The waterfall is not dead
I cannot believe that in 2019 a lot of companies are still using the waterfall model. Although I knew that some rare cases of projects need a waterfall model, the cases I have noticed were not one of them. Those companies did not change their traditional implementation methodology to deliver a quicker value to their customers.
Therefore, This article will discuss two important models that can help those who are still using the waterfall to deliver a quicker value to the customers without the need to be an agile company. But, it is the first step toward the change to agile.
Iterative vs incremental
I got a lot of questions about both models. what is the difference? why use iterative not the incremental?
Short answer, they are the same in results and purpose of splitting the software into smaller packages that deliver early business value. But, they are different in the implementation approach.
Let us imagine that we will deliver a hospital information system (HIS). This system contains a set of modules, for example, InPatient, OutPatient, Pharmacy, Labs, Radiology, Patient records management …etc. Please look at the image below.

Imagine that we have 12 months to deliver this system. So, how incremental, iterative, or even the waterfall will be different to deliver this system, what are the pros and cons of each mentioned SDLC model in practice.
Let us consider that we have a good understanding of the system requirements, let us see how the different models will shape the implementation.
The Waterfall model
Using the waterfall model, we will go through the SDLC phases without going back. It starts with requirements, then design, then implementation and coding, then testing, and finally, we deliver the system to the end user in order to start using it.
The below images visualize the waterfall model implementation.




Now, we just passed 12 months of implementation. The end user can see the system at the end of the 12 months. At that moment, the users discover a lot of missing requirements and most probably the project will be marked as a failure or maybe became unfit for the business current needs or not matching the current hospital strategy.
So, how can we make that better? Let us see how iterative or incremental models will help us do that.
The Incremental model
The incremental model needs some planning upfront and requirements prioritization to find out what are the dependencies of the system components with each other, which feature or module should we start with?
In the first increment, we decided that records management is the core for patient index and to collect the mandatory patient data that will be used across the other modules.

In the first or the second month of the time plan, we delivered one module for our customer. So, they can start using it. Moreover, a feedback loop is initiated here to get the feedback of the required changes into the next increment.
The idea is to reach the minimum viable product (MVP). This MVP does not present all requirements, but it presents part of the requirements that can be developed to deliver a quicker value to the customers. The customer they can use this MVP while the system development is progressing.

In the second increment, we add another module to the delivery. This can be a module, a feature, a new function, or capability. In the last increment, the full system is ready.

Thus, we achieved better feedback from the end users, the requirements will evolve during the implementation and the requirements are not frozen anymore. The end users can change the requirements during the feedback loop. New requirements can be added to the new increment or even old requirements can be neglected or deprioritized. Now, the project failure risk is reduced significantly.
The incremental model cannot fit all business needs. It has some limitations as well. Imagine you have a different system that it is a process based, for example, in banking, we can have a new customer creation process. This process has various steps, for example, create the customer record, the customer due diligence, open the bank account, …etc.
In this example, if make the customer record as an increment. The end users cannot turn this increment into operation, because it needs the other steps to make that record a real customer. Without the other steps, we can have a fake or untrusted customer data without a real identity.
The Iterative Model
How to apply the iterative model? Iterative model mainly takes horizontal services or features that are related or unrelated to each other to deliver value from the whole system iteratively.
Let us see the HIS first iteration below.

So, we took a part of each module and implement them together to deliver 20% of our system. Imagine that, our customer has some challenges with a specific type of patients for a specific disease. That’s the hospital priority to have that first. So, our plan should reflect what the customer sees as a priority.
Through new iterations, we add another completion percentage to the system like below.


Now, you can link how the iterative model can help with the banking process example, we can apply the same with a specific type of the customers, for example, saving accounts or credit card accounts.
The Iterative-Incremental combined
Yes, you can combine both actually. And this is the agility start. You can start iterative and then at each iteration you can focus on a feature to be delivered, then the next iteration to focus on horizontal service across all layers.


Yes, some features can be eliminated while we are developing the system, others can be added on. Until the last iterative increment and we will have the system ready.


I hope you now understand the difference between the different SDLC models mentioned here. Kill the waterfall model unless it is mandatory to deliver the full system altogether and it cannot operate iteratively.
In order to make your customer happy and satisfied, use the iterative and the incremental models correctly, prioritize the requirements with the customers, and make sure that you deliver a product that can work and add business value.


Help to do more!
The content you read is available for free. If you’ve liked any of the articles at this site, please take a second to help us write more and more articles based on real experiences and maintain them for you and others. Your support will make it possible for us.
$10.00

how is the combined ( incremental+iterative ) model differs from agile ?….can we say RUP is a combined model ( incremental+iterative ) ?
Yes, it will be very similar if you applied agile princible 🙂
Theoretically, this sounds reasonable but practically I don’t think that this is usually the case. Users won’t always be satisfied with scooters bikes, they want the cars and will sometimes complain that they didn’t get it quickly.
I like the clarification of each of the methodology but disagree on the generalization and putting assumptions to say that this is better than that or this.
Yes, I agree that users need the car mainly which, what are they aim for. But, they must need that car for a reason and they have a lot of required functionalities, not just a simple car model. They need advanced acceleration, safety, air conditions, connected car, storage space, …etc.
They may not like the scooter as the first MVP while if we give them something that can satisfy part of their requirements to eliminate the pain they have daily. They need to transfer some goods from different places, the bicycle can solve the problem partially, then it will be evolved by time to have the fancy car they needed.
Waterfall should be dead 😉