The X Penny Game

The X Penny Game is a simulation game exploring the effects of WIP limits. It is a combination of Karen Greaves modified Scrum Penny game with Karl Scotland’s version of the Ball Flow Game.

This game is geared to show the importance of limiting the work in progress and to explore the following formula (implied by Little’s Law)

Flow Time = WIP/Throughput

  • Flow Time (Cycle Time, Lead Time) – average amount of time it takes to fully complete a unit of work
  • WIP (Work In Process) – is the average amount of units in the system
  • Throughput – average number of units being completed within a given time frame

The game is designed to work with 6 to 12 people – we had 8 players and 1 facilitator

The team divides into the following roles:

  • 1 – Customer
  • 5 – Workers
  • The rest are efficiency experts

We had a total of 8 players (6 workers, 2 efficiency experts).

The team organises themselves around a table. The image below shows how our team arranged themselves. Each worker has an empty area on the table directly in from of them referred to as a workspace.


The props
100 coins – I used 10 pence coins (GBP), all coins should be the same size
1 table – large enough to have 3 people stand side-by-side on each side of the table
A stopwatch for each efficiency expert – ones that can pause and resume
A spreadsheet to record stats – discussed later

The game
The customer takes a batch of coins (from 1 to 100) and passes them to a workspace. A worker turns over each coin one-by-one and then passes the batch to the next workspace where the process is repeated. A batch of coins are returned to the customer once they have been turned over once in each workspace. The facilitator records the time it took to process the coins. The team then decides how to improve the performance and tries again. It is recommended that you limit the game to 5 rounds to avoid fatigue.

The objective of the game: The team aims to turn over each coin once, in each workspace as fast as possible.

The objective should not be misinterpreted as “each worker turns over each coin once as fast as possible” . There is no 1 to 1 mapping between a worker and a workspace. This gives teams the opportunity to come up with a pairing or swarming strategy that may improve performance e.g. near the end of the round all workers who have nothing to do can join a work station where there is still work to be done.

The constraints
The game has soft constraints and hard constraints. The soft constraints are there for the team to change and to see the effect on performance. The hard constraints are there to make the game more challenging and to force certain behaviours. If you do change the hard constraints, change them after 4 or 5 rounds. The team can only make one change per round.

Soft Constraints
These constraints are enforced on the first round, after that the team can start changing or removing them.

  • The customer and product owner may only use their left hands
  • Batch sizes of 20 must be used

Hard Constraints

  • Only the customer can add coins to the system and removed them from the system
  • The complete batch must be processed before passing the batch on
  • Each batch must be the same size
  • The customer and workers may not pass batches to their neighbours sitting directly on the left or right, passing to the opposite neighbour is allowed. If you want to be cruel, don’t allow passing to opposite neighbours.
  • A worker can only turn one coin over at a time

Defects
A dropped coin is a defect, you can choose to collect the defects in a round or enforce a different penalty. If you would like to focus on the impact of defects you may want to use a higher penalty for defects  e.g. the worker needs to redo that batch. Obviously this introduces a new dimension to the game.

Stats
The more stats you can collect the better. In our exercise each of the 2 efficiency experts chose a worker to monitor. They kept track of how much time the worker spent turning coins i.e. waiting time was not counted.

Karl Scotland was kind enough to provide a spreadsheet with the Ball Flow Game. I used a modified version of this spreadsheet in this X Penny Game. I needed to alter it as the ‘batches’ are different in this game. In the ball flow game the batch is the amount of balls in the system, in this game batches of coins are passed around. Thus 3 batches of 10 coins each could be in the system at once. This difference is reflected in the how the stats are collected. You can download the spreadsheet from the home page of this blog, near the top right.

Whenever the customer added a batch to the system she yelled “in!”, when she received a processed batch she shouted “out!”. This helped me, the facilitator, to record when a batch went into or out of the system. The spreadsheet displays some interesting data and graphs.

The game in progress…

The team gathered around the table, as per the image above. I explained the rules and gave them a few minutes to plan the routes for the batches of coins.

I had previously sketched out paths I thought the team would use to pass the coins and it looked similar to this:

I introduced the ‘neighbour constraint’ to create two troublesome intersections. The plan is for those intersections to cause delays and mishaps. The ‘X’ shape is the reason I called this the ‘X Penny Game’.

Interestingly the team did not come up with those paths, they opted for this strategy:


Later I found out that I did not explain the rules clearly, the team thought they could not pass to opposite neighbours. This misunderstanding did not do any damage, it made things more challenging. You can choose which versions of the game you would like to try.

Round 1
Batches of 20
Left hand only
All the hard rules in place

These are the initial set of constraints enforced in round 1.

The results:

The first batch came back to the customer at 2:00 minutes. The total time was 3:45min. The first two batches went through the system the fastest. The batches were delivered at an average rate of every 30 seconds.

