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 some of our team members knew the theory of the methodology but lacked the necessary practice for the knowledge to be consolidated. In addition, the practice makes the training more enjoyable and gives people the opportunity to establish links that will help the maturity of the team to grow and become better work buddies.
Prior than 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 as well as 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 on 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 is told is very important because it has to create an environment in which the group feels motivated, and this is partly the responsibility of the history conceived as well as the capacity and creativity of the simulation facilitator.
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, five would form the development team responsible for carrying out the project and one Scrum Master that would be responsible for ensuring the correct use of the framework during the development of each sprint.
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 this 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.
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
- 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 ask for more details. This is important because as a customer, you think that those details are obvious to you and for everyone or you never thought about any details until the asked you.
Usually teams start building things without asking for acceptance criteria, the objective with this is learn how important is to discuss and confirm the requirements and how frustrating 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.
- Question during the game: Participants can ask to PO for more details if they want.
PO only answer exactly what it 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?”. Or maybe the answer “I am busy right now”, this is to increase the complexity of the exercise.
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, at the beginning, the team would forget to engage with the PO, they didn’t ask about the tasks that wasn’t clear and they assumed wrong things. This is totally 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.