Gamification – Building House Game

The Gamification is one of the most effective ways to engage people. We have used this practice several times in Elfo, both as a retrospective feedback and as an introduction to a discussion. The last time was on the occasion of a retrospective feedback, that was involving some members of the production teams and customer service teams. The aim was to think on the themes of collaboration, communication, quality and how these affect the value that we provide to the customer. We created this game through the use of Lego. We had a lot of fun and, above all, it has permitted to reflect on certain behaviors and interactions, making simulations on different contexts.

HOW DOES IT WORK

The objective of the game is to build a Lego House, close to an original model. We divided the participants into two teams, the Red one and the Blue one. Each team was made up of:

• A person interested in gathering requirements, simply called “Product Owner” (hereafter PO)
• A person with technical and coordination skills, called “Team Leader” (hereafter TL)
• One or more persons, purely techniques, called “Developers” (hereafter DEV)

The game is divided into iterations: at each iteration each team has to be able to create a Lego House as much close as possible to the original model.

The Blue team iteration is organized as follows:

• PO has 3 minutes at his disposal, in order to look at the model of the house and describe it through a list of specifications written in natural language, without using drawings, sketches or colors. PO is the only one who can watch at the original model.
• A example of requirements from the PO might be: “The house is made primarily of white bricks, there are two windows on the right side of the house, on the roof there is a chimney, built with 3 bricks” etc.
• At this point, the TL has one minute left to read the requirements and ask appropriate questions in order to improve the house description.
• Afterwards, starting from the requirements, TL and DEV have 5 minutes to build up the house.
• The first iteration ends and the house has to be delivered.
  A new iteration can now start and the PO can improve the requirements, starting from what has been built in the first iteration.

The iteration of the team Red is similar to the one of the team Blue but:

• TL doesn’t have time to fine tune PO requirements
• TL tells DEV how to build up the house, instead of joining the development

The two teams work simultaneously and the scheduling is marked by a person who doesn’t join the game. Three or four iterations can be made, depending on the complexity of the house to build and how much participants are having fun.

WHAT IS REVEALED

Obviously the Blue team was better positioned and it has built up the house closer to the original model. In fact, people were able to take advantage of better collaboration and communication in the team. Both teams, during the first iteration, have focused the attention on the details (the tree in front of the house, the fireplace …), leaving out important information such as the orientation of the house. This has required them to start again from scratch. Often what was delivered at the end of each iteration was not a house, but a “set of walls”, without any added value for the customer. In one case a last second change has caused the collapse of part of the house, as it could occur during software development.

Generally, it has been a good experiment: we had a lot of fun but, above all, we started a discussion on collaboration and communication inside and outside the team.