In times of remote work and meeting fatigue, it may be reasonable to cut meetings or merge those that seem most similar. However, review and retrospective sessions should not fall under this procedure. Both are instruments for continuous improvement in agile environments and take place at the end of the cycle, but serve different purposes and are therefore not carried out in the same manner. 

In a nutshell, a Review is about the outcome, while the Retrospective focuses on the process. 

Find out more about retrospective meetings in this article.

Purpose: ​What is the reason to hold a Review/Retrospective?

Both meeting formats enable teams to learn faster from the past and respond better to changing market conditions. They help to evaluate where improvements are needed, while emphasizing lessons learned and acknowledging achievements. 

Review:

The review meeting helps teams reliably meet customer needs and deliver the best products and services. The teams discuss their results, but also reflect on their workload and preparation, and come up with new ideas.

Retro:

The retrospective aims to "improve the system" and enable better collaboration and a streamlined process. It sheds light on team dynamics, behaviours, meeting rhythms and the overall work environment.

Time and Duration: When is the right time for a Review/Retrospective? How much time should be allocated for each meeting?

Review and retrospective meetings are held at the end of an iteration such as a Scrum sprint or OKR cycle to ensure that the team still remembers the most important incidents, and so that learnings can be applied immediately in the next iteration. Meetings should be scheduled to be of sufficient length and at a time that suits the intentions, rather than on a Friday afternoon.

Review:

Teams first analyze their work in a review session before moving on to a Retrospective. Teams typically take half an hour to two hours for a review session. Especially after introducing a new agile framework like OKR, the participants may take more time to examine their performance in depth.

Retro:

A Review often points towards relevant topics for the subsequent Retrospective. For example, the realization that teams were unable to address all goals due to unpredictable ad hoc tasks might lead to the conclusion that teams should generally plan more buffers in advance. The Retrospective is usually shorter. Many teams allocate half an hour for it.

Insights from Workpath: At Workpath, we have found it to be most effective for each team to conduct their Reviews and Retrospectives two to three weeks before the end of an OKR cycle and then share key findings with our Program Lead. This approach helps us identify cross-functional and organizational patterns that may indicate structural alignment issues or similar problems. These insights are then shared throughout the organization.

Participants: Who should attend a Review/Retrospective?

To foster transparency and alignment, it is important to include the right people in these meeting formats. Neither Reviews nor Retrospectives are leadership responsibilities, but they involve everyone who is part of the process, such as the Scrum team, and can therefore contribute to the feedback session. Feedback does not follow any hierarchy; it is usually very valuable to gain different perspectives on a situation.

Review:

Since Reviews focus on the work done, they should be conducted by everyone who was involved in achieving the set goals. This may even include customers or other stakeholders. In the case of OKR, it can be helpful to seek feedback from other teams that were also aligned on a particular Objective or Key Result.

Retro:

Retrospectives can provide teams with sensitive information such as communication barriers and hurt feelings. To gain truly valuable insights and effectively improve processes, participants need to feel safe to openly share their thoughts. Therefore, Retrospectives may be organized in a smaller group. Usually, all members who participated in the last iteration are included.

Agenda: What is the right structure for a Review/Retrospective?

Neither Reviews nor Retrospectives are there for destructive criticism, heated discussions, or planning sessions. To prevent these meeting formats from drifting off, it is helpful to ask the participants to prepare, and to have a clear structure and a moderator, such as a team lead or other person, to facilitate and coordinate the sessions.

Review:

The Review starts with an introduction to bring everyone on the same page. If possible, the work results are shown or explained and feedback is solicited from stakeholders. OKR teams may want to discuss each Objective, its relevance, progress, and outcome, and assess the time and resources spent on every goal. Some teams tend to rate or score the achievement of their goals to establish a baseline. 

The participants ask what went well, what went wrong, what could be improved and what was not tackled or accomplished. For this reason, they also present their backlog. This agenda item also serves as a transition to the next iteration. Some teams prefer to start drafting their new priorities or goals right after a review. 

The review can be concluded with a brief wrap-up and should motivate participants for the next iteration, for instance by giving kudos.

Insights from Workpath: At Workpath, we ask ourselves how the progress of our OKR went and how satisfied the team is with its performance. This second question is intended to emphasize the teams' ownership and to take into account the challenges and learnings during the quarter. Often, the degree of goal achievement does not tell the whole story as it does not necessarily indicate how the team dealt with emerging blockers or additional urgent tasks. It may not display the relevance and scope of an outcome.

Retro:

The Retrospective begins with any kind of opening that raises awareness for the team’s personal context and creates the right atmosphere for an honest exchange. Some companies use team-building games or icebreakers. The method of choice should be whatever the participants are most comfortable with.

