A very well known exercise for teaching the importance of small batches and flow is the penny game. When I first played this game, I was amazed at the impact just changing the batch size has on throughput. The setup of the game is quite simple. Typically the game is conducted with groups of 5 to 7 players. Give each group 20 pennies. The objective is for each group to process the pennies in batches until they have completed the job. To process a penny, it must be flipped. Each worker must flip their batch of pennies before passing the batch on to the next person in the group. The job is completed when the last person in the group has flipped the last penny. One person in the group is designated as the timer and they track the time it takes to complete the first batch as well as the time to complete the last batch.
The exercise starts by making the batch size 20 and then reducing it to 5 and then to 1. I have seen 3 fold improvements in time from 20 penny batches to single penny batches. To add a little spice to the game, you can declare that a batch must start over if a penny drops on the floor, or they must use their left hand and have 3 inches of vertical drop.
I recently modified the game to help groups understand the importance of synchronization and cadence. When is this important? In agile software development at scale, this is vital. When working as a single team, that team is free to work at whatever sprint cadence they desire. Scrum recommends anywhere from 1 to 4 weeks. There is no concern about whether a sprint starts on a Monday or a Friday or any day in between.
At scale with 4 or 5 teams this will not work. If each team is completing their sprints on different weeks and on different days, when can I deploy the software? There is no single point in time where I can count on all the code being complete. To overcome this issue every team must work with the same sprint length and start on the same day.
To illustrate this I came up with a slight adjustment to the penny game. The basic premise is that the groups are no longer independent teams working alone. They are interdependent and must work together. The change I made is to require the groups to have to pass their batches from one group to the next. In my game, I have the 2nd person in the group pass theirs to the 3rd person in the next group and then the 5th person in each group pass their batch to the 6th person in the next group. The following diagram shows how this would work with four groups of seven players. The doted lines show how the pennies would move from player to player.
For the first round of the game mix the batches as follows: A = 10, B = 2, C= 5, D = 4. If you have 5 groups, put group E between D and A and give it a batch of 5. Record the time to complete the very first batch at any group and the time to complete the last batch overall. The important rule to remind the groups is that players 3 and 6 are not allowed to start a batch until a full batch of pennies is at their table from the previous group.
Repeat the game only this time every team has the same batch size of 4.
Several issues will become very apparent in the first round. There will be down time at the tables as they wait for their full batch to be delivered from the previous group. There will be confusion as they try to identify who the right person is at the next group to receive their batch. Logistics and coordination have been added to the process.
In the retrospective, I ask what issues they ran into and how they could improve the overall process. I heard many suggestions including having a person bang a drum to provide a single cadence. I then ask this question, would making the batch size 2 improve the process? There was a mixed response. Because of the logistics of moving batches between tables, the value of a smaller batch is offset by the overhead associated with moving the batch to the next table. This is a great illustration that there is an optimum batch size that is not necessarily the smallest size possible.
I like to have the group then implement the improvements they thought would help and run the game one more time. Give them the challenge of seeing how much faster they can go.
Feel free to use this exercise when you are trying to get multiple agile teams to work together.
