If you are interested in Agile and if you want to read up on it (reading books, blogs or following discussions on twitter) you soon stumble upon the following picture to visualize incremental value. I believe it’s from Henrik Kniberg:
I do understand where this picture is coming from. It is about focusing on value and delivering incremental value step by step, bit by bit. Vasco Duarte uses a similar example in his must-read book about NoEstimates. He uses an example which starts with a tent, then creating a hut, a trailer home, an apartment, a condo and finally a house. This way we deliver value fast and at least have something ready to ship when the deadline hits. This is opposed to the traditional method where you would have a half built house which is unusable.
These aren’t strong examples. In fact I dare to say these are not reflecting the idea of incremental value. In the example above, the increments don’t add value on top of a previous increment. It is basically replacing one feature with another.
I won’t argue that the first feature of the picture, the skateboard, is not reflecting what the end user wants. You can only determine this if you know the demand and it might be that the only requirement is to have a fast way of transportation. All increments then would improve the situation, when compared to walking, but not really compared to the immediately preceding increment.
The fact that you don’t deliver incremental value on top of what you already delivered is the issue here.
Below I have an example which I love to use. It is about building a holiday park, starting with an empty field. Everything you add is added value and the previous features remain as useful. You can start with a very basic campsite and improve it step by step.
Holiday Park
Tom and Jane bought a piece of land in the French Alps. It is their dream to start a beautiful holiday park. They expect to have visitors throughout the year.
Tom and Jane start with the quick wins and deliver value bit by bit.
They start with the basic campsite for tents. All very rudimentary, but at least they are able to generate income very early on. In fact: they started this in March and already in April there are people staying on their campsite, and paying for the services.
Next they add the reception. Now it is very clear were to be to check-in and check-out, ask questions etc… They did this based on the feedback that people, coming to the park, did not know where to go to check-in.
Next addition are toilets and showers. Now people’s basic hygienic needs are met, and they don’t need to take a shower with a bucket containing ice-cold water from the river near by.
Next they add electricity outlets to allow caravans. This is ready before the summer season, allowing Tom and Jane to make evenmore revenue.
Next are laundry facilities so people don’t have to leave the holiday park for this, and end up finding a better holiday park.
Then a camp shop for convenience and added revenue.
After that, container homes to attract winter holiday makers, well before Christmas.
Then a swimming pool to appeal to families with kids.
And then the fun and entertainment team to make the holiday park even more appealing.
Etc… the list can be endless.
This is a very clear example where you can start with quick wins and add increments on top of that adding more and more value. There is immediate value from the first increment. It is also – and I think this is crucial – very much applicable to software development. That is why this example is so vivid if I use it to explain one of the benefits of incremental delivery to my colleagues.
About the author
Willem-Jan Ageling (Willem-Jan Ageling on twitter, Willem-Jan Ageling on LinkedIn)
I have worked in IT for more than twenty years. Mostly for larger financial companies and IT service providers. But also for smaller companies with rapid/continuous delivery. I have witnessed how traditional projects failed. More often than not they were delivered too late and at a higher cost. I have worked on continuous delivery of working software and worked with 4 week cycles before Agile was born and Scrum and XP got even remotely popular. Huge advocate of Agile software development and also participating in the NoEstimates discussion.
I love the holiday park example, probably because it’s an example I’ve seen in action and WORK many times over. It’s also a good example of approaching things from a Lean Startup perspective, mitigating risk (of building the wrong thing) by splicing up the value proposition and starting with the first iteration (rudimentary campsite in this example).
The important thing to remember is that it’s not necessary to know that you’ll end up with a swimming pool (or shepherds huts, luxury cabins etc), it’s that you first need customers to be able to test ideas on and gradually alter your plan based on their feedback (and as resources allow).
The example by Henrik Kniberg isn’t as good an explanation of iterative software development because it lacks real life context. If all a customer said was ‘I want a faster mode of transport and to feel the wind in my hair’ then maybe it would work ok as an example. But in reality that’s not what a customer would say and actually, if they did say that, it’s our job to ask the questions of that elicit further information so we can avoid pointless iterations.
Hi Kirsten,
Thanks for the positive feedback. I fully agree that this also is an example of Lean Startup.
I always had issues with the transportation example. It is very logical that people criticize it, but that doesn’t mean that the theory it tries to visualize doesn’t work either. As I couldn’t stand this fact (example is wrong therefore theory is also wrong). I tried to come up with an example that -in my view- is both simple and correct.
The transportation example doesn’t even work for faster mode of transport, as you state. Reason is that you have been putting effort in a product, throw it away and replace it with something new. It simply doesn’t match with incremental delivery.
This can be a guided conversation with a Box of Legos. The physical layer again reinforces clearance, avoids a meta discussion what could be and leads to first prototypes fast.
Another great example is a Zoo: Here the animals are the constraints as well.
Hi Sebs, is there a way of explaining in plain English what you mean in your opening sentence? It’s very difficult to understand (I don’t get it at all) but maybe there’s something useful to be heard.
Hi Sebs,
Do you mean that you can visualize the story real-time by building the holiday park up with Lego? Yes I think that is a great way to explain it.
I love the holiday park example, probably because it’s an example I’ve seen in action and WORK many times over.
Yes, a much better example Sebs – I have never liked the Kniberg picture and have had to use it on a couple of courses I have run, that were built by other people. I always ended up making my own example along similar lines as yours – but not as good.
Effectively, each increment delivers another usable chunk of value – usually extra features (but not always as it may be non-functional change or an efficiency improvement, etc). But the key is that whatever is delivered adds further value and builds on top of what you have.
The analogy can go further, as sometimes you may replace an existing increment with a totally new and improved version – e.g. replacing your current swimming pool with a bigger one, perhaps including a health spa 🙂 You may site the new pool in another spot so that you keep the old pool until the new one is fully working but then you could use that space for something else (although you could keep it as a 2nd pool or maybe make some small changes to become a children’s play area with pool – who knows!).
Really good analogy thanks Sebs – I will use it in future if I may??
Hi, thank you for this post I agree with you that It is about building a holiday park, starting with an empty field. Everything you add is added value and the previous features remain as useful. very useful information