4 years of squad health checks
Earlier in January, we ran our squad health check for Q4 2018. We invited an observer that was keen to discover the activity, and see if it would be beneficial for his own team. We had a quick chat at the end of the hour about my experience as a manager, and it suddenly hit me that I had been running squad health checks for the better part of the last 4 years… Time flies! Here are some thoughts on this activity.
Squad health checks?
If you have never heard about it, a squad health check is a small workshop to get a pulse on how a team feels it is doing. It was introduced by Spotify in this article. In one line, a facilitator describes a category such as “teamwork”, “health of codebase” or “easy to release” and get all team members to vote on how they feel about it with red/amber/green cards. A quick conversation follows where people explain their vote.
There is no point for me to paraphrase the Spotify blog post, so go check it out if you are not familiar with it!
4 years later, why do I keep doing it?
A squad health check is one of the easiest activity one can introduce in an organization, even if the teams are not used to these kinds of Agile workshops. It only takes ~1h every quarter and in my experience, there is low resistance to it. All it takes is something like that: “People, I’d like for us to take an hour to reflect on what works and what doesn’t in the team. Would you mind trying? What’s the worse that can happen? Loosing 1 hour of our time? What’s the potential upside though?” Better, I always get my team to vote on whether they want to rerun the activity next quarter (or teams for which I act as facilitator). I’m yet to find one where there isn’t an overwhelming majority for it. I actually realized a couple of months ago that most of the dev teams in my company were now running those, I had no idea. Long story short, it’s a great way to start changing the culture.
I’m often asked what do we do with the collected data. While this is a relevant question, I came to realize that the main benefit from a squad health check is less about taking actions and more about building empathy within the team. It’s about getting people to share their thoughts without being judged, building psychological safety and releasing the pressure. They can vent, they can joke, they can laugh. As a leader, this is not your meeting even though this is a great way to get signal, this is theirs! Do not intervene, do not talk, do not try to correct anyone. You are here to listen, so keep your thoughts to yourself. To be honest, I’m yet to have a massive revelation after 4 years. I guess it’s a good sign. However, I always get small things here and there that I was not aware of, especially in a big team. I will write a note about it and follow up in the following days. Possibly ask about some of those in my next 1:1 or deliver a message to the whole team in my next staff meeting.
Interestingly, people tend to mentor each other during the discussion. For instance, a team member mentioned that we were creating too much technical debt at times. Someone quite senior responded that he thought the team had a lot of freedom to tackle it. However, few people were actually taking the opportunity, choosing to focus instead on features. These were exactly my thoughts too, but I didn’t have to intervene: the team reached the same conclusion without me.
It’s also a good opportunity to think about how much you have progressed in the last quarters. Well… hopefully :-). I’m always pushing my people to challenge the status quo, which means they/I sometimes forget where we are coming from. This time I was slightly surprised by people voting amber for “easy to release”, considering that we automatically deploy commits that reach master in production. It can’t be more automated than that! And sure, there were a few comments about why most of our older apps don’t have this feature enabled, fair enough. At this point, someone also reminded the team that all those apps were only one click away from being released, and that we all were extremely happy when that was implemented 18 months ago. Another new joiner also mentioned that it was by far the best deployment experience in his career. Not bad :-).
Which leads me to my last point: do not compare teams. I repeat, DO NOT compare teams. This would be counterproductive since they all have varying levels of expectations. A green for team A can be a red for team B, so don’t fall into that trap. People would start gaming the system.
In conclusion, give it a try! The upside is 10 times worth the risk of losing an hour of your team. Thanks Spotify for introducing me to this many years ago. And please let me know if your experience differs in the comments.