1. Introduction and explanation of the game (20min)
2. First round (60min)
3. Retrospective (10min)
4. Second round (60min)
5. Retrospectives / Share the findings (30min)

After explaining, attendees will form teams of 4-6 person each. Each team can use prepared set of tasks or create their own set, if they can do in short time. I’ll provide two sets for choosing: one is developing a mail client (MUA), the other is some non-software project (I usually use house renovation in Japan.)

Each team will choose their stories and tasks for the iteration, without really knowing how much they can finish in the period. Sounds familiar? Sometimes a member ‘draws’ a problem and must find a solution to make a progress on her task. Should others in the team try to help the poor coworker? Or, hoping she can take care of herself, concentrate on finishing their own tasks to maximize team’s output? You may try your strategy in the game and the outcome will be visible immediately.

Is it a good thing to let your architect handle all technical problems? How small (or large) tasks should be split? What if tasks have significant dependency? The game lets you experiment and give you findings which is realistic to some degree. (You know, this is just a ‘game’ and there is a reson why I named it game. This game is easy to learn, intentionally lacking many factors, yet still retaining the feeling of using Kanban, and fun :-)

Each team will play the game by themselves supported by experienced friends who will come with me. After each round, each team will do retrospective (I’ll recommend and guide Keep/Problem/Try framework) and after two rounds, every teams are encouraged to share their experience and findings with others.

Usually a single game (simulating two 1-week iterations) takes an hour. Attendees will be given second chance to do better on similar project, after a retrospective.

The game has a set of defined rules but teams are allowed to extend the rule to make their experience deeper.