Rolling Waves, Vertical Slices und WIP-Limits

Agentische KI kann in Minuten mehr Arbeit beginnen, als ein Mensch in Stunden prüfen kann. Sie kann parallel recherchieren, schreiben, testen, Bilder erzeugen, Daten umformen, Code ändern und Folgeaufgaben an weitere Agenten delegieren. Genau darin liegt ihre Stärke – und eines ihrer größten Projektmanagement-Risiken.

Denn ein Projekt scheitert nicht nur daran, dass zu wenig passiert. Es kann genauso daran scheitern, dass zu viel gleichzeitig angefangen wird, dass ein langfristiger Plan mit Scheingenauigkeit überfrachtet wird oder dass erst sehr spät sichtbar wird, ob die vielen Einzelarbeiten überhaupt zu einem funktionierenden Ganzen passen.

Die entscheidende Frage lautet deshalb nicht: Wie viele Agenten können wir parallel beschäftigen?

Sie lautet: Wie schneiden wir Arbeit so, dass Lernen, Fertigstellung und Kontrolle schneller sind als die Erzeugung neuer Arbeit?

Drei Konzepte bilden dafür eine besonders starke Kombination:

Rolling Waves bestimmen, wie weit in die Zukunft wir detailliert planen.

Vertical Slices bestimmen, welchen vollständigen, testbaren Teil des Systems wir als Nächstes beweisen.

WIP-Limits bestimmen, wie viel Arbeit gleichzeitig begonnen, aber noch nicht abgeschlossen sein darf.

Zusammen entsteht eine Architektur für agentische Projekte, die weder auf Mikromanagement noch auf grenzenlose Autonomie angewiesen ist. Die KI darf schnell arbeiten. Aber die Projektgeometrie sorgt dafür, dass Geschwindigkeit nicht in unkontrollierte Breite kippt.

Das eigentliche Problem ist angefangene Arbeit

In klassischen Projekten war parallele Arbeit teuer. Neue Mitarbeitende mussten koordiniert werden, Zugänge erhalten, Briefings lesen und Termine finden. Bei agentischer KI sinken diese Startkosten drastisch. Ein weiterer Rechercheagent, ein zweiter Reviewer oder drei zusätzliche Varianten sind nur einen Befehl entfernt.

Damit verschiebt sich der Engpass.

Nicht das Starten von Arbeit ist knapp, sondern das Fertigstellen, Zusammenführen und Prüfen.

Das lässt sich an einer einfachen Situation erkennen. Ein Agent erhält die Aufgabe, für zwanzig Produkte jeweils drei Bildvarianten zu erzeugen. Aus einer scheinbar überschaubaren Aufgabe können durch Subagenten plötzlich Dutzende parallele Arbeitsstränge entstehen. Jeder Strang produziert Dateien, Entscheidungen, Statusmeldungen und Folgefragen. Selbst wenn technisch alles funktioniert, wächst die Review- und Integrationslast schneller als der reale Erkenntnisgewinn.

Agentische Projekte brauchen deshalb eine andere Grundregel als viele traditionelle Digitalprojekte:

Optimiere nicht die Zahl aktiver Agenten. Optimiere den Fluss abgeschlossener, überprüfbarer Arbeit.

Das ist der Hintergrund, vor dem Rolling Waves, Vertical Slices und WIP-Limits ihre eigentliche Bedeutung erhalten.

Drei Werkzeuge - drei verschiedene Probleme

Die drei Konzepte werden leicht vermischt, obwohl sie unterschiedliche Steuerungsprobleme lösen.

Ein Projekt kann bei einem dieser Punkte gut und bei den anderen schlecht aufgestellt sein.

Ein Team kann zum Beispiel sauber in Rolling Waves planen, aber jede Welle mit zehn parallelen Agenten überladen. Oder es kann ein hartes WIP-Limit besitzen, aber nur horizontale Teilstücke produzieren, die einzeln gut aussehen und zusammen trotzdem nicht funktionieren. Oder es kann einen hervorragenden Vertical Slice bauen, danach aber wieder sechs Monate im Voraus bis auf Task-Ebene planen und damit eine Scheingenauigkeit erzeugen, die beim ersten neuen Befund zerfällt.

Die Wirkung entsteht erst durch die Kombination.

Rolling Waves: Nicht weniger planen, sondern dort genauer planen, wo Wissen vorhanden ist

Rolling Wave Planning ist keine Ausrede für fehlende Planung. Es ist das Gegenteil: eine disziplinierte Antwort auf Unsicherheit.

Die Grundidee ist einfach. Die nahe Zukunft wird detailliert geplant. Weiter entfernte Arbeit bleibt gröber beschrieben und wird erst dann verfeinert, wenn genügend neues Wissen vorhanden ist.

