Iterative Development

As a profession, we've learned a lot in trying to understand why software development projects succeed or fail. By far, the most important concept to come out of the last 20 years is iterative development. Aside from the obvious prescription that you can't develop great systems with mediocre people, the most important methodological consideration is how you go about building the software. What I have observed time and time again is that those teams that practice iterative development succeed more often, whereas those that employ other methods have a greater tendency to fail. Of the best practices advocated by Rational Software, I find iterative development to be the most compelling.

Why is this?

The iterative development approach breaks away from the overly rigid waterfall approach that had come to dominate large projects in the eighties. It is an approach that is grounded in risk mitigation, incremental construction, and progress measured by actual working code as opposed to documents. If you need more background on the details of iterative development, see Royce^[1] or Kroll and Kruchten.^[2]

^[1] Royce, Walker, Software Project Management: A Unified Framework (Reading, Massachusetts: Addison-Wesley, 1998).

^[2] Kroll, Per and Philippe Kruchten, The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP (Boston, Massachusetts: Addison-Wesley, 2003).

In this chapter, I describe some of the technical reasons why iterative development has proven superior time and again. But more important, I discuss the business reasons why you should use it. This should help bridge the gap between the software development manager and his manager, in the following sense. Iterative development is something that is new and unique to software development. Many general managers feel more comfortable with the waterfall approach, which is closer to classical project management as they know it. So this chapter can be used in two different ways:

• A software development manager can have his manager read it, so that the two of them can have a common understanding of how the project will be managed.

• The general manager can have his software development manager read it if the software development manager is not going to employ iterative development. The question, of course, iswhy not?

In both cases, the chapter can be used as a springboard for discussion as to how the project will be managed, monitored, and reported. It is a discussion that is well worth having before the project is launched, because it will help establish the rules of engagement between the software development manager and his manager. Along with the budget and team-selection discussions, this one is mandatory.