Conducting A Project Retrospective
Many resources are available for conducting a retrospective. Esther Derby provides a five-step approach for retrospectives in Scrumpedia. Although the focus is on two-week retrospectives, you can use the same steps for a post-project retrospective. Derby’s steps include: (1) set the stage, (2) gather data, (3) generate insights, (4) decide what to do, and (5) close the retrospective.
Elise Keith presents a three-step process on the Lucid Meetings Blog: (1) review the project, (2) discuss what worked well and what didn’t, and (3) action planning: identify specific ways to improve future work.
Norman Kerth’s handbook on project retrospectives provides four questions to guide a retrospective: (1) What did we learn? (2) What should we do differently next time? (3) What did we do well? (4) What still puzzles us?
There isn’t one right way to do a retrospective. A quick search on Google yields dozens more articles on how to conduct a retrospective. Below, I discuss some key features that every retrospective needs to include.
Small changes have a bigger impact than good ideas that never happen.
At the end of the meeting, you need to walk out with some concrete actions to take. Big exciting plans feel great, but it’s a real let-down if the change never happens. If people see that these meetings generate all kinds of ideas, but nothing real ever comes of it, they’ll stop participating.
For a meaningful result, make sure the action plans coming out of your meeting are realistic, and that the people responsible for the changes can actually implement them. The change can be big if the person responsible has the time and authority to put it in action. But if not, get creative and go for the quick win that the team can control.
Another tip on this one: if you and your team only have enough influence to make tiny changes, retrospect more often. Those tiny changes will compound over time.
See more: The ROI of Agile Retrospectives: How Effective Rertros Can Improve Your Bottom Line