Dadurch entstehen unterschiedliche Planungshorizonte:

1. Projektbild: Was ist das Ziel, was gehört ausdrücklich nicht dazu, welche Wirkung soll entstehen?

2. Mittlerer Horizont: Welche größeren Ergebnisbereiche, Meilensteine oder Planungspakete sind wahrscheinlich notwendig?

3. Aktuelle Welle: Welche konkreten Work-Packages werden jetzt bearbeitet?

4. Nächster Zug: Welche unmittelbar nächste Aktion ist freigegeben und ausführbar?

Die Fehlerquelle vieler KI-Projektpläne ist, dass alle vier Ebenen gleichzeitig mit maximalem Detail gefüllt werden. Die KI kann in Sekunden einen 90-Tage-Plan mit Hunderten Tasks, Rollen, Fristen und Abhängigkeiten erzeugen. Formal sieht das beeindruckend aus. Inhaltlich basiert ein großer Teil dieser Detailtiefe aber auf Annahmen, die noch gar nicht getestet wurden.

Die Folge ist Planungsillusion: Ein Dokument sieht präzise aus, ohne dass die Realität bereits präzise genug wäre.

Rolling Waves akzeptieren, dass ein Projekt am Anfang weniger weiß als später. Sie machen diese Unsicherheit sichtbar, statt sie mit Tabellen zu kaschieren.

Der Detailhorizont ist eine Steuerungsvariable

Die entscheidende Frage lautet deshalb nicht nur: Was planen wir? Sondern auch: Bis wohin planen wir detailliert?

Ein sinnvoller Detailhorizont hängt unter anderem ab von technischer Unsicherheit, Änderungswahrscheinlichkeit, Verfügbarkeit von Evidenz, Abhängigkeiten zu externen Systemen, Kosten einer Fehlplanung, Geschwindigkeit, mit der neue Informationen entstehen, und der Reversibilität kommender Entscheidungen.

Bei einem stabilen, wiederholbaren Prozess kann der detaillierte Horizont relativ weit reichen. Bei einem experimentellen agentischen Prototyp kann bereits die nächste Woche zu weit sein.

Das ist kein Zeichen schlechter Projektführung. Es ist eine bewusste Kalibrierung der Planungsauflösung.

Je unsicherer die Zukunft, desto gröber darf ihre Planung sein – solange klar definiert ist, wann und wodurch sie verfeinert wird.

Progressive Elaborierung braucht feste Trigger

Rolling Waves funktionieren nur, wenn aus „später planen" nicht „nie planen" wird.

Deshalb braucht jede zukünftige Planungseinheit einen Auslöser für die Verfeinerung: ein Prototyp ist getestet, ein Slice erreicht die Definition of Done, eine zentrale Annahme wurde bestätigt oder widerlegt, ein Kostenrahmen ist geklärt, eine Schnittstelle ist technisch verifiziert, ein externer Stakeholder hat entschieden, oder eine Risikoschwelle wurde unterschritten.

So wird die nächste Welle nicht nach Kalenderreflex geplant, sondern auf Basis von neuem Wissen.

Ein nützlicher Wave-Review fragt daher:

1. Was haben wir seit der letzten Planung gelernt?

2. Welche Annahmen sind jetzt falsch oder unsicherer als zuvor?

3. Welche Planungspakete können wir nun sinnvoll zerlegen?

4. Was sollte bewusst noch grob bleiben?

5. Welche Arbeit wird aus der nächsten Welle entfernt, nicht nur hinzugefügt?

Gerade Punkt fünf ist wichtig. Agentische Systeme sind sehr gut darin, neue Optimierungsideen zu erzeugen. Reife Planung muss deshalb genauso gut im Nicht-Tun werden.

Vertical Slices: Nicht Schicht für Schicht, sondern Wirkung Ende zu Ende beweisen

Rolling Waves strukturieren Zeit. Vertical Slices strukturieren den Beweis.

Ein Vertical Slice ist ein kleiner, aber funktionierender End-to-End-Ausschnitt eines größeren Systems. Er soll nicht alles können. Er soll zeigen, dass der Kernpfad tatsächlich funktioniert.

Das unterscheidet ihn von horizontaler Zerlegung.

Angenommen, ein Team baut einen KI-gestützten Beratungsworkflow. Eine horizontale Zerlegung könnte so aussehen: Woche 1 Datenmodell, Woche 2 Promptbibliothek, Woche 3 Benutzeroberfläche, Woche 4 Reviewer-Logik, Woche 5 Export, Woche 6 alles verbinden.

Jede einzelne Schicht kann Fortschritt melden. Trotzdem weiß das Team fünf Wochen lang nicht, ob der Gesamtfluss trägt.

Ein Vertical Slice würde stattdessen einen sehr kleinen End-to-End-Pfad bauen:

