Friday, September 07, 2012

The Meaning of Iteration

There is a curious ambiguity about the word "iteration". Sometimes it means doing exactly the same thing, over and over again; sometimes it means doing something slightly different each time.

When a process is drawn as a loop, we need to understand what exactly this means. Which aspects of the process are the same for each execution of the process, and which aspects are different? What is the nature of the feedback, allowing each iteration to improve on previous iterations, and what is the scope for learning and development?

For example, a business process architecture may include a product development cycle. We usually understand this to mean not that the products themselves are recycled, but that there is some accumulation of knowledge and experience (trial and error, learning by doing) that allows each product and each product-related activity to learn from and improve upon previous iterations.

Therefore a process model that is drawn as a loop or cycle cannot be interpreted in the same way as a process model that is drawn as a simple production line or value chain, because there is something else important going on. This is one of the reasons I distinguish the Cybernetic View (which specifically looks at feedback and its effects) from the Activity View (which looks at the work itself). The Cybernetic View allows the architect to pay attention to the effectiveness and efficiency of the feedback, which is not the same thing as the effectiveness and efficiency of the underlying activities but is at a different logical level.

One process that is attracting a lot of interest at the moment is the commissioning process. Commissioning is an important component of a healthcare system, and I also heard Jennifer Saunders recently talking about commissioning at the BBC. I wanted to see how people were depicting the commissioning process, so I did an internet search for images associated with the term "commissioning". The top six diagrams (ignoring one diagram that wasn't really about commissioning but about paying commission) all showed commissioning as some kind of cycle.

Bristol Compact Commissioning Cycle Diagram Diagram: Showing Collaborative Commissioning Cycle graphical representation of questions commissioning cycle

This selection of diagrams reflects a common agreement that commissioning can be thought of as a cycle. However, although the wide variety of diagram styles might be regarded as merely a fashion statement, it could be a sign of a more fundamental methodological issue. It is not clear that all these sources share the same understanding of what it means for commissioning to be regarded as a cycle. What do these diagrams tell us about how the commissioning process develops and evolves and hopefully improves over time? Are there different categories of improvement, with different cycle times?

There is also the question of responsibility. Are the same people responsible for both executing and improving the commissioning process, or does improvement call for a different kind of distributed intelligence?

So there are lots of important and interesting questions here, which a traditional process model doesn't help much with.


Alex McLachlan said...

Hi Richard

My preference is to use the term "incremental change" rather than iterative [change], where each iteration has a defined and understood business value (insofaras this is believed by the stakeholders).

Incremental change is one of the key tenets of Agile, but can be applied to strategic change as well.


Richard Veryard said...

Hi Alex

I don't mind whether you call it incremental or iterative. What I'm more interested in is the nature of the cycle.

One idea of a learning loop is that we can make mistakes and learn from them. So a failed experiment has value (and you would presumably be be happy to call it an increment) if and only if we can learn something useful from it.

More generally, can the tenets of Agile be applied to a complex and demanding business process such as Commissioning? Or does Agile really only work as a software development process?

Alex McLachlan said...

Commissioning seems to me to be a "big-bang" change, so I would question whether an incremental/iterative/step-wise approach could be used. But I'm not very close to this as a change programme, only what I pick up from the press.

Agile certainly does work at the strategic business change level, rather than just at the software level. You have to be careful what you apply - value prioritisation by the business and minimum viable product are useful; 2 week sprints are better at the software level. There is more on our website.

Richard Veryard said...

The NHS reforms may be a big-bang change, but commissioning itself (as described in each of these six pictures) is an ongoing process.

Among other things, the NHS reforms will permanently (at least until the next reforms) transfer responsibility for the commissioning process onto a new set of organizations known as CCGs.

The commissioning process is something like a planning cycle. Hopefully the plans (and the planning process) will improve incrementally over time, without the need for further "big bang" reforms. But I don't know whether it makes sense to refer to these increments as "sprints".

Ivo said...


When looking at iterations, there is some difference of scope and intent between "when a process is drawn as a loop" and "when there is a loop in a process".

When there is a loop in a process, that usually means there is a desired or unfortunate discrepancy between work- and information-dependencies. If the process from work (control-) flow perspective is A->B->C->D, meaning the work of D is dependent on that C, which - of that of B, and B of A, and information-wise it is the same with the exception of B which is dependent on both A and D, then there will be a loop from D to B, and then B, C and D will be repeated. In this case, from systemic perspective, this loop is goal-seeking, and the token (using the process modelling jargon) will move from D to E, when the gap is closed. In such cases either the loop is placed to improve the quality of the process, or one of the ways of improving the process would be to eliminate the loop.

"When a process is drawn as a loop, we need to understand what exactly this means." Well, in that case the observer/designer of that system has chosen to focus on only one loop. Then it's interesting what's the intention. In most of the cases it is to communicate certain message in a simple form or just to pay attention on some dependencies believing that those are of higher importance in some context.


Richard Veryard said...

Thinking a bit more on the difference between iteration and increment, especially following @RiczWest's tweet "#Increment ... seems more PC these days".

Perhaps the key difference is that the word "increment" assumes that you are always adding something, whereas "iteration" could mean oscillation or going around in circles. So the word "iteration" is more neutral.

Obviously if you are designing a feedback loop, you might hope that the feedback would continually improve matters, but there are many situations in real organizations where feedback doesn't produce the desired result.