We went to Malaysia and built cities out of Lego
- Colin Bell
- Jan 6, 2018
- 7 min read
Updated: Nov 25, 2024
In the last quarter of 2017 we took part in a university programme in Malaysia. As part of the agenda, we ran some Scrum training events and used the Lego4Scrum simulation to make our training more engaging. Here is a bit of a writeup about our experience- this is mainly intended for others who might be thinking about running similar events.
This is a bit of a long post so if you want something to listen to while you read this, then of course this is the most appropriate music.
Background
A few years ago while I was still working for HP as a technical instructor I was involved in the pilot of a new scheme at a university in Malaysia teaching fresh graduates about HP's software testing tools (edit: these tools have since changed hands, from HP Enterprise to Micro Focus and now OpenText). The scheme was a success and evolved gradually over a few iterations. Eventually the organisers decided to add some modules about other tools and a section about agile methodology (in particular, Scrum).
We added this because it turned out there was a gap in many students' knowledge- for example, apart from a little bit of unit testing, many students had not experienced testing at all in their studies (even those who had done significant amounts of programming). Also, knowledge of agile, which is fairly essential to a number of IT careers, was also lacking. Additionally, there are plenty of articles (such as this one) that talk about the graduate skills gap and mention things like critical thinking, team working and so on as skills that graduates commonly lack.
Given that the aim of our course was to give students an edge in finding employment, we decided that even a little bit of exposure to these things would help them out in interviews and so on. I wrote this new module and while I was looking around for ways to teach Scrum effectively to a group of students in a short space of time, I found the Lego4Scrum website. Scrum and Lego! This can only be a win/win scenario! At the time the guide was at version 2.0 so we modified the structure a bit and included some things such as getting the students to come up with the product backlog (which was also added to the guide in version 3.0).
Since then it has been presented a few times and in October 2017 I got to present it a couple of times myself in its latest iteration, so I thought I would share my experiences.
Setup and structure
We had a load of Lego from previous runs, mostly the large 10698 "Classic" box (one per team), although the pieces are all mixed up by now.
Also from previous runs the team had made "construction sites" complete with boundary fences from rectangles of plastic which served to prevent over-enthusiastic builders from getting Lego all over the floor. You can see them in the pictures. They didn't all survive the sessions intact, but they served their purpose.
We also had a pre-made road layout (made in true Blue Peter style of plastic sheeting and cardboard). I'm not certain this would be considered "canonical"- perhaps building roads should be a backlog item- but I think it helped to reinforce the "building a city" storyline and it made the end result look better.
We made a few changes to the outline of the project in the original facilitation guide. We added an extra sprint and increased the sprint time to ten minutes. We thought this would give us more time to experiment with different ideas, like adding new backlog items or changing things mid-sprint or the product owner changing their mind about things (you know, like real life). Overall our structure looked like this:
Stage | Minutes |
|---|---|
Getting organised | 10 |
Introducing the project | 10 |
Building the backlog | 15 |
Estimating | 20 |
Sprint 1 - planning | 5 |
Sprint 1 - building | 10 |
Sprint 1 - review | 5 |
Sprint 2 - planning | 5 |
Sprint 2 - building | 10 |
Sprint 2 - review | 5 |
Sprint 3 - planning | 5 |
Sprint 3 - building | 10 |
Sprint 3 - review | 5 |
Sprint 4 - planning | 5 |
Sprint 4 - building | 10 |
Sprint 4 - review | 5 |
Final review | 15 |
Total | 150 |
The total is 150 minutes, 2.5 hours. Allowing time for the inevitable overruns and so on, that fills up most of an afternoon. In the morning, we did warn everyone that we would be needing all their energy in the afternoon. And of course, everyone wants to take pictures of their creations at the end, so that also takes up a bit of time.
We divided up the group into teams randomly, so before the main activity we also added an extra task to get people warmed up and used to working together- after distributing the Lego, we asked teams to build the tallest tower they could in three minutes. Alas there was no prize for this, and of course the teams had to demolish the tower before the main activity. But working on a software project is full of these little disappointments.
Building the backlog and estimating
With all the group gathered around a planning wall we added backlog items. As we had talked about user stories earlier in the day we got the group to come up with some "personas"- types of user of the city, such as tourist, commuter, resident, police and so on- then about four to six items that each persona would need.
With everyone gathered around, we used the "swimlane" estimating technique. We'd already done a "planning poker" activity earlier in the day so we wanted to introduce another method. Of course, estimating is everyone's favourite agile ranting topic... but we wanted to introduce some of the different techniques that people might encounter and let them make up their own minds.
Then in the sprint planning phase we let the teams pick some items from the backlog and get on with it...
Sprinting
...and of course the first sprint was a disaster!
Despite having emphasised the importance of communication and collaboration in Scrum, and given the teams plenty of opportunity to ask questions, in each of the events not a single question was asked by the teams before or during the first sprint. I mean, everyone knows how to build a Lego house, right? Nope! As teams found out during the first review (when almost everything was rejected), they should have been asking the product owner about what exactly they wanted.
Things improved in the remaining sprints as people got more accustomed to working together and collaborating with the product owner. Of course, this is a familiar outcome to everyone who has run this simulation (Tuckman's model of group development also predicts this is what would happen in real teams).
By the time we got to the fourth sprint the teams were working well together but energy was starting to sag a little bit. A good time to stop and in the final review make a point about velocity being sustainable.
Lessons learned
1 Don't call it the Lego Scrum "game"
Despite the rise of tools such as "gamification" there is still a bit of a stigma about anything called a "game" in a learning setting when it comes to getting buy-in from management and this is doubled when used in conjunction with Lego. So, it's always "simulation".
2 Don't get the Lego out before the simulation is due to start
Everyone loves Lego. It's a universal constant. If you put Lego on a table in front of people, they will naturally start picking it up and playing with it. Sometimes this is exactly what you want to happen- this is founding idea behind Lego's own "serious play" method. But it's not really what you want to happen if you're trying to make a serious point about sprint planning or something. In fact it's best not to even mention Lego before the simulation is due to start, otherwise people will be wondering what on earth Lego has to do with Scrum.
3 Make sure your accomplices are briefed
Although I provided the overall direction of the activity, I was working with two or three other people who played roles within the simulation (reviewer, product owner and so on) so that we could get the tasks done promptly. It's important to make sure that everyone knows their role and any guidelines before the start- for example, if there aren't enough questions beforehand, almost everything in the first sprint gets rejected. As an example, in the first run I made the mistake of not mentioning the purpose of the "build the tallest tower" task beforehand and the product owners thought this was supposed to be part of the city.
4 Make it clear that there is no more Lego
We noticed that in the first sprint students would tend to create huge structures that used up a lot of the Lego, even for items that were only 1-2 story points. Of course these items got rejected! We did have a box of spare bricks for anyone to use and we did encourage "trading" between teams- after all the teams are supposed to be collaborating, not competing. But we emphasized that resources are limited. Being left with a pile of tiny bricks to build an airport in the last sprint because you used all the big bricks to build a house in the first sprint is not good resource management.
5 Be firm but fair
Of course, Scrum activities are supposed to be strictly timeboxed. But in a large group, with several teams, this is quite difficult to police, even when using a big screen stopwatch. Usually this is because the team wants to get on with building their next user story items. Getting the teams to actually stop at the end of one sprint, and plan what they are going to do at the beginning of the next, can be quite challenging and may involve the intervention of the "project manager" to enforce discipline... but, there is a balance between following the rituals of Scrum and allowing people to be creative and constructive.
Finally
As the last task for the day we asked each team to come up with three words that described the activity and write them on a flipchart. "Fun", "enjoyable" and "awesome" all appeared, but also "stressful" appeared a couple of times. Well... I guess that means it was a realistic simulation.
Here are some pictures. These are from three different events.
