Games are a fun, interactive, effective way to teach. A dose of competition mixed with social interaction keeps people engaged. You learn by doing and reflecting on the experience. Powerpoint, your time is over.
Until recently, I hadn’t had the opportunity to use learning games, since most of my work as an Agile coach is done remotely. In February I tried out the Resort Brochure with The Blog Studio and Thmvmnt with positive results, and then in early March I spent a few days with the Web Collective, all small purpose-driven organizations looking to become more Agile.
To introduce everyone to Scrum, I used Alexey Krivitsky‘s excellent Lego For Extended Scrum Simulation. Alexey’s game has improvements over other Scrum simulations I’ve read online:
- Build the backlog. Teams estimate the size of items, and the product owner may re-prioritize based on those estimates, just like in a real project. Some games have pre-determined backlogs, with all items sized and prioritized for you. Seems a little too command-and-control to me, which Scrum isn’t supposed to be.
- Multi-team collaboration. Teams work together, not against each other to reach their goal.
- Metrics applied to planning process. If you are going to bother estimating, make it useful. Teams estimate the size of their work, compare planned vs. observed velocity (how much they get done each sprint) and see the effect of observed velocity on their release plan.
How it works
This was my first time trying the Lego exercise. The product owner (me) explains to the team the vision for the project, to get everyone inspired and focused. In this case, the team has been hired to build a new city.
The team then estimates the items in the backlog, which includes things like one story buildings, a church, a tow truck and a crane. We used Steve Bochman’s team estimation technique to quickly size up stories. Team estimation turned out to be quicker than planning poker, which is what I had always used in projects. Team estimation and planning poker focus on comparing the relative size of features / stories, which is far easier to do and more accurate than trying to guess the absolute time to build each item. The next day the Air Charity team at Web Collective estimated over 50 stories, averaging between 2-3 minutes per story! Amazing speed given this was their first Agile project.
Once the items are estimated, the teams have guess how much they can get done in one 5 minute sprint, and that is used to determine their initial velocity. We’ll then count up the number of points at the end of each sprint to adjust that number. In the diagram above, the team estimated 18 points per sprint before starting the work. Each section of stories is a sprint.
Watch the passion, focus and determination for yourselves.
What went well
- Teams learned the importance of getting enough information from the Product Owner (client) to deliver what the client wanted. Some Lego creations were rejected because they didn’t pass expected scenarios, like being able to open the door on a building without the wall coming apart. The quick feedback cycles of sprints enabled them to fail fast and get back on track.
- Everyone had fun learning about Scrum. They went through most of the Scrum process, from release planning to working in 4 sprints, including a demo / review at the end of each one.
What could have been better
- Forgot to update burn down chart at the end of each sprint, and with that, the review of the teams’ overall progress in comparison to the release plan.
- Need more Lego. One tow truck hobbled on 3 wheels.
- With 8 people, team estimation stalled at times. Need to learn more techniques to keep flow moving. Hank Roark (@hroark on Twitter) pointed me to James Grenning’s Companion games for planning poker.
What I will do differently next time
- Use a timer that everyone can see
- Tweak the estimation process to make it go faster
- Keep a check list of items to do during every sprint
- Expand Lego set to add some variation