Demonstrates the problems that occur when we don’t integrate frequently enough.

Continuous Integration


Start with five teams, ideally split across tables so they can’t see what the other teams are doing. If you can only have four then drop the crane.

If it’s not possible to physically split the groups then try to group them so that the teams are staggered. For example, teams 1 and 3 at one table rather than 1 and 2.

Background scenario

We’re going to some exotic destination [it really doesn’t matter where] and when we’re there, we’re going to bring some gifts back and this group is going to help us do that.

  • Team 1 will build the gifts to be brought back.
  • Team 2 will build the container that the gifts will be put in.
  • Team 3 will build the truck to hold the container.
  • Team 4 will build the crane that will build the crane to lift the container from the truck to the ship.
  • Team 5 will build the ship.

Round one

  • Teams are given their instructions and told to start building. They have three minutes to build and at the end, we’ll integrate all the pieces.
  • Teams will often ask if they are allowed to talk to the other teams and while we don’t say no, we want to make that unattractive. “I’m not sure if you have time for that”, “If you really want to” etc.
  • When the time is up, integrate all the pieces. I generally get everyone to stand up and move over to the first area at this point. Movement will help re-engage anyone who is getting distracted.
  • Do the gifts fit in the container? Does the container fit on the truck? Is the crane appropriately sized for the container? What about the ship? Have people move from one table to the next as we integrate the pieces. Have some fun with this - when done well, people will be laughing through the integration as they realize their mistakes.
  • Hold a quick retrospective. What went well? What needs improvement?
  • If they actually delivered and they don’t call that out as something that went well, then point that out to them. Most groups won’t deliver on the first round and some can’t even deliver after three.
  • During integration, as we’re moving LEGO builds from table to table, it’s quite common to have things break apart and this is a good place to call out the problems with “fragile code”. The more we can get people laughing, the better the lessons will stick.

Round two

Teams have mostly the same instructions.

  • This time they have one minute to plan (not allowed to touch the LEGO® during this time) and then three minutes to build.
  • This time if the teams want to talk to each other, we don’t discourage it. We don’t suggest it to them though.
  • Hold a quick retrospective, same as before. Have they actually delivered anything yet? Remember that if gifts can’t get as far as the ship, there is no value being delivered.

Round three

Same rules as round two. If they had already had success in earlier rounds then this time they’re just optimizing the process. If they haven’t delivered gifts yet then this is their last chance.

Round four

While we don’t actually do a fourth build, I ask the participants what they would do differently if we did. That leads into the debrief questions.


  • “What did you notice? Any surprises?”
    We’ve seen teams that deliver gifts on the first round and other groups that can’t deliver even after three. Discuss how early they could deliver end to end.
  • “What did they do to improve?”
    Typically, teams don’t integrate until the end on round 1 and all work together, integrating continuously, by round 3. Did that happen here?
  • Typically each round, the LEGO builds become more and more complex. I remind them of simplicity and ask how small it could have been. The reality is that each gift could have been a 1x1 brick but almost nobody builds it that way. The size of the gifts then drives the sizes of each of the subsequent components.
  • I remind them that the requirements called for the gifts getting to the ship. “Did we actually need the container, the truck, and the crane?”
    The answer of course is no. None of those things added to the value of getting the gifts to the ship. They were technical implementation details, not value to the customer.
  • “So why did we build the container, the truck, and the container, if they added no business value?”
    Because our product owner said so. This leads into a discussion of whether the product owner should have any say in technical implementation details.