In Part 1 of this two parter, I outlined the premise of Scrum City and some of the planning required (in the context of running the game as part of the tutoring work I do for QUT’s Agile Project Management course). Go read that if you want more information, but at a high level Scrum City is an education game that demonstrates many of the principles and practices of Scrum.

The last post outlined the beginning of the activity:

• Communicating the vision, i.e. “I want a city! In lego! Make it awesome!”
• Eliciting requirements, i.e “What features do you want in your model?”
• Estimation, i.e. “Just how much will this cost me?”
• Prioritization, i.e. “I want this before this, but after this”

With the above preparation out of the way, all that’s left is the delivery, and as everyone already knows, delivery is the easiest part...

Executions Can Be Fun

At this point, each team participating in the game (for me that was the two opposing sides of the classroom), should have a backlog. Each backlog item (some feature of the city) should have appropriate acceptance criteria, an estimate (in story points) and some measure of how important it is in the scheme of things. If the team is bigger than 5 people (mine were, each had about 25 people in it), you should also break them down into sub-teams of around 5 people (it will make it easier for the teams to organise their work).

Scrum City consists of 3 iterations of around 20 minutes each. For instructive purposes, the first iteration usually goes for around 30 minutes, so that you have time to explain various concepts (like planning and retrospectives) and to reinforced certain outcomes.

Each iteration consists of 3 phases; planning, execution and retrospective, of length 5, 10 and 5 minutes respectively. Make it very clear that no resources are to be touched during planning/retrospective and that work not present in the delivery area (i.e. the city) at the end of an iteration will not be accepted.

All told, you can easily fit the second half of Scrum City into a 90 minute block (leaving some time at the end for discussion and questions).

Obviously you will also need some physical supplies like lego, coloured pens/pencils and paper. Its hard to measure lego, so just use your best guess as to how much you’ll need, then double it. It doesn’t hurt to have too much lego, but it will definitely hurt to have too little. A single pack of coloured pens/pencils, 10 sheets of A4 paper and a single piece of A2 will round out the remaining resources required.

Don’t Fire Until You See the Whites of Their Eyes

Each iteration should start with a short planning session.

The goal here is to get each team to quickly put their thoughts together regarding an approximate delivery plan, allocating their backlog over the course of the available iterations. Obviously, 5 minutes isn’t a lot of time, so make sure they focus on the impending iteration. This is where you should reinforce which items are the most important to you (as the product owner) so that they get scheduled sooner rather than later.

Of course, if the team insists on scheduling something you don’t think is important yet, then feel free to let them do it and then mercilessly reject it come delivery time. Its pretty fun, I suggest trying it at least once.

With priorities and estimates in place from the preparation, planning should be a relatively smooth process.

After each team has finished, note down their expected velocity, and move onto the part where they get to play with legos (I assure you, if people are even the tiniest bit engaged, they will be chomping at the bit for this part).

Everything Is Awesome!

The execution section of each iteration should be fast and furious. Leave the teams to their own devices, and let them focus on delivering their committed work (just like a real iteration).

You will likely have to field questions at this point, as it is unlikely the acceptance criteria will be complete (which is fine, remember stories are invitations to conversations, not detailed specifications).

For iterations past the first, you should complicate the lives of the teams by introducing impediments, like:

• In iteration two you should introduce an emergency ticket. You’ve decided that it is a deal breaker that the city does not have a prison (or other building), and you require some capacity from the team to prepare the story. You can then require that this ticket be completed during the next iteration.
  • Interestingly enough, the scrum master of one of my teams intercepted and redirected my attempt to interrupt one of his sub-teams with the prison story. It was very well done and a good example of what I would expect from a scrum master.
• In iteration three, you should pick some part of a teams capacity (pick the most productive one) has all come down with the bubonic plague and they will not be available for the remainder of this iteration.

Once the team runs out of time (remember, 10 minutes, no extensions, tightly timeboxed), its time for a showcase.

That means its time for you, as product owner, to accept or reject the work done.

This is a good opportunity to be brutal on those people who did not ask enough questions to get to the real meat of what makes a feature acceptable. For example, if no-one asked whether or not a one storey house had to be all one colour, you can brutally dismiss any and all houses that don’t meet that criteria.

The first iteration is an extremely good time to really drive the importance of acceptance criteria home.

Once you’ve accepted some subset of the work delivered, record the velocity and explain the concept so that the teams can use it in their next planning session. Most groups will deliver much less than they committed to in the first iteration, because they overestimate their ability/underestimate the complexity of the tickets, especially if you are particularly brutal when rejecting features that don’t meet your internal, unstated criteria.

