|February 12, 2018|
Part of the responsibilities of the Quality Assurance team is to find out why things go bad. This is typically done after the project gets deployed into production - otherwise known as a Project Postmortem.
The goal of a Postmortem isn't to blame people or processes. The goal is to highlight the issues and then come up with suggestions to fix the problem so it doesn't happen again.
The postmortem shouldn't just benefit the team working on the project, the data gathered should be shared so future projects can learn from past mistakes.
A few years ago, I put together a reference document as a guideline for a typical Postmortem. This is useful in starting the conversation and get some fresh ideas flowing.
Download the PDF version of the document and feel free to use it for your next Postmortem.
I find it more practical to send out the document to the individual team members a few days before the meeting so they can have some time to think about the issues and come up with viable solutions.
Schedule the meeting at least a week after the incident. If you wait too long some issues might get overlooked. This issues may come back to haunt another deployment.
Remember: Stay on track with the conversation - it's very easy to get side track. Use the "Parking Lot" to shelf ideas that are off topic.
Feel free to leave a comment about this post.