Iterating and incrementing

Agile approaches like Scrum are often described as iterative but we seem to forget where iteration really benefits us and how to plan for iteration when compared to incrementing.

Iteration is a strategy for discovering a requirement by building software and soliciting feedback. By travelling through this cycle a few times you home in on the true customer need. Where there is a high degree of complexity of uncertainty this feedback driven approach is likely to be more cost effective that attempting to completely analyse the requirement.

By contrast an incremental approach involves building a part of a solution completely followed by the next part.

While iteration expects re-work and assumes the requirement is not known, incrementing can be used when the requirement is well understood and does not pre-suppose (or rule-out) re-work.

In practice we should seek to combine iteration and increments. In previous posts I have described MMFs (minimum marketable features) as a strategy for defining increments. Iteration can be used within each increment to ensure that the customer need is met.

To complicate our mental model a little we can iterate across increments. This provides us with the opportunity to respond to feedback from the market in addition to feedback from more immediately accessible customer representatives.

It is critical to think about iteration when planning a project. While some stories will pass through a single development cycles others may take 2,3 or 4 iterations in order to deliver the value they represent. A simple velocity measure does not provide for the uncertainty and variation that this can represent.

Now for the theory

The Cynefin framework developed by David Snowden described 4 different problem domains; in fact there were 5 and I’ll only consider the first 3 right now.

The domains relate to where we might choose to use iteration.

Simple – sense, categorise, respond
Simple problems are characterised by simple cause effect. When faced with problems in the simple domain we should find out the current best practice for the problem and apply the solution.

Complicated – sense, analyse, respond
Complicated problems are the domain of the expert. With sufficient expertise and thought these problems can be broken down into their simple constituent parts.

Complex – probe, sense, respond
Complex problems are different. These cannot be broken down into simple problems or solved by hard thinking. Rather we must solve these problems through experimentation and feedback.

As we seek to understand our customers needs we should consider where they fit in this classification. We waste our time if we try to analyse complex requirements. By contrast if rely in iteration for simple or complicated problems we are likely to take longer than necessary.

The best teams will learn to recognise where iteration is most valuable and where to apply analysis.