Warum Scrum in der KI-Ära an sein eigentliches Ende kommt

Scrum wurde nie erfunden, weil kleine Schritte schön sind.

Es wurde erfunden, weil Menschen sich nicht schnell genug abstimmen können. Sprints, Standups, Story Points, Retros — das ist fast ausschließlich Maschinerie gegen ein einziges Problem: begrenzte Kommunikationsbandbreite zwischen Menschen. Wer in einem Team von acht Leuten arbeitet, kennt das Muster: Die Zahl der Abstimmungswege wächst nicht mit der Teamgröße, sie wächst schneller. Jede zusätzliche Person bedeutet nicht eine zusätzliche Verbindung, sondern mehrere. Scrum ist eine sehr durchdachte Antwort auf genau dieses Wachstum.

Jetzt kommt der Teil, den kaum jemand offen ausspricht: Dieses Problem verschwindet gerade, in dem Ausmaß, in dem ein wachsender Teil der Umsetzung von KI-Agenten übernommen wird. Ein Dialog zwischen zwei KI-Instanzen braucht keine Sprint-Grenze. Keine Kapazitätsschätzung. Keinen Standup, um herauszufinden, wer woran arbeitet. Die Kommunikationsbandbreite, die bei Menschen die eigentliche Engstelle war, ist bei KI-Agenten schlicht keine Engstelle mehr.

Zwei Probleme, die nie sauber getrennt wurden

Heißt das, Scrum ist tot? Nein — und genau hier wird die Sache interessant, wenn man genauer hinschaut.

Scrum hat nämlich zwei komplett unterschiedliche Probleme gleichzeitig gelöst, die in der Praxis so gut wie nie getrennt betrachtet wurden:

Erstens: Koordination zwischen Menschen. Wie stimmt man mehrere Personen so aufeinander ab, dass ihre einzelnen Arbeitsergebnisse am Ende zusammenpassen? Das ist das Problem, das gerade verschwindet.

Zweitens: Unsicherheit über echte Anforderungen. Weiß man zu Beginn eines Projekts wirklich, was am Ende gebraucht wird — oder stellt sich das erst im Kontakt mit echten Nutzern, echten Daten, echter Realität heraus? Das ist ein Problem, das exakt gleich groß bleibt, egal wie viel KI im Entwicklungsprozess steckt. Kein noch so schnelles System weiß von sich aus, was ein Nutzer eigentlich braucht, wenn selbst der Nutzer es noch nicht genau sagen kann.

Diese Vermischung ist der Grund, warum die Debatte um Scrum so oft in die falsche Richtung läuft. Wer sagt "Scrum ist überholt", meint meistens das erste Problem. Wer dagegen hält "aber wir brauchen doch kurze Feedback-Zyklen", meint meistens das zweite. Beide haben recht — sie reden nur über zwei verschiedene Dinge, als wären es eines.

Das Beispiel, das mir die Augen geöffnet hat

Ich habe das an einem sehr konkreten Fall gesehen, der sich nicht wegdiskutieren lässt: einem Datenmodell, das über mehrere Features hinweg konsistent bleiben muss.

Ein Datenmodell lässt sich nicht sauber in unabhängige Sprint-Slices zerlegen. Jedes Team, jeder Sprint, jede Story modelliert "seinen" Ausschnitt der Realität — und an den Nahtstellen zwischen diesen Ausschnitten entstehen Widersprüche, die oft erst spät sichtbar werden, wenn zwei Features aufeinandertreffen, die unabhängig voneinander entstanden sind. Das ist kein Detailfehler, den man mit mehr Disziplin beheben könnte. Das ist eine strukturelle Folge davon, wie Scrum Arbeit überhaupt zerlegt, um die Koordination zwischen Menschen handhabbar zu machen. Conway's Law lässt grüßen: Die Architektur eines Systems folgt fast zwangsläufig der Kommunikationsstruktur der Organisation, die es baut. Ein Team, das in Sprint-Slices organisiert ist, produziert tendenziell auch eine Architektur, die in Slices zerfällt — selbst wenn die Domäne selbst das gar nicht hergibt.

Wasserfall hatte im Kern dasselbe Grundproblem, nur mit umgekehrtem Vorzeichen: ein an sich vernünftiges Prinzip — vorher gründlich denken, bevor man baut —, aber ohne einen Mechanismus, ein wachsendes Anforderungswerk über die Zeit hinweg widerspruchsfrei zu halten. Revisionen wurden immer teurer, je länger ein Irrtum unentdeckt blieb, und irgendwann war es billiger, einen Fehler zu verschweigen als ihn zuzugeben.

Drei Achsen statt einer Glaubensfrage

Die eigentliche Frage für 2026 ist deshalb nicht "Scrum oder Wasserfall", als müsste man sich für ein Lager entscheiden. Jede Methode lässt sich stattdessen an drei unabhängigen Größen messen:

Wie teuer ist die Abstimmung zwischen den Beteiligten? Wie viel Vorabwissen über die tatsächlichen Anforderungen ist überhaupt verfügbar oder erreichbar? Und wie teuer ist es, eine wachsende Menge an Entscheidungen konsistent zu halten, während sie sich über Zeit verändert?

Historisch hingen die erste und die dritte Größe eng zusammen — weil derselbe Mensch, der für Abstimmung sorgen musste, auch für Konsistenzprüfung zuständig war, mit denselben Kapazitätsgrenzen. Das war kein Naturgesetz, nur eine Folge der bisher verfügbaren Werkzeuge. Genau diese Kopplung löst sich gerade auf. Was das für die zweite Größe bedeutet — die Unsicherheit über echte Anforderungen, die bestehen bleibt, ganz gleich wie schnell und günstig alles andere wird — ist Thema des nächsten Artikels dieser Serie.

Was daraus praktisch folgt

Für ein bestehendes Scrum-Team heißt das keinen Bruch mit dem eigenen Selbstverständnis. Es heißt eine Verschiebung, wofür die iterativen Zyklen tatsächlich noch gebraucht werden. Die Ceremonies, die reine Menschen-Koordination lösen sollten, verlieren an Gewicht, sobald ein wachsender Teil der Umsetzung an KI-Orchestrierung übergeht — dort gibt es schlicht weniger zu koordinieren, weil ein synthetisierter, konsistenter Plan die Nahtstellen bereits klärt. Die kurzen Feedback-Zyklen selbst bleiben so wichtig wie zuvor, aber sie wandern dorthin, wo tatsächlich Unsicherheit besteht: in den Dialog mit dem Entscheider und in echten Kontakt mit Nutzern — nicht in die Abstimmung zwischen Entwicklern, die dieses Problem gar nicht mehr haben.

Genau daran arbeite ich seit acht Monaten, ganz praktisch, an einem eigenen Softwareprojekt, das seine eigene Methodik gleich mit sich selbst beweist. Im nächsten Artikel geht es um SAFe — und warum es ein Koordinationsproblem mit noch mehr Koordination beantwortet, statt die Notwendigkeit dafür zu reduzieren.