Never out of style: Engineering principles and the Coin Game, pt.1
A running series on principles that don't seem to go out of style. The first few parts of this series: How 1 simple game can clarify a lot from Lean, Agile, DevOps and more.
Applying Lean principles to increase flow for software development is one of my favorite topics during any training or talk. The Poppendiecks proved in 2003 that applying Lean to software development works, and it was reinforced further by the work of other trailblazers like Nicole Forsgren et al. (Accelerate). Something as seemingly simple (and yet neglected) like reducing batch sizes and limiting work-in-progress provably leads to better outcomes in terms of speed and quality. And I don't think it'll go out of style any day soon.
My favorite way to illustrate this is by playing something called the Coin Game, and I wanna spend a few posts illustrating why this simulation is so great at uncovering some great insights whether it's on Lean, Agile, DevOps, software engineering in general or whatever.
In the Coin Game, you have 4 people to sit alongside each other on a long table to simulate different phases of a piece of software coming together from idea to value, and 20 coins laid down at the 1st person to simulate 'stories' being built. Each person will, one after another, flip the 20 coins with just one hand, before moving the whole batch to the next person who repeats the action before moving the whole batch of 20 again until it eventually reaches the end, i.e. the customer.
You measure (or have someone else measure ;)) the time it takes for each person from the time they touch their first coin, to the time they've touched their 20th. Additionally, measure how long it takes for the first AND last batch of coins to reach the customer (hint: for the first round it's the same).
You repeat this but with batches of 10, 5 and 1, while keeping the total number of coins at 20.
In the picture above you'll find the results of a game I played with batches of 16/4/1 (w/ 16 coins or markers total), but the principle remains the same: a lower batch size leads to better outcomes for both 'time to first' and 'time to total' value, thus an expected happier customer!
How this translates to software development is both simple and complicated and the same time: Focus on deploying / releasing 1 story or change at a time, rather than bunching them up and doing a big batch release. More on that later…
Stay tuned for some more insights I tend to teach using this game alone. Any other games you recommend to play for teaching certain principles?