Quand une Root Cause Analysis est pertinente
Un matin, j'ai eu un pneu crevé sur ma voiture. Heureusement, j'ai pu changer la roue rapidement. Cependant, j'aime aussi transférer les choses que j'ai apprises au travail dans ma vie quotidienne. J'ai donc décidé de réaliser une Root Cause Analysis – c'est-à-dire une analyse des causes profondes. J'espérais pouvoir éviter les pneus crevés à l'avenir. Après tout, j'aurais pu mieux utiliser le temps passé à changer le pneu.
La méthode des « Five Whys » de la Root Cause Analysis
La méthode des "Five Whys" est bien adaptée à ce type d'analyse des causes. On pose simplement cinq fois de suite la question "Pourquoi ?" – mes enfants savaient particulièrement bien le faire vers l'âge de quatre ans ! La recherche de la cause a donc commencé :
Pourquoi avais-je un pneu crevé ?
-Parce qu'un clou était planté dans le pneu.
Pourquoi y avait-il un clou dans le pneu ?
-Parce que j'avais visiblement roulé dessus la veille.
Pourquoi avais-je roulé sur le clou la veille ?
-Parce que le parking de ma salle de sport (le seul endroit où j'étais allé ce jour-là) était en cours de réfection.
Pourquoi le parking était-il en cours de réfection ?
-À cause des nombreux nids-de-poule.
Pourquoi y avait-il des nids-de-poule sur le parking ?
-À cause de la pluie.
La cause de mon pneu crevé était donc la pluie. Donc il ne doit plus pleuvoir.
Malheureusement, ce n'est pas en mon pouvoir. Normalement, j'aurais pu transmettre ce genre de chose à mon Scrum Master, mais même un Scrum Master ne peut pas changer la météo.
Conclusion de la Root Cause Analysis
Qu'est-ce que je veux dire par là ? Parfois, une Root Cause Analysis n'en vaut tout simplement pas la peine. Comme toute autre méthode ou technique, elle n'est pas toujours pertinente. Beaucoup de choses dans le développement logiciel sont complètement nouvelles, c'est-à-dire qu'elles sont faites pour la première fois (du moins par la personne ou l'équipe). L'analyse des causes est plus utile dans les situations récurrentes – par exemple en production. Elle est moins utile pour les choses nouvelles et complexes, comme celles qui surviennent dans le développement logiciel (ou dans le développement de produits en général).
Je ne dis pas que tu devrais complètement renoncer à la Root Cause Analysis et aux Five Whys. Garde simplement à l'esprit qu'il n'existe pas de méthode qui puisse toujours être appliquée.
Ce texte provient du blog de Mike Cohn et a été traduit par nos soins en français.
Deviens Certified Scrum Master !
Pour les Scrum Master, nous proposons les formations et opportunités de perfectionnement gratuites suivantes :
