Ist Scrum noch zeitgemäß? Was KI mit agilen Teams und Methoden macht

Ich habe meine Gedanken zum Thema Scrum im KI-Zeitalter vor einigen Tagen in einem kurzen Beitrag skizziert. Die Reaktionen, intern wie extern, haben mich überrascht: rege Diskussionen, klare Widersprüche, aber auch Zustimmung und Präzisierungen, die meinen eigenen Blick geschärft haben. Das hat mich dazu bewogen, meine Thesen hier ausführlicher darzulegen.

Vorweg eine Klarstellung, die mir wichtig ist: Ich stelle nicht Agilität in Frage. Iteratives Arbeiten, Kundennähe, schnelles Feedback, das alles bleibt richtig und hat sich absolut bewährt. Was ich in Frage stelle, ist Scrum als konkrete Umsetzung dieser Prinzipien, in seiner heutigen Form, mit 14-Tage-Sprints, dediziertem Product Owner und Scrum Master und Teams von sieben bis zehn Personen. Das agile Manifest selbst, das 2001 auf agilemanifesto.org formuliert wurde, stellt das nicht in Frage. Scrum als konkrete Umsetzung davon schon.

Das Projekt, das alles in Frage gestellt hat

Vor einigen Monaten hatten wir ein Kundenprojekt, für das ich ursprünglich ein Fünf-Personen-Team eingeplant hatte. Am Ende habe ich entschieden, es mit zwei Personen zu machen, beide nur halb ausgelastet, also effektiv einem Vollzeit-Äquivalent. In vier Wochen haben sie geliefert. Von null.

Inklusive Kundeneinbezug: Wir haben gemeinsam mit dem Kunden definiert, welche Probleme er hat, haben das Frontend iteriert, noch einmal mit dem Kunden abgestimmt, und dann die App gebaut. Nach vier Wochen war das MVP fertig. Wohlgemerkt mit einem FTE.

Für mich war das der letzte Beweis, dass sich etwas grundlegend verändert hat. Was früher ein Fünf-Personen-Team in mehreren Sprints gebraucht hätte, haben zwei Personen in einem Monat geliefert. Das ist für mich kein Ausnahmefall mehr. Hier zeigt sich ein Muster, das ich in immer mehr Projekten beobachte, und das direkte Konsequenzen für die Art hat, wie wir Teams aufstellen und Projekte steuern.

Das McKinsey Global Institute beschreibt in seiner Studie zum wirtschaftlichen Potenzial generativer KI, dass Softwareentwicklung zu den Bereichen gehört, in denen KI das größte Produktivitätspotenzial entfaltet. Meine Praxiserfahrung deckt sich mit dieser Einschätzung. Nur dass die Konsequenzen für Teamstrukturen und Prozesse bisher kaum jemand zu Ende denkt: Was macht enorm beschleunigte Teams mit (agilen) Prozessen, mit Frameworks, Absprachen und der Art und Weise, wie wir in Projekten arbeiten?

Wo Scrum bricht, wenn KI ins Spiel kommt

Wenn ich heute Teams habe – meist sieben bis zehn Leute, gute agile Teams, die einen guten Prozess fahren – und jetzt kommt KI, dann entsteht ein Problem: Ein paar Teammitglieder gehen mit, ein paar nicht. Die, die mitgehen, erledigen das Projekt bald alleine. Die, die nicht mitgehen, werden abgehängt.

Der nächste logische Schritt: Ich ziehe die wirklich guten Leute zusammen, die Bock auf KI haben, und stelle fest, dass ich gar keine sieben bis zehn mehr brauche, sondern vielleicht drei bis fünf. Und wenn die richtig gut sind, noch weniger.

Jetzt laufe ich mit diesen drei bis fünf weiter und stelle fest: Die sind so gut und so schnell, dass sie ständig auf neue Requirements warten, auf Arbeitsvorrat, letztlich auf Aufgaben.

Das ist der Punkt, an dem klassische Scrum-Strukturen brechen, und zwar an einer ganz bestimmten Stelle: beim Product Owner.

