Was ist gut geflossen?

Wo lief die Arbeit reibungslos über das Board?

Bugfixes gingen innerhalb eines Tages von Review zu Done, echt schnell.
Unser Daily Standup hat uns geholfen, blockierte Items schnell gemeinsam anzugehen.
Dank klarer Akzeptanzkriterien sind weniger Karten zurück in die Entwicklung gewandert.
Wo lagen die Engpässe?

In welchen Phasen hat sich Arbeit gestaut oder ist ins Stocken geraten?

Code Review war ständig ein Engpass, weil nur eine Person reviewen konnte.
Karten lagen tagelang in „Wartet auf Deployment“.
Beim Testen hat sich alles gestaut, weil die Umgebungen instabil waren.
WIP-Limits und Regeln

Funktionieren unsere WIP-Limits und Regeln?

Wir haben das WIP-Limit in der Entwicklung ständig überschritten. Sollten wir es senken?
Das Limit für „In Arbeit“ hat uns gezwungen, erst fertig zu machen, bevor wir Neues anfangen. Das hat geholfen.
Unsere Definition of Done ist unklar, deshalb werden Karten zu früh weitergeschoben.
Was werden wir verbessern?

Welche konkreten Änderungen verbessern unseren Fluss?

Eine zweite Person in die Code-Review-Rotation aufnehmen, um Review-Verzögerungen zu verringern.
Das Dev-WIP-Limit auf 3 senken, um Kontextwechsel zu reduzieren.
Eine Altersregel für Blockiertes einführen: Alles, was länger als 2 Tage blockiert ist, wird eskaliert.

Was ist die Kanban-Flow-Retrospektive?

Kanban-Teams arbeiten nicht in Sprints, deshalb geht eine auf Sprints zugeschnittene Retrospektive oft am Kern vorbei. Die Kanban-Flow-Retrospektive betrachtet, wie Arbeit über euer Board fließt: wo Karten stocken, wo sie zügig vorankommen und was zu Staus führt. So findet ihr ganz praktisch die Reibungspunkte, die die Lieferung verlangsamen und schwer planbar machen. Das Team arbeitet vier Themen durch: was gut geflossen ist, wo die Engpässe lagen, ob eure Work-in-Progress-Limits (WIP-Limits) und Regeln funktionieren und was ihr ändern werdet. Wenn ihr sie gemeinsam in TeamRetro besprecht, entsteht ein gemeinsames Bild davon, wie Arbeit von „To do“ zu „Done“ gelangt. Das Format eignet sich für Teams, die Lean oder Kanban praktizieren, und für jedes agile Team, das Cycle Time und Durchsatz verbessern will. Regelmäßig durchgeführt, wird daraus eine Gewohnheit kleiner Verbesserungen (Kaizen). Wenn ihr das Board und eure Flow-Metriken mitbringt, bleibt das Gespräch beim System statt bei einzelnen Personen. So kann sich das Team auf Prozessänderungen einigen und in der nächsten Sitzung prüfen, ob sie gewirkt haben.

Format der Kanban-Flow-Retrospektive

Was ist gut geflossen?

Wo lief die Arbeit reibungslos über das Board?

Dieses Thema erfasst die Teile eures Workflows, die gut funktioniert haben: Arbeitselemente, die ohne unnötige Verzögerungen stetig vom Start bis zum Ziel gelangt sind. Ermutige das Team, an konkrete Karten, Übergaben oder Phasen zu denken, die sich reibungslos angefühlt haben, und frag nach, was diesen Fluss ermöglicht hat, damit sich diese Praktiken wiederholen lassen.

Wo lagen die Engpässe?

In welchen Phasen hat sich Arbeit gestaut oder ist ins Stocken geraten?

Engpässe sind die Phasen, in denen sich Arbeit schneller ansammelt, als sie abgearbeitet werden kann, wodurch der gesamte Fluss ausgebremst wird. Bitte das Team, sich die Spalten anzuschauen, in denen sich Karten gestapelt haben oder liegen geblieben sind, und geh den Ursachen auf den Grund. Lenke den Fokus auf System und Prozess statt auf Einzelpersonen, um Schuldzuweisungen zu vermeiden und das Gespräch konstruktiv zu halten.

WIP-Limits und Regeln

Funktionieren unsere WIP-Limits und Regeln?

