Scrum hat eine bestimmte Welt vorausgesetzt: ein Team aus Entwicklerinnen und Entwicklern, die gemeinsam Code schreiben, sich abstimmen müssen, Schätzungen abgeben und in zweiwöchigen Iterationen liefern. Das war kein Zufall, sondern eine kluge Antwort auf reale Engpässe, vor allem den Engpass menschlicher Synchronisation. Wenn fünf Leute am selben System arbeiten, brauchst du Rituale, die geteiltes Verständnis herstellen. Daily Standup, Backlog Refinement, Sprint Planning, Retrospektive: jedes dieser Meetings ist eine Antwort auf eine Frage, die menschliche Teams nun einmal beantworten müssen.

Die Frage ist: Was passiert mit diesen Antworten, wenn sich die Fragen ändern?

Die Annahmen, die nicht mehr halten

Wer heute konsequent mit KI-Assistenten entwickelt, merkt schnell, dass mehrere Grundannahmen von Scrum erodieren. Die Implementierung, also das eigentliche Tippen von Code, ist nicht mehr der zeitaufwendige Teil. Die Durchlaufzeit von einer klaren Spezifikation zu lauffähigem Code schrumpft von Tagen auf Stunden, manchmal auf Minuten. Eine zweiwöchige Iteration als Planungseinheit ergibt in dieser Welt wenig Sinn. Sie ist nicht falsch, sie ist nur grobkörnig geworden.

Auch das Daily verliert seinen ursprünglichen Zweck. Es war erfunden, um zu synchronisieren, was menschliche Teammitglieder über Nacht parallel getan oder gedacht haben. Wenn die Synchronisation aber über Pull Requests, Pipelines und Telemetrie läuft, kontinuierlich, automatisiert, lesbar, dann ist das morgendliche Stand-up redundant. Das gilt analog für Backlog-Refinement-Meetings: Die Aufbereitung von Anforderungen lässt sich heute weitgehend im Dialog mit der KI selbst leisten, asynchron, ohne Kalenderslot.

Was bleibt, ist die Inspektion, aber nicht im klassischen Sinn als Retrospektive alle zwei Wochen, sondern als kontinuierliche Auswertung dessen, was die Maschine produziert hat.

Das Manifest gilt weiter, Scrum nicht zwingend

An dieser Stelle ist eine Unterscheidung wichtig, die in der Diskussion oft verloren geht: Scrum ist nicht agil. Scrum ist eine Implementierung agiler Prinzipien für eine bestimmte Welt. Wenn ich also sage, dass Scrum nicht mehr passt, sage ich nichts gegen das Agile Manifest. Im Gegenteil: die vier Werte und die zwölf Prinzipien scheinen mir in der KI-gestützten Entwicklung relevanter zu sein als je zuvor.

„Individuen und Interaktionen mehr als Prozesse und Werkzeuge“. Das wird gerade jetzt entscheidend, wo die Werkzeuge mächtiger werden. Die Qualität eines KI-gestützten Entwicklungsprozesses hängt mehr denn je davon ab, wie gut Menschen miteinander und mit den Modellen interagieren, nicht davon, wie streng der Prozess eingehalten wird.

„Funktionierende Software mehr als umfassende Dokumentation“. Continuous Delivery ist die radikale Einlösung dieses Prinzips. Wenn ich mehrmals täglich produktiv deployen kann, ist die laufende Software selbst zur Dokumentation des Fortschritts geworden.

„Reagieren auf Veränderung mehr als das Befolgen eines Plans“. Ein zweiwöchiger Sprint-Plan ist in einer Welt, in der sich Anforderungen schneller umsetzen lassen als planen, fast schon das Gegenteil von Agilität. Er wird zur Bremse für genau die Anpassungsfähigkeit, die er eigentlich ermöglichen sollte.

Auch die zwölf Prinzipien tragen weiter. „Liefere funktionierende Software regelmäßig, innerhalb weniger Wochen oder Monate, mit Bevorzugung der kürzeren Zeitspanne“. Das war 2001 ambitioniert. Heute ist die kürzere Zeitspanne nicht mehr zwei Wochen, sondern zwei Stunden. Das Prinzip bleibt, nur die Größenordnung verschiebt sich.

„Einfachheit, die Kunst, die Menge nicht getaner Arbeit zu maximieren, ist essenziell.“ Gerade bei KI-generiertem Code, der schnell und in Mengen entsteht, wird dieses Prinzip zur Überlebensfrage. Ohne disziplinierte Reduktion produziert man in atemberaubendem Tempo technische Schulden.

