Good Project Retrospectives

Retrospectives can potentially be one of the most beneficial tools in software development; then again most retrospectives I’ve participated in where a complete waste of time…

The idea of a retrospective, or postmortem as we called them about 10 years ago, is simple. At the end of the project take the time to define 3 things:
1. What went right and should be kept?
2. What went wrong and should be changed?
3. How to make things better the next time around?
So, how come most projects either don’t perform retrospectives, or carry out postmortems but don’t learn from them and keep doing things in the same unproductive way?

The answer to the first part of the question comes from the statement behind the second part. If a Manager “tries” doing retrospectives on a couple of projects and doesn’t get any added value, why should she continue doing them?
I think the problem is not with the concept of the Retrospective, but with how it is carried out in many Organizations and what is done with the results that come out of it.

There are a number of recurring mistakes and wrong-doings that can be seen in most postmortem failures:

1. Lack of Manager Leadership – If Senior Managers don’t give retrospectives their full attention and don’t communicate (using personal example) their importance, then middle management and the rest of the team will not treat these activities seriously.
Postmortems need to be lead by someone with authority and charisma; this is the only way to successfully guide the team through the complex process of reviewing, analyzing and learning from past activities and results.

2. Not gathering issues and facts throughout the project – Bad retrospectives focus mostly on the issues that happened during the last legs of the process, since these are the things we remember better and the ones that still have an emotional effect in most of us.

It is very hard to keep track of issues if we don’t record them when they happen, and it is even harder to analyze them if we don’t have objective data. The Project or Team manager needs to find ways to record important issues when they happen, and store information that will help the team understand how and why they took place.

A good idea I got from a Group several years ago was to create an e-mail alias that people could send important issues as they happened. At the end of the project the team running the retrospective can use these e-mails as a starting point for their process.

3. Letting postmortems turn into Witch Hunts – In some Young Organizations or after a very stressful project a postmortem can easily turn into a personal Witch Hunt. The most effective way to stop this from happening is by not letting it start in the first place.

If during the analysis and discussion process the team starts taking the subject into personal tones and levels, it is the job of the Manager to stop this on-the-spot and to turn the subject to a solely constructive and impersonal discussion. If necessary she should make a time-out or call a recession until people have a chance to cool down.

4. Lack of clear Lessons Learned, Action Items and Follow-through Plan – The big mistake of creating a large list of things to improve and yet continue working in the same way…Improvement doesn’t happen by itself, it needs to be pushed by people who keep track of the unwanted behavior and constantly make an effort to correct it.

A good practice is to focus on only 3 things to improve from each retrospective, and then during the following project to implement a way to measure these 3 things and constantly track their improvement.

I personally like to take my targeted improvements and start reviewing them on the weekly (or periodical) management and team meetings, 10 minutes before each meeting and 2 minutes during the meeting itself is usually enough to ensure these action items stay in-mind and on-track.

Last but not least, as I was looking more material for this article I found something really amazing from a group of people I was not taking seriously enough. The Game Development Industry, or at least the New Engineers specializing in this area have been using and publicly posting their retrospectives more than any other groups that I know of. I suggest you take the time to review this site, and learn both from the way the can seriously analyze their wins and mistakes; you might even read something that can be leveraged to your team or project.

About PractiTest

Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.

Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.

With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user’s needs.


  1. What do you do when a ShowStopper escapes into production? | QA Intelligence - a QABlog - August 9, 2011

    […] Step 2 – Analyze Once the critical part is over and the issue has been solved, but before people “move on” with their lives and tasks, its better to make sure you understand what went wrong. The analysis process should never be a witch-hunt, it should be an opportunity where everybody feels safe to collaborate and bring forward all the factors that contributed to the problem happening in the first place (both internal as well as external factors). This activity is fairly common and it is called a retrospective or post-mortem. […]

  2. How to use easy to find bug information to improve the quality of your testing | QA Intelligence - a QABlog - April 11, 2013

    […] This metric can be used within the process to modify your current project, or during the project post-mortem to provide feedback for future […]

  3. What did I learn this year as a Tester…? | QA Intelligence - a QABlog - April 11, 2013

    […] and we are getting to the end of the year. In the spirit of On-Going-Improvement and the art of Good Retrospectives I decided to take a look back at these past 12 months and make a list of what I’ve learned […]

  4. On-Going Improvement – running a Marathon one step at a time | QA Intelligence - a QABlog - April 11, 2013

    […] they’ve been around for a long time and are used in all sorts of methodologies such as Project Retrospectives and even in as part of the Scrum Methodology.  I simply think that we can take advantage of them […]

Leave a Reply