Wanneer een Root Cause Analysis zinvol is

Foto van Sohrab Salimi
Sohrab Salimi
2 min. Leestijd
Deze inhoud is vertaald met AI. Bekijk origineel

Op een ochtend had ik een lekke band aan mijn auto. Gelukkig kon ik het wiel snel verwisselen. Maar ik pas ook graag dingen die ik op het werk heb geleerd toe in mijn dagelijks leven. En dus besloot ik een Root Cause Analysis – oftewel een oorzaakanalyse – uit te voeren. Ik hoopte daarmee lekke banden in de toekomst te kunnen voorkomen. Tenslotte had ik de tijd die ik aan het verwisselen van de band had besteed ook beter kunnen gebruiken.

De "Five Whys"-methode van Root Cause Analysis

De "Five Whys"-methode is goed geschikt voor dit soort oorzaakanalyse. Je stelt simpelweg vijf keer achter elkaar de vraag "Waarom?" – mijn kinderen konden dat op vierjarige leeftijd bijzonder goed! De zoektocht naar de oorzaak begon dus:

Waarom had ik een lekke band?
-Omdat er een spijker in de band zat.

Waarom zat er een spijker in de band?
-Omdat ik er kennelijk een dag eerder overheen was gereden.

Waarom was ik de dag ervoor over die spijker gereden?
-Omdat de parkeerplaats van mijn sportschool (de enige plek waar ik die dag naartoe was gereden) opnieuw werd bestraat.

Waarom werd de parkeerplaats opnieuw bestraat?
-Vanwege de vele kuilen.

Waarom waren er kuilen op de parkeerplaats?
-Vanwege de regen.

De oorzaak van mijn lekke band was dus de regen. Het mag dus niet meer regenen.

Helaas heb ik daar geen invloed op. Normaal gesproken had ik zoiets kunnen doorverwijzen naar mijn Scrum Master, maar zelfs een Scrum Master kan het weer niet veranderen.

Conclusie van de Root Cause Analyse

Wat ik hiermee wil zeggen? Soms is een Root Cause Analysis gewoon niet de moeite waard. Net als elke andere methode of techniek is ook deze niet altijd zinvol. Veel dingen in softwareontwikkeling zijn volledig nieuw, d.w.z. ze worden voor het eerst gedaan (tenminste door de betreffende persoon of het team). Een oorzaakanalyse is het meest zinvol bij terugkerende situaties – bijv. in de productie. Minder nuttig is ze bij nieuwe en complexe zaken, zoals die voorkomen bij softwareontwikkeling (of bij productontwikkeling in het algemeen).

Ik zeg niet dat je de Root Cause Analysis en de Five Whys helemaal achterwege moet laten. Houd er alleen rekening mee dat er geen methode bestaat die altijd toepasbaar is.

Deze tekst is afkomstig uit de blog van Mike Cohn en door ons vertaald naar het Nederlands.

Word Certified Scrum Master!

Voor Scrum Masters bieden we de volgende trainingen en gratis bijscholingsmogelijkheden:

Praat met onze assistent Praat met onze assistent