Skip to main content

The Scrum Value Simulation

But please don't call it a game. Call it An Interactive Simulation on Optimizing the Creation of Value.

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:
  1. Process Small Batches (unchanged from Joe)
  2. Remove Impediments
  3. Do Less (but do the right thing!)
So I set up the game as follows:
The Players:
  • 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.
I deliberately identified the timers as 'efficiency experts' rather than 'managers.' Better not to antagonize the people who will influence the adoption of Scrum... ;-)

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.
(During the briefing, I do not mention the values of the coins).

Constraints: Just so that the game is not too easy, there are a few constraints:
  1. All workers work with their left hand only.
  2. A worker may not combine coins for processing (added this one during the game)
  3. A worker may only pass on a complete batch.
  4. The moderator will specify the batch size.
We played several rounds. As there were only enough people for one complete team, We did some things sequentially, which I would have preferred to do concurrently (with the teams in competition with one another).
  • 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.
(Note: I only entered the totals for the last round on the table below).

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 20 19 to 10: Processing Time went from 1:41 to 1:03, a 38% reduction. Although that 3 of 4 worker's times were slower in round 2 than round 1, the time measured by the customer was substantially better.

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.

Remove Impediments

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
  • swarming
  • 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
 Thank you

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.


Sameer Bendre said…
Peter, I was very happy with the way things shaped up during the game. It was FUN with the competitive element Brian Bozzuto brought into the game and the explanations by you and @srob were eye-opening. Everyone in that room njoyed the game and contributed their experience and learning.
Thanks again for organizing this and your valuable inputs during our meeting.
- Sameer Bendre (@Bendre)
Karen Greaves said…
Hey Peter, really enjoyed this game in Open Space. Will give it a try in my next newbie Scrum training in April and let you know what happens.
Karl Scotland said…
Hi Peter,

I used the Penny Game to kick-off my Kanban Deep Dive at the Scrum Gathering for the reasons you describe. I missed the OpenSpace opening - if I'd know you were doing this I'd definitely have come along!

I really like your variation. The one thought I had was that if you're going to be specific about calling it a simulation, why also include Scrum in the name? Its not really about Scrum but about value flow? So how about "The Value Flow Simulation"?

Peter said…
@Bendre, @Karen

Thank you very much! I used this game in a CSPO course this week. Lessons learned:

1. This game is immensely powerful. There are so many lessons that can be extracted from the game. Too many, actually. It's important when doing the game to decide and communicate clearly which messages you want to get across.

2. Don't do too many iterations. After a couple iterations, people get numb. 3 or 4 is probably the right amount. 5 was too many.

3. Main disadvantage: Like the Ball Point Game, this is about production, not knowledge creation. (Yeah Karl, I hear you ;-) ).

For the product owner, I will probably focus on these messages:

1. Produce Small Lots
2. How the customer role changes as the lots get smaller
3. Prioritize & Do Less

(This means I can do away with the efficiency experts)

For a Scrum Master course, I would probably focus on:

1. Smaller lots
2. How individual performance and team performance are (not) related
3. Removing impediments.


KarenG said…
I did this last week in my inhouse Scrum training with some modifications. Check out my post here:
Peter said…
Great alternative Karen, I'm going to try it out with my next group!

You can find Karen's version more easily by following this link: The Scrum Penny Game – a modification
leansimulation said…
Such a simple game that demonstrates the benefits of smaller batch sizes! Thanks for the description! I posted a review on my blog at http://
Peter said…
Should have mentioned long ago - I now prefer Karen's version of this game. I like the addition of 2 minute iterations - the increase in value produced per sprint can be really dramatic and makes the game more Scrum like. Without the iteration it's more of a flow simulation.

Popular posts from this blog

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

10 Warning Signs, that your team is not self-organizing

How do you know that self-organization is working? The Bern Chapter of Scrum Breakfast Club looked into this questions, and identified the following warning signs (which I have taken the liberty of translating).

The team reports to the Scrum Master at the Daily ScrumPeople wait for instructions from the Scrum MasterTeam members don't hold each other responsible [for their commitments]The same impediment comes up twice"That's the way it is" => resignation"I" instead of "We"Flip charts are lonelyCulture of conflict-avoidanceDecisions processes are unclear, nor are they discussedPersonal goals are more important than team goals
To this list I would add my a couple of my favorites:
you don't see a triangle on the task board (not working according prioritization of stories)after the daily Scrum, people return directly to their desks (no collaboration)there are a least as many stories in progress as team members (no pairing)
P.S. You can join the …