Let me tell you about I had a conversation with a friend, about the most efficient way of delivering software.
My friend loved taking on new pieces of work. She has an excellent work ethic, and hates not having work to do.
If her work became blocked – BOOM – she would find another deliverable to work on
If she had finished developing and testing something …. WHAMMO – straight on to the next piece of work
Her work efficiency is very impressive, however, how can I tell this person, who is so focussed on being busy, that by doing less, she can deliver more?
So I created a little game.
I got 20 pens (10 for her – 10 for me).
I broke up the pens into their individual components – the body of the pen – the ink cartridge of the pen, the lid, and the small plastic base of the pen.
I asked my colleague:
Is it quicker to build one pen at a time, or is it quicker to begin work on all the pens and focus on one part at a time for all the pens?
“DEFINITELY working on all pens, building one part at a time”
Just as I expected! The challenge was on!
- I was going to build one pen at a time
- She was going to complete all of the components before moving to the next component
- We would see who was completed first
Aside from learning which technique was faster, we also learned some really interesting things.
- Within a few seconds I had a pen to Sell – Ship – Make Money faster – KA-CHING!
- Immediately after selling the pen I could get customer feedback
- After each pen I could check the quality
- I could learn about how I was building the pen after completing each one and alter (In fact, midway, I began testing the ink earlier in the process to eliminate waste)
- I had less inventory to manage
Lastly (and to her great surprise) – the big learning point for my friend
6. I WAS FASTER!!! I WON THE RACE!!! GET IN!!!
(subsequently I have run this game a lot of times – the lean approach of delivering one pen at a time is always faster by ~ 20%)
So by focusing on one deliverable at a time I delivered quicker, and delivered more, I delivered in a more efficient way, I had less risk of a flawed product, and I made money quicker.
I could sense my friend was beginning to waver on her stance.
I wanted to hammer home the point, so I drew two very simple Cumulative flow diagrams, for two hypothetical Software delivery teams both building an identical product at the same rate.
|The first cumulative flow diagram depicts a team delivering less frequent, larger batches of pens||The second cumulative flow diagram depicts a team delivering more frequent, smaller batches of pens|
To finally convince my friend, I illustrated through these charts that, even when we build at the same rate, by having more shipments, and less work in progress, we simultaneously reduce the risk while increasing the value we can reap from our product.
With my friend convinced, our conversation turned back to our pen production line race. We applied what we learned to a software development team. We believed:
- We could build faster when we had less deliverables to manage.
- We could release easier with smaller releases
- We could reduce risk by having less moving parts in each release
- We could learn more responsively how our application performs in production with frequent, smaller releases.
- We could have a shorter time to market
- We could add value earlier by releasing an MVP earlier.
- We could get feedback from our customers earlier
- We could tune how we build our software with a shorter delivery feedback loop.
This is something my team put into practice, and the rewards have been hugely beneficial. To get to this point we have had to remove a number of obstacles that were in our way. Waste work and blockers become magnified with frequent releases and this has fostered a leaner way of thinking about our delivery process.