Almost 2 years ago I wrote about my experience with Lego Scrum simulation. Since that time I practised it about 10 times with different teams – inside and outside of my company. When you start playing it for the 2-3rd time you get a bit tired of building the city, so we changed the theme and the backlog every time) I also discovered, that this game helps teams not only to understand the Scrum better, but to uncover some conflicts existing in the teams. When I stopped trying to combine the roles of trainer and product owner and invited my gorgeous colleague Dmitry Velikoivanenko (thank you, thank you a lot for all you have done!) to join I was able to get more from the sessions, as I had time to observe the team’s behaviour.
So, what variations we tried(and some ideas):
- creating the prototypes of the animals which will be used for cloning and populating the planet, that was prepared for one of the clients of our company. Our bosses – white mice – hired the development teams to create the “matrixes” of animals for the further cloning. We had the description of the each animal, prototype, design (design was coming portion by portion every sprint from the design team and, of course, was changing all the time – like in the real life). Teams were to create 15-20 different animals with Lego.
- constructing one house floor by floor with the different requirements for each floor and “deployment” when the one floor should be “integrated” on the top of the previous one. The fifth floor is to be build first, of course 🙂
- creating computer hardware according to the specification (mainly system unit – graphic cards, sound cards, memory, motherboard and chips) – very much fun adding all the parts together.
Teams were taking the game “too serious” – especially the ones who worked under a great pressure in the real life. One of the teams was so angry about the product owner changing his mind that they almost started fighting. We talked to the team afterwards and had a great discussion of the “change management” in their project – it was a disaster for them. And when they saw the same in the game – they were furious. So we talked to their managers and tried to help them to change the process.
You could easily identify the most negatively minded peoples in the teams – they were fighting with the rules of the game, they were arguing with the team members instead of cooperating. There were different reasons for all of them to behave this way, but the game clearly showed us the conflicts in the teams and PMs had a chance to work on them and solve before they ruined the teams. This game provides you the great “pressure” feeling which makes possible to see how the teams behave under the pressure. 1st sprint can be like “game”, but from sprint 2-3 they start taking it seriously and forget about the Lego completely – it becomes the real “product’ and real “production”.
Isn’t that easy
Even certified Scrum masters and developers made a lot of mistakes. When they enter the room they think that they know everything and will be perfect in this simulation.
Team’s real life issues
This simulation is so great in uncovering the problems teams have in the real life! So it can be used as the “reprospective” and “facilitation” for the discussions afterwards. We did that with one of the teams, as the issues were so clear – I could not stand leaving without fixing them 🙂 So, the issues:
- Team demanded the specifications upfront. They spent a lot of time discussing them, making assumptions (instead of talking to the PO).
- Building not what the PO asked for, but what they wanted to build 🙂 It was like playing with the new frameworks)
- Forgot to “deploy” or everything was broken during the deploy. Deployment was during the last seconds of the sprint. The winning one was – crushing all the other teams built during the “deployment” due to the slippery flour.
- Communications with POs- some of the teams were hardly asking any questions. And on the demo they got “you did it wrong! I imagined it completely different!” But they still kept building without communicating with PO. They did the same in the real life too) ‘The more distant your client is – the better” – they told me then.
0 experience with Scrum
If the teams you are going to play this game have 0 experience with Scrum – you definitely have to spend some time describing them the framework before starting the game. As you’ll start using all these buzz scrum words and they won’t understand you)
No prize 🙂
People were disappointed that there is no prize in this game for the team which wins 😀 When you say – “we’ll play the game”, they think that there will definitely be the winner and the looser. It’s difficult to get that we are all building the same product) We laughed first as thought it was a joke. But no – they were serious) So in the beginning of each game we started telling teams that the winner will get prize. We are looking forward for someone from the participants to tell us there can’t be a winner) This experiment is still on, as no one said that. So, to make everyone happy we in the end of the workshop presented the lego “most beautiful animal model/floor/etc” to the the team which created it.
Definitely recommend you to try this simulation with your team!
2 thoughts on “Variations of Lego Scrum simulation and lessons learned”
I was lucky and I was on one of the Galina’s Lego Scrup simulations, so it was awesome! I recommend to try it to every dev team
I have recommended the Lego simulation to my Scrum Master, would love to learn more about the team ;).