How to check Your Team’s Health Through a Retrospective
Being an Agile Project Manager & a Scrum Master at SFL, I use different types of games and practices every week to spice up meetings and retrospectives. To be honest, most of them already existed and some format/content changes needed to be made to make them more suitable for me and the team.
Well, this time I decided to try the Spotify model though there is a lot of debate around whether it’s useful or not.
General insights
So, we call my THAT team “Squad” from Spotify Squad Framework and on a single project, we have 4 teams, aka Squads (You can download and print the cards from Spotify Labs).
Every Squad is responsible for a set of functionalities and domains and has its own PO and SM/Agile Coach. My team began to perform well (ok they are super smart and work their ass off to get everything done) and sprint by sprint started showing impressive results, thus, coming up with some action points based only on one sprint became a bit difficult. But when as a Scrum Master you have to make your team’s work smoother and collaboration more efficient, you need to dig deeper to identify hidden “problems.” Hence applying Squad Health Check as a tool for Gathering Data had two main reasons in our case:
- It switches the scope, so we can review the team’s performance and feelings in general
- It gives us a good reason to honor the team’s achievements and, of course, spot problems that we need to work on
Well, as for the domains to be discussed, I decided we could cover topics suggested by Spotify model (teamwork, fun, easy to release, suitable process, delivering value, speed, mission, support, pawns and players, learning, the health of codebase) and add some specific health indicators (managed dependencies, velocity).
By discussing the different domains, the team will become more aware of what’s working and what’s not. It can be a case that they were aware of the health of codebase, but hadn’t really thought about the mission of their product or the value they provide to the customer.
The voting process and results
How do we carry out the discussion? One of the ways is to hold dot voting. I read a health indicator name and possible extremes (green: an indicator of awesome and red: an indicator of horrible) out loud, and the team members start voting whether it’s Green, Yellow or Red (Green = good, yellow = some problems, red = really bad).
Afterwards, everyone tells his opinion about the trend (are things improving, stable, or getting worse?) and through discussions, we decide one general trend of a health indicator.
What is important here is to make everyone speak. If you have a team member who is shy to express his thoughts or not vocal enough and someone who loves discussions, start with the person who is shy. Always ask him to elaborate on the statements he made, which will help him to think and speak out loud.
So, this process allows us to mix Gathering Data and Generating Insights steps together while keeping our focus on one area. My role as a Scrum Master is to facilitate the discussion and write down anything that may be useful later on. Well, opinions might differ during the discussion, but making notes of the points highlighted by the team is a must. Note that it’s key to guide the team towards agreeing on an action point (at least one improvement) before finalizing the session.
Well, this is where you have to confirm or reject the hypothesis you had because the topics you chose were actually based on some assumptions on what’s wrong in the team. And of course, it’s useless to conduct a team’s health check if you are not going to work on and improve the action points in the end.
Wrap-up
Performing the health check once will give you a snapshot of your team’s health, but performing it regularly (once or twice a year) will allow you making comparisons and getting a picture of how you’re doing over time.
So if you ever ask yourself why you have to deep-dive into the collected data or why you need to do a team health check at least once a year (seems like a relevant question, right?), keep in mind that the data will certainly help you to make your team’s work smoother and most importantly build like-mindedness within the team.
It’s all about letting your team members share their thoughts in a safer atmosphere and as a Scrum Master, you have to keep your mouth closed in some situations by not intervening, not correcting them. Be there to listen and make notes for further improvements. If you just stay a listener, you will notice that people direct each other and mentor during the discussion.
To elaborate, a developer might mention that dependencies had not been tackled well and a senior developer might respond that it’s the responsibility of each developer to be able to manage some of the dependencies by communicating to the right people. You might agree with the senior engineer but do not intervene because they will reach the same conclusion without you. Coming up with the same opinion and action points will help them to be aligned and be on the same page for specific topics.
So, I consider this model of Squad’s health check very valuable and fun in terms of reviewing and improving your team’s “health.”
Thanks for reading!
Shoot me a line if you have any questions or ideas we could discuss.
Check out our open roles at https://sflpro.com/job/.
Read More:
