Incremental vs iterative developing

I am starting to learn drawing, I do not aspire to be an artist, to me, drawing is like a way of communication, so many times I wish I could draw the pictures in my mind. While I am learning drawing, one lesion I learned early on is that you have to get the structure ready and right early on, you put on finer details later on, and some finer details will pop you drawing out, making it vivid. But if you get the structure correct, at least you won’t get a terrible picture, so terrible that no amount of finer details can make it look good. 

For software development, we need to take a similar approach. My drawing is not so good at the moment, so I took the pictures and ideas from “User Story Mapping: Discover the Whole Story, Build the Right Product”.

Incremental

The problem with this approach is:

1. You are optimizing prematurely

     You work on something to perfection, only to find out later that this kind of perfection is not necessary. We know this from performance tuning, without taking the full picture and identifying the bottleneck, we can fine tune a part to death and won’t make a significant difference. 

     2. You may lose sight of critical risks at a later stage, when you realize that the pieces that you’ve work out to perfection can’t be integrated together. 

     3.  It is easy to lose sight of the whole picture when working on piece by piece

        

With (badly implemented)Scrum, it is easy to make this kind of mistakes. You pick up stories from the backlog and work on them without knowing how these stories will come up and make up a whole picture.

   

     4. Even if the whole picture turns out to be perfect, when it is released, it may not be what the end user wants. You lose the opportunity to be told by users earlier.

Agile’s value is to tell you earlier (way before step 5) whether you are doing the thing that users want.

Iterative

This is how one draws a picture, and how software should be built. 

Last year, I was involved in a POC which was to prove the feasibility of a project. The team tasked with the POC took an “incremental” approach: they made several POCs to test several parts of the project, and concluded the project feasible. While no one single POC tested the project from end to end. The project was claimed feasible, and all teams were thrilled to jump onto it, until they stumbled on a critical block. Had they performed an end to end POC, they would’ve found out the block. 

Here is the bad news. In reality, users might ignore you completely until you’ve reached step 4 or 5:

You need good product managers or product owners who know how to engage users, and how know how to extract information from them.