This week, a few other Scrum coaches and ScrumMasters and I conducted a trial run of the “Scrum Lego City” game. Thanks to Sven Röpstorff, Thorsten Sturm, Mathias Vaagt and Sibylle for joining the game!
Scrum Lego City by agile42 is licensed under a Creative Commons Attribution-Share Alike 3.0 Germany License. Openly sharing experiences should be in the spirit of the creative commons license. I’ll provide a brief summary of our setting and the key learning points below.
- 5 “players”, 3 of them Scrum coaches, 2 SCMs. So the Scrum Team consisted of PO, SCM and a development team of 3. The game facilitator was part of the development team.
- We used a Lego Duplo set with a train set.
- We used the standard set of requirements/stories as provided here.
- In the Sprint planning, we did not break down the stories into tasks, merely committed to a certain number of stories.
- We used the timing / “rules of play” suggested by agile42 as a basis.
- We used one “event card” in the 3rd sprint: “The PO gets a call from the MD, stating that all work needs to be stopped immediately in order to build a McDonalds restaurant in Lego city.”
- The rather chunky Lego Duplo worked great for a group of such a small size. The train set contains a few handy things such as a crane, train, lorry, … It was definitely sufficient to try out the general idea and to have a good learning experience.
- Towards the 3rd sprint, the (Lego) resources were nearly depleted – make sure you bring a ton! (Or, use this restriction to bring out creativity in people.)
- For a bigger team, the “standard” Lego should be used. It allows for better parallel working on the same story, and for much more detailed results.
- It is important to find the right balance between providing some pressure and sufficient time learning. The proper balance depends on the people involved and the general setting. Particularly less Scrum-experienced teams should not be rushed too much, otherwise learning will be inhibited. The time box for the retrospectives might be loosened or a “Stop” sign agreed for additional reflection any time.
- The suggested 10min for the first Release Planning are definitely too short. For a rookie team, this should be something like 30min.
- We only did a Team Estimating of about 10min, did not play Planning Poker at all. For teams new to Scrum, this could be confusing. There, starting with Planning Poker only and introducing other techniques like Team Estimating or Magic Estimating later would probably be a safer path.
- Timing for the sprints themselves (5′ Planning, 5′ Sprint, 3′ Review, 5′ Retrospective) worked surprisingly well.
- The facilitator should normally not be involved as a player himself or herself, as this naturally distracts attention from observation and things like bringing in event cards when the team works too smoothly 😉
- Last but not least (thanks Sven for reminding me): Don’t let your kids notice you “stealing” (borrowing) their lego sets!! A lot of hassle down the road, certainly if they’re around the age of 3 😀
Ideas / things to try out in future games:
- If enough people, materials and facilitators available: Try the game with multiple teams working in parallel to introduce a competitive element which increases pressure.
- Use more “events” to get more pressure and learning points.
- At first, only provide the team with half of the available Lego resources, then let them handle this constraints.
- Besides some real “events” like PO getting a high urgency interrupt from management, a team member getting sick etc., behavior-oriented cards could be used. For instance, give players different stereotypes of personalities to play, like a whiner, a very shy person, someone who always tries to dominate the others etc. This will bring much richer situations, as in real life. Remember, the Scrum practices themselves are easy, it’s the behaviors and team dynamics that make things interesting.