Here is my first contribution. Please use comments for questions and feedback. Below you will find a zip file with the files that make up the game, including these instructions. This version was updated November 9, '10. Thanks for playing!
Christina Skaskiw
Software Development Kanban Game
The aim of this game is to experience pull-scheduling and limiting work-in-progress (WIP) using a simple kanban system simulating a software development situation. It is intentionally simple and should not require more than an hour to an hour and a half to play. The game facilitator is assumed to be familiar with kanban, pull, and WIP.
Goal
A group of 5 players collaborate to collect as much “business value” as possible during a fixed set of rounds. The game can be played competitively.
Overview
The players implement Stories by rolling dice to see how much get done in each step. The steps are Planned, Analysis, Development, Test and Deployment. Each player plays a specific role: Business Representative, Analyst, Developer, Tester and Deployer. During a round, the players pull Story Cards into their step, roll the dice and distribute the dice score onto the pulled Cards for completion.
Each step is represented by a column on a kanban board. The maximum number of Stories allowed in each step is stated by its WIP-limit. The WIP-limit can be different for each step. Initially, there are no limits on WIP. During the game, the players can empirically observe the effects of different WIP-limits and adjust them to improve throughput.
The number of dice allocated represents the capacity of the step, or in other words, how much work that can get done. A step with two dice can expect, on average, to get twice as much done as a step with only one dice. The number of dice to be used in each step is limited (see the board layout below), but they can be redistributed to reflect a reallocation of resources. WIP-limits and numbers of dice are independent of each other.
The random outcomes by the dice represent the variability inherent in development.
The key to the game is to find the optimum WIP-limits and distribution of dice in order to maximize throughput while minimizing delay.
How to play the game
The Business Representative starts by adding one or more Story Cards to the Planned column. The Analyst then pulls one or more Cards into the Analysis column and rolls the dice. If the first Card says, for example, 6 in the Analyze box on the Card, and the Analyst rolls 5, he or she would indicate the level of completion by entering ‘5’ in that box, leaving one more for the next round before analysis is complete for that Story. If the Analyst rolls 7, only 6 would go onto the first Card, and the seventh point goes to the next Story.
After the Analyst finishes, it’s the Developer’s turn. If the Analyst completed a Story, this can be pulled in to Development by the Developer and he or she rolls the dice for development. If the Analyst did not complete, then there is nothing for the Developer to do. This is repeated for Test and Deploy.
Whenever a dice score cannot be fully used towards completing Stories, an opportunity to advance in the game is lost. This will happen either when there are not enough Cards to pull, or more Cards cannot be pulled because the limit for the step has been reached. If too many cards are brought onto the board, Stories will take longer to finish and will end up late. The group can change the limits in order to increase the throughput. They may make the change before starting a new round.
Round number | Planned
| Analysis Limit: ¥ Dice: 2 | Development Limit: ¥ Dice: 4 | Test Limit: ¥ Dice: 2 | Deploy Limit: ¥ Dice: 1 |
Changed dice: c Once c Twice |
|
|
|
|
|
A player pulls Cards first, and then rolls the dice. After a player has rolled the dice, no more Cards can be pulled. If two Cards are pulled and first Card says, for example, 6 in the Analyze box on the Card, and the Analyst rolls 8, he or she would indicate the level of completion by entering ‘6’ for analysis on the first Card, and ‘2’ would be allocated to the second Story. (Tip: circle or cross over the number on the Card to indicate that the step has been completed.)
The capacity of each step is represented by the number of dice that step can use towards completing. The group may redistribute the dice between the steps if they so choose, but they may only do this twice during a game. The decision to redistribute can be made before starting a new round. They may not add more dice.
The group may change limits and redistribute dice at the same time or at different times.
Note that it is not allowed to “push” Stories downstream in order to make room for more Cards in your own step; this is a violation of the WIP-limit.
The group tracks the rounds by making a note on the board of which round they are at in the beginning of each round. The Business Rep can be given this task. When a Story Card is pulled into the Analyze column, the Analyst marks the number of the round on the Card. From this point on, the Story has to be completed in 4 rounds. If it is late, 50% is deducted from the business value for the first late round, 75% if two rounds late, and no business value is awarded if completed more than two rounds late. If a Story enters Analysis in round 4 and completes in round 7, it is on time. If it completes in round 8 it is one round late. The task of entering ‘round completed’ and ‘business value’ can be given to the Deployer.
At any time, the groups can be given an Expedite Story by the game facilitator. Expedite Stories have to be completed in 3 rounds, and yield no business value if they are completed late. An Expedite may break the WIP-limits.
They game is concluded after 20 rounds. The group with the highest accumulated score wins. (It can also be time-boxed, but that may reward the team that plays without thinking, instead of the team that gets a good discussion going; it’s for learning after all.)
Preparation
Print and cut out the Story Cards. You need one set per group. Consider using different colored paper to keep them separate.
Print and cut out the Expedite Story Cards, one set per group, and retain them for surprise distribution. If many groups are playing, they should all receive the same Expedite Story at the same time.
Print the Rules and the Round description for each group as reference.
If you don’t have the use of a projector, print copies of the slide showing the board layout to give out to the groups. (Or you could create all the flip chart boards in advance.)
Acquire 5 dice per group. They will also need pens to score with.
Game setup
Explain the game.
Divide into groups. Decide who is going to be in which role: Business Rep, Analyst, Developer, Tester and Deployer. In case a group is short of people, a person can have two roles. If you have too many, one person could be in charge of calculating business value, or double up with another role.
Give out flip chart papers and markers. Project the kanban board layout slide (or distribute the printed copies) and have the group draw up their board.
Hand out the Rules and Round descriptions.
No one gets to see the Story Cards in advance. The game begins when the Cards are distributed. Have all groups start at the same time. If timing the game, start timing now.
Helpful hints to the game facilitator
The best WIP-limits are probably two across the board, if there is a good mix of smaller and larger stories. Dice are best distributed with two for analysis, three for development, three for test, and one for deployment.
If Stories start to come in late, the best thing to do is reduce the limit in analysis to one until Stories are on time again.
The loss of 50% of business value, if late one round, may or may not be reflective of the real world of the players. Because of the emphasis of shortening lead time in Lean Software Development, the game punishes lateness severely. The players will find that they are rewarded by focusing on getting Stories through quickly, and that lost dice points is almost incidental, which reflects the idea that throughput is more important for productivity than utilization. This can be a discussion point after the game in relating the behaviors of the game back to real development.