Root Cause Analysis in der Softwareentwicklung: Warum es keine Projekt-manager*innen- und Pilot*innenfehler gibt

Die Piloten waren schuld am Absturz. 

Bei einem Flugzeugabsturz schreiben Medien kurz nach dem Ereignis sehr oft von Pilot*innenfehlern als Ursache für ein tragisches Unglück - so auch beim Absturz der Tante Ju 52 vom 4. August 2018 bei Flims (GR) mit 20 Toten. Als anfangs 2021 der Schlussbericht der Schweizerischen Sicherheitsuntersuchungsstelle (SUST) zum Absturz publiziert wurde, staunte ich nicht schlecht über mediale Schlagzeilen wie “Pilotenfehler führten zu «Tante Ju»-Absturz von 2018.” (SRF)

Alle Ursachen und Faktoren, insbesondere die in Bezug zu den direkten Ursachen des Unfalls, deuten auf den ersten Blick eindeutig auf einen Pilotenfehler hin. Dabei stellt sich aber die so wichtige Frage, warum es überhaupt soweit kommen kann, dass eine Flugzeugbesatzung derart viele Risiken eingehen kann und dabei die sehr strikten Regeln und Rechtsgrundlagen der Luftfahrt über Jahre ignorieren konnte, ohne dass die Behörde eingriff? Liegen die Fehler womöglich im System?

Finger Pointing: Es gibt keine Pilot*innen- und Projektman- ager*innenfehler

Probleme sind sehr oft Hindernisse in Projekten, die möglichst zeitnah aus dem Weg geschaffen werden müssen, um in eine stimmige Zielsituation zu gelangen. Um effektiv ein Problem lösen zu können, muss es aber zuerst erkannt werden. Dies geht nur, wenn eine Organisation eine offene Problem- und Fehlerkultur pflegt und lebt, und dabei gewillt ist, aus entdeckten Fehlern zu lernen, um sich langfristig zu verbessern. Dabei geht es nie darum, etwaige Schuldige durch sogenanntes Finger Pointing zu bestimmen, sondern darum, die Fehler im System zu identifizieren, diese zu analysieren und gemeinsam nachhaltige Lösungen zu finden, welche die Fehler oder Probleme nicht wieder entstehen lassen. 

Bei Apps with love sind die Projektmanager*innen die Pilot*innen der Projekte. Sie planen, koordinieren, steuern und kommunizieren alle projektrelevanten Tätigkeiten und sind dabei sehr oft die direkte Ansprechperson gegenüber unseren Kund*innen. Die Projektmanager*innen tragen eine grosse Verantwortung, die Projekte in Zeit, Budget, Scope und hoher Qualität abzuliefern. Ausserdem gilt es, den Kund*innen ein gutes Erlebnis zu bieten und deren Zufriedenheit zu gewährleisten. All dies ist eine hohe Kunst und wie ich aus meiner persönlichen Erfahrung weiss sehr anspruchsvoll.

Die Idee, diesen Blogpost zu schreiben, entstand einerseits durch den publizierten Bericht der SUST und das mediale Finger Pointing, andererseits erhielten wir zur gleichen Zeit zu einer von uns entwickelten und in Betrieb stehenden Applikation mehrere Softwarefehler gemeldet: Rund einen Monat nach einem produktiven Release eines grösseren Projekts wurde zuerst einer und dann mehrere kritische Softwarefehler (sogenannte Incidents) durch die Kundin entdeckt und an uns gemeldet. Wie die einzelnen Schritte für die Analyse und die Behebung solcher Incidents aussieht, könnt ihr gerne unten oder im Detail auf der Support-Seite nachlesen.  

Durch den oft vorherrschenden Zeitdruck während der Behebung eines Softwarefehlers in einem produktiven System und dabei fehlender Zeit für das systematische Aufdecken des effektiven Problems, werden oft nur die Symptome behoben. Die eigentliche Ursache des Problems bleibt bestehen, mit der hohen Wahrscheinlichkeit, dass der gleiche oder ein ähnlicher Softwarefehler bald wieder auftritt. 

