Although I've had this thought for years, it was only last week that I spoke about it with a colleague and it seemed like a good idea to blog as well. Retrospectives have become a norm with many teams and for good reasons, it's a dedicated time to think about the past and improve for the future, aka continuous improvement. And one of the activities that many teams conduct during a retrospective is a Safety Check. For those who are unaware of the Safety Check during retrospectives, let me help you with its details.
A Safety Check is a short exercise (almost like a poll) before beginning a retrospective meeting. It is anonymous in nature and basically used to check a couple of things;
Do the participants feel safe to share their thoughts in this meeting?
Are the participants in the right frame of mind to provide feedback that's true to the Prime Directive?
What's the Prime Directive you ask?
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. -- Norm Kerth, Project Retrospectives: A Handbook for Team Review
The most common way to conduct a Safety Check is by creating a poll with some kind of a scale that spreads between "I feel safe to participate" and "I don't feel safe to participate". In the past I've used some variations of it to indulge the audience, like popular songs:
I believe I can fly - R. Kelly
Feel good - Gorillaz
Don't start now - Dua Lipa
Help me out - Maroon 5
The hope is that there are more votes in the first two than the last two. But what happens if there are even a few votes in the last two? When I asked around, there was a common theme to this question's answer - "then you shouldn't have the retrospective and find out the cause of this unsafe environment". This is a very valid reason and I would definitely opt for this; however I have some conditions and caveats for this to happen. Here is why I believe Retrospectives may not need a Safety Check.
Reason #1: Retrospectives are for strengthening relationships
I'm purely going to quote the Scrum Guide here, Retrospectives are to inspect how the last Sprint went with regards to people, relationships, process, and tools. Let's consider that there have been conflicts between team members recently to an extent where these people don't feel like talking to each other; or a toxic culture is growing within your team due to which some team members feel being targeted, and these reasons lead to getting a lower score during the Safety Check. What will be a good reason to cancel the retrospective and attempt to mend this relationship elsewhere, when this is exactly what retrospectives are for?
No way am I saying that this is easy, I don't expect retrospectives to be easy; it's a place for introducing change and that's always difficult. What I have experienced in these circumstances is that the usual way of conducting a retrospective (collect points on cards, group, vote, discuss, get actions) may not be best suited. For example, if there's a conflict between two team members, it's very difficult to speak about it in person let alone do it in a group. Group therapies however is not uncommon, we may not be specialists in conducting it but we are specialists in being human.
One of the ways to have a conversation during these type of retrospectives is to use "I feel ..." statements. "I feel targeted by a few groups due to which I'm unable to do my best job" ... "I feel I can get more support from my team lead to hear my ideas" ... "I wish to come to common grounds with my tester". These sharing statements become the basis of gathering data which can be followed-up with "I hear you ..." statements by other team members as a reply. "I hear you and I propose we talk about your apprehensions" ... "I hear you, let's discuss your design ideas in more detail tomorrow". These become your actions.
At times, all people may need is to be heard and even a retrospective where people just share their "I feel ..." statements and others just listen can make a lot of difference. Although there's no guarantee that relationships will improve during these retrospectives, there is an attempt in the right direction. Addressing the elephant in the room is important, conflicts are better than artificial harmony, and a skilled facilitator can make a huge difference. I still conduct a Safety Check many times before retrospectives mostly to determine the way I should conduct the retrospective; cancelling a retrospective usually doesn't come up as an option.
Reason #2: Retrospectives are personal to a team
It is important to consider who are the attendees of a retrospective. Retrospectives are very personal to a team, almost sacred. An outsider can create a tensed environment for a team which may tip your Safety Check to the bottom. Who is an outsider? Anyone who's considered a chicken; in other words, not a member of the autonomous self-organised team (those responsible of creating the results) or a political influencer (e.g.: a sponsor or a CXO).
The essence of a retrospective is for a team to be open about their past actions and take ownership of their improvement. The best way to make this happen is to leave the team alone and trust their capabilities. If you thought reason #1 needed a skilled facilitator, this one for sure needs a courageous facilitator - it may not be easy to ask people to leave the room if they're an outsider with respect to a team (sometimes being a bad person in the eyes of the management may be a good thing for the team). As long as the team is free of outsider disturbances, a Safety Check may be redundant.
It is also important to point out that the facilitator must be a neutral person; for e.g. a manager responsible for the appraisal of team members isn't a good candidate to be a facilitator during a retrospective. In case the team has decided to get an external facilitator, it may be a good idea to provide some context around the attendees and a possible theme for the retrospective (e.g. when was the last retrospective conducted and the action items identified). One of my retrospectives I remember was so successful that it drastically improved my team's way of working, all because I was able to push away the outsiders from our meeting (this was followed by presenting an anonymous report portraying my team's feelings in front of the right audience).
Reason #3: Retrospectives are regular
It is important to have a regular cadence for retrospectives (weekly, monthly, quarterly, etc.). This ensures that safety concerns are addressed as soon as possible. As far as conflicts and toxic relationships are concerned, these don't pop up in the team one fine day; these build up gradually and hence addressing these in their nascent stages is extremely important. Teams that do not have a regular cadence with their retrospectives may miss out on addressing this and end up having a Safety Check result that's not to our liking.
For me personally, I do not like an interval of more than a month between two retrospectives. Quarterly and Post Project Retrospectives may be exceptions that get conducted with a different theme, the regular ones however are not disturbed. Teams who have a cadence of less than a month usually have a common request before every retrospective meeting - "it's just been a few weeks, we don't have enough points" - a good facilitator should conveniently ignore this request and carry on with the retrospective, it's a surprise to see the number of points that come up.
A regular cadence also indicates to the team that this is a time when we're supposed to come together and work towards improvement; this feeling can create a mental state of a safe environment by itself. One may argue, if continuous improvement is the goal why do we need a dedicated time for it? You don't. In the past I have managed to have a retrospective board put up near the team's seating area; individuals can add improvement points to this board any time. Points that don't need the team's intervention, e.g.: need new poker cards, can be addressed at any point of time by a manager. A retrospective meeting ensures that the team's can spend sometime for deliberate improvements and can focus on work outside of this meeting without any interruptions.
Conclusion
The above reasons are not to say that one shouldn't conduct a Safety Check at all, it is merely to point out that it is not the basis for deciding if a retrospective should be conducted or skipped (hint: never skip a retrospective). As mentioned above, as a facilitator, I would conduct a Safety Check every now and then, especially if I'm an external facilitator for a team, just to gauge what approach I should consider for the retrospective. With my teams, the attempt is to create a safe environment in general and a Safety Check during a retrospective may not change the team's existing state. In case you have observed things differently or have a different approach to mine, please leave a comment, I'll be happy to discuss.