# The Coin Game

By Zsolt Fabók

Today’s post is about the Coin Game. It is a repetitive group game in which the players have to move a heap of coins from one part of the table to another by passing the coins to each other. Additionally, when a player receives a coin, she has to turn it over once. The aim of the game is to have the coins lay heads up after the last player has finished. Each round starts with a quick discussion about the group’s strategy: how many coins can be passed at once (batching), how many coins can be at a player at a time (WIP and inventory handling), and whether the players give the coins to the next player (push system), or the next player has to take it (pull system). They measure the time they need to move the coins and the game ends when the group finds the best strategy which leads to the shortest completion time. This game is really great to highlight the benefits of the pull system and to allow participants to practice the deliberate and data based batch size setting and inventory handling.

The game starts with the setup: the players sit or stand around a table and lay a certain amount of coins on the table to the right side of one of the players. Some of the coins lay heads up, others tails up. The game goes clockwise: the coins arrive at a player from her right and leave at her left side. The newly arrived coins are at the right side, the middle is the working area where the player turns over the coins, and the left side is where the overturned coins are kept. These are the inventories of a player. If the group is using a push strategy, the player puts the overturned coins into the right inventory of the next player, in case of a pull strategy, the player takes the coins from the left inventory of the previous player. All the coins in an inventory should face the same direction. If this is not the case, the player must throw back the coins to the right inventory of the previous player.

The role of the first player is special. The coins in her right inventory aren’t facing the same direction, so she won’t turn over each coin, however she should figure out which direction the coins should face in her left inventory so that they will face heads up in the left inventory of the last player.

We played the coin game at the first event of the Budapest Lean and Kanban Meetup (now limitedwipsociety.hu). The first round started rather quickly and the group decided to move all the pieces together. Their lead time was 2 minutes and 40 seconds. The group wasn’t satisfied with this result and had a long discussion about what went wrong. They learned that while one station was very busy - especially the last one - the rest of the group was idle, and that put too much pressure (mura) on that specific station, and errors were made: not all the coins were flipped and they had to be moved back. So they realised that they needed a different batch size.

The conclusion was a bit surprising, because most of the groups would have chosen 1 as the batch size, but this group chose 2. The result spoke for itself: 1 minute and 26 seconds. The group got more engaged in the game, and started experimenting with different batch sizes. The next candidate was 6 (unfortunately I don’t recall why). With this setting the lead time was a surprising 1 minute and 10 seconds. It was interesting that a larger batch size actually decreased the lead time. One of the group members argued that the batch size had less effect on the lead time. According to him, the group learned how to play the game and gained more experience, and that was the reason of the shorter lead time.

In order to validate his hypothesis, the team did another two rounds with the same batch size of 6 and with a batch size of 1. In the first case the lead time was almost the same as in the previous round - 1 minute and 11 seconds -, however, with a batch size of 1 it was 1 minute and 40 seconds. The hypothesis had been refuted: regardless of the batch size more experience should have decreased the lead time which didn’t happen. That member accepted the fact that the batch size matters more than the experience. It seems that data can really change opinions.

I can only recommend this game, because it is fast and it teaches the basics of the Kanban method: the pull system, the batch and inventory handling, and improving the flow with continuous improvements and experiments. You can see from the example above that a round was quite quick and the discussion about the next strategy was never longer than 5 minutes. Of course the game is an excellent opportunity to learn how to handle WIP limits and inventories. If you would like to do that, just add a constraint to the game: the size of the batch must be 1. Happy gaming!