What's left of Agile?

Agile was seventeen people in a ski resort in Utah in February 2001 who couldn’t agree on much. They agreed on a name, four values and twelve principles, and that was enough to start a movement.

Twenty years later most people who say Agile mean Scrum, and most people who sell Scrum have never shipped anything. Here’s what I think is left.

There are two kinds of business people

The first kind work in sales, customer relations, requirements, finance, reporting. Honest business people. These are the ones you collaborate with to make the software worth more.

The second kind attach themselves to whatever initiative is currently cool and produce confused hot air, wide logic gaps, certified certification paper, cargo cults, and cult masters to run them. I call these Dishonest business people™.

You can spot one. They possess knowledge that is somehow both magical and unavailable to you. They sell certifications and titles. They impose rigid rules in the name of adaptive process. They have a meta job title like Agile Evangelist or Certified Scrum Trainer. You could swap them for a religious or political leader without noticing a change in attitude, discourse, behaviour or output.

I call them dishonest rather than mistaken because they know. They know Agile. They know they don’t have the practical experience to consult on it. They know the processes they evangelise are flawed. They know a certification you pay for without being tested is worthless. They know all of it, and they keep selling to people who don’t know yet.

I should declare an interest here. I hold two of these certifications myself, Certified Scrum Master and Certified Scrum Practitioner. That is precisely why I’m comfortable telling you what they’re worth.

Agile humbleness

Robert C. Martin calls himself a software engineer. Martin Fowler calls himself a software developer. Kent Beck, software engineer. Ken Schwaber, software developer. Alistair Cockburn, computer programmer.

The people who started this thing describe themselves in the plainest terms available. If they don’t call themselves Agile Coach or Agile Guru, it’s worth asking why anyone else does.

What project management actually is

A way to reduce chaos in a project so that you get a better than random outcome.

That’s it, and every methodology is just a different lever on the chaos. Waterfall reduces it with detailed upfront analysis and supervision. Scrum with timeboxing and fixed iteration scope. Kanban by limiting work in progress. RUP with diagrams. XP by sharing knowledge and keeping things simple. Six Sigma by measuring everything. PRINCE2 by cutting the project into controllable stages.

Which brings me to the thing that took me years to properly absorb. If you’re doing Scrum but not keeping the code clean, Scrum fails. If the team isn’t motivated, Scrum fails. Scrum succeeds only when everything except the project management is already working. It is not a fix for anything. It’s a coordination layer that works on top of a healthy team and collapses on top of an unhealthy one.

Where Scrum came from, and what got dropped

The original is a 1986 Harvard Business Review paper, “The New New Product Development Game”. An executive at Honda, describing the approach: “I believe creativity is born by pushing people against the wall and pressuring them almost to the extreme.” Same man, on how it feels: “It’s like putting the team members on the second floor, removing the ladder, and telling them to jump or else.”

Two of the original core concepts were Multilearning and Transfer of Learning. Both were dropped later, because it turned out people didn’t love being asked to learn that much. Another was Subtle control, about how management keeps instability and tension from becoming chaos, including group-based evaluation and reward. That didn’t make the cut either. It wasn’t cool.

The paper was also honest about where the approach doesn’t work. It requires extraordinary effort from everyone, with team members logging 100 hours of monthly overtime at peak and 60 the rest of the time. It doesn’t suit breakthrough work needing real invention. It doesn’t suit enormous projects where face-to-face won’t scale. It doesn’t suit organisations where one person makes the invention and hands down the specification.

Read that list backwards and you get the target audience: regular people, doing small and not very innovative projects, working a lot of overtime.

It took two decades to catch on

ProtoScrum appears somewhere between 1983 and 1993. Scrum is formalised in 1995. Then a gap nobody talks about. Guided popular Scrum arrives around 2009.

Sixteen to twenty-six years to reach the early adopters. Ten of those years are pure confusion. That’s not the adoption curve of an idea that was obviously working.

It evolved like an ideology

First there are some people with a new philosophy. Help strangers, be good to those who hurt us.

Then early adherents join and adjust it to fit their own view. Let’s do that, but maybe not all the strangers, and maybe just try hard to ignore the ones who hurt us.

Then the Dishonest business people™ arrive and finish the job. Good idea, but first you pay us. We use the money to build Expensive Goodness Edifices™. The whole thing is now rigid, and if you change it we burn you. We keep a cut for certifying people as adherents. We also sell tickets to the burning.

The vegan test

There are two ways to be a vegan. You can label yourself one and then try to fit the pattern, or you can follow the practices and skip the label.

The difference shows up when you change. Move from vegan to ovo-lacto-vegetarian as a labelled vegan and people judge you as inconsistent and disloyal to the cause. Do it as someone who just ate vegetables and nobody says anything, because you’ve simply changed what you do.

Doing Scrum is labelling yourself. Being Agile is eating the vegetables. Think about how much time has gone into arguing whether a team is really doing Scrum, or ScrumButt, or FlaccidScrum. None of that time went into the product.

Scrum’s education problem

It teaches rituals instead of the nature of the work and the difficulty of improving at it, because a ritual is far easier to teach. Sprint planning, retrospective, estimates, user story, daily stand-up, epic. That’s what most companies I know actually practise, and it is a cargo cult.

Until Scrum starts being about agility again, it has lost its claim to being Agile.

So what’s left

Avoid labels. Stick to the values and the principles, which still hold up.

Don’t learn superficially. Read, try, listen, observe, understand. The ritual is the easy part and it’s the part that doesn’t work.

And take the thing back. Dissociate Agile from Scrum. Tell newcomers that the soul of it is building your own process that works, improving on it, and learning from the people who got it wrong before you. Remember that Agile is a software thing, so pair programming and unit testing are not optional extras. And remember it’s built out of people: no process or ritual substitutes for a motivated team.