In every class, I teach the A3 approach to kaizen.
Kaizen is usually translated into English as 'continuous improvement.' In Scrum that means 'removing impediments.'
The first thing to note is that it is an approach. It is a method, with certain values and principles, and the fundamentals of the approach are more important than the detailed practices per SE. But, to make an approach into action, you must have practices.
The A3 approach gets its name from that size of paper (for North American readers, roughly 11 x 17 inches).
The A3 approach wants to fit 'everything' on one sheet of paper. And make it as concise and as visual, and obvious as possible. The concept is "if you need more paper, you don't really understand it well enough yet."
Then I must mention team-based interactive 'thinking together' at all the right levels. So, in context, the Scrum Team is trying to get the manager or managers on board with fixing an impediment. Usually that means the manager must approve ...
(a) money
(b) people
(c) allowing the change to happen (give permission), or
(d) some combination of the 3 above.
The A3 approach supports multiple formats (eg, different section titles) depending on the situation and the need.
Maybe the next thing to say: The A3 approach is tied with the classic PDCA cycle. Plan - Do - Check - Act.
The context I am talking about, we want to use an A3 document to get the 'planning and approval' done. First.
After the approval, then Do - Check. After that, 'act' in the sense or reflect and learn and assess whether it solved the problem. Or assess, after the fact, "okay, we fixed x amount, but should we fix this problem even more?" (I am imagining that was only partially mitigated a rather large problem or impediment.)
So, use an A3 document to summarize to managers (or potentially other stakeholders) what we plan to do. The Scrum Team learns to speak manager-speak. (smile)
The A3 sections I recommend (in addressing impediments) are: Problem, Solution, Benefits, Costs, Action Items, Measures. They are discussed below.
First, I must say: Use common sense. I make some suggestions below, but you must use common sense in applying those suggestions to your situation. If you are having questions, be aware that the community has almost surely dealt with a similar situation, and may already have a better suggestion for your specific case. Again, common sense is very uncommon.
<h4>Problem</h4>
Give a problem statement. Sometimes longer, sometimes fairly short.
Perhaps justify the problem. And explain it, often visually.
Two related questions often from the manager:
* why is this problem important enough for me to address?
* is this our most important problem now? (or high on the list)
When you present, be ready for those. (That does not mean you have to address them visibly in the A3 'report'...just be ready.)
To address the important question, often you are tempted to mention ALL the benefits here (eg, to discuss them verbally as you are making the presentation). Do not. At this point, the manager wants just one key number that tells him 'I am not wasting my time in discussing this.'
The second, relative importance, may be easier or harder to address. I would have to know more about your situation.
Often start with a symptom, and ask the classic 5 Whys to get to the root cause of the problem.
Some problems (and even some root causes) are quite obvious. So, this can be short. Or it can be a long section 'selling the problem.'
Many managers know from experience: often we have a solution looking for a problem. So, they know that identifying the problem well is often half the issue. The Lean community and lots of others give you plenty of tools to identify and assess the problem.
The manager may well follow-up with....'why do I believe you have identified the correct root cause?' Or similar questions. You may need to have done 'root cause analysis' or the 5 Whys or something similar.
<h4>Solution</h4>
Here you describe the solution you are proposing. Fairly succinctly. Perhaps visually.
You might talk about why you chose Solution X over Solution Y.
Often the question is: why do I believe this solution will really fix the problem (root cause) identified?
As suggested earlier, people have two problems in this section of the A3:
(a) the connection between the problem and the solution is just weak. Period. (Human nature I think is the culprit.)
(b) it is hard to quickly and simply <span style="text-decoration: underline;">show</span> the connection between the problem and the solution.
If you only have a partial solution (very common), say so. And explain, briefly, why you think this solution should be implemented before other possible solutions to the 'bigger problem.'
Again, make the solution as visual as possible. KISS (Keep It Stupid Simple) for the managers.
<h4>Benefits</h4>
Address all the benefits of the solution. Both tangible and intangible.
Often it helps to express these as money estimates. Expect the managers to question your estimates. Estimates of the future are never perfect, so expect them to revise your estimates.
Try to express your estimates as improvements in velocity, such that we get extra BV delivered in the same time period (say, year). Usually BV is some multiple of the cost of the Team (say, 3X). So, the benefits are larger if you see them that way. If you look at the benefits as only cost reduction, then the benefits are much less.
<h4>Costs</h4>
These are both the tangible and intangible costs. As broadly defined.
Consider all the costs for 'everyone.' There might be some debate about what 'everyone' and 'all' includes.
It is classic to have two types of cost: (a) one-time costs, often called 'initial costs' and (b) on-going costs (costs over some future time period).
Again, a manager typically wants all of these expressed 'apples-to-apples' with the benefits. Dollars to dollars makes it clear and simple to the manager (although seldom simple for you).
Again, make estimates of the future, which are always 'rough and ready.' Expect the managers to question them, and perhaps even revise them.
And the benefits need to be a high multiple of the costs (I recommend 6x, but this varies by the situation, etc).
You may not write this down, but at least consider the personal cost to the manager. There are many types of personal cost, but one might be political risk, or who he has to explain this to, or 'will I get fired if this goes south?' Be ready to address these in the discussion.
When discussing costs, the managers will often ask questions like:
* who has to be involved
* how much time is involved
* which other efforts must be delayed if we do this (aka opportunity cost)
In this section we also want to address risk. Reduction of risk may be addressed in Benefits, but any concerns about increased risk (for any important person) should be considered here.
ROI Ratio: Make very clear and visible the ratio between benefits and costs. That ratio needs to pass a 'hurdle rate' to be approved. I suggested 6X above. Not every firm uses the term 'hurdle rate,' but almost all firms have the concept. The benefits must be at least X times higher than the costs.
Why? Almost always there are plenty of good things to do. The manager needs the ROI to be high enough to justify executing your proposal versus other (not quite as good) proposals. We can't do all the 'good' proposals.
<h4>Action Items</h4>
This section can be phrased other ways. 'Next Steps' is a common alternative title. And it can have different purposes.
But usually the manager wants to know: "If I approve this, what will you do next?"
Maybe the manager wants you to check it out with X or Y or Z person or group. Maybe he wants to know when it will be done. Maybe he just wants to know that you have 'a plan that has been thought through, which suggests a high likelihood of successful implementation.' In that case, you might summarize the key steps in 'the plan.'
Some people think this section requires a very detailed project plan. Almost always: No! Almost always that is too much information for the manager. Maybe she would want to know that you had planned this out at some moderate level of detail, though. (Not to see the detail, just to know that your team has done it.)
Often you are addressing a semi-latent concern, such as: "The last time we did something like this, X (a bad thing) happened. How do I know X won't happen again?" You might address that concern in this section.
<h4>Measures</h4>
This is a very important section, both in practice and also concept. Often, even for managers, this is <span style="text-decoration: underline;">new</span> in concept.
In this section you propose how you will measure, after the fact, that the implemented solution turned out to have the success expected. In this way, after implementation we will close the P-D-C-A loop.
This 'learning after the fact' is vital. In this way you become better and better at solving problems, or as we call it in Scrum: fixing impediments.
In the context of getting the manager to say yes, it has two benefits. One, the manager is impressed that you thought the measures through. And guesses that if we actually measure X and Y and Z (however many things you propose measuring), that you and your team will surely do a lot better job in executing, since you will be measured later. And if execution is better, then success is more likely.
Two, the manager can also see that if the measures start soon, and if the measures show this proposal going 'south', then the manager can mitigate his risk by stopping the implementation quickly. Before his boss finds out that 'it did not work out well.'
***
I spent most of the time discussing the A3 document, because that is essential to implementing a basic A3 approach.
One of the key ideas behind A3 is: "Things should be as simple as possible, and not simpler." (Einstein) Since we are agile people, maybe the Ward Cunningham version is better: "Try the simplest thing that could possibly work, and then test." (Ward complains that people often forget the '...that could possibly work' phrase.)
In other words, do not make the A3 document more complex than it needs to be. But do not make it too simple, either.
Related to that, the A3 is a focus for collaboration in solving problems. The purpose is to work together and become better. The purposes are not (to pick some bad examples): fight endlessly, CYA, grandstanding, to nit-pick, analysis paralysis, hide the truth (by saying too little), or, hide the truth (by saying too much).
Enough for today.
For more background on the A3 approach, there are many many resources on the internet. Here is <a href="http://asq.org/conferences/six-sigma/2009/pdf/proceedings/c6.pdf">one.</a> A good slide deck. If you get into it, you may notice that the A3 approach is used in many, very diverse situations. So, the 'culture' around it is rich and complex. But the basics are very simple. I recommend KISS at first.
Enjoy!
PS. Thanks to Jeff Sutherland and Mary Poppendieck, who got me 'into the A3' many years ago.