eine reale Anfrage → definierter Input → KI-Ausarbeitung → Review → sichtbares Ergebnis → Export.

Vielleicht funktioniert dieser Slice nur für einen einzigen Use Case. Das ist in Ordnung. Sein Wert liegt nicht in Breite, sondern in Tragfähigkeitsbeweis.

Der Slice ist eine Hypothese in ausführbarer Form

Ein guter Vertical Slice beantwortet nicht nur „Funktioniert der Code?". Er prüft eine Projekthypothese.

Zum Beispiel:

Wenn wir diesen vollständigen Kernablauf mit realistischem Input durchführen, können wir innerhalb des vorgesehenen Qualitäts-, Zeit- und Kostenrahmens ein nutzbares Ergebnis erzeugen.

Damit wird der Slice zum Lerninstrument.

Er kann technische Fragen beantworten: Kann die Schnittstelle zuverlässig angesprochen werden? Reicht die Modellqualität? Funktioniert der Export?

Er kann aber auch organisatorische Fragen beantworten: Ist der Reviewaufwand tragbar? Versteht der Mensch den Output? Entsteht zu viel Nacharbeit? Ist der Ablauf für reale Nutzer plausibel?

Und wirtschaftliche Fragen: Wie hoch sind echte Laufzeit- und Tokenkosten? Wie viel menschliche Zeit bleibt notwendig? Ist der Nutzen groß genug, um weitere Entwicklung zu rechtfertigen?

Ein Slice sollte deshalb nicht als „Mini-Version des ganzen Backlogs" verstanden werden. Er ist ein gezieltes Experiment mit End-to-End-Verantwortung.

Ein Slice-Vertrag verhindert Mini-Monolithen

Auch Vertical Slices können ausufern. Aus „wir testen einen Kernablauf" wird schnell „wenn wir schon dabei sind, bauen wir noch Login, Dashboard, Analytics und drei Rollenmodelle".

Dagegen hilft ein Slice-Vertrag.

Der wichtigste Eintrag ist oft Non-Scope. Ohne ihn wird ein Vertical Slice schnell zu einem vollständigen Produkt im Kleinformat – und verliert seine Lernfunktion.

Die richtige Slice-Größe liegt zwischen trivial und unprüfbar

Ein Slice kann zu klein sein.

Wenn er nur beweist, dass ein Agent Text erzeugen kann, lernen wir wenig. Die eigentlichen Integrationsrisiken bleiben verborgen.

Er kann aber auch zu groß sein.

Wenn der Slice sechs Wochen, zwölf Tools und fünfzig Unteraufgaben benötigt, erfahren wir sehr spät, welche Annahme zuerst gescheitert ist.

Eine gute Slice-Größe maximiert deshalb nicht die Menge fertiger Features, sondern das Verhältnis aus Lerngewinn zu Aufwand.

Hilfreiche Fragen sind: Welche größte Unsicherheit können wir mit einem kleinen End-to-End-Pfad sichtbar machen? Welche Schnittstelle könnte das Projekt später blockieren? Welche Annahme wäre teuer, wenn wir sie erst in drei Monaten widerlegen? Welche minimale Nutzerwirkung können wir real beobachten? Welche Entscheidung können wir nach diesem Slice besser treffen als davor?

So wird Zerlegung zu Erkenntnisdesign.

WIP-Limits: Begonnene Arbeit ist ein Bestand

Vertical Slices sagen, was wir beweisen. WIP-Limits bestimmen, wie viel davon gleichzeitig offen sein darf.

WIP steht für Work in Progress – Arbeit, die begonnen, aber noch nicht fertig ist.

In Wissensarbeit ist angefangene Arbeit leicht unsichtbar. Sie liegt in offenen Browser-Tabs, Agentenläufen, Branches, Chats, Reviewqueues, Entwurfsdateien und halbfertigen Analysen. Agentische Systeme vergrößern dieses Problem, weil sie neue Arbeit sehr schnell erzeugen können.

Ein WIP-Limit macht daraus eine explizite Kapazitätsentscheidung.

Beispiel: maximal 2 aktive Slices, maximal 3 offene Recherchepakete, maximal 1 unreleaster technischer Branch, maximal 4 Ergebnisse gleichzeitig im Review, maximal 2 parallele Agentenläufe mit externen Toolrechten.

Die konkreten Zahlen sind kontextabhängig. Die Logik ist allgemeiner:

Neue Arbeit wird erst gezogen, wenn reale Kapazität frei wird.

Das ist der Unterschied zwischen Pull und Push.

WIP ist mehr als die Zahl laufender Agenten

In agentischen Projekten wäre es zu einfach, nur die Zahl aktiver Agenten zu begrenzen.

Denn ein einzelner Agent kann zehn offene Unteraufgaben erzeugen. Umgekehrt können fünf Agenten gemeinsam an einem einzigen klar begrenzten Slice arbeiten.

WIP sollte deshalb auf mehreren Ebenen betrachtet werden:

Diese Sicht verhindert einen verbreiteten Denkfehler: Ein Team senkt die Zahl aktiver Agenten, lässt aber gleichzeitig zwanzig offene Arbeitspakete im System liegen. Der Engpass bleibt bestehen.

Der WIP-Limit-Test: Kann das System alles Offene wirklich abschließen?

Ein brauchbares WIP-Limit orientiert sich nicht daran, wie viel Arbeit gestartet werden kann, sondern wie viel Arbeit zuverlässig beendet werden kann.

Dafür sind fünf Fragen besonders nützlich:

1. Wie viele Ergebnisse können wir pro Zeiteinheit ernsthaft reviewen?

2. Wie viele parallele Stränge können wir noch konsistent im Projektzustand halten?

3. Wie viele offene Abhängigkeiten können wir koordinieren, ohne ständig umzuschalten?

4. Wie viel Kosten- und Tokenverbrauch akzeptieren wir gleichzeitig?

5. Wie schnell erkennen wir, wenn ein Strang blockiert oder sinnlos geworden ist?

Wenn die Antwort auf eine dieser Fragen „nicht zuverlässig" lautet, ist der aktuelle WIP wahrscheinlich zu hoch.

Kontrollierte Parallelität ist nicht dasselbe wie maximale Parallelität

Parallelität bleibt wichtig. Vier unabhängige Quellenrecherchen können sinnvoll gleichzeitig laufen. Zwei voneinander unabhängige Testvarianten ebenso.

Problematisch wird Parallelität, wenn Arbeit nur scheinbar unabhängig ist.

Typische versteckte Kopplungen sind: alle Agenten benötigen dieselbe instabile Baseline, mehrere Stränge schreiben in dieselben Dateien, alle Ergebnisse müssen von derselben Person geprüft werden, ein späterer Merge benötigt Informationen, die unterwegs verloren gehen, eine Entscheidung in Strang A ändert die Annahmen von Strang B, oder alle Agenten verbrauchen denselben begrenzten Tool- oder Tokenpool.

Kontrollierte Parallelität beginnt deshalb mit einer Abhängigkeitsfrage:

Welche Arbeit kann wirklich unabhängig fertig werden – und welche erzeugt nur parallele Warteschlangen?

Das Ziel ist nicht, alle Ressourcen auszulasten. Das Ziel ist, den Gesamtfluss zu verbessern.

Auslastung ist kein Erfolgsmaß

Dieser Punkt wirkt zunächst kontraintuitiv. Wenn Agenten billig und verfügbar sind, warum sollten sie nicht permanent beschäftigt werden?

Weil maximale Auslastung häufig zu maximalen Warteschlangen führt.

Ein Projekt, in dem jeder Agent immer etwas Neues beginnt, erzeugt schnell: mehr offene Ergebnisse, mehr Reviewbedarf, mehr Kontextwechsel, mehr Konflikte beim Zusammenführen, mehr veraltete Zwischenstände, und mehr Arbeit, deren Nutzen niemand mehr priorisiert.

Agentische Produktivität sollte deshalb nicht an „Agentenstunden" oder „Anzahl erzeugter Artefakte" gemessen werden.

Bessere Fragen sind: Wie viele wertvolle Work-Items werden wirklich abgeschlossen? Wie lange liegen angefangene Items offen? Wie viel Nacharbeit entsteht? Wie viele Ergebnisse werden verworfen, bevor sie genutzt werden? Wie schnell erreichen wir die nächste belastbare Projektentscheidung?

Finish more. Start less.

Das klingt unspektakulär. In agentischen Systemen ist es eine radikale Steuerungsregel.

Work-Packages müssen menschenlesbar enden

Ein weiterer Vorteil kleiner Arbeitspakete ist die Verständlichkeit.

Wenn ein Agent über Stunden autonom arbeitet und am Ende nur einen riesigen Endzustand präsentiert, entsteht ein Prüfproblem. Der Mensch sieht zwar das Ergebnis, aber nicht mehr zuverlässig, welche Annahmen, Änderungen und Entscheidungen dorthin geführt haben.

Deshalb sollte jedes relevante Work-Package mit einem kurzen Abschlussreport enden.

Ein solcher Report kann enthalten: Ziel des Pakets, ausgeführte Arbeit, erzeugte oder geänderte Artefakte, wichtigste Ergebnisse, offene Unsicherheiten, Abweichungen vom Plan, blockierte Punkte, Kosten oder Laufzeit, empfohlene nächste Aktion, und die Frage, ob das Paket wirklich „Done" ist.