WIP-Limit-Simulator: weniger gleichzeitig, schneller fertig

Schau auf dein Board. Zähl die Tickets zwischen Backlog und Done. Dann zähl die Leute, die daran arbeiten.

Wenn die erste Zahl doppelt so groß ist wie die zweite, brauchst du keine Retro über Motivation. Du hast ein Rechenproblem.

Ein WIP-Limit ist die Antwort darauf, und der Simulator hinter dieser Seite ist der Beweis, den du im Team vorzeigen kannst: Flow Physics und WipIt!. Läuft im Browser, kostenlos, ohne Account.

Was ein WIP-Limit ist

WIP heißt Work in Progress: alles, was angefangen und nicht fertig ist. Ein WIP-Limit deckelt diese Zahl pro Spalte. Development mit Limit 3 heißt, dass das vierte Ticket liegen bleibt, bis eines rausgeht.

Der eigentliche Effekt liegt woanders als beim Deckeln. Ein Limit dreht die Übergabe um. Ohne Limit schiebst du fertige Arbeit weiter und bist sie los; mit Limit zieht sich der nächste Schritt Arbeit erst dann, wenn er wirklich Platz dafür hat. Wer keinen Platz hat, hilft dem, der zu viel hat, statt etwas Neues anzufangen.

Stop starting, start finishing. Mehr ist es nicht.

Little's Law: das Gesetz, das du nicht verhandeln kannst

Cycle Time = WIP / Throughput

Throughput ist, was du pro Woche fertig bekommst. Cycle Time ist, wie lange ein Ticket vom Start bis Done braucht.

Rechne mit. Dein Team schließt zehn Tickets pro Woche ab, und auf dem Board stehen vierzig offene. Vierzig geteilt durch zehn: jedes Ticket braucht im Schnitt vier Wochen.

Jetzt nimm die vierzig runter auf zehn. Zehn geteilt durch zehn ist eins. Eine Woche.

Das ist keine Empfehlung. Das ist Mathematik.

Es gibt genau einen Hebel, an dem du heute drehen kannst. Throughput hochzuziehen dauert: Leute einstellen, Skills aufbauen, Testautomatisierung, Deployment-Pipeline. WIP senken kannst du in der nächsten Viertelstunde. Du musst nur aufhören, Neues anzufangen.

Warum sich das trotzdem falsch anfühlt

Weil ein Board mit weniger offenen Tickets aussieht, als würde weniger passieren.

Auslastung und Geschwindigkeit sind zwei verschiedene Dinge. Ein Ticket wartet den größten Teil seiner Lebenszeit, statt bearbeitet zu werden; typisch ist ein Verhältnis von zehn Prozent Arbeit zu neunzig Prozent Warten. Die meisten Organisationen optimieren die zehn Prozent. Der Stau steckt in den neunzig.

Dazu kommt der Engpass. Drei Entwickler und zwei Tester: die Entwickler bauen zehn Features pro Woche, QA prüft fünf. Fünf gehen raus, und fünf liegen halbfertig herum, sind bezahlt, sind für niemanden etwas wert und tauchen in keiner Statistik als Verlust auf. Wer jetzt einen vierten Entwickler dazustellt, macht die Cycle Time schlechter, weil noch mehr Code in einen Engpass drückt, der schon voll ist. Mehr Geld, mehr Leute, langsameres System.

Und wenn alle bei hundert Prozent laufen, kippt das System beim ersten unerwarteten Ticket. Kingmans Formel sagt: je näher die Auslastung an hundert Prozent liegt, desto exponentieller wächst die Wartezeit. Ein perfekt geplantes System ist ein perfekt fragiles System.

Slack ist nicht Verschwendung, sondern der Grund, warum ein System Überraschungen übersteht.

Erst die Theorie, dann das Board

Hinter dem Link liegen zwei Sachen, und du landest zuerst auf der ersten.

Flow Physics ist die Theorie in fünf Modulen: Resource gegen Flow Efficiency, Little's Law, Engpässe und Theory of Constraints, Variabilität und Kingmans Formel, Pull-Systeme und WIP-Limits. Jedes Modul rechnet am gleichen Beispiel weiter, den drei Entwicklern und zwei Testern von oben. Das liest sich in unter zehn Minuten.

WipIt!, der Simulator, liegt einen Klick weiter. Das Board hat vier Spalten: Backlog, Dev, QA, Done. In den Spaltenköpfen von Dev und QA sitzen Plus und Minus, damit stellst du das WIP-Limit ein. Oben läuft die Cycle Time als Zahl mit Verlaufskurve mit, unten sitzen Play, Pause, Reset und Tempo bis dreifach.

Zwei Umschalter machen den Unterschied zur alten Version. Compare stellt zwei Boards nebeneinander, eines ohne Limit und eines mit, gleiche Arbeit, gleiche Ankunftsrate. Du siehst beide Cycle Times gleichzeitig laufen und auseinandergehen. Expert gibt jeder Spalte ihr eigenes Limit und schaltet einen Regler für die Arrival Rate frei, also für das Tempo, mit dem neue Arbeit ins System kommt. Im Learn-Modus ziehen beide Spalten gemeinsam, und für den ersten Durchlauf reicht das.

Die Anwendung ist auf Englisch. Bedienbar ist sie ohne Vorkenntnisse; wer die Begriffe nachlesen will, findet sie in Flow Physics.

Drei Durchläufe, die etwas bringen

Erster Durchlauf. Compare einschalten, das WIP-Limit auf 3 stehen lassen, laufen lassen und nichts anfassen. Beobachte die linke Seite. Ohne Limit stapelt sich Dev voll, QA läuft leer, und die Cycle Time zieht nach oben und kommt nicht mehr zurück, egal wie lange du wartest.

Zweiter Durchlauf. Zurücksetzen, Solo-Modus, Limit auf 1. Warten, bis die Kurve flach liegt. Dann das Limit auf 8 hochklicken und zuschauen, wie die Zahl oben mitwandert. Das ist Little's Law, und du hast es gerade selbst bewegt.

Dritter Durchlauf. Expert-Modus, Arrival Rate langsam hochziehen. Irgendwann säuft das Board ohne Limit ab, während das limitierte weiterläuft und der Backlog davor wächst. Genau das ist der Punkt: Wartezeit gehört in den Backlog, nicht zwischen Dev und QA.

Im Team

Ich bin kein Entwickler und kein Warteschlangentheoretiker. Ich bin Team Lead eines Kanban-Teams und habe diese Diskussion oft genug von der Board-Seite geführt. Was bei mir funktioniert: den Simulator im Compare-Modus laufen lassen, während jemand anderes redet. Nach zwei Minuten schaut sowieso jeder hin.

Danach die ehrliche Frage stellen. Nicht "wollen wir WIP-Limits einführen", darauf sagt spontan keiner ja. Sondern: wie viele Tickets haben wir gerade offen, und wie viele schließen wir pro Woche ab? Die zweite Zahl kennt meistens jemand. Die erste erschreckt.

Und dann der Teil, den der Simulator nicht kann. Er hat keine Meetings, keine Prioritätswechsel von außen, keine Tickets, die drei Tage beim Kunden liegen. Er zeigt die Physik, nicht deinen Alltag. Wenn jemand im Workshop sagt, bei euch sei das komplizierter, hat er recht, und die Diskussion darüber ist meistens produktiver als jede Folie zum Thema.

Was du morgen machst

Schreib zwei Zahlen an das Board: offene Tickets und abgeschlossene Tickets der letzten Woche. Teile die erste durch die zweite. Das Ergebnis ist deine durchschnittliche Cycle Time in Wochen, und du hast sie noch nie so genau gesehen.

Dann setz ein Limit. Wenn es beim ersten Versuch nicht unangenehm ist, ist es zu hoch.

Simulator öffnen oder erst die Theorie lesen.

Tiefer im Thema: NBA48 – WiP Limits Deep Dive und NBA66 zur Flow-Messung in agilen Teams. Warum das Tool WipIt! heißt und woran es sich abarbeitet, steht in Warum dein Team nicht langsam ist, sondern überladen.