« Thoughts on the Future of the Boutique Software Shop | Main | Class Splitting and the Graph View of 'Extract Method' »

April 25, 2010


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.


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.


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?


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 ?


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.


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.


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.


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.


iPhone contacts backup

Just think about it and get ready to do it.

The comments to this entry are closed.