Die sieben Kanban-Kadenzen

Scrum hat vorgeschriebene Events. Kanban hat Kadenzen – empfohlene regelmäßige Meetings für spezifische Feedbackzwecke.

Der wesentliche Unterschied:

• Scrum-Events sind obligatorische Bestandteile des Frameworks
• Kanban-Kadenzen sind optional und werden je nach Bedarf eingesetzt

Sie benötigen nicht alle sieben Kadenzen. Beginnen Sie mit ein oder zwei. Fügen Sie weitere hinzu, wenn Sie reifen.

Die sieben Kadenzen dienen drei Ebenen:

1. Teamebene: Tägliche Abläufe
2. Service-Ebene: Lieferung an Kunden/Stakeholder
3. Strategische Ebene: Portfolio- und Organisationsausrichtung

Zweck: Flow koordinieren, Blocker identifizieren, reibungslose tägliche Abläufe sicherstellen.

Häufigkeit: Täglich, maximal 15 Minuten.

Fokus:

• Das Board von rechts nach links durchgehen (mit Elementen beginnen, die am nächsten an „Fertig" sind)
• Blockierte Elemente identifizieren
• Gefährdete Elemente besprechen (die über den Schwellenwert hinaus altern)
• Pull-Entscheidungen treffen

NICHT im Fokus:

• Statusberichte („Was hast du gestern gemacht?")
• Detaillierte Problemlösung (das offline klären)
• Individuelle Leistung

Zentrale Fragen:

• „Was blockiert den Fortschritt bei diesem Element?"
• „Dieses Element ist seit 6 Tagen hier – was passiert?"
• „Jetzt, wo X fertig ist, wer zieht das nächste Element?"

Unterschied zum Scrum Daily: Scrum Daily fokussiert auf Menschen und Fortschritt in Richtung Sprint-Ziel. Das Kanban-Meeting fokussiert auf Arbeitselemente und Flow. Das Board, nicht die Teammitglieder, ist das Subjekt.

Diese Kadenzen steuern die Beziehung zwischen dem Team und seinen Kunden/Stakeholdern.

1. Replenishment Meeting (Wöchentlich)

Zweck: Entscheiden, welche neue Arbeit ins System kommt.

Teilnehmer: Product Owner, Teamleitung, wichtige Stakeholder.

Aktivitäten:

• Eingehende Anfragen prüfen
• Backlog priorisieren
• Elemente in „Bereit" ziehen (unter Beachtung der WIP-Limits)
• Kommende Kapazität besprechen

Ergebnis: Eine aufgefüllte und priorisierte „Bereit"-Spalte.

2. Service Delivery Review (Zweiwöchentlich oder monatlich)

Zweck: Überprüfen, wie gut Sie an Kunden liefern.

Teilnehmer: Team, Stakeholder, Kunden wenn möglich.

Überprüfte Metriken:

• Lead-Time-Trends
• Durchsatzstabilität
• Kundenzufriedenheit
• SLA-Performance

Ergebnis: Datengestützte Diskussion über Servicequalität. Erfüllen wir die Erwartungen? Was muss sich ändern?

3. Delivery Planning Meeting (Bei Bedarf)

Zweck: Lieferung/Release fertiger Arbeit koordinieren.

Teilnehmer: Team, Ops, alle am Release Beteiligten.

Aktivitäten:

• Prüfen, was release-bereit ist
• Release-Timing planen
• Abhängigkeiten koordinieren
• Release-Risiken identifizieren

Ergebnis: Klarer Release-Plan mit Terminen und Verantwortlichkeiten.

Diese Kadenzen verbinden die Arbeit auf Teamebene mit der Organisationsstrategie.

4. Risk Review (Wöchentlich oder zweiwöchentlich)

Zweck: Risiken für die Lieferung identifizieren und managen.

Fokus:

• Blockierte Elemente und Blocker
• Elemente, die über Schwellenwerte hinaus altern
• Abhängigkeiten von anderen Teams
• Systemische Probleme

Ergebnis: Maßnahmen zur Risikominderung. Eskalationspfade für ungelöste Blocker.

5. Strategy Review (Monatlich oder quartalsweise)

Zweck: Teamarbeit mit Organisationsstrategie ausrichten.

Teilnehmer: Führung, Product, Teamvertreter.

Fokus:

• Arbeiten wir an den richtigen Dingen?
• Wie verbindet sich unsere Arbeit mit Geschäftszielen?
• Welche strategischen Änderungen beeinflussen unsere Prioritäten?

Ergebnis: Aktualisierte strategische Ausrichtung, Prioritätsanpassungen.

6. Operations Review (Monatlich)

Zweck: Teamübergreifende Abhängigkeiten und Flow überprüfen.

Teilnehmer: Vertreter mehrerer Teams, Management.

Fokus:

• Wie fließt die Arbeit über Teams hinweg?
• Wo sind teamübergreifende Engpässe?
• Welche Policy- oder Strukturänderungen sind nötig?

Ergebnis: Koordinationsverbesserungen, teamübergreifende Vereinbarungen.

7. Retrospektive (Zweiwöchentlich oder monatlich)

Zweck: Über den Prozess reflektieren und Verbesserungen identifizieren.

Format: Variiert (ähnlich wie agile Retrospektiven).

Fokus:

• Was funktioniert gut?
• Was funktioniert nicht?
• Welche Experimente sollten wir ausprobieren?
• Was haben wir aus früheren Experimenten gelernt?

Ergebnis: Konkrete Verbesserungsexperimente mit Verantwortlichen und Terminen.

Kanban-spezifische Retrospektiven-Themen:

• Sind unsere WIP-Limits richtig?
• Was verursacht unseren aktuellen Engpass?
• Helfen oder behindern unsere Policies?
• Verbessert sich unsere Lead Time?
• Was erzeugt Blocker?

Integration mit Scrum: Wenn Sie Scrumban praktizieren, haben Sie wahrscheinlich bereits Sprint-Retrospektiven. Diese dienen demselben Zweck. Sie müssen kein weiteres Retrospektiven-Meeting hinzufügen.