Here’s my default approach to problem solving and organizational change. Basically a light-weight version of the A3 problem solving approach and Toyota Kata.
(BTW my keynote at ALE2012 next week is on a similar topic: “Everybody wants Change, but nobody likes to Be Changed”)
- Give the problem a name to hold on to. For example “bugs in production”. Might be rephrased later. Keep it neutral, no finger-pointing.
- Identify the different perspectives on the problem. Ex: developer, tester, operations.
- Get some key people together from these different perspectives (people who are affected by the problem and care about it), and have an informal discussion in front of a whiteboard. Example: one developer, one tester, one ops person, and the product owner. We want a small number of people, covering a wide perspective.
- Describe the problem, see if everyone agrees that it is a problem. Possibly rephrase it.
- If there is a simple obvious solution, just do it. Sometimes, just getting the right people into the room is more than half the solution.If the problem is complex, or recurring, or has no obvious solution, then go on:
- Discuss if this problem is actually worth solving. You can’t solve all problems at once, so it’s worth asking if this is the right problem to be focusing on right now. If so, go on:
- Do root-cause analysis using 5 why’s or a cause-effect diagram or similar, to understand the nature of the problem, and reduce the risk of solving symptoms instead of the real problem.
- Discuss what “perfect” looks like (“Definition Of Awesome”). If we didn’t have this problem at all, what would that look like? Example: “Zero bugs in production”. Doesn’t need to be realistic – perfect is a direction, not a place.
- Discuss what one bold step towards perfect would look like. Example: “50% reduction in production bugs, and when a bug is found it is fixed within 1 hour”. Should be challenging but not impossible.
- Brainstorm a bunch of changes you could do, that might get you to that first step. Be creative. include simple “quick-n-dirty” ideas as well as wild & crazy ideas.
- For each idea, list the most obvious pluses and minuses.
- Decide on one change to execute. See it as an experiment. If you have trouble choosing one, do dot-voting or a consensus vote (everybody writes a number 1-5 next to each idea, to show how much they like each idea). Don’t spend too much time deciding, you don’t know in advance what will work anyway. Just pick any one that doesn’t obviously suck.
- Find out who is affected by the change, get their buy-in. If you don’t get their buy-in, find out what it would take to get their buy-in. Or go back and choose one of the other ideas that have better buy-in. Organizational change doesn’t really work without buy-in.
- Do the experiment! And schedule a time for followup.
- ….. (experimenting)….
- At the followup meeting: Bring data and evaluate what happened. Example: How many production bugs have we had? How long did they take to fix?
- Discuss lesson learned, and decide if the problem is still a problem. If so, go back to step 10 or 11 and do another iteration.
You might want to take some notes as you do these steps. Keep it short. Draw pictures. There, that’s your A3 🙂
Great Henrik! Yes… and… (:D)
If the nature of the problem is complex, the solution/action to take is not straightforward and there is agreement that it is a problem worth solving, I’d certainly suggest a bit (or a lot!) more fact finding on the current situation, beyond people’s perception/experience, to understand what is the real gap with the expectation. This is avoid going fast in the wrong direction (although I appreciate that, when dealing with complex adaptive systems, even a potentially inadequate countermeasure may “poke” the systems just enough to change the overall dynamics ;-)).
I’d also generally move step 8. (cause analysis) after step 10. (the bold step towards ideal, i.e. the target). The reason is that we focus on WHAT before WHY. I often see the cause analysis as “what cause(s) is/are likely to be in the way of reaching the specified target (by a stated date).”
See you around!
/Claudio
http://www.agilesensei.com
http://www.a3thinker.com
A3 & Kaizen: Here’s How
Good stuff, thanks Claudio!
Once we choose a solution, I focus on the “experiment” part of it: timeboxed and unambiguous binary pass/fail criteria. This tends to help the problem of some people wanting to give up too soon and others not wanting to give up even when we generally agree that we didn’t get the result we want.
Lovely summary. Thanks.
Hi Henrik, your post is great! I’ve translated it into french :
Démarche légère de résolution de problèmes
Regards, Fabrice