Are incremental and iterative the same phenomenon or not? (part 2)

In the first part of this article (see previous post) I compared a waterfall and an agile approach when creating a payment app. In this second part of the 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. At the end you will find the corresponding mini webinar.

As stated, I noticed that students often mix the words iterative and incremental together. In figure 4 you can find four quadrants as a result of a horizontal line presenting incremental or not and a crossing vertical line representing iterative or not[1].

In the left lower corner, we see the approach where there are no iterations and no increments. This is the waterfall approach. All activities (design, analysis, build, test and deploy) are performed once for the entire project. In this case we see a single delivery of the final product based on a fixed scope. Customer value can only be achieved after the delivery of the final product. One of the key goals in this approach is to manage cost. See also the waterfall approach to develop the payment app in the first part of the article.

In the lower right quadrant, we see an incremental approach without iterations. This is a staged or incremental delivery of smaller parts the product. All activities for a given stage (design, analysis, build, test and deploy) are performed once. Within a given stage the scope is fixed, but the total product is based on a more dynamic or flexible scope. Customer value can be achieved after every delivery of the product. One of the key goals in this approach is speed of delivery.

Figure 4: Iterative versus incremental

In the left upper quadrant, we see a spiral or iterative approach without increments. This is a single delivery where the final product is created by using several iterations. A good example of this approach is design thinking. In the graph you see a sequence of the activities framing, analysis, idea generation, realization and reflection. This sequence will be performed repeatedly or iteratively where in every iteration you get closer to the final, correct or required, product. In many cases this final product is a prototype or model. In this spiral approach we have a dynamic or flexible scope. Customer value can only be achieved after the delivery of the final product. One of the key goals in this approach is the correctness of the solution.

In the upper right quadrant, we see the agile approach with increments and iterations. Scrum is a good example[2] of this approach. At the end of each increment, often called a sprint or timebox there is a delivery of an increment of the product. This increment is the result of many iterations to develop small but correct parts, often called user stories or backlog items, of the product. The final product will be delivered piece by piece. In this agile approach we have a dynamic or flexible scope. Customer value can be achieved after every delivery of the product. One of the key goals in this approach is customer value via frequent deliveries and customer feedback. See also the agile approach to develop the payment app in the first part of the article.

MVP or MMP?

In figure 4 you can also find the acronyms MVP and MMP. MVP stands for minimum viable product (Eric Ries, Lean Startup) and is a version of a new product or service which

allows a team to collect the maximum amount of validated learning about customers with the least effort. The MVP for the Dropbox service was a simple movie. This means that the P in MVP could be a completely different product in comparison with the final product.

I often use the following example of a new financial product. An enthusiastic sales manager has a great idea regarding a new financial product. He thinks that they can sell at least 100.000 of these products. Together with some finance experts, they design the product in a couple of months. A development team is assigned, and it takes them 4 months to develop the product. In parallel commercial brochures are developed and the product is launched with a big event. Unfortunately, just a few people buy the product. If we follow Eric Ries’ approach we could make the assumption that 10% of their web users are interested in this product. To test this hypothesis, they develop a MVP. In this case a simple button on the homepage. If you click you get a screen with a message regarding this new product and the question to leave your mail address behind if you are interested. Less than 1% of the visitors pressed the button. The product will not be developed. They saved a lot of scarce resources.

If we take a closer look at figure 4, we see the potential usage of MVP’s in all quadrants. When using a waterfall approach, you could create a MVP in the first design phase to check if there is a business justification for the project. The same can be done in the first phase of the first increment when following a staged delivery. In some cases, the result of your spiral, or design thinking approach could be a MVP. At the beginning of an agile approach the MVP could be beneficial too.

Many people see the first product delivered at the end of your staged delivery as the MVP. This could be the case but, in most cases, this is not a MVP but a MMP. MMP or minimum marketable product is the smallest product that can bring value to your customer. See the staged delivery or agile approach where a MMP could be deployed.

How does an agile delivery looks like?

Now it is clear that incremental and iterative are not the same and we understand the usage of MVP and MMP, we can explore in more detail how an incremental and iterative delivery could look like. You probably have seen Jeff Patton’s famous example of the Mona Lisa where the painting is created piece by piece (staged delivery) or in the first increment only a rough sketch and every new iteration more details are added to the sketch and ultimately you have the final painting (incremental and iterative or agile delivery). In the first situation you must already have a detailed idea of the final product and in the second situation you just need a high-level outline and changes are much easier to make. If we look at figure 5, we see a story map for a new product called ABC.

Figure 5: Story map for product ABC

The product owner envisioned seven features for this product. The first four features are must haves. Feature 5 and 6 are should haves and the last feature is a could have. Many would call this MoSCoW prioritization (Must haves, Should haves, Could haves and Won’t haves). Every feature in itself can be sliced down in smaller parts. In the figure you see features with must, should and could have user stories. A feature can be a must have but that doesn’t mean that all the underlying user stories are must haves too. Or a feature can be a should have but if you implement that feature some user stories are must haves and others are should or could haves.

To implement this ABC product, you see five increments or releases. The first one is the minimum marketable product. This MMP consists of the first two must have user stories of feature 1, and the first must have user stories of feature 2 and 3. Release 2 contains the next two must have user stories of feature 1, 2 and 3 (iterative development). Product development continues by implementing the next releases. With every release the customer value increases. After release 5 the product owner stops implementing user stories. Feedback from the customer showed him that the ABC product is ‘fit for purpose’ and he takes the Agile manifesto’s principle Simplicity – the art of maximizing the amount of work notdone – is essential, into account and stops further development.

Mini webinar Incremental versus iterative

[1] See YouTube for a very simple version of this figure: https://www.youtube.com/watch?v=20SdEYJEbrE&t=31s

[2] See my article with more than 70 agile frameworks or approaches: Portman, H. (2019). A bird’s eye view on the agile forest; PM World Journal, Vol. VIII, Issue X, November.