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!
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!
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.
Four sprints of 20 minutes each one.
And that’s it! Let the game begin!
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.