Guidance on Performing Retrospectives
craigkerstiens.com
craigkerstiens.com
The one thing I would add to the article is spend time to calculate the business impact of the incident and start the retrospective with this. This is something that might not be that straightforward for engineers to know and might need help from other people within the company to understand. How many customers were impacted and in what way? E.g. if you had an outage on your web site where people could not check out, how many orders did you lose and what was the total value? The answer will depend if people completed their order after the outage was over, if they could use e.g. the mobile app that time and so on. Pinpointing the business impact can help understand just how severe that specific outage was (and how that part of the system is connected with everything else).
The business impact is something that is important, and we often do measure. I often aimed to separate two somewhat as leading with that can create some unintended consequence of aiming to point blame/etc.
I also like and use the term postmortem to mean what this author calls retrospectives, and use the term retrospective to mean a more general look back without being event-based.