Scrum hat der Softwareentwicklung viel Gutes gebracht. Es hat Teams beigebracht, in kleinen Schritten zu denken, Feedback ernst zu nehmen und sich regelmäßig zu hinterfragen. Das war ein echter Fortschritt gegenüber dem, was vorher da war – starre Wasserfallpläne, monatelange Zyklen, Releases ins Unbekannte.
Aber die Welt, für die Scrum entworfen wurde, existiert so nicht mehr. Und sie wird in fünf Jahren noch weniger existieren.
Dieser Artikel ist keine Abrechnung mit Scrum. Es ist der Versuch, ehrlich hinzuschauen: Was passiert mit unseren Prozessen, wenn AI nicht mehr das Neue ist, sondern das Normale? Wenn die Frage nicht mehr lautet, ob wir AI einsetzen – sondern wie wir ohne sie jemals gearbeitet haben?
Die Grundannahme hat sich verschoben
Scrum basiert auf einer einfachen Prämisse: Softwareentwicklung ist komplex und unvorhersehbar. Also plant man in kurzen Zyklen, liefert früh, lernt schnell. Zwei Wochen Sprint. Planning, Review, Retro. Ein bewährter Rhythmus.
Das Problem ist nicht der Rhythmus selbst. Das Problem ist, was sich innerhalb dieses Rhythmus verändert hat – und was sich in den nächsten Jahren noch verändern wird.
Ein Entwickler mit AI-gestützten Tools – Claude, Copilot, Cursor – kann heute in Stunden liefern, wofür vor zwei Jahren Tage eingeplant wurden. Prototypen entstehen am Nachmittag, nicht am Ende eines Sprints. Code Reviews, die früher ganze Meetings füllten, werden durch AI-unterstützte Analyse in Minuten erledigt. Dokumentation, die niemand schreiben wollte, generiert sich quasi nebenbei.
Das ist der Stand von heute. Jetzt stell dir vor, wo wir in fünf Jahren stehen.
2030: Ein Tag im Leben eines Entwicklers
Es ist Montagmorgen. Du öffnest dein IDE – oder das, was in fünf Jahren ein IDE sein wird. Wahrscheinlich eher eine Konversation als eine Oberfläche voller Dateibäume. Dein AI-Agent hat über Nacht drei Pull Requests vorbereitet, basierend auf den Prioritäten, die du am Freitag gesetzt hast. Nicht irgendwelche generischen Code-Schnipsel, sondern kontextbewusste Implementierungen, die deine Architekturentscheidungen kennen, die Coding Standards des Teams einhalten und die Abhängigkeiten zu anderen Services berücksichtigen.
Du reviewst. Nicht Zeile für Zeile – das macht ein zweiter AI-Agent, der auf Security und Performance spezialisiert ist. Du schaust auf die Architektur-Ebene: Ist das die richtige Lösung für das Problem? Passt das in die langfristige Richtung des Produkts? Dein Review dauert zwanzig Minuten für etwas, das heute drei Tage Entwicklung und einen halben Tag Review bedeuten würde.
Um zehn Uhr hast du ein Gespräch mit dem Product Owner. Nicht im Daily – das gibt es nicht mehr, weil der Stand jederzeit transparent ist. Stattdessen diskutiert ihr über eine strategische Entscheidung: Soll das neue Feature als eigenständiger Microservice laufen oder als Erweiterung des bestehenden Systems? Die AI hat beide Varianten über Nacht als Prototypen gebaut. Ihr könnt sie nebeneinander vergleichen. Nicht als Wireframes oder Architekturdiagramme, sondern als funktionierende Software.
Am Nachmittag arbeitest du an einem komplexen Integrationsproblem. Ein Legacy-System, das seit zwölf Jahren im Einsatz ist und dessen Dokumentation lückenhaft ist. Vor fünf Jahren hätte das bedeutet: wochenlange Analyse, Reverse Engineering, vorsichtiges Herantasten. Heute lässt du deinen AI-Agenten die gesamte Codebasis analysieren, Datenflüsse rekonstruieren und eine Integrationsstrategie vorschlagen. Deine Aufgabe: die Strategie bewerten, Randfälle identifizieren, die die AI nicht kennen kann, und Entscheidungen treffen, die über den Code hinausgehen. Wer sind die Stakeholder? Welche politischen Abhängigkeiten gibt es? Welche Risiken sind akzeptabel?
Um siebzehn Uhr hast du acht Features in Produktion gebracht. Nicht weil du acht Mal so schnell tippst, sondern weil du acht Mal so schnell entscheiden, bewerten und steuern kannst.
2030: Ein Tag im Leben eines Product Owners
Auch die Rolle des Product Owners wird sich fundamental verändern – vielleicht sogar noch radikaler als die des Entwicklers.
Es ist Dienstagmorgen. Du öffnest dein Dashboard – nicht das Jira-Board, das du heute kennst, sondern eine Oberfläche, die dir in Echtzeit zeigt, wie sich das Nutzerverhalten über Nacht verändert hat. Dein AI-Analyst hat Muster erkannt: Die Conversion Rate im Onboarding ist um drei Prozent gefallen, und zwar spezifisch bei Nutzern, die über Mobile einsteigen. Die AI hat bereits drei Hypothesen generiert, warum das passiert sein könnte, inklusive Datengrundlage für jede Hypothese.
Du musst keine Story schreiben. Du musst kein Refinement ansetzen. Du sagst: "Hypothese zwei klingt plausibel. Baut mir einen A/B-Test, der das validiert." Drei Stunden später läuft der Test. Nicht weil irgendein Entwickler alles stehen und liegen gelassen hat, sondern weil die AI den Test implementiert, deployed und die Monitoring-Infrastruktur aufgesetzt hat. Ein Entwickler hat die Implementierung in zehn Minuten reviewed und freigegeben.
Am Mittag sitzt du mit dem Stakeholder aus dem Vertrieb zusammen. Er will ein neues Reporting-Feature – bis gestern hätte er dafür einen Termin im nächsten Sprint Planning gebraucht, dann Refinement, dann Schätzung, dann Priorisierung gegen andere Stories. Jetzt zeigst du ihm einen funktionierenden Prototyp, den du auf dem Weg zum Meeting generiert hast. "Meinst du so etwas?" Ihr iteriert live. Am Ende des Meetings ist die Anforderung nicht nur verstanden, sondern validiert – an einer funktionierenden Software, nicht an einem Akzeptanzkriterium in einem Ticket.
Am Nachmittag triffst du eine Entscheidung, die keine AI für dich treffen kann: Welche drei von zwanzig möglichen Initiativen haben den größten strategischen Impact für die nächsten sechs Monate? Die Daten liegen vor. Die Analysen sind gemacht. Aber die Entscheidung erfordert Kontextwissen, das in keinem System steckt. Wer im Vorstand wofür kämpft. Welcher Kunde gerade kurz vor der Kündigung steht. Welches Team gerade in einer schwierigen Phase ist und nicht noch ein ambitioniertes Projekt braucht.
Das ist die Arbeit des Product Owners in fünf Jahren: nicht Tickets schreiben und Backlogs pflegen, sondern Entscheidungen treffen, die Maschinen nicht treffen können.
Warum Scrum dieser Zukunft nicht standhält
Scrum ist für eine Welt gebaut, in der der Weg von der Idee zur Software lang, unsicher und teuer ist. Jeder dieser drei Punkte wird sich in den nächsten Jahren fundamental verändern.
Der Weg wird kurz. Wenn ein Prototyp in Stunden statt Wochen entsteht, braucht man keine aufwändige Vorab-Planung mehr. Man baut und schaut, ob es funktioniert. Sprint Planning als Instrument, um die nächsten zwei Wochen vorherzusagen, wird obsolet, wenn die Vorhersage weniger Zeit kostet als die Umsetzung.
Die Unsicherheit verlagert sich. Scrum adressiert Unsicherheit in der Umsetzung – wir wissen nicht genau, wie lange etwas dauert, also planen wir in Inkrementen. Aber wenn die Umsetzung nicht mehr der unsichere Teil ist, verlagert sich die Unsicherheit dorthin, wo sie schon immer am größten war: in die Frage, ob wir das Richtige bauen. Und diese Frage beantwortet kein Sprint Review am Ende von zwei Wochen. Sie beantwortet sich durch kontinuierliches Experimentieren – täglich, stündlich, in Echtzeit.
Die Kosten sinken dramatisch. Wenn die Kosten für einen Prototyp gegen null gehen, verändert sich die gesamte Ökonomie der Softwareentwicklung. Man baut nicht mehr ein Feature und hofft, dass es funktioniert. Man baut fünf Varianten und misst, welche funktioniert. Das ist ein anderes Paradigma, das eine andere Prozesslogik erfordert.
Ceremonies als Overhead – eine ehrliche Bestandsaufnahme
Ich spreche das aus, was viele in der Branche denken, aber selten laut sagen: Die meisten Scrum-Ceremonies haben sich von nützlichen Ritualen zu bürokratischem Overhead entwickelt. Und mit zunehmender AI-Integration wird dieser Overhead nicht kleiner, sondern absurder.
Sprint Planning. Heute sitzen fünf bis acht Leute zwei Stunden zusammen und diskutieren, welche Stories in den nächsten Sprint passen. Sie schätzen in Story Points, diskutieren Abhängigkeiten, brechen Epics in kleinere Teile. In einer Welt, in der die Umsetzung einer Story Stunden statt Tage dauert, ist diese Granularität nicht mehr nötig. Die Frage "Schaffen wir das in diesem Sprint?" wird ersetzt durch "Was ist gerade das Wichtigste?" – und diese Frage braucht keine Zeremonie, sondern eine klare Priorisierung.
Daily Standup. "Was habe ich gestern gemacht? Was mache ich heute? Gibt es Blocker?" In einer Zukunft, in der der gesamte Entwicklungsfortschritt in Echtzeit transparent ist – weil AI-Agenten jeden Schritt dokumentieren, Pull Requests automatisch erstellt werden und Deployment-Pipelines sofortige Sichtbarkeit bieten – ist das Daily ein Relikt. Es war erfunden worden, um ein Informationsproblem zu lösen. Das Informationsproblem wird nicht mehr existieren.
Sprint Review. Das Team zeigt dem Stakeholder, was in den letzten zwei Wochen gebaut wurde. Aber wenn Stakeholder bereits am Tag der Anforderung einen funktionierenden Prototyp sehen und Feedback geben können – wofür dann ein Review alle zwei Wochen? Das ist, als würde man in einer Welt mit Echtzeit-Messaging immer noch darauf bestehen, einmal pro Woche einen Brief zu schreiben.
Retrospektive. Die Retro ist das einzige Scrum-Element, das auch in fünf Jahren noch Wert haben könnte – aber in einer anderen Form. Die Frage "Wie können wir uns als Team verbessern?" bleibt relevant. Aber die Antworten werden andere sein. Statt "Wir brauchen bessere Akzeptanzkriterien" eher: "Wie stellen wir sicher, dass unsere AI-Agenten die richtigen Architekturentscheidungen treffen?" oder "Wie bewahren wir unsere Fähigkeit, Code zu verstehen, den wir nicht mehr selbst schreiben?"
Backlog Refinement. Tickets detaillieren, Akzeptanzkriterien formulieren, Abhängigkeiten identifizieren. Das ist Arbeit, die eine AI in Zukunft in Sekunden erledigen kann – und zwar besser als die meisten Refinement-Sessions, weil sie die gesamte Codebasis kennt, alle bisherigen Tickets gelesen hat und die technischen Abhängigkeiten tatsächlich versteht, statt sie zu schätzen.
Das Projektgeschäft in fünf Jahren
Was bedeutet das für das Projektgeschäft? Für die Art, wie wir als Studios, Agenturen und IT-Dienstleister arbeiten?
Heute verkaufen die meisten IT-Dienstleister Zeit. Sprints. Kapazitäten. "Wir stellen Ihnen ein Team mit zwei Seniors, einem Mid-Level und einem Scrum Master für sechs Monate." Das Geschäftsmodell basiert auf der Annahme, dass Softwareentwicklung aufwändig ist und menschliche Arbeitsstunden der limitierende Faktor sind.
In fünf Jahren wird diese Annahme nicht mehr halten.
Wenn ein kleines Team mit AI-Unterstützung das Zehnfache des Outputs eines heutigen Scrum-Teams liefern kann, dann wird niemand mehr für Kapazitäten bezahlen. Kunden werden für Ergebnisse bezahlen. Nicht "Wir haben acht Sprints lang gearbeitet", sondern "Wir haben euer Problem gelöst."
Das verändert alles: die Vertragsmodelle, die Teamstrukturen, die Zusammenarbeit mit Kunden.
Vertragsmodelle. Time-and-Material – das Standardmodell im agilen Projektgeschäft – wird zunehmend schwer zu rechtfertigen sein. Wenn ein Entwickler mit AI-Unterstützung ein Feature in zwei Stunden baut, das er dem Kunden für acht Stunden berechnet – wie lange geht das gut? Die Branche wird sich in Richtung Value-Based Pricing bewegen müssen. Festpreise für definierte Outcomes. Success Fees. Modelle, die den Wert der Lösung abbilden, nicht den Aufwand der Erstellung.
Teamstrukturen. Das klassische Scrum-Team – fünf bis neun Personen mit definierten Rollen – wird sich auflösen. Stattdessen werden wir kleine, hochspezialisierte Einheiten sehen. Zwei, drei Leute, die jeweils mit einem Arsenal an AI-Agenten arbeiten. Kein Scrum Master, weil es keinen Scrum-Prozess mehr gibt, den jemand faciliten muss. Kein dedizierter Tester, weil AI-Agenten Testing in Echtzeit übernehmen. Dafür Menschen, die strategisch denken, Domänenwissen mitbringen und die Fähigkeit haben, die richtigen Fragen zu stellen.
Kundenzusammenarbeit. Heute ist der Kunde im besten Fall Teil des Sprint Reviews. In fünf Jahren wird die Zusammenarbeit kontinuierlich sein. Nicht weil man mehr Meetings hat, sondern weil die Einstiegshürde für Feedback gegen null geht. Der Kunde sieht eine Änderung in Echtzeit, gibt Feedback direkt am Prototyp, und die nächste Iteration ist am selben Tag live. Der gesamte Feedback-Loop – von der Idee über die Umsetzung bis zur Validierung – verkürzt sich von zwei Wochen auf Stunden.
Was stattdessen?
Ich habe kein fertiges Framework, das Scrum ersetzen soll. Und ich bin skeptisch gegenüber jedem, der behauptet, eines zu haben. Frameworks, die auf dem Reißbrett entstehen, scheitern an der Realität – das hat die Geschichte der Softwareentwicklung oft genug gezeigt.
Aber ein paar Prinzipien zeichnen sich ab:
Kontinuierlicher Fluss statt getakteter Sprints. Die Idee ist nicht neu – Kanban arbeitet seit Jahren nach diesem Prinzip. Aber mit AI bekommt der kontinuierliche Fluss eine neue Qualität. Wenn Umsetzung fast sofort passiert, wird der gesamte Wertschöpfungsprozess zu einem Strom, der nie pausiert. Keine künstlichen Grenzen mehr zwischen "wir planen" und "wir bauen" und "wir testen" und "wir liefern". Alles passiert gleichzeitig, kontinuierlich, ineinander übergehend.
Outcome über Output. Statt "Wie viele Stories haben wir geschafft?" die Frage "Hat sich die Conversion Rate verbessert?" oder "Haben wir die Fehlerquote reduziert?" oder "Ist der Kunde zufriedener?" Das klingt trivial, ist aber ein fundamentaler Paradigmenwechsel. Es bedeutet, dass wir aufhören, Aktivität zu messen, und anfangen, Wirkung zu messen.
Autonomie mit Alignment. Kleine Teams, die eigenständig entscheiden, was sie als Nächstes tun – aber innerhalb eines klaren strategischen Rahmens. Keine detaillierten Backlogs, die von oben befüllt werden, sondern Ziele, die das Team selbst in konkrete Maßnahmen übersetzt. OKRs kommen dem nahe, aber auch die werden sich weiterentwickeln müssen.
Experimentieren als Grundhaltung. Statt "Wir planen, was wir bauen" hin zu "Wir bauen, um zu lernen." AI macht es möglich, Hypothesen in Stunden statt Wochen zu testen. Das verändert den gesamten Planungsansatz. Statt einmal pro Sprint zu liefern und dann Feedback einzuholen, werden Teams täglich mehrere Experimente fahren, messen und entscheiden. Build-Measure-Learn, aber im Zeitraffer.
Menschliche Fähigkeiten als Differenzierungsmerkmal. Wenn Code kein Engpass mehr ist, werden andere Fähigkeiten zum entscheidenden Faktor: Domänenwissen. Empathie für den Endnutzer. Die Fähigkeit, komplexe Stakeholder-Landschaften zu navigieren. Kreativität bei der Problemdefinition – nicht bei der Problemlösung. Die Frage "Was sollen wir bauen?" wird wichtiger als "Wie sollen wir es bauen?"
Der Elefant im Raum
In vielen deutschen Großunternehmen ist Scrum nicht aus Überzeugung im Einsatz. Es ist ein Instrument, das Struktur in Organisationen bringt, die Struktur brauchen – nicht weil sie agil sein wollen, sondern weil sie kontrollierbar sein müssen. Scrum liefert Metriken, die man reporten kann. Velocity, Sprint Burndown, Story Points – alles Zahlen, die sich in ein Management-Dashboard einfügen lassen, auch wenn sie über den tatsächlichen Projektfortschritt wenig aussagen.
Das ist verständlich. Große Organisationen brauchen Governance. Sie brauchen Nachvollziehbarkeit, Compliance, Auditierbarkeit. Das sind legitime Anforderungen, die nicht verschwinden werden, nur weil sich die Technologie ändert.
Aber die Art, wie diese Anforderungen erfüllt werden, muss sich ändern. Wenn AI-Agenten jeden Schritt dokumentieren, jede Entscheidung nachvollziehbar machen und jeden Codechange automatisch in einen Audit-Trail schreiben – dann braucht man keine Scrum-Ceremonies mehr als Kontrollmechanismus. Die Transparenz, die Scrum durch Meetings herstellen sollte, wird durch Technologie hergestellt. Besser, schneller, vollständiger.
Scrum liefert ersteres. AI wird letzteres liefern.
Ein Wort der Vorsicht
Dieser Artikel könnte den Eindruck erwecken, dass die Zukunft der Softwareentwicklung eine rein technische Frage ist. Das ist sie nicht.
Die größte Herausforderung wird nicht sein, die richtigen Tools zu finden oder den perfekten Prozess zu definieren. Die größte Herausforderung wird sein, Menschen mitzunehmen. Entwickler, die seit zehn Jahren in Scrum-Teams arbeiten und deren gesamte Karriere auf diesem Framework aufgebaut ist. Scrum Master, deren Rolle in fünf Jahren möglicherweise nicht mehr existiert. Product Owner, die lernen müssen, in Echtzeit zu entscheiden statt in Sprint-Zyklen zu denken.
Das sind keine technischen Probleme. Das sind menschliche Probleme. Und sie verdienen Respekt und Aufmerksamkeit – nicht die Arroganz eines "Scrum ist tot, passt euch an."
Scrum war das richtige Framework für seine Zeit. Es hat die Softwareentwicklung besser gemacht. Aber seine Zeit geht zu Ende – nicht weil es schlecht war, sondern weil sich die Bedingungen, für die es geschaffen wurde, fundamental verändern.
Die Frage ist nicht: "Wie retten wir Scrum?"
Die Frage ist: "Was brauchen wir stattdessen?"
Und diese Frage sollten wir jetzt stellen. Nicht erst in fünf Jahren, wenn die Antwort schon offensichtlich ist.
Die Antwort muss nicht Ja oder Nein sein. Aber wer sie nicht stellt, hat sie schon beantwortet.