THE RESPONSIBILITY WHEN CONDUCTING RETROSPECTIVES

If you work as a Scrum Master, you are well aware by now that Retrospective is one of the most important moments in a Sprint. It is the very moment when the team has the opportunity to reflect on how they performed during the sprint, how they acted as individuals and how they interacted as a squad.

It sounds wonderful if it wasn’t for being extremely risky, today I'm going to talk about some attention points I've noticed in different teams and scrum masters to keep in mind and ensure that this precious ceremony doesn't end up becoming a trap.

Retro isn’t all fun and play

The first scenario I would like to address here are squads and scrum masters who see retro as an opportunity for fun, applying the most diverse types of colorful, creative and ingenious dynamics, without actually analyzing the dysfunctions that need to be addressed and the plans that should result from a successful retrospective. I do recommend that some retrospectives focus on celebration, team building and energizing, however this should be the exception and not the rule. Note that the retrospective, even if conducted in a lightly manner, should promote a moment of introspection and bring out the team's most latent difficulties, in addition, the output of a retrospective should invariably generate a practical and tangible action plan that needs to be conducted by the team and followed up during the sprint. It is the Scrum Master's role to see what kind of retrospective this team requires, and to provide the best method and technique to bring up the reflections needed.

Retrospective doesn't have a reset button

Another very common practice is to believe that retrospectives of each sprint need to be created from scratch, that is, for each sprint end a retrospective is designed, with a new reflection, new material, board and so on. The truth is that much more harmful than not having a retrospective at all, is building a new retrospective without having completed the previous one. As I mentioned, the retrospective action plan permeates the entire sprint and it is very common that by the end of the next sprint, not all issues raised in the previous retro have been addressed. Thinking from this perspective, it is important that the Scrum Master understands this need for continuity and instead of launching a new dynamic at the end of the next sprint, recovers the evolution of previous themes and if relevant opens the discussion to new “pains”. This practice is not only coherent, it also helps building stability and confidence with the squad, as well as more solid and lasting solutions.

The Scrum Master's autonomy

This next item is one of the most dangerous ones, especially for the Scrum Master. We know that a retrospective is basically built on questions, provoking and reflective questions, as you can observe, for example, the famous “liked, lacked and learned”, “positive, negative and how to improve” etc. The questions are just the basis, and during facilitation, the scrum master brings up more arguments and stimuli for the team to reflect. This conduction and invitation to reflection also needs to be well planned. Joining a meeting and asking, “what are your major frustrations today?”, without restricting the question to the sprint, squad interaction etc., can easily backfire. I've seen situations where a less prepared scrum master was faced with answers such as “my biggest frustration is my salary”, among other very sensitive issues. The point is, a facilitator should never ask such wide-ranging questions as to bring out issues that he or she does not have the autonomy to address. For several reasons: because it confuses the team about the role of the Scrum Master, because it raises an expectation of dealing with problems that the Scrum Master is unable to provide and exposes the team in an unproductive context. It is common in the role of the scrum master to come across relationships with their teams that favor this type of confidentiality, but it is our responsibility to embrace these concerns while clarifying the extent to which issues we can or cannot support and which issues are not within our reach.

The hostile environment

Last but not least, it is necessary to be careful with the environment where the retrospectives are conducted. I can mention two hostile scenarios that can hinder the conduct of a good retrospective. The first is a hierarchical environment, when the leadership is invited to watch or participate in a team retrospective. The second is when there is a very contrasting conflict between two or more individuals on the team. Both scenarios will generate one or more of the following scenarios: absolute silence, passive aggressive communication, positive but false speech, among others. It is the role of the scrum master to ensure that the retrospective is an intimate environment where only the team members are present, and when there is a healthy relationship, perhaps the Product Owner can be invited. The SM must also ensure that if there are individual problems, these are addressed individually before, or if there is sufficient maturity, that the retrospective is focused on these issues, so that the reconstruction of the team's bonds of trust can emerge.

In addition to these four topics I covered, there are several ways to treat minor malfunctions that occur when applying retrospectives, but I believe that by taking care of these more harmful scenarios, it is possible to guarantee revealing and very productive conversations, which lead the scrum masters as agents of change and their squads, to a new level in Agility.