Retrospective: Look ahead by looking back

So what are these retrospectives and how do they work? As one of the twelve principles in the Agile Manifesto states: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” In the Scrum methodology this happens in so-called ‘sprint retrospectives’ which are held after the completion of an iteration. As many project team members as possible should participate in these meetings so that they can contribute different perspectives to generate a higher input. If it is about a very specific problem that only affects the sales department, for example, you can also limit the number of participants.

Goals of a retrospective

The purpose of a retrospective is to look back at what you have achieved and learn from your past experiences. Particularly the team and their bond among each other is of interest, which is why you should improve teamwork and strengthen that bond. In order to achieve that, an open atmosphere that is free from fear is an absolute requirement. Without trust between the participants, the retrospective can’t be completed successfully. It’s not about finding a scapegoat, but rather about the question why something happened in a certain way and how you can improve that in the future. Ideally, you should work on solutions right away. But you shouldn’t only concentrate on the negative things, but also highlight successes: what worked great and what should you keep doing?

Procedure

You should hold retrospectives regularly during the process of a project. You also need to set a time limit (‘time box’) for these meetings beforehand. In bigger intervals, you can also execute longer retrospectives, e.g. every two or three months. A neutral scrum master, who can be an external person, leads the event.  

According to Esther Derby and Diana Larsen, a retrospective consists of 5 phases.

Phase 1: Set the stage

  • Make preparations
  • Set the focus of the event
  • Include context (e.g. “This is retrospective 5 out of 10, three months until the end of the project etc.)

Phase 2: Gather data

Give an overview of the events that lead to the finished iteration.

Phase 3: Generate insight

  • Draw inferences from past events
  • Suggestions for improvements

Phase 4: Decide what to do

  • Decide what you want to implement
  • Who takes on the new tasks
  • What should you scrap

Phase 5: Close the retrospective

Summary of the main points discussed and decided in the retrospective

Retrospective vs. Lessons Learned vs. Project Audit

You might’ve stumbled upon the words ‘lessons learned’ or ‘project audit’ in relation to retrospectives. However, these three concepts are not synonymous, but represent three different approaches.

Lessons Learned

These are the insights you have gained at the end of a project and are part of the project closure report. Thus, they are not taking place during the project’s process like retrospectives. Lessons learned is a more traditional PM method which is why you won’t find them in many agile projects.

Project Audit

A project audit is also part of the ongoing project. It serves as an inspection or control of the project and, thus, often takes place when the project is in danger of failing or is in a crisis. It is always a neutral, external authority who performs the audit.

Tips

One of the goals of a retrospective is to strengthen the team, which is why you should be inclusive of anyone on the team. The scrum master should encourage exchange and communication so that everyone participates actively in the meeting. You can use different retrospective methods to create a relaxed atmosphere (examples here and here).For example, did you know that you could integrate fortune cookies and soccer into a retrospective?

 

(Text by Klara Obermair, translated by Linh Tran)

Subscribe to our newsletter

Lounges 

Lounges are like channels. Choose your favorite lounge based on your interests:
Project Lounge
Executive Lounge
Tips Lounge
InLoox Lounge

Blog Search