Wie optimiere ich den Workflow mit Kanban?

Kanban-Grundprinzipien

Kanban ist nicht 'Scrum ohne Sprints'. Es ist ein eigenes Pull-System mit klaren Regeln:

• Visualisiere den Workflow: Board mit Stages (Backlog, In Progress, Review, Done).

• Begrenze Work in Progress (WIP): pro Stage maximale Anzahl Items.

• Manage Flow: Items durchziehen, nicht stehen lassen.

• Mach Regeln explizit: was darf in welche Stage rein? Definition of Done pro Stage.

• Kontinuierliche Verbesserung: regelmäßig Bottlenecks identifizieren.

Schritt 1: WIP-Limits setzen

Faustregel: pro Stage max 1.5x Team-Größe. Beispiel: 5-Personen-Team -> 'In Progress' max 7-8 Items. Ohne WIP: Items stauen sich, Cycle Time explodiert.

Schritt 2: Bottlenecks identifizieren

Cumulative Flow Diagram (CFD): zeigt Anzahl Items pro Stage über Zeit. Wenn ein Band breit wird = Bottleneck. Beispiel: Review-Stage wird breit = QA-Kapazität zu klein.

Schritt 3: Service-Klassen

Nicht alle Items sind gleich dringend. Vier Standard-Klassen:

• Expedite: P0-Incidents. WIP-Limit überschritten okay. Eilig.

• Fixed-Date: harter Termin (Regulatorik). Geplant + verfolgt.

• Standard: normaler Fluss. FIFO oder Cost-of-Delay.

• Intangible: Tech-Debt, Lernen. Wann immer Kapazität übrig.

Schritt 4: Cycle-Time messen

Cycle Time = Zeit von 'Start' bis 'Done' pro Item. Zentrale Flow-Metrik. Sinkt sie über Zeit: gut. Steigt sie: Bottleneck oder Komplexität stieg.

Zusätzlich: 85 %-Quantil-Cycle-Time. Beispiel: '85 % unserer Items sind in 14 Tagen durch'. Präzisere Aussage als Durchschnitt.

Anti-Patterns

• Kein WIP-Limit: 'Wir sehen wie viel klappt'. Klassisches Anti-Kanban.

• Board nicht aktualisiert: Realität drift weg vom Board.

• Items nie expedite: alle gleich, kritische Tickets warten.

• Estimation-Wahn: Kanban braucht keine Schätzungen. Cycle Time ist die Metrik.