Think Real Hard

After the intense and generally exhausting execution part of each iteration, its time for each team to sit back and have a think about how they did. Retrospectives are an integral part of Scrum, and a common part of any agile process (reflection leading to self-improvement and all that).

Being that each team will only have around 5 minutes to analyse their behaviour and come up with some ways to improve, it may be helpful to provide some guided questions, aimed at trying to get a single improvement out of the process (or a single thing to stop doing because it hurt their performance).

Some suggestions I’ve seen in the past:

• Instead of waiting until the end to try and delivery the features, deliver then constantly throughout the iteration.
• Allocate some people to organising lego into coloured piles, to streamline feature construction.
• Constantly check with the product owner about the acceptability of a feature.

Ideally each team should be able to come up with at least one thing to improve on.

The Epic Conclusion

After a mere 3 iterations (planning, execution, retrospective), each team will have constructed a city, and its usually pretty interesting (and honestly impressive) what they manage to get accomplished in the time available.

The two pictures below are the cities that my tutorial constructed during the activity.

S1 2016 Scrum City

Scrum City is a fantastic introduction to Scrum. It’s exceptionally good at teaching the basics to those completely unfamiliar with the process, and it touches on a lot of the more complex and subtle elements present in the philosophy as well. The importance of just enough planning, having good, self contained stories, the concepts of iterative development (which does not mean build a crappy house and then build a better one later, but instead means build a number of small, fully functional houses) and the importance of minimising interruptions are all very easy lessons to take away from the game, and as the organiser you should do your best to reinforce those learnings.

Plus, everyone loves playing with lego when they should be “working”.

The Agile Project Management course that I tutor at QUT (now known as IAB304) is primarily focused around the DSDM Agile Project Framework. That doesn’t mean that its the only thing the course talks about though, which would be pretty one sided and a poor learning experience. It also covers the Agile Manifesto and its history (the primary reason any of this Agile stuff even exists), as well as some other approaches, like Scrum, Kanban and the Cynefin Framework.

Scrum is actually a really good place to start the course, as a result of its relative simplicity (the entire Scrum Guide being a mere 16 pages), before delving into the somewhat heavier handed (and much more structured/prescriptive) DSDM Agile Project Framework.

Of course, Scrum fits in a somewhat different place than the Agile Project Framework. Scrum is less about projects and more about helping to prioritise and execute a constantly shifting body of work. This is more appropriate for product development rather than the planning, execution and measurement of a particular project (which will have its own goals and guidelines). That is not to say that you can’t use Scrum for project management, its just that it’s not written with that sort of thing in mind.

Often when tutoring (or teaching in general) it is far more effective to do rather than to tell. People are much more likely to remember something (and hopefully take some lessons from it), if they are directly participating rather than simply listening to someone spout all of the information. A simulation or game demonstrating some lesson is ideal.

Back in September 2014 I made a post about one such simulation, called Scrumdoku. In that post, I also mentioned a few other games/simulations that I’ve run before, one of which was Scrum City.

It is Scrum City that I will be talking about here, mostly because its the simulation that I just finished running over the first two tutorials of the semester,

A City of Scrums?

The premise is relatively simple.

The mayor of some fictitious city wants a scale model of their beloved home, so that they can display it to people and businesses looking to move there.

Those of you familiar with the concept of a Story will notice a familiar structure in that sentence.

As a (mayor), I want (a scale model of my city), so that (I can use it to lure people and businesses there).

Like all good stories, it comes with some acceptance criteria:

• All items in the model must be made out of lego.
• Roads, lakes and other geographical features may be drawn.
• The model must fit on a single piece of A3 paper.

Now that I’ve set the stage, I’ll outline the process that I went through to run the game over the first two tutorials.

Breaking Up Is Hard

I have approximately 55 students in my tutorial. For most of the work during the semester, I break them into groups of 5 or less (well, to be more accurate I let them self-select into those groups based on whatever criteria they want to use).

For Scrum City, 11 groups is too many. For one thing, I don’t have that much lego, but the other reason is that acting as the product owner for 11 different groups is far too hard and I don’t have that much energy.

The easy solution would be to try and run one single Scrum City with all 11 teams, but the more enjoyable solution is to pit one half of them against the other. Already having formed teams of 5 or less, I simply allocated 4 of the larger teams to one side and the remaining teams to the other.

Each side gets the same amount of materials, and they both have approximately the same number of people, so they are on even ground.

The Best Laid Plans

The very first thing to do is to get each group to elect/self-select a Scrum Master. For anyone familiar with Scrum, this is a purely facilitative role that ensures the Scrum ceremonies take place as expected and that everyone is participating appropriately. It helps to have a Scrum Master, even for this short activity, because they can deal with all the administrative stuff, like…

The creation of the backlog.

Creating the backlog is a good opportunity to explain how to create a good story, and the concept of acceptance criteria. Each group needs to figure out a way to farm out the production of around 40 stories, each describing a feature that you (as the mayor) wants to be included in the model. Participants should be encouraged to ask questions like what it means for a one story house to be done (i.e. how big, to scale, colour, position, etc) and then note down that information on an appropriate number of index cards (or similar).

Each backlog should consist of things like:

• 5+ one storey houses (as separate cards)
• 5+ two storey houses (again, separate cards)
• 5+ roads (of varying types, straight, intersections, roundabout, etc)
• hospital
• stadium
• statue
• bridge
• police station
• fire station
• …and so on

It doesn’t actually matter what elements of a city the stories describe, it’s whatever you would prefer to see represented in your city.

Spend no more than 30 minutes on this.

As Big As Two Houses

Once the backlog is complete, its time for the part of planning that I personally hate the most. Estimation.

That’s not to say that I don’t understand the desire for estimates and how they fit into business processes. I do, I just think that they are often misinterpreted and I get tired of being held to estimates that I made in good faith, with a minimum of information, in the face of changing or misunderstood requirements. It gets old pretty quickly. I must prefer a model where the focus is on delivery of features as quickly as possible without requiring some sort of overarching timeframe set by made up numbers.

Each group will be responsible for ensuring that every story they have is estimated in story points. A lot of people have trouble with story points (especially if they are used to estimating in hours or days or some other measure of real time), but I found that the students were fairly receptive to the idea. It helps to give them a baseline (a one storey house is 2 points) and then use that baseline to help them establish other, relative measures (a two storey house is probably 4 points).

There are a number of different ways to do estimation on a large number of stories, but I usually start off with Planning Poker and then when everyone gets tired of that (which is usually with a few stories), move over to Affinity Estimation.

Planning Poker is relatively simple. For each story, someone will read out the content (including acceptance criteria). Everyone will then have a few moments to gather their thoughts (in silence!) and then everyone will show their estimate (fingers are a good way to this with a lot of people). If you’re lucky, everyone will be basically in the same ballpark (+- 1 point doesn’t really matter), but you want to keep an eye out for dissenters (i.e. everyone things 4 but someone says 10). Get the dissenters to explain their reasoning, answer any additional questions that arise (likely to clarify acceptance criteria) and then do another round.

Do this 2-3 times and the estimates should converge as everyone gets a common understanding of the forces in play.

Planning Poker can be exhausting, especially during the calibration phase, where there is a lot of dissent. Over time it usually becomes easier, but we’re talking weeks for a normal team.

Once 3-4 stories have been estimated using Planning Poker, its time to switch to Affinity Estimating.

Spread out all of the unestimated stories on a table or desk, place stories that have been estimated on a wall in relative positions (i.e. the 2 pointers at one end, 10 pointers at the other with room in between) and then get everyone in the group to silently (this is important) move stories to the places where they thing they belong, relative to stories with known estimates. Everyone story should have an estimate within about 5 minutes.

Keep an eye on stories that constantly flip backwards and forwards between low and high estimates, because it usually means those stories need to be talked about in more detail (probably using Planning Poker).

Affinity Estimating is an incredibly efficient way to get through a large number of stories and give them good enough estimates, without having to deal with the overhead of Planning Poker.

Again, spend no more than 30 minutes on this.

What’s Important To Me

The final preparation step is prioritization.

Luckily, this is relatively simple (and gets somewhat repeated during the planning sessions for each Scrum City iteration).

As the mayor (i.e. the product owner), you need to provide guidance to each team as to the relative importance of their stories, and help them to arrange their backlog as appropriate.

Generally I go with basic elements first (houses, roads, etc), followed by utilities (hospital, school, police station, etc) followed by wow factor (statue, stadium, parks, lake, etc). Its really up to you as product owner to communicate the order of importance.

You can (even though it is not Scrum) introduce the concept of MoSCoW here (Must Have, Should Have, Could Have, Won’t Have) and label each story appropriately.

The most important thing to have at the end is some measure of the priority of each story, so that when the teams start planning for their iterations, they can create a basic delivery plan taking your preferences into account.

Because the prioritization is less of a group activity than the others, you only really need to spend around 10-15 minutes on this.

To Be Continued

This post is getting a little long, and I’m only about half way through, so I’ll continue it next week, in Everyone Loves Lego: Part 2.

There will even be pictures!

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.