Agile game – Pass the pennies


Timing: 10-15 mins

Ingredients:

  • 20 Pennies (any kind)
  • 4 departments (1 worker per dep. sitting at table)
  • 4 dep. managers with stopwatch
  • 1 CEO  (with stopwatch)

Directions:

Game has three turns – each with different batch size [20, 5 and 1].

Workers job is to flip the pennies he receives as fast as he can and then pass them on to next. Department managers job is to take time his worker spends from the first to the last coin flipped. CEO takes total time from the first coin to the last. 

For fun, let managers have a "one-on-one" chat with his worker after each round.

Display results on a flipchart:

 
20 coin batch 5 coin batch 1 coin batch
Department 1 10s 17s 12s
Department 2 12s  
Department 3      
Department 4      
Total .. .. ..

Learning Points:

  • When batchsize decreases, total cycle time decreases
  • As total time decreases, worker time increases!
  • People idle more when batch size is high

CREDIT: Agile Coachcamp members

10 responses on “Agile game – Pass the pennies

  1. Great exercise, it’s now a staple on my CSM courses! A really simple and powerful way to demonstrate how cycle time gets messed up by suboptimization and batching. Thanks George Dinwiddie for showing it to us at the Agile Coach Camp in Michigan!

  2. * As total time decreases, worker time increases!

    What does this mean, people are busier?

  3. Wonderful game and concept – I think, though, that the conclusion and explanation might need a little refinement. You might not have meant it this way, but the game is an extreme case in idling.
    For example, what if there were a steady un-ending stream of coins (as you’d have in a product development scenario). Do you agree that in Round-1, we’d have 20 coins come out of the process every 20-odd seconds. A coin a second. And hardly any idling.
    On the other hand, in Round-3 you’d have 20 in 35-odd seconds. However, Round-3 is still superior despite being slower, because each coin spends much lesser time in the system – reducing feedback/cycle-time.

    So, fundamentally reducing idle-time doesn’t make the process worse up to a point.- in fact some slack makes the cycle-time dip. Does that sound right?

    1. “For example, what if there were a steady un-ending stream of coins (as you’d have in a product development scenario). Do you agree that in Round-1, we’d have 20 coins come out of the process every 20-odd seconds. A coin a second. And hardly any idling.”

      > The game has an initial setup costs for that would be removed if coins entered continuously. In a product development scenario a setup cost of some sort is to be expected (requests will be different). But even if we had continuous flow of coins, the coins would still idle. It can easily be seen by observing the number of inactive coins in front of each worker)

      “On the other hand, in Round-3 you’d have 20 in 35-odd seconds. However, Round-3 is still superior despite being slower, because each coin spends much lesser time in the system – reducing feedback/cycle-time.”

      > Agree. It reduces cost of a quality error (faulty batch), cost of late change and requires less invested capital.

      “So, fundamentally reducing idle-time doesn’t make the process worse up to a point.- in fact some slack makes the cycle-time dip. Does that sound right?”

      > We should define what slack we are talking about first.. But resource/worker slack helps accommodate for variance/uncertainty, thus helps us deliver with better accuracy.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.