Imagine this: your team has been working on a big feature for the last couple months. You’re about to have the first big milestone of the project: an observation in a real classroom. So exciting! But you can’t shake the feeling that things will go wrong in surprising and terrible ways… what if you forgot something? Good news: that’s normal, and you’re human. Yay! Bad news: your team probably has similar feelings of dread. Hmm, what to do…
How about a pre-mortem?
“A pre-what-now?”, I hear you say, “Don’t you mean post-mortem? And don’t you usually do those after something has already gone wrong?” Well, yes! We traditionally do retros after the fact, but with a little re-framing they’re also useful for talking about things that might happen.
Try this: set up some time with your team. An hour should be about right, with enough time to make changes before your milestone. Include everyone who makes sense; at NoRedInk, this meant including the engineers, product manager, and designers a couple days before our QA deadline. When you’re all together, set the scene:
OK, let’s talk through possible failures while we’re getting ready to ship. Imagine that it’s a month after release, and our project has failed utterly. We have to talk about what happened so that we can avoid making the same mistakes again—what do we say?
Next, give everyone 10 minutes or so to write. Privacy is important here, so don’t do it in a shared document. You want people to be able to share their worries and feelings unguarded. Keep yourself open to possibilities! People should feel free to write down anything they can think of, regardless of likelihood. This is actually more important than you’d think: in a previous NoRedInk pre-mortem, we said “everything shy of natural disasters is fair game,” but then our classroom observation was cancelled due to a natural disaster and we didn’t have a backup plan. Whoops, lesson learned.
You should also make it clear that people should be candid. The big goal of this exercise is to avoid problems where we can, so if people hide problems they know about you might as well not do it. Lead by example here!
It may be clear by this point that this exercise will really only work well in an established blame-free environment. If people cannot be honest about the things they’re worried about, they’re probably not going to speak up just because you asked them to. If you find that your organization is having trouble with blaming individuals feet in these kinds of scenarios, I’d recommend reading and applying blameless post-mortems.
After the writing time is up, go around and give everyone a chance to share one thing that they’re most worried about. Have people raise their hands if they wrote down the same thing. Write down a summary of what the speaker said, and how many hands went up. Do several rounds here, sharing one item each time you go around. In a medium-size group (say 6 people), you’re more likely to run out of time than concerns, so you will probably have to stop short of sharing everything to make time to address the concerns people shared.
Typical concerns will range from the annoying (“the user’s device didn’t support this feature”) to human error (“we forgot to turn on the feature flag for the teacher”) to the extreme (“we lost all student writing entered in the tool.”) There’s room for all of this here!
Next, start at the thing that the most people had written down. Remembering that we’re treating this as something that already happened, how could it have been avoided? What should you have done differently to avoid this failure? Now might be a good time to apply 5 Whys or another root cause analysis technique. Make a plan to address these root concerns now!
Once you either have addressed everything or run out of time, thank everyone for their honesty and adjourn. After the meeting, work through the list with whoever is responsible for setting priorities to figure out what needs to be addressed right away. At NoRedInk, that means the team lead and product manager usually sit down to figure out prioritization.
And, that’s it! With this list in hand, you can put mitigations in place to avoid the errors you were about to blindly stumble into. Hooray! At NoRedInk, we were suspicious about this practice originally but gave it a try to see how it would actually work. We ended up being pleasantly surprised! This technique is not only helpful for avoiding avoidable errors, but is also cathartic for the team. There’s nothing quite like hearing from someone that they have also been worried about the things you are!
Next time you’re about to launch something, I hope you’ll consider making pre-mortems part of your planning process.
Further reading: - Performing a Project Premortem from the Harvard Business Review - Blameless PostMortems and a Just Culture from Code as Craft
Brian Hicks@BrianHicks Engineer at NoRedInk
(thanks to Michael Newton, Michael Hadley, and Anita Nuthi for reviewing drafts!)