(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 🙂