Solange etwas WIP ist, ist es kein ROI.
Es gibt diesen Moment in jedem Teammeeting. Das Board ist voll. Überall Karten. Überall Bewegung. Jemand sagt stolz: „Wir haben gerade 42 Dinge in Arbeit.“ Und alle nicken.
Ich nicke nicht mehr.
42 Dinge in Arbeit bedeutet: 42 Dinge, die noch keinen Wert geliefert haben. 42 Versprechen, die noch nicht eingelöst wurden. 42 halbfertige Ideen, die Aufmerksamkeit fressen, Koordination kosten, und — das ist der entscheidende Punkt — deinem Kunden noch keinen einzigen Franken wert sind.
WIP ist kein Fortschritt. WIP ist Illusion.
Der Valuestream lügt nicht
Stell dir einen Fluss vor. Oben rein fliesst Arbeit. Unten raus fliesst Wert — also das, wofür dein Kunde bereit ist zu zahlen. Alles, was in der Mitte steckt, ist kein ROI. Es ist Wasser, das nicht fliesst.
Und Wasser, das nicht fliesst, wird irgendwann stinkig.
Ein Feature, das zu 80% fertig ist, hat einen ROI von 0. Nicht von 80%. Von null. Kein Kunde zahlt für „fast fertig“. Kein Nutzer profitiert von „läuft bald“. Die letzten 20% sind nicht das Problem — das Problem ist, dass du die ersten 80% investiert hast, ohne auch nur einen Franken zurückzubekommen.
while (WIP) { ROI = 0; } ist keine Metapher. Das ist Buchhaltung.
Warum aus WIP nie ROI wird — eine ehrliche Liste
Goldplating. Das Feature ist „eigentlich fertig“, aber dann fällt jemandem noch etwas ein. Und noch etwas. Und plötzlich ist aus einer einfachen Lösung ein Architektenwunder geworden, das niemand bestellt hat. Der Kunde wollte einen Schalter. Ihr baut ein Cockpit.
Multitasking-Theater. Alle sind beschäftigt, niemand ist fertig. Jeder jongliert fünf Bälle. Fünf Bälle in der Luft sind beeindruckend anzuschauen — aber kein Ball landet. Und am Ende des Sprints schaut man sich an und fragt sich, warum wieder nichts deployed wurde.
Der endlose Review-Loop. Fertig? Fast. Nur noch schnell durch’s Approval. Dann durch den nächsten. Dann warten auf Feedback. Dann Feedback einarbeiten. Dann nochmals reviewen. Das Feature altert im Staging-System, während der Markt weiterzieht.
Priorisierungsangst. „Wir können noch nicht deployen, es fehlt noch Feature X.“ Warum? „Weil der Stakeholder das erwartet.“ Hat der Stakeholder das gesagt? „Nicht direkt, aber…“ Und schon hat das Bauchgefühl eines Meetings dein Deployment um drei Wochen verschoben.
Das halbfertige Feature als Sicherheitsnetz. Solange es nicht fertig ist, kann es auch nicht scheitern. WIP ist manchmal kein Organisations-problem — es ist ein psychologisches. Wer nie deployed, wird nie enttäuscht. Und wer nie enttäuscht wird, lernt auch nie.
Was ihr stattdessen nicht tut
Hier ist das, worüber niemand redet, wenn das Board voll ist.
Während ihr 42 Dinge gleichzeitig halb fertig habt, liegt etwas anderes brach. Etwas, das keine Karte auf dem Board hat, weil es nie dringend genug war um angefangen zu werden — aber wichtig genug, um euch jeden Monat ein bisschen langsamer zu machen.
Eure technische Schuld. Die wächst still. Jeder weiss, wo die Problemstellen sind. Jeder hat sie im Hinterkopf. Und jeder schiebt sie vor sich her, weil „gerade kein Platz ist“. Der Platz ist aber nie da, wenn das System immer voll läuft.
Oder KI. Euer Team spürt, dass sich gerade etwas fundamental verändert — wie Teams arbeiten, wie Wissen verarbeitet wird, wie schnell man von Idee zu Ergebnis kommt. Aber ihr habt nie die Ruhe gehabt, euch als Team hinzusetzen und ernsthaft zu fragen: Was bedeutet das für uns? Wie machen wir das nutzbar? Nicht als Hype, sondern als Werkzeug, das uns wirklich schneller macht.
Das ist das eigentliche Paradox von zu viel WIP: Ihr seid zu beschäftigt damit, langsam zu sein, um schneller zu werden.
Ein System das nie Luft hat, kann sich nicht verbessern. Es kann nur reagieren. Und Organisationen die nur reagieren, werden irgendwann von denen überholt, die sich die Zeit genommen haben, ihr System zu verbessern — weil die nämlich mal fünf Dinge fertig gemacht haben, anstatt fünfundzwanzig anzufangen.
10x deployen schlägt 1x perfektionieren
Hier ist das Gegenbild. Nicht das grosse Release nach sechs Monaten Arbeit, auf das alle gewartet haben und das dann — trotz allem — nicht ganz passt. Sondern zehn kleine Deployments, jedes ein Lernmoment, jedes ein Rückfluss, jedes eine Chance, den nächsten Schritt besser zu machen.
Das erste Deployment bringt dir Feedback, das du nicht antizipiert hattest. Das zweite zeigt dir, was die Nutzer wirklich brauchen. Das dritte ist bereits besser als das, was du nach sechs Monaten gebaut hättest — weil du jetzt weisst, was zählt.
Wer früh deployed, lernt früh. Wer früh lernt, baut das Richtige. Wer das Richtige baut, hat ROI.
Der Rest hat WIP.
An alle Coaches, POs und SMs da draussen
Ja, ich meine euch.
Ihr sitzt in diesem Meeting. Ihr seht das Board. Ihr wisst, was „42 Dinge in Arbeit“ bedeutet. Und trotzdem sagt ihr nichts — oder ihr habt es gesagt, aber es hat niemanden interessiert.
Hier sind drei Fragen, die ich euch für diese Woche mitgebe:
Was ist das älteste WIP-Item auf eurem Board — und warum ist es noch nicht fertig? Schaut es euch an. Wirklich anschauen. Nicht „wir arbeiten dran“, sondern: Was hält es auf? Was muss weg, damit es durchfliesst?
Was wäre, wenn ihr morgen deployen müsstet — was wäre dann wirklich fertig? Alles andere ist kein WIP. Es ist ein Wunsch.
Wann habt ihr das letzte Mal nein gesagt zu einer neuen Anfrage, weil zuerst etwas abgeschlossen werden muss? Wenn euch keine Antwort einfällt, habt ihr euer WIP-Limit gefunden. Es ist: unendlich.
Finishen ist eine Haltung. Nicht ein Zufall.
Euer Board wird nicht kürzer, weil ihr mehr anfangt. Es wird kürzer, weil ihr aufhört anzufangen — und anfangt, fertig zu werden.
while (WIP) { ROI = 0; } lässt sich nur auf eine Art auflösen: den Loop beenden.
Deploy. Lernen. Wiederholen.
Ruedi Gysi ist Senior Agile Coach bei Wertwandler GmbH. Er schreibt über Flow, Führung und funktionierende Organisationen auf agile-reflection.org.
Ein Kommentar zu „while (WIP) { ROI = 0; }“
Die Kommentare sind geschlossen.