Incremental or Iterative – Taking a Pragmatic Approach

As Agile practitioners we all know and agree that implementing Agile is challenging. Am also sure most of us have pondered on the question – why is it so hard for some while some others implement Agile quite well reap benefits? Is it because we are stuck with too many preconditions?

One of the key factors for successful implementation of Agile in today’s world is to adopt a pragmatic approach to it. It is necessary for us to understand and deploy Agile practices such as iterative and incremental development and delivery. Let’s explore this aspect a bit more in this blog.

What is the difference between incremental & iterative? Is Scrum iterative or incremental?

Although this sounds simple, I have found most struggle to get this concept.

Iterative Approach
Iterative development is when an attempt is made to develop a product with basic features, which then goes through a refinement process successively to add to the richness in features. For example, in a scenario when you are getting a customized coat made, you may be required to go for a trail to check for the fitting. Even though the you may find the coat fitting well, you may not be able to use it as it has not been finished. The fitting test was to give you an idea of the final product, which may not be ready for your consumption. This is an example of iterative prototyping.

In its purest form, iterative approach sticks to developing the basic functionality that is a minimum requirement. Subsequent iterations are used to add to the richness or features of the product.

Incremental Approach
In an incremental approach, one aims to build pieces of program/product that is complete in features and richness. In this case, each functionality is built to its fullest and additional functionalities are added in an incremental fashion. The key difference is each increment is fully functional with no requirement for iterations. You can compare this to a visit to restaurant. You get served starters first and on completion of its main course and then dessert. You get served incrementally and you consume it.

Going back to my question, Is Scrum iterative or incremental? – both Scrum and Agile are both incremental and iterative.

Agile gives you an option to do development in incremental & iterative way at the same time. The vision is to develop a product and share it with the user. If the user likes it she/he takes it and if they don’t like they give us a feedback to rectify it. Connecting with the analogy I shared before, it is more like cooking a dish completely and providing it for someone to taste. If the person likes it, they eat it. Else, we make changes to suite his/her palate. This is being incremental & iterative at the same time.

In my view this is difficult to achieve, particularly in early developmental stages. In my experience, I have seen most of the new product development to be iterative. After one release, once you have your minimum viable or marketable product, you start adding features to it.

While it is great to be iterative & incremental at the same time, are we doing it? If we are not, maybe we have to manage iterative development in an iterative way, rather than managing it in an incremental development way. There is value in doing iterative development. If you are cooking something new it’s good to test in-between, otherwise, there are chances that you may cook something which will never be liked by anyone. There is no point in spending much time in giving finishing touch to something when you not sure if it will really work.

This is where pragmatic Agile comes into play. The key is to be open to change. Rather than sticking to a framework and following just one sequence, we need to be open to considering multiple dimensions. We may find situations where in a whole product, one line is doing Agile and the other is following predictive. You may find this often when working with manufacturing and devices based project, where there are both elements of hardware and software and these are finally integrated together to as a product.

In my view, we need to be open about such hybrid approaches. This is what the project management body of knowledge or the PMI practice guide brings to you. There is always value of looking at things in perspective – while practicing Agile, you may focus on one dimension of things, while in a PMI world there is a project management background, they try to see how this fits into the overall project management framework.

In today’s environment, we need to be open to hybrid models. There is no wrong or right and we cannot afford to be rigid when you are working as an Agile coach. This is my view based on some of the experiences and as always I would like to hear from you on your experiences. You can also view a discussion on the same topic during one of my sessions in the link below.