Three Hours to Three Years

Everybody is talking about iterative development. It is state-of-the-art as well as fashionable. It is a rare software developer who admits that he is not working iteratively. And if somebody has to admit to non-iterative development, it is possibly because he is forced to work to a waterfall model, where phases follow each other and a workable software system appears only at the end of development.


Are phase-models old fashioned since we have iterative software development? What exactly are iterations? How often should we iterate and how long should it be between iterations? This is a critical perspective on iterations, showing examples from various points of view, and I shall try and demystify the buzzword "iterative".

Why is there such a discrepancy about the duration of iterations?

Surely there are software tasks that can be done in a couple of hours. Maybe the 10-person company needs some statistics about their work. A solution based on a spreadsheet will take a software developer only a few hours.

For complex systems including hardware, software and organizational aspects it might take years before they can be used productively in the business. Think of a European air traffic control system, a new car or an international message switching system. You will surely remark now that although such systems may only achieve their full potential after years we will be able to deliver useful subsystems in a time span that is much shorter than "many years".

A maximum of 2 years ....

Back in 1984 Steve McMenamin and John Palmer [MP84] postulated: "Every software project must show useable, running software in less than 18 — 24 months. Otherwise the project will be killed by reasons that are beyond even a perfect project manager."

A maximum of 3 hours ...

Extreme Programming contrasts the 18 - 24 months with an extremely different time budget. An extreme programmer should have tested and working software several times a day. Kent Beck demands that development, integration and test take place within hours up to a maximum of a day [Bec00] (XP-Fans are really serious about this time frame. A panel discussion at one of the XP conferences was entitled "Daily Build is for the Wimps".) Within this time frame a "user story" (i.e. the explicit wish of a customer for some functionality) is analyzed, the acceptance tests are written, then the code is written, immediately integrated and tested. Thus we have a running version. Three decades ago this approach was unthinkable since it took forever to punch the cards and get decent turn around times in closed shops. Technically those cycles are no problem today: the development and test environments allow for these short cycles.

For most of you these two periods will be extreme endpoints. Most of my customers practice cycles that are between 3 hours and 2 years. 3 months, 6 months or 12 months are industrial average. Many of the new agile methods recommend using iteration lengths in the middle between the extremes. For example, the Rational Unified Process suggests the following durations for iterations according to the size of the software and the number of developers [Kru00]:

Lines of Code Number of Developers Duration of iteration
5,000 4 2 weeks
20,000 10 4 weeks
100,000 40 12 weeks
1,000,000 150 32 weeks

Let's try to get a better handle to iterations.

Iterations for software and product life cycles

Let's start the discussion with a provocative observation: Historically, the term iteration was created for periods during coding. Therefore it only makes sense during the construction phase of software projects. Today the term iteration is often uncritically extended to the overall software development, often even beyond that to the development of whole hardware/software-products.

Before you jump in with a "yes, but . . " Or "you've got it totally wrong" let me add some more observations. Almost all publications mentioning iterative development suggest that the result of an iteration is a running piece of software. Lets call this iteration an "iteration in the narrow sense". They are often used to clearly depart from the waterfall model where at least the first half of the project was about paper production (analysis specs, design specs, quality plans, . . .) and only then you could write code. In large project neither customer nor project managers could be sure that the system is growing and will be ready in time before it was too late to react from a management viewpoint.

Iterations are not sufficient, phases are necessary

Nobody, not even the creators of eXtreme Programming, state that a large system should only be developed using iterations in the narrow sense. Even XP acknowledges definition of the goal and planning. The nomenclature for phases has changed compared to the waterfall. Now we talk about inception, elaboration, construction and transition. The names are not important in our discussion of iterations. But note: with the introduction of phases the term iteration gets a different meaning. Now we cannot only use iterations in the construction phase, but also in the other phases. But you have to acknowledge that the result of an iteration is not necessarily running, deployable software.

During the inception you can of course also write some code, but the major result are the goals for the project, a vision and a rough plan how to achieve the goal. During elaboration you should have some code, e.g. a prototype for your architecture, but the major results are well-understood requirements, a proven architecture, a plan for the rest of the project and risk lists.

Iterations in early phases are mainly used when the overall goals cannot be reached within weeks or months. In order to minimize risks you define intermediate goals that can be reached within weeks or months. In order to cope with these different kinds of iterations we left the definition of an iteration deliberately a bit vague in [OHJ01]. We defined an iteration as "similar periods of time within a development process". What makes them similar? Seven features came to our minds:

  • There is a time budget for the iteration
  • The iteration gets other budgets than time (e.g. personnel, money)
  • You plan an iteration
  • You define results that you want to achieve in this iteration
  • You execute the iteration
  • You control the iteration
  • You check the results of the iteration

