In Agile-Teams ist die Root Cause Analysis wichtig, um Autonomie zu wahren, Probleme im Team eigenständig zu diagnostizieren und wirksame Lösungen zu entwickeln. Mehr erfahren.
Giles Knights
Eines Tages entdeckt ihr einen Riss im alten Mauerwerk, das ansonsten solide und unbeweglich wirkt. Zuvor war er nicht da, aber so schlimm sieht er nicht aus. Die Mauer ist ansonsten in einem hervorragenden Zustand – also beschließt ihr, den Riss auszubessern.
Ihr bohrt und meißelt den alten Mörtel heraus und ersetzt ihn durch neuen. Wie neu.
Ein paar Wochen später ist der Riss wieder da. Diesmal ist er sogar noch größer. Trotzdem beschließt ihr, ihn erneut auszubessern, weil ihr davon ausgeht, dass eure mangelnden Fähigkeiten als Maurer schuld daran waren.
Wieder ist alles in Ordnung.
Bis der Riss einige Wochen später praktisch zu einem klaffenden Abgrund geworden ist. Die Mauer neigt sich und wölbt sich eindeutig. Sie steht kurz vor dem Einsturz.
Dann erkennt ihr den Grund: Auf der anderen Seite der Mauer wächst ein Baum.
Die Wurzeln haben sich langsam unter der Mauer ausgebreitet, die Erde verschoben, das Fundament beeinträchtigt und so die Risse und Belastungen verursacht – und um die Mauer zu retten, müsst ihr euch um den Baum kümmern.
Das ist – in diesem Fall ganz wörtlich – die Ursache des Problems.
Dies ist nur ein sehr einfaches Beispiel, um das Konzept zu veranschaulichen – in komplexen Systemen kann es deutlich schwieriger sein, etwa im menschlichen Körper. Die Ursache eines Problems zu finden, ist genau das, was Ärzte tun, wenn ein Patient krank ist – nur in einem anderen Maßstab, was Komplexität und Bedeutung angeht.
Die Symptome einer Krankheit mit Medikamenten zu behandeln, ist die Aufgabe eines Apothekers.
Doch genau wie das ständige Ausbessern und der schließlich eintretende Einsturz unserer sprichwörtlichen Gartenmauer sind die Medikamente des Apothekers nur Mörtel, der das Mauerwerk flickt.
Irgendwann brauchen wir die Untersuchung eines Arztes, um die Ursache zu finden – das zugrunde liegende Problem, das die Symptome verursacht –, damit wir das Problem ein für alle Mal lösen können. Doch in einem so komplexen System wie dem menschlichen Körper kann ein Problem mehrere Ursachen haben.
Bei der Root Cause Analysis (RCA) im Agile-Kontext müssen wir eher wie der Arzt und weniger wie der Apotheker handeln: Medikamente verschreiben, die uns zunächst helfen, während wir nach der Ursache suchen – bevor unser Patient wie die Gartenmauer endet.
Was ist Agile Root Cause Analysis (RCA)?
Root Cause Analysis (RCA) ist der Prozess, die tatsächliche Ursache eines Problems zu ermitteln, um wirksame, dauerhafte Lösungen zu finden.
Für Agile Teams ist dies ein wichtiger Aspekt, um Autonomie und Verantwortlichkeit zu wahren: Sie können Probleme innerhalb des Teams selbst diagnostizieren und wirksame Lösungen entwickeln. So wird verhindert, dass dieselben oder ähnliche Probleme künftig erneut auftreten.
Sie ist auch wichtig, um Erfolge zu analysieren und zu wiederholen. Herauszufinden, warum etwas gut funktioniert hat, kann so einfach sein wie rückwärts zu arbeiten. Häufig wird dabei jedoch die Ursache des Erfolgs übersehen, weil wir uns in jeder Phase zu stark auf das Ergebnis konzentrieren.
Warum solltet ihr eine Root Cause Analysis durchführen?
Wenn euer Team immer wieder auf dieselben Probleme stößt, liegt das wahrscheinlich daran, dass Probleme nur oberflächlich behoben werden, statt ihre Ursache anzugehen.
Agile Root Cause Analysis kann sie zur Ursache des Problems führen.
Es ist deutlich effektiver, zugrunde liegende Probleme zu verhindern und zu lösen, als ständig nur Brände zu löschen.
Genauso ist es besser, etwas mehr Zeit in die Lösung des richtigen Problems zu investieren, statt allein der Geschwindigkeit hinterherzujagen – und die falschen Probleme schnell zu lösen.
Schauen wir uns vor diesem Hintergrund die grundlegenden Ziele jeder RCA an:
Die Ursache eines Problems oder Ereignisses zu ermitteln
Vollständig zu verstehen, wie sich die Ursache beheben, abmildern oder für zukünftiges Lernen nutzen lässt
Wendet das Gelernte an, um künftige Probleme zu verhindern und Erfolge zu wiederholen
Punkt 3 ist wichtig. Stellt euch vor, wir hätten in unserem Beispiel mit der Gartenmauer herausgefunden, dass die Baumwurzeln die eigentliche Ursache des Problems waren, aber die Mauer neu gebaut, ohne uns um den Baum zu kümmern.
Wir würden uns produktiv fühlen – schließlich haben wir eine komplett neue Mauer gebaut. Wir haben gute, harte Arbeit geleistet.
Doch auch die neue Mauer wird den wachsenden Wurzeln wieder zum Opfer fallen. Und die, die wir danach bauen. Und die danach …
Wenn wir die Grundursache nicht angehen, werden wir wahrscheinlich immer wieder exakt dasselbe Problem haben. Um künftige Probleme zu verhindern, können wir das Gelernte nutzen, um nach anderen Bäumen in der Nähe zu suchen, oder eine Roadmap erstellen, um ähnliche Probleme künftig zu lösen.
RCA klingt großartig, oder? Wie geht ihr dabei vor?
Nun ja – theoretisch ist es einfach, in der Praxis komplex …
So führt ihr RCA in Agile-Teams durch
Legt zunächst die folgenden Leitprinzipien fest:
Versucht, die Grundursache zu beheben, nicht nur die Symptome – lindert die Symptome aber kurzfristig
Es kann – und oft gibt es – mehr als eine Grundursache
Schuldzuweisungen bringen nichts. Konzentriert euch auf das WIE und WARUM, nicht darauf, WER WAS getan hat
Sucht nach verlässlichen Belegen für Ursache und Wirkung
Sammelt genügend Informationen, um eine Lösung zu entwickeln
Überlegt, wie sich dieselbe Grundursache künftig verhindern lässt
Jetzt habt ihr einen Leitstern, an dem ihr euch orientieren könnt, und könnt nach Methoden für eure Analyse suchen.
Der 5-Why-Ansatz
„Die 5 Whys“ sind eine klassische RCA-Methode.
Stellt zu jeder Antwort auf eine Frage eine weiterführende, tiefere Frage.
Vielleicht reichen drei Fragen wie „Aber warum?“, um zur Ursache zu gelangen, oder ihr braucht Dutzende davon.
Eines der bekanntesten und langlebigsten Beispiele stammt aus dem berüchtigten Toyota Production System – dem Großvater der Agile-Methoden. Das Problem? Mein Auto startet nicht. Wenden wir den 5-Why-Ansatz an:
Warum? – Die Batterie ist leer
Warum? – Die Lichtmaschine funktioniert nicht
Warum? – Der Keilriemen der Lichtmaschine ist gerissen
Warum? – Er hatte seine vorgesehene Lebensdauer deutlich überschritten und wurde nicht ersetzt
Warum? – Das Auto wurde nicht regelmäßig gewartet
BINGO. Die fehlende Wartung ist die Ursache – nicht die leere Batterie oder der gerissene Keilriemen der Lichtmaschine.
Wir haben gelernt, dass wir dies – oder ähnliche Probleme durch Verschleiß – vermeiden können, wenn wir uns an einen Wartungsplan halten. So stehen wir nicht wieder ohne Auto da.
Die 5-Why-Methode ist nicht perfekt – aber sie hilft uns, keine Annahmen zu treffen. Indem wir immer tiefergehende Fragen stellen, werden die Antworten klarer. Idealerweise kennen wir die Ursache, sobald wir das letzte Warum beantwortet haben. In komplexen Systemen kann das jedoch schwierig werden.
Und denkt daran: Es kann durchaus mehr als eine Ursache geben.
Es gibt zwar weitere Methoden für eine RCA, aber diese ist ein guter Einstieg.
Und wenn ihr tiefer einsteigen müsst, ist es vielleicht an der Zeit, außerhalb eurer Organisation nach Unterstützung zu suchen.
Agile-Experten einstellen
Eficode Contractor Hub ist darauf spezialisiert, die besten Agile Contractors weltweit zu finden – geprüft, auf ihre Fähigkeiten getestet und bereit, die Art und Weise zu verändern, wie euer Unternehmen Probleme löst.
- Contractor Hub
Subscribe to our newsletter
Related blogs