Last week we gathered together in Barcelona members of the team that use to work from Brazil, Ukraine, so we thought it would be a good idea to do some team building activity, and it would be even better if we used the opportunity to show the values of Agile and Scrum to the members who never had used them before.So, I prepared a game. Two teams of 4 and 5 people each, working collaboratively to build a city using LEGO, with a backlog containing the buildings the be built and a Product Owner available to refine requirements.
I used Alexey Krivitsky's paper, Scrum Simulation with LEGO bricks enhanced with ingredients from Agile42 and my friend Saket.
They organized in two teams, having at least one non Spanish speaking person in each group, and I explained the backlog, the parts of the city to be built or drawn.
Then they estimated the work to be done using swimlane sizing and story points, and did a release planning, planning three sprints ahead.
From then on, the worked against the clock. We did three sprints each of them with 3 minutes plan, 7 minutes work and 3 minutes review.
In the first review the team have not realized they were expected to show "a city", and were arguing the requirements until they understood they were working to build what the Product Owner needed, and they had him available to ask questions if needed. After some User Stories not accepted, finally they succeeded and did a great job.We included an extra retrospective in the end, and all the process was about 2 hours.
I used the happiness door technique to get feedback from the experience and I cannot be more satisfied :-)
What I learned:
- In this game it's important to have a tight schedule and a visible timer.
- It's a good tool to explore the behavior of the team under stress.
- It's a very effective way to learn Scrum values and build a team.
- They decided to nominate an Scrum Master within one team, but in the retrospective they pointed out that it's role was not used at all.
- The language (almost all were non-native English speakers) was not an issue.
- We run to build, instead to plan and talk, and it's hard to correct this behavior.
- It's easier to build what you think, working on assumptions, than to ask. But far as effective.