In unserem Fall passierte genau dies. Kurze Zeit nachdem wir die Software geflickt und neu ausgeliefert hatten, wurde bereits ein neuer, relativ ähnlicher Fehler an unser Support-Team gemeldet. Das Spiel begann von Neuem. 

Um die Ursache des Problems herauszufinden, entschieden wir uns, eine umfassende Root Cause Analysis durchzuführen. Dahinter stand die Absicht, die Qualität unserer Projekte, aber auch der unserer Organisation langfristig zu verbessern (kontinuierliche Verbesserung). Eine ziemlich aufwändige, komplexe und manchmal auch emotionale Sache. Maud Cottier, meine ehemalige QM-Kollegin, und ich machten uns daran, die Methodik, die wir beide aus unserer Studienzeit kennen, in einem "echten" Projekt anzuwenden.  

Was ist eine Root Cause Analysis (RCA)?

Eine Root Cause Analysis (Ursachenanalyse oder auch Fehler-Ursachen-Analyse genannt) ist ein methodischer Vorgang, um die zugrunde liegenden Probleme eines Ereignisses zu identifizieren und dient damit als retrospektive Analyse eines Vorfalls. Dabei wird untersucht, wann, wie und warum ein Problem entstand. Es wird davon ausgegangen, dass Probleme immer in einer Ursache-Wirkungs-Kette sind und das ein Problem so lange nicht gelöst werden kann, bis die Ursache an der Wurzel (englisch: Root) beseitigt wurde. 

Dabei stellen sich folgende grundsätzliche Fragen, die mit der Durchführung einer RCA beantwortet werden sollten:

• Was waren die Ursachen für das vorliegende Problem / die vorliegenden Probleme?

• In welcher Abfolge und in welcher Beziehung stehen die Ursachen zueinander?

• Warum gab es überhaupt einen Fehler?

Methoden zur Durchführung einer Root Cause Analysis

Für die Durchführung einer Root Cause Analysis kann aus verschiedenen Methoden gewählt werden. Die gängigste Methode ist dabei die 5-Why- oder 5-Warum-Frage-Methode ergänzt mit der visuellen Darstellung der Ursachen in einem Ursache-Wirkungs-Diagramm.

5-Why-Methode

Die 5-Why-Methode ist ein beliebtes Vorgehen für eine Root Cause Analysis und ein Werkzeug für die Analyse von Problemen und deren Ursachen. Es wird dabei zusammen mit Protagonist*innen ein eingegrenztes Problem mit fünf- oder mehrmaligem Nachfragen nach “Warum ist das so passiert?” untersucht. Die “Warum?”-Fragen (es können durchaus auch mehr als fünf sein, die Zahl ist symbolisch zu verstehen) sollen schliesslich zur Ursache des Problems führen.

Die 5-Why-Methode hat ihren Ursprung in der Produktionssteuerung und ist ein Instrument innerhalb der Qualitätssicherung für die Ursachenanalyse von Prozessen und Systemen, die sehr oft linear, kausal und  kompliziert sein können. Die Methode wurde erfunden von Toyoda Sakichi und ist heute in der gesamten Lean Philosophie nicht mehr wegzudenken.

Die Anwendung der 5-Why-Methode ist einfach und sehr schnell erlernbar. In einem ersten Schritt wird das Problem oder der Sachverhalt einfach formuliert. Anschliessend wird den Protagonist*innen das Problem erläutert und es wird mit der ersten “Warum?”-Frage begonnen. Die “Warum?”-Fragen werden solange wiederholt, bis die Root Cause, also der Ursprung oder die Wurzel des initialen Problems identifiziert wurde. 

Visuelle Darstellung der Ursachen mit dem Ursache-Wirkungs-Diagramm 

Mit dem Ursache-Wirkungs-Diagramm lassen sich potenzielle Ursachen für ein entstandenes Problem clustern, strukturieren und visuell darstellen. Dabei werden die Ursachen identifiziert und in Abhängigkeit gebracht. Eine der meistgenutzten Darstellungsformen von Ursachen von Qualitätsproblemen im Qualitätsmanagement ist dabei das Ishikawa-Diagramm, auch Fischgräten-Diagramm genannt, mit welchem sich die Ursachen und die zusammenhängenden Beziehungen derselbigen einfach und übersichtlich darstellen lassen. 

