Recently, due to a new exciting engagement, I have been thinking a lot about simple ways to explain the advantages of iterative incremental delivery over big bang releases. When speaking to C-level executives, coaches like me often have very little time, so we need to be able to engage with language they understand to make those few minutes count.
Money and impact on revenue seems to be a topic that is widely understood and accepted, so I have used and will use it during those conversations. My recent musings have brought me to a place where there is a currency that for modern organisations might be more important than revenue itself. Knowledge.
Now, let me expose differences between iterative incremental delivery and bing bang releases in terms of revenue and of knowledge.
Let’s start with revenue.
This picture is probably familiar to most of the agile/lean coaches out there and it is a good one to start the conversation on why releasing often while monitoring our customers behaviours has an immediate positive effect
From the picture is clear that incremental delivery has an earlier return on investment, while for big bang we have to wait until time t1 to get any return.
This is quite powerful but I don’t think it tells the full story.
Can we express the differences in term of something else?
To look at other aspects of the full story, we need to start visualising a different dimension than the usual revenue or $.
This new dimension is the currency of modern organisations, and it is called knowledge.
Let’s look at what happens with knowledge in a big bang delivery approach:
At the start of envisioning and planning we start building knowledge about what the customer wants but at the same time, being humans and fallible, we start building wrong assumptions about it. We will get full knowledge (wisdom) only after the release date t1. At that point we will be able to validate our assumptions and will build the knowledge about what the customer really wants. Isn’t it a bit too late?
Now let’s look at the same dimensions for an incremental iterative delivery
As we can see, even in our iterative incremental world we build up wrong assumptions about what the customer wants, the difference is that we disprove them very quickly by delivering early and validating them through customer behaviour. This reduces the risk of building assumptions over wrong assumptions but most of all frees our mind to look at how the customer behaves using our product and understand it better. As you can see the assumptions get eliminated and rebuilt often but the knowledge grows continuously. This is very different from our previous graph, what happens if we overlay the two is the following
Maximising the amount of work not done
Every time we deliver a small increment we must ask ourselves 2 questions:
- Have we satisfied our customer needs?
- Do we still need to do more to satisfy them?
Given K the point at which we can answer one of the 2 questions with a NO then a decision that impacts on the amount of work to be done can be made.
Case A: If at point K i have enough knowledge to decide that I have done enough to satisfy the customer and any other added work will have diminishing return on investment, I can decide to stop.
Case B: It at point K I have enough knowledge to decide that the customers aren’t happy with the product and I am losing revenue, I can decide to stop.
In cases A and B the red area is the work not done as a consequence of my decision. Such decision could not be taken with the knowledge gained with a big bang release if not AFTER the release and all the work had been done.
So, in conclusion, you should use iterative incremental delivery to maximise the amount of work not done. This way, you will save money on work not done, will have the opportunity to spend that money on something your customers really want, obviously through iterative incremental and knowledge seeking delivery.
| Published on Java Code Geeks with permission by Augusto Evangelisti, partner at our JCG program. See the original article here: How to maximise the work not done Opinions expressed by Java Code Geeks contributors are their own. |
