# Guidance on performing retrospectives

DevFeed: [Guidance on performing retrospectives](<https://devfeed.tech/articles/guidance-on-performing-retrospectives-41203.md>)

Original publisher: [Read original article](<https://www.craigkerstiens.com/2017/12/26/Guidance-on-performing-retrospectives/>)

Author: Map

Published: 2017-12-26T20:55:56Z

Content type: tutorial

Language: en

Sources: [Craig Kerstiens](<https://devfeed.tech/sources/craig-kerstiens.md>)

Topics: [retrospectives](<https://devfeed.tech/topics/retrospectives.md>), [incident](<https://devfeed.tech/topics/incident.md>), [Process](<https://devfeed.tech/topics/process.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [incident](<https://devfeed.tech/tags/incident.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [process](<https://devfeed.tech/tags/process.md>), [retrospectives](<https://devfeed.tech/tags/retrospectives.md>)

## AI overview

This article explains how to conduct incident retrospectives. It recommends documenting a complete timeline and relevant chat logs while details are fresh, tracing causes beyond the immediate outage, and structuring the meeting around what went well, what did not, and follow-up actions.

## Source excerpt

In my career I've had to conduct a number of retrospectives. Ahead of them it already sucked, there was an outage at some point, customers were impacted, and it was our fault. Never was it solely on our underlying infrastructure provider (AWS or Heroku), nope the blame was on us and we'd failed in some way. And as soon as the incident was resolved, it wasn't time to go home and decompress with a beer, it was time start the process of a retrospective. Finding the motivation to get right back to work is tough, but not losing time is important. There is probably a lot out there on retrospectives, and in general I was well rehearsed at them. But since I'd not performed a large scale one in a few years I found myself rusty and thought it'd be good to share some of our process. Capture details immediately It may not be clear if you've not been involved in many, but a retrospective is more than just a meeting to discuss what happened and how to fix it. It's an overall process, it begins with capturing thorough details of what happened. The start is a timeline. The best thing to do is capture the details while they're fresh. Start with a google doc and simply document the timeline of everything. Capture chat logs that are relevant while they're fresh in history and easy to find. The start of an outage likely wasn't the start of the timeline, there may have been something that happened days, weeks, or even years ago. Don't just start from the time things went offline, go back to the causes as much as possible. If code was committed a year ago that was the offender make sure to note that. Running the retrospective (the meeting part) There are a number of various good practices for running the retrospective itself. There are also a lot of different formats, all valid each with their own pros and cons. You can do with a basic timeline, what went well/didn't, do a five whys analysis. I tend to prefer a clean and dry analysis of timeline, what went well and what didn't and what w