Where is my city? – Lego scrum simulation

I really love games, that is why I am trying to use them in my work life too. When it comes to the serious questions – adopting new processed framework or show the team why it is great to work in a team – I prefer to use games too. It is fun, it is easy and very engaging. When I came across lego scrum simulation by Alexey Krivitsky, I thought – “Bingo! That is what I need.” In addition – I really wanted to buy some lego and could not find any excuse to do that…So it was my chance.

We have tried this gave with several teams and the results were surprisingly good.

The idea:

The team is going to simulate the real scrum development process and have all the scrum process artefacts during the development. There are several roles: Product owner, Scrum master (we didn’t have him on our first simulation, but it was really hard to keep the track without the scrum master), Developer, Tester.

Product owner (trainer) provided the vision of the product – the city with different buildings and facilities. Team had to estimate it and build in about 3 sprints.Product owner had to be as strict and stubborn, as the real-life PO 🙂

For estimation we used the quick swimline sizing (1-2-3-5-8 SP). Once we were done with all the user stories – teams made the assumption, how many SP they can do in 7-minute sprint. We’ll then count up the number of points at the end of each sprint to adjust that number.

Teams estimating

You can see how the planned/observed SP correlate:

Sprints progress

Building. PO is suspicious

Sprint 1 – start of the development

Isn’t this church with stained glass beautiful?

What was useful for us:

• Team collaboration and focusing on development of the product. We encouraged developers to come up with a lot of ideas – not just create what the PO asked for. teams worked on one product, so that had not to work “against” each other.
• Metrics: teams understood, how we can make estimations quickly and easily. Compare the planned/observed velocity, change our release plan based on these observations.
• Continuous improvements: teams got multiple tries at the game. Each session generates lessons learned and helps them to figure out better processes.
• For the PMs it was very interesting to observe the behaviours of the team members: as the game is designed to be stressful – team members show very similar to the real work situations behaviour. So, the observation gives the great information for the personal coaching. Also you can see who is  “manager”, “dictator”, “loud voice”, “pessimist”.
• Where the process is broken. One of the teams had a great problems with collecting requirements – they haven’t asked PO many questions. They created the building, bud haven’t asked even what the colour PO wanted. As a result they could not close stories for 2 or 3 sprints. Their PM told me that it is a common problem on their real project) So, it was a good lesson about the importance of getting enough information from the Product Owner to deliver what the client wanted.

What could be better

• PO was not strict enough 🙂 Teams said that their real POs are more crazy guys. I tried to improve that during the next games and found it difficult to balance.
• Forgot to update burn down chart on time. Scrum master can help with that a lot.
• Retrospectives – teams tried to ignore the discussions about the process improvements and move to planning asap.
• Teams tried to start building before the beginning of the sprint -during the discussion of the backlog. Seems that I should not give them lego too early? 🙂
• Teams talked a lot about “creating the one scheme of roads we can use then for the building to be build on them”. It was close to the “let’s create the ideal architecture in the beginning, plan everything and then start coding the features…”. Had to create new stories and through away some of the old ones to show the backlog changes.
• It was very hard to keep an eye on the timer and switch it on when necessary.

What I will improve next times:

• Ask Scrum master to help me with timer
• Give more complicated tasks for the teams and change requirements more often if the tasks are too easy for the team
• Try planning poker with the teams, which haven’t tried it yet

And released cities photos: