Scrumdoku!

One of the most common ways to communicate the principles of the various Agile software development methodologies is games. I like to think that this is because the Agile software development methodologies are more like games than the others, focused more on the team, the overall goal and responding to change, rather than following some meticulously planned process that “guarantees” success. Jeff Patton presented a nice talk that incorporated those elements at his Yow! 2013 talk (which is well worth watching).

I’m sure there are a lot of games that people use to teach the principles of Agile development methodologies, I’m aware of (and have run) two, Scrum City and the Lean Manufacturing Game (which might actually be called the Lego Lean Production Game). I ran both of these games in the workshops for the new Agile Project Management course at QUT (Semester 2 2014, INB123, replacing the Prince 2 Project Management course), and they proved to be quite effective in communicating critically important elements of Agile to the students. It helped that they were also fun and very physical, which helps engagement.

A fellow tutor for the Agile Project Management course (Andrew McIntyre, the great and powerful) came up with the idea for another game, teaching elements of Scrum using Sudoku puzzles. The other tutors and I helped him flesh it out a bit, and we then used our poor students as test subjects to see how it worked out in reality.

It was awesome! Also hilarious.

And thus Scrumdoku! (don’t forget the exclamation point) was born. At a high level, the game is focused around teaching planning and the optimisation thereof, where teams have to maximise the value of delivered Sudoku puzzles over some number of iterations.

Materials

50+ individual Sudoku puzzles.

Standard 9x9 is easiest. I found the generator available at http://www.opensky.ca/~jdhildeb/software/sudokugen/ to be perfect for this. You’ll want about 60% Easy, 20% Medium, 15% Hard and 5% Very Hard. I needed 4 copies of each puzzle, as my workshop had 4 teams of approx. 8 people each. Make sure you get solutions.

Pens/pencils, depending on how confident the teams are. One for each person.

Erasers (highly recommended). Again, one for each person.

Willing Participants (obviously).

Rules

3 Iterations. I used 7 minutes planning/retrospective, 20 minutes work. Make sure you timebox aggressively.

Make sure you leave enough time to actually complete a Sudoku puzzle. 20 minutes felt a little long, so maybe try 15? Experiment and see what feels best for you.

During planning each team will commit to some set of puzzles, of their choosing.

Completed and correct puzzles are worth an amount of points relative to difficulty.

The generator I linked has Easy, Medium, Hard, Very Hard. I used 2, 5, 8 and 13 for value.

Incomplete or incorrect puzzles are worth nothing, and are lost forever.

Participants may choose to mark a puzzle as “Must Have”, in which case it will be worth double points if completed. However, if not completed or incorrect it will be worth double negativepoints.

No electronic solvers.

There’s some amazing Sudoku solvers available on phones/tablets now. Just snap a picture and the solver will tell you what numbers go where. Speaking of Sudoku solvers, Peter Norvig has a fantastic article on writing a Sudoku solver. Go read it, its great.

Optional Rules

These rules can add a hilarious…I mean “educational” element of stress to the game. Use as you see fit.

• Incorrect puzzles previously delivered can be reintroduced later as “bugs”, which must be fixed before any other work, and are worth nothing.
• Reserve some of the puzzles for “expedite” challenges. During the middle of an iteration throw one of these puzzles at the team, and tell them that it must be completed before the end of the iteration or their score for the iteration will be zero.
  • This can have some interesting side effects, as if the team has over-committed with a large number of “Must Haves” they can choose to intentionally fail the expedite challenge and zero out their scope, saving them from a large negative score. One of my teams actually did this, and I totally didn’t see it coming.
    
    

Instructions

Make sure to setup one area for each team involved in the game. Separate the planning area from the working area, like in the following (terrible) diagram.

Note that where I have said “puzzles”, that’s the planning area.

Start by introducing the teams to the rules (not the optional rules though, they shouldn’t see them coming, for maximum effect). Give them maybe 5 minutes to discuss and ask you questions. Don’t spell everything out, let them be responsible for getting to the detail by encouraging good questions.

At that point, show a nice visible timer (http://www.online-stopwatch.com/ isn’t bad) with 7 minutes on it, and tell them their planning time has started. No puzzles can be started until the planning time has finished. Note down what each team has committed to, and which puzzles (if any) are marked as “Must Have”. I found it most helpful to mark the puzzles themselves, much easier to keep track of later when marking, but make sure you also note down their commitments in some public place, like a whiteboard. I used a simple table on a white board, and a simple notation of:

[Puzzle Number] [Difficulty] [Optional: Must Have] [Correct]

27 M ! [Tick] would indicate that puzzle 27, which was a Medium, was marked as a Must Have and was correct.

Once planning has completed, start the timer for execution (20 minutes is pretty good) and let them get started.

Once that timer expires, collect all of the puzzles (regardless of state) and start the timer for 7 minutes for planning and retrospective. While the teams are planning, mark the puzzles, and note down the cumulative score for each team in some publically visible place. The quicker you do this, the quicker the teams can have feedback on how they are doing. Ideally, it should be before their planning finishes, although even without marking the teams will have some idea about how they went.

Planning/retrospective time up, iteration time start.

Rinse and repeat until done.

Have a prize for the team with the best score. Its always a fun note to end the activity on.

Observations

As with everything in life, people are bad at estimating, even when the estimating is implicit. Teams will almost certainly massively over-commit in their first iteration and then commit to a more reasonable amount in the second, quickly establishing what they are able to accomplish in the time provided. The interesting point here is that Sudoku puzzles are basically the same, even though they vary in difficulty. After the first 2 iterations, the teams will probably still not be all that great at estimating, but they will improve. Software, unfortunately, rarely conforms to the same sort of pattern as the Sudoku puzzles, which means that you may never see software development teams be able to make accurate estimates. I’ve been trying to estimate software for years now, and while I’m definitely better than I used to be, the most important element to delivering on time, is to have flexibility in what you deliver, not in getting the estimates perfectly accurate.

Other observations:

• You may see a participant assume a command and control role, deciding what will be done and assigning out work in the first iteration, which may or may not work.
• Some teams will establish themselves a mini-backlog and work through that in priority order (those teams are awesome).
• People may try to cheat, by saving partially completed puzzles in one iteration so they can continue to work on them in the next (that’s why you note down the committed puzzles publically).

Summary

Like most of the various Agile training games, the game allows for two main outcomes.

One, it teaches Agile principles to the participants (which you should reinforce at the end with a summary). The participants don’t even need to know the principles beforehand, the activity itself can be a great way to introduce them.

Two, it allows you to watch participant behaviour. Watching the way people react to situations can tell you a lot about them, which you can then leverage later on. If you play this game after introducing Agile concepts, you will easily be able to see those who took them to heart (in comparison to the people who just fall back to their old ways).

Also its fun to watch people squirm.