The 5 stages of a retrospective
Everyone who worked with me know of my strong appreciation for retrospectives. It does not matter if a team is running on Scrum, I think this is a practice for any team. The way I view it a retrospective is a shared event of a team looking back _or forward!_ and investigating the deepest causes of success, failure and everything in between.
It is a practice that helps teams in any stage of their maturity; the first one I suggest any team to adopt and the one to never abandon, but it is very common for new teams or individuals that never worked in an Agile way to disregard it. In fact it is one of the last ones to be honored and the first to be put aside if we "lack time". Many such teams would use references such as "Kumbaya" or just "feel good" meetings. Others would judge it as a moment in which people get confrontational and therefore no important issues are discussed, as people might feel the need to protect themselves. I think we can all admit this is a possibility, even thought it is not the intention. If we do admit it, we are at the brink of making a break-through for our teams. Do not disregard their disdain or animosity towards the practice of retrospective. Investigate it!
Coaches and Scrum Masters and other facilitators are the ones that can make a team love retrospectives and teach them how to reap the benefits of hosting them. It is not a meeting in which we just go in and discuss freely about whatever is on our minds. That is indeed one of the recipes for ineffective retrospectives. A good, consequential retrospective has an intention and a structure; it requires preparation and a good facilitator has a very active and non-judgemental part to play throughout. It cannot be overstated the importance of preparation: adopting the mindset, creating a structure, deciding a format, coming up with questions, preparing the room and the materials. At the end of this article you should find a template to help you prepare for your next retrospectives in case you feel you are needing structure. You can also download the infographic and use it with your team or just by yourself as a quick reminder of the 5 steps of a retrospective, which are as follows:
1 - Set the stage
Setting the stage is the step of initiating the retrospective. We welcome the folks in the room, give some context about what it is a retrospective and why we do them (if the team is inexperienced), but also setting the tone and making the team feel invited, comfortable and open enough to have a productive session. That includes a walk-though on how the session is structured and how people are expected to participate. That should also include an introduction or a read-out-loud of the Prime Directive:
"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."
On a personal note, I particularly consider this step of setting the stage starts much before, when the facilitator, usually the coach or Scrum Master, looks back into the iteration and identifies some potential themes and some of the questions that might be needed to make people engage in the mood of the activity.
In its duration, however, I give it a short space in the retrospective. I consider it takes about 10% of the total time.
2 - Gather the data
When teams are more inexperienced with retrospectives I find very helpful when the coach bring his or her observations as a starting point. Have we been missing sprint goals? How are our burndown charts? Have our builds been constantly broken for days before someone fixes anything? Did we onboard a new team member or did we left her scrambling? We have to be mindful that the team was focusing on the sprint work and it will probably escape them the attention to how things were going as they were trying to deliver the product. A coach or Scrum Master should not shy away from bringing factual elements, charts, pre-digested summary of what happened in the iteration from the eyes of the observer. Also, if a team had previously committed to a particular improvement, the coach or Scrum Master should bring the results of this commitment for discussion.
Remember, the team is focus sprinting; the coach is the one holding the mirror in the end of the sprint.
However, all this is done in an investigative, collaborative manner. There is no right or wrong and it is not because the coach had an opportunity to observe certain facts that they are necessarily the most important items to be discussed. Gathering the data involves really going for the quantity, inviting the team to really come up with all memories and ideas they have, going for quantity first. Only then should we consider narrowing down and figure out which theme actually speaks to the team's improvement appetite. We definitely want to hear from everybody for this to be a constructive session. Single-minded retrospectives, in which the coach always pushes for an agenda, even well-intended, end up being a top-down approach and the team gets detached from the practice, despite though them being "allowed" to participate and find it fun.
I usually shoot for the equivalent of 20% of the total retrospective time to be destined for gathering the data.
3 - Generate insights
This is a moment for the coach to be very attentive. Facilitating the discussion visually is usually the best idea, as well as inviting people to circulate and draw or use materials and be physically engaged. In every team we have people who speak more and people who speak less and even though we do not need to resort to timers it is a good idea to ensure that people have a balanced opportunity for speaking. Be sure to also encourage the team to not remain on the surface of their causal analysis. Help the team if they seem to be going in circles or on a tangent. Do not let the discussion stall, bring the tone down if things get heated.
This is probably the longest part of the retrospective and at this point the coach should be at full speed alert. I estimate a good 40% of the total time is spent here, so 20 to 30 minutes of active facilitation on this mode is a real possibility. Be prepared.
4 - Decide what to do
Sometimes ideas on what to do happens as the team is investigating the deep root causes. Make sure to register those or invite the team to do so. Remember to encourage the team to be creative and once again shoot for quantity before selecting the best ideas.
When the time calls for narrowing down, it is useful to vary the method through which you do so. Voting is
a good system, but sometimes people might be holding on to favoritism or have remained a tad bit too superficial. Making quadrants such as the Eisenhower method in which you classify the ideas or ranking those ideas using a weigh system might yield a more mature decision in the end.
Reserve a good 20% of the total duration for this decision time.
5 - Close the retrospective
Sometimes we just run out of time, people have to leave or some other abrupt reason makes us cut the retrospective. Other times we might just experience a slow disengagement and people lack words or get tired and we sort of enter the unannounced end of the session. Be attentive till the end! Do not let those things happen. Even if you have to cut the retrospective due to time, make sure to give it a clear, announced end. I believe the following needs to happen and it can take place in up to but no more than 10% of the total retrospective time:
Summarize what was discussed and the decisions made.
Assess the team's confidence moving forward with the decision.
Clearly and soundly say that the retrospective ended.
Last but not least, ask for feedback for improvement for the next retrospective. It can be even an offline feedback with a door with emojis or a mural of ideas. This is a meta-action that reinforces the intention and quality of the retrospectives moving forward.
To keep learning
Effective retrospectives are all about the intention and the structure they have. Give yourself time to learn and apply those, especially if you have different teams configuration, such as remote teams or segregated functions. But overall:
Be familiar with Systems Thinking techniques to be sure the root cause analysis are not superficial.
Be familiar with Liberating Structures.
Download my infographic below for reference.