Pattern of the Month: Iteration

If there is one pattern which is most commonly associated with agile practice it is surely the ability to iterate. The skill to inspect and adapt may be considered to be more fundamental by seasoned experts who have mastered agile theory, while the actual delivery of increments might be favored by others. In the vagabond court of public opinion, however, iteration is the defining quality of an agile way of working. Iteration is held to be the proof of it, irrespective of how incremental delivery is accommodated or whether inspection and adaptation ever happens at all. The rationale behind iteration may not be generally well understood, yet to many, it is the singular characteristic which most obviously distinguishes an agile approach from a stage-gated one.

The superficiality with which iteration is commonly regarded can be quickly exposed. Try to define what iteration means, and a range of modalities soon becomes apparent. In Scrum, for example, an “iteration” may be crudely equated with a Sprint during which a forecast of work for achieving a goal is framed and met. It is a time-boxed event which contains other events such as planning, a review, and a retrospective. A Sprint is certainly a true iteration in which no gaps or delay between cycles may be countenanced, and which is subject to clear rules of time-boxing. Even within the terse framework of Scrum, however, the equation of a Sprint with an “iteration” is too simplistic. After all, each working day can also be considered to be an iteration. It is a narrower cycle marked by a Daily Scrum in which team progress towards a Sprint Goal shall be inspected and adapted.

The confusion of an iteration with an increment is an old chestnut which is often encountered. In Scrum each Sprint must yield an increment which is of release quality. The conflation of this product artifact and the iteration in which it is produced can therefore seem natural. However, Scrum does not proscribe against the continuous delivery and deployment of increments at multiple discrete points throughout a Sprint. Increments, in Scrum, are held to be cumulative. Any number of increments may therefore be envisioned, developed, tested, and verified before a Sprint comes to an end. Each may be subject to a finer level of iterative development which teams are free to implement as they see fit within their own operating context.

This nested model of iterative agile development perhaps finds its clearest expression in Extreme Programming. Arguably more of a methodology than a framework, XP describes loops for release and iteration planning, acceptance testing, the holding of daily stand-ups, right down to testing and pairing at a fine-grained coding level. Each cycle is an opportunity to inspect and adapt the flow of value to a commensurate level of concern.

DSDM, meanwhile, places iteration “at the heart of everything developed.” In accordance with this principle we are reminded that business feedback is essential in order to truly close a loop, and that it is an opportunity to exploit creativity, experimentation, and learning. Interestingly an iteration is deconstructed from the wider notion of a time-box, one of several distinctions which typify this framework.

The practice of iterative development and delivery is challenged by Kanban and other lean models which emphasize flow. An iteration, such as a Sprint, may be criticized as an attempt to batch work and to increase the leap-of-faith taken before value is evidenced, while the depreciation of work-in-progress is risked along with other forms of waste. This concern may be overstated in the case of Scrum, where a Sprint Backlog is essentially a forecast of work to meet a goal, revised in light of evidence, and which therefore mitigates the worst batch-like characteristics. Nevertheless the argument remains that a lean way of working should operate on the basis of continuous flow and is therefore essentially non-iterative. A counter-argument can be made that while product increments may indeed flow non-iteratively on the basis of demand and pull, a Kanban team may reasonably iterate at a certain cadence in order to inspect and adapt its progress using time-boxed metrics.

Iterate

Intent: Handle small pieces of work at regular intervals.

Proverbs:

• "Many small steps make a journey."
• "A rolling stone gathers no moss."

Also Known As:

• Sprint

Motivation: Linear planning has a very limited capacity to support change, and defers the delivery of value beyond stage gates. The iterative rebaselining of plans minimizes the risk of change and the potential for waste, while also providing regular and frequent opportunities for the incremental delivery of value.

Structure: A project will have many Sprints (iterations). A team will tackle the project one Sprint at a time. They will select a Sprint Backlog of work from the Project’s Product Backlog. The success of each Sprint can be determined by inspection, and working practices adapted so that future Sprints are more effective.

Applicability: Iterative development and delivery is a feature of any truly agile process. Although it is possible to develop products iteratively and without the incremental release of value, this limits feedback and the ability of a team to inspect and adapt their process in an risk-reductive manner. It also results in the depreciation of product worth. The application of iterative development in agile projects must therefore align with the incremental delivery of value.

Consequences: Iterative development allows plans to be revised at regular time-boxed intervals. When accompanied with incremental releases of value, product depreciation is minimized and the risks associated with delivery are reduced.

Implementation: The canonical iteration in most agile ways of working is the Sprint. This is a time-box of no longer than one month and always results in a potentially releasable increment. This implementation originated with Scrum but it has subsequently gained wider currency. Each working day is also an iteration, and is commonly demarcated by the inspect-and-adapt opportunity of a Daily Stand-Up. DSDM and XP support iterative feedback at additional levels of granularity.

See Also:

• Increment
• Iteration (Guide to Agile Practices), Agile Alliance
• We Iterate...So We Are Agile?, by Illya Pavlichenko