Learning SCRUM with LEGOS

In Kreitech, we know about Scrum, and we apply it in many of our projects, which gives us very positive results, such as better bonding with our client and team, and having a predefined process to manage change in the product. But the reality is that, although some members of our team knew the theory very well, they needed to put it into practice to incorporate the knowledge. Also, the practice makes the training more enjoyable and allows people to establish links that will help the team’s maturity grow and become better work buddies.

Before this, I participated in a workshop at the university, and I immediately realized that the power of simulating a real project was a great way to clarify unknowns and to learn Scrum in a practical and fun way. So, I came up with the idea of applying this in our office to do a fun practice. That is how we started with the development of our first Scrum workshop with LEGOS following the method of Lego4Scrum!

The workshop was divided into two parts. The first part consisted of presenting the theory based on the Scrum Guide, where we review the three pillars and five values, the team and roles, artifacts, and events.

After the presentation, the fun part would come, simulate a real project in a practical way, and this is where the Legos appear!

The Story

How the story and the problem are told is very important. They have to create an environment in which the group feels motivated.

In our case, the challenge was to build the best and most beautiful dinosaur in the market ever!

The Scrum Team

Groups of 7 people were formed: one Product Owner, one development team, and one Scrum Master that would ensure the correct use of the framework during the development of each sprint.

Materials

• Lego pieces, a box with around 300 pieces, is enough for a development team of 4-6 people. You can use the Lego classic (models 10693 or 10694).
  ‍
• A board with columns (Backlog, Sprint Backlog, In Progress, Done, Accepted) to show the workflow.
  ‍
• User stories (each one with an associated business value to show how important the story is for the client and the success of his business). I suggest you print them as cards.
  ‍
• Post-it’s and markers for the retrospective. For example, red sticky note for things that the team should improve in the next sprint, and green sticky notes to write down those things that were done well and to remember not to abandon them and should be part of our usual practice of work in the next sprint.
  ‍

Sprints

Four sprints of 20 minutes each one.

• Sprint Planning – 5 minutes
  ‍
• Building – 10 minutes
  ‍
• Sprint Review – 2 minutes to show the product increment
  ‍
• Sprint Retrospective – 3 minutes  
  ‍

Some tips:

• Secret Acceptance Criteria: the product owner should have the list of acceptance criteria for each story, but he wouldn’t provide any of them unless the team asks for more details. This is important because, as a customer, you think that those details are evident to you and for everyone, or you never thought about any details until they asked you.

• Usually, teams start building things without asking for acceptance criteria, the objective is to learn how important it is to discuss and confirm the requirements and how frustrating it can be to put effort into building something that looks good, but nobody wants.

• Done criteria: PO is the only one that can approve a story as done. If a team did something awesome, but it is not aligned with the acceptance criteria, do not approve, and do not let them convince you.

• Sprint timebox: check the time of the sprint.

• Questions during the game: Participants can ask the PO for more details if they want.

• PO only answer what has been asked. Sometimes may act as he/she does not like a feature unless the participants ask “why” or “how would you like it to be?”. Maybe the answer, “I am busy right now” is to increase the complexity of the exercise.

And that’s it! Let the game begin!
‍

Final thoughts

At the end of the game, the teams share their thoughts and conclusions with all the participants. Some common mistakes were, in the beginning, the team would forget to engage with the PO, they didn’t ask about the tasks that weren’t clear, and they assumed wrong things. This is to be expected, but this is when the scrum master must jump to the game, in the retrospective SM must help the team to ask them what they did wrong and what can be improved for the next sprint. The result is a team that evolves and learns as the sprints pass.

On the other hand, they live the experience of working under pressure, with a time boxing. Finally, although not all the requirements were done, they have a working product ready for production that has most of the value with the minimum effort.

‍