Warum ich bei TAISC-Projekten kein klassisches Scrum mehr mache

TL;DR

• Meine Sprints waren zuletzt öfter leer, bevor sie fertig geplant waren, weil ein Kick-off-Gespräch, ein Prototyp und Kunden-Feedback oft schneller gingen als das Zwei-Wochen-Ritual drumherum.
• Das ist kein Bauchgefühl: DORA 2025, der State of Agile Report und sogar Scrum.org selbst bestätigen, dass klassische Scrum-Rituale unter Druck geraten, seit KI-Agenten eigenständig mehrstufige Aufgaben umsetzen.
• Trotzdem ist das kein Freibrief für Chaos. Ich sage auch, wo klassisches Scrum weiterhin die richtige Wahl ist, und wo ich mit meiner Einschätzung vielleicht falsch liege.

Der Moment, der mir zu denken gegeben hat

Vor einigen Monaten saß ich in einer Retro mit mir selbst, das klingt komisch, ist aber genau das, was bei einem TAISC-Projekt mit einem Kunden passiert ist. Kick-off am Montag. Am Dienstag stand ein klickbarer Prototyp. Mittwoch kam Feedback vom Kunden. Donnerstag war die erste Version live. Für ein klassisches Zwei-Wochen-Sprint-Ritual mit Planning, Refinement, Review und Retro blieb schlicht nichts mehr übrig, das dieses Ritual gebraucht hätte.

Mein erster Impuls war, das für einen Einzelfall zu halten, ein besonders gut laufendes Projekt mit wenig Komplexität. Als ich anfing, genauer hinzuschauen, wie oft das inzwischen passiert, und als ich anfing, öffentlich darüber zu reden, wie wenig ich noch von klassischem Scrum übrighabe, wurde schnell klar: Das ist kein Einzelfall. Und es macht ziemlich viele Leute in der Branche entweder neugierig oder wütend.

Was mich überzeugt hat, dass es keine Einbildung ist

Ich will hier nicht nur meine eigene Erfahrung als Beweis anführen, das wäre zu billig. Zwei aktuelle, unabhängige Studien stützen den Eindruck.

Der 17th State of Agile Report von Digital.ai zeigt: Scrum ist mit 63 % weiterhin das meistgenutzte Team-Framework, das ist unbestritten. Gleichzeitig ist die Zufriedenheit mit Agile-Praktiken von 72 % auf 59 % gefallen, der stärkste Einbruch seit Beginn der Erhebung. Skalierte Frameworks wie SAFe verlieren sogar mehr als die Hälfte ihrer Nutzerbasis.

Der DORA-Report 2025 von Google Cloud, knapp 5.000 befragte Fachleute, liefert die vielleicht wichtigste Erkenntnis: KI ist kein Fixer, sondern ein Verstärker. Wer stabile Praktiken hat, kleine Batches, automatisierte Tests, schnelle Feedback-Schleifen, profitiert überproportional von KI. Wer die nicht hat, wird mit KI nicht produktiver, sondern instabiler. Das erklärt auch, warum meine Erfahrung so unterschiedlich zu der mancher Kolleg:innen ausfällt: Es hängt nicht an der KI, sondern daran, was vorher schon an Prozessdisziplin da war.

Und dann ist da noch etwas, das mich wirklich überrascht hat: Scrum.org selbst, die Organisation hinter dem offiziellen Scrum Guide, veröffentlichte im Mai 2026 einen Beitrag mit dem Titel „The Sprint Review Is Broken, Here Is What Replaces It”. Wenn die Institution, die Scrum offiziell definiert, öffentlich zugibt, dass ein Kernritual überholt ist, ist das kein Nischenmeinung mehr, das ist ein Branchensignal.

Was ich konkret anders mache

Ich will ehrlich sein: Ich habe Scrum nicht “abgeschafft”. Ich habe drei Dinge verändert, und die haben den größten Unterschied gemacht.

Erstens, ich plane nicht mehr in festen Sprints, sondern in einem laufend priorisierten Backlog. Der Rhythmus liegt oft bei ein bis zwei Tagen statt zwei Wochen. Der Agile-Berater Yuval Yeret nennt das in seiner Analyse „Is Spec-Driven Development a Step Forward or Back?” treffend: Story Points, detaillierte Task-Breakdowns, ausformulierte User Stories, all das wird optional, sobald KI-Agenten einen Großteil der Aufgabenzerlegung übernehmen. Der Kern von Scrum, Empirie, Fokus, Transparenz, Anpassung, bleibt. Das Drumherum nicht zwingend.

Zweitens, der Prototyp ersetzt die meisten User Stories. Statt eine Anforderung tagelang in Textform zu verhandeln, baue ich mit KI-Agenten oft noch während des Kundengesprächs einen ersten klickbaren Entwurf. Das deckt Missverständnisse auf, die eine Story in Prosa nie gezeigt hätte, und es macht das Gespräch konkreter, statt abstrakter.

Drittens, ich reviewe anders. Ich zeige keine Screenshots mehr, sondern beantworte vier Fragen, ziemlich genau die, die Scrum.org in seiner „Evidence Review” vorschlägt: Was war die Wette? Was wurde gebaut? Was hat der Kunde tatsächlich damit gemacht? Was ist die nächste Wette? Kein Applaus, aber eine klare Entscheidung am Ende.

Was bleibt, ist ein „Parking Lot”, ein sichtbarer Ort für Ideen, die gerade nicht in den Kernprozess gehören, aber nicht verloren gehen sollen. Das ist im Grunde ein Backlog, nur ohne den Zwang, alles sofort in Tickets zu pressen.

Wo ich vorsichtig bin

Ich will hier keine Blaupause verkaufen, das wäre unehrlich und würde auch nicht zu dem passen, was ich sonst über Beratungen sage, die nur Folien statt Code liefern. Drei Situationen, in denen ich selbst zu klassischem Scrum raten würde:

• Große, verteilte Teams mit vielen Abhängigkeiten. Der State of Agile Report zeigt klar: Größere Organisationen setzen deutlich häufiger auf hybride Modelle, aus gutem Grund. Mehr Koordination braucht mehr Struktur.
• Stark regulierte Projekte. Wo Audit-Trails und Dokumentationspflichten gesetzlich vorgeschrieben sind, ersetzt ein schneller Prototyp keine nachvollziehbare Spezifikation.
• Teams ohne die technische Autonomie, die das braucht. Ship / Show / Ask und ein flexibler Backlog setzen Vertrauen und Erfahrung voraus. Ohne das kippt Flow schnell in Chaos.

Der DORA-Befund gilt hier für mich persönlich als Warnung, nicht nur als Beobachtung über andere: KI verstärkt, was schon da ist. Wenn bei mir intern Verantwortlichkeiten unklar wären, würde KI das nicht lösen, sondern schneller sichtbar machen.

Was das für dich bedeuten könnte

Falls du gerade in einem Team arbeitest, das mit KI-Coding-Agenten baut, und dich fragst, ob deine Sprints noch echten Zweck erfüllen: Ein einfacher Test hilft. Wenn dein nächstes Sprint Review, dein nächstes Refinement oder deine nächste ausformulierte Story ausfallen würde, würde das jemand als echten Verlust an Klarheit spüren? Wenn nein, ist es wahrscheinlich Ritual ohne Funktion geworden.

Das ist übrigens derselbe Denkfehler, den ich schon beim Thema MVP-Kosten beschrieben habe: Warum ein MVP heute nicht mehr 50.000 € kosten muss. Es geht nicht darum, dass Qualität günstiger oder Prozesse beliebiger werden. Es geht darum, ehrlich zu prüfen, welcher Teil eines etablierten Vorgehens noch einen Zweck erfüllt, und welcher nur noch aus Gewohnheit weiterläuft.

Häufige Fragen

Heißt das, du machst gar kein Scrum mehr? Nein, das wäre übertrieben. Ich behalte den empirischen Kern, kurze Feedback-Zyklen, Transparenz, laufende Anpassung. Was ich losgelassen habe, sind starre Zwei-Wochen-Grenzen, vollständig ausformulierte User Stories vor dem Bauen und Demo-Reviews ohne echte Nutzungsdaten.

Funktioniert das auch bei größeren Teams? Ehrlich: Ich habe das vor allem in kleinen, autonomen Setups erprobt, oft mit mir selbst als Forward Deployed Engineer und einem schlanken Team auf Kundenseite. Bei großen, verteilten Teams mit vielen Abhängigkeiten würde ich selbst eher zu mehr Struktur raten, nicht weniger. Dazu mehr in meinem Beitrag zu Forward Deployed Engineering im DACH-Raum.

Ist das nicht einfach Chaos mit besserem Marketing? Der berechtigte Einwand. Die Antwort liegt in den Voraussetzungen: stabile CI/CD, kleine Batches, automatisierte Tests. Ohne das würde ich selbst nicht auf feste Sprints verzichten. Genau das bestätigt auch der DORA-Report: KI verstärkt Instabilität, wenn diese Grundlagen fehlen.

Wie fange ich an, wenn ich das ausprobieren will? Nicht alles auf einmal. Ich würde mit der Review anfangen: Ersetze die nächste Demo durch eine Evidence Review mit echten Nutzungsdaten statt Screenshots. Wenn das funktioniert, wird der Rest oft von selbst klarer.

Fazit

Ich bin kein Scrum-Gegner, ich bin nur skeptisch gegenüber Ritualen, die aus Gewohnheit weiterlaufen, obwohl der eigentliche Zweck längst woanders erfüllt wird. Bei mir läuft das inzwischen über schnelle Prototypen statt Textstorys und über Evidence Reviews statt Demos. Ob das für dein Team passt, hängt davon ab, wie stabil eure technische Basis schon ist, nicht davon, wie modern die Methode klingt.

Wenn du darüber sprechen willst, wie das in deinem Kontext aussehen könnte: Lass uns reden.