Trick question: What’s the problem?

Maybe the problem goes away if I close my eyes?


Let’s say you witness a boy fall off his bike. What do you see? What do you do? If you help the kid back up on his bike, most would argue that you’ve solved the issue at hand. But isn’t it likely that the boy will soon fall off again? And if that is the case, did you really solve the problem?

If we scratch the surface, there’s a whole range of other problems hidden behind the most obvious one. Why did the child fall off the bike? He probably needs more training in order to reliably control a bicycle. He certainly lacks basic risk management skills. Do we have an equipment problem? Perhaps the bike is of the wrong type or size for the child?

Riding a bike is basically a process. I don’t know about you, but when the rider of the bike ends up face down in a ditch  more often that not, I see room for improvement.

Let’s leave the kid and his bike for now. Say a customer reports a bug in your software. What do you do? Fix the bug, of course! Problem solved, right? Wrong. Why wasn’t the bug discovered before the software was released to the customer? Your test team (if you even have one) should have prevented that from happening. So improving your test and QA process will do the trick, surely? The QA manager raises his hand: Wait a minute, isn’t the developer supposed to test his work before releasing it to us? A lazy developer must be the real problem here!

At this point you’re probably on to me. “I see what you did there,” you say with satisfaction in your voice. These are all reactive solutions to the real problem. The real question. Why did the bug occur in the first place? Lazy or incompetent developers? Maybe. Someone has created a piece of software that doesn’t work as intended. You may guess my next question: WHY?

When I find myself in a similar situation, I often find that the developer wasn’t given enough information to make the right choices during development. Let’s all say it together: Shit in, shit out. If I had a better developer, he may have recognized the turd when I shit in his hand, but I can hardly argue the origin of the turd itself.

So we have established that I’m full of shit, but how did we do that? We did a (somewhat informal) root cause analysis. As a fan of Lean and the heritage from the Toyota Production System, I like the 5 Why’s. – It’s a process where you basically keep asking why until you arrive at the real source of whatever problem you need to resolve.

The kid fell off his bike – Why?
He doesn’t really know how to ride a bike all that well – Why?
His dad doesn’t have time to teach him – Why?
He works all the time – Why?
He thinks making money for his family is more important than being there for his kid.

So there you go. Not only did you learn how to solve problems (instead of just removing symptoms), you also got a life lesson. No worries, you can thank me later. Now put down your laptop and go be with your family. And never solve another problem without asking WHY at least five times!

@TSigberg

Advertisements

Posted on March 25, 2012, in Life, Management and tagged , , , . Bookmark the permalink. Leave a comment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: