5-Whys-Ursachenanalyse

Fragen Sie nach dem Warum, bis Sie eine behebbare Ursache finden.

Probieren Sie diese Retrospektive live aus

Problembeschreibung

Was genau ist passiert, wo und wann?

Release 4.2 wurde zwei Tage zu spät ausgeliefert, das dritte verspätete Release in diesem Quartal.
Nach dem Deployment am Dienstag stiegen die Checkout-Fehler auf 3 % der Bestellungen.
Letzte Woche warteten vierzig Support-Tickets mehr als 48 Stunden auf eine erste Antwort.
Was wir wissen

Welche Fakten und Daten beschreiben das Problem?

Der Build war am Freitag grün, und der Release-Branch wurde am Montag erstellt.
Die Fehlerlogs zeigen ab 14:05 Uhr Timeouts vom Zahlungsanbieter.
Zwei unserer vier Reviewer waren in dieser Woche im Urlaub.
Warum ist es passiert?

Was hat das Problem direkt verursacht?

Die finalen Tests begannen spät, weil das letzte Feature am Release-Tag gemergt wurde.
Die neue Retry-Einstellung hat die API des Zahlungsanbieters mit Anfragen überflutet.
Montagmorgens war niemand im Support-Dienstplan eingeteilt.

Was ist die 5-Why-Methode?

Die 5 Whys (auch 5-Why-Methode) sind eine Technik der Ursachenanalyse. Sie formulieren ein Problem, fragen, warum es passiert ist, und fragen dann bei jeder Antwort erneut nach dem Warum, bis Sie eine Ursache erreichen, die das Team beheben kann. Die Methode stammt aus dem Toyota-Produktionssystem. Taiichi Ohnos eigenes 5-Why-Beispiel verfolgt eine stillstehende Maschine über eine durchgebrannte Sicherung, ein trockenes Lager und eine verschlissene Pumpenwelle bis zur Grundursache: Die Pumpe hatte kein Sieb. Mit dieser 5-Why-Vorlage durchlaufen Sie die gesamte Kette in einer einzigen TeamRetro-Retrospektive. Schreiben Sie die Problembeschreibung in die erste Spalte und die bereits bekannten Fakten in die zweite. Danach beantworten alle in der dritten Spalte das erste Warum: „Warum ist es passiert?“ Das Team gruppiert die Antworten und stimmt über die wahrscheinlichste Ursache ab. In der Diskussionsphase öffnen Sie diese Karte und stellen die nächsten vier Warum-Fragen als Kommentar-Thread, wobei jede Antwort auf die vorherige erwidert. Die letzte Antwort ist Ihre Grundursache. Diese kopieren Sie in eine Maßnahme mit verantwortlicher Person und Fälligkeitsdatum. Die 5 Whys funktionieren am besten, wenn ein Problem einer Hauptlinie von Ursache und Wirkung folgt: ein verspätetes Release, ein wiederkehrender Vorfall, ein Fehler, der durch die Tests gerutscht ist. Wer eine Kette bis zum Ende verfolgt, gibt sich nicht mit der ersten Antwort zufrieden, und die Diskussion verlagert sich von der Frage, wer einen Fehler gemacht hat, zu der Frage, was im Prozess ihn zugelassen hat. Hat ein Problem viele beitragende Ursachen, erfassen Sie diese zuerst und wenden dann die 5 Whys auf die wahrscheinlichsten an.

5-Whys-Retrospektiven-Format

Problembeschreibung

Was genau ist passiert, wo und wann?

Einigen Sie sich auf eine Problembeschreibung, bevor jemand eine Ursache hinzufügt, und beschränken Sie sie auf eine einzige Karte. Formulieren Sie sie konkret: was passiert ist, wo, wann und in welchem Umfang, ohne eine Vermutung zur Ursache. „Release 4.2 wurde zwei Tage zu spät ausgeliefert“ gibt dem Team etwas, wonach es fragen kann. „Releases sind ein Chaos“ nicht.

Was wir wissen

Welche Fakten und Daten beschreiben das Problem?

