…and start solving them. Sounds great, but what does it mean? What’s the difference between managing a problem and solving it?
I recently held a workshop on using Scrum to drive process improvement at CIISA 2009, held in Guadalajara, Mexico, where I focused on using Scrum as a process improvement process to find problems with a development organization’s processes and practices and then using the A3 Problem Solving process¹ to drill down to the root causes and eliminate them. Let me give you a brief overview on what I covered.
Every software development organization can deliver some functionality, at some level of quality, in some amount of time. But can they deliver a specific, committed amount of functionality, at a high level of quality, in a specific amount of time? That is what we are asking for at every sprint planning meeting. Do we get it? Usually not, when we first transition to Scrum. Failing to meet a commitment is not unique to Scrum; the vast majority of traditionally-managed projects fail to deliver the desired functionality within the established schedule and cost constraints. One advantage of Scrum is that you fail faster, while you still have time to do something about it.
Failing to deliver isn’t bad… if you seize the opportunity to improve. Failures happen for a reason. What was the reason? Why did you fail? This next statement may seem tautological in its obviousness, but true wisdom is often found in simple profundity. You failed because a problem exists that prevented you from succeeding. You won’t stop failing until you recognize the problem, understand the root causes, and then make the changes required to eliminate the root causes and solve the problem.
Is this how most companies handle problems? I don’t think so. It’s human nature to only want to see the good things. Twenty-five hundred years ago, the Athenian playwright Sophocles wrote that “No one loves the messenger who brings bad news” to reflect the then-common practice of an angry ruler killing the bearer of bad tidings. Shakespeare’s “Don’t shoot the messenger” has become a common metaphor, advising us to not blame the person for the problem. We see this around us every day; someone yelling at testers when they find a lot of bugs, or rejecting high estimates and demanding ‘more reasonable’ ones, etc. Perhaps we need to rethink our approach to problems that are expressed as bad news.
At Toyota, honesty is prized. Managers are taught to present bad news first, and no one is admonished for doing so. To the contrary, managers are severely admonished if they don’t bring bad news to their superiors. Similarly, Jim Collins writes about the Stockdale Paradox in “Good to Great.” Companies that excel do so because they maintain faith in their ability to prevail in the end while simultaneously confronting the brutal facts of their current reality, whatever those facts are. They embrace the truth, no matter how awful it may be, because they understand problems must be acknowledged before they can be solved.
Ken Schwaber, one of the creators of Scrum, says “Scrum doesn’t solve your problems, it exposes your problems.” Scrum isn’t a Silver Bullet. Your organization needs to solve its problems if it wants to get better. Managing a problem is kicking the can down the road, working around the problem, putting it off until it can no longer be avoided. All too often that is exactly what we do.
For instance, let’s say that one day last week you walked out to your car and noticed the front left tire was low on air, so you went by the local gas station on the way to work and filled it up. A few days later, you noticed it was low again, so you filled it up again. You managed the problem. Now the weekend is here, and you’ve scheduled a round of golf with your buddies in the morning followed by an afternoon at the stadium watching your local team. Now you have a choice: do you change plans so you can go down to the gas station and get the leak found and fixed, or not? Sure, you can keep topping it up every couple of days, but we all know what eventually happens to a leaky tire. It fails at the worst possible time, perhaps a blow-out on the freeway, or else we walk out after a late night at the office to find ourselves staring at a flat. Problems that aren’t solved only get worse, and the solution becomes more onerous.
Solving problems is a choice; it is up to your organization to solve them… or not. You have to have the courage to exercise integrity at the moment of choice², to make the decision to solve problems because not making a decision is making a decision. Actively decide to solve your problems.
Contact me if you’d like an A3 Problem Report template, along with examples and instructions.
______
¹Tom Poppendieck, Gabrielle Benefield, and Henrik Kniberg led an excellent workshop on value stream analysis and problem solving using the A3 Problem Solving process at the Agile2009 conference… thanks!
²The Seven Habits of Highly Effective People, Covey, Stephen
Technorati: gu7dh42snr