Once the stage is set, both hard and soft factors affecting the process are gathered. Teams should be encouraged to share facts and feelings. One option could be to offer participants to give their feedback anonymously. 

These insights can then be clustered, sorted by relevance and/or prioritized using methods such as scoring systems. 

The issues that received the most votes are then discussed further to improve them for the next iteration of the process. The teams focus on treating the cause, not the symptoms. Proposals should be specific and achievable. 

The Retrospective ends with a check-out, for instance a feedback round, so that participants can settle with what they have learned and return to their work smoothly.

Common Mistakes

  1. No preparation

Both the facilitator and the participants should be prepared for these meeting formats. To encourage team members to reflect thoroughly on the past iteration, they should be provided in advance with the topics to be discussed.

  1. No engagement

First, team members should be aware of the relevance and goals for both meeting formats. Second, it is helpful to structure sessions in a way that avoids unnecessary repetition and naturally encourages more engagement such as icebreakers and physical tasks.

  1. No context

Especially in company-wide meetings, individual employees from different departments may not understand the relevance of all topics. Teams need to focus on sharing only the most important insights, providing context and giving others time to ask questions.

  1. No adequate atmosphere

Reviews and Retrospectives are not occasions to blame or judge each other. Destructive criticism is just a look back, while these meeting formats are meant to enhance the future. Teams need to focus on potential lessons learned from past experiences. The biggest failures can provide the most valuable lessons. Agile frameworks, such as OKR, are about gaining knowledge, continuously improving and driving innovation.

  1. No supporting culture

The values mentioned above are exemplified by the organization and its leadership team. Leaders must be willing to accept feedback, no matter where it comes from, and to address higher problems such as structural alignment issues or insufficient capacity. Ideas cannot be judged by who they come from, but how they serve the company and its goals. Organizations need to adopt a learning-oriented culture and make their employees feel safe to admit mistakes and grow from them.

Further Questions

What questions should be asked in a Review/Retrospective?

Teams should use the following questions as a guideline, rather than feeling obligated to answer every single question or limiting themselves to them. As with other agile practices and methods, teams are responsible for their own process and can come up with individual questions. The answers given should then be discussed within the team.

Review:

  • How did we perform overall?
  • Were we doing the right things?
  • What did we achieve? What impact did our work have?
  • How satisfied are we with the result?
  • Did we allocate sufficient time for each goal?
  • Did we allocate sufficient resources for each goal?
  • Did we have the necessary skills to do our part?
  • Did other teams contribute what we needed from them?
  • Why were we (not) successful in achieving our goals? 
  • What were the biggest obstacles and could they have been prevented? If so, how?
  • What were the biggest success drivers?
  • Did we prioritize our goals correctly and did we maintain our focus?
  • Did we continuously track our progress and course-correct based on learnings?
  • Were we and others aware of our responsibilities?
  • Did we manage dependencies effectively? 
  • Have our goals remained relevant?
  • Will they continue to be a priority?
  • What are our learnings?
  • Which key-takeaways from this iteration might be relevant to other teams?
  • How can we set better goals for the next iteration?

Retro:

  • How did we feel (individually) during this process?
  • What were our strengths in this iteration as a team?
  • How can we work on our weaknesses for the next iteration?
  • Did we notice any communication barriers or other collaboration issues?
  • Did we notice any misalignment that led to double work?
  • Did we support each other throughout the process?
  • Did we feel supported by other teams?
  • Are the overall goals visible and relevant?
  • Do we all understand the purpose and techniques of our framework (like OKR)?
  • Does weekly/monthly/quarterly planning make sense for us?
  • What is missing from our current setup to boost our performance?

Are Reviews and Retrospectives mandatory?

Agile methodologies, such as OKR, are not set in stone, but are flexible frameworks that teams customize in order to make them work. In other words, conducting Reviews or Retrospectives is not mandatory. However, both meeting formats provide teams with important information about their past performance and open doors to further improve their performance. Today, it has become critical to learn and adapt faster to keep up with rapidly changing market conditions. 

If teams are struggling to conduct both Reviews and Retrospectives, one solution may be to reduce the time for each meeting rather than not conduct the meeting at all.

How often should a Review or Retrospective be held?

For these meeting formats to reach their full potential and provide the team with valuable insights, both Review and Retrospective should ideally be conducted immediately after each iteration and before moving to the next iteration, such as an OKR cycle. This allows teams to reflect on specific events, rather than over a broad, fuzzy period of time, and quickly apply their key learnings. 

However, some teams run shorter iterations, such as weekly Scrum sprints, and may feel overwhelmed with the time they spend in meetings and not have the space to effectively put their learnings into practice. On the other hand, if Reviews and Retrospectives are held too infrequently, collaboration issues and personal frustrations can build up and damage the company culture. There is no one-size-fits-all; teams should strive to find a good balance between work and reflection.