Iterations, not sprints

David Hussman raised this very interesting point on Twitter, something worth serious thought…

But Agile already has an alternative word for sprint — Iteration. “Sprint” is Scrum-specific terminology.

Words are vague, and drag oft-unintended implications around with them. The word “sprint” implies a velocity — in a forward direction, for a short period, as fast as humanly possible.

Of course, in the real world, you don’t run a sprint and immediately follow it with another sprint, and another, in an uninterrupted sequence. You’d quickly fall over from exhaustion. So as a metaphor for software development, it’s problematic.

The Tortoise and the Hare, Disney 1935

Agile has always had this problem — the idea that Agile is a faster way to develop software, rather than a better way. Frankly, I think this is one of the things that sold the industry on Agile. And now, twenty years since Scrum and Extreme Programming hit the scene, people still expect Agile to be faster, as opposed to better.

And David hits the nail on the head here… the idea that Agile is fast rather than good is embedded right in the most fundamental terminology of the most widely-used Agile methodology. It’s a problem we’re bringing on ourselves.

“Iteration” has different implications. First, it implies that we are taking something we already have, and making it better. But perhaps more importantly, it does not imply a pace of change. Iterations can be fast, or they can be slow. The important part is the improvement, not the speed.

This gets to the heart of Agile, for me. When we finish an iteration, we should be in a better place than when we started the iteration. We should see visible progress. The curse of Waterfall was not being able to see progress (and due to that lack of visibility, not being able to make course corrections). The curse of Scrum seems to be this false idea of maximum speed.

When we’re driving and conditions are sketchy ahead of us, we slow down. We don’t drive at maximum speed. The beauty of Agile is that it helps us deal with uncertain conditions, because the road to our products is rarely straight and level and dry.

Agile isn’t how fast you can go, it’s how fast you can turn.

The other day, I watched The Quick and the Dead, a classic documentary about Formula One auto racing in the early 1970s. At the start of the movie, the narrator made an interesting point — “These cars aren’t just fast. They’re quick.” Formula One cars can brake hard, accelerate hard, and turn hard, much harder than ordinary cars. They’re the fastest cars not because they have the highest top speed, but rather because they are the most responsive to complex, always-changing conditions.

And that’s what I want Agile to be. Not necessarily fast, just quick. Not sprints, just iterations.