Visualise interruptions on a LEGO Wall

As part of the apprentice-craftsmen Programme at Codurance, I had the privilege to attend the Certified Scrum Product Owner course at Skills Matter. During the two-day course, I learnt many techniques to deliver value efficiently, and I am going to share a less widely known tool to help teams visualise interruptions.

Keeping track of interruptions helps teams improve their productivity during inspect and adapt activities such as daily meetings and retrospectives. In order to turn impediments into opportunities, both development team and stakeholders should collaborate, support and trust each other. These concepts are at the foundation of “shared responsibility”: everybody is responsible for the success of the business.

Sharing opinions about what is decelerating the team performance is easy in the best-case scenario where we know that no one will assign blame. However, the culture of fear is still widespread in most organisations and people are afraid of being blamed. When people stop sharing their concerns, they lose motivation and start to leave it to the Scrum Master and the Product Owner to fix their problems.

Team members' concerns turn into frustrations and become internalised. Impediments become even harder to identify when people are afraid to speak up in front of stakeholders.

The LEGO Wall

The LEGO Wall has been conceived to reduce the fear factor when identifying impediments. It is an artifact to keep interruptions visible while ensuring anonymity.

The whole Scrum Team (Product Owner included!) is involved and the Scrum Master facilitates the LEGO Wall Setup Session, explaining the importance of tracking interruptions. The LEGO Wall gives voice to the team’s frustrations. By collecting and displaying real data, it creates the conditions to discuss the interruptions. At a glance, the team is able understand:

  • How much time they spend working on delivering the value agreed during the Sprint Planning
  • How much time they spend working on unplanned activities

The core part of the Setup Session is to build a collective understanding of the type of interruptions the team has to deal with. The teammates share their experience and at the end of the discussion they decide to keep track of top categories of interruptions – keeping them to a maximum of five. After that, they can assign a brick colour to each of them.

In the example shown in the pictures the team identified 4 categories:

  • Production Support:
  • Release Support:
  • Business as Usual:
  • Help the PO:

“Business as Usual (BAU)” is the time spent on the ceremonies and the artifacts associated with the development process. These include: meetings, creating reports, writing documents, etc.

The category “Help the PO” encompasses the activities that the development team is asked to do to help the Product Owner prioritise stories (backlog refinement sessions). In fact, these activities should be considered part of the work, but often the development team perceives these activities as interruptions. Work is not only about coding, UX design or testing; it also involves collaboration with the PO, as these activities are also essential to delivering value.

Materials and preparation

You can build a LEGO Wall with as many base plates as you need, in order to display:

  • The days of the Sprint (2 boards are enough to keep track of a 2-week Sprint)
  • As many rows as team members (4 developers as shown in the photos)
  • A legend of the colours used (4 colours + white)

You will need colourful LEGO bricks to display interruptions and LEGO figures to represent an anonymous team member.

From the pictures, you can see that the team decided to use LEGO figures to represent themselves. This is because this activity should be pleasurable as well as useful. In fact, I recommend creating your own figure as if you are playing a tabletop game. Thanks to the modularity of LEGO and the figures from movies and comics, you can be whoever you want and change your character as many times as you like, so that you can keep your anonymity.

Lego is an excellent tool to visualise interruptions because:

  • Thanks to its modularity, it is easy to split a working day in 16 1x1 blocks. A 1x1 block corresponds to 30 minutes of activity
  • Maintaining the LEGO Wall is an effortless activity
  • It is easy to get the whole team involved because LEGO bricks are beautiful and fun to play with

How to use it

I suggest you hang the LEGO Wall in a place that would be highly visible to the team and stakeholders. We want to trigger discussions in front of it. The LEGO Wall displays real and meaningful data that can be extremely useful during retrospectives. The more colourful the LEGO Wall gets the more margin of improvements the team and the organisation can work on to deliver more value.

Since the LEGO Wall is not a micro-management tool, at the end of every day, each team member should update it exclusively with bricks assigned to each category of impediment. The white bricks should be added only at the end of the Sprint. They have the function of highlighting the time spent to achieve the Sprint goal so that it’s easy to compare how much time the team has spent working and how much time has been spent on interruptions.

The power of the LEGO Wall during retrospectives

The LEGO Wall is a collector for meaningful data that shows how the Sprint went. If the LEGO Wall shows that the team has spent more time on fixing bugs then delivering new value, then they may need to put more focus on quality. Thanks to this effortless way of gathering data the team can set up discussions with stakeholders and, together, find ways to reduce impediments and improve team capacity. Production and release support interruptions are an opportunity to invest in better delivery practices.

BAU interruptions can be reduced by asking a couple of questions:

  • Why was the meeting or the deliverable necessary?
  • Does the Sprint goal have any business value (or are we just following a process)?

If the answer to the second question is YES then it means that it’s not an interruption but it’s work that should be prioritised.

Conclusion

The LEGO Wall is a powerful tool to get an idea on how much time the team can spend on working to deliver new value instead of working on problems inherited from previous Sprints.

However, this is not a step-by-step recipe because this tool can be used in several ways according to the following variables:

  • How experienced the team is
  • The type of interruptions
  • The environment
  • How the company is organised

I suggest staying focused on the principles and importance of this activity (honesty, transparency, courage, inspect and adapt). Don't be afraid of experimenting and changing this to suit your needs. If you start looking at things from another perspective, you might realise that impediments and interruptions are actually opportunities for improvement.


I’ll be happy to hear about your stories and know how you set your LEGO Wall. Which kind of impediments your team has to face? What is dragging your performance down at the moment? Feel free to contact me and send me your pictures! I hope to see walls different from mine so that I can collect them and make them become a source of inspiration for the community. Cheers!

About the author

Giulia has worked as a design consultant and art director in an integrated communications agency for more than ten years.

During her career she has developed both the design talent and business knowledge necessary for creating meaningful holistic brand experiences.

Giulia joined Codurance as an Apprentice driven by the desire to apply the Software Craftsmanship mindset and values to the whole product development process.

She is a Certified Scrum Master and Certified Scrum Product Owner with a strong focus on the present and the future of a product, backed up by her Integrated Design background and the mastery of User Experience Design skills.

Giulia bridges stakeholders and development teams: she facilitates their collaboration in designing solutions that balance business needs, technical feasibility and user expectations.