Dieses Thema beleuchtet, ob die WIP-Limits, Spaltenregeln und die Definition of Done des Teams den Fluss fördern oder behindern. Rege das Team dazu an, darüber nachzudenken, ob die Limits eingehalten wurden, zu eng oder zu locker waren und ob die Regeln für das Verschieben von Karten klar waren. Oft zeigt sich dabei, wo der Prozess selbst nachjustiert werden muss.

Was werden wir verbessern?

Welche konkreten Änderungen verbessern unseren Fluss?

In diesem handlungsorientierten Thema verwandelt das Team Erkenntnisse in Zusagen. Ermutige zu konkreten, messbaren Verbesserungen mit klarer Verantwortung statt zu vagen Absichten. Verknüpfe jede Maßnahme mit einem zuvor genannten Engpass oder Flow-Problem und legt gemeinsam fest, woran ihr bei der nächsten Retrospektive erkennt, dass es funktioniert hat.

Wann sollte diese Retrospektive durchgeführt werden?

  • Wenn euer Team Kanban oder Lean praktiziert und den Fluss verbessern will, ohne auf das Ende eines Sprints zu warten.
  • Wenn die Cycle Times steigen oder die Arbeit festzustecken scheint und ihr den Engpass finden müsst.
  • Wenn WIP-Limits und Spaltenregeln unklar sind oder ignoriert werden.
  • Wenn ihr die Diskussion in der Retrospektive an Flow-Metriken wie Durchsatz und Lead Time knüpfen wollt.
  • Alle zwei Wochen oder einmal im Monat, um die Verbesserung des Flusses zur Gewohnheit zu machen.

Vorschläge für Fragen zum Icebreaker

  • Wenn euer Workflow eine Verkehrslage wäre, welche wäre es gerade: freie Autobahn, Rushhour oder kompletter Stillstand?
  • Was läuft in deinem Alltag immer reibungslos, ganz ohne Engpässe?

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

  • Bringt das Board und eure Flow-Metriken (Cycle Time, Durchsatz, WIP) mit, damit die Diskussion bei den Daten beginnt.
  • Sprecht über das System, nicht über Einzelpersonen. Engpässe sind meist Prozessprobleme, also verzichtet auf Schuldzuweisungen.
  • Beschränkt euch auf ein oder zwei Verbesserungsmaßnahmen, damit das Team sie bis zur nächsten Retro umsetzen kann.
  • Gebt jeder Maßnahme eine verantwortliche Person und eine Möglichkeit, sie in der nächsten Sitzung zu messen.
  • Lasst Ideen vor der Diskussion anonym erfassen, damit sich auch ruhigere Teammitglieder einbringen.
  • Beginnt mit einem Rückblick auf die Maßnahmen vom letzten Mal, um zu sehen, was sich verändert hat.

Häufig gestellte Fragen

Wie unterscheidet sich die Kanban-Flow-Retrospektive von einer Sprint-Retrospektive?
Eine Sprint-Retrospektive blickt auf eine feste Timebox zurück. Eine Kanban-Flow-Retrospektive betrachtet, wie Arbeit durch euer System fließt, und nutzt dafür statt Sprintzielen Flow-Metriken wie Cycle Time, Durchsatz und WIP.
Wie lange dauert eine Kanban-Flow-Retrospektive?
Die meisten Teams sind nach 45–60 Minuten fertig. Plant bis zu 90 Minuten ein, wenn das Team groß ist oder ein größerer Engpass bearbeitet werden muss.
Wann sollten wir eine Kanban-Flow-Retrospektive durchführen?
Kanban kennt keine Sprints, also wählt einen festen Rhythmus, etwa alle zwei Wochen oder einmal im Monat. Setzt eine zusätzliche an, wenn ihr merkt, dass Cycle Times steigen oder Warteschlangen wachsen.
Welche Metriken sollten wir zur Retrospektive mitbringen?
Cycle Time, Lead Time, Durchsatz, WIP-Stände und ein Cumulative Flow Diagram. Sie zeigen, wo sich Arbeit staut und ob eure Änderungen helfen.
Wer sollte eine Kanban-Flow-Retrospektive moderieren?
Oft übernimmt das ein Scrum Master, Agile Coach, Teamlead oder Flow Manager, aber jede Person im Team kann es tun. Wichtig ist, die Diskussion beim System zu halten und sicherzustellen, dass jede Maßnahme eine verantwortliche Person und eine Messgröße hat.
Sind Sie bereit, diese Retrospektive durchzuführen?Probieren Sie diese Retrospektive live aus