I’ve been thinking about iterations quite a bit lately. To me, they’ve always been an odd part
of Agile. Scrum gave us the month
long sprint, and for years it was sacrosanct. The thought was that it wasn’t possible for teams to do real
work in less time. In Extreme
Programming, we had two-week iterations, but at least it wasn’t a hard-and-fast
rule. The primary consideration we
had was that no matter how you picked your initial iteration-length, you should
at least keep it constant and not give in to the temptation of saying “well,
we’re having trouble finishing our stories for this iteration, let’s extend it
for a few days.”
From the very beginning, the goal of iterations was to force tradeoffs, hard decisions. Without that discipline, development can really fall off the rails. Teams need to know how to bring work to closure and there’s no closure quite like being able to say: “this functionality is tested and shippable right now.”
The odd thing about iterations, though, is that you don’t really need them. Or, at least not everyone does. This was a bit of a shock to me. I remember working with a team back in the 1990s that had three-month iterations, and things weren’t really ever getting to closure except in the last few weeks. There was no urgency and they suffered because of it. This reinforced the idea that iterations really were necessary, but then I heard about programmers in some trading companies that pushed code into production continually. It was odd, I thought. It must be weird not to work with a macro cadence or rhythm – no sense when you go home that you’re closer to realizing a large concrete goal that you’ve had for the last week or month.
Later, after the first wave of agile, I encountered high performing teams that had gone completely iteration-less with no ill effect. Today, Lean and Kanban are popularizing this model. Regardless, I do feel that iterations teach a valuable lesson. They teach you how to really bring work to closure. It’s a very valuable thing to know, and once you know it, many other things become easy in software development – going iteration-less is no big deal. I do think, though that there is another piece of learning we can get from iterations that is hard to achieve any other way. I guess I can describe it as an experiment:
Suppose that you had an iteration of one week, followed by an iteration of 2 days, followed by an iteration of 1 day, followed by an iteration of one-half a day, and so on. If you still had your sanity at the end of this process, would you have learned anything? I haven’t tried it with a team yet, but here’s the thing that I hope would come across: if you apply enough ingenuity and you’ve acquired enough skill, you can deliver business value in shorter times than you can currently imagine.
Time boxes are a constraint. They force conversation and force tradeoffs. And, really, that’s not a bad thing. It’s fertile ground for creativity.
Look at your product today. If you only had one day to develop and deploy some feature, before putting the product on ice and letting it generate revenue as is forever, what would it be?
