Tips for running the paper plane game
I learnt the paper plane game from the awesome Sam and Karen at a SUGSA meeting in Cape Town some years back. It blew my mind, because it shows (with maths!) that everyone works more effectively when not everyone is working all the time. It shifts the focus from someone’s individual productivity to the throughput of the team. The principle here is “Stop starting, start finishing” but to actually experience that is amazing.
The problem the game is trying to solve is what many teams and organizations seem to default to, which is working on as many things as possible at the same time (this could be number of features in a project, number of projects, number of strategic initiatives). While this seems productive — because everyone is working all of the time — it’s not smart…or productive. The paper plane game is a way of showing this mathematically and experientially by having teams of people build 10 paper planes in two rounds, changing just one thing in the second round and recording some interesting metrics to compare the difference. A good debrief will draw out some insights into the work environment.
Also, it’s more fun to say, “Let’s build paper planes together!” than it is to say,
“Let me do a presentation on why implementing Kanban’s work-in-progress limits at the place we want to see value is an example of applying the Theory of Constraints to a value stream system which results in more slack, less multitasking and decreased cycle time while maintaining throughput and increasing predictability.”
If your team is theoretically minded, bring this out in the debrief — but in my experience, it’s more important to focus on what new behaviours this enables for the team, such as better questions to ask in standup given this new awareness — and keep the theory for one-on-one discussion afterwards.
The instructions for the paper plane game are at http://www.growingagile.co.nz/2015/02/aeroplane-game/
I run this game with all teams I work with because when it’s debriefed well, it shifts the focus in standups away from each individual onto the team, resulting in better conversations about the work. I’ve also learnt a number of things from running this game (and having it fail twice!).
The failures I’ve had
- The 3rd station is the bottleneck but I once had someone be so slowly meticulous that station 1 was the bottleneck, and so the difference between round 1 and round 2 wasn’t much.
- People forgot to maintain the order the planes were built in, which means the recorded cycle time for plane number 6 was wildly inaccurate (but this can still be debriefed: “Why was it so hard to keep track of plane 6? Oh, because there’s so many other planes? Has something like this ever happened to someone, where you lost track of work because there was so much else going on?”).
- I forgot exactly how the station 3 fold worked, so when I demonstrated it I only served to confuse others (and myself!).
- Someone on station 3 felt pressured so drew the stars as fast as possible, resulting in a squiggly mess.
- Not having the organisational “Agile coach” present in the game, so that when in standup a week later the team literally asked for WIP limits — he said no. Because he didn’t get it. I’m still sad about that. Get all of the stakeholders in the room! Including ScrumMasters and product owners, and even business people too. Implementing WIP limits increases throughput: this can be applied to the number of projects in progress, not just number of dev tickets on the board (yes, there are levels to this).
Setup tips
- Make sure you have enough paper, and have a coloured piece of paper as the 6th plane. If you don’t have coloured paper (I usually don’t) then draw lines on both sides of a piece of paper and use that as the 6th plane.
- On a board or large piece of paper, draw up the table on which to record each team’s metric.
- If you have someone who is so meticulous that folding a piece of paper in half will take them as long as station 3, put them on station 3! Make sure that station 3 really is the bottleneck.
- Have 3 planes already folded to show what each station is meant to do. Then when you demo each station’s job, you can just hold up each plane and show the folds.
Improvisation tips
- This game can be run with just one team. More than one works too, but isn’t required.
- Don’t worry if you have less than 6 members per team. I’ve run this recently with two 4-person teams. The first station then becomes the timer — for total time as well as for plane 6 time. Tip: make sure to remind them to start their timers at the start of the game as as plane 6 starts and ends.
- Don’t worry about exhaustively explaining all of the details until everyone “gets” it. It’s ok that some people are a little confused and uncertain — that can be brought out in the debrief (“What does it feel like to walk into a new team and not really be sure about what’s going on? How can we help new team members?”). As long as you’ve emphasized the important points the game will work: how each station needs to fold the plane, the order must be maintained, don’t work too fast or too slow, don’t worry about what’s going on around you.
The first round
Some things to emphasize again to everyone the first time the game is played are:
- Don’t worry about what’s going on around you. Just keep your head down and focus on your own work. Fold and pass, fold and pass.
- Very important! Keep the planes in order!
- Remind everyone that there’s still a focus on quality: the aim isn’t to build 10 planes as fast or as slow as possible, but for them to be decent planes. Don’t rush! But don’t be slow either. Work at a decent pace.
The second round
- Remind everyone to work at the same pace! Don’t try to work faster or improve or be better. Just work at the same rate as the first time around.
- Don’t pass work on. Wait for someone to take it from you.
- I’ve played a variation of this where when someone isn’t doing anything at their station, they should put their hands in the air. This is a bit silly and also encourages them to look around. It also allows you to do be a seagull manager.
Be a seagull manager
Finally, you get to live your dream of being in management! Be the seagull manager! Hover over people and crap on them! With humour, look at people with their hands in the air and say things like, “Why aren’t you working? I don’t pay you to come to the office and do nothing! Why aren’t you being productive? Why are you slacking off?” Have some fun here.
The debrief
The first number of times I debriefed this it was on the more conceptual level, of trying to show the value of limiting work-in-progress and maybe even helping the team commit to WIP limits in the next sprint. While this is still a good thing to do, I’ve added more of a focus on the different kinds of behaviour that a limited WIP system allows to emerge in standups.
Start the debrief neutrally: “What was the difference between the first and second times?” Bounce between bringing out people’s experiences and referring back to the numbers on the board. Especially focus on what it felt like to be someone at the 3rd station in terms of pressure and expectations.
Debrief first goal: individual productivity vs team productivity
Key question: “Which way of working is more productive?”
The first goal is to move towards showing that one’s individual feeling of productivity is not related to team productivity. I first experienced this as strong cognitive dissonance: I knew I worked less hard the second time around, but actually we were more productive and less stressed.
I once had someone say how they weren’t being productive second time around. Great! “How do we measure productivity? How do we know when we’re being truly productive?” This is beginning to shift the understanding of productivity away from individual good efforts and onto the work flowing through the team.
This draws on Russell Ackoff’s system thinking:
“A system is not a sum of the behavior of its parts, it’s the product of their interactions.”
…which then leads to this gem:
“If we have system of an improvement, that’s directed at improving the parts taken separately. You can be absolutely sure that the performance of a whole will not be improved.”
Note: the team isn’t actually being more productive in terms of overall throughput: the time it takes to build 10 planes should only marginally improve, or even improve a bit (maybe people are getting better at their tasks, which is why it’s important to emphasize that everyone should work at the same rate the second time around). The massive improvement is on the cycle time of a single work item and the consequences of limiting WIP through a pull system. If we were to fast forward the time the system runs for into 20, 50 or 100 planes, the cycle time in the first system would keep getting worse, while the second time around it’s constant. Constant! This means that we have predictability!
So you’ve just discovered a way to answer, with data, the management question of “How long is this going to take?” Start recording the cycle time of the thing you care about (I usually default to features rather than tasks) and once you have 2 weeks of data you can start answering this question. The next step is to not use cycle time averages (which are wrong 50% of the time) but to use the historical data as inputs to Monte Carlo simulations, which can give an 80th percentile answer (e.g. “It will take the team 7 days to finish a new feature, with an 80% degree of confidence”). How to do this is beyond the scope of this article, but if you’ve implemented WIP limits then you’ve created a stable system which is the pre-requisite for trustworthy estimations.
Debrief second goal: try WIP limits
Now we’d like to say, “This is useful — how about we try it in our team?”
There is no correct WIP limit — the guideline is to choose one which is starting to be uncomfortable. The WIP limit must be a constraint — otherwise there’s no enabling constraint which results in the emergence of new behaviour. If you want to encourage pair programming, have a WIP limit smaller than the number of team members.
The WIP limit should be applied at the place you want to see value (i.e. greater throughput). Should this be on the “Dev — in progress column” or at a feature level? The guideline is to use it at the most abstract place possible within your system (i.e. features instead of tasks, and that can keep on working up the organization to projects and even portfolio level).
Debrief third goal: shift to a pull system
The first time the team pushed work to each other, so work piled up. The second time team members pulled work from each other as they freed up capacity. Implementing this change on a physical board requires a little bit of work: each column on the board then gets divided into 2 columns: “In progress” and “Done”. This is what a Kanban board looks like — Kanban literally means “signal card” — the idea is that each sticky on the board isn’t just a task placeholder, but is now signalling to the team its exact status (“Being worked on” or “Ready to be pulled into the next work state as capacity allows”).
Think about it: a standard Scrum board doesn’t have this level of clarity. If something is in “Dev” is it being worked on, or is it finished? We just have to wait for standup to find out — in other words, the board isn’t properly functioning — there’s information which the information radiator is not radiating.
If we can coach team members to update the board as they’re done with a task, and other team members to look at the board to see what to do next, the board is now being used as a way to signal to other team members what needs to happen next.
Standups then shift towards talking about the work, rather than about what each person is working on.
Note: redrawing the board shouldn’t happen during the debrief, and this “shifting to a pull system” doesn’t really need to be emphasized any more than “Let’s try WIP limits” and then you — or the ScrumMaster — draws new columns on the board later.
Side rant: this is why having a physical board is better than a digital one — it can be redrawn at will. A digital board which can’t be changed (here’s looking at you, Jira Kanban boards) means the tool shapes the way of working, rather than the other way around.
Debrief fourth goal: improving standups
Key question: “How does this change the kinds of questions we ask in standups?”
The second time the game is run, there’s more slack. What do people do in their slack time? One person looked at their own plane and realised he could fold it better — so there’s an increase in quality. Others looked at the 3rd station and wished they could help. People were more aware of what work was blocking the system.
Encourage the use of this awareness in standups by shifting the focus away from individual status reports to what’s going on on the board, and how we as a team can help work flow across the board. A standup run in this way “walks the board” from right to left, starting with the right-most item and asking, “What can we do to finish this item?”
Ideally people are now seeing how they can help each other rather than just ensuring they have stuff to work on.
Post-game tips
- Re-draw the board, explicitly showing the WIP limit number and where it applies, and having each workflow column showing “In progress” and “Done”.
- Take a photo of the metrics captured on the whiteboard during the paper plane game and send it to your team (and potentially beyond), with a little writeup reminder about the benefits of working smarter.
- Tell me how it went!
Conclusion
That was much longer than the blog post I set out to write! I’ve honestly felt like the paper plane game has been the most useful tool I have in order to bring about a feeling of calm focus within the teams I work with and in. Instead of productivity being felt as “The number of items being worked on” where people just start working on new things as they feel like it, productivity is expressed in the behaviour of finishing in-progress items before new ones are started.
And you get to build planes. Make sure to throw them around the room afterwards. And let me know how the game goes for you!
