5 ms·

5 Whys is great for getting depth into one causal subtree, but based on a paper I once read, answers can lack breadth when there is more than one cause (which i

5 Whys is great for getting depth into one causal subtree, but based on a paper I once read, answers can lack breadth when there is more than one cause (which is often the case). It said that "Why" is often best answered with a directed acyclic graph of causal relationships. (Though when I tried to use a causal DAG for root cause analysis of an incident at my current company, I was told that I was wasting time and no one cares. But I thought the data I found was pretty interesting and worth exploring.)

wheelinsupial 5y ago
Regarding the lack of breadth of a 5 whys analysis, there is a fishbone diagram that can be used before the 5 whys to ensure more breadth. In manufacturing there is usually 4 big topics (person, machine, material, method), but there are many variations that can be used. Trees or other visual depictions can be used too. The point is to have some sort of structure and adapt it to your needs.
lowercased 5y ago
Similar here. Was pumped in an RCA with "why?" multiple times. The 'root cause' was I fucked up and missed something. But that was because "prod was broken right then, fix ASAP!" and no one else understands the problem, and we're understaffed, and people 'reviewed' the code without understanding what it was doing (or why) and one 'fix' led to another problem, and that 'fix' led to a third, and trying to explain this in an 'RCA' meeting confused the heck out of everyone because there were 3 different days/times people saw the problem, and could not understand it was one original thing that triggered, with cascading problems in the 'fixes', etc. You keep asking "why?" and only want one 'thing' to be 'actionable'... you will raise my frustration level. The root cause is an emergent property of understaffing, poor communication practices and a belief that everything can be reduced to a jira card providing sufficient context and understanding for a diverse audience with different skills and needs.
- sswastioyono18 5y ago
  In a japanese company that I worked at previously, answering RCA must be clear and in detail way. I got used to it so when I explain something to people, I want them to NOT ask any further question again because I compiled all the information they needed, including prevention. Their next response should be "got it understood" or clarifying their action. Other than that, I think I failed to explain things in a very basic way
- indymike 5y ago
  > The 'root cause' was I fucked up and missed something. It's really hard to do RCA when people are blaming themselves. It had to suck to be in that meeting. A really good RCA isn't about finding a single actionable thing, it's about finding our what the root cause of the problem is... which in this case, might have been whatever originally broke production and caused an emergency fix that failed three times.
  - lowercased 5y ago
    "It's really hard to do RCA when people are blaming themselves" Often, the root cause is someone made a mistake. You can say there should have been other systems to prevent/review/etc, but the root cause is a mistake a person made. You can '5 whys' it to death, but I made a mistake (or... someone did). "whatever originally broke production" - in this case, I made a mistake. That mistake wasn't caught until production. Then the fixes were all broken too. I don't always blame myself for everything, but if I've made a mistake, I'll own up to it. For me, it helps me be aware of what I can do to avoid those in the future. This may or may not be some rca-checklist other people can refer to, because... it's not 'actionable' to anyone but me.

wheelinsupial 5y ago

Regarding the lack of breadth of a 5 whys analysis, there is a fishbone diagram that can be used before the 5 whys to ensure more breadth. In manufacturing there is usually 4 big topics (person, machine, material, method), but there are many variations that can be used. Trees or other visual depictions can be used too. The point is to have some sort of structure and adapt it to your needs.

lowercased 5y ago

Similar here. Was pumped in an RCA with "why?" multiple times. The 'root cause' was I fucked up and missed something. But that was because "prod was broken right then, fix ASAP!" and no one else understands the problem, and we're understaffed, and people 'reviewed' the code without understanding what it was doing (or why) and one 'fix' led to another problem, and that 'fix' led to a third, and trying to explain this in an 'RCA' meeting confused the heck out of everyone because there were 3 different days/times people saw the problem, and could not understand it was one original thing that triggered, with cascading problems in the 'fixes', etc. You keep asking "why?" and only want one 'thing' to be 'actionable'... you will raise my frustration level. The root cause is an emergent property of understaffing, poor communication practices and a belief that everything can be reduced to a jira card providing sufficient context and understanding for a diverse audience with different skills and needs.

sswastioyono18 5y ago
In a japanese company that I worked at previously, answering RCA must be clear and in detail way. I got used to it so when I explain something to people, I want them to NOT ask any further question again because I compiled all the information they needed, including prevention. Their next response should be "got it understood" or clarifying their action. Other than that, I think I failed to explain things in a very basic way
indymike 5y ago
> The 'root cause' was I fucked up and missed something. It's really hard to do RCA when people are blaming themselves. It had to suck to be in that meeting. A really good RCA isn't about finding a single actionable thing, it's about finding our what the root cause of the problem is... which in this case, might have been whatever originally broke production and caused an emergency fix that failed three times.
- lowercased 5y ago
  "It's really hard to do RCA when people are blaming themselves" Often, the root cause is someone made a mistake. You can say there should have been other systems to prevent/review/etc, but the root cause is a mistake a person made. You can '5 whys' it to death, but I made a mistake (or... someone did). "whatever originally broke production" - in this case, I made a mistake. That mistake wasn't caught until production. Then the fixes were all broken too. I don't always blame myself for everything, but if I've made a mistake, I'll own up to it. For me, it helps me be aware of what I can do to avoid those in the future. This may or may not be some rca-checklist other people can refer to, because... it's not 'actionable' to anyone but me.