Fight Bad Agile!

Command and control did not
 work then and it will not work now.  

I have been involved in the agile reformation for the last ten years.  In 2009, the agile manifesto was relatively young, and it was a quirky idea to make software better. Today we have three primary scaling techniques for agile.  The reformation has grown and splintered over the years, but the manifesto remains the pole star which every variation circles.  Now business professionals and executives are paying attention to the reformation.  Agile is eating the world, but instead of confronting opposition, we are dealing with corruption caused by the status quo as it exists in many companies.  The corruption creates bad agile, and it is up to coaches and scrum masters to call it out.

Last week, I pointed out that a common dysfunction in organizations is leadership spends too much time pleasing superiors rather than doing the necessary work to make the business successful.  The behavior hurts collaboration between departments and categorizes people as resources which can be swapped out like machine parts.  It is dehumanizing and alienating.  Agile helps fight this dysfunction with emphasis on cross-functional teams and less organizational friction.  The challenge of agile is it works well in the realm of the team, but as it attempts to scale out to the organization, it butts against status-quo thinking, entrenched political agendas, and the command and control mindset of most executives.

Put yourself in the shoes of a typical executive who has spent ten, fifteen, or twenty years in an organization. The executive has presided over budgets and deadlines.  The contact they have with the people doing the actual work is limited, and their knowledge of project management is slight, so they hire project managers to handle the responsibility.  Most of the time, executives spend time involved with pleasing superiors and political sparring with rivals.  An agile coach comes along who tells them they have the wrong career focus, and they have been leading their people incorrectly.  Agile, with its emphasis on inspection, adaption, and transparency, undermines political infighting within an organization, which means career advancement depends on results instead of deception.  It is going to create anxiety, and the executive is going to push back.

The executive is not evil in this instance; the new way of doing things creates uncertainty and fear.  It is natural they would be resistant when confronted with this upsetting of psychological safety.  As a coach, it is going to be your responsibility to address the resistance.  You are going to walk the executive through the process of shifting from a command and control mindset to an agile mindset.  It will not be easy.

Instead of telling people what to do, the scrum master will have to show them.  Lead by example, give the team what they need to succeed, live the agile manifesto and principles, and point out organizations friction where it exists.  Inspection, adaption, and transparency are designed to hold everyone accountable particularly executives.

Bad agile happens because self-interest and the status quo are more important than getting work done.  We tolerate double standards, and it creates corruption.  It is up to each scrum master or coach to reveal this corruption so we can mitigate its effects.  It is up to each of us to show instead of telling others what to do.  Finally, we need to create psychological safety among leaders if they are to embrace agile.  Otherwise, we remain stuck with bad agile.

Until next time.

People are individuals not resources.

Treat people like individuals.

The global economy is a big place.  Trillions of dollars slosh around the globe while people attempt to traverse the currents without drowning.  What business people often ignore is the people keep the global economy moving are individuals with lives, families, and challenges outside the business realm.  A person is more than a job description.  A person is a flesh and bone being with triumph and tragedy.  Each day billions of people wake up and struggle in the global economy to put food on the table.   The daily struggle is equal parts heroic, absurd, and necessary.  As leaders, we should understand the people around us as individuals rather than anonymous cogs in a wheel.

I often cringe when I hear professionals and business people refer to the people working for them as resources.  It is deeply dehumanizing. Each person working today is an assemblage of emotions, education, and experience.  Leaders should see these differences and put them to work.  Often, leadership is too busy showing off to their superiors to concentrate on what it takes to do the work.  It is a common pathology in business, academia, and government.  Agile Coaches and scrum masters have to help break this cycle of dysfunction.

The first part of the agile manifesto says, “Individuals and Interactions, over processes and tools.”  We need to embrace that value.  Each person working with us is an individual.  Each time we inspect and adapt, we should take into account not only the performance of the team but the performance of the individuals with the team.  In this way, we can coach others for success and help them work through failure.

What I am suggesting is hard work, but it will provide significant dividends.  Well lead teams have higher quality and deliver work faster.  Teams who work well together innovate.  Finally, teams who work well jointly make work more satisfying and sustainable for the business.  It is what happens when we treat people like people instead of resources.

Until next time.

