In this video, we're going to discuss the popular A3 Problem Solving Framework. By the end of this lesson, you should be able to outline and explain, all the steps in this framework, as well as compare it to Deming's plan, do, check, act cycle. So, what's really funny regarding this framework, is that people are always asking, why is it called an A3? There is not much to it actually, really, A3 just refers to a European paper size, that's equivalent to an 11 by 17 inch size paper. Upon which, many people choose to outline their templates for this framework. That's all the magic there, behind the fancy sounding name. Regardless of whether you chose to use that size paper or not, there are structured steps that you go through, when you use A3 problem-solving. It's tightly linked to the Deming plan, do, check, act cycle. Steps one through four are about the plan, and I'll go into those steps in a minute. Step five, essentially maps to the do phase. Step six, is check, and step seven, is act. If you search the internet for examples and templates, you will find a bit of variation, in how each step is labeled and described. Don't worry about that so much. It's more important to make sure you go through each step, spending the majority of your time in the planning stages. Step one is really to set the background. Why is this being discussed? This should include a statement, about how this problem directly impacts business outcomes. For example, in the last lesson, I mentioned the problems the Nordstrom web team was addressing. The problem statement for the test automation included, information about how the quality issues we're creating production incidence, and impacting the customer. Step two, is understanding the current condition, and creating a problem statement. Note, that the use of current condition is also aligned with the improvement kata language. The current condition needs to be, the current reality of where things stand today. For example, quantify the production incidents being created due to the quality issues. Ideally, you would also be able to tie that to lost revenue, or another business metric. Regardless, a statement like, "every rep web release we have three high severity production issues impacting our customers." Step three, Develop the Goal, and or the Target State. This should be the outcome you are trying to achieve for the business, and how you will measure success. For example, having zero high severity incidents due to a release. Step four, is Performing Analysis. If you look at A3 guidance online, you may see this step, called root cause analysis. Now here, I'd like to make a slight adjustment. In complex systems, there are usually multiple contributing factors, and not a single root cause. In this step, as you're going through, and identifying potential root causes, there maybe multiple contributing factors. Continuing the example regarding quality, the team documented multiple [inaudible] symptoms, and contributing factors including, automation of integration testing, unit test coverage, and process related issues. For example, allowing exceptions late in the life cycle. Those are steps one through four, the Plan phase. Again, this is where you should spend most of your time. I've seen situations where people want to breeze through, and get to the Do phase, but teams that spend the majority of their time in the Plan phase, typically had the most success in reaching their targets and goals. As we move on, step five, is to brainstorm and determine some potential countermeasures, that you could introduce to experiment, and attempt to solve the problem. This should include how you intend to reach the target condition, meaning a hypothesis on how the countermeasure could help reach the goal. For example, the team felt that instituting a gate, to reduce the number of exceptions, would reduce the number of incidents by two. Think about how you will choose which countermeasures, and which ones will be implemented. Often that looks like decision criteria, such as effort versus impact. If it will take a month to implement integration test automation, and the hypothesis is that it will reduce incident count by one, versus changing the process and adding a gate is immediate, and expected to reduce the count by two, then you'd propose the process change first. Step six, is to create an implementation plan, that will enable you to check the results, and really confirm if it had an impact on the current condition. So, you're going to pick one of your countermeasures, and document the actions needed, to implement the countermeasure. A timeline for implementation, and the person or persons responsible. For example, we will create 15 additional automated test scripts within two weeks, and it's assigned to our QA manager. Then based on the results, step seven is when you're going to update what's called standard work, based on the outcome of the steps that you took. For example, if you automate it those test scripts, and it reduced your production incident count, then you will want to check those into a library, and have those become your standard automated scripts going forward. This A3 problem solving framework, can then be used as an ongoing tool, to create a culture of continuous improvement, or continuous learning. I highly encourage you to research it further, to see how you may be able to implement it in your organization.
