Sarah: “Whoa, whoa, whoa, Walter. Where are you going in such a hurry with that look on your face? You look like you’re chasing that guy who stole Christmas.”
Walter: “Grinch.”
Sarah: “What?”
Walter: “It was the Grinch that stole Christmas.”
Sarah: “Stop changing the subject, Walter! Where are you going?”
Walter: “I’m going to the Frboz 2.0 Project Post Mortem, and it’s gonna be pure hell. It was over 100% late, bad quality, angry customer. It’s a classic. And I wasn’t even on it. I’m supposed to be there to criticize the project leader.”
Sarah: “How did that happen? I thought they went through all of that on 1.0, didn’t they?
Walter: “Yes they did, and they had a post mortem and they made changes and it seems to have made things worse. They blamed a few people and then left them to work on the 2.0 project because they learned something by being blamed, so they were pretty demoralized to start with. The post mortem decided to be more rigorous on signatures, so the Requirements phase took twice as long as planned. Every time they tried to get all 12 people to sign, one of them had a change to make. Same thing happened during System Test. They were supposed to get CTO approval for every push to pre-production, but the CTO was never around and she had to be completely briefed on everything that had happened in that build when they finally found her before she would sign. Everything took ages! In the end, everything they did made things worse. I don’t know what to do. This meeting is going to rip some people up, and for no reason that I can see.”
Sarah: “Hey Walter, I have an idea! What if you tried to get them to look at root causes instead of concentrating on blame for surface symptoms? Maybe they would discover some useful ways to actually improve things. What do you think?”
Walter: “You know, Sarah, it’s crazy enough that it just might work. Remind me of some easy ways to do root cause analysis. I’ll only get maybe one or two chances to make my point.”
Sarah: “Try the 5 Whys. It’s a technique from Lean Manufacturing, but it works really well. Start with a symptom and ask ‘Why is that?’ Then when you get an answer, ask ‘Well, why is that?’ When you get that answer, ask it again. Do it a bunch of times and you’ll eventually drill down to a root cause. Ask ‘Why?’ five times. Get it?
Walter: “OK, let me see if I got it right. I pick a symptom, like ‘requirements not agreed on time’ and ask “Why?”. Then they say ‘…because it was too hard to get all 12 signatures.’ So then I say ‘Why was that?’ And they say ‘…because every time we made a change and went to get the signatures, one of the people would have another change to make.’ So then I ask ‘Well, why did that happen?’ And they say ‘Because everybody kept learning more about what the product should be.’ And on and on until eventually we find out something like ‘Oh. It’s impossible to get all the requirements right up front.’ Or whatever. Then we can figure out how to address that root cause. Is that it?
Sarah: That’s it, you’ve got it.
Walter: Gimme five, Sarah! Thanks for the help!
About the Author: Alan Atlas is a poker player, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.

