Bamboo Blog

At Scrum Gathering we presented a lego game that we use to teach prospective clients about agile projects. We've run this game twice internally and once with live clients. There's quite a detailed structure below, but running the game involves a lot of improvisation; really, it's about throwing up the same set of obstacles both times, and showing how an agile approach makes them less painful.

Materials

• Box of lego
• Specification document
• Pile of story cards
• Pile of fake cash

Players

One trainer, 3-6 players

Run 1: Waterfall

Estimation phase (2 mins)

Give the players the Specification. Ask them to agree on an estimate (2 mins). Then ignore the estimate and write the actual phase timings (10 min / 2 min) on the Specification.

Build phase (10 mins)

Give the players some of the lego bricks and ask them to start building. Halfway through the build phase, give them the rest of the lego bricks. Two minutes before the end, announce that the deadline has been shortened by one minute. Make the process of getting answers to questions difficult and time-consuming - for example, questions and answers must be in writing. Stand on the other side of the room.

Acceptance testing (2 mins)

Look for symmetry, colourscheme, size, etc. Find some defects:

• Wheels? ("it's a plane.. how will it land? you should have inferred it from the specification")
• Pick a colour (eg red) that's retrospectively not allowed ("it's not in the spec? But we never use red. Marketing hates it.")
• Announce an "emergency rebuild, since the project is late".

Emergency rebuild (2 mins)

Final Assessment

Add up fines for defects at £100M per minute late (which is actually wrong, and may provoke contract arguments), and £50M per defect. Hand over the remaining cash.

Run 2: Scrum

Initial planning (2 mins)

Join the players. You'll be playing as both SM and PO. Hand them the story cards, along with a statement of vision. Help them move the cards into swim lanes and write estimates on them, then plan the first 3-minute sprint.

Sprint 1 (3 mins)

As soon as a player reaches for a red brick, stop them - no red in the project.

Aggressively done-done test work in progress.

At the end of the sprint, hand over cash ("value delivered") for stories which are complete. Add some additional story cards (eg "inflight movies").

Sprint 2 (3 mins)

As before, but when planning Sprint 3, note that it will only be two minutes and that it will be the last sprint for now.

Make extra bricks available for sprint 3.

Give cash for both new stories, and previously-completed ones which are in production and earning money.

Sprint 3 (2 mins)

Reflect

Allow the players to compare and contrast. Some things they might notice:

• The scrum team still spent lots of time planning. It was just divided up.
• The scrum team needed _more_ customer interaction. This is key - it all hinges on the PO.
• The scrum team delivered more _value_ (maybe more or less planes. Agile Is Not Fast)
• The scrum team had a very structured process (Agile Is Not Easy)
• The pace of development was calmer and more sustainable on the Scrum team, but there were still peaks.
• Done-done testing is crucial. Early deployment is crucial (the waterfall team's plane didn't fit in the Delivery Box the first time we ran this).
• Did we end up with a contract argument when we should have been building planes?
• Were there bugs? We had a waterfall team saying "the fuselage has fallen apart again"..
• The scrum team could take advantage of last-minute requirements changes.
• The scrum team assumes that long-range planning is inaccurate. We had a scrum team ship multiple small planes! While you don't know for sure what you're going to get, you often don't know anyway; this just removes the illusion that you do know.

We're still refining this, so I'd be interested in any changes or experimental results.