A3 - Analyse des causes profondes

La première cellule sert à décrire le contexte du problème. Il est important que toutes les parties prenantes participent à cette phase afin que chacun ait une idée claire du problème. L'A3 étant un processus, même si le problème est évident, il est important d'en discuter et de s'assurer que tout le monde est littéralement sur la même longueur d'onde. Souvent, l'arrière-plan est un macro-problème qui affecte plusieurs parties du processus Scrum.

Une fois le contexte établi, la discussion passe à l'établissement des conditions actuelles. Il s'agira d'une liste de symptômes tels qu'une diminution Vélocité ou un mauvais moral. Il est important de s'assurer que le groupe est en mesure d'inclure certaines personnes. Métriques dans cette cellule. La perte de revenus est toujours utile car elle attire l'attention de la direction, mais n'importe quelle mesure peut faire l'affaire. L'important est qu'elles soient précises et mesurables.

Ensuite, le groupe doit décider quel sera le résultat idéal lorsque le problème sera résolu. (L'état idéal est similaire à un Test d'acceptation ou Définition de "Fait pour un Élément du carnet de commandes du produit.) Les mesures sont également utiles à cet égard. Il est important d'avoir un état cible bien défini, car cela permettra d'aligner toutes les parties prenantes sur une vision commune.

La dernière partie de la phase de planification est l'analyse des causes profondes (voir la vidéo) et c'est le cœur de l'A3. Il est relativement facile d'établir le problème et ce que sera la vie une fois le problème résolu, mais se mettre d'accord sur les causes profondes peut impliquer quelques vérités inconfortables.

Cela peut sembler très élevé, mais l'analyse des causes profondes de la qualité nécessite en fait de canaliser l'enfant de cinq ans qui sommeille en vous. Cette technique s'appelle l'analyse des causes profondes. Cinq raisons. En fait, le groupe doit commencer par le problème le plus évident et se demander pourquoi. Voici un exemple :

Les sprints échouent.
"Pourquoi ?
R : Les gens pensent que l'équipe est paresseuse.
"Pourquoi ?
R : Parce que le moral est bas.
"Pourquoi ?
R : L'équipe reçoit des messages contradictoires de la part du Product Owner.
"Pourquoi ?
A: The Product Owner is getting conflicting orders from two managers.
"Pourquoi ?
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 it has discovered the root causes, they should then put in again as much time as they’ve just spent. It is important to be exhaustive. (There are other root cause analysis techniques. A variety can be found ici.)

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.

Finding a root cause is a bit of an art.  Here are a few characteristics to help guide your process: first, a root cause will resonate with stakeholders. Second, root causes also tend to be actionable, meaning that the group will have an idea how to approach the specific challenge. And, third it will have a certain amount of specificity. 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 root causes have been identified, counter-measures can start to be developed. In the upper-right cell the group should outline at least one countermeasure for each root cause.

In Systems Theory, if multiple solutions are implemented at once, it is impossible to trace the effect of each. Therefore, it is important to implement only one solution at a time.  The A3 is a living document so the group should continually note the results of each solution implemented and update the A3 as conditions change.

It is 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 test that hypothesis. Often stakeholders go through the entire A3 process, implement a countermeasure and then assume that the countermeasure has worked.

It is important to confirm that the countermeasure has the ideal state identified in step one. In order to know if the countermeasure worked, it is important to have objective criteria to judge it against. That is why having metrics in the current and target conditions makes for a better A3. It may be that multiple countermeasures are necessary to achieve the ideal state.

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.

A3 Problem Solving Tool: Jakobson, Lean as Scrum Troubleshooter