The Lego Exercise
The Lego Exercise is a facilitation tool I learned over 25 years ago and have tweaked over the years to suit particular situations. This exercise is best done with key stakeholders, often C-level and their direct reports. The point of the exercise is to open their eyes in a new way to how systems are implemented. It works like this:
Split into 2 teams
Each team is placed on one side of the room.
Team A has a completed Lego model (behind a screen).
Team B has a pile of Legos (same model, only disassembled, also behind a screen).
Team B has 30 minutes to build a Lego model from the pile of Legos.
Can ask Team A questions to help with assembly.
Team A can tell Team B how to build the model.
Can give instructions to the team on how to assemble the object.Can only describe the object according to what is seen.
All team members must stay behind their screens.Neither team can see what the other team has.
The model has about 50 pieces and says, “For ages 6 and up” on the box. I start of by instructing the teams as follows: “Team A, you are the business. Team B, you are IT. Team A, you have an idea and you want IT to build it. In fact, you have something better than an idea: you have an actual working model. Team B, you have everything you need to successfully construct Team A’s idea. You have exactly the parts you need in front of you: no more, no less. All you have to do is let Team A describe to you what they want, and build it out of what you have in front of you. You have 30 minutes to assemble the model. Begin.”
Sounds simple, eh? In 25 years of doing this exercise, no group has ever successfully completed the exercise. Not even close. We usually end up with a quarter-build model on one side, and the original model disassembled.
There is a predictable dynamic that often emerges. One person becomes the leader, one or two assist in some way, and the rest watch. To mimic a real-life corporate environment, about halfway through the exercise I decapitate the teams. Their “leaders” are “reassigned” to another job in the company. Not exactly an uncommon real-life situation. If they were truly operating as a collaborative, agile, highly-functioning team, that shouldn’t make a difference. But, oh, it does! In one particularly telling exercise, I had two sets of teams racing each other. Halfway through, the leaders were reassigned to another team. Their leadership role in the new team was rejected outright, and the transplanted "leaders" ended up just watching. That dynamic, in and of itself, could be the topic of an entire research paper.
This exercise is quite complex, actually, and gets to the heart of issues that often vex companies: communications, language, perception, collaboration, hierarchy, politics, culture…the list is long. After the exercise is over, I often begin with a little humiliation: “How many of you have kids?” Many hands go up. “So you’re familiar with Legos?” Many nod. “And yet you couldn’t put together a toy make for a six-year-old?!”
We spend another thirty minutes discussing the following topics:
Why were the groups unable to complete the model?
How did the groups collaborate? Within the group? Across groups?
What happened to the collaborative dynamic when people were shuffled around? What about the communications?
What could have been done differently?
If Team A had had the instructions (instead of a model), would it have helped?
Was this exercise harder than it looked? Should it have been easier?
Would a collaboration tool have helped?
Is planning a form of collaboration?
Does this remind you of any real-life situations?
The discussion is usually engaging. A few common themes typically emerge:
The teams use the lowest common denominator of communication: They talk at each other. Not with each other or even to each other - at each other. Sometimes one person attempts to draw a picture on a whiteboard. They assume that use of electronic devices is prohibited, which it is not. This means that teams, as in real life, often hamstring themselves by imposing rules and barriers around themselves. Sometimes these are corporate or cultural in nature. The fear of breaking rules, real or perceived, is stronger than the urge to succeed.
The teams often use different language to describe the same part. How hard is it to describe a thin, white Lego part with 4 bumps? Pretty hard. Especially if your counterpart is calling it a “four-square.”
Not everyone in the team engages. Many participants are often content to let others take the lead and do most of the work. A real leader should assign tasks and segregate duties, not do all the work himself. There is plenty for everyone to do, especially if the tasks are distributed.
The teams never plan. They just go. Each team should take at least a few minutes to organize themselves, figure out how they will tackle the problem, and decide who will do what.
I end by pointing out the following: “This exercise was both stacked in your favor and also against you. It was deceptively simple-looking. You had an advantage in that you had an exact model in front of you. Oftentimes, we have only ideas or concepts. Here, you had something concrete. The other team had exactly what it needed. In real life, you start off with nothing. You have to figure out what you need, go find it, and then figure out how to put it together. Often, that is like trying to build something out of Legos, Tinkertoys, and an Erector set.”
This exercise highlights the very basic difficulties people and teams will have in a complex environment, with different words being used, alternate perceptions of what is “simple,” and varying agendas and motivations. After all, if you can’t collaborate enough to put together a toy made for a 6-year-old, how will you put together a complex multi-million dollar computer system?
I usually let my customer keep the assembled model. It serves as a reminder of the deceptively simple yet incredibly complex journey they are about to embark.