Was ist die Fischgräten-Retrospektive (Ishikawa)?
Die Fischgräten-Retrospektive (Ishikawa) hilft eurem Team, die eigentlichen Ursachen eines Problems zu finden, statt nur seine Symptome zu behandeln. Sie basiert auf dem Ursache-Wirkungs-Diagramm, das Kaoru Ishikawa in den 1960er-Jahren bekannt gemacht hat. Es ordnet mögliche Ursachen in einer Form an, die an ein Fischskelett erinnert. In dieser Vorlage arbeitet euer Team sechs Ursachenkategorien durch: System, Prozess, Formulare, Menschen, Richtlinien und Arbeitsumgebung. Wer Kategorie für Kategorie vorgeht, schaut über die erste naheliegende Erklärung hinaus. So kommen auch Ursachen zur Sprache, die außerhalb des eigenen Bereichs liegen. Am meisten bringt sie bei Problemen mit mehreren Einflussfaktoren, bei denen eine offensichtliche Lösung nicht funktioniert hat. Wenn ihr die Ursachen in Kategorien sortiert, wird sichtbar, wie sie zusammenhängen, und ihr erkennt, welche Änderung am meisten bewirkt. Ein Fischgrätendiagramm (auch Ishikawa-Diagramm oder Ursache-Wirkungs-Diagramm genannt; alle drei Namen bezeichnen dasselbe Werkzeug) setzt das Problem an den „Kopf“ des Fisches und zeichnet die wichtigsten Ursachenkategorien als Gräten, die von der Hauptgräte abzweigen. In der ursprünglichen Form aus Fertigung und Qualitätsmanagement sind das die „6 M“: Mensch (Personal), Methode (Prozess), Maschine (Ausstattung), Material (Einsatzstoffe), Messung (Daten und Kennzahlen) und Mitwelt (das Umfeld). Das Team sammelt an jeder Gräte mögliche Ursachen und fragt dann immer wieder „Warum?“, um jeden Zweig bis zur Grundursache zu verfolgen. Die Kategorien dieser Vorlage übertragen die 6 M auf Software- und Wissensarbeitsteams. Die Technik bleibt gleich, nur die Bezeichnungen sind an eure Arbeit angepasst. Steht am Kopf des Fisches zum Beispiel „Releases verzögern sich ständig“, könnte eine Ursache unter Menschen „wichtiger Reviewer ist ein Engpass“ lauten, unter Prozess „keine Definition of Done“ und unter System „instabile CI-Pipeline“. Wenn ihr Ursachen so abbildet, verhindert ihr, dass euer Team nur ein Symptom behebt und übersieht, was das Problem wirklich antreibt.
Format der Fischgräten-Retrospektive
System
Welche Technologien, Software oder Tools beeinflussen möglicherweise die Leistung oder Ergebnisse unseres Teams?
Schaut euch eure technische Infrastruktur, eure Software-Tools und die Schnittstellen zwischen Systemen an. Fragt nach offensichtlichen technischen Fehlern, aber auch nach den unauffälligeren Wechselwirkungen zwischen Systemen, die die Arbeit ausbremsen.
Prozess
Welche Abläufe oder Arbeitsschritte verursachen Verzögerungen oder Ineffizienzen in unserer Arbeit?
Sucht nach Engpässen, doppelten Arbeitsschritten und Lücken in euren Abläufen. Wenn ihr nach konkreten Schritten fragt, wie die Arbeit erledigt wird, kann das Team Prozessprobleme leichter von anderen Ursachen unterscheiden.
Formulare
Welche Probleme mit unseren Vorlagen oder Dokumentationen könnten Klarheit oder Genauigkeit beeinträchtigen?
Schaut euch eure Vorlagen und Dokumentation an. Finden die Leute, was sie brauchen? Ist alles vollständig, und erfüllt es seinen Zweck? Bezieht informelle Dokumente genauso ein wie formelle.
Menschen
Welche Faktoren bei Fähigkeiten, Kommunikation oder Rollen beeinflussen unseren Erfolg?
Sprecht über Fähigkeiten, Kommunikation und Rollen, ohne Schuld zuzuweisen. Konzentriert euch auf die Rahmenbedingungen, etwa unklare Rollen oder Wissenssilos, und nicht auf Kritik an einzelnen Personen.
Richtlinien
Welche Vorgaben oder Regeln passen nicht zu unserer tatsächlichen Arbeitsweise oder bereiten Schwierigkeiten?
Schaut euch die geschriebenen und ungeschriebenen Regeln an, die die Arbeit beeinflussen. Fragt bei jeder Richtlinie, ob sie die heutige Arbeitsweise des Teams noch unterstützt oder ihr im Weg steht.
Arbeitsumgebung
Was an unserem physischen oder virtuellen Arbeitsplatz beeinträchtigt Zusammenarbeit oder Produktivität?
Betrachtet den physischen und virtuellen Arbeitsplatz, also eure Tools, die Büroaufteilung und wie gut die Zusammenarbeit remote funktioniert.
Wann sollte diese Retrospektive durchgeführt werden?
- Wenn ein Problem wahrscheinlich mehr als eine Ursache hat
- Nach einem größeren Vorfall, der eine strukturierte Analyse braucht, bevor jemand eine Lösung vorschlägt
- Wenn das Team immer wieder Symptome behebt und das Problem trotzdem zurückkommt
- In Projekt-Post-Mortems oder Incident-Reviews, damit sich derselbe Fehler nicht wiederholt
Vorschläge für Fragen zum Icebreaker
- Wenn unser Team eine Maschine wäre: Welches Teil bräuchte gerade die meiste Wartung?
- Was ist die überraschendste Lösung, die du für ein wiederkehrendes Problem gefunden hast?
Möchten Sie eine Aufwärmübung, bei der Ihr Team aktiv mitmacht, und nicht nur laut Antworten gibt? Kostenlose Icebreakers durchsuchen →
Ideen und Tipps für Ihre Retrospektive
- Formuliert eine klare Problembeschreibung am Kopf des Fisches, bevor jemand eine Ursache ergänzt
- Achtet darauf, dass alle in jeder Kategorie Ursachen beitragen, auch in denen außerhalb ihrer eigenen Rolle
- Wartet mit Lösungen, bis alle Ursachen erfasst sind
- Nutzt die 5-Why-Methode innerhalb jeder Kategorie, um über die erste Antwort hinauszugehen
- Haltet jede Ursache fest, auch wenn sie anfangs unbedeutend wirkt
- Plant 90–120 Minuten ein, damit ihr alle sechs Kategorien gründlich behandeln könnt
Häufig gestellte Fragen
Was sind die 6 M eines Fischgrätendiagramms?
Was ist der Unterschied zwischen einem Fischgräten- und einem Ishikawa-Diagramm?
Wie führt man eine Ursachenanalyse mit einem Fischgrätendiagramm durch?
Wer hat das Ishikawa-Diagramm erfunden?
Verwandte Vorlagen
Sammle umsetzbares Feedback zu deinem Sprint Review.
Rose-Bud-Thorn-Retrospektive
Benennt Erfolge, erste Chancen und Schmerzpunkte eures Teams in einer Session.
What? So What? Now What?-Retrospektive
Von dem, was passiert ist, zu dem, was ihr als Nächstes tut.
FLAP-Retrospektive
Erkenntnisse, Erfolge und Probleme reflektieren und dann die nächsten Schritte planen