Penny Flow

Summary:

This game is based on The Penny Game.  I’ve seen it in various incarnations, but this is based on the original concept.  Instead of simply showing how batch size affects throughput, this game has been heavily modified to give several additional lessons.  Attendees can expect to learn about Agile’s roots in Lean manufacturing, batch size theory, single piece flow, being adaptive to change, quick feedback and communication.

Each round after the first is essentially optional, you can choose exactly which lessons you wish to deliver.  This may be all of them for more experienced teams, or fewer for those new to Agile.

Timing: 20 – 60 minutes depending on team size and number of rounds.

Materials:

• 20 x pennies
• 10 x larger denomination coins
• Whiteboard / Blackboard / Flipchart
• 1 x stopwatch per team
• Post-Its
• Pens for Post-Its and board

Instructions:

This game will be run over several rounds, with each round introducing a new concept.

Setup:

• Split your group into equal teams of at least 4, ideally not more than 6.
• Choose one person from each team to be the timer.
• If there are people left after this split, they can take charge of recording the results.
• Each team should form a line, sitting down along the edge of some work surface, like a table length.
• Ensure the timer for each team has a stopwatch.
• Give each team an equal amount of pennies (around 8 – 15 is good).
• You should now have equal teams with an equal set of coins, with everybody in the group having something to do.
• Draw a large grid that will hold the scores for the completed rounds.  Something like:

Round 1 – Batch Size:

Explain to the group that they each form a different team.  Each team will complete the same work, which in this case is the flipping of coins.  Each team member will need to complete the work in batches, before passing the batch to the next person.  People are only allowed to use 1 hand, and the batch must be stacked in a tower before they can pass it to the next person.

Give each person a job title to model a real project.  Commonly, this would be some subset of ‘Analyst’, ‘Designer’, ‘Programmer’, ‘Tester’ and perhaps something like ‘Acceptance’ if needed.

Tell the teams that you are the client, and that when the batch reaches you, they have delivered that value.  Tell each timer that they must record the time it took for the first and last batches to be processed.

Finally, tell each team that they will be working with a different batch size.  For 2 teams, use a full batch (the amount of pennies each team has) and 1 for the sizes.  This will result in 1 team processing pennies individually before passing them, and another processing the whole batch at each station.  With more teams, use intermediate numbers; so for 3 you would use 1, 5 and 10 perhaps.

1. Get each team to stack their coins in the required batch sizes.  Teams working on a single coin can simply use a heap.
2. Start the teams working with a countdown.
3. Ensure players only use 1 hand and that the work is completed according to their batch size.
4. Ensure the time taken for the first and last coins for each team is recorded.
5. Stop timers when all work is completed.
6. Record scores in the appropriate sections of your grid.
7. Asks teams to discuss what they noticed.

• The conversation will often be limited with more experienced teams here, so it’s unwise to linger on lessons that are already known.
• People should note that smaller batch sizes allowed other people to start working earlier.
• Indicate that even if the final times were very close for both teams, the teams with smaller batches were delivering value almost immediately. Reference the Agile Manifesto with regard to early and continuous value.
• The team working with a single batch size have been using single piece flow, first pioneered in the Toyota Production System.  It is largely this process that helped fuel the Lean movement, later translated to software by Tom and Mary Poppendieck

Round 2 – Reactive to Change:

Tell everyone that you will be doing the same game, but with some additional coins.  The timers will complete the same role as they previously did.  All other aspects of the game will be the same.

1. Evenly distribute the other coins through the batched stacks of the teams.
2. Start the teams working with a countdown.
3. Around halfway through, announce that you have changed your mind and now only want the pennies.
4. Allow the game to finish and record the scores.
5. Ask the teams to discuss how the exercise went.

Learning:

• Teams should see that with large batch sizes, there was a lot more wasted effort that went into processing and stacking unneeded coins.
• Teams should see that larger batch sizes made it more difficult to separate the required from the extraneous work.
• It should be noted that smaller batch teams were able to ignore the other coins once the change came in, reducing the wasted effort.

Round 3 – Quick Feedback:

The teams will now continue to use all of the coins, but change requests will no longer play a part.

1. Give each ‘Tester’ (Or simply choose one of the latter work centres in the chain) in your team a note that says the following: “We need all coins to be face down, reject entire batch back to Developer.  You can say why.”.  It is vital that this secret message is not shared with other teams or anyone else on their team.  The aim is for the ‘Tester’ of each team to reject the first faulty batch, have it ‘reworked’, and then successfully complete the remaining batches.
2. Allow the game to finish as normal.
3. Ask the teams what they noticed.

Learning:

• Teams should note that with larger batch sizes, the amount of work wasted was much higher.
• Note that smaller batches allowed for significantly quicker feedback to the team, reducing waste.
• Watch for teams repeatedly failing batches because the message wasn’t passed all the way back.

Round 4 – Bottlenecks:

This time we will model bottlenecks, and show the difference between local and systemic optimisation.  Ask each team to identify their primary bottleneck.  They should identify the first work centre as it is this person who delays the next from starting.  You may see people identifying themselves because they are slow, steer the conversation towards a more general view.

Next, ask the team how they would optimise that bottleneck.  You will generally see people saying that they would use more people.  Use this and say you are going to simulate that by allowing that person to use two hands for the next round.

1. Tell the first person in each chain that they can now use 2 hands to process their batches.  Each batch passed to the next person MUST be stacked on top of the coins that person is waiting to process.
2. Start the countdown to begin the game.
3. Allow the game to complete and record the scores.
4. Ask the teams what they noticed.

Learning:

• The times should be slightly quicker here.
• You are looking for the teams to mention that work started to build up further along the line as the rest of the team struggled to keep up.  they should identify that resolving their primary bottleneck has given way to another.
• Note that the work being built up before bottlenecks represents inventory.  Show that this is expensive to store for companies and often increases overall time due to the extra work required in maintaining it (The stacking).  This corresponds to the cost in manufacturing of storing large volumes of parts in warehouses.  By eliminating the need for storage using ‘Just In Time’, companies reduced the cost of maintaining and transporting that stock.  In software, this represents stories being stuck waiting for a person to complete the next step in the chain.  This increases the cycle time of that story, delaying value.
• Ask what would happen if you continued to optimise your first person.  You would be unlikely to see a decrease in overall time because you were optimising something other than your bottleneck, this is the difference between local and systemic optimisation.

Round 5 – Optional:

You may additionally run the game with a further optimisation on the first player here, just to highlight the point of local vs. systemic optimisation.

Alternatively you could choose to allow all teams to optimise their bottlenecks by using 2 hands for every work centre.  This would allow the teams to finish with their best output.

Concluding Notes:

For me, the benefit of this framework is that there are so many lessons to take from it.  Different people will see different things, don’t be afraid to run your own experiments in additional rounds; even asking your teams if there is something that they would like to model.

Thanks: 

Thanks to David Grant, Matt Pearce, Matt Grover, Steffan Liassides and the South Wales Agile Group for their assistance in refining this game.

 

Originally posted at: SeanTRobinson

 

Sean Robinson

I’m an Engineer/Leader with an insatiable appetite for personal improvement and an unrelenting passion for all things technological or Agile related.

www.seantrobinson.co.uk