Sammeln Sie Fakten vor Ursachen, etwa Zeitabläufe, Kennzahlen, Logs, Kundenmeldungen und kürzliche Änderungen. Jede Antwort in der Kette der Warum-Fragen sollte auf etwas von hier oder auf etwas, das das Team prüfen kann, beruhen. Fehlt ein Fakt, notieren Sie das und machen Sie die Beschaffung zu einer Maßnahme.

Warum ist es passiert?

Was hat das Problem direkt verursacht?

Jede Karte hier ist ein erstes Warum, also eine direkte Ursache der Problembeschreibung. Beschränken Sie die Antworten darauf, was passiert ist, nicht wer. Stimmen Sie nach dem Gruppieren über die Ursache ab, die das Problem am wahrscheinlichsten erklärt. Öffnen Sie in der Diskussion die oberste Karte und stellen Sie die nächsten vier Warum-Fragen als Kommentar-Thread, wobei jede Antwort auf die vorherige erwidert. Treffen auf einer Ebene zwei Antworten zu, antworten Sie zweimal auf denselben Kommentar und verfolgen Sie beide Zweige.

Wann sollte diese Retrospektive durchgeführt werden?

  • Ein Problem tritt immer wieder auf, obwohl es behoben wurde, und Sie möchten die Ursache finden, die bei der letzten Lösung übersehen wurde.
  • Nach einem Vorfall, einem durchgerutschten Fehler oder einer verpassten Deadline, wenn das Team das Warum verstehen muss, bevor es sich auf Änderungen einigt.
  • Ein Punkt in einer Retrospektive hat die meisten Stimmen erhalten und verdient eine gründliche Betrachtung in einer eigenen Sitzung.
  • Das Problem scheint einer Hauptlinie von Ursache und Wirkung zu folgen. Hat es viele beitragende Ursachen, erfassen Sie diese zuerst mit einem Fischgrätendiagramm.

Vorschläge für Fragen zum Icebreaker

  • Welche kleine Korrektur haben Sie einmal vorgenommen, die ein viel größeres Problem gelöst hat?
  • Was haben Sie erst verstanden, nachdem Sie mehr als einmal nach dem Warum gefragt haben?

Möchten Sie eine Aufwärmübung, bei der Ihr Team aktiv mitmacht, und nicht nur laut Antworten gibt? Kostenlose Icebreaker durchsuchen →

Ideen und Tipps für Ihre Retrospektive

  • Einigen Sie sich vor dem Brainstorming gemeinsam auf die Problembeschreibung und fügen Sie sie als einzige Karte in „Problembeschreibung“ ein. Die Vorlage stellt das Brainstorming auf „Ideen sofort anzeigen“ ein, sodass alle jede Karte sehen, sobald sie hinzugefügt wird. Sie können das in den Meeting-Einstellungen ändern.
  • Die Vorlage stellt die Diskussionsphase auf „Alle diskutieren“ ein, damit die Problembeschreibung und die Fakten neben der Ursache mit den meisten Stimmen sichtbar bleiben. Sie können das in den Meeting-Einstellungen ändern.
  • Führen Sie die Kette als Kommentar-Thread auf der Ursache mit den meisten Stimmen durch. Diese Karte ist das erste Warum. Fügen Sie einen Kommentar hinzu, der „Warum ist das passiert?“ beantwortet, antworten Sie darauf mit der nächsten Antwort und machen Sie so weiter. Antworten lassen sich drei Ebenen tief verschachteln, sodass Karte, ein Kommentar und drei Antworten zusammen fünf Warum-Fragen ergeben.
  • Hören Sie auf, wenn Sie eine Ursache erreichen, die das Team ändern kann, ob das nun drei oder sieben Warum-Fragen dauert. Brauchen Sie eine sechste, fügen Sie der Karte einen neuen Kommentar hinzu, der an die letzte Antwort anknüpft.
  • Fragen Sie nach dem Prozess, nicht nach der Person. Landet eine Antwort bei „Jemand hat einen Fehler gemacht“, fragen Sie, warum der Prozess diesen Fehler durchgelassen hat.
  • Machen Sie aus der Grundursache eine Gegenmaßnahme. Öffnen Sie das Menü an der letzten Antwort, wählen Sie „In Maßnahme kopieren“ und geben Sie der Maßnahme eine verantwortliche Person und ein Fälligkeitsdatum. Prüfen Sie sie in der Phase „Offene Maßnahmen“ einer späteren Retrospektive, um zu sehen, ob die Lösung gewirkt hat.