Der PO wird zum Flaschenhals. Und zwar nicht weil er schlecht ist, sondern weil er schlicht nicht schnell genug Requirements nachliefern kann. Aus strukturellen Gründen. Er kann nicht mit der Beschleunigung von KI mithalten.

Das Team ist viel schneller fertig, der PO denkt noch. Und dann stellt sich die Frage: Hast du heute noch Arbeit? Ja, für heute. Für morgen nicht mehr.

Ich habe das auch in einem weiteren Kundenprojekt erlebt. Der Product Owner musste quasi jeden Tag neuen Arbeitsvorrat generieren, damit das Team nicht ausläuft. Und gleichzeitig musste er schon wieder einen gigantischen Sprintvorrat für den nächsten Sprint herstellen. Am Abend war er komplett fertig, weil wenn er es nicht gemacht hätte, wäre sein Team ausgelaufen.

Brauche ich überhaupt noch einen 14-Tage-Sprint, wenn ich von heute auf morgen neue Arbeit brauche? Was soll ich in den Sprint planen, wenn das, was früher fünf Sprints gefüllt hat, jetzt in einem abgearbeitet wird?

Zwei Einwände zur Präzisierung

In der Diskussion, die dieser Gedanke ausgelöst hat, wurde ein Einwand mehrfach geäußert: Scrum wäre für ein Zweier-Team schon immer eine seltsame Wahl gewesen.

Das stimmt. Aber es dreht die Kausalität um. Das Team im ersten Projektbeispiel war ja nicht von vornherein so klein angesetzt, sondern es konnte nur so klein sein, weil KI die Produktivität massiv gesteigert hat. KI ist der Auslöser der Teamgröße. Und wenn KI systematisch dafür sorgt, dass Teams kleiner werden, dann ist die Frage, ob Scrum damit noch passt, sehr wohl eine KI-Frage.

Der zweite Einwand ist: Scrum ist doch gar nicht so starr. Man könnte die Sprints einfach kürzer machen, auf eine Woche, auf zwei Tage, auf was auch immer das Team braucht.

Das stimmt, Scrum lässt das zu. Aber es löst das strukturelle Problem nicht, sondern verschärft es. Denn kürzere Sprints bedeuten: Der PO muss noch schneller noch mehr nachliefern. Was bei 14-Tage-Sprints noch halbwegs funktioniert, weil zwischendurch Zeit zum Denken bleibt, wird bei Zwei-Tage-Sprints zur Vollzeitaufgabe ohne Puffer. Der Flaschenhals bleibt, er wird nur enger.

Und irgendwann stellt sich – für mich zumindest – die Frage, ob es nicht sinnvoller wäre, das System grundlegend neu zu denken, statt es immer weiter zu beschleunigen.

Was ich nicht in Frage stelle (und was schon)

Scrum ist als agile Methode entstanden, um Teams iterativ und kundennah zu steuern. Das war – und ist – richtig und wichtig. Davor hat man im Wasserfall-Modus gearbeitet: zuerst alles aufschreiben, Lastenheft, Pflichtenheft, das hat teilweise Jahre gedauert. Und währenddessen hat sich die Technologie weiterentwickelt, sodass man am Ende etwas umgesetzt hätte, das technologisch nicht mehr auf dem neuesten Stand war.

Dann kam Agilität: iteratives Arbeiten, Sprints, nach jedem Zyklus ein Ergebnis, auf dem man aufbauen kann. Die Rollen wie PO, Scrum Master und Entwicklungsteam wurden definiert, weil man gesagt hat: Die Abstimmung mit dem Kunden und die Fachlichkeit, dafür ist der PO verantwortlich. Der Scrum Master hilft dabei, Blocker zu räumen und den Prozess einzuhalten.

Der Haken daran: Das alles war für eine bestimmte Welt gebaut, in der es KI noch nicht in ihrer heutigen Form gab. Man hatte mittelgroße bis größere Teams, langsamere Lieferzyklen und andere Abstimmungsbedarfe.

Was ich ganz grundsätzlich nicht in Frage stelle: Agile Prinzipien wie iteratives Arbeiten, Kundennähe, schnelles Feedback und Retros als Prinzip. Das bleibt richtig.

Was ich in Frage stelle: den 14-Tage-Sprint. Die Rolle des PO in seiner heutigen Form. Den Scrum Master als dedizierte Vollzeitrolle, wenn zwei Leute sich täglich sehen und täglich abstimmen, weil sie gar keine andere Wahl haben. Brauche ich dann in Vollzeit jemanden, der mit mir Retros macht zu zweit? Ich sehe die andere Person jeden Tag.

Ein weiterer Einwand aus der Diskussion hat mich beschäftigt: Wenn der PO zum Flaschenhals wird, liegt das Problem vielleicht nicht in der Rolle, sondern in der Entscheidungsarchitektur. Schnellere Delivery brauche nicht einfach schneller nachgelieferte Stories, sondern früher geklärte Ziele und direkte Feedbackschleifen.

Das ist zwar ein fairer Punkt. Aber mein Argument ist ein anderes: Bei der Geschwindigkeit, die solche Teams heute erreichen, reicht es nicht mehr, strategische Ziele vorzugeben und dann auf die nächste Iteration zu warten. Die Zyklen sind so kurz, dass neue Probleme und Entscheidungsbedarfe entstehen, bevor der PO überhaupt reagieren kann. Das ist ein strukturelles Geschwindigkeitsproblem, das kein besserer PO löst.

Die präzisere Formulierung, die in der Diskussion gefunden wurde und die ich für treffend halte: Es geht weniger darum, ob Scrum 'tot' ist, sondern darum, wohin sich der Engpass verschiebt. KI verschiebt einen Teil der Entwicklungsarbeit nach vorne. Die Entwickler:innen sind weniger reine Umsetzende und müssen stärker mitdenken, Lücken erkennen und Entscheidungen treffen, bevor daraus in kürzester Zeit Code entsteht.

Das ist nicht das Ende von Anforderungsarbeit, sondern eine vollständige Neuverteilung der Rollen.

Scrum heute und morgen: Ein Vergleich

Tabelle 1: Wie KI klassische Scrum-Strukturen verändert und was an ihre Stelle treten könnte

Wie das neue Modell aussehen könnte

Ich würde daher eher sagen, dass es zukünftig kleinere Teams gibt, zwei bis vier Personen, für wirklich große Projekte auch fünf bis sechs, in denen alle für das Produkt verantwortlich sind.

Alle folgen der gleichen Vision. Alle können Tickets schreiben. Alle wissen, wo sie hinwollen, und schreiben sich ihre Tickets selbst.

Das Einzige, was noch gemeinsam gemacht wird: die Epics definieren, die Produktvision schärfen, den Tech-Stack festlegen. Dann rennen alle einzeln los. Verantwortlichkeiten werden auf Basis der Epics verteilt, und dann setzt jeder sein Epic Ende-zu-Ende um.

In den Projekten, die ich beschrieben habe, war es genau so: Die beiden haben sich täglich abgestimmt, weil sie gar keine andere Wahl hatten. Das war die natürliche Konsequenz daraus, dass zwei Leute gemeinsam an einem Produkt arbeiten und beide wissen, wo sie hinwollen. Kein zweiwöchentliches Planning, sondern tägliche Abstimmung dort, wo Abhängigkeiten oder Schnittstellen entstehen.

End-to-End-Verantwortung bedeutet dabei: Ich bin nicht nur verantwortlich für meinen kleinen Teil, sondern für mein gesamtes Epic, inklusive der Integration ins Gesamtkonstrukt. Was ich einbaue, darf nichts anderes zerstören. Wenn jemand einen Fehler findet, fixt er ihn. Keine langen Abstimmungsschleifen, weil die KI am Ende ohnehin den Code schreibt.

Für den Fall, dass jemand krank wird, muss gut dokumentiert werden, damit die KI des anderen Teammitglieds den Kontext übernehmen kann.