Agile, Story Points and Rock-n-Roll

The Crüe are very rock-n-roll and agile.

Being an agile coach is filled with plenty of touchy-feely moments.  You have to deal with difficult emotions and move change through an organization which is satisfied with the status quo.  Other times a coach or scrum master must deal with the practical matters of scheduling a meeting and facilitating a retrospective.  Finally, you are learning new things and applying them to your clients.  My vision of how story points work has changed over the years.  Recently, I am looking at story points in a new way, and it is good enough to share.

My first thoughts about story point made me think of them as measures of volume.  A story point contained a certain number of hours, and it would be easy to convert the two back and forth.  After my first 18 months of being a scrum master, I saw the folly in that way of doing things.  It became apparent that story points represented something analogous to distance.  An Olympic runner can cover 3,000 meters in under four minutes.  I can walk it in about a half hour.  Story points provided a quantitative way to measure uncertainty and help communicate to upper management.

Now I see a story point as the sum of four factors; complexity, risk, effort, and uncertainty.  We sum all these factors together and round them up to the nearest whole number in a Fibonacci sequence.

So if I wrote it out a math formula it would look like this:

Story Point = Complexity + Risk + Effort + Uncertainty
F_N = [Story Point]

Where F_N is a number in a Fibonacci sequence.

The new acronym for this is CRÜE, after the rock band Mötley Crüe.  By today’s standards, this giant of 1980’s glam metal would flame out in the public eye.  The band was nihilistic, misogynistic, and poster children for the destruction of alcohol and drugs could do to a person.  Finally, the lead singer killed someone in the act of vehicular manslaughter.  In spite of all the baggage, you could count on the band to put on a great show.  You could also count on them to be blaring out of any stereo at a house party during the 1980s. People of a certain age have memories of significant life events happening with Mötley Crüe playing in the background.

As an agile coach, I will let the young people concern themselves with sex, drugs, and rock-n-roll.  It is not my lifestyle.  I prefer agile, story points, and rock-n-roll.  If you are talking about story points, talk about Crüe; complexity, risk, uncertainty, and effort.

Rock on people and until next time.

The Scrum Master as a Square Peg

Your scrum master is a square peg.

I have said repeatedly agile is a reformation to the business world.  It is not an uprising with torches and pitchforks.  It is a smart and conscientious people seeking reform and the abolition of corruption in business.  It is thankless work. Today on the blog, I would like to talk about the job and how it requires devotion to be successful.

The scrum guide makes the role of scrum master sound easy to fill.  A scrum master is a servant leader.  A scrum master is a person who promotes and supports scrum in the organization.  Finally, they help others understand what helps and interferes with the delivery of solutions.  It sounds simple but is a career fraught with peril.  A scrum master is often a misfit inside the organization doing what they need to do to get work done.

A scrum master ruffles feathers daily.  It means being on the phone, making sure network permissions are correct.  It is attending a meeting so the development team can concentrate on delivering value.  A person in the job spends plenty of time asking uncomfortable questions and does not accept, “…because we have always done it that way,” for an answer.

Scrum mastery requires being the person who points out when the emperor’s new clothes are illusionary.  The scrum master gets work done and being able to ship product to customers often silences critics inside the organization.  Paradoxically, this kind of success breeds organization resistance because you are upsetting established patterns of work and culture.  It is leadership without authority which drives ineffectual people to resentment.  It is the opposite of the go along to get along personality, which often crops up in corporate organizations. A scrum master by their very nature is an iconoclast.

It explains why a scrum master is often a square peg in a round hole.

Until next time.

A River of Leadership

Leadership is like white water rafting.

The world of software development is an untamed river of uncertainty and innovation.  I swim in this whitewater of ambiguity and get caught up in its currents regularly.  Technology never rests, and the pressure to sink or swim is always present.  Being a leader is more perilous because you are also responsible for the wellbeing of others who work with you.  I want to take a closer look at those responsibilities of leadership.

At the recommendation of my colleagues, I am stepping forward and founding a chapter of the Agile Coaching Exchange in the greater Chicago area.  It is a new role for me and something I have not done before.  I am gathering speakers and attempting to set up venues for the group to meet.  I have been a participant in these kinds of gathering for years, and now I am organizing them.  It makes me respect the people organizing meetups and user groups more because I understand how much hard work it is.

