Iterative & Incremental Development: New Definitions

Many authors have elaborated on the importance of iterations and increments, particularly in the last ten years. Unfortunately, only few of them have made serious attempts to explain what the differences between iterations and increments really are. Even worse, methodologies like RUP and SCRUM have muddled the waters by making iterations and increments equivalent to each other, which makes it difficult for project managers and development managers to decide how to handle temporal cycles in their software projects. And communication among agile practitioners doesn’t get any easier when authors of agile methods like XP and DSDM don’t agree on definitions and terminology. The 16-year old definitions of increments and iterations, provided by Alistair Cockburn, are as follows:

  • Incremental development is a staging and scheduling strategy in which various parts of the system are developed at different rates, and integrated as they are completed.
  • Iterative development is a rework scheduling strategy in which time is set aside to revise and improve parts of the system.

While these definitions have been extremely useful for a long time, I now think that they have begun to break down under the environmental changes of the last decade. The definitions, in particular the first one, reflect the old way of looking at the construction of big systems: break them down into manageable parts, schedule them all to be built and then assemble the system from those parts. The Unified Process and agile methods can be blamed for confusing the incremental and iterative strategies, but it seems that there was a good reason behind it: We have learned to build better products by putting them into the hands of our users. Only the people who actually use our products are the ones who are in the best position to tell us what we did wrong. This was the whole idea behind evolutionary and adaptive software development, both of them popular terms in our field until agile development became the norm.

Before the whole evolutionary-adaptive-agile wave iterative development was often seen as a rework cycle within the cycle of big increments. But with the new approach incremental delivery itself, just like iterative development, became just another rework strategy. It appeared that users preferred working with a system that was only half correct and half finished, over having to wait endlessly for a system that was being tuned to perfection. I believe this is the main reason why so many experts simply decided to lump iterative and incremental development together: both of them are now associated with learning and adaptation.

Therefore, I think we need to adjust our views on increments and iterations, or we will never be able to understand which approach is best for our projects, and how popular methodologies and best practices compare with each other. Allow me to explain my first attempt at cleaning up this mess that we got ourselves into.

For development of complex software systems in the 21st century the definition of incremental development might look like this:

  • Incremental development is a staging strategy in which various parts of the system are developed and delivered to the user at different rates, with the intention for the software project to adapt to external feedback.

The goal of an increment is to expose a growing system to the environment it will need to survive in. The feedback drawn from real users, real hardware, real infrastructure and real interfaces, acts as a feedback loop that enables learning and adaptation. A software project continuously needs to seeks the optimum value in a fitness landscape that is defined by a performance system comprised of numerous quality criteria. These criteria are imposed by the environment and are always subject to change.

After rewriting the definition of incremental development the definition of iterative development might look like this:

  • Iterative development is a rework strategy in which various parts of the system are revised and improved at different rates, with the intention for the software project to understand the system it is building.

The goal of having iterations is to learn by doing. The feedback in this case is from a person’s own knowledge and experience, from other members in the team, and from people representing the customer and the intended users. In reworking requirements, the user interface, the data model, the architecture and any other parts of the product, the project learns to deal with itself as a complex system. Note that feedback from users may be involved here too. But they will be users who are part of the project itself, acting as people who might have a better chance at predicting how the product is going to survive once it is released in its real environment.

5 thoughts on “Iterative & Incremental Development: New Definitions”

  1. Nice article. My company recently adopted SCRUM methodology, and I am also reading a book related to SCRUM. But i was still confused to know the difference between iterative and incremental developments in SCRUM. Your article helped me a lot to understand their differences.

  2. Hi Alistair

    The whole web-site cries for a refresh. After some three years of working on it, I pretty much abandoned the site.. well, for a while. Will get back to it at some point

  3. Hi, Jurgen!

    Another thoughtful article from you, congrats, and I like your fresh review of those (as you exactly say) really by now outdated terms. I would be happy to drop or merge them if people didn’t still make classic mistakes with each. As you point out, almost all modern project use both in a dynamic mix, and that’s as it should be.

    That having been said, I’m not sure I would agree with your extension to the definition of Incremental … getting feedback to *change the system that was delivered* looks like straight iterative work as I’m seeing your sentence .

    I don’t know if you’ve seeen
    (short URL ). There I wondered what was the real use or value of incremental versus the real use or value of iterative. I came up with these:

    – Incremental development gives you opportunities to improve your development process, as well as adjust the requirements to the changing world.

    – Iterative development helps you improve your product quality. Yes, it is rework, and yes, you probably need to do some rework to make your product shine.

    See if those do you any good, or you still find a different difference.

    cheers – Alistair

  4. (p.s. Your captchas are too difficult. It took me three tries to get one accepted, and I was guessing each time. I don’t normally have the energy to try three times. Can you get easier ones?)

    (four times)

Leave a Reply

Your email address will not be published. Required fields are marked *