Retrospective: Squad Health Check
It’s great to have insight in aspects of the team that need improvement. This way, you know what to focus your efforts on. Unfortunately (or fortunately, depending on how you look at it) there are hundreds of Retrospective formats to measure the current state of the Scrum Team, and to determine what to do next.
One of those formats is the Squad Health Check, which originated from Spotify in 2014. In my own Scrum Team (the “Squad”) we’ve picked up this format halfway through 2017 and we’ve used it a couple of times now. This allowed me to form an opinion on the format and now I want to share it with you... It’s great!
When using this format, the team will judge several subjects by how satisfied they are about their current way of working. Let’s first see what “default” subjects are provided by the Squad Health Check.
- Easy to release
- Suitable process
- Tech quality
- Pawns or players
Important to note is that these default subjects all have an Example of Awesome and an Example of Crappy provided. For Easy to release these examples are:
Example of Awesome: Releasing is simple, safe, painless & mostly automated.
Example of Crappy: Releasing is risky, painful, lots of manual work, and takes forever.
The peple who made this format up say the following about the subjects/questions: “These questions are just a starting point, a default selection. Squads are free to remove, add, or change the questions to whatever they think is relevant.”. Use this advice and remove the questions that don’t make much sense for your team, while adding others which fit better.
That’s enough about the subjects, now let’s see what we can do with them.
The subjects will be assessed by the team based on personal opinion about their satisfaction, one subject at a time. The team will rate this subject by holding up a traffic sign which is either on green, yellow or red. It will describe whether or not this team member wants to change their current way of working, or thinks that improvement is necessary.
When we look at - for example - easy to release, the following situation may occur. Team member A might hold up a green traffic sign argumenting: “I know that our current release process consists of two team members placing files on a server for 4 hours straight… but that’s fine with me, I think we should focus on other improvements and ignore this one for now.” while another team member B will hold up a red traffic sign argumenting: “It’s unacceptable that we need people to release our software, we should automate it completely!”.
An example that comes straight from my own squad is the dissatisfaction about the current state of the codebase (10 votes; 7 of them were red traffic signs compared to 0 a previous Squad Health Check). The discussion that followed resulted in more time made available for quality improvements.
Once input is gathered from all team members, the result should be an average score per subject. You should then use a format you like for determining improvements, this Squad Health Check is aimed just at the collection of data from the team.
I really like the idea of rating different aspects of your team based on what the team members believe is most important, instead of objectively looking at the process and comparing it to some kind of ideal scenario. You should use this format once every few months (Spotify advises to start quarterly), and use other formats to collect objective data in other Retrospectives. Just try it out a couple of times, and see if you can discover a trend in your results.naar overzicht