How to teach integration development to management with Legos


The old saying goes: “a chain is only as strong as its weakest link”. In that sense it’s rather strange that a lot of the IT projects I’ve witnessed have skirted around the combined integration testing between two teams.

Usually this becomes apparent when the product is being demoed for the first time. The teams show how the two systems connect with each other. Then it’s time for the questions. I’ve got a pre-selected bundle of questions that I ask:

  • What happens if the system A tries to send information to system B but the system B is down? Is the message queued or is it lost?
  • What happens if the system A is sending information to system B but the data connection breaks during the send? Is the entire message resent? Is there a possibility that some of the data has reached system B and for instance the message’s unique id number is already filled?
  • Does system B send back any confirmation to system A? What if this confirmation is not sent? Will system A retry its message?
  • Does the system A allow system B to change anything? Is the integration push or pull or does it work with queries?

These questions might seem obvious and the answers to them should be obvious as well. If the development team can answer them right away with good arguments, the situation is good. However if any of them are answered with a blank stare and “well…I don’t really know” then the situation is bad.

A lot can go wrong even if all the components of the system are tried and tested but the integration hasn’t been thought of.  But who should think of these things? The team leaders, the architects, the product owners.

As so, I present you with a quick workshop for management to understand the importance of integration planning.

What do you need?

  • Two boxes of Legos. They don’t necessarily _need_ to be Legos, they can also be Duplos or any other type of blocks.
  • Either two rooms (one for the other team and one for the other) or a big room with corners for both teams
  • A whiteboard and markers for requirements
  • Some post-its and pencils
  • A stopwatch (or an alarm clock)
  • 4-8 people
  • A couple of hours for doing and discussion


How to do the exercise

The first flight

Divide the group into two. Preferably put together people that don’t know each other yet as this depicts the development team that has been hand-picked by management.

Give a box of Legos to both teams.

Write on the whiteboard the assignment: let’s build a spaceship! Write requirements on the whiteboard. They can be eg.

  • The spaceship must be able to carry 8 legopersons and a 5 cm x 5 cm x 5 cm Lego block.
  • The spaceship must fit into a certain area drawn on a grid paper
  • The spaceship must have 4 engines
  • You have to be able to “fly” the ship by keeping it in one hand

You can think of other ones as well.

Now, send the other team into the other room and let the other one stay in the first room.

Go to the teams separately. Assign the front half of the spaceship for the other team and the back half to the other.

Give the teams 10 minutes to build their components and then bring them back into the first room. Let them then attach the two parts together in two minutes so that the spaceship can be flown by taking it into your hand and swooshing it around the space.

Chances are that the two minutes timespace is not enough for the teams to be able to connect the two parts together.

So there’s your lesson one: Communication. Dismantle the spaceship and go to the next phase.

The Waterfall phase

Wipe the whiteboard and make new requirements. They can be anything, just keep the “swoosh around the room with one hand” requirement.

After writing down the requirements let the two team plan their approach together for five minutes. Give them the pencils and post-its so they can agree on things. Then after five minutes divide the teams again.

Now go and throw a wrench in their works. Write down on post-its some specific requirements for both teams that the other team doesn’t know about.

The back half team could for instance get a requirement that the company doesn’t have a big enough hall to house anything that’s bigger than 10 x 10 on a grid paper.

The front half team could have a requirement that they need to incorporate the “government-approved control system” into their half that is a bulky and weird contraption of Legos you just happened to whip up.

Then after 10 minutes let the teams again try to connect the two pieces together. It might be a bit easier but the unspoken private requirements will probably create problems.

That’s the lesson number two: there are usually more stakeholders in the project than just the two

Dismantle the spaceship and go to the final phase.

The Agile phase

Once again wipe the whiteboard and rewrite the requirements, all except the “swoosh!” one. Let the teams discuss for two minutes and then send them to their own rooms. Give both again the unexpected private requirements.

This time let the teams use a “quick meeting” option. After three minutes they have the option to meet with each other for a minute, glance at each other’s product and make required changes to their plans. The development clock stops during the meetings, so the time is 3+1+3+1+4 = 10 minutes of “development” time and short meetings.

Now even though the teams have received their mystery requirements, they can tell these things to the other party and they can plan accordingly. Yes, one minute is a short time, it keeps the exercise hectic.

The importance of communicating everything to the other party in order to work for the final product should now be a bit clearer than before. Discuss how the exercise might have changed the viewpoint of the participants.

What else?

This exercise is something that has been rolling around in my head for quite a while now.  I’ve never run it on any group but probably will in the near future. As such, the time constraints might be a bit off. If anyone is inspired and wants to run it, let me know how well the exercise went and what changes you would make to it. I would really appreciate it!

Sogeti Labs


SogetiLabs gathers distinguished technology leaders from around the Sogeti world. It is an initiative explaining not how IT works, but what IT means for business.

Related Posts

Your email address will not be published. Required fields are marked *

  1. Anna Lenkiewicz August 14, 2018 Reply


    One of our leaders ran a similar exercise. It was supposed to show Agile way of working (the only thing was that both teams had to deliver the same product – no integration) but really to me it showed the team dynamics very well. So
    – if you have one ‘loud and pushy’ person in a team then the rest of the team does not have a chance to contribute too much as there is not much time and people will just give up. Place similar personalities together as pushy people will push each other and quiet people with their idea may deliver additional stuff.
    – just before the exercise, the quieter part of the team hurdled together and we were kind of hoping we will work together but then we were shuffled and unfortunately each part got at least one of the ‘leaders’ (loud and pushy).
    – we got a last minute requirement which the other part of the team with 3 pushy people implemented. in our part there was just 1 person like this so all quiet people simply didn’t do it and the feedback was the it was last minute ridiculous requirement not possible to deliver why no one questioned? Our answer was ‘we just didn’t do it’ and no one mentioned that we didn’t want to waste our time on arguments with the pushy person who already decided that we have to do it and better than the other team 😉
    – also some people were highly skilled but as in this team pushy people take over and no one listens to good ideas, they simply were getting on with their stuff and everyone was surprised that introverts are so highly skilled (I was among them).
    So, give more space to quiet ones and group teams accordingly. The loudest is not necessarily a born leader, that person is simply loud.