The first cell is used to describe the background of the problem. It is important that all stakeholders participate in this phase so everyone involved has a clear idea of what the problem is. The A3 is a process so even if the problem is obvious, it is important to discuss it and make sure everyone is literally on the same page. Often, the background is a macro problem that is felt in multiple parts of the Scrum process.
With the background established, the discussion moves on to establishing the current conditions. This will be a list of symptoms like decreased Velocity or bad morale. It is important to make sure that the group is able to include some Metrics in this cell. Loss of revenue is always helpful because it gets management’s attention but any number of metrics will do. The important part is that they are precise and measurable.
Next, the group should decide on what the conditions will be if the problem is solved. The target conditions are similar to an Acceptance Test or Definition of Done for a Product Backlog Item. Metrics are helpful here as well. The idea is to provide a somewhat objective condition in which all stakeholders could feel the problem was solved. It is important to have a well-defined target condition because it will help align all stakeholders around a common vision.
The last part of the planning phase is root cause analysis (see video) and is really the core of the A3. Establishing the problem and what life will be like after the problem is solved is relatively easy, agreeing on what the root causes are may involve some uncomfortable truths.
It sounds very high minded, but good root cause analysis actually requires channeling your inner five-year old. The technique used is called the Five Whys. Basically, the group needs to start with the most obvious problem and ask why. Here is an example:
Sprints are failing.
“Why?”
A: People think that the Team is lazy.
“Why?”
A: Because morale is low.
“Why?”
A: The Team is getting mixed messages from the Product Owner.
“Why?”
A: The Product Owner is getting conflicting orders from two managers.
“Why?”
A: The organization incentivizes competition rather than cooperation.
The point of the exercise is to get at least five layers deep into any problem. Five layers is a general rule of thumb. Root causes can be found three or seven layers deep. It is really important to invest a lot of time here. Often the stakeholders think they have arrived at a few root causes only to have to repeat the process later. Another good rule of thumb is that once the group thinks its discovered the root causes, they should then put in again as much time as they’ve just spent. It’s important to be exhaustive. (There are other root cause analysis techniques. A variety can be found here.)
There will likely be multiple root causes to a problem. In the above example, the Product Owner role has broken down, managers are probably talking to the team outside of their scope and the organization’s incentives are flawed.
A root cause is highly dependent upon the organization, the developmental process and, most importantly, the people involved so coming up with an example is difficult. However, there are a few signs. First, a root cause will probably resonate with most stakeholders. Root causes also tend to be actionable, meaning that the group will have an idea how to solve the specific challenge. And, a root cause will have a certain amount of detail. In the above example, “people think the Team is lazy” doesn’t have any granularity. Further inquiry helped pinpoint a more detailed root cause.
Once the stakeholders have agreed on the root causes, they can start to develop solutions. In the upper-right cell the group should outline
at least one countermeasure for each root cause. This can be done in a couple of ways. The group can choose to prioritize the root causes and their countermeasures and work their way down the list one at a time, or they can try to attack all the root causes at once.
Typically, it is a good idea to implement one countermeasure at a time. Given the nature of complex-adaptive systems, a change to one part of the system could ripple throughout the organization, changing the overall issue. If it turns out the countermeasure doesn’t work, or does work and doesn’t change the problem, the group can move onto the next root cause and its countermeasure. Or, it may be that solving the first root cause reveals that the problem resides in another part of the organization. The A3 is a living document so the group should continually update it as conditions change.
Countermeasures, like root causes are typically specific to the organization and can’t be proscribed based on the problem alone. If the group is unable to settle on a solution, it is probably outside of the organization’s power to solve. It could be that there is no demand for a certain product or feature. If this is the case, it may be time for leadership to realize they need a different vision.
Its critical that when working through the countermeasures the group treats each one like a small science experiment. A root cause is just a hypothesis. A countermeasure is a tool to
confirm that hypothesis. Often stakeholders go through the entire A3 process, implement a countermeasure and then assume that the countermeasure has worked. It’s important to confirm that the countermeasure had the desired effect. That is why its recommend to list some metrics in the current and target condition fields. In order to know how or if the countermeasure worked, it’s nice to have some objective criteria to judge it against. The clearer your metrics, the better your A3.
If the countermeasure worked, great, if it had an effect on the current conditions and moved the Team closer to the target condition, it may be that multiple countermeasures are necessary to achieve the target condition. If there is no effect move on to the next countermeasure for that root cause or move onto the next root cause and try its countermeasure.
A root cause is a hypothesis. A countermeasure is an experiment that tests your root cause. If the countermeasure changes the metrics in the Plan phase, the group then should either scale-up the countermeasure to solve the root cause or adapt the countermeasure to more directly address what the group has learned through the experiment.
Hard Truths
When an A3 fails it is usually because the group didn’t delve deep enough into the problem or that the problem was beyond the ability of the team to solve or recognize. Solving the root cause can be the end result of a successful A3. However, that’s not always the case. A successful A3 can show that the root cause is beyond the ability of the organization to change like in the above example where there wasn’t enough market demand for the product. A good A3 can reveal deep challenges within the organization like conflicting core values, poor leadership or a critical lack of resources. The A3 isn’t a silver bullet; rather it’s a tool to bring transparency to dysfunction. How the stakeholders handle the dysfunction is their responsibility.
Paper:
The Scrum Pattern Language of Programming codifies well known Agile practices that have been successfully implemented many times.
