Next week Scrum Inc. is broadcasting its monthly Webinar on some of the more costly pitfalls Teams wander into when implementing Scrum. In preparing slides for the presentation, Scrum Inc.’s Chief Product Owner Alex Brown is having some of the staff work through the more frequent problems using the lens of the A3 process. It was a great exercise and a reminder of how useful root cause analysis can be when trying to overcome a stubborn impediment.
For those of you unfamiliar with the A3 process, it is a tool for identifying the root causes of challenging problems and achieving a consensus on how to remedy them. The process was pioneered by Toyota to document problems with their production process. Anyone at Toyota can initiate the process and they do it for almost all problems they encounter. To capture their analysis, they use the largest sheet of paper that fit into a copy machine, the A3 or Tabloid (two 8.5x11 sheets side-by-side.)
Above is an example of an A3 we ran for an OpenView Venture Partners’ company. The process is based on Plan, Do Check, Act or the PDCA cycle. On the right side we broke down the problem and started to plan. The stakeholders gathered together to outline the context, current and target conditions and did some basic root cause analysis. Root cause analysis sounds like some fancy class you take at business school but it is basically about channeling your inner five-year-old.
In the above example, the Team couldn’t get testing done within the Sprint and Sprints were consistently failing. This was costing the partner company about 2 million Euro a year. We had the stakeholders ask why they thought Sprints were failing. They would come up with an answer and we would ask them again: Why? This continued until the stakeholders got a few layers deep at which point everyone thought had discovered the root cause. The engineers weren’t working well together and everyone thought it was obvious that if the Scrum Master was doing his job, the engineers would be a functioning Team.
A root cause is like a little scientific hypothesis and it needs testing. That’s why it’s important to have a number of possibilities. On the A3 form, use the right side to sketch out how each root cause can be tested. Start with the most likely root cause. Outline what it would take to achieve the target conditions the team agreed to earlier. It’s a good idea to have a few solid metrics for your target conditions so the group has an objective way to tell if the process improvement worked. (Velocity is always a good metric to use.) Implement the proposed change and see if the process change has the desired result. Often something will change but it will be unexpected. The change may help clarify the problem. Or, it may solve it. If it doesn’t, move down the list of root causes. Often Teams think they’ve solved the problem but then some other force will result in the same problem and the stakeholders will have to gather again. The A3 is a living document and as the problem changes, the A3 needs to be updated.
In the above example, all invovled thought the Scrum Master wasn’t getting the team to work together so management decided to discipline him. However, a few weeks later, the problem reared its head again. The stakeholders went back to the A3 and dug a bit deeper. It turned out that the Product Owner was so focused on adding new features the Team didn’t have time to implement the continuous integration that would allow them to test their code within the Sprint. Since the Product Owner was also the company CEO, the team didn’t feel they could push back effectively on this issue.
Using the A3, however, made this root cause transparent to everyone, including the investors who sat on the company’s board. They could push back on the CEO, and got him to comit to implementing continuous integration before any new features were allowed to enter the Backlog. This solved the problem and a few Sprints later, the Team increased their velocity by 50% and OpenView saved themselves and the company 2 million Euros. If you are intetested in a deeper look into the A3 process, you can get a complete breakdown at http://scrumlab.scruminc.com/index.html.
The June 26th Webinar will deal with a number of different impediments Teams frequently run into. Each will be introduced using an A3-like format. However, the secret to removing stubborn impediments is using the techniques imbeded in the A3 process. Your Team will see a significant improvement in Velocity if they, like the workers at Toyota, use it for almost every problem.
-- Joel Riddle
English 
French 
Spanish