patternMinor
Should we name names in a blameless post-mortem/retrospective?
Viewed 0 times
blamelessretrospectivenamespostnameshouldmortem
Problem
We want our post-mortems to be blameless.
Recently someone included this statement in a post-mortem report:
It was suggest that to be "blameless" we shouldn't include PERSONNAME. The suggested replacement was:
In a blameless culture, nobody should be worried about having their name listed in a report. In the first example, it feels blame-full to point out their name.
On the other hand, in the second example, someone could follow the link and see who the engineer was. This seems to be hiding someone's name without really hiding it. It feels like something we'd do in an organization that is having a problem with blame/shame.
What should we do?
Recently someone included this statement in a post-mortem report:
On DATE, PERSONMAME did code a fix (link), but forgot to merge it to masterIt was suggest that to be "blameless" we shouldn't include PERSONNAME. The suggested replacement was:
On DATE, the code fix (link) was created but the engineer failed to merge it to master.In a blameless culture, nobody should be worried about having their name listed in a report. In the first example, it feels blame-full to point out their name.
On the other hand, in the second example, someone could follow the link and see who the engineer was. This seems to be hiding someone's name without really hiding it. It feels like something we'd do in an organization that is having a problem with blame/shame.
What should we do?
Solution
Usually for a blameless postmortem, the best idea is to go further than the human error (which for a proper 5 whys should not arise, that's rule 11, but we're just humans :)) and complete the 5 Whys with the 5 Hows.
To follow on this particular case for a blameless postmortem I'd go few step further whith those iterations (For the sake of the example) of How possible follow up interpretation (possible answers):
Now you don't have someone who have forget to merge something, you have an analysis of how it was possible and more important, you have something actionnable to improve which is the main, if not the sole, reason to do a postmortem.
A more detailled criticism of the 5 whys (which as you show end often with a Who instead of a Why) can be found on O'reilly's blog post The infinite hows
To address the specific point of naming in the analysis, I'd argue neither the name nor the fix itself are of value, wording the step in the analysis as "An engineer wrote a fix and didn't merge it" without any link would be enough for the report.
To follow on this particular case for a blameless postmortem I'd go few step further whith those iterations (For the sake of the example) of How possible follow up interpretation (possible answers):
- How this fix has been left unmerged after creation ? (it wasn't reviewed and didn't follow the usual path)
- How did it miss review ? (That was urgent and straightforward, review wasn't necessary and decision was taken to deploy)
- How this process has been defined ? (It wasn't)
- How was the bug report closed without merge (No validation/no defined process for this case)
- How to prevent the problem arise again ? (Define the process and set validation/review even for quick patches)
Now you don't have someone who have forget to merge something, you have an analysis of how it was possible and more important, you have something actionnable to improve which is the main, if not the sole, reason to do a postmortem.
A more detailled criticism of the 5 whys (which as you show end often with a Who instead of a Why) can be found on O'reilly's blog post The infinite hows
To address the specific point of naming in the analysis, I'd argue neither the name nor the fix itself are of value, wording the step in the analysis as "An engineer wrote a fix and didn't merge it" without any link would be enough for the report.
Context
StackExchange DevOps Q#4604, answer score: 3
Revisions (0)
No revisions yet.