1. Nothing, but I had 5 bullets to fill and he thankfully served the stereotype.
2. Anyway, skipping the bullets now.
What bothers me about this "presentation" is that it's the prototype pointless "biz-speak" ramble that many of us have to deal with every day.
He packs a nugget of truth ("when shit happens, ask why!") into a truckload of superfluous verbal padding and tries to sell it as some sort of great revelation, all the while completely ignoring the reality of the situation™.
Over here in the real world root-cause analysis falls under common sense for every engineer worth their salt. We are naturally inclined to fix problems at the source, simply because we don't like fixing stuff in the middle of the night, because we hate fixing the same thing repeatedly, and because we like paychecks.
However, his video lacks the tiniest bit of acknowledgement of reality, where the answer to the third 'why' usually amounts to something like "because the boss decided to outsource this" or "because the deadlines make no sense" or "because 3 people are doing the work of 8 here" or "because the product manager is incompetent" or "because they wouldn't listen when we told them 5 times this would happen".
Yes, these are people-problems, too. But you rarely see those addressed, presumably because these shiny polished biz-school fortune cookies tend to
conveniently ignore how the fish, more often than not, stinks from the head.
I could go on for a while on his rosy misconceptions about "proportional investment at every stage of the problem" (duh! can it be that simple!) and "training", but this is getting too long already and I'm going to be voted to -8 and beyond either way.
Of course root cause analysis is common sense, anyone with a couple of braincells to rub together gets it as soon as it is explained to them.
However as I understand it Ries' drive is for it to be a institutional practice, you are right an engineer will get to #3 as you say and there it will end. However if the entire company has taken up the practice it won't stop there. This is especially true if root cause analysis isn't used to assigning blame but fixing issues.
As to management and people issues, he addresses that directly in the video talking about management issues being part of the process. So this aspect isn't ignored and is promoting them being addressed.
I am certainly interested in what misconceptions there are is in "proportional investment at every stage of the problem" as I have used this stuff successfully in the past.
Well, you can formalize common sense only so much before it turns into parody.
I've been in these meetings too often where one (or more..) of the managers would follow their formulaic script, repeatedly uttering these catchy phrases without ever grasping the kernel of the issue.
Yes, "proportional investment" sounds awfully catchy. Yet it's simply not applicable in any kind of interesting situation. You can't "proportionally invest" into fixing a cronjob that shouldn't exist in first place but had to be rushed as a bandaid to meet unrealistic requirements.
You can't "train" a manager to make reasonable trade-offs when he has a track-record of doing the opposite.
These are literally the two most common root-causes that I have seen. And it would be great if the "5 why's" were ever executed consequentially, but they are not. In this type of meeting the analysis always ends before it gets to the point of questioning the guy who was calling the shots that went in the foot.
The cases where the formulaic "5 why's" are actually applicable are the uninteresting ones, the easy ones, the no-brainers.
It's the cases where the intern screwed something up - yes we shouldn't give critical stuff to the intern. Or the cases where not enough headroom was planned - yes we should be more conservative. In short: It's the cases where nobody important gets hurt by the conclusion.
I have never seen a people-problem being solved by someone following a catchy formula.
You either have the common sense to identify and the balls to tackle these kind of problems - or you're likely part of the problem in first place.
But in functional teams all of this isn't even something anyone talks about... Which makes videos like the above seem so surreal and detached from reality.
In this type of meeting the analysis always ends before it gets to the point of questioning the guy who was calling the shots that went in the foot.
One of the things I really enjoy about 5 Whys done well is that it can be done asynchronously. You don't need to gather everyone into a room for a long drawn out retrospective, preach lofty best-practices that everyone knows, and come out of it with nothing actionable on a reasonable timeframe.
Instead, someone who was close to the incident can draw up a quick email with the 5 whys, a tally of person-hours spent on the incident, and send it out quickly.
Oftentimes the answers from the 5Ws /are/ obvious to engineers -- we need more monitoring! that wasn't tested well enough! we didn't have time to prepare for this problem! -- their power comes in formalizing cleanup of technical debt, and prioritizing it appropriately.
Production problems don't get swept under a band-aid, new features get queued until the proportional investments are made.
And, yes, if the 5 Whys has management buy-in, it does address why the problematic cron job was rushed into production in the first place.
I think you can teach a manager with a track record of bad tradeoffs. The first step is showing that manager that their track record isn't as good as they may think it is. And that's hard to do in a single incident, so consistent feedback over time, as Eric suggests, has a chance to help enlighten.
If the past track record is bad, and one opportunity to enlighten is pursued and they "don't get it", that's ok. Either another chance will come up in the future, or it won't. If it doesn't, there isn't really a problem.
I believe that thinking like this is helpful by giving license to "demand fixes for things that aren't yours to fix". Specifically, why stop in the example at fixing the bad code? That's what some organizations, perhaps more than half, would view as sufficient.
2. Anyway, skipping the bullets now.
What bothers me about this "presentation" is that it's the prototype pointless "biz-speak" ramble that many of us have to deal with every day.
He packs a nugget of truth ("when shit happens, ask why!") into a truckload of superfluous verbal padding and tries to sell it as some sort of great revelation, all the while completely ignoring the reality of the situation™.
Over here in the real world root-cause analysis falls under common sense for every engineer worth their salt. We are naturally inclined to fix problems at the source, simply because we don't like fixing stuff in the middle of the night, because we hate fixing the same thing repeatedly, and because we like paychecks.
However, his video lacks the tiniest bit of acknowledgement of reality, where the answer to the third 'why' usually amounts to something like "because the boss decided to outsource this" or "because the deadlines make no sense" or "because 3 people are doing the work of 8 here" or "because the product manager is incompetent" or "because they wouldn't listen when we told them 5 times this would happen".
Yes, these are people-problems, too. But you rarely see those addressed, presumably because these shiny polished biz-school fortune cookies tend to conveniently ignore how the fish, more often than not, stinks from the head.
I could go on for a while on his rosy misconceptions about "proportional investment at every stage of the problem" (duh! can it be that simple!) and "training", but this is getting too long already and I'm going to be voted to -8 and beyond either way.