Das führt direkt zu einer Anforderung, die in Zukunft entscheidend wird: Knowledge- und Context-Management. Gute Prozesse, gute Dokumentation, gute Governance drum herum. Das ist keine optionale Ergänzung, sondern die Voraussetzung dafür, dass dieses Modell funktioniert.

Hinzu kommt eine neue Rolle für Agenten: Sie können innerhalb der Epics Abhängigkeiten erkennen, andere Verantwortliche informieren und Tickets aktualisieren. Wenn in einem Epic etwas definiert wird, das in einem anderen wiederverwendet werden kann, meldet sich der Agent. Das ist Orchestrierung, die heute noch Menschen übernehmen, und die in Zukunft zunehmend automatisiert wird.

Mehr dazu, wie Multi-Agenten-Systeme diese Koordination übernehmen können, haben wir in einem eigenen Beitrag beschrieben.

Was aus den klassischen Rollen wird

Heißt das, dass wir die Menschen nicht mehr brauchen, die heute Product Owner oder Scrum Master sind? Nein. Aber ihre Rollen verändern sich grundlegend.

Zum Product Owner: Ein PO, der KI selbst nutzt und direkt im Produkt iteriert, kann schneller reagieren. Nur ist ein PO, der so arbeitet, kein klassischer PO mehr. Das ist jemand, der Fachlichkeit und Umsetzung zusammenzieht, der nicht mehr Anforderungen beschreibt und dann wartet, sondern selbst mitbaut und mitentscheidet.

Ob man das dann noch PO nennt oder anders, ist mir ehrlich gesagt weniger wichtig als die Erkenntnis, dass das Modell 'einer liefert Anforderungen, andere setzen um' bei dieser Entwicklungsgeschwindigkeit an seine Grenzen kommt. Die Verantwortung muss direkt ins Team. Alle kennen die Vision, alle schreiben ihre Tickets selbst, alle tragen Ende-zu-Ende-Verantwortung.

Zum Scrum Master: Die Rolle wird nicht abgeschafft, aber sie verändert sich. Ich würde sie eher als 'Responsibility Manager' beschreiben: jemand, der Blocker räumt, Kunden begleitet, den Change beim Kunden mitbetreut, weil der Kunde bei dieser Geschwindigkeit schlicht überfordert ist, und der trotzdem Retros moderiert. Was ist gut gelaufen? Was ist schiefgelaufen? Das bleibt sinnvoll. Nur nicht mehr im klassischen Scrum-Framework, sondern in einem neuen.

Wie sich diese Verschiebung auf das gesamte Organigramm auswirkt und welche Strukturen Unternehmen im KI-Zeitalter brauchen, habe ich in meinem Artikel Das Organigramm im KI-Zeitalter ausführlicher beschrieben.

KI im Unternehmen einführen: Ihr Whitepaper mit Praxisleitfaden

Wie gelingt der strukturierte Einstieg in KI, von der Bestandsaufnahme über die Organisationsfrage bis zur skalierbaren Umsetzung? Unser Leitfaden zeigt, welche Schritte Unternehmen von der ersten Idee bis zur belastbaren KI-Nutzung gehen müssen, mit konkreten Best Practices aus realen Projekten.

Jetzt kostenlos herunterladen

Die neue Schlüsselrolle: Head of Delivery Excellence

Es gibt noch einen Aspekt, den ich in dieser Diskussion bisher nur angedeutet habe: Selbst wenn das neue Modell inhaltlich überzeugt, landet es nicht von alleine in einer Organisation.

Wenn Teams kleiner werden, End-to-End-Verantwortung übernehmen und täglich statt zweiwöchentlich abstimmen, braucht es jemanden, der dafür sorgt, dass dieser Prozess in der Mannschaft wirklich ankommt. Das muss also nicht jemand sein, der die Technologie umsetzt, sondern jemand, der das Organisationsmodell definiert, den Prozess reibungslos macht und sicherstellt, dass alle so arbeiten.

