This game is a co-creation by Renee Troughton and Craig Smith. It has had some minor tweaks through the years, originally starting off as Kanbanopoly (a game of chance based on a Monopoly like board) and has also been attempted as a simpler kids puzzle. This variation has been run over a dozen times.

Overview

The Sudokuban game is a quick 45 minute game to practice Kanban in a safe to fail environment where constraints have been setup to swiftly force work in progress limits to be hit. Built using pre-constructed sudoku puzzles, participants are encouraged to beat the other teams in the room and achieve the most value at the end of the timebox. The aim of the game is to get as many high value sudoku puzzles through to “Completed” as possible. The game is run once but can potentially be split into two rounds to allow for teams to retrospect and adjust WIP limits if they want. This game is normally done in a forty-five minute time block: 10 minutes upfront for instructions, 20 minutes for the game and 15 minutes for the debrief.

Materials and setup

Each team of 5 people requires the following:

  • SudokubanCards S1 – S12, two Expedites E1 & E2 (click the link to download the pack)
  • 10 headers: Expedite [1], Backlog, Dev [3], Doing, Done, Test [1], Doing, Done, Exec Review [1], Completed
  • A pen or pencil and eraser for each team member
  • Lots of wall space, preferably 3 meters per team.

The sudoku cards should be printed and cut out to include the story number and the value. Bluetak or a similar adhesive should be attached to the back of each sudoku puzzle. Similarly the headers will need to be able to stick to a wall. These can be simply a post it note or a system card with bluetak.

The setup time of preparing the puzzles and the wall space for the teams is generally as long as the effort to run the game itself.

Each wall should be setup with it’s ten headers and with the cards placed into the positions as indicated on the last page in the SudokubanCards pack. The game is deliberately setup so that the sequence of the puzzles is in order of the card number and not he value of the puzzle.

Kicking the game off

The instructor needs to walk the participants through one of the setup walls explaining the concepts of:

  1. What is a Work In Progress (WIP) limit and how they work – specifically calling out that the WIP limit for Dev [3] includes both the doing and the done columns; and that similarly the Test [1] includes the doing and done.
  2. How pulling works – that work cannot be pushed to ease the WIP issue, highlight that for example that they cannot push the item that has been QA’d into Exec Review.
  3. How expedites work – that they can break the WIP limit by one, but no more should be allowed

Additional instructions include:

  1. How to generally do a Sudoku puzzle
  2. For the purpose of the game, the instructor is also the Exec Reviewer
  3. That teams of 5 need to be formed – in each team there should be 3 Sudoku experts, 1 QA and 1 Scrum Master/Visual Leader. Any extra people in the room can be observers.
  4. That the purpose of the game is to generate the most value as possible by the end of the game

Once teams have formed and agreed to their roles kick off the game.

In progress

Once the room starts quietening down  and people get into the right head space the instructor shakes it up by providing the first Expedite to the Visual Leader. The team usually has capacity to take this on or you start seeing the Visual Leader pick up the work. Approximately one minute after a team member begins to work on the first Expedite the second one is handed to the Visual Leader with considerable pressure to get it done.

Care has to be taken (especially if team members take puzzles off the wall) to ensure that they keep to their WIP limits.

The game is deliberately setup to fail almost straight away. Puzzles S1 and S2 are both bugged along with both of the expedites. Teams will be forced to deal with the defects and not push work through the system in doing so.

Instructor Tips

  • This game is run mid-stream of a Kanban 101 rapid class. The matching slides can be found at: http://www.slideshare.net/AgileRenee/sudokuban but be aware that the Reporter role has changed into a Exec Review role and the game rarely requires a second round.
  • Whilst the game has a guide of being in play for 20 minutes, as long as the two expedites have been handed over the game can usually be cut shorter as long as all teams have a puzzle in “Completed” and one team has a good number of cards in completed.
  • Sometimes very ingenious people will download an app onto their smartphone which automatically solves the puzzles. Generally this should not be discouraged as it mimics the implementation of effort to automate and because the four unsolvable puzzles cannot be resolved by the apps. Ultimately teams will still be blocked which is the point of the game.
  • Whilst you could laminate the cards so that you don’t have to re-print them for future training sessions the cleaning time generally makes the effort similar.
  • Keep the instructor cheats hidden, but if someone asks for an external consultant or expert feel free to quickly give the solution to the error.
  • Sometimes team members will try to sneak unfixed puzzled through to Exec Review. Luckily instructors have the cheats to know where the errors are and to highlight that they are not valid, returning them to the Visual Leader.
  • Sometimes people will clue in that there are different shades of numbers and then ask if one of the shades could be wrong. It is worthwhile to give these teams hints that one shade has had it’s analysis done particularly poorly.

Debrief

At the end of the ten minutes the teams are then asked to reflect on what occurred in the game. Reflections that the instructor should ensure are brought to light are:

  • Did teams re-prioritise their backlog (and even in flight work) to ensure they were focusing on value?
  • For the teams that re-prioritised based on value did they achieve a better result?
  • How was the second expedite handled? What did it feel like to have an established policy where you could say “no” to push?
  • What did team members do when they couldn’t pull more work due to WIP limit constraints?
  • How much pairing/swarming occurred?
  • How quiet was the room?
  • Quality issues in puzzles and it’s impact on flow
  • Was there a need for a full time Visual Leader role? If not, what else did they get up to?
  • What did it feel like to not stop work on something that was hard and be forced to resolve it rather than just pull another item?
  • How did you handle work that failed QA – did QA try to fix it or did it go back in the flow and then break WIP?
  • Would you change the WIP limits?
  • Do expedites normally come in from management that are of seemingly little value?
  • What was the impact of the flow of normal work given the expedite?

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.