Häufig gestellte Fragen

Was ist die 5-Why-Methode von Taiichi Ohno?
Dabei fragt man bei einem Problem immer wieder nach dem Warum, um über das offensichtliche Symptom hinaus zur Grundursache zu gelangen. Die Methode ist Teil des Toyota-Produktionssystems, an dessen Aufbau Taiichi Ohno maßgeblich beteiligt war, und sein Beispiel einer stillstehenden Maschine erreicht die Grundursache, eine Pumpe ohne Sieb, beim fünften Warum.
Wie wendet man die 5 Whys an?
Beginnen Sie mit einem konkreten Problem, fragen Sie, warum es passiert ist, und fragen Sie dann bei jeder Antwort erneut nach dem Warum, bis Sie eine behebbare Ursache erreichen. Ein 5-Why-Beispiel: Das Release war verspätet, weil die Tests erst am Release-Tag begannen, weil das letzte Feature an diesem Morgen gemergt wurde, weil es drei Tage auf ein Review wartete, weil nur eine Person Datenbankänderungen freigeben kann, weil niemand sonst im Schema geschult wurde. Die Lösung ist, eine zweite Person für Freigaben zu schulen, nicht, alle zu schnellerem Testen aufzufordern.
Welche Techniken der Ursachenanalyse gibt es?
Gängige Techniken sind die 5 Whys, das Fischgrätendiagramm (Ishikawa), die Pareto-Analyse, die Fehlerbaumanalyse und die Änderungsanalyse. Die 5 Whys verfolgen eine einzige Kette von Ursache und Wirkung. Hat ein Problem mehrere beitragende Ursachen, erfassen Sie diese daher zuerst mit einer Fischgräten-Retrospektive (Ishikawa) und wenden dann die 5 Whys auf die wahrscheinlichsten an.
Wie schreibt man eine Ursachenanalyse?
Beschreiben Sie das Problem mit Fakten: was passiert ist, wo, wann und in welchem Umfang. Verfolgen Sie die Ursachen bis zu einer Grundursache zurück, prüfen Sie jeden Schritt anhand von Belegen und halten Sie dann die Korrekturmaßnahmen mit verantwortlichen Personen, Fälligkeitsdaten und der Art der Wirksamkeitsprüfung fest. In dieser Vorlage sind Problem und Fakten Spalten, der Kommentar-Thread zur wichtigsten Ursache ist die Kette der Warum-Fragen, und die Maßnahmen sind die Korrekturmaßnahmen.
Welche Vorlage eignet sich am besten für eine Ursachenanalyse?
Das hängt vom Problem ab. Eine 5-Why-Vorlage passt zu einem Problem mit einer Hauptlinie von Ursache und Wirkung, ein Fischgrätendiagramm zu einem Problem mit vielen möglichen Ursachen in Menschen, Prozessen und Tools. Beide funktionieren am besten, wenn das Team sie gemeinsam ausfüllt, die Fakten vor Augen hat und jede Lösung eine verantwortliche Person bekommt.

Verwandte Vorlagen

4L-Retrospektive

Reflektieren Sie, was Ihrem Team gefallen hat, was Sie gelernt haben, was gefehlt hat und was Sie sich gewünscht hätten

Agile Retrospektive

Vier Fragen, um den letzten Sprint zu reflektieren und Änderungen zu planen.

Anker & Motoren Retrospektive

Erkennen Sie, was Ihr Team antreibt und was es bremst

Retrospektive zur teamübergreifenden Zusammenarbeit

Reibung zwischen Teams beseitigen, die voneinander abhängig sind

Sind Sie bereit, diese Retrospektive durchzuführen?Probieren Sie diese Retrospektive live aus