The experience reminded me of a blog I authored about leadership.  A person has three choices when confronted with a challenge; lead, follow, or get out of the way.  It is time for me to show some leadership in the agile community instead of ranting like a voice in the wilderness.  It is not the traditional leadership I was trained earlier in my life to adopt.  Times change, and so does leadership.  Claire Croft mentions this in an article for Forbes magazine.

The global economy is changing too quickly.  Sears and ToysRUs are gone.  The internet reaches over half the world's population, and it is growing by 2% annually.  We measure success in days instead of years.  Finally, the job I have today did not exist when I was a college undergraduate.  It means traditional notions of leadership are not going to adapt to the turbulence of the current business world.

It means leadership needs to come from inside.  You have to play up personal strengths and work with your shortcomings.  Instead of a mask of command, a leader should expose themselves to others to build empathy and radical candor.  It includes being kind to yourself and others because we are all fighting unique struggles each day.

I continue my adventures rafting the unsettled river of technology.  As the water rises and falls, I will change my leadership style to navigate to the next destination.  I am grateful for each of my readers, who are sharing this journey with me.

Until next time.

Start Writing Unit Tests!

It helps when you test your code.

Software development is a difficult process.  It is filled with trial and error.  Developers must contend with vague requirements and impossible timelines.  It explains why the profession has a high failure rate.  I think we can do a better job and today I would like to discuss the easiest way to help reduce failure.

When I first learned about software development, the notion of software testing was primitive.  Often software testers manually went through the software attempting to find bugs.  It was a tedious and time-consuming process.  Automated testing began to pop up in the world of JAVA and then spread to the Microsoft world.  At first, developers chaffed at writing unit tests calling it extra work and unnecessary. 

After the initial resistance, the engineers and developers began to see the importance of unit tests.  Unit tests ensured the code functioned when checked back into source control.  It also made sure a change in one part of the code would not break a different portion of code.  Automated testing had another impact.  Manual testing became unnecessary and if freed up people to deliver more value in the organization. 

Automated testing not only cut back manual tests, but it also makes the release of software faster.  What usually would take three weeks to release could now take as little as three weeks.  Thus, automated unit testing reduced labor overhead improved the quality of software and increased the time to market for software.  Instead of chaffing at writing a unit test, the real question is why you haven’t started writing them.

Until next time.

Self-Organization Works If You Let It.

Teams cannot be assembled like Lego bricks.

I spend much of my time working with agile teams.  A big challenge is often these people are thrown together and forced to behave as a “team.”  The self-organizing team is one of the most critical pieces of an agile project, and it is one of the hardest things to create.  I wanted to spend some time discussing why building teams is so difficult.

In most business environments, a team is formed by hiring consultants and putting them together with existing employees.  The team is broken up, and the consultants are laid off or moved to a different project when work is complete.  The approach from an accounting perspective might make sense, but it creates plenty of unnecessary work.  Teams are continually going through Tuckman’s stages of group development and are in the “storming” stage of team maturity.  In a more agile environment, work comes to teams, and then the teams do the job.  The group moves on to a different project when they finish work.

According to the Harvard Business review teams which stick together have a 19% decrease in defects and 30% decrease in budget deviations.  The bottom line is that spinning up units and disbanding them is a foolish use of company money.  So what makes the team self-organizing?  Yvette Francino has an excellent blog on the subject.  In short, teams which self-organize have a few properties:

1. They hold themselves accountable for success and failure.
2. They healthily handle conflict.
3. They have a common goal which they strive to achieve.
4. They have a standard way of working.
5. Finally, they have stable membership.

These traits make an excellent self-organizing team, and it is up to agile coaches and scrum masters to hold them accountable.  Notice that these requirements do not mention test-driven development, SOLID Development, or other technical paradigms.  Most of these skills are soft skills.  It means that a team needs to learn how to work together outside of the technical skills, and this is difficult.  People have egos and subtle hierarchies of expertise and authority.  Add to the mix unrealistic deadline pressure and micromanagement from outside leadership, and you corrupt the five characteristics of self-organization.

So look toward creating more functional teams and allow upper management to understand how they are more successful.

Until next time.