Den Inhalt des Fischgräten-Diagramm ergibt sich in unserem Fall durch die Analyse des Vorfalls und den Ergebnissen der 5-Why-Methode. Die Ergebnisse der Analyse, also die Ursachen, die womöglich zum Problem geführt haben könnten, werden nun den einzelnen Kategorien - Material, Methode, Management, Mitwelt, Maschine, Mensch - mit Hilfe von Pfeilen zugeordnet. So ergeben sich kleine Äste innerhalb dieser Kategorien, welche auch Fischgräten genannt werden. 

Ziele der Root Cause Analysis der aufgetretenen Incidents

Bevor wir mit der Root Cause Analysis begannen, haben wir uns nochmals gefragt, was wir mit der Durchführung der RCA genau erreichen wollen. Dazu haben wir uns erneut mit der Ausgangslage beschäftigt: Rund einen Monat nach dem produktiven Release eines grösseren Projekts wurde zuerst einer und dann mehrere kritische Softwarefehler durch die Kundin entdeckt und an uns gemeldet.

Folgende Fragen stellten wir uns und wollten wir beantworten:

1. Welche Faktoren führten dazu, dass Apps with love ein nicht funktionierendes Software Inkrement ausgeliefert hat?

2. Was kann Apps with love langfristig verbessern, damit ein solcher Vorfall verhindert werden kann?

3. Können wir das Risiko für uns als Unternehmen durch die Root Cause Analysis langfristig reduzieren?

Vorgehen und Anleitung zur Durchführung einer Root Cause Analyse

Wie gingen wir nun also bei der Durchführung der Root Cause Analyse in unserem Beispiel?

Schritt 1: Entscheid die RCA durchzuführen
Gemeinsam wurde entschieden, eine RCA durchzuführen mit dem Ziel, die Organisation kontinuierlich zu verbessern und nicht alltägliche Methoden zur Verbesserung zu etablieren. Das RCA Projektteam und der Auftrag wurde definiert.

Schritt 2: Definition des Projektauftrages der RCA
Wichtig war es, den Projektauftrag der Durchführung der RCA zu definieren, klare Ziele zu setzen, zeitlich zu terminieren, abzugrenzen von anderen gleichzeitig laufenden Projektvorhaben und die RCA möglichst unabhängig durchzuführen. Das Team und die Protagonist*innen, die Tools und Werkzeuge zur Analyse sowie die anzuwendende Methode wurde definiert.

Schritt 3: Erarbeitung der Datengrundlage und chronologische Dokumentation aller Informationen
Schritt 3 war der zeitaufwändigste Schritt, aber auch der wichtigste. Hier mussten alle Daten für die weitere Analyse dokumentiert werden.

Folgendes haben wir also gemacht: 

• Chronologische Dokumentation der gemeldeten Incidents

• Teilweise fehlende Informationen zu den Incidents mussten durch Gespräche mit einzelnen Projektmitarbeitenden aufgearbeitet und ergänzt werden: Wie wichtig kontinuierliche Dokumentation zur Nachvollziehbarkeit ist wurde uns hier einmal mehr bewusst.

• Analyse der ausgeführten und entwickelten Aufgaben und Abgleich mit den Anforderungen an das Produkt

• Analyse von Diskussionen und Kommentaren in unserem Kommunikationstool Slack

• Reverse Engineering und Analyse von bereits behobenen Softwarefehlern sowie deren Nachdokumentation

• Analyse und chronologische Dokumentation der Software-Releases und Deployments auf die verschiedenen Entwicklungsumgebungen

• Analyse der durchgeführten Projekt-Retrospektiven und des Projekt-Debriefings

Die Aufarbeitung half uns, die Probleme ein- und abzugrenzen.