1 coin had dropped off the table and we noted this as a defect.

The efficiency experts said that worker X worked for 1:33min and worker Y was active for 1:35min.

The team said that they experienced major delays waiting for the first batch to arrive.

Round 2
Left hand only
All the hard rules in place
Change: Batch size of 10

The first batch was delivered at 1:04min, with a total time of 2:54. The average cycle time was about half of round 1. There were regular deliveries only 10 seconds apart. 

3 defects (dropped coins) occurred in this round.

The efficiency experts recorded worker X had worked for 2:00min and worker Y was active for 1:25min. 

The team noted that the total time was half that of round 1, even though worker X worked for 30 seconds longer. 

While looking at the stats, one of the team members pointed out a WIP of 60 coins. We were doing batches of 10 with 5 workers. We came to the conclusion that a queue must have formed. The stats recorded a 60 WIP on 4 occasions.

Round 3
Keep: Batch of 10
Left hand only
All the hard rules in place
Change: Don’t give coins to the next worker, unless they have an empty workspace

We discussed the new constraint “Don’t give coins to the next worker, unless they have an empty workspace”.  Some of us felt that this was now a pull system while others disagreed and felt more changes needed to be made before it was a true pull system. Personally I felt that it was a pull system as it looked like a Kanban system to me. We had WIP limits and the empty workspaces were visual indications that the worker required more coins.

The first batch arrived at 0:56min, the total time was 2:45. This was 9 seconds faster than the previous round, interesting given the small change made in this round.

There were 2 defects in this round.

Worker X was busy for 1:45 minutes with worker Y working for 1:36 minutes.

The team felt that this round was more organised and that there was less waiting.

The following graph shows the WIP and the total time of the first 3 rounds:

The throughput between round 2 and round 3 are intriguingly similar:

Round 4
Left hand only
All the hard rules in place
Keep: Don’t give coins to the next worker, unless they have an empty workspace
Change: Batch of 5

In this round, the first batch was delivered at 00:32min. The total time took ~2:50min. I don’t have the exact time, for some reason we only did 19 batches. None of us noticed this. The 19th batch was delivered at 2:43min. The throughput was impressive. On five occasions we had 2 batches coming through within the 10 second time span.

We encountered 4 defects.

The efficiency experts said worker X worked for 1:55, worker Y for 1:51.

The following graph overlays the WIP from round 3 with round 4:

In this case, moving from a batch of 10 to 5 seems counterproductive. Had we done all 100 coins, it may have taken longer than using batches of 10. This may have been due to the cost of moving coins from one workstation to the next. The team said this round felt more exhausting. This shows us that we don’t always benefit from reducing the batch size.

Round 5
Left hand only
All the hard rules in place
Keep: Don’t give coins to the next worker, unless they have an empty workspace
Change: Batch of 1

In this round the system ‘burst’. The first batch (coin) came in at 14 seconds. The throughput was about 4. By the time 8 coins had entered the system, we had recorded 7 defects. I could not keep up with the stats and called an end to this round.

The team noticed that while there was a high throughput, we also had a high defect rate and the pace was not sustainable. We could have made changes to make a batch of 1 more manageable e.g. limiting the number of batches\coins entering the system. Unfortunately we were not brave enough to try this batch size again.

Round 6
Batch of 5
Left hand only
Keep: Don’t give coins to the next worker, unless they have an empty workspace
Change: You can now pass to your direct left or right neighbour

This change allowed the team to simplify the routes the coins were passed along:

This simplification reduced the time and disruption of passing a batch on. We remarked that this was similar to reducing the cost of moving work between stages. For example, when a development team passes work on to a separate testing team, the testing team would also need to learn about the requirements of these new features. If one team developed and tested the work we could avoid this duplication of effort.

The first batch was delivered at 27 seconds and the total time was 2:18 minutes. No defects were recorded.

Worker X worked for 1.40 minutes and worker Y worked for 1.35 minutes. The team mentioned that worker Y was extremely consistent, almost always having a time of 1.35 minutes.  While we had a ‘new and faster’ system in place, there was no significant change in the average time spent working.

In this round the team felt that there was less waste in the system. They noted that they did better, even though people worked for the same period of time. One of the team members felt that they worked better in the first half of the round, the stats confirmed this.

A comment was made about the synchronicity that was achieved in this round. The team seemed to be working like clockwork. The team developed a natural rhythm or cadence. This is reflected in the consistent cycle time:

Round 7
Batch of 5
Keep: Don’t give coins to the next worker, unless they have an empty workspace
Keep: You can now pass to your direct left or right neighbour
Change: Right hand only

The first batch came in at 28 seconds, the total time was 2:19 min.

1 defect was recorded.

Worker X worked for 1.36 and worker Y worked for 1.35 minutes (again!).

We discussed why the team had done better with their left hands. The team said this was because they had now trained their left hands.

