Agile software development methods are often described as being forms of something called iterative and incremental development (or, IID). But, what does that mean? I went looking for an answer recently, and was surprised to find a single, simple definition elusive.
Wikipedia defines IID this way: (from Wikipedia: Iterative and incremental development, accessed on 2007.07.25 at 3:00PM PDT)
Iterative and Incremental development is a software development process developed in response to the weaknesses of the more traditional waterfall model.
While true, that definition hardly describes what it means to practice IID.
Craig Larman, in his book Agile and Iterative Development – A Manager’s Guide, defines “iterative development” as follows:
Iterative development is an approach to building software (or anything) in which the overall lifecycle is composed of several iterations in sequence. Each iteration is a self-contained mini-project composed of activities such as requirements analysis, design, programming, and test. The goal for the end of an iteration is an iteration release, a stable, integrated and tested partially complete system.
Now we’re getting somewhere. So, the “iterative” in IID means that work is broken into sequential “iterations” that are themselves composed of enough analysis, design, implementation and testing to produce a “partially complete system” that is “stable, integrated and tested.”
Larman goes on to define “incremental development” as follows:
Although an iteration can in theory be only for clean-up or performance tuning, usually the partial system grows incrementally with new features, iteration by iteration; in other words, incremental development.
So, the “incremental” in IID means that one or more new features are added to the system each iteration. Let’s put it all together to come up with a single, short definition of IID:
Iterative and incremental development (IID) is a process that grows a system feature by feature during self-contained cycles of analysis, design, development and testing that end in the production of a stable, fully integrated and tested, partially complete system that incorporates all of the features of all previous iterations.
So, what should you expect to see when someone describes a process (agile or otherwise) as iterative and incremental? Well, first, you should expect to see the team working in iterations. Second, each iterations should be growing the software feature by feature. And, finally, each iteration should end in the production of a stable piece of software that real users can use. If you don’t see these things, the process is not IID.
Update: Note that my definition above does not preclude non-agile processes. For example, a team could be doing IID by stringing together multiple miniature waterfall projects. While agile methods tend to use IID, not all IID processes are inherently agile.