I Played LEGO with My Team!


I Played LEGO with My Team!


two lego people 

As 2016 came to its end, I wanted to do something different with my teams. I decided to try LEGO® Scrum which was proposed on Lego4Scrum.com  and highly rated by many practitioners.

I won’t explain how this game is played since there is a very good guide on the website, but I will try to share my experience and the lessons the team learnt.

My main goal was to coach the teams on how different teams can work on the same product, share the same backlog and plan sprints together. I divided my two teams into three smaller ones, four members each. I acted as the PO and tried to simulate several real life scenarios, like changing priorities and team members getting sick during the sprint.

Reasons I Chose to Build LEGO City

We chose to build a LEGO® city. The reasons?

  1. We are building a product that is very similar to building software.
  2. You can decide on several buildings aka user stories which can have different levels of complexity and require different amount of time.
  3. It is something tangible the team can feel and they can see the direct effect of their decisions right away.
  4. It can be fun.

Playing the Game

First I presented the training’s agenda and how we will organize the sprints and so on. Afterward, I presented the requirements of the city and we wrote the user stories together.

We did the estimation using a fast estimation technique, “swimlane sizing.” We created several groups with different story points, then each team nominated one member to place different user stories in the group where it would fit more. Then a sanity check was done where all the teams reviewed the estimates to make sure everyone had the same understanding.

As soon as we started with the first sprint, many issues facing newly formed teams were obvious: there were alpha males, shy persons, people who didn’t want to make decisions, etc.

As a result, two teams failed to deliver their committed scope. One team decided to work on the design of the city and drew it on paper for others to place the finished buildings, i.e., the integration environment was missing. The other team spent too much time building a “perfect” building and didn’t manage to deliver the second one.

On the second sprint, a team member of the “successful team” got sick and they didn’t manage to deliver, while the other two teams delivered all they’d committed to.

Just before the third sprint, there was a change of requirements and new features were requested. The teams estimated them and each team worked on one of the new features while some of the previous user stories in the backlog were left behind.

One of the teams working on one of the new user stories finished a little bit earlier and tried to “add” more features which were not required. This led to making the finished building fall apart. They managed to fix it by the end of the sprint, but it was a good lesson.

My Remarks

At the end we had a debriefing or a retrospective to get feedback. Here is my overall feedback on the game:

  • The game is fun, of course, but also simulates what happens in real life.
  • The game is also stressful, we had very short sprints (seven minutes) as well as the meetings.
  • Not everyone loves games in the office.
  • If teams plan together, they can work on the same product, but if the teams are not co-located, it will be more challenging.

What the Teams Learnt

Since it was similar to real life, there were many lessons the team learnt during this practice. Also, the teams appreciated trying something new and fun. Here is a highlight of some of their comments:

  • Scrum coaching is not always boring and we can have fun at work.
  • Several teams can work on the same product and share the same backlog.
  • While designing the city, the team was trying to reach the perfect design which cost them a lot of time.
  • Gold plating is harmful. Don’t get tempted to add features that were not initially required unless they are needed.
  • While committing to delivery, leave some room for emergencies, which means taking risks into consideration.

In general, I liked the session and I would like to do it with more teams involved in the future.

Have thoughts about this exercise? I would like to read your thoughts on the idea and practice itself in the comments below.



 

Islam Kotb Ismail (PMP, CSM, CSPO) is a senior agile project manager and Scrum Master at Wirecard Technologies GmbH in Munich, Germany.

Learn More
comments powered by Disqus