Agilität nach AI: Warum Rollen, Teams und Verantwortlichkeiten neu gedacht werden müssen

Scrum-Teams mit zehn oder mehr Personen könnten bald ein Relikt aus der Vor-AI-Zeit sein. Nicht, weil Scrum oder Agilität grundsätzlich falsch wären. Sondern weil sich die Realität der Softwareentwicklung gerade grundlegend verändert.

Viele Organisationen arbeiten noch immer mit dem klassischen Setup: Teams aus neun bis zwölf Personen, klar getrennte Rollen wie Product Owner, Entwickler, Designer und QA – dazu ein Scrum Master, der Prozesse organisiert und moderiert. Dieses Modell ist in einer Welt entstanden, in der Coding der Engpass war. Wenn Entwicklung durch AI-gestützte Tools massiv beschleunigt wird, verschiebt sich dieses Gleichgewicht. Und damit verändert sich zwangsläufig auch die Art, wie Teams funktionieren.

Es zeichnet sich bereits eine andere Struktur ab. Statt großer Scrum-Teams entstehen kleinere, hochautonome Einheiten – oft drei bis vier Personen –, die man als AI Pods beschreiben könnte. Diese Teams bestehen aus sehr erfahrenen Menschen, die deutlich enger zusammenarbeiten und schneller Entscheidungen treffen können. Der Engpass liegt nicht mehr primär im Schreiben von Code, sondern in der Klarheit darüber, was gebaut werden soll, warum und in welcher Architektur ein System aufgebaut sein muss, damit AI sinnvoll damit arbeiten kann.

Damit verändern sich auch die Rollen. Die Grenzen zwischen Produkt, Design und Engineering werden durchlässiger. Product Manager formulieren Spezifikationen, Prompts oder sogar Teile des Codes. Engineers denken stärker in Produktlogik, Architektur und Nutzererlebnis. Designer arbeiten nicht mehr nur an Oberflächen, sondern direkt an Komponenten- und Systemdesign. Die Rollen verschwinden nicht, aber sie beginnen sich zu überlappen, weil viele der bisherigen Übergabepunkte schlicht weniger relevant werden.

Parallel dazu entstehen neue Rollen, für die viele Organisationen heute noch gar keine klare Bezeichnung haben. Ein AI Systems Architect etwa kümmert sich um Architekturentscheidungen und Systemgrenzen, bevor überhaupt AI-generierter Code entsteht. Ein Context Engineer sorgt dafür, dass AI-Tools mit der richtigen Struktur aus Dokumentation, Coding-Guidelines und Domänenwissen arbeiten können. Ein Product Systems Designer verbindet UX, Produktlogik und technische Struktur zu einem konsistenten System. Und ein AI Quality Lead verantwortet Review- und Qualitätsprozesse für AI-generierten Code. Diese Rollen entscheiden künftig stärker über die Produktivität eines Teams als klassische Sprint-Mechaniken.

Gerade deshalb wird eine Rolle plötzlich besonders wichtig: Menschen, die Transformation begleiten können. Denn diese Veränderungen passieren nicht von allein. Organisationen müssen lernen, neue Teamstrukturen aufzubauen, Rollen neu zu definieren, Verantwortlichkeiten zu klären und Entscheidungswege anzupassen. Gleichzeitig müssen neue Arbeitsprinzipien im gesamten Unternehmen verstanden werden – vor allem in Software-Produktorganisationen.

Wenn Teams plötzlich schneller entwickeln können, als Organisationen Entscheidungen treffen können, entsteht kein Fortschritt, sondern Chaos. Transformation bedeutet deshalb heute weniger, ein neues Framework einzuführen. Es bedeutet vielmehr, Unternehmen dabei zu helfen zu verstehen, wie Produktentwicklung funktioniert, wenn AI Teil des Systems wird. Dazu gehört auch, Dinge einzufordern: klare Rollen, klare Verantwortung und klare Qualitätsstandards.

Die agilen Prinzipien selbst bleiben dabei relevant. In vieler Hinsicht sogar relevanter als zuvor. Aber viele der Strukturen und Rituale, die wir über die Jahre darum gebaut haben, wirken plötzlich schwerfälliger, als sie einmal gedacht waren.

Vielleicht erleben wir gerade die größte Chance seit zwei Jahrzehnten, Agilität wirklich zu leben – statt sie nur zu verwalten.