The Retrospective Formula: The Context — Part 2

If you have not yet read part 1 of this article series, I highly recommend doing so, as this will further your understanding of the coming section.

Part 1 of the Retrospective Formula explained the importance of having the right mindset when participating in a retrospective. In this section, we look into an equally important principle; understanding the context, and how to plan and execute the retrospective.

Understanding the Context

Let me briefly clarify what I mean by “context” before continuing. Context could be structural elements like the team is formed a cross multiple departments. It could be a newly formed team. It could be the maturity and experience levels of each team member.

I prefer to understand the environment and circumstances in which the team operates.

This insight is utilized to optimize planning and facilitation of the retrospective.

Gather Data

There is no silver bullet when doing a retrospective. Some agendas, exercises etc. may work great for some teams and not for others. That is why I tend to spend some time on understanding the team’s context and their current situation, especially if I am an external facilitator. I typically set up a short preparation session with the Scrum Master, or another team member, to gather data and generate insights to what they are struggling with now. Questions I typically ask could be:

• Have any team members recently joined or left the team?
• Are there any indication of low morale?
• Is it a new team or an experienced team hitting their “one year crisis”?

There is a plethora of information that could be relevant for a facilitator to know. It is a fine line, however, as one does not want to know too much either, and keep in mind to gather data from multiple team members.

These are the things a Scrum Master should know about his/her own team. Sometimes, though, even the best ones get tunnel sight, and the need of a new perspective is important. Using other scrum masters or facilitators is often a good idea to help get new eyes on the context of the team. A bonus effect is that the scrum master can then participate as a peer team member, and get inspiration from the external facilitator.

Tailor the agenda

Now that you understand the context, it is important to tailor the agenda. You should select exercises that supports, but also challenges the context of the team.

As an example, if it is a new team with little or no agile experience and knowledge about Scrum, you may want to focus the topics around that in the first retrospective sessions. It is important that the team rather quickly becomes fluent in the scrum events, as this can mitigate other startup issues. Later, when the team is more fluent, you want to have a wider focus and help them identify some of the unknown or hidden potential.

If the team has low motivation, you may want to include a more storytelling-based format when gathering data, and use techniques like “powerful” questions to get the conversation flowing. You can use tools like mood matrix, health checks, or similar, to gather data from the past weeks to get an indication of the morale or mood in the team.

If the team consist of both introvert and extrovert members, you need to think about ways to ensure everybody gets a voice. A good method is to use a ball: It is only the person holding the ball, which is allowed to talk. Some are more comfortable writing than talking. This is where facilitation and understanding of context meets on a higher note. By understanding the context, you can adapt the facilitation. I will address this topic in depth in the third article in this series.

I have also experienced team members that are not good at giving feedback to each other: They are not changing code in the code review sessions, or they are not challenging each other during the sprint. You could decide to adapt the retrospective agenda to try avoiding giving feedback. While this approach may secure a calmed retrospective, it does not address, or improve the context. Instead of accepting status quo, I would ask each team member to try out feedback models, like the perfection game. This could begin inside the retrospective, where team members provide feedback to experiments being formed at the retrospective itself. In addition, then ask them to practice it during e.g. the code review.

The right focus at the right time

Key for the retrospective is: Understanding the context and the importance of optimizing the agenda and flow of your retrospective, and to have the right focus at the right time. Sometimes, you need to focus on a specific element to make a substantial change. At other times, you want to open up and gather data from all aspects of the team and its environment. It is the same way I explain what to do in product backlog refinement. Occasionally, we want to add detail to a very specific epic or story, and every so often, we want to do brainstorm activities where we identify many elements we want to work on. The same goes for retrospectives, yet the context can be very complex to understand, so do not underestimate its importance.

In next weeks article I will focus on the facilitation aspect of the Retrospective