Additional Discussions and Observations

We have noticed that when we try to think of ways to improve performance, our ideas tend to involve increasing WIP e.g. introducing queues. Returning to this formula:

Flow Time = WIP/Throughput

Increasing the WIP may be counterproductive. We noticed this in round 2 and round 3. The only difference between the two round was that we waited for the next worker to have an empty workspace before passing on the batch. In round 2 there were times when we had a WIP of 60 while in round 3 the WIP did not exceed 50. Round 3 was completed 10 seconds faster than round 2.

The following graph shows the amount of time worked by worker X and worker Y mapped against the time it took to process all 100 coins in the different rounds:

I have included this to show that performance was improved due to changes in the WIP and process. The individual workers did not perform their work any faster.

What we didn’t try

Some team members suggested a pairing strategy, another suggested converting the efficiency experts into workers to increase the size of the team.

We did not try a batch of 1, with fewer batches in the system.

There was a discussion about using queues, this would be interesting to try.

It may be possible to send batches around in opposite directions, it would take some organisation but it is possible.

Again. these ideas suggest increasing WIP therefore they may be counterproductive. 

Improvements

We had a number of misunderstandings as I did not have the rules written down. Sometimes fuzzy rules lead to interesting results, sometimes they frustrate participants.

I would have liked to have spent more time gathering feedback from the participants. Next time I may hold less rounds to give more time for discussions.

Your Turn

You are welcome to try this with your team, I am keen to hear what results you observed…

About these ads

17 thoughts on “The X Penny Game

  1. @RickJ, we only tried this once so far. It sounds like people are keen to try it again.

    Please let us know if you have tried this…. Thanks, Daryn

  2. Hi
    Sound like an interesting improvement to the ball game. Could I ask you to send the modified spreadsheet to me?
    Best regards
    Jesper

  3. Great game, and an improvement to my current simulation used in my Lean training!

    Thank you!

  4. hi,
    Like the adaptaion of the ball flow game…feel a little dim, can you clarify
    ““The team aims to turn over each coin once, in each workspace as fast as possible” should not be misinterpreted. ‘Turning the coins over once in each workspace’ is different to ‘each worker turns the coins over once’. This allows team members to work together.”

    does this mean that each of the 100 coins need only be turned over 1 time ?
    or each coin must be turned over one time in each workspace ?

    confused :(

  5. @Cuan, sorry for the confusion I have not explained it properly. Your second assumption is correct – each coin must be turned over one time in each workspace.

    The point I am trying to make is that there is not a 1 to 1 mapping between a work space and a worker e.g. three workers may decide to work together at one work space, 1 worker may decide to do all the work at two work spaces e.t.c.

    This gives teams the opportunity to come up with a pairing strategy that may improve performance e.g. near the end of the round all workers who have nothing to do can join a work station where there is still work to be done.

    I updated the post to try and clarify that point…

  6. @Jesper, the spreadsheet is on its way to you!

    Please let me know if you would like a copy it…

  7. The spreadsheet is now available from links in the page and on the home page.
    Please let us know how your exercise went…
    – Daryn

  8. ah

    Now that does sound interesting…

    A practical question, do you in any way create a physical workspace ?
    also, is throughput measured when a coin has been tuned in each of the workspaces ?

    you mention a batch, is that all 100 coins ? so must all 100 coins be tuned over in 1 workspace, before any can be moved to the next workspace for processing ?

    Cheers
    Cuan

  9. @Cuan

    I did think about drawing a workspace in chalk or with tape. In the end I just explained that there are 5 workspaces and did some hand waving. A drawn workspace is likely to effect behaviour. if we had clearer workspaces we might not have developed a natural queue in round 3. Clearer workspaces may be a good idea if you are looking to push the pairing and swarming behaviour. I was very subtle with that but I will try to encourage this the next time I run this exercise.

    With regards to the batching. The 100 coins represent the total work which needs to be processed. We then divide that into equal batches of work. A worker needs to fully process a batch before passing it on.

    If you are using batches of 20, the customer passes the 20 to the first worker. Then that worker must turn over each coin before passing the batch of 20 to the next worker. The next worker starts turning over coins and the customer gives the first worker another batch of 20 to process.

    Thanks, Daryn

  10. A small point I forgot to add to the original post: Whenever the customer added a batch to the system she yelled “in!”, when she received a processed batch she shouted “out!”. This helped me, the facilitator, to record when a batch went into or out of the system.

  11. @Jo, thanks for the compliment. The software development industry is always looking to manufacturing for inspiration. I’m glad to give a little something back to manufacturing. I am keen to here the results of running this at Goodyear. If you get a chance to try this game, I would like to hear about it – I could even post an entry on your experiences.

    Thanks, Daryn

  12. If anyone would like a version with a summary sheet comparing the results of the 5 rounds as well as the ability to introduce expedite requests let me know.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s