Lets do a little Gedankenexperiment. Replace the word "iteration" in the seven characteristics above with the words "project", "subproject", "release", "phase", "build" or "user story" (for the XP freaks). And read the sentences again. They still work! So what's the difference between an iteration and a project, a subproject or a release?

Differences are in the time budget (from n hours to n years), in the kind and depths of planning, in the types of results, in the way you execute them, control them or check the results. Also the human resources will differ. While you can develop a user story with a pair of programmers you might need 15 persons to develop a release. The differences are larger than the commonalities. This is why I mentioned the uncritical use of the word iteration, although release after release is done in the same manner, as is a sequence of subprojects. According to the definition above releases and subprojects are also iterations (in the wider sense).

Let's go one step beyond. In many systems software plays an important role. But what the customer wants is often not software, but a product or a system (that might include software).

The table below contrasts various aspects for different development scopes:

System/product Development Software Development Iteration in the Narrow Sense
Duration: 1 to n years 3 — 12 months Hours to weeks
Often visions instead of clear goals Relatively clear goals Very precise goals
Budget frame (up to . . .) Fixed budget Often no separate budget
Time frame (in about 3 years) Fixed deadline (31st March) Exact detailed target time (until next Wednesday)
No exact plans, more of a strategy, that is operationalized as we go. Detailed plans The shorter the less explicit planning
Can be done iteratively, but the iterations do not necessarily deliver software-increments, but also other results that allow risk management and planning. Split into short iterations, that have software as result, but also other artifacts Each iteration produces executable software.

     Table 1: System-/Product development and Software development

Based on these considerations it becomes clear why talking about iterations is sometimes difficult. A short product development or some more complex software project can both take one year. A long iteration and a short software project can both last for 2 — 4 months. Therefore you cannot generalize the length of iterations. But one trend is clearly visible: the cycles are generally getting shorter. My recommendation: Avoid the term iteration the large and replace it with terms like release or subproject. And these repeatable time frames may be larger than iterations in the narrow sense, for which there is a trend to not go beyond 6 months. In many domains even shorter cycles of 3 — 4 months are doable. They help to give early feedback to managers and customers and let everybody sleep more relaxed.

In my opinion political tolerance has dropped to a maximum of 6 months today while a cycle lengths of 12 — 18 months was okay back in 1984. Exceptions are projects with hardware/software co-development because processor or chip development often needs more time than software iterations. Even in such projects you often find 3 — 4 software iterations before the hardware is ready.

What should you do?

If you don't do it already you should definitely plan to develop software iteratively. But don't stretch the term iteration. 3-hour iterations are okay for programmers, for most of the other project members longer iterations are useful. For many software projects today iterations of 4 to 12 weeks are ideal. This time frame motivates the development team and provides enough milestones for managers and customers to create feedback. For most end users release cycles may be longer. Six months (i.e. 2 releases per year) is an acceptable compromise for many domains. Those domains that have longer periods before deployment become less and less every year.

A provocative thought at the end

Independently of your domain and your current cycle time: check your cycle length and seriously consider to cut it in half or into one third. (Don't do it, when you are already down to one week.) Try to replace cycles of 12 month with cycles of 4 or 6 month. Or try to replace cycles of 3 month with cycles of 4 — 6 weeks. The technology enables it and the advantage of quick feedback outweighs the costs of additional planning, and controlling. Even when you are fine with your current cycle length you can have better results by following my suggestion. Take on this challenge and try it. And send me feedback.

References:

[Bec00] Kent Beck: Extreme Progamming Explained – Embrace Change, Addison Wesley, 2002

[Kru00] Philippe Kruchten: The Rational Unified Process (2nd Edition), Addison Wesley, 2000

[MP84] Steve McMenamin/John Palmer: Essential Systems Analysis, Yourdon Press 1984, deutsch: Strukturierte Systemanalyse, Hanser 1988

[OHJ01] B. Oestereich, P. Hruschka, N. Josuttis, H. Kocher, H. Krasemann, M. Reinhold: Erfolgreich mit Objektorientierung, Vorgehensmodelle und Managementpraktiken fur die objektorientierte Softwareentwicklung, 2. Auflage, Oldenbourg, 2001

Peter Hruschka, Aachen