Wann eine Root Cause Analysis sinnvoll ist
Eines Morgens hatte ich einen platten Reifen an meinem Auto. Zum Glück konnte ich das Rad schnell wechseln. Allerdings übertrage ich auch gerne Dinge, die ich bei der Arbeit gelernt habe, in meinen Alltag. Und so beschloss ich, eine Root Cause Analysis – also Ursachenanalyse – durchzuführen. Ich erhoffte mir davon, platte Reifen in Zukunft vermeiden zu können. Schließlich hätte ich die Zeit für das Wechseln des Reifens auch besser nutzen können.
Die „Five Whys“-Methode der Root Cause Analysis
Die “Five Whys”-Methode ist gut für diese Art der Ursachenanalyse geeignet. Man fragt einfach fünf Mal in Folge “Warum?” – meine Kinder konnten das im Alter von etwa vier Jahren besonders gut! Die Suche nach der Ursache begann also:
Warum hatte ich einen platten Reifen?
-Weil ein Nagel in dem Reifen steckte.
Warum steckte ein Nagel im Reifen?
-Weil ich offensichtlich einen Tag zuvor darüber gefahren war.
Warum war ich am Tag zuvor über den Nagel gefahren?
-Weil der Parkplatz meines Fitnessstudios (der einzige Ort, zu dem ich an dem Tag gefahren war) neu befestigt wurde.
Warum wurde der Parkplatz neu befestigt?
-Wegen der vielen Schlaglöcher.
Warum gab es Schlaglöcher auf dem Parkplatz?
-Wegen des Regens.
Die Ursache für meinen platten Reifen war also der Regen. Also darf es nicht mehr regnen.
Leider steht das nicht in meiner Macht. Normalerweise hätte ich so etwas an meinen Scrum Master weiterleiten können, aber sogar ein Scrum Master kann das Wetter nicht verändern.
Fazit der Root Cause Analyse
Was ich damit sagen will? Manchmal lohnt sich eine Root Cause Analysis einfach nicht. Wie jede andere Methode oder Technik, ist auch sie nicht immer sinnvoll. Viele Dinge bei der Softwareentwicklung sind vollkommen neu, d. h. sie werden zum ersten Mal gemacht (zumindest von der Person oder dem Team). Am sinnvollsten ist die Ursachenanalyse bei wiederkehrenden Situationen – z. B. in der Produktion. Weniger nützlich ist sie bei neuartigen und komplexen Dingen, wie sie bei der Softwareentwicklung vorkommen (bzw. der Produktentwicklung im Allgemeinen).
Ich sage nicht, dass Sie komplett auf die Root Cause Analysis und die Five Whys verzichten sollten. Denken Sie nur daran, dass es keine Methode gibt, die immer angewendet werden kann.
Dieser Text stammt aus dem Blog von Mike Cohn und von uns ins Deutsche übersetzt.
Werde Certified Scrum Master!
Für Scrum Master bieten wir folgende Trainings und kostenlosen Fortbildungsmöglichkeiten: