How Can We Know That We Are Really Iterative?

As organizations attempt to embrace an iterative development approach for the first time, I often hear comments such as "We don't have to plan the whole project--we're iterating." Or, "Our architect says we are doing an iterative process, but he (or she) can't tell us where we are going or how we are going to get there!"

One of the greatest self-deceptions I encounter is where development groups equate iteration with the Indiana Jones School of Software Development—"I'm making this up as I go, kid." Nothing could be farther from the truth. Whether you are doing a Rational Unified Process approach or eXtreme Programming (XP), iteration demands that you always know where you are, and where you are going to be tomorrow or next week. An iterative approach is not an excuse to throw caution and control to the wind. On the contrary, an iterative project is highly controlled and every team member is acutely aware of the current status of the project and what the next areas of work will be.

Let’s remember that iterate means you do the same activities over and over, again and again. So if you just iterate you are a lot like a hamster spinning ‘round and ‘round in a wheel—very active but going nowhere. An iterative approach requires incremental progress: everything you do in this iteration builds on what you did in the previous iteration, and so on. And if you are going to incrementally construct a software system you need to plan the increments:  acknowledge the dependencies (Don’t we need walls before the roof goes on?), match the interfaces (OOPS! Hey! Anyone got a gender-mender?), and have a clear vision of where you are going before you get there (WARNING: Be sure to read all instructions before assembling the bicycle).

The Indiana Jones approach to software development is best known by its familiar name: HACKING!  Hacking (at its worst) is a lot like surfing through hyper-space on the web, never knowing where you are going to end up. You start out, but you don’t have much of a vision of the goal. You cycle around and around and end up…somewhere. Lewis Carroll’s Cheshire Cat expressed this mindset very accurately:

Alice asked the Cheshire Cat: 'Would you tell me, please, 
which way I ought to go from here?'

'That depends a good deal on where you want to get to,' said the Cat.

'I don't much care where___' said Alice.

'Then it doesn't matter which way you go,' said the Cat.

'___so long as I get somewhere,' Alice added as an explanation.

'Oh, you're sure to do that,' said the Cat, 'if only you walk long enough.'

                           (Alice's Adventures in Wonderland)

Hacking projects may indeed even have a Project Plan. But a Project Plan by necessity is created early in a project and will cover breadth rather than depth. It is just not feasible to accurately describe in depth the content of an iteration which is perhaps two months or six months away. Part of this confusion about the iterative approach is a failure to recognize that an iteration is really just a sub-project within your "real" project. Everything that is true of your project as a whole, is also true of each iteration. And a primary characteristic of any project is having a definition of knowing when to stop!

For example, on one project I developed a Project Plan which spanned a 9-month development period. This Project Plan contained 16 pages including a schedule and high-level description of the 13 planned iterations. But my Iteration Plan just for iteration #6 contained 28 pages, including the use cases and scenarios for this iteration. And this iteration was only 4 weeks long! I prepared this Iteration Plan while iteration #5 was being coded and tested by the development group. The Project Plan gave me a rough-sketch of what iteration #6 should accomplish, but only when we were actually within iteration #5 did we obtain a much clearer view of the detail and depth of content we needed in iteration #6. And within iteration #6 I prepared the Iteration Plan for iteration #7, and so on. Each iteration plan has a clear and defined set of written goals, risks, feature descriptions, tasks to achieve the goals, and assignments to specific members of the development team. The Iteration Plan has much more detail and depth than the Project Plan, but they have essentially the same structure.

The bottom line is: If you cannot convey to an outsider where your project currently is, where it is going to be every week through the end of the project, and a high-level description of how you will achieve your project goals—then you probably haven’t thought enough about these criteria, and you are most certainly on the Indiana Jones team.