This activity was designed to teach continuous integration concepts and value without resorting to code, a continuous integration server, or any hardware or software.  While the participants will experience some frustration in trying to complete the activity, they will also have a great deal of fun and will learn.


  • Prep time: 30 – 60 minutes
  • Execution time: 45 – 60 minutes


One set of LEGO per team. Each set should include the necessary pieces to build a cube (see images in ZIP file) plus some random pieces. You can include base pieces or not. I don’t, because it adds to the challenge and the fun, having them figure out how to make the pieces stick together. Include at least a few flat pieces in each set, though, because it’s almost impossible without.


The participants should be divided into project teams that have between 4 and 8 people (smaller teams are preferable). Each project team should have two halves, call them left half and right half. Each half will have between 2 and 4 people. There should be as many project teams as necessary to include all participants.

Say you have 15 participants in the room (typical size). Since it’s an odd number, some grouping(s) will be off-by-one (which is acceptable). Here are the sizes of the various groupings:

Room = 15 people
Project Team = 5 people (3 project teams in room)
Left Half: 3 people
Right Half = 2 people

Here’s another way to split 15 people:

Project Team: 7 or 8 people (2 project teams)
Left Half: 4 people
Right Half: 3 or 4 people

With a group of 10 people:

Project Team: 5 people (2 project teams)
Left Half: 3 people
Right Half: 2 people

This exercise will be done in two rounds. In round one (The Waterfall Way), the halves of each project team will build a specific object, using LEGO, based on a set of “specs” – three pictures of their finished “subsystem.”

In round two (Continuous Integration), the halves of each project team will build the same object, but in iterations, performing integration at the end of each iteration.

Both rounds lead to the same goal: at the end of the round, the two subsystems fit together cleanly to create the final “system.”

The pictures below reflect the finished “system.”


The Waterfall Way (Round One)

Each half of each project team (left and right) receives their specs, and is given 3 minutes to look over their LEGO and to discuss what they’re going to build.

Left Half builds the object specified in the set of specs named left-finished-xxx.pdf.

Right Half builds the object specified in the set of specs named right-finished-xxx.pdf.

  • Neither pair gets to see the other pair’s specs
  • Neither pair gets to see the other pair’s work in progress
  • Both pairs first get to see the other pair’s “subsystem” when both pairs are done
  • When both pairs are done, they will try to fit their subsystems together
  • They will make modifications until they are successful
  • Record the time when both pairs first say they’re done, and then record the time it takes to get the two subsystems to fit together (build time, integration time, total time)
  • You will probably need to get the pairs or project teams to track their own times, depending on the size of your group
  • Expect that the teams will not finish simultaneously, so track the time per team for build
  • Expect that the two subsystems will not fit together properly – let them struggle with deciding which team should make which modifications
  • Encourage them to talk about the “specs” and figure out how to get the subsystems to fit together properly
  • Hopefully, this will be somewhat painful and frustrating for them

The Agile/Continuous Integration Way (Round Two)

As with the Waterfall examples, the project teams will be divided into two halves.

This exercise will be conducted in five iterations.

Before starting this second half, give the following instructions:

Please completely disassemble your systems down to individual blocks, and return the blocks to their buckets/boxes/bags.

Members of each left half, please get up and trade places with the right half of your project team.

For the second part of this exercise, you have now switched – left halves have become right halves, and right halves have become left halves.

For each iteration, there is a set of specs that incrementally add to the previous iteration’s results.

Iteration one is very simple – just a flat rectangle – in order to get them accustomed to building and working together in pairs, plus giving them their first experience of continuous integration with an easy one that can’t fail.

Before starting this exercise, have the pairs switch – that is, Pair Left becomes Pair Right and vice versa.

Each Iteration follows the same pattern:

  1. Receive specs
  2. 2 minutes to review and discuss specs
  3. Build (they will record the time to build)
  4. Integrate (they will record the time to integrate)

Instructions are the same as for the first exercise:

  • Neither pair gets to see the other pair’s specs for each iteration
  • Neither pair gets to see the other pair’s work in progress during an iteration
  • Both pairs first get to see the other pair’s “subsystem” when both pairs are done in each iteration
  • When both pairs are done, they will try to fit their subsystems together at the end of the iteration

At the end, they will total their build and integration times.

Learning Points: 

There is a bug in the specs. In the waterfall first round, the two halves cannot come together without a couple of tweaks. The same is true in round two, but they should get there more quickly.

  • While it is expected that each Integration stage will take a bit longer than the last in round two, each should still be pretty quick
  • One or more teams will not complete their cubes during round one. This is an opportunity for learning.
  • Some may not finish in round two, but that’s less likely.
  • Learning questions for the final debrief:
    • Did your team feel more confident in the product you were delivering each iteration?
    • How long was the integration phase in Waterfall compared to the total time spent in integration over the several XP iterations? (When overall time is roughly equal, this could be a key insight: XP teams have an easier time integrating even when the overall project timeline appears roughly identical to a waterfall Gantt chart)
    • Were there any features that could not be delivered in Waterfall because integration was too difficult/costly, whereas in XP the same features were delivered successfully?

Handouts and the slide deck I use are here

9 thoughts on “Continuous Integration with LEGO”

  1. Hi,

    Thanks for sharing the game and materials! Great stuff!!
    Do you have any ideas on games to show the importance of a green build and not committing when the production pipe is red? Maybe this one can be used for that also and I’m not seeing it yet! 🙂

  2. Are the specs (right-finished-xxx.pdf. left-finished-xxx.pdf) referenced just copies of the finished build pictures or something else? If something else, I did not find those pdfs with the rest of the docs related to this. Please advise. thanks

  3. I guess, CI and agile methods have somehow the same effect. I still think though that it is a great way to teach agile methods AND the benefits of CI, especially for non-tech people.

    Anyhow, I think there is an error in the downloadable ZIP File. A colleague of mine and me just tried it out: According to the text above, the CI way (part 2) should have 5 iterations, yet the handout ends with Layer 4 for each side (left and right). Furthermore layer 4 for each side is the finished view for part 2. I don’t know If we got something wrong or if there is really a mistake?

    Thanks for your help!

  4. Though I haven’t played it yet, this game sounds really great.

    Only thing is: I don’t see how this shows the benefits of CI, I think it rather shows the benefits of agile development. After all: You can also use TDD in a waterfall project.

    1. Thanks, Dominik. That’s a valid challenge. For me, it’s hard to separate Continuous Integration from Agile. However, this exercise doesn’t require nor imply Agile in any particular way. What it is intended to show is that continuous integration reduces the cost and time typically spent at the end by utilizing CI. That is, the first round is intended to show the classic situation in which one significant bug can lead to significant rework. The second round is intended to show how doing integration incrementally reduces the time and cost. It consistently does take less time for round two than for round one. This is not about developers doing TDD, although that’s a valid point. You can also use CI on a waterfall project. However I don’t think that negates the learning this introduced. It’s not intended specifically to teach developers CI – although it can – but to teach the general concepts.

Comments are closed.