Schritt 4: Durchführung von Workshops mit einzelnen Protagonist*innen des Projekts und gemeinsame Analyse der Ursachen mittels 5-Why-Methode
In Schritt 3 konnten wir durch die ausführliche aufgearbeitete Datengrundlage die Probleme einordnen. Dies war die Grundlage für die Workshops mit den einzelnen Protagonist*innen. Mit der 5-Why-Methode werden die eingegrenzten Probleme einzeln durchgegangen und die Ursachen aus Perspektive der Protagonisten auf Metaebene beschrieben und dokumentiert. Wichtig ist, dass die 5-Why-Methode nicht sagt, dass nach dem fünften “Warum?” die Ursache klar ist. Es kann durchaus sein, dass es 7 oder mehr “Warum?”-Fragen braucht.

Schritt 5: Clustering aller Ursachen mit Hilfe des Fischgräten-Diagramms
Nach den Workshops mit den Protagonist*innen konnten die Ursachen auf der Metaebene geclustert und visuell mit Hilfe des Fischgräten-Diagramms dargestellt werden, um einen ganzheitlichen Überblick zu erhalten, welche Ursachen zu den Ereignissen beigetragen haben.

Schritt 6: Ableitung von Empfehlungen und möglichen Massnahmen zur Verbesserung
Im nächsten Schritt konnte aus der Dokumentation der 5-Why Workshops, der erkannten Ursachen und der visuellen Darstellung derselben die ersten Empfehlungen und Massnahmen formuliert werden. Spannend war hier zu sehen, dass während der Durchführung einer RCA bereits die ersten Massnahmen durch das Projektteam initiiert und angegangen wurden, vor dem eigentlichen Abschluss der RCA. Etwas, das öfters bei der Durchführung von RCAs vorzukommen scheint. 

Schritt 7: Vorstellung der Massnahmen dem Projektteam und anschliessend den einzelnen Fachbereichen
Ein wichtiger Bestandteil der RCA ist die Vorstellung der Empfehlungen und der möglichen Massnahmen an die einzelnen Fachbereiche und Teams sowie deren Übergabe für die Weiterverarbeitung durch diese. 

Schritt 8: Überprüfung Umsetzung der Empfehlungen und Massnahmen
Wichtig ist es, die Umsetzung der Empfehlungen und Massnahmen in regelmässigen Abständen zu überprüfen, den Status zu erfragen und Lösungen zur Verbesserung kontinuierlich zu dokumentieren. Aus den Empfehlungen einer RCA raus werden sehr oft Prozesse verbessert und angepasst.

Fazit: Kontinuierliche Verbesserungen von Softwareentwicklungs- Prozessen mit Root Cause Analysis

Um die Qualität innerhalb einer Organisation zu verbessern, müssen die echten Ursachen eines Problems erkannt, analysiert und angegangen werden. Dabei werden Techniken wie die 5-Why Methode wie auch das Fischgrätendiagramm eingesetzt um nachhaltig Fehler zu eliminieren und Prozesse sowie Prozessabläufe zu optimieren.

Der Entscheid eine Root Cause Analyse nach einem Vorfall durchzuführen muss gut durchdacht sein, nicht immer lohnt sich der Aufwand für eine solche, insbesondere in der Softwareentwicklung wo immer wieder viele Dinge ganz neu sind. Der Entscheid eine RCA durchzuführen war in unserem Fall schnell klar, da nach der ersten Behebung der gemeldeten Softwarefehler weitere Softwarefehler gemeldet wurden. 

Mit der Durchführung der RCA konnten wir nicht nur eine neue Methodik innerhalb der Firma etablieren, sondern haben dabei auch einige Ursachen, die zu den Softwarefehlern geführt haben gefunden. Diese Ursachen führen nun in einem weiteren Schritt dazu, dass einige interne Prozesse, zugehörige Abläufe und Prozessdokumentationen überdacht und angepasst werden. Die Arbeit ist also nach der RCA noch nicht getan 😉.

Quellen

• SUST 1

• SUST 2

• SUST 3

• SUST 4

• Wikipedia

• NZZ

• SRF

• ZHAW