Are incremental and iterative the same phenomenon or not? (Part I)

webinar During training classes I often notice that students mix these words 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. At the end you will find the corresponding mini webinar. In the second part of this article, I position waterfall and agile in an incremental versus iterative cross or matrix and shows what happens in the other two quadrants too (will be part of a next blog post).

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[1] 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[2] 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, iteration 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.

Figure 2: Agile delivery of an app

If we look at figure 2, we see a steady flow of delivery within a fixed duration and using permanent agile teams (fixed costs). The scope and underlying quality criteria are flexible (dynamic) with frequent small deliveries (increments). All steps are performed repeatedly (iterative) to deliver a feature or user story until the required quality is reached. Management control is focusing on customer value delivery. Value delivery to the customer takes place after every deployment of an increment of the app.

Waterfall versus agile delivery results

If we take a closer look at the two products from both the waterfall as well as the agile approach, we see a product with 250 features and a not so happy customer and one with only 150 features and a very happy customer (see figure 3).

Figure 3: Waterfall versus agile delivery results

And if we even look in more details to the product delivered by the agile approach, we only see 100 features from the original list and 50 are new or adjusted features. This is in line with some important principles of the agile manifesto[3]:Simplicity – the art of maximizing the amount of work not done – is essential (only 150 features instead of 250 features) and Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage (50 new or adjusted features were delivered). And as a result, a very happy customer (Our highest priority is to satisfy the customer through early and continuous delivery of valuable software)!

Mini webinar Waterfall versus agile delivery