Meaningful RCAs: Asking Why

I did my first RCA back in 2019. We looked at each stage of development and used a “5 whys” approach to tap into why it wasn’t caught at this stage. We maintained this approach over the next few years and when I switched to my more coaching/leadership role in 2023, I started running them with the teams that I supported. We actually used Google Sheets or Excel for these. I’d have my bunch of questions to ask then I’d be asking the question then “why” to the answer. For example:

• “During refinement did we call out our support for different browsers”
  • Nope, we should have
    • “Why wasn’t it raised? Tell me about your refinement”
    • Well we look at the high level requirements and turn that into ACs. We don’t look at more non-functional aspects.
      • “Why not?”
      • That is for the story’s test plan I guess.
        • “Why does this only impact testing and why isn’t that part of the estimate?”
        • … and so on

The point I’m trying to make in the fictional example above is that rather than just taking that first answer, you tap into it more to understand the real reason why the issue happened.

To help with asking questions, I like to lean on my ignorance – even if I had actually done my homework. It is more powerful to get someone to explain their problem or have to articulate what they did than you saying X & Y was done but not Z. This is why despite having read the ticket several times by now and dived through Slack conversations, I’ll ask who worked on it. I’ll ask whether everything went OK. I’ll ask whether topics like this came up in review.

My point here is I’m not running the RCA to have an answer to “why did this bug come to be” but so that we can discuss it and learn from it. This is what makes an RCA meaningful.

In time I’ve adapted and improved my questions, including the order that I ask them… but I’ll cover more in a subsequent post.