Incremental and Iterative Development

Peoplestill get wrapped around the axle trying to understand the difference between incremental and iterative development. The Unified Process authors in the 1990s didn’t help by indiscriminately calling everything iterative development. The two are different and must be managed differently. Successful teams do both at the same time, usually without thinking about it. Then someone starts thinking about it and does one without the other. Bad news follows.

Current agile practice doesn’t seem to make it important that the users get to see what’s being built and have a chance to change it. Iteration lengths are so short that the programmers barely have time to program up the basics before the end of the iteration, so there’s no time for the users to show up and say, “No, that’s not actually what I want.”

I heard one Extreme Programming (XP) customer ask others in a multi-project exchange:

Is it just me, or do you also have to get it right the first time? On our project, if I request a change, they tell me that story will go to the back of the queue and the project timeline will be delayed. As a result, I have to get it right the first time. Isn’t this against the very spirit of agile development?

This person is right on all counts—it happens, it runs against the spirit of ag­ile development, and it is bad business.

This problem is the opposite of what we wrestled with back in the 1990s. Back then, we struggled to get people to do in­cremental development. Getting people to break work into small-ish pieces and build a piece at a time was all we aspired to. Many people understood that it was good policy to show the results to users several times, and so, oddly enough, we sometimes saw iterative but not incre­mental development!

If you create smaller pieces but don’t show them to real users and incorporate their responses , then you revert back to the project failures of the 1980s, when users complained that what got delivered to them didn’t satisfy their needs.

How Did We Get into this Mess?
Back in 1991, my assignment with the IBM Consulting Group was to inves­tigate development methods for object-technology projects. In my research, I ran into two terms— incremental devel­opment and iterative development.

I read articles and interviewed people to learn what they meant by these two phrases and learned that they refer to distinct staging and scheduling strate­gies. They are choices made by the proj­ect team on how to slice, integrate, and revise the work. We learned that:

Incremental development is a staging and scheduling strategy in which the various parts of the system are developed at different times or rates and integrated as they are completed. The alternative is to develop the entire system with a big bang integration at the end.

Iterative development is a rework scheduling strategy in which time is set aside to revise and improve parts of the system. The alterna­tive development is to get it right the first time (or at least declare that it is right!).

Please notice that these strategies don’t imply, require, or preclude each other. It is possible to work incrementally without iterating (the product manager’s complaint at the start of this article), to iterate without incrementing, or to do both (the recommended strategy).

In the next section, we’ll look at the definitions more closely along with how to manage the differences, but first: How did we get into the situation where the two became so confused?

Back in the 1990s, the authors of the