Und „in regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an“. Das bleibt der Kern. Nur dass „regelmäßig“ eben nicht mehr alle zwei Wochen im Retro-Meeting bedeutet, sondern in einem Takt, der zum tatsächlichen Arbeitsfluss passt.

Mit anderen Worten: Das Manifest war nie an Scrum gebunden. Scrum war eine Antwort auf die Frage, wie man agil arbeitet, wenn die Realität so aussieht, wie sie 2001 aussah. Eine andere Realität braucht andere Antworten auf dieselben Fragen.

Was sich verschiebt, statt zu verschwinden

Es wäre verkürzt zu sagen, dass die Entwicklerrolle einfach wegfällt. Was wegfällt, ist die Tätigkeit des Code-Tippens als Hauptaufgabe. Was bleibt und an Bedeutung gewinnt, sind Spezifikation, Review, Architekturentscheidungen und Verifikation. Wer KI-generierten Code unkritisch übernimmt, baut sich Probleme ein, die später teuer werden. Das Vier-Augen-Prinzip mit unterschiedlichen Modellen ist nicht nur eine nette Praxis, sondern wird zur Notwendigkeit: verschiedene Modelle haben verschiedene blinde Flecken, und der Mensch dazwischen ist derjenige, der die Diskrepanzen interpretiert.

Auch der Product Owner verschwindet nicht, im Gegenteil. Wenn die KI sehr schnell sehr Falsches bauen kann, wird die Qualität der Spezifikation zum neuen Engpass. Wer unscharf beschreibt, bekommt unscharfen Code, nur eben in höherem Tempo. Das macht produktorientiertes Denken wichtiger, nicht unwichtiger.

Der Scrum Master ist die Rolle, deren Zukunft am offensten ist. Wenn die Rituale wegfallen, für deren Hüter sie ursprünglich gedacht war, muss sich diese Rolle entweder neu erfinden, etwa als Verantwortliche für Workflow-Architektur und Tool-Integration, oder sie löst sich auf.

Wie könnte ein Nachfolger aussehen?

Ich habe keinen fertigen Vorschlag, und ich misstraue allen, die jetzt schon ein neues Framework verkaufen wollen. Aber ein paar Konturen lassen sich erahnen.

Der Takt verschiebt sich von Iteration zu Fluss. Continuous Integration und Continuous Delivery sind dann nicht mehr eine Praxis innerhalb eines übergeordneten Prozesses, sondern der Prozess selbst. Was gestern als Sprint-Ende mit Demo gefeiert wurde, ist morgen ein Deployment unter vielen.

Die Teamzusammensetzung wird kleiner und anders gemischt. Statt fünf bis neun Entwickler vielleicht zwei oder drei Menschen, die zwischen Spezifikation, Review und Architekturarbeit wechseln, plus die Modelle, mit denen sie arbeiten. Rollen wie „QA-Engineer für KI-generierten Code“ oder „Prompt- und Spezifikationsverantwortliche“ zeichnen sich ab, ohne dass es schon eingebürgerte Bezeichnungen gäbe.

Und schließlich braucht es neue Formen der Inspektion. Die Retrospektive im klassischen Sinn ergibt weniger Sinn, wenn der Zyklus nicht zwei Wochen, sondern zwei Stunden lang ist. Aber die Frage, was gut funktioniert und was nicht, bleibt. Sie wird nur datengetriebener beantwortet, näher an Telemetrie und Code-Qualitätsmetriken als an Post-its an einer Wand.

Offene Fragen

Vieles davon ist Beobachtung, nicht Lehrsatz. Bleibt das Daily wirklich überflüssig, oder erfindet es sich als Sync zwischen menschlichen Reviewern neu? Wie steuert man Teams, in denen die produktivste „Kollegin“ ein Modell ist, das morgen ersetzt werden kann? Wer trägt Verantwortung, wenn der Code von einer KI stammt: die Reviewerin, der PO, das Unternehmen?

Ich weiß die Antworten nicht. Was ich weiß: Die Praxis ist der Theorie gerade voraus. Wer heute mit KI entwickelt, merkt im Alltag, dass Scrum nicht mehr passt, lange bevor das nächste Framework geschrieben sein wird. Das Manifest aber, scheint mir, wird uns dabei helfen, die Richtung zu finden.

13:01