In hindsight, every project offers you some insights – positive as well as negative ones. You should use this treasure trove of experience to optimize future projects and improve performances. In agile project management this is called ‘retrospective’.
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.
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?
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
Phase 2: Gather data
Give an overview of the events that lead to the finished iteration.
Phase 3: Generate insight
Phase 4: Decide what to do
Phase 5: Close the retrospective
Summary of the main points discussed and decided in the retrospective
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.
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?