If done right, retrospectives can help you inspect past actions, help adapt to future requirements and guide teams towards continuous improvement. However, organizations find it difficult to adopt the right mindset to execute retrospectives effectively. This blog will help you understand what retrospectives are and provide valuable tips to make your retrospectives meaningful.
A retrospective is a structured process that typically helps you reflect on the events from past activities and set a precedent for future decisions. Retrospectives are often conducted at the end of a project/event or at a regular cadence. The aim is to give teams the opportunity to backtrack and examine their activities and plan future actions that can help achieve the desired results.
It should be a blameless process where team members can share their honest feedback about what’s working for the team and what could be improved. The next step is to document the takeaways from these discussions (shortcomings, actionable items, etc.), which can be followed up in the future.
An important term related to retrospectives is postmortems. Postmortems are a type of retrospective that deal with operational problems and the response to those problems. (Read more about Squadcast's Postmortem templates)
Retrospectives are often wrongly interpreted, here is what retrospectives are not meant to be,
Teams often make the mistake of focusing more on ‘what’ happened and ignore asking the ‘how’ questions. “how” questions help you identify the causes of events. Knowing the cause will help you define preventative actions. A retrospective, therefore, should be treated as a process that reviews the "how" of what happened.
Many teams are stressed with deadlines and that forces them to miss out on regular retrospectives. In some cases, retrospectives are not done at all. This makes retrospectives less effective and you might miss out on important insights in the process.
When retrospectives are done in terms of postmortems, it is essential to plan and schedule retrospectives at regular intervals. There can be exceptions (false positives) when you don’t have retrospectives. Hence, there should be a criteria for retrospectives and if an incident merits a retrospective, you should have a retrospective. Oftentimes, many insights unravel once everyone is in the room. It is a habit every team should cultivate.
Teams often do not use data to build a shared mental model of what actually happened to the team. It is good to have a shared understanding of what happened in the first place otherwise in pursuit of improvement teams may end up targeting different problems or different set of data that could potentially hinder growth.
Facilitators are responsible for the smooth execution of a retrospective meeting. Their job is to ensure everyone has a say in the retrospectives and to make sure all planned events are discussed in the meeting to make it more productive. Having neutral facilitators without a stake in the incident outcome helps, as they will not push the discussion in one direction or the other. This will help in rational decision-making and smooth & blameless retrospectives.
Safety checks are an important part of a retrospective. Before a team reflects on their past actions, everyone who is participating in the process, should feel comfortable about sharing information. Even if one individual does not feel safe, or is hesitant to share information, it can nullify the purpose of a retrospective. A facilitator should encourage everyone to participate in the process and ensure everyone feels confident to give their input in the discussion. This helps break barriers and can make these conversations insightful.
Different members attending a retrospective may come to a retrospective meeting expecting a certain outcome. For individuals, it can be about addressing a certain issue with the existing incident management process. For someone it could be about a tool being used or a database issue. The process should have time for expectation-management and certain criteria should be in place to do this effectively.
Based on the needs and processes of an organization, postmortems and retrospectives can be as short as an hour or can even go on for 1-2 days. Safety checks are more suited for longer retrospectives. In some situations, an exercise called Speed Boat can be beneficial. It takes the metaphor of a boat and asks participants to think about the causes of an incident, takes their input and moves the discussion to the next participant. This exercise enables collective intelligence to be brought into play. There are many such exercises that add value to retrospectives and team building. Here is a reference guide if you wish to use the subject more: Improving Agile Retrospectives: Helping Teams Become More Efficient
Measuring the effectiveness of retrospectives is important. On completion of a retrospective, one participant may have more takeaways than the other. For example, after a meeting, an incident responder may have more takeaways than a software engineer or vice versa. There should be a process that not only measures how balanced the outcome of a retrospective was but it should also help set processes for future retrospectives where every participant has some takeaways. This ensures active participation of every member, which can add value to the activity and not force it as a burden on individuals who had no takeaways from it.
Good communication helps a team to perform in unison. Especially when the projects have longer spans, familiarity with team members serves well in achieving consistent results.
The team members should feel comfortable giving and receiving feedback. Having regular team-building exercises can help team members to open up and express their ideas, and also help to have a healthy communication culture.
Incidents are bound to happen, and when they do, it's crucial that retrospectives or postmortems are conducted in a blameless manner. Rather than focusing on individuals or teams as points of failure, the emphasis should be on understanding the underlying situations that contributed to the incident.
Traditionally, postmortems have often sought to assign responsibility by identifying a specific individual or failure point. This can create a negative and defensive mindset among participants, where key information may not be shared openly for fear of blame. However, in a blameless post mortem, the goal is different—it's about collective learning, encouraging a positive attitude, and treating the situation itself as the source of failure, rather than placing blame on people.
A helpful way to ensure this approach is by using a blameless postmortem template. Squadcast provides predefined incident post mortem templates, which can be customized according to your organization’s needs. These templates guide your team through a structured and blameless postmortem process, fostering open communication and helping uncover valuable insights. You can create a new post mortem doc, modify an existing postmortem template.
Whether you’re creating a blameless postmortem documentation, or simply following a post mortem document template, these resources help ensure that your blameless postmortems lead to actionable improvements without assigning blame.
Check out the Squadcast blameless post mortem template to facilitate your next retrospective and ensure it remains constructive and solution-oriented.
It's essential to ask the right questions in a retrospective. One approach is the ‘Three little pigs retrospective’:
Another approach is the ‘Process, People, Tools’ approach. With this approach following questions should be asked,
Your team should be encouraged to focus not just on the current cycle, but on the broader state of the product/problem. While doing so, you should aim to find answers for the questions mentioned above and then plan the future steps accordingly.
Not all retrospectives can help yield solutions to the problem at hand, especially not at the very moment you start discussing it. You can try out different techniques to reach a solution. Some common examples include,
There are various solutions/techniques that could help solve problems specific to your team. However, it is important to understand the issue and find different ways to address and analyze these situations.
The Incident Activity Timeline serves as a real-time chain of incident resolution activity. This timeline is very helpful in understanding how an incident is addressed from detection to resolution. Having a feature that records incident activity can give you valuable insights. Squadcast’s Automated Incident Activity Timeline feature lets you download incident timelines and use them for Incident Reviews or to create Postmortems.
Incident response teams need to be prepared to handle unplanned incidents, so they can help save time, prevent frustration, and reduce refactoring in the long run. Having effective retrospective processes in place can help teams identify what went wrong in the past and plan for incidents that can arise in the near future.