the same phenomenon or not?
ADVISORY ARTICLE
By Henny Portman
The Netherlands
During training classes I often notice that students mix the words iterative and incremental together. After reading this article I hope you understand the relationship between incremental and iterative development. I will start with a comparison of a waterfall and an agile approach by delivering a payment app[1]. In the second part of this article, I position waterfall and agile in an incremental versus iterative matrix and shows what happens in the other two quadrants too. As a last step I elaborate on the minimum viable product (MVP) and the minimum marketable product (MMP) and shows where these fit in the different approaches and a story map[2].
The development of a payment app
Waterfall approach
If this app is developed according to a traditional waterfall approach, the following steps could be observed (see figure 1).
It all started with a project sponsor from the marketing department who was able to free up the necessary funds for this app. It was his assumption that the app will improve the retention figures and the inflow of new clients will grow. He visualized three high level function groups.
At a certain moment this project gets the approval to commence. A project manager is assigned, and a project team built. After many discussions and requirement gathering workshops there was an agreement to deliver a payment app with 250 features. All these features are recorded in an extensive and very detailed requirements document and signed by the project sponsor and customer representative (and some others).
In the next step the project team translates the requirements into a design for the app. The architect checks the design towards the design principles. He checks if all needed data attributes are available in the backend system too.
Figure 1: waterfall delivery of an app
We are now two months underway and the customer hasn’t seen anything working yet, only some progress reports. Probably some sort of ‘melon’ reporting[3] so they have no clue if the project is on track or not. It takes six months to develop the app and when that’s done the customer representative is asked to deliver some people who can help with a user acceptance test. During the test it becomes clear that several features are not working. The project team doesn’t understand why. It’s exactly what was described in the requirements document. Lots of discussions, rework, delays and customers who aren’t happy with the results. If we look at the final result, we can also notice that many of the developed requirements are not or rarely used[4] by the customer. It could even be worse. Suppose the development of the app took 1.5 year and another bank delivers a payment app when you are halfway. What would you do at that moment? Would you still have a viable business case to continue and finish your own app?
If you look at figure 1 it becomes clear that in case of a waterfall approach the scope and underlying quality criteria are fixed with a single delivery. All steps are performed once for the entire project and management control is focusing on cost and time. Value delivery to the customer only takes place after the deployment of the complete app.
Agile approach
If we develop the app in an agile way, we see the following pattern. The development team stated that they are able to deliver the first two features prioritized by the product owner (balance information and submit feedback) in the first iteration. The project team delivers every three weeks (sprint or timebox) an increment of the product. After the first deliveries or increments we see a customer who has confidence that the project will deliver. He/she already has a working app. He understands that not all features are there yet but what he has is working. Looking at the latest release and the provided features, he mentions a completely new feature. One that nobody had on his mind at the start of the project but a feature that can make his life as a customer much more productive. After every increment the customer feedback results in new features (not on the list) or adjustments of potential features and the product becomes more and more mature. Every time when the customer receives a new version you can see a happier customer.
More…
To read entire article, click here
How to cite this article: Portman, H. (2020). Are incremental and iterative the same phenomenon or not? PM World Journal, Vol. IX, Issue IV, April. Available online at https://pmworldlibrary.net/wp-content/uploads/2020/03/pmwj92-Apr2020-Portman-are-incremental-and-iterative-the-same.pdf
About the Author
Henny Portman
The Netherlands
Henny Portman, a partner of HWP Consulting, has 40 years of experience in the project management domain. He was the thought leader within NN Group of the PMO domain and responsible for the introduction and application of the PMO methodologies (portfolio, programme and project management) across Europe and Asia. He trains, coaches and directs (senior) programme, project and portfolio managers and project sponsors and built several professional (PM(O) communities. He is an accredited P3O, PRINCE2, MSP, MoP, PRINCE2 Agile, AgilePM, AgilePgM and AgileSHIFT trainer and a SPC4 SAFe consultant and trainer too. He is a P3M3 trainer and assessor and PMO Value Ring Certified Consultant. In addition, Henny is international speaker and author of many articles and books in the PM(O) field and blogger (hennyportman.wordpress.com). Henny can be contacted at henny.portman@hwpconsulting.nl .
[1] See YouTube for my mini webinar on this topic (Waterfall vs agile delivery): https://youtu.be/Ky4BUPEFq7Y
[2] See YouTube for my mini webinar on this topic (Incremental vs iterative): https://youtu.be/cWADcFyMX4w
[3] ‘Melon’ or better ‘watermelon’ reporting is a progress report with green indicator(s). In reality the green indicator is red inside.
[4] Standish Group research shows that 60% of the developed requirements are not or rarely used (https://www.standishgroup.com).