Ich nenne diese Rolle ‘Chief of Staff’ oder ‘Head of Delivery Excellence’. Ihre Aufgabe ist es, genau diese Delivery Excellence in der Organisation herzustellen: Wie funktioniert das eigentlich? Wie kommen wir dahin? Wie muss das Organisationsmodell aussehen, und wie setzen wir das in der Mannschaft um?

Der Erkenntnisprozess kommt bei den meisten Unternehmen schnell. Wenn man ihnen zeigt, was möglich ist, dann kommt oft nach kurzer Zeit die Erkenntnis: Mit meiner Mannschaft, so wie es jetzt läuft, komme ich da nie an.

Denn es braucht Antworten auf bisher ungeklärte Fragen: Welche Rollen brauche ich in Zukunft? Mit welchen Skills? Und selbst wenn ich die Antwort erahne, heißt es nicht, dass ich diese Menschen identifizieren, finden und auswählen kann. Und selbst wenn ich sie finde, müssen sie auch das Mandat bekommen, wirklich agieren zu dürfen.

Und genau hier setzt der Head of Delivery Excellence an: Er oder sie sorgt dafür, dass der neue Prozess nicht nur verstanden, sondern auch gelebt wird, dass er richtig verstanden und umgesetzt wird. Dass die richtigen Menschen die richtigen Rollen übernehmen. Und dass Projekte nicht daran scheitern, dass eine entscheidende Rolle unbesetzt oder nicht klar definiert ist.

Aus meiner Sicht wird erst mit dieser neuen Position das Modell für KI-Teams vollständig. Wie das in seiner Gesamtheit aussehen könnte, zeigt das folgende Schaubild.

Schaubild: Das neue KI-Team-Modell

Abbildung 1: Wie Rollen, Verantwortlichkeiten und KI-Orchestrierung im neuen KI-Team-Modell aussehen könnten

Ausblick: Das agile Manifest bleibt, aber Scrum braucht neue Spielregeln

Was ich außerdem aus dieser Diskussion mitnehme: Es geht nicht darum, ob Scrum 'tot' ist.

Scrum ist nicht tot. Aber die Methode wurde für eine andere Welt gebaut. Und daher müssen wir jetzt, wo KI systematisch dafür sorgt, dass Teams kleiner, schneller und eigenverantwortlicher werden, uns ehrlich fragen, ob die Strukturen, die wir kennen, noch passen.

Und meine Antwort auf diese Frage ist: Nein, die Strukturen passen nicht mehr unverändert. Es braucht ein neues Framework oder jedenfalls eine Ergänzung des alten. Eines, das kleinere Teams als Normalfall begreift, End-to-End-Verantwortung als Grundprinzip verankert, tägliche Abstimmung statt zweiwöchentlicher Planungszyklen vorsieht und Agenten als Orchestrierungsschicht mitdenkt.

Das bedeutet nicht, dass alles, was Scrum ausmacht, falsch war. Iteratives Arbeiten, Kundennähe, regelmäßige Reflexion, das bleibt richtig. Das agile Manifest hat sich bewährt. Aber die konkrete Umsetzung muss sich der Realität anpassen, in der ein Team von zwei Personen in vier Wochen liefert, was früher fünf Personen in mehreren Sprints gebraucht hätten.

Ob 'Product Engineer' der richtige Begriff für die neue Rolle ist, die die Teammitglieder einnehmen müssen, weiß ich nicht. Aber die Richtung stimmt: jemand, der Fachlichkeit und Umsetzung nicht mehr sauber trennt, weil diese Trennung bei dieser Geschwindigkeit einfach nicht mehr funktioniert. Genau das sollten wir gerade herausfinden.

Warum viele KI-Projekte trotzdem scheitern, nicht an der Technologie, sondern an organisatorischen Voraussetzungen, beschreibe ich in meinem Artikel Warum KI-Projekte scheitern. Und wie KI-Implementierungen gelingen, wenn die Rahmenbedingungen stimmen, zeigt unser Beitrag KI-Implementierung erfolgreich meistern.

Fazit

Für mich ist klar: Agilität bleibt richtig. Aber Scrum in seiner heutigen Form passt nicht mehr zur Geschwindigkeit, die KI-Teams heute erreichen.

Was es braucht: kleinere Teams mit zwei bis vier Personen, End-to-End-Verantwortung statt Rollensilos, tägliche Abstimmung statt zweiwöchentlicher Planungszyklen, Agenten als Orchestrierungsschicht und neue Rollen, die Fachlichkeit und Umsetzung zusammendenken. Dazu gehört der Responsibility Manager ebenso wie die erweiterte Verantwortung der Teammitglieder.

Und es braucht jemanden in der Organisation, der dafür sorgt, dass dieser Wandel nicht nur als Idee existiert, sondern wirklich in der Mannschaft landet. Bei Assecor haben wir das mit der neuen Rolle des Head of Delivery Excellence gelöst.

Das ist kein Aufruf, Scrum abzuschaffen. Sondern ein Denkanstoß, ehrlich zu fragen, für welche Welt Scrum gebaut wurde, und ob diese Welt noch die unsere ist.

Wie verändert KI Ihre Teamstruktur und Ihre Delivery-Prozesse?

Wenn Sie diese Fragen für Ihr Unternehmen konkret beantworten wollen, sprechen wir gerne darüber. Wir begleiten Sie dabei, KI-Strategie und Organisationsstruktur zusammenzudenken, von der ersten Einschätzung bis zur Umsetzung.

Jetzt Erstgespräch vereinbaren

FAQ: Scrum im KI-Zeitalter

Ist Scrum durch KI überholt?

Nicht grundsätzlich, aber in seiner heutigen Form passt es nicht mehr zu KI-beschleunigten Teams. Die Grundprinzipien der Agilität, iteratives Arbeiten, Kundennähe, schnelles Feedback, bleiben richtig. Die konkreten Strukturen wie 14-Tage-Sprint, der Product Owner als alleiniger Anforderungslieferant und der Scrum Master als Vollzeitrolle in kleinen Teams, müssen neu gedacht werden.

Was passiert mit dem Product Owner in KI-Teams?

Die Rolle verändert sich grundlegend. Bei der Geschwindigkeit, die KI-Teams heute erreichen, reicht es nicht mehr, strategische Ziele vorzugeben und auf die nächste Iteration zu warten. Verantwortung wandert ins Team: Alle kennen die Vision, alle schreiben eigene Tickets, alle tragen Ende-zu-Ende-Verantwortung für ihr Epic. Der klassische PO als alleiniger Anforderungslieferant wird strukturell zum Flaschenhals.

Wie groß sollten KI-Teams sein?

Zwei bis vier Personen für kleinere Projekte, bis fünf für größere. Entscheidend ist nicht die Teamgröße als solche, sondern End-to-End-Verantwortung pro Epic, tägliche Abstimmung dort, wo Abhängigkeiten entstehen, und ein gemeinsames Verständnis der Produktvision. KI verstärkt vorhandene Kompetenz, sie gleicht fehlende nicht aus.

Was ist ein Responsibility Manager?

Der Begriff beschreibt die weiterentwickelte Scrum-Master-Rolle im KI-Zeitalter: jemand, der Blocker räumt, Kunden begleitet, den Change beim Kunden mitbetreut und dafür sorgt, dass der neue Prozess in der Organisation wirklich landet. Keine Zeremonien-Hüterin, sondern eine Person, die Entscheidungswege und Abstimmung so kurz macht, wie das Team liefern kann.

Was ist ein Head of Delivery Excellence?

Eine neue Schlüsselrolle, die dafür sorgt, dass das neue Arbeitsmodell nicht nur als Idee existiert, sondern in der Mannschaft wirklich ankommt. Nicht technologische Umsetzung, sondern Organisationsmodell, Prozessdesign und Rollendefinition. Der Erkenntnisprozess kommt bei Unternehmen schnell. Die Hilflosigkeit danach auch. Genau hier setzt diese Rolle an.