Zeno-Length Iterations

 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?

 

Comments

[Steve Berczuk]

Very well said. The challenge I often see is teams that decide to skip iterations not because they are successful at setting and reaching goals, but because they feel that iterations are "too constraining." Which often translates into "we can't figure out how to deliver something in 2-weeks." This post at least explains that the opposite of iterations is going toward shorter intervals between deliverables, not longer ones. I do suspect that many teams can benefit from 1-2 week iterations though, and need to practice delivering on that schedule a few times before changing to a different approach.

[Tungano]

I find iterations valuable for giving me a period in which I can work on a small batch of stuff uninterrupted. With a constant flow of 'features' to be build you can't have the whole team be part of analysis (unless you want to continuously interrupt them for it that is), something that is possible when trying to do the bulk of analysis at iteration boundaries.
In more ad-hoc situations I have faced a constantly changing demand from the business which can result in a lot of half done work (destabilizing the codebase if it had intermediate commits), work that gets terminated, things that need to be 'shelved' for awhile (only to find out it doesn't easily fit on the codebase anymore when unshelved). Iterations perhaps create some closure on the business end also. For me it ends up feeling like analysis paralysis while having people actively coding to it too.
Also a small batch of features may widen your 'YAGNI context' when designing, especially when the 'features' are around one particular theme.
I don't want to be interrupted while building feature A to help analyses of feature B, iteration boundaries help there.
With a constant influx of new features to code, programmers may end up getting removed from analyses altogether and loose contact with the software's big picture, road map and it's context.

[Javame]

Iterations are useless, or, at least, useless with an experienced, committed agile team. In a less experienced team they should remember the weekly targets, however in a team pulling stories from the wall rather than pushing stories to the devs iterations are just a waste.
Some manager may need to track the velocity, that can be hidden to the team, no need to communicate team speed, values of the story points or current iteration target, the team has to release features not points, the team doesn't have to burn down iterations burn down charts, the team has to produce quality software.
I never got the way too long spring monthly iterations, I don't see the point of two weeks iterations (still too long to get an heartbeat), I was ok with flexible weekly iterations (just for tracking, no wall reset, no planning, no usual zealot activities).
Some teams use micro-iterations, day iterations or half a day, pure madness.

Iterations are muda, they require quite some time from the team to get setup, tracked and followed and they add very little value.

[Matteo Vaccari]

I keep trying to get my team to split large stories. They resist strongly to this, as they say "the *customer* will not accept that this bit by itself has value". What should I answer to this?

[Samipoimala]

You all have good points there but the thing that stresses me is that you (like many others these days) do not make difference between an iteration and an increment. The fixed timebox that forces tradeoffs is an increment.

A few days ago I tried to illustrate these things, have a look: http://samipoimala.com/it/2010/04/16/iterations-and-increments-explained/

Kanban and other lean techniques are abandoning increments and replacing them with continuous flow of value (and process feedback), but iterations can still coexist if less visible though.

[Pawel Brodzinski]

Personally I never liked iterations much. Short iterations do a good job in creating tension to complete things on time (and often), but they also make planning more difficult since you have to find chunks of work which suit the iteration.

Longer iterations are more difficult to plan and usually learning pace is average.

On the other hand one of risks of resigning of iterations at all means throwing away deadlines (to some point at least) which can may result in a bit of disengagement.

In my team we use Kanban and have no iterations in a way people understand them but we use something I call pseudo-iterations. This helps us to bring more order to deployment and version control but is also a way to bring some more tension.

[Luca Minudel]

> Regardless, I do feel that iterations teach a valuable lesson. They teach you how to really bring work to closure.

also think that boundaries iterations help to deal with wicked problems and help the team to self-organize.

have to questions:

- should a team try Zeno-Length Iterations before been capable of doing well time-boxed iterations ?

- anyone used Zeno-Length Iterations and successfully managed wicked problems ?

[Manfred]

A team is not isolated to the rest of the organization. An iteration can be a heart beat going through the whole organizations. As bigger a organization gets as more important is the rhythm they dance.

[Swreflections.blogspot.com]

I accept the idea that changing the length of iterations, making them smaller, has some value. It’s an idea that Johanna Rothman explores in Manage It!

The smaller the iteration, the easier to look at it from beginning-to-end and see where time is wasted, what works, what doesn’t, where time is being spent that isn’t expected.

And the idea of moving to zero-length iterations by halves is an interesting thought experiment, in a Zeno’s Paradox kind of way I guess.

But I have real concerns about shortening iterations towards zero.

First there is the problem of sustaining this approach over time. I manage a group that has been following incremental, rapid development and delivery on the same product for a few years now. We deliver business-critical software for an online financial application to production every 2-3 weeks. I am concerned about the effects that rapid cycling and continuous focus on delivery have on an organization, the demands that it makes on people, over an extended period of time.

http://swreflections.blogspot.com/2009/06/how-long-can-this-go-on.html

You are always delivering, always “on” with little time to reset. Moving even faster, moving towards zero, I don’t think is sustainable over any reasonable period of time.

My other concern is around reliability, and especially security. This idea of "zero-length iterations" has a lot of the flavor of “continuous deployment” and there are some serious weaknesses to continuous deployment, which I ranted about here.

http://swreflections.blogspot.com/2010/03/continuously-putting-your-customers-at.html

As a community, we as software developers are already being challenged by the poor job that we are doing in building secure software, or software in a secure way. In the latest releases of its SDL, Microsoft has shown how to strip a secure development lifecycle down to fit short iterations, down to a minimum set of practices. And at this level you are already taking on risk, you are making compromises for speed over safety, which might be acceptable if you have an experienced development and operations team, excellent engineering practices, a secure architecture and deployment infrastructure, and you’re not deploying a system which is exposed to the Internet. I have yet to see a successful secure SDLC for Kanban or whatever, a secure way of building and deploying software in a continuous way, some way to include all of the necessary reviews and checks in-line with the work as it is done.

There are some serious, to me, unsolved problems and risks here, we need to think and learn a lot more before we’re ready to take this kind of idea on and be successful in any real way.

Jim Bird

[George Harrison]

I love 2 year iterations, they are like a combination of everything I love about Scrum (iterations), XP (2 of something, pairing, 2 week iterations), and waterfall (really long amounts of time between feedback)!

Really, you guys need to work harder on melding the best concepts from each Project Lifecycle methodology.

[Robert Sfeir]

Fact is that iterations are necessary to box things in for everyone. What I often find asinine is that teams feel like they have to stick to 3-4 week iterations even if you don't finish everything in your iteration; the next one is still 3 weeks.

The way I approach it is: setup the first 3 week iteration. Let the team do the work. If you get to the end and work is not done create an iteration for the issues left. You figure out the length of the iteration based on the number of points left over from the previous sprint. The advantage of that is that sometimes you can release what ever is in the first iteration, and it gives your users a chance to get to use the new code. You then release the remaining work a week or two later and you get the whole thing out. In the mean time you got feedback and everything is still going full speed for your team. The result is low stress, continuous releases, and good timeboxing to setup expectations for your team.

Good article.

R

[iPhone contacts backup]

Just think about it and get ready to do it.