Since the beginning of 2019, I have been part of the organising committee of Agile Malaysia (we are are also on Facebook and LinkedIn). The group has been active for about five years, but it needed some fresh blood to engage our community. We are all volunteers, passionate about Agile and intending to create a strong knowledge-sharing community. Our committee is made of Agile Coaches, Managing Engineers, and Product Managers.
We organise different types of events, working with companies in Kuala Lumpur and abroad to either have a quick glance into how they are using Agile frameworks and practices in their companies, or we organise workshops to spread awareness and knowledge on Agile. Over time we had experts such as Woody Zuill, Janet Gregory and Dave Thomas from YOW! Nights share their experience and knowledge with our community.
Our latest event was a Scrum LEGO workshop, lead by Shibu Abraham, a member of our organising committee, where we had about forty participants.
*For a detailed guide on how to run the workshop, check out the brief facilitator guide here or the book by Alexey Krivitsky. I will not cover much of the rules of the workshop here.
What’s the purpose of the Scrum LEGO workshop?
The workshop focused on teams working together to build a city, based on a set of instructions (requirements), following the Scrum framework. The building instructions are light (e.g. a building must have minimum a door, and a window on each floor), so there’s a lot of room for innovation and creativity.
There is an owner of the city, who will accept or reject the buildings as they are delivered. We called him the Client.
There is also a Bank of LEGO pieces (in case you need more that the starter kit you get), with an attached Banker. You can only buy pieces with money that you get from delivering buildings.
The teams (composed of 7+/-2 people maximum) work with a Product Owner – the person who owns and manages the list of buildings that need to be done, and has the information on how the buildings should be done.
You’ll also need the Facilitator and a time-keeper (he/she can do both).
There are some things that you need to get done for the workshop:
- a list of buildings that make the city, that will be posted on the wall – sticky-notes are better, as you can easily move them around; this is your Product Backlog; there is not much information or details on how the buildings look like. The notes have to be prioritised based on what the Client needs.
- LEGO starter set for each teams (100 pieces / team). Also sets of 20 LEGO blocks should be already organised, as they will be bought during the game.
- printed documents with instructions and details for the facilitators.
How does the workshop go?
The workshop will follow the Scrum rules (as a note, the rules were adapted to fit the diversity of our participants and our time constraints):
- the teams will work in sprints (the duration depends on the total duration of the workshop; we kept ours at maximum 10 minutes).
- they start with Sprint Planning (1 minute), where each team will choose from the Product Backlog what they think they can get done in this sprint.
- the execution consists of 4 minutes of work; at the end, the teams arrange the LEGO buildings in the city and are being paid for the buildings accepted by the Client.
- there is a 2 minutes Sprint Review, where the Client accepts or rejects the buildings delivered.
- the teams close the sprint with a 1 minute Retrospective, where they reflect on learning and decide on improvements for their work.
Before starting the work, we engaged the team in a Product Backlog Refinement session; they worked with the Product Owner to organise the buildings based on value and customer needs, get clarity on buildings specifications and acceptance criteria.
We also had the team estimate the work, by arranging the user stories based on their size. So in the end the prioritised Product Backlog looked similar to this (1, 2, 3… are story points; smaller stories are on the left size, bigger ones on the right):
From here on, it was up to the team to choose the stories they think they can get done (based on priority but also the resources – LEGO blocks – the team had) and start building.
*As mentioned, if you would like more details in how to run the workshop, check the facilitator guide from lego4scrum, it’s quite comprehensive and detailed.
What did we learn?
The learning is highly dependent of the level of Scrum knowledge of the teams. Our participant profiles were random – we got a balanced number of experienced, total newbies, and people that have been working with Agile frameworks for a little while. Each team had at least one very experienced person.
What’s fascinating about the LEGO workshop – and about Agile learning games in general – is how well it recreates dysfunctions that you encounter in product development teams, no matter the seniority. From my point if view, the game reflects reality and it gives you a good intro into how Scrum teams work.
At the end of the workshop we held a 15 minutes retrospective to discuss our learning and discoveries. Here are the most interesting insights:
- Our client rejected many of the buildings released at the end of the first Sprint. Even if they did accomplish the acceptance criteria, they were entirely different, from team to team, and the client considered that the town wasn’t cohesive with so many architectural styles. This was a huge AHA! moments for the teams: they were supposed to align on a few design and architecture standards if they wanted the client to actually accept their buildings. This mimics reality in software development teams perfectly: only after a few sprints, when issues and errors start to pile up, do teams consider alignment on design and architecture.
- The teams complained that they didn’t get enough time with the Product Owner (as it was only one person for five teams, so a scarce resource). But, the Product Owner was assaulted with questions only during the Planning phase (which happened at the same time for all the teams). He was quite lonely and on his won the rest of the time. This mimics quite well some new Scrum teams, that forget that the Product Owner is part of the team, and should be engaged with the team during the sprint also (in an organic feedback, clarification, discussions loop).
- The teams were rewarded for the buildings that the Client accepted (a certain price per building, depending on size, complexity, value). As expected, this created a wave of competition between them. They didn’t communicate with each other (unless they needed to set basic standards based on the feedback from the Customer), and they held information from each other as much as possible (e.g. the Client told a team that he prefers a type of roof and that team capitalised on it greatly; but they didn’t share this with the other teams, which would’ve increased the overall value of the city, kept it to themselves). This is the most relevant finding (and a dysfunction that you see in most Agile companies, where there are individual rewards versus team rewards; or, if there are team rewards, they isolate each team, which in turn lose focus on the bigger picture, the overall product). The rewards system – each team got paid based fort their delivery only – was a huge impediment against collaboration.
Conclusion
I have tried plenty of methods to introduce new concepts to my teams or the idea of Agile or Scrum to entirely new teams, and so far none of them is as powerful and revealing as games. Experiencing working in an Agile way, versus learning the theory, has a big impact on the understanding of what Agile is and how it works. It’s definitely worth trying and there are games that look at Agility overall, or specific games for a framework (e.g. following the Kanban game, my teams started using Lead Time metrics and really caring about their Work in Progress (WIP) limits, after working with them to adopt them for months).
In the end, I’d like to give you a sneak peek into our workshop:
Agents of Awareness 
Leave a Reply