Abstract: As organizations experience with greater concurrency and integration between their departments and move toward a continuous delivery of customer-value, failure is assured. Asking "how can failure be avoided?" isn't as useful or relevant as focusing on
- "How does our organization react when failure occurs?" and
- "How do we create a sustainable, actionable process for describing, exploring, and remedying failure?"
Of course, retrospectives are not new to the Agile community. But are the "end of sprint" retrospectives we know and love enough?
As organizations integrate the work being done under the "DevOps umbrella" into their Agile practices, the need for a new type of retrospective becomes obvious: the operational retrospective. (Many operations teams know this as the "post-outage postmortem.")
An operational retrospective has a number of important differences from end-of-sprint retrospectives:
- Events can prompt them at any time, even multiple times per day in large enterprises.
- These events can generate a lot of data for review.
- Because they are prompted by performance problems and outages, they are often high pressure situations.
- Unlike our team retrospectives, many different actors become involved, as cross-functional engineers swarm on problems and leadership demands to know "Why?"
Altogether, this can create a breeding ground for finger-pointing, bias, and a host of other behaviors which destroys our ability to learn anything useful from the event.
But it doesn't have to be this way.
We'll examine the current thinking on organizational and technological failure and look at tools and techniques used by other industries (transportation, construction, manufacturing) to conduct their postmortems. We'll also look at the cognitive biases that often find their way into a postmortem process and why it's important to be aware of them when conducting our own operational retrospectives.
We'll finish by looking at techniques to conduct postmortems within your own organizations, both from a process/skill perspective and from a tooling perspective, to help ensure that the results of your postmortems are incorporated back into the organization's shared knowledge for the next time there's an issue with production, not just stored on some wiki somewhere that no one remembers to look at again.
Learning Outcomes: - Describe existing models for postmortem/retrospective analysis
- Describe the "New View" model of postmortems/operational retrospectives
- Recognize bias (situational and social) and how they impact the retrospective process
- Employ different linguistic structures for postmortem analysis
- Compare/contrast other industries' postmortem structure and processes and be able to select techniques relevant to their Operations-focused postmortems
- Familiarity with tools that facilitate the operational retrospective process and how they improve the organization's ability to act on the findings, learn, and improve
