The terms "iterative" and "incremental" are used so frequently and naturally in the context of agile that their meaning is no longer challenged. Sometimes the two terms have even become synonymous. Agile development is often referred to as an iterative-incremental process. This term already suggests that they are actually two different, complementary concepts. In the following, we will briefly discuss what these differences are and, of course, what practical implications this distinction has. For behind this there is far more than splitting hairs.
Phase-driven development
In the classic, phase-driven development (waterfall), the individual activities such as planning, design, implementation and testing are combined in a sequential order into the project period, from the planning phase to the final result. All necessary steps are carried out exactly once. The term waterfall has its origin exactly in the fact that these phases are completed sequentially one after the other before a subsequent phase is started and one does not move backwards in the process.
For phase-driven development, a plan for the entire project is created at the very beginning with the aim to forecast the end of the project and to detect deviations from the plan in an early stage. An appropriate project controlling during the project should ensure success. In the event of deviations from the plan, appropriate actions (e.g. increasing capacities) are taken to try to get back on track.
Iterative development
If you work iteratively, you will also first create a rough overall plan of all necessary work steps. But in contrast to the classical "waterfall", this overall plan is then divided into small steps, the iterations, and only the next iteration is planned in detail and then implemented. A distinction is often made here between requirement and solution. The requirements of the project represent the rough overall plan, the concrete implementation (solution) of these requirements is worked out iteratively.
A team working iteratively thus has the possibility to incorporate the knowledge gained from a completed iteration into the planning of the next iteration. However, the goal remains to adhere to the overall plan. Still, the overall plan is relatively rigid, for example, with regard to the scope of features. The flexibility results primarily from the details how to implement the features in detail. The more high-level the requirements are, the more flexibility is gained. Controlling for iterative procedures is usually done by checking the progress of the project.
Incremental development
Incremental development is often combined with an iterative approach. This is also referred to as iterative-incremental development. The key difference to the iterative approach is that a team that proceeds iteratively-incrementally replaces the overall plan with a goal, a vision. The scope and the path to the goal, however, are completely open. A plan in the classical sense no longer exists. Rather, after each step it is reflected what has been achieved so far and with which next step the team feels it is best to get closer to the goal. This means that the result at the end of the project can look completely different than originally expected if this result better fulfils the vision.
Thus, while the iterative approach might change the plan if new knowledge is gained, the iterative-incremental approach does not create such a plan at all. The risk of questioning the plan too late in the project does not exist, and a decision is always made on the basis of the latest insights as to how the benefits of the work invested can be optimized. However, this always requires a reflection at the end of each iteration. In a Scrum context the Sprint Review and the Sprint Retrospective would be such reflection points.
Mastering Iterative-Incremental
A team using iterative-incremental work gives up the imaginary security of a fixed plan. But it gains infinite freedom and flexibility: new ideas can simply be tried out - at the latest in the next reflection, you can discuss the benefits they bring. Improved knowledge and new creative approaches to solutions gain more room for optimizing the value compared to how many work we are able to finish. Value is more important than output. This creates a completely different, motivating working environment in which the customer and developer work together to find the best, most efficient and fastest way to realize the vision. The goal is not to work faster, but to identify the functionalities that bring the greatest possible added value to the benefit.
It is important to understand that an open-ended collaboration according to an iterative-incremental pattern requires all participants to think in a completely new way. All those involved: this also includes the client. While the team must be prepared to "just try it out" (and to the fact that this may even result in a "detour to increase knowledge"), clients must be prepared to accompany the team on its way and to keep up the dialogue. The " So go ahead, see you in three weeks/months/years" that is so popular with many clients is no longer possible.
Conclusion
If a team understands the agile philosophy correctly, they will not be satisfied with the iterative approach. This should only be seen as a preliminary stage to the - from my point of view - optimum: the iterative-incremental working method. This means the final rejection of the idea that in highly complex areas, such as software development, a project can actually be foreseen and planned from start to finish. It also means getting involved in completely new, because completely open-ended, work processes, which is a challenge for both client and contractor. On the other hand, a team gains the freedom to find its own way to convincing results without being fixated on working according to plan. It's a pity that many organizations are already settled for an iterative approach and that they believe, mistakenly, that they are already exploiting the full potential of agility or are shying away from the challenges of an iterative-incremental approach.
The Professional Agile Leadership Training (https://www.agilemax.de/trainings/pale), shows how managers can accompany and support the organizational changes towards an iterative-incremental approach.