It is a commonplace that iteration length should be set according to release cycle length. I disagree; I think the two cycles should be decoupled. Short iterations provide more-frequent feedback from customers than long iterations and afford the team more opportunities to reflect and improve their work practices. Shorter cycles result in a "heartbeat" that occurs frequently enough to be meaningful. Short cycles naturally prevent the team from creating work items that are tediously large, with no "success" point to be had until a great deal of work has been done. These benefits apply even when the release cycle is long.
Benefits
- Rapid response to changes in priority without disrupting work in process. It's not unusual for the Product Owner or Customer or Proxy to change priorities or add features in mid-iteration. This can be managed more cleanly if iterations are short enough that the changes may be made in the next iteration instead, since the regular pulse of iterative work need not be disrupted.
- Problem detection. Mature agile teams recognize process smells and act on them immediately. At the moment, however, most teams using agile methods are still on the learning curve and they haven't reached a level of maturity with agile development that lets them depend on their noses. They need to track trends in project metrics to recognize problems. Given that it takes 3 data points to make a a trend and that project data are collected once per iteration, the implication is that shorter iterations expose problems faster.
- Scope management. It's easier to move backlog items around when they are small than when they are large. Longer iterations tend to result in larger User Stories. When the Product Owner needs to change the priorities of backlog items, the impact of any given change is greater when the User Stories are larger. Shorter iterations tend to result in smaller User Stories. Following the INVEST principles, the User Stories will be easier for the Product Owner to reprioritize.
- Iteration planning and tracking. The larger User Stories that usually come from long iterations often require decomposition into "tasks" to break the work down into bite-sized pieces. The tasks then have to be tracked throughout the iteration just so that the team can understand the status of all the Stories, either using a kanban-like system or an iteration burn chart. Many teams pause to re-estimate individual tasks that remain in incomplete status each day. All this internal process overhead can be eliminated by running short iterations so that User Stories are, themselves, small units of work and people can follow the status of the iteration in a simpler way.
- A foundation for moving to an iterationless process. An iterative approach retains some of the natural overhead of a waterfall process even when we go to some pains to remove it. A cumulative flow diagram may expose this overhead in the form of "lead time" from the start to the end of each iteration. As teams I've worked with have squeezed their iteration length as far down as they could manage, I've noticed that they were able to eliminate significant amounts of this overhead. The shorter the iteration, the less process overhead is needed to keep things on course.
On the other hand, the discipline of working in timeboxed iterations is the source of some of the value-add of the agile approach, including frequent and regularly-scheduled demonstrations and retrospectives, a consistent schedule for delivering incremental results, frequent opportunities for customer feedback, and the sense of a "heartbeat" or "pulse" that seems to keep teams engaged over the long haul. Therefore, it seems reasonable to expect short iterations can provide a low-pain transition to a very lightweight iterationless process without making the mistake of "throwing out the baby with the bathwater" by dropping the value-add aspects of timeboxing the work, as some teams unfortunately have done when adopting an iterationless process.
A common mistake is to assume any and all practices the team had associated with "iterations" should be discarded when they move to an iterationless process. We do well to separate the concept of "iterations" from the specific value-add practices that are commonly associated with agile development, and look for ways to reduce process overhead while preserving beneficial practices.
Potential downsides
Some people have experienced problems with short iterations. Mishkin Berteig, proponent of short iterations, also mentions some potential downsides:
- "Intensity of work can lead to burnout." I think this is a question of how the team chooses to work. Short cycles don't necessarily translate into higher intensity. It can be done in such a way that short iterations only mean smaller timeboxes; that is, you commit to deliver less work per timebox. There needn't be any difference in "intensity." Other agile principles (notably "sustainable pace") are designed to prevent burnout.
- "Strategic thinking can be hard to fit into the schedule." Strategic thinking isn't an iteration-by-iteration matter. Iterations are tactical. Strategic thinking is...well, not tactical. This sounds like a management problem rather than a characteristic of short iterations as such.
- "Overhead tasks that must be done every iteration take a larger proportion of the time in the iteration." This sounds like another issue that boils down to how the team chooses to work. I've observed an interesting effect of squeezing down the iteration length: People "discover" certain overhead tasks were never really necessary in the first place, and stop doing them. They end up doing only what is necessary, which is another way to say they eliminate waste from their process. In fact, this observation leads me to disagree respectfully with Jim Shore's observations in a Java Ranch discussion that longer iterations are less stressful and that longer iterations work better for experienced agile teams. I don't think we want more time for iteration planning; I think we want less iteration planning. I'm for ever shorter iterations, vanishing to none as we move to a customer pull approach with single-piece (read: single feature) flow.
- "Waiting for resources or people outside of the team can make it more likely for work to span iterations." This is an organizational constraint. It isn't practical to try and run iterations shorter than the organization can handle. When you do that, they aren't really "iterations" because it isn't possible to deliver results that quickly; the organization can't absorb the results. To go further than this requires us to address the organizational constraints. I wouldn't assume shorter iterations are impossible because of a temporary organizational constraint - and they're all temporary, if you really want them to be. Easy? No one said that. But if organizational change were easy, it wouldn't be so much fun, would it?
Related InfoQ content: Extremely Short Iterations as a Catalyst for Effective Prioritization of Work
About the Author
An IT professional since 1977, Dave Nicolette discovered Agile in 2002 and found it solved or alleviated many of the problems inherent in traditional IT. Since then, he has been a dedicated practitioner and ardent proponent of change toward Agile and Lean thinking and practices. He enjoys sharing experiences and effective practices with fellow IT professionals and participates actively in the agile community. Dave is currently an agile team coach for Valtech Technologies in the US.
