At Jeff Sutherland's CSM Course in Zurich, I witnessed him lead the class through Joe Little's Scrum Penny Game. It teaches the importance of small batches and optimizing the whole. I was really intrigued by the game, and thought it had much more potential, so I revised it and tried out the first incarnation at the Open Space in the Scrum Gathering. I wanted to see a) if the game (and especially the revised game) had the same impact on the assembled experts as it did on me, and b) get feedback for improved or alternative versions.
I wanted to emphasize principles that management could implement to improve value creation:
- Process Small Batches (unchanged from Joe)
- Remove Impediments
- Do Less (but do the right thing!)
- Customer: sends the batch of coins to the workers, accepts (by touching) the received coins from the last worker.
- Customer's Boss: Measures the time elapsed time between between sending out the first coin and receiving a) the first value (coin) accepted and b) all coins accepted.
- Workers: Each worker receives a batch of coins, flips them, and moves the bath to the next worker
- Efficiency experts: measure the time "their" worker spends flipping coins.
The Props: per team, 20 coins, consisting of
- 5 quarters (25 cents each)
- 5 dimes (10 cents)
- 5 nickels (5 cents)
- 5 pennies (1 cent)
- Each efficiency expert and the customer's boss need a stopwatch with a lap split. Most cell phones can serve this purpose.
Constraints: Just so that the game is not too easy, there are a few constraints:
- All workers work with their left hand only.
- A worker may not combine coins for processing (added this one during the game)
- A worker may only pass on a complete batch.
- The moderator will specify the batch size.
- Round 1 - Lot of 20 (well 19 actually)
- Round 2 - Lots of 10
- Round 3 - Lots of 5
- Round 4 - Lots of 5 without constraint on using one hand.
- Round 5 - Reduce total volume. Customer selects the 10 coins with maximum value.
Perform in Small Batches
Round 1 establishes the baseline. It also established competition between the team members (the one lefty was very proud that his time was the best). Note that the sum of the individual times != the total time measured by the customer's boss. Some workers blamed this on the slow reaction of the customer to accept the coins. There were also gaps because the measurements don't account for transit time.
Round 2: Before starting, the team noticed that a coin was missing. This was not intentional, but a great addition: Where is the missing functionality? What does this say about acceptance testing? This round showed the improvement of reducing the lot size from
Round 3: There was some disbelief about the effects of the batch size, so the third round was made with smaller batches still: 5 instead of 10. Individual performance was about the same, but the customer time improved again, declining to 0:43, a 32% reduction from round 2.
At this point, the team accepted the importance the first principle: produce in small batches.
I asked the team if anyone noticed that they had one hand tied behind their backs and pointed out the rules are there for a reason, but improving performance is not usually one of them.
Round 4: Same configuration as round 3, but team members may use both hands. Time to produce full customer value: 33 seconds, a further reduction of 23% from the previous round.
Do Less, but do the right thing!
I asked the team how much value they had produced. The sum of all the coins was $2.05. I asked the customer to pick the 10 coins with the most value (the quarters and dimes). This reduced the processing time a further 30% (down to 23s), but only reduced the value delivered by 15% (to $1.75).
As I write this, I realize that if the team had processed the pennies and nickels instead of the quarters and dimes, the value produced would have been $0.30.
Summary and Discussion
After playing 5 rounds, we had a spirited discussed on the lessons of the game and other lessons which could be learned from the game, and how to use the game to address other issues, such as:
- the problems of a hand-offs in a phased model
- self organization
- rivalries between team members and teams
- impact of bonuses
- tension between optimize team and optimize self
- need to release earlier than planned
- what happens if someone is pulled out of the team
- use different activities, some of which are harder than others
I would to thank everyone who came to the game for their help and energy, and above all for the great discussions afterward. There will be a picture here in a moment. If you use this game (uh, simulation) or modify it do drive home some other points, please leave a comment ( or a link to your own blog) so that this simulation can develop its full potential! Thanks.