3 ms·

Before deploying new code, ask yourself and at least one other person “If this is going to cause a major issue, what would it be?” I love a premortem, but this

Before deploying new code, ask yourself and at least one other person “If this is going to cause a major issue, what would it be?” I love a premortem, but this isn't quite how I do them. I prefer to start long before a deploy, before a feature hits sprint planning. By asking my team "What could go wrong if we start this?" we often uncover some of the unknowns that can derail our engineering effort. It's particularly important to get the quality assurance team involved that early too, by getting them to think about how they'll test the feature - QA should be about implementing processes to assure quality after all.

nickm12 5y ago
When I first heard about premortems, the application was project planning. Before embarking on a project, you'd assume it failed and try to root cause the failures. You'd then take action to mitigate these risks (or possibly scrap the project completely if you discovered a fatal flaw, but that would presumably be rare). I've since used them to mitigate risks to high-profile events that you can't really simulate, like major product releases or peak traffic events. In those cases, it's important that you do the premortem at a time where it can make a difference. Ideally there is a time when you are more or less code-complete but still have a few development cycles before the big day where you would be otherwise working on polish work.