Planes, Trains and Automobiles
I’ve recently run a few workshops using different modes of transport to help explore some aspects of agile and thought I’d share the experiences here and what we learnt.
Redgate aims to work in an agile way and you might expect that many of the concepts are second nature to the people who work here, but occasionally it can be worth taking a step back and reminding yourself of the basics and why they are important. It can help ensure you’re not just blindly following a process and spot some areas ripe for improvement. Doing it in a fun way can help those lessons be memorable, after all, who doesn’t enjoy playing with toys in company time (all in the interests of learning 😊)?
Paper planes (and Kanban)
The idea for this one came from the Practical Kanban book by Klaus Leopold. I’d wanted to run it at our conference in Duxford (for obvious reasons) but it didn’t make it onto the schedule, so I ran it at our open space session in August.
The basic principle is you have a team of people building paper planes, they each have a set number of tasks to do, but there is one person who has more to do than others, i.e. you have a bottle neck. You also have somebody responsible for timing how long each plane took.
In the first run through everybody builds at their own pace (i.e. a push process, you do your work and push it on to the next person), but in a strict first in, first out basis, after a period of time you feed in a special colour piece of paper and make that the last one. Inevitably you land up with a big pile of incomplete planes in front of the bottleneck person which once the last paper has been fed in, eventually get cleared.
The next run through you work in a pull mechanism, so each person does their work and indicates to the next person they’ve completed it (hand in the air), if the next person has nothing to do they “pull” that plane forward and start work. When it gets to the bottleneck person things slow down a bit and the people before are left with partially complete planes in front of them and their hands in the air, only when the bottleneck person completes and can pull the next plane does the system free up (a bit like a Mexican wave) and people can pull more work in. After the same period of time as the first run through you again feed in the coloured piece of paper as the last plane.
What did we learn from this game.
Firstly it can feel very different working in the first mode than the second, especially if you were the person with the big pile of incomplete planes in front of you. The stress levels in the first run through were far higher and the quality of the planes produced lower.
Another surprising lesson from this is that the number of planes completed per minute for each run through is the same, the work takes as long as it takes. The key difference is in the first run through some of the planes spent longer partially complete than in the second, this was clearly demonstrated by the time it took for the special coloured paper plane to be completed. In the first run through it was a random (high) number, depending on how many planes were already in the system and how long it took to clear the backlog, in the second run through it was the same amount of time as every other plane, i.e. the second system was entirely predictable whilst the first was not.
If you have an unpredictable system (the first run through) then it can be tempting to put something through as a priority, i.e. it jumps the queue of things already in the system, but then the temptation is to add something else as a priority, and then something else and before you know it you have a system full of priority items. The best solution to priority is to have a stable system and do the prioritisation before the work enters the system.
The final thing that we explored was how a local optimisation can bring about a global sub optimisation e.g. if we’d split our team in 2 and the first team built their part of the plane really quickly but the second team couldn’t work at the same pace then there would just be a backlog between the 2 teams and nothing would be gained — when optimising you need to consider the whole system.
Trains (and incremental delivery)
The next workshop was designed to help our teams appreciate the value of incremental delivery and we used the Train Game described on tastycupcakes.org.
The game involves two teams building train tracks and getting paid for certain features. One team works in a big bang delivery approach, just getting paid on delivery and the other team delivers in sprints, accruing money each sprint depending on what features they’d delivered.
The exercise is obviously biased towards the team working in sprints but that doesn’t mean the lessons aren’t powerful. We’ve run this exercise across several of our teams now and each time the results have been similar.
No matter how much time we run the exercise for (10 sprints of 1 minute were not uncommon) the big bang team are rarely “done” at the end and often haven’t included all the features that the sprint team have.
The other glaring lesson is that the sprint team have usually delivered in their third sprint the same value as the big bang team do in the total time — somehow, they just seem to get to the value a lot earlier than the big bang team.
The final lesson is the cumulative value of early delivery, it’s a bit like compound interest, getting a feature that somebody values to them as early as possible means they can make use of it and they will start “paying” for it. The fact that the final sprints of both teams are worth roughly the same can hide the fact that you could have been paid an increasing percentage of the amount for the previous 9 sprints, overall you’re going to earn more money.
There were some other interesting observations made: the sprinting team spent more time communicating, collaborating and focusing on the high value items early. Often the big bang team fractured into individuals trying out their own ideas, there was no grand plan.
Automobiles
The title of this article was a bit of a cheat. Has anybody got any experiences of using an exercise based on cars they’d like to share? I feel like I need one to complete my vehicle based repertoire.
