Retrospective in Scrum & Agile: A Quick Start Guide for Managers

Whether you are developing a complex software module or putting plans for entering a new market, you have a host of processes at the core of your action. Knowing how different actions (and actors, performing them) contribute to your project’s success is key to ensuring smooth progression. A retrospective is a solid method for regularly analyzing your process efficacy and taking corrective action before the project gets off track.

What is a Retrospective in Agile and Scrum?

Agile Alliance provides the following retrospective definition:

“A retrospective is often a facilitated meeting following a set format. During it, the team reflects on the main events that happened since the last meet-up and suggests improvement steps for the next cycle ahead.”

The idea of holding retrospectives — as regular checkpoints for analyzing past actions in terms of effectiveness, and finding ways to tune up the behavior  — was put in place within The original 12 principles of Agile Manifesto.

Source: Agile Process Lifecycle Diagram for PowerPoint by SlideModel

But the term ‘retrospective’ itself was popularized by Norm Kerth in his book “Project Retrospectives“, which is now considered a ‘classic’ read for Project Managers and Scrum practitioners.

Speaking of Scrum, retrospective meetings play an important role in this agile framework for leading projects. Typically, retrospective reviews are held at the end of each sprint. Unlike other types of analytical meetings such as after-action reviews (AAR), project post-mortems, or agile sprint reviews (more on this in a moment), sprint retrospectives are organized with the team only (not managers or other stakeholders). It’s a ‘private’ ceremony, facilitated by a Scrum Master, where each person is asked to share their honest observations and feedback (without any blaming or shaming).

A good Scrum Master can elicit answers to the following questions from the team:

• What went well during the sprint and what didn’t.
• Which areas are due for an improvement (across people-processes-tech).
• What should be added or removed from the current process?

The purpose of such project retrospectives is to locate areas for improvement (similarly to what VSM does) and prompt the team to correct their behavior. But, unlike other types of ‘reflective meetings’, retrospectives are held at regular intervals during the project, not at its very end.

Sprint Review vs Retrospective: The Differences

In short, the difference between sprint review and sprint retrospective is the intention behind each meeting. The goal of a sprint review is to discuss the overall project progress including ‘done’ things, future project backlog, any bottlenecks, goals, plans, and timing.

A sprint retrospective is focused more on inspecting how the work was done during the Sprint. In essence, it’s an expertise in process optimization, prompting the team to self-reflect on their actions, analyze the experienced difficulties, and brainstorm ways for improvement.

The Main Principles and Methods of Agile Retrospective

Similar to other agile practices, there’s no completely right or wrong way to run retrospectives. Every leader should find their own beat for making such meetings productive for the team.

Perhaps the only one major principle of retrospective reviews is the Prime Directive, suggested by Norm Kerth:

“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.”

The Prime Directive places a strong emphasis on building the right culture within the team. Such where each retrospective review is seen as a ‘safe place’ for expressing opinions, offering proactive improvements, and acknowledging one shortcoming without experiencing any negative retribution.

Since the Prime Directive can be interpreted and implemented in many ways, a lot of other approaches to retrospective meetings in agile have branched out.  Here are the top-3 most popular sprint retrospective examples:

• 6 Thinking Hats Retrospective: During the meeting, each team member is asked to wear one of De Bono’s thinking hats — a metaphor for a particular way of thinking — and discuss the last sprint from a very particular perspective. The facilitator documents everyone’s suggestions and then helps draw the best conclusions.
• Strengths-Based Retrospective: Rather than focusing on weak areas, the team is prompted to think in terms of their strengths and then encouraged to define new actions for using these strengths more often in the project.
• Sailboat: This retrospective play uses a boat as a metaphor for the team. As a facilitator, you should help everyone identify the main anchors (blocks and professional inefficiencies) and win (positive forces) for steering the project in the right direction.
• Start, Stop, Continue, More of, Less of Wheel: The facilitator creates a simple wheel with 5 categories (start, stop, continue, more of, less of) and prompts each team member to assess the last milestone through these five categories. This method is also called a retrospective starfish.

Source: Starfish Retrospective PowerPoint template

Today every remote high-performing company follows the Agile methodology. Even if the teams are distributed across different time zones, they run retrospectives asynchronously using standup bots for MS Team or Slack. This retrospective tool keeps remote Project Management viability and assists Scrum Masters in Agile process automation.

Standup bot also keeps answer statistics, create simple polls, integrate with third parties, and automates main Agile workflows such as:

• Retrospectives
• Standup meetings
• Backlog refinement
• Sprint plannings
• Planning poker and more

How to Run a Retrospective Successfully: a 5-Step Framework

As mentioned briefly, there are many interpretations of what makes a successful retrospective and which retrospective tools are worth using. So in this post, we’d focus on one of the most classic retrospective frameworks, promised by the Agile Retrospectives book by Esther Derby.

1. Set the Stage

Remember: retrospectives are a therapeutic exercise, not a harsh intervention. Your goal is to help the team better understand their performance and identify areas for improvement.

Thus, your meeting should have a warm, welcoming atmosphere. To set the right mood, to the following:

• Send a quick meeting note, recapping what a retrospective is all about, along with the basic rules for participation.
• Note if you are inviting an external facilitator and introduce them. It’s a good practice to ask someone from outside of the project to lead the retro. Sharing thoughts with an uninvolved party can be easier for some folks.
• Prepare all relevant notes, summarizing key goals, achievements, and KPIs, set for the iteration.
• Select several project retrospective templates that you plan to use.

2. Gather Data

The first part of the meeting should be focused on gathering data and feedback.

As described above, you have several different methods to elicit information from your team —the 6 thinking hats, retrospective starfish, sailboat, and Glad/Sad/Mad.

The last one prompts your team to categorize all the events within the project into three buckets. So that you could focus on resolving those on the mad/sad lists. During the discussion, remind people that it’s not a blame game and they should honestly share their feelings about different aspects of the project — from management to communication, tools, and processes.

Also, to keep the discussion productive and prompt people into addressing the right issues, gather some data in advance. In particular, look in the sprint burndown charts — or your list of complete/incomplete items — and your sprint reports.

Present the data from these reports to your team an try to identify:

• If the team met your forecasts. If not, what was in their way.
• Did everyone perform as expected? Why were some people more or less successful than others?
• Why were certain items not completed? When did things go off track and what prompted that?

Your goal here is to facilitate group root cause analysis and identify the underlying inefficiencies and blockers.

Helpful template: Root Cause Analysis PowerPoint Diagrams.

3. Generate Insights

After discussing the data and facts, prompt everyone to go a level deeper, and brainstorm the areas for improvements. In particular, you should:

• Reflect on the good things: new knowledge gained, progress made, strengths exhibited. Ask if your team sees how productive practices can be extended to other project areas.
• Acknowledge positive contributions. Highlight the main achievements, wins, and positive changes that took place so far.
• Address the weaknesses. Discuss the negative trends and shortcomings. But Don’t point fingers. Instead, speak to how such things can be mitigated in the future.
• Summarize the action points. Ask everyone to share their prompt for doing better during the next interaction.

4. Decide What to Do Next

The second part of your retrospective review should focus on follow-up action. Review all the proposed solutions, group similar points, and create plans for actualizing the best ideas.

This stage can be the most challenging one. Because your team may come up with too many action points to address. If that’s the case, refine your list using the Plan of Action technique.  The premise of this exercise is as follows: each team member should write down as many action points as they like in this format:

• Long-term goal: Release new website by Jan, 31st.
• Now-Action: Sam will do UX testing.

Then, pair all the retrospective participants and ask them to explain each other’s actions. Every pair must come up with a limited number of actions (e.g. 5) that they deem the most important to the goal. Next, change pairs and ask them to go through the same refining process. At the end of the process, you should end up with a more succinct list of action points worth addressing during the current iteration. All the now-actions that didn’t make it to the final cut, should be discarded for now.

5. Close the Retrospective

End your retrospective meeting on a high note. Summarize all the key findings, praise the positive changes, and highlight the next target areas for correction. Once again, celebrate your team’s accomplishments and give a quick pep talk for the next sprint.

To Conclude

Retrospective is a cornerstone practice among high-performing Agile/Scrum teams. But this practice can be also incredibly beneficial for teams across all verticals. If your goal is to improve project planning, employee engagement, and performance, you too should be hosting regular retrospectives. Besides, you now have all the tips and templates for that!