Teaching simulation (aka board game)
The Flow Game
‘Work in progress’ (WIP) limits can be counterintuitive if you have never experienced their effects. To help teach and illustrate the benefits of WIP limits, I have created a physical simulation, i.e., a board game. The game is simple enough that anyone can participate but complicated enough that the results are surprising.
Let’s jump straight into the game and then explain pitfalls and spoilers afterward.
Setting up the game
To play the game, we need:
- 3–9 players, and optionally a facilitator
- Two regular dice per player
- 200+ tokens (we use jigsaw puzzle pieces)
The players are seated in a sequence where they can reach their two neighbors. The area between each pair is called the buffer. From a player’s perspective, the buffer toward the first player in the sequence is called the input buffer, and the other is called the output buffer. One player’s output buffer is another player’s input buffer. Before the first player is a container with all the tokens, and after the last player is an empty container.
There are three rounds, each consisting of a number of beats. The process of a beat is:
- Everyone rolls their dice.
- Everyone picks up as many tokens from their input buffer as the dice show. If there are not enough tokens, you pick up as many as possible. Hold the tokens in your hand.
- When everyone is ready, the facilitator says “put,” and everyone puts the tokens in their output buffer simultaneously.
Before starting the game, we need to initialize the buffers and ensure everyone understands the beats, so we run one beat for each player — if there are five players, we do 5×(roll→pick→put).
Round 1
Now we are ready to begin round 1. The goal of the round is to move tokens from the input container (with a lot of tokens) to the output container (empty at the beginning of a round). Each round starts with the players predicting how many tokens they will move per beat.
The first round is simple because, after the predictions, we run one beat per person again.
After all the beats, we evaluate. Count how many tokens made it to the output container and check how accurate the predictions were. Empty the output container into the input container.
Round 2
The first round simulated work flowing between silos in an organization where we don’t work together. The silos could be departments, teams, or individuals, so long as we have work moving from one to the other. A classic example would be: design, then implementation, then testing, then security, then deployment.
In the second round, we add teamwork. Between each beat, the players can discuss and move around the dice however they want before they roll.
Otherwise, the round proceeds like the first: predictions, one beat per player, then evaluation.
Round 3
The second round simulated something like Scrum, with much time spent coordinating and discussing what is best without any real chance of finding an optimal dice assignment.
In the third and final round, we add WIP limits. The players collectively come up with some limit, usually around the 9–14 size. Our output buffers may not exceed this limit. To solve this, we add a ‘bubble-back’ step to each beat:
4. While an output buffer is above the WIP limit, move the overflowing tokens back to the input buffer. Notice this can cause the input buffer to overflow, in which case we repeat this step.
We also replace the discussion with a fixed rule: if your output buffer is full, give one of your dice to the next player in the sequence. If your input buffer stops being full, give one dice (back) to the previous player in the sequence. Again, if multiple buffers in a row are full, the middle players will both give and get a dice.
Otherwise, the round proceeds as usual: predictions, then one beat per player, then evaluation.
Game epilogue
The third round simulated something like Kanban, focusing on exposing bottlenecks and alleviating them. At this point, I like to give players a summary of The Goal and the Toyota Production System.
The game satisfies the two prerequisites of the Theory of Constraints:
- Sequentially linked workstations
- Statistical fluctuations
Those are the exact rules of the game. Therefore we have emergent properties and unpredictability. Discussions are great for dealing with exceptional situations, such as emergencies. However, in environments where humans cannot predict what will happen, discussions are unlikely to yield optimal results. In addition, meetings take an enormous amount of time, which is fine for rare situations but wasteful if it happens often. Building a remediation mechanism into the system is much more helpful in this environment, i.e., the WIP limits and dice motion.
Discussion
Usually, each round produces improvements in terms of how many tokens are produced, in time saved, or both. The conclusion I typically want the teams to reach is that when they get stuck, for whatever reason, they don’t open up a new ticket. Instead, spend your time helping someone else with their work, like giving them one of our dice. One head can work on one thing at a time, so a team should never need more open tickets than they have heads. This is our WIP limit.
Team productivity is the theme of the whole second part of my book, so if you care about that, you should check it out:
