How I Used the Spotify Squad Health Check Model

Yesterday I facilitated a retrospective within a medium-sized (±30) web agency. I truly love these kinds of companies. Most of them are…

Yesterday I facilitated a retrospective within a medium-sized (±30) web agency. I truly love these kinds of companies. Most of them are full of passionate, energetic, and creative people. Getting an interactive, fun, and collaborative session isn’t difficult. Everyone is eager to learn and help each other out, yesterdays session proved to be a great example!

Beforehand, I only knew the team had some issues, didn’t do a retrospective that often, and was curious about which areas they could improve. Therefore I was looking for a retrospective format that focused on the team as a whole that would cover all the relevant areas. Given this context, the Spotify Squad Health Check Model seemed appropriate. I’ve wanted to use this model for a long time, but today I finally found the opportunity!

What is the ‘Squad Health Check Model’ about?

It’s an approach that visualizes the ‘health’ of a team. It covers areas like teamwork, fun, easy-to-release, learning, and health of the codebase. While discussing the different health indicators, the team builds up self-awareness about what’s working and what’s not. The broad selection of questions helps expand their perspective. Perhaps they were well aware of the code quality issues but hadn’t really thought about the customer value perspective, or how fast they learn. It also provides a balanced perspective, showing the good stuff as well as the pain points.

What’s the source?

Henrik Kniberg and Kristian Lindwall shared this approach via this website. It contains a comprehensive description of how to use it, therefore I’ll only share my approach, takeaways, and lessons learned.

Duration

2 hours.

What you need

A printed version of
The indicators with the different topics
The ‘traffic lights’ (green, orange, red)
The instructions
Markers and pens
A large whiteboard or flip chart sheets
Sticky notes

How I’ve used it

For the entire session I used the standard approach for a retrospective:

Setting the stage (15 minutes)

I briefly explained the format and instructions and shared the different topics we would cover.
If the team finds a topic irrelevant or they miss a specific area, this is a good moment to remove or add it.

Gather data (30 minutes)

Per indicator, I shared the positive and negative description that is written down on every card.
Every participant decided for themselves what color was most suitable. Green = good, yellow = some problems, red = really bad. When everyone had made a choice they showed it to each other.
I didn’t discuss the results in detail but only wrote them down on the whiteboard.
The next step was to determine the trend, is this generally improving or getting worse? The question mark indicates that on average the trend might seem stable but there were a lot of differences between the team members.

Generate insights (30 minutes)

Because of the group size (12 participants), I created two sub-teams. Every group studied the result and discussed it within their team, taking a few minutes per topic.
The insights were written down on sticky notes and placed on the whiteboard.
Every team presented their insights to each other and briefly discussed the questions and peculiarities.

Decide what to do (30 minutes)

Defining concrete improvements, agreements, and actions was the next step. Dot-voting all the specific insights would be too much, therefore we decided to dot-vote the eleven topics.
‘Health of the codebase’ and ‘pawns or players’ turned out to be the most urgent topics to discuss in more detail.
Again the group was divided into two subteams, this time people could join the team with the topic they found most interesting.
Each of the teams discussed the topic in-depth with each other and defined concrete improvements and agreements.
After 20 minutes the results were shared and presented. An important step was to rewrite the results into actionable improvements and clear agreements.

Close the retrospective (15 minutes)

As a closing of the retrospective, we discussed how we could ensure the improvements and agreements would be realized. Defining ‘topic owners’ and planning a new session were some of the ideas for this.
The ROTI (Return On Time Invested) was the last part of the retrospective. The result was positive, therefore this format proved to be valuable enough to use more often!

Wrap-up

I consider the Squad Health Check Model a very fun and valuable approach to assessing a team's health’. Especially the opportunity to add/remove topics ensures it can be suitable for all kinds of teams. Using this approach periodically will give the team some great insights into their current state and the areas in which they can improve themselves.

I hope this blog post inspires you to give this workshop a try yourself. If so, I would really like to hear about your experiences! And of course, helping you out by facilitating this workshop is always negotiable.