0 Comments

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”.