Team Health Checks
One of the dynamics that I have observed while working in a great many organizations over the years is this: when leaders say that they care about employee engagement and satisfaction, there is often ample evidence to the contrary. One of the most obvious signs of this gap between words and deeds is apparent when it comes to what benchmarks organizations choose to measure themselves against.
Team Health Checks are an example of a technique that can help provide insight into a wide range of topics that can have a material impact on employee happiness and satisfaction, and they can also be a part of the measurements and metrics that organizations choose to collect. Another challenge that we face is that many more traditional measures are lagging indicators, which in practice means that we might not discover there are issues we need to address until things have gone significantly off of the rails. By using Team Health Checks, we have an opportunity to get visibility into what’s going on in a team’s context, and/or across a group of teams, at a particular moment in time.
Team Health Check Anti-Patterns
Before discussing examples of Team Health Check technique, let’s consider ways in which Team Health Checks can do more harm than good. Andy Cleff offers some excellent advice in his blog post Agile Team Health & Morale Checks:
- “A health check model is not a competition nor a comparison across teams. If team A is mostly green and team B is mostly red, that doesn’t mean team A is “better”. It could just as well mean that team A has a simpler context or a more optimistic outlook, or that team B is more honest about their struggles. Either way, the model and visualization tool is about support and improvement, not judgment. The organization’s attitude should be ‘how can we help?’ and not ‘why are you guys worse than the others?’
- This is not an incentivized model — there’s no reason for a team to want to game things just to ‘look good.’ Our teams intrinsically want to succeed and will perform as well as they can under given circumstances. This model is meant solely as a tool to help boost and focus team improvement efforts, for the sake of improvement alone.
- ‘Done.’ Like everything we do, inspect and adapt. If this model helps teams, keep doing it. If there are ways to make the model more useful, try them. If a team finds no value in this, stop it.”
Examples of Team Health Checks
There are numerous examples of Team Health Checks, and we’ll cover a couple of them in this section:
- Atlassian Team Health Monitor
- Spotify Squad Health Check
Atlassian Team Health Monitor
Atlassian’s Team Health Monitor, which is part of the Atlassian Team Playbook, provides a method for assessing the health of various types of teams, based on a set of eight attributes that Atlassian has found to be instructive when it comes to helping teams self-assess. The three types of teams are:
- Project Team (analogous to what many practitioners might call a Feature Team)
- Leadership Team (C-level executives or other groups of leaders/managers)
- Service Team (examples include Operations teams and Support teams)
For the purposes of this post, we’ll focus on the Project Team form of the Team Health Monitor.
Note: For a short (1-minute) overview of how the health monitor works, see the Atlassian Team Playbook Health Monitor video.
Health Monitor Grid
The health Monitor Grid serves as the basic framework for the activity. Either draw the grid on a white board, use downloadable .pdf version of it, or create your own physical or electronic representation.
Below is an example of what a completed Health Monitor Grid might look like.
Ratings
For each area of the eight areas shown in the Health Monitor Grid, we can ask team members to rank where they feel they are, using the color coding scheme below.
Color Coding
- Green (Thumbs-up) — We’re strong here
- Yellow (Thumbs-sideways) — We’re okay, but a little shaky
- Red (Thumbs-down) — We’re not okay
Areas of Inquiry (Attributes)
Below is a list of the areas of inquiry (attributes) that are part of the Health Monitor, along with some examples of what green or red might look like.
Spotify Squad Health Check
The Spotify Squad Health Check has evolved over time, and as the name implies, was first introduced at Spotify many years ago. It includes 11 areas of inquiry, with three potential ratings, similar to the green/yellow/red that we saw in the Atlassian Team Health Monitor. As Jimmy Janlén points out in his blog post Health checks for Teams and Leadership, the nature of the questions that are asked can and should be adjusted for the organizational and team context. Jimmy also includes links to Google Slides and a Google Sheet to help us get a head start with using this in our own organizations.
Note: Jimmy also offers variations on the health check, customized for leadership teams and Communities of Practice, respectively.
It is important to point out that the Spotify Squad Health Check is ideally suited for collecting data in a cross-team context, where a “Tribe” is a collection of teams, or “Squads.” Below is an example of a visualization showing the high level results across an entire Tribe, consisting of seven Squads, from one of the earliest public descriptions of this technique (in 2014), by Henrik Kniberg, titled Squad Health Check model — visualizing what to improve.
In a spirit of continuous improvement, we might well imagine how clusters of like colors can send important signals. For instance, in the example above, four of the seven Squads indicated significant concerns about the health of the codebase, which should send a clear signal that follow-up conversations would be wise, to better understand what is happening. For instance, a likely culprit might be that the teams are being pressed to meet unrealistic deadlines and are cutting corners as a result, which is causing technical debt to increase.
Below is a longer description of one version of the Spotify Squad Health Check, as described by Andy Cleff in the previously mentioned blog post:
Ratings
For each area of inquiry, we ask each team to rank where they are and what the trend is (stable, improving, or getting worse), where color coding and arrows help with visualization.
Color Coding
- Green — Awesome; doesn’t necessarily mean things are perfect; what it does mean is that the team is happy with this area, and sees no need for improvement right now
- Yellow — There are some problems that need to be addressed, but it’s not (yet) a dumpster fire.
- Red — The situation is really poor and we need to do something to address it right away.
Trends
- Up arrow — Things are getting better over time
- Down arrow — Things are getting worse over time
- No arrow — Things are basically stable over time
Areas of Inquiry
The areas of inquiry, based on Andy Cleff’s modifications to the Squad Health Check, are listed below, along with examples of what green and red ratings might mean for each area.
Where Team Health Checks Can Fit in the Broader Context of Agile Metrics
Getting back to the topic of metrics, in an Agile context, there are certain metrics that tend to get a great deal of attention (such as Velocity), while other areas get scant attention or no attention at all. There are different labels or categories under which Team Health Checks might fit, and one such label is “Collaboration Metrics.”
For instance, in the Excella Guide to Measuring Impact with Agile Metrics, in addition to gathering insights related to satisfaction and happiness, via techniques such as the Atlassian Team Health Monitor and the Spotify Squad Health Check, which can help us understand what’s going on an the individual team and cross-team level, respectively, there are other areas we can potentially look at, such as the number of cross-team dependencies identified and closed, and also what impact those dependencies might have on lead time and cycle time.
Note: For more information about lead time and cycle time, and what they can tell us about team flow, see the Excella Labs blog post How’s Your Team’s Flow? Measure it to Master It! And for an additional perspective about dependencies, see my blog post Dependency Management Techniques.
Conclusion
As is the case with any technique, it’s important for us to first get familiar with the technique, understand what it can and cannot tell us, and make sure we’re transparent about it and get buy-in from team(s) before taking it for a test-drive. The bottom line is this: if we really care about employees, what they think, and what is most likely to make them satisfied or dissatisfied with their work, a Team Health Check is one tool that can potentially give us visibility into this important and often neglected area.
And, there are a great many other techniques to choose from. A couple of years ago, I worked with one of my colleagues at Excella, Joe Morrison, to pull together a broad sample of techniques, which might fall under categories like “assessments,” “checklists,” “explorations,” and “surveys.” We shared what we found via this public Trello board called Agile Exploration Techniques.
