Both iterative and incremental models are closely related to Agile, but they are sometimes incorrectly used interchangeably. Perhaps this is because it’s hard to find a precise definition of either approach and also because both of them deal with similar subject matter. In this case, however, the devil is in the details, and while both models address the same issue, they have different meanings. Read on to find out more.
Iterative and incremental models – table of contents:
Iterative and incremental models
Let’s start with the fact that both of these concepts relate to a process aimed at improvement, but they operate on slightly different principles. In the case of an iterative approach, it involves repeating the same activity, ultimately leading to its enhancement or diversification. On the other hand, an incremental approach aims to continually increase the quantity or value of something, with each element being thoroughly refined from the outset.
While at this point we could provide an example of an IT team or any other, the analogy brought up by Mike Cohn seems to be the closest. He compared the iterative process to sculpting. In the initial phase, the sculptor has different stones to choose from and selects the one whose shape most closely resembles what they want to create.
In the next step, the sculptor’s task is to give the stone a general outline, and only in the next steps does a final shape start to emerge. Thus, each step leads to the completion of the process, i.e. the creation of the sculpture, and each is important and necessary. However, none of them will be considered by the sculptor to be complete until the final vision, i.e. the finished sculpture, is created.
Let’s bring this colorful analogy to a more down-to-earth process – think of a project where programmers are building a new website. When working on a website, the programmers are immediately creating a product and putting it in the hands of the users so that they can test it. However, this doesn’t mean that this is a complete and finished product. While users are testing it, the team identifies problems, looks for ways to make it better, and plans the next version. This process of making repeated improvements is called iterating.
The sculptor adopting the incremental model would work in a quite different way. They wouldn’t treat every step as an element to be refined later but would create the final shape of each element from the beginning. What does this mean? Let’s suppose such a sculptor wanted to create a statue of a man. In this case, they wouldn’t give it a general outline or shape but would concentrate immediately on creating perfect details that wouldn’t need to be refined later and would achieve its final appearance right away.
How does this translate into the work of the project team? Each section or subgroup focuses on its task and creates a complete component of the website that has limited functionality but is finished and refined. Only when the work of all the groups is combined does the final product emerge, made up of all these components.
The main differences between iterative and incremental models
The key to choosing the model that works best for you is to understand the differences between these approaches.
- Risk of error
- Project duration
- User involvement
- Project costs
The incremental approach carries a lot of risk, as any potential errors or defects can only be discovered at the end of the process, i.e. when the individual components are combined into the final product. Before that, each part is complete in itself, so it is one big unknown. When it comes to detecting errors and making changes, this is easier to do when taking the iterative approach.
With the iterative approach, you can create a design that is ready for testing more quickly. This stems from the fact that all possible improvements are made in subsequent stages, but this happens in the background and doesn’t interfere with the original version. In contrast, the incremental approach involves developing and enhancing each element separately, which takes more time.
In the case of the iterative approach, users are more involved in the process and can test the product more quickly. That is a value in itself, but it also allows you to gain valuable information about the product’s usability to make possible improvements and developments. With the incremental approach, users must wait longer for the final product, and their participation in the entire process is not so important.
It is impossible to say unequivocally which approach is more expensive. It all depends on how long a project will take and how many revisions it will require. The iterative method becomes costly when many iterations are needed, as each iteration involves another increase in the budget. The incremental approach seems to make it easier to estimate the budget and determine the final cost. This is true, however, assuming that the finished version is bug-free and doesn’t require any fixes.
Iterative and incremental models of development. Which is better?
It’s impossible to answer this question other than “it depends”. The iterative approach is better in the case of large projects, where it is assumed from the start that the first version of the product will not be the final one and that the product itself has a chance to grow. It’s a great solution if you need to get to market quickly. The incremental approach, on the other hand, will be better when you have a clear idea of what the final product will look like, and you know there won’t be any room for improvements or enhancements.
This means that when making your final choice, you need to take into account the goal of your project, as well as its circumstances and requirements. If you expect quick results and want to involve customers in the process, choose the iterative approach. However, if you know exactly what product you want to develop and want to achieve the highest quality right away, the incremental approach will be better.
Apart from specific situations, when the answer to the above-mentioned question is clear, there is still a space in between where it is not at all so obvious. So the question is, can we combine the benefits of both these models and use only the aspects that fit into a particular project?
Both approaches have the same goal, they both have their advantages and disadvantages, and they both carry certain risks. Which one will be better depends on the process you want to conduct. However, is it really necessary to choose one solution? Perhaps the best option will be to combine them both and find a golden mean?
Nothing stands in the way of using both models, as it’s not necessary to stick to one specific framework. It’s better to use them as inspiration and a good starting point. Select relevant elements for your project and create your own customized process.