Throw it over the wall: A lego game which can shift waterfall mindsets

I’ve realised recently just how deceptively powerful games can be. They can open people up to different ways of thinking, and promote learning through real experience. Games are a great alternative to telling people what to think (or telling people that what they think is wrong). A good game can furnish someone with new experience, new knowledge, and openness to learning more. I’d like to share a game with you today, one which I have found to be a powerful mindset shifter. I call it the “throw it over the wall” game.

This game simulates “waterfall”, which is a phase-driven approach to making things.

When to use the “throw it over the wall” game

You might like to use this game if you’re supporting people to transition out of a waterfall-driven product development culture. You can also use this game to help people see the value in agile ways of working, if they’re having trouble with that.

Materials you’ll need

• Lego bricks
• Pictures of things people could build with lego bricks (I used photos of houses).
• Enough participants to form at least two teams
• Something for the teams to write on

1. Introduction

Introduce the game, get people into teams, and give the customers a picture.

Firstly, make sure your lego bricks are well hidden, to keep them a surprise. Tell the room that we’re going to do a little exercise on analysis. You can be tantalisingly vague and not give any more information than that.

Split people into teams, and find someone to be the customer for each team. It could be that you are the customer, or it could be that you find other people to play that role. Give each customer a picture, and say it’s for their eyes only. That is, ask them not to let their team see the picture. This is simulating the real life scenario where only the customer can see their vision.

Examples of pictures that you could give to customers

2. Analysis phase

Each team asks their customers questions, write a requirements document and gets it signed off by their customer.

Now it’s time for each team to complete an analysis phase. It’s the team’s job to produce a written requirements document. They’ll need to ask a series of questions to the customer which will help them produce written requirements. The customer will answer questions by referring back to their ‘vision’ (ie the picture you gave them earlier).

There’s one rule for the team: every requirement that they write must start with “The product shall…”

The customer might want to be difficult on purpose. They could give vague answers, trying to simulate a customer who doesn’t know what they want until they see some product.

You may want to timebox this analysis phase, or you might choose to finish it when there’s a few documented requirements. Either way, when the requirements are written, then ask the teams to get sign off from their customer. The customers are signing off that the answers they gave to the team are represented accurately.

3. Development phase

Throw the documents “over the wall”, complete development and get customer feedback

Now that the analysis phase is complete, the teams can move into the development phase. Everyone in the room (including the customers, if they want) is now a developer. Ask each team to hand over the requirements that they’ve written to another team in the room. The analysis is done, time to “throw it over the wall” to the development team! This is the name of the game.

By now people might be wondering how they’re going to build this thing that’s documented in the requirements they’ve just received. You can do a big reveal, telling everyone that lego bricks will be the tool that the teams use to build their product.

And so the development phase begins! You might see some confused expressions as people look at their lego bricks, look at their written requirements, and look back at their lego bricks again. “The requirements say that it needs to be blue, but we only have red bricks! What do we do?” Unfortunately they can’t ask their customer, because the customer already talked to the analysis team and they’re very busy.

When you’re ready to conclude the development phase, ask the teams to show their customer what they’ve made. The customer is then free to give their final verdict. Let the team absorb that for a moment. Once they’ve had a chance to digest the feedback, ask the customers to show the team what their ‘vision’ was — ie give everyone a look at their picture.

What the team might have made vs what the customer wanted

4. Debrief

Bring the room back together, and ask some questions to tease out the experience.

What was that experience like?

How did it feel to hand over your final product to the customer?

How did it feel to receive the customers final verdict?

What did you find challenging about this game?

Are you feeling any of these challenges in your current way of working?

Here’s some of the challenges of the game connected to learning objectives. This might be useful material for you to guide debrief conversations:

If the people in your room have experienced these challenges before, they will probably find it helpful to have their pains labelled. You can talk about how labelling challenges is a great way to see them with more clarity. Labelling painful things also diminishes the chaos or hurt that they can cause. People might start to feel a little hopeful that things can change.

Here’s an opportunity! You can show people an alternative way of working at this point. A way of working which will feel positive and far less challenged.

5. Let’s do something different

This is where your flavour comes in. What kind of alternative way of working would you like to present for the next round of lego building? It’s up to you. You can explore “agile” concepts here if they feel meaningful.

Take a look back at the challenges of the game. How would you design alternative work processes that give people a much more positive experience? You might want to figure this out up front, so you’re ready to prescribe it to your game participants. Better still, you might co-design a new way of working with the people in the room — ask people how they might address the challenges they felt.

Here’s my ideas for an alternative way of working:

• Analysis and development don’t have to be done by different teams. The same team will be working on their product from start to finish!
• There don’t even have to be separate analysis and development phases. You can do ‘analysis’ and ‘development’ whenever you like.
• You don’t have to try and figure out what the customer wants through written requirements. You can draw pictures, make prototypes, whatever you like.
• Customer communication doesn’t have to be restricted to the analysis phase. Teams can talk to their customer regularly as they’re building things, to show them work in progress and get their feedback.

Whatever you come up with, make sure everyone in the room understands how this new process will work. Now we’re ready to do another round! Ask your people to return to their roles of team or customer. Give the customers different pictures to form their ‘vision’, and remind them it’s for their eyes only.

Time to get started! Feel free to give people a prompt of how they can get started, if they’re looking a little lost.

This round will finish either by the end of your timebox, or when you feel that people have had enough time to experience your new way of working. Once things are finished, ask the teams to show the customers what they’ve made. The customer can give their final feedback and share their picture with their team.

To debrief after this round, invite people to reflect.

How was this experience different to what you tried before?

Think about the challenges we talked about before. How were they addressed in this way of working?

That’s all! The game is done. Package your final takeaways, present them to your people, and set them free to apply what they’ve learned.

Parting thoughts

I call this game “throw it over the wall”. It helps people to really feel some of the challenges inherent in waterfall-driven ways of working. And then, it presents an alternative option. Your participants will be able to see their pain melting away. You don’t need to keep having conversations about how waterfall sucks for doing complex, unpredictable work. You can start with this game instead!

I’d love to hear from anyone who wants to try running this game, or anyone who has thoughts on developing it further. I’ve left a conversation starter in the comment section.

This game is heavily inspired by a conversation I had with Laurna Munro, and also by the Lego4Scrum body of work. Big thanks to Craig McDougall for inviting me to come up with this game and teach it at MSD! Thanks also to Ming Janssen and Chris Starling for their feedback which helped to shape this write-up.