Impediment Spotting
So there I was in a meeting the other day (saving the world…yawn). Everything was going smoothly (too smoothly) so I did a quick spot check for impediments. You know, “Hey folks, before we wrap things up, are there any blockers we should be aware of?” There was the usual pregnant pause and then:
“The teams aren’t talking to each other. I think we should have a wiki page to share what we are doing.”
“We need a common defect tracking system. I have to look in too many places to find bugs.”
“We don’t do test driven development.”
“Bob’s not helping.”
Oh brother…Me and my big mouth. Where to start? One of the first things that I often encounter when soliciting impediments is the dreaded vague problem statement. Some aren’t even impediments at all. They’re just statements of opinion. Let’s take the TDD one as an example:
“We don’t do test driven development.”
Really? No kidding? That’s too bad. Why should I care? Seriously, I know TDD is supposed to be good for you (like motherhood and apple pie), but why should I care if we are doing TDD or not? Why is not doing TDD a problem? Do the teams do any unit testing? Do they have a high defect rate? Is there a lot of staff turnover? Now where did I leave my tiny little violin?
Let’s pretend for the moment that the problem gets a little further refinement:
“We can’t quickly validate our code and spend hours in debugging. We should do test driven development.”
Ah, I see…that’s a little better. Now I think I understand your problem. You’ve even gone so far as to offer a solution (how thoughtful). In fact, what we’ve done is mix up the problem statement and the solution. Ugh! In one fell swoop we have managed to describe the problem and eliminate a whole world of potential solutions from consideration. Brilliant! How about we just limit ourselves to the problem for now, shall we?
“We can’t quickly validate our code and spend hours in debugging.”
Now THIS is a problem statement (OK…impediment) I can work with. I know who is affected. I know what they are doing, I know why it’s a problem. I know where they end up. There’s a lot of information here. So now that we have a decent statement of our impediment, what do we do about it?
Well, you have a couple of options:
Do some root cause analysis (dig into that impediment and find out what’s going on)
Skip the root cause analysis, because you already know the answer. (No, I’m serious, why screw around? When you know, you know – you know?)
From there we brainstorm a few potential solutions and then we are off to the PDCA races!
You can get all of this from a crappy problem statement. Well, actually you can’t. That’s why you need to take the time to refine the problem statement. Notice that I didn’t just throw out the impediment in disgust in the very beginning. Sometimes an impediment is a clue and we end up the detectives.
Happy sleuthing!
#rootcause #PDCA #vagueproblems #problemsolving #rootcauseanalysis #problemstatement #Impediments