Kanban

Kommend von Toyota (Autofabrik). Statt feste 2-Wochen-Pakete (Scrum) gibt es einen kontinuierlichen Fluss. Wichtigstes Werkzeug: Das Board. Spalten: To Do -> In Progress -> Done. Regel: Du darfst erst was Neues anfangen, wenn das Alte fertig ist. Beschränkung der Arbeit (WIP Limit - Work In Progress). "Maximal 3 Autos in der Lackiererei". Das verhindert Stau. Liefert schneller.

Merksatz: Eine Methode zur Steuerung von Arbeitsprozessen, die auf Visualisierung (Board) und Begrenzung der parallelen Arbeit (WIP) setzt, um Durchlaufzeiten zu optimieren.

Perfekt für Support-Teams oder DevOps. Warum? Ein Bug ("Server down") kann nicht auf den nächsten Sprint warten. Er muss sofort durch den Prozess fließen. Kanban ist flexibler als Scrum. Man kann die Priorität täglich ändern.

1. WIP Limits (The Magic)

Warum begrenzen? Wenn du 10 Dinge gleichzeitig machst, wirst du langsamer (Context Switching). Wenn die Spalte "Testing" voll ist (Limit 3 erreicht), dürfen die Entwickler vorne nichts Neues in "Coding" schieben. Der Stau wird sichtbar. Die Entwickler müssen den Testern helfen, den Stau abzubauen. Das Team arbeitet zusammen, um den Flow zu retten. "Stop starting, start finishing."

2. Lead Time vs. Cycle Time

Lead Time: Vom Kunde bestellt ("Ich will Feature X") bis zum Release. (Sicht des Kunden).
Cycle Time: Vom Beginn der Arbeit ("Dev fängt an") bis zum Release. (Sicht des Teams). Kanban optimiert diese Zeiten.

3. Service Classes

Man kann "Spuren" auf dem Board haben.

Expedite (Notarzt): Darf Limits ignorieren. Muss sofort bearbeitet werden. (Server Down).
Standard: Normale Features (First In, First Out).
Fixed Date: Muss bis Weihnachten fertig sein.

1. Little's Law

Die mathematische Grundlage von Kanban stammt aus der Warteschlangentheorie. Durchlaufzeit (Lead Time) = Bestand (WIP) / Durchsatz (Throughput). Wenn dein Team pro Woche 5 Tickets fertigstellt (Throughput) und 20 Tickets im Status "In Bearbeitung" rumliegen (WIP), dann liegt die mathematisch garantierte Durchlaufzeit eines neuen Tickets bei exakt 4 Wochen (20/5). Die Formel beweist hart: Je größer die Spalte "In Progress" (WIP) explodiert, desto länger muss ein Kunde pauschal warten. Der einzige Hebel, um ein System schneller zu machen (ohne mehr Personal), ist die Verringerung von WIP.

2. Cumulative Flow Diagrams (CFD)

Scrum misst mit Burn-Down Charts. Kanban misst mit dem mächtigeren CFD. Im Graph stehen auf der X-Achse die Tage, auf der Y-Achse kumuliert die Anzahl der Tickets. Jeder Bereich (Backlog, Coding, Testing, Done) wird als farbige Fläche geschichtet. Die visuelle Analyse ist massiv:

Die horizontale Breite einer Fläche im bestimmten Tag zeigt dir die exakte Cycle-Time.
Die vertikale Dicke der "Testing"-Schicht zeigt dir in Echtzeit den WIP des Test-Teams. Wächst "Testing" exponentiell an wie ein Tumor, siehst du sofort den Bottleneck in der QA. Wenn die oberste (Done) Linie flach bleibt, liefert das Gesamtband nichts aus.

3. Upstream Kanban vs Downstream Kanban

Ein reiner Dev-Prozess beginnt in der Regel erst, sobald das Backlog voll von "Ready for Dev"-Stories liegt. Das ist das klassische Downstream (Delivery). Das ignorierte Desaster: Ein Projekt scheitert nicht am Deving, sondern oft an schwammigen Anforderungen. Das Upstream (Discovery) Kanban zieht das Brett massiv nach vorne: Idee -> Review CTO -> User Research -> Prototyp -> Backlog. Auch hier existieren schmale (oft kleinere) WIP-Limits. Dies verhindert das Aufblähen einer massiven Ideas/Triage-Halde. Tickets sollen Upstream sterben (verworfen werden), statt teuer im Downstream als falsches Product Feature zu enden.