I love agile games! They help explain the concepts behind Scrum in a much more direct, fun and powerful way than any theory session will do. When executed well, they allow participants to experience first-hand why Scrum really works. Over the past few years, a number of simulation games have popped up to do just this. The one that always captured my imagination was the Scrum Lego game invented by Alexey Krivitsky because it looked like great fun to play with legos and learn about Scrum. Because I would love to be able to add this game to my own workshops, training and coaching sessions, I decided to invite some friends and colleagues to try the game and see if it really worked. Simply put, we had a blast! In this post, I would like to share my experiences and recommendations for playing this game.
As a visual representation of the process, I created two timelapse videos; one of our [lego city] and one of the [work table]. You can see them at the bottom of this post. The lego city was positioned just outside of the work table camera.
A bit about Scrum Lego
In the Scrum Lego game, one or more teams work together with a customer or product owner (usually played by the trainer) to construct a city, primarily with legos. The product owner begins by presenting a prioritized backlog of buildings he or she requires, and the teams helps clarify the requirements. An estimation round can be performed to help the teams size the buildings in terms of complexity. Teams then proceed by pulling items from the backlog, one by one and starting from the top, that they feel can be finished in a sprint of 7 minutes. The sprint begins when teams feel unconformtable enough with the amount of work they have selected but are willing to give it a try. A large countdown timer is displayed and the teams have 7 minutes to finish the work. After the first sprint, the product owner reviews the results with the teams. Changes are discussed and specifications are clarified when a building was built incorrectly. A short retrospective can be done and the teams proceed with two additional sprints. The game finishes with a global retrospective on “lessons learned”.
A more detailed description of the game and how to play it can be found in the excellent manual by Alexey Krivitsky.
A report of the game we played
We played the game with seven people; myself, Hilmar van der Bijl (Scrum Master at Garansys, Maarten de Bruin (project manager at ABN Amro), Jasper Huiskamp (Product Owner at Teijin Aramid), William Water (developer at NowOnline), Tim van Elst, (analyst at NowOnline) and Laurens Verwijs (account manager at NowOnline). This group consisted of two certified Scrum Masters and two certified Product Owners. Five of us had solid hands-on experience with Scrum. So we certainly went in prepared!
We used the presentation room at NowOnline for the game. I put up two whiteboards, one populated with the backlog and a release burndown and another with a sprint planning wall. We used our large presentation table as a workplace and put the legos there. The ‘staging city’ was set up by pulling in an elevated bar table covered with A4 paper so we could draw on the landscape.
I decided that it was best to combine the roles of trainer and product owner. Although this is tricky (see the lessons we learned below), it did help me to work out a plan and act out a typical customer. I decided that I needed a mockup of a city so that I could present my ‘building’ plans to a city council. I started out the first sprint by keeping my answers vague and unspecific, just like a real customer who assumes that it is all very easy. After a barrage of questions, I acted a bit annoyed. What was so difficult about building some buildings, after all? Of course I pressured teams to put more work in the backlog than they could finish. I wrote up a list of general specifications for all my buildings (but kept it to myself) so that I could answer any questions without having to think up too much ‘on the spot’ (and perhaps make it less realistic). We did add a number of additional specifications throughout the game as the teams asked good questions or came with good suggestions.
We started around 8:00 PM with a short introduction icebreaker (hero game). I asked the group to split into two teams of three with a shoesize sorting game. We then proceeded with the actual Scrum Lego game as described. We rounded up with a solid retrospective (using a modified learning matrix game).
Sprint #1: epic failure (actual velocity: 2 points)
We spent quite a bit of time hammering out the specifications and estimating everything (we ended up with 35 points total). The teams asked a lot of questions and decided to write everything down. When the sprint finally started, both teams started to build like crazy (every member a building). I received one question, but that was it. When the sprint finished, both teams seemed very happy. The ‘staging city’ was indeed populated with a few buildings. But I told the teams that I did not like the results at all. The teams had made a lot of assumptions on what I needed without verifying with me before or during the sprint. I also came up with new ideas for some of the buildings because of what I saw. Of the 10 points of work the teams initially selected, only 2 points were actually finished. So, despite the massive combined experience with Scrum, the teams still failed to deliver anything substantial during the first sprint.
Sprint #2: new strategy, more results (actual velocity: 7 points)
Initially, some team members felt that I came up with new stuff that we did not discuss. Yes, just like a real customer. I pressured the teams to make the changes, because I paid them well for it after all. So, the teams re-estimated shortly and pulled a selection of the unfinished work into the new sprint. I acted a bit disappointed with the little work that was going to be done, and got the teams to pull in more work.
Interestingly, the second sprint saw the application of a new strategy. Some team members started to collect bricks of the same color, while others focussed on building ‘templates’ for buildings. The teams also started to share work and involved me quite a few times to check if I liked it. The ‘staging city’ was populated more frequently with new buildings.
The second sprint ended in an actual velocity of 7 points. Although it was certainly not enough, it was more than the previous sprint. I also found the results more satisfactory. Because I had already seen most of the work during the sprint and had been asked if “I liked it”, I sent only one or two building back for changes.
Sprint #3: Hyperproductivity (actual velocity: 24 points)
The team was very worried by this point. With 24 points remaining, the velocity was too low for the teams to finish everything. Together, we went back to the purpose of the whole ‘lego city’. Based on this goal, the team realized that there was a simpler way to create the buildings and still finish the work. They started offering me a number of choices that allowed me to decide how to go ahead and what to let go.
During the next 7 minutes, the teams finished all the work that was on the backlog. They achieved a hyperproductive state based on their velocity, which was a whopping 24 points. Another important factor was their increased cooperation between the teams, as some team members started helping the other team. Teams also started reviewing all the work by asking questions like “Is this what we need?” or “Is this ok?”. Interestingly, they asked me to participate very often.
The sprint was a major success, as all the work was finished and I was happy. The city actually matched up quite well with the specifications that I originally had in mind.
We finished up the final sprint with a global retrospective and identified a number of lessons that we learned.
Lesson #1: Very realistic!
Initially, I was worried that this game would be more fun and less realistic. But it turned out that we recognized a lot of ‘bad’ habits that are also prevalent in normal projects, some of which I will describe in more detail below. We recognized:
- The urge to get all the specifications detailed upfront, and spend a lot of time on hypothetical reasoning on what might be;
- The urge to build technically clever stuff, which is not really necessary, and will not be noticed by the Product Owner. One of us actually complained that the Product Owner had not seen the clever standard he had built for one of building facades, which was actually even not necessary to keep it up;
- Forgetting to put everything on ‘staging’ on time and before you do a proper review;
- A customer that changes his mind during a sprint review or comes up with additional specifications that “make total sense”;
- The difficulty that people often have to estimate something, even if it is based mostly on gut feeling. There is a strong 'need for cognition' here;
- The appearance of character traits when working under high pressure;
We all felt that the game really hit the mark here and taught us a lot.
Lesson #1: Enough Scrum knowledge, and still we fail
It was interesting to see how the Scrum proficiency of the teams did not protect them against basic errors. In the first sprint, the teams assumed too much and had to do a lot of re-work as a result. They also pulled too much work into the sprint, partially because I pressured them. Interestingly, the first sprint was very much an ‘every man for himself’ strategy, with little intra/inter team collaboration. This improved greatly throughout the sprints though. We also noticed that there was a somewhat blaming response from the teams when I changed my mind or when I came up with new stuff. Even though all we all know that this always happens with software development (embrace change).
Lesson #2: Estimation is wasteful when done for the wrong reasons
We ‘wasted’ 50 minutes on discussing the backlog and estimating it, but still failed almost the entire first sprint. Why are we estimating again? Apparently, all the talk did not help at all when it came to the first sprint review. This was a big lesson for us, and a major insight in the uselessness of estimating for predicting anything at all. A more useful strategy may have been to just start building one or two buildings after a cursory discussion on the specifications and gauge my response. This would have saved us a lot of time and would have allowed more sprints to take place. One of us actually stated that “if we can’t even predict the complexity of a lego building, how can we possibly predict software functionality?”.
Lesson #3: Teams improved vastly throughout the sprints
Although we did no formal retrospective during the sprints except for a simple question ("Can we improve anything?"), both teams quickly increased the degree of collaboration and work delivered. Some of us felt that the retrospective should be a formal part of the game, while others felt that learning had taken place regardless and that a retrospective would have just been “more talk”.
Lesson #4: Combining the trainer / product owner role is difficult
Combining the role of product owner and trainer is possible, but it is quite tricky. The responsibilities are different as the trainer is focussed on getting the lessons across, while the product owner is focussed on acting out a realistic customer. I did try to tell the team if I was speaking to them as the customer or as the product owner, but it still felt confused. It might be best to find someone who can play the role of product owner convincingly. But this will take some planning with the trainer to make sure that the session is as effective. Another solution might be to work with different actual hats; a “product owner hat” or a “trainer hat”.
Lesson #5: Great fun!
We all massively enjoyed playing this game. It was quite stressful, but we also laughed a lot during the process. The game managed to combine great fun with a very educational experience. When done properly, it really provides a very insightful simulation of software development. And do I need to mention that you get to play with legos....?
Conclusion: just do it!
The Scrum Lego game by Alexey Krivitsky is a great game that can be played in a few hours and can really bring home the concepts and reasons behind Scrum. When properly done, it can easily be integrated in a Scrum training. If the people playing the game have little or no knowledge of Scrum, it is important to first take quite some time to explain how Scrum works. In the game there is not enough time to explain everything. This makes the game something you can very well play at the end of a training day to bring everything home (and still make all those mistakes you thought you would stop making). In short, we highly recommend playing this game and I will certainly make this a regular part of my longer training sessions.
I apologize for the inconvenience, but the timelapse videos seem to have been removed by YouTube, and I don't have a local backup available