Monday, February 21, 2005

Iterations - more than just risk management

Classic software engineering tells us that iterations and incremental delivery are all about risk management. With each iteration of working code, risk is reduced for the whole release. This is a key theme in Barry Boehm and Richard Turner’s Balancing Agility and Discipline. It’s oft repeated by the establishment and by the SEI. So when you are selecting a feature mix for an iteration, you should be selecting the riskiest things first. That would be good risk management and good use of iterations. A fail early strategy!

I’d like to suggest that there are other reasons why we do iterative development. Reasons which are aligned with the Declaration of Interdependence and with Lean and agile concepts of value flow. We iterate to keep batch sizes small. Small batch transfers to system or user acceptance test, keep flow smooth through test and keep WIP inventory in test departments manageable. Small batch sizes facilitate short lead times. Short lead times mean knowledge is created quickly with minimum atrophy from concept to realization. This in turn implies that quality is higher. All of this applies regardless of how risky the individual features in an iteration mix may have been.

Naturally, it’s academically easy to argue that all of that smooth flow is simply a risk management technique. Reducing everything to risk management is academically convenient as an abstraction. However, I feel it is a model which has outlived it’s usefulness. I’m not saying that risk management as a practice is outmoded. It’s not! Risk management - the practice of anticipating special cause events and mitigating them or forming contingency plans to recover from them if they occur is still good practice. However, we can widen our view of why iterations are useful. Iterations facilitate the smooth flow of value and consequently an improved quality assurance.