Warum am Freitag nichts fertig ist, obwohl du die ganze Woche gearbeitet hast

Freitagnachmittag, das Board ist voll. Sieben Karten stehen in "In Progress", auf vier davon klebt dein Avatar. Du hast die Woche durchgearbeitet, keine Stunde vertrödelt, zwei Reviews gemacht, einen Produktionsbug gefixt und an drei Features weitergebaut. Fertig geworden ist nichts. Am Montag fragt jemand im Daily, warum das Feature aus Sprint 12 immer noch offen ist, und du hörst dich sagen:

"Ich war zwischendurch an was anderem dran."

Dieses Gespräch führen Teams jede Woche, und es führt jedes Mal zur selben Schlussfolgerung. Das Team ist zu langsam. Vielleicht braucht es mehr Leute. Vielleicht bessere Tools. Vielleicht muss jemand mal was zum Fokus sagen.

Die Schlussfolgerung ist falsch, und zwar nicht ein bisschen daneben, sondern grundsätzlich. Ihr seid nicht langsam. Ihr habt zu viel gleichzeitig offen. Das sind zwei völlig verschiedene Probleme mit zwei völlig verschiedenen Lösungen, und solange ihr das erste behandelt, wird das zweite schlimmer.

Das Missverständnis heißt Auslastung

Fast jede Organisation optimiert darauf, dass alle beschäftigt sind. Das fühlt sich richtig an. Niemand sitzt herum, alle Kapazität ist verplant, das Board ist voll. Wenn jemand mit einer Aufgabe wartet, weil das Review noch aussteht, greift er sich eben die nächste. Klingt vernünftig.

Der Satz, an dem du merkst, dass diese Logik am Werk ist, lautet: "Fang schon mal an, damit wir keine Zeit verlieren." Er ist gut gemeint und richtet mehr Schaden an als fast jede andere Entscheidung im Prozess. Jede Karte, die auf euer Board kommt, bevor eine andere fertig ist, verlängert die Wartezeit für alles, was schon drin ist. Nicht ein bisschen. Proportional.

Der Grund dafür ist, dass ein Ticket den allergrößten Teil seiner Lebenszeit nicht bearbeitet wird, sondern wartet. Es wartet auf ein Review, auf eine Antwort vom Fachbereich, auf QA, auf ein Deployment-Fenster, darauf, dass du von dem anderen Ticket zurückkommst. Wenn du misst, wie viel Zeit tatsächlich jemand aktiv an einer Karte arbeitet, landest du in den meisten Teams bei zehn bis zwanzig Prozent. Der Rest ist Liegezeit.

Deine persönliche Auslastung sagt über diese Liegezeit nichts aus. Du kannst zu hundert Prozent ausgelastet sein und trotzdem dafür sorgen, dass alles länger dauert. Genau das passiert gerade.

Wenn du mir nicht glaubst, dann schau gerne mal in die kleine Simulation "Flow Physics", die ich genau dafür gebaut habe.

Es gibt eine Formel dafür, und sie ist keine Metapher

Little's Law beschreibt den Zusammenhang zwischen drei Größen, und zwar nicht als Erfahrungswert, sondern als mathematische Notwendigkeit. Die Durchlaufzeit einer Karte ergibt sich aus der Menge gleichzeitig offener Arbeit geteilt durch den Durchsatz. Also: Cycle Time = WIP ÷ Throughput.

Setz deine eigenen Zahlen ein. Angenommen, ihr schließt im Schnitt zehn Tickets pro Woche ab, und es sind gleichzeitig vierzig offen. Dann braucht jedes Ticket im Mittel vier Wochen, vom Start bis zur Auslieferung. Nicht weil ihr langsam arbeitet, sondern weil vierzig durch zehn vier ergibt.

Jetzt halbiere die offene Arbeit auf zwanzig, ohne sonst irgendetwas zu verändern. Keine neuen Leute, kein anderes Tooling, keine Überstunden, dieselben Menschen mit derselben Geschwindigkeit. Die Durchlaufzeit fällt auf zwei Wochen. Halbierst du noch einmal, sind es fünf Arbeitstage.

Das ist der Punkt, an dem die meisten misstrauisch werden, weil es nach einem Trick klingt. Ist es aber nicht. Die Formel sagt nichts darüber, wie viel Arbeit erledigt wird, sondern nur darüber, wie lange die einzelne Karte unterwegs ist. Ihr schafft nicht plötzlich mehr. Ihr wartet weniger, und dadurch kommt das Ergebnis früher an. Und weil weniger parallel läuft, fallen die Kontextwechsel weg, die dich jeden Tag zwanzig Minuten kosten, wenn du dich wieder in den Branch von vorgestern eindenkst. Der Durchsatz steigt also meistens sogar noch.

Warum das für dich als Entwickler wichtig ist

Weil WIP der einzige Hebel in diesem ganzen System ist, den du ziehen kannst, ohne jemanden um Erlaubnis zu fragen.

Die Architektur kannst du nicht über Nacht entkoppeln. Die Testabdeckung baust du nicht in einem Sprint auf. Ob deployt wird, wenn etwas fertig ist, oder alle zwei Wochen an einem Freitag, entscheidet nicht dein Team. Aber ob du das nächste Ticket anfängst, bevor das aktuelle durch ist, das entscheidest du. Und wenn ihr euch als Team darauf einigt, dass ihr das nicht mehr tut, braucht ihr dafür kein Mandat und kein Budget.

Wichtig ist, dass du dabei etwas aushalten musst, das sich zuerst falsch anfühlt. Wenn dein aktuelles Ticket im Review hängt und du nichts Neues anfängst, sitzt du da. Das sieht nach Leerlauf aus und fühlt sich auch so an. Der produktive Reflex wäre, das Review von jemand anderem zu übernehmen oder dem Kollegen beim Blocker zu helfen, statt eine neue Karte zu ziehen. Genau das ist gemeint, wenn von Fokus die Rede ist. Nicht härter arbeiten, sondern die Warteschlange kürzen, statt sie zu verlängern.

Was du am Montag machen kannst

Zähl im Daily, wie viele Karten wirklich in Arbeit sind, und zwar ehrlich, inklusive der Sachen, die seit drei Wochen auf "wartet auf Rückmeldung" stehen. Vergleich die Zahl mit der Anzahl der Menschen im Team. Wenn sie deutlich höher ist, hast du deinen Engpass gefunden, und er heißt nicht Kapazität.

Dann setzt ihr eine Obergrenze. Nicht die theoretisch richtige, sondern eine, die etwa der Teamgröße entspricht, und ihr haltet sie zwei Wochen lang durch. Wenn jemand eine neue Karte anfangen will und das Limit ist erreicht, hilft er stattdessen dabei, eine bestehende fertig zu bekommen. Das ist die ganze Regel.

Wenn du das vorher selbst sehen willst, statt es zu glauben, gibt es einen Simulator, in dem du den WIP-Regler bewegen und live beobachten kannst, wie Cycle Time und Warteschlangen reagieren. Ausführlicher habe ich das Thema in NBA48 besprochen.

Wo das herkommt

Zu viel gleichzeitige Arbeit ist kein isoliertes Ärgernis, sondern einer von sechs Engpässen, die dafür sorgen, dass ein Team nichts aus seiner eigenen Arbeit lernt. Der Gedanke dahinter ist die Work-Feedback Loop: Du leistest Arbeit, bekommst Feedback aus der Realität und passt die nächste Arbeit daran an. Wie agil ein Team ist, entscheidet sich daran, wie schnell und wie sicher diese Schleife läuft.

Große Batches verlangsamen sie an der teuersten Stelle. Solange vierzig Karten offen sind, dauert es vier Wochen, bis irgendetwas die Realität berührt, und bis dahin hat niemand erfahren, ob die Entscheidung von damals richtig war. Ihr arbeitet dann nicht langsam. Ihr lernt langsam. Das ist der Unterschied, um den es geht.