These meetings go by many names – lessons learned, postmortems, retrospectives, after-action reviews, wrap-ups, project “success” meetings. Regardless of what you call them, they all have the same goal and follow the same basic pattern.
Retrospective – looking back on or dealing with past events or situations oran exhibition or compilation showing the development of work over a period of time.
An Agile retrospective is a meeting that’s held at the end of an iteration (sprint) in an agile project. During the retrospective, the team reflects on what happened in the iteration (sprint) and identifies actions for improvement going forward.
The Project Retrospective dedicates time to reviewing a completed project and learning from both the successes and the failures so the team and organisation can improve how they work going forward.
The general purpose is to allow the team, as a group, to evaluate its past working cycle. In addition, it’s an important moment to gather feedback on what went well and what did not.
Classic questions answered in these meetings:
- What did we set out to do?
- What actually happened?
- Why did it happen?
- What are we going to do next time?
“We do not learn from experience … we learn from reflecting on experience.”; John Dewey
Retrospectives give a team time to reflect on what they learned.
The process for debriefing a project covers roughly the same topics as the quick after-action discussion.
- Review the Project
- What went well and did not
- How can we do it better next-time
Review the project
Start by reviewing the project facts: goals, timeline, budget, major events, and success metrics.
In order to come up with useful ideas that everyone can agree on, the team needs a shared understanding of the facts and insight into the parts of the project in which they may not have been involved.
It’s important not to skip or rush through this step, especially for larger projects. People will arrive at the retrospective ready to discuss and solve problems, often assuming they know everything they need to know about what happened. This is rarely true.
If you are reviewing a project as a team, that means it took many people with unique experiences to get to that point. This step ensures everyone gets all the facts straight before they try to solve problems they may only partially understand.
What went well and what did not
This is the heart of the meeting. Everyone shares what they learned during the project: both the good and the bad.
In my opinion, this is the most fun and most challenging part of the meeting. As the meeting leader, you have an enormous impact on the success of your retrospective by deciding which questions you’ll ask and how the team shares their answers.
How can we do it better next-time
Real change is the ultimate measure of a retrospective’s success. To ensure that your retrospective results in something actually getting better, you’ll end the meeting by creating a specific action plan for improvements.