On Closing Feedback Loops – Squad Health Check model edition

Intro

So, after several Team Morale (http://teammetrics.apphb.com) runs with our teams we decided to try also, just a few months ago, the popular Squad Health Check model.

Main reason for that was the fact that even though the Team Morale survey has low costs (in terms of prep & execution times), it’s very top-level friendly, & its output is really good input for retrospective & one-on-one conversations, in my experience, the fact that it is an online & an optionally anonymous short survey (I mean most people choose anonymity unless they want to send a signal of sort) makes it feel a bit more distant, not so immediately actionable, folks can easier game it and does not guarantee high participation rates.

The Squad Health Check model, on the other hand, due to its more direct, face-to-face retrospective-ready design seemed more suitable to experiment with at the time, for all above reasons, where we (the Scrum Masters community) were looking for a way to introduce a more holistic, faster and more directly actionable feedback loop on team, and most importantly on project (communities) and on management level. But it is much more heavy and demanding, planning/execution-wise. Nothing is free. 🙂

The sessions

The Squad Health Check model as outlined in the original Spotify paper (https://labs.spotify.com/2014/09/16/squad-health-check-model/) includes 11 areas for evaluation (teams themselves added two more) and 3 health indicators (green, yellow, red). We intentionally tweaked it a bit by giving to it a more intense retrospective flavor by augmenting it with an Insights section, an Actions section & a short ROTI section, exactly like Barry Overeem did when he tried it with some teams in 2015. Thanks Barry! (http://www.barryovereem.com/how-i-used-the-spotify-squad-health-check-model/).

As per our plan, we facilitated 2 teams per day, 90 mins per team, in 4 days, in 2 meeting rooms in 2 different buildings (thank you Legamaster Magic-Charts) and with some valuable sugar support (cookies!), 65 people from all 8 Scrum teams delivered (>90% participation vs ~65% participation on Team Morale surveys) in ~10 hours in total. We decided from the start that all Scrum Masters must attend even when not facilitating, something that helped grow a common understanding & shared consciousness among us on the most hot topics (and to provide each other with constructive feedback). In retrospect we think that this was immensely valuable, to veteran and newcomer Scrum Masters alike:

Folks in action

After sessions conclusion

We split the work into two main parts:

Part I: The Output Summary: Where we basically transferred the voting results from the board into the below form using excel & sent it to management & the teams themselves. We also reserved some time at the next Sprint Review to present it and discuss briefly.

Censored, please excuse.

On top of this we also created and shared a discussions heat-map, highlighting the most discussed areas, as measured by the number of Post-it® notes collected. This proved to be very helpful because in latter stages we were able to focus on these areas where the most «heat» came from during the sessions.

Discussions Heat Map. No need to censor this one.

Part II: Improvements Backlog Creation: A Sprint later, we explored in more detail the insights gathered. We first did some FOG (Facts, Opinions, Guesses) analysis to clarify feedback received. After some discussions, we grouped it into clusters of recurring themes/patterns using some basic affinity mapping & extracted Key Insights. 

Left: Raw Post-Up of collected feedback / Right: Help poster, Bottom-Up analysis results

As a result of this, we were able to form specific Problem Statements. Then we did the same for the proposed actions to extract Key Actions to tackle those Problem Statements. At that point we placed them on the whiteboard to initiate discussions with management on all those Key Actions that we considered required management attention & green-light. We then had two follow-up discussion sessions with management.

Left: Drafting / Right: Problem Statements & Team/Project/Management Suggested Actions

It’s important to note at this point that team level actions, which were the most immediately actionable ones, soon after the sessions concluded, were taken to the teams themselves and some of them were even directly resolved. Actions targeted in project (communities) level were taken to the respective communities to be part of their discussions during their syncs and actions targeted in management level were taken, well.. to the management sync (not sink) 🙂 By the way, at least one Scrum Master attends all those events, so it is ensured that things keep going.

After all this processing, we eventually created another artifact which we introduced next to keep track of all those actions: the project’s Improvements Backlog. In that backlog, the Problem Statements were rewritten in the form of Areas of improvement:

The Improvements Backlog artifact

We officially introduced it at a Sprint Review later and posted it in the teams space for everyone to see & refer to anytime.

Now, after every Scrum Master sync (we do two Scrum Master syncs per week) we dedicate some time to go through this board.

Closing (the loop) & lessons learned

Teams liked Health Check a lot. ROTI had a ~5-star average rating. However, our original plan of allocating 90 mins per team proved to be really tight. So next time we will definitely go for 2 hour sessions per team. Also, and after taking into consideration the current reflex/flow/materialization/name-it-as-you-like times, we decided to run 2 Health Checks per year, one every six months to see how many small or big things we can accomplish on cycles of this length. Team Morale surveys will still be run in between (every 3 months, with a jump). And, our next goal, will be of course, what else? To shorten those continuous improvement & learning cycles further.

Thanks for reading!