Cross functional teams are complete in expertise but not necessarily collaborative. Sometimes team members hold on to their expertise too much and the team does not perform to its potential. This Lego game illuminates the difference when members allow themselves to take on tasks outside their expertise, being so called T-shaped. Play the game to kick-start your change and create collaboration.
This post was first published on the Crisp blog when Mia Kolmodin was a Crisp consultant.
Sometimes you hear during stand up phrases like “there’s nothing on the board for me” or “the story is blocked until she comes back”. Those are signs of silos and a team not working at full potential.
Cross-functional teams are teams with different areas of expertise that covers enough to create a product and put it into production. However, it is not enough to put together a group of differently skilled persons, usually experts on their area, and expect them to deliver as a team. This game tries to convey the consequences of holding on to your primary expertise and role only.
- Divide the Lego bricks in 4 stacks, based on colour. Each colour represents a skill.
- Each player gets a stack of at least 12 bricks. If fewer than 4 players, a player can handle more than one stack.
- Place the game poster on the table, one for each team.
How to play
On the board there are three user stories in priority order. To complete a story, bricks are to be placed in the order as shown in the story. A game consists of 5 rounds (an iteration). Begin the round by marking it on the poster. Each round, every player, in turn, takes a brick and places it as shown in any of the stories. Order of players are: yellow, white, red, blue.
If a player can’t place a brick, that is noted as a missed turn on the board.
When a story is completed, the round which it was completed on is noted on the board.
After 5 rounds, the game ends. Note how many stories were done, how many turns were missed and how much work had been put in unfinished stories. Then wait for instructions for the next phase.
Download the poster and print it on A3 paper, 1 for each team
Download the facilitators instruction guide to facilitate the game
The game takes about 20 – 30 minutes to play.
Place groups by 4 with the game poster on the table along with the exact number of pieces of Lego in each colour. If there are 5 people in the group, you ask one of the players to be the “scrum master” or facilitator of the team, and ask that person to take notes and handle the process of the game. If there are only 4 players, you ask who in the team will be the facilitator, that person will then be a player as well. With less than 4 players, a person may handle more than one colour.
The colours must also be in the right order, as shown on the poster, to make the game work well.
It is important that you tell the players that the different colours represent different expert roles, pick roles that they have in their organisation to connect to their reality. Red could be the tester, white the back end developer, yellow the UX and blue the front end developer.
The game runs in 2 iterations, after the first iteration you make a big metric board (see image) and ask each team to report their metrics.
- On what round did they finish each story?
- How many missed turns?
- How many unfinished stories?
It can also be very interesting to see what different results each team get.
Start the second iteration by giving all teams new copies of the poster and ask them to break up the Lego pieces again, bring it back in 4 colour stacks. But now they should all give away 2 pieces of their colour to each player. All players should now have 6 of “their” colour and 2 pieces of the other colours. Now they are more likely to be able to help each other and work as a team since all team members are allowed use more competences than one. This is something we call T-shaped team members, you have a main area of expertise but can do some work outside of it.
After the second iteration you take all metrics again from each team. Compare with the first iteration. Now you can have discussions around team work where all team members can help out and how that affects their deliveries. Ask the group for their reflections after the game has ended, there is usually a lot if these type of problems exists.
Example of questions to discuss after last iteration:
- What would happen if I only do one type of work and I go for a leave?
- What happens if one team member’s expertise is not included in the most prioritized story?
- What would happen if we would let some other team “borrow” the yellow player in the first round?
- What happens when we don’t deliver the most prioritized story, but all the rest?
- What happens if all stories are unfinished in the end of a sprint because of how we work?
- What happens when some team members only can do their work in the end of the sprint, and all others are done?
- What happens when we split our stories so that every one can help out?
- What happens if we let not only experts do all type of work. How can we make that possible in reality?
- What would happen if we stopped having roles as titles, and “just” team-members instead?
This game was created by Per Lundholm and Mia Kolmodin, tailored to be a part of our course “Lean Team” to make the course participants experience the problems with Agile teams working in silos and how that easily can be improved – and then we teach them the tools, methods and process to do so during the course 🙂 Let us know if you are interested in taking the course internally for all your teams, then we can come and visit you, or if you want to participate in our open course at Crisp.
Hope you will enjoy the game and that it works for you to improve collaborative work in teams.
We would love if you would let us know what you think!