Scrum in Zeichen KI-Entwicklung neu denken

Scrum verfügt über eine kurze Phase der Evaluation (Review), dem kurzen Lernen im Team zur Verbesserung der Zusammenarbeit (Retrospektive) sowie im Vergleich zur Gesamtsprintlänge ebenfalls kurzen Planen (Planning) des nächsten Sprints.

Der aktuelle Scrum Guide (PDF) definiert eine maximale Sprintlänge von vier Wochen + empfiehlt einen Sprintlauf von zwei Wochen oder weniger. Viele Teams, die wir kennen, haben sich auf zwei Wochen "eingeschossen". Für viele Teams ist auch das genau der Releasezyklus.

Technisch gesehen wären kürze Releasezyklen möglich. Für viele Organisationen ist es einfacher, Abnahmeprozesse + weitere formale Prozesse an den 2-Wochen-Zyklus anzuhängen. Für einige ist auch das nicht möglich, so dass die Beteiligen alle vier Wochen offiziell releasen. Und noch andere Organisationen sprinten monatsweise und releasen dann einmal im Quartal, weil ihnen formale Prozesse + Regularien im Weg zu stehen scheinen.

Das agile Manifest ist da ziemlich klar, was kurzfristiges Releasen + den Kund*innennutzen angeht. Die Fordertung ist, Kund*innennutzen in möglichst kleinen Zeitzyklen schaffen:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Die grundlegende Antwort darauf sind PDCA-Zyklen.

Die Hauptzeit einer Scrum-Iteration liegt heute in der Umsetzung von UserStorys

Das im Vergleich deutlich kürzere Review, eine kurze Retrospektive sowie ein kurzes Planning zu einer im Verhältnis langen Umsetzungszeit in der laufenden Iteration reflektieren die Umsetzungswahrheiten vor Vibe- beziehungsweise Agentic Coding. Vibe Coding ist Programmieren in natürlicher Sprache + intuitive Iteration mit KI-Agents.

Dabei verändert sich das Handlungsfeld für die menschlichen Teammitglieder.

In Zeichen von KI verändert sich der Entwicklungszyklus. Die "Bob-der-Baumeister"-Frage

"Schaffen wir das?"

fokussierte auf die Frage, ob die Beteiligten genügend Fokus + Klarheit für die Entwicklung über Review, Retro + Planning erzeugt hätten, um in der Iterationszeit das Gewerk zu entwickeln + zu testen.

Dabei schafft Scrum eine gute Kommunikationsebene für Stakeholder*innen. Im Review können diese nicht nur den Fortschritt ablesen, Meinung + Richtung äußern. Sie begleiten auch die Vorstellung der Produkt-Vision, in die Product Owner*innen die aktuellen Ergebnisse einordnen + so auch das Motto der kommenden Iteration ableiten.

Welcher Entwicklungsprozess ist nun für uns dienlich?

Methodengläubigkeit + "so haben wir das immer gemacht" bremsen Organisationen aktuell aus. Scrum in der gewohnten + geübten Form ist häufig Teil der Komfortzone Eurer Organisation geworden. Scrum ist Teil Eures Systems geworden.

Es hilft ein Blick darauf, wie Ihr gerade Eure Arbeitsweise angesichts Prompting, Vibe- oder Agentic Coding ändert. Und dann fragt Euch:

"Dient die Methode uns oder dienen wir der Methode?"

Ihr solltet für jeden Methodenbaustein klarhaben, warum Ihr diesen Baustein nutzt + welchen Einfluss auf die Ergebnisqualität Ihr für den jeweiligen Baustein seht.

Mit VibeCoding verändert sich Entwicklung grundlegend. Die Umsetzung von UserStorys erfolgt signifikant schneller als bisher üblich. Daher ändert sich die Aufgabenstellung "Planen": Es ist nicht mehr zu erfassen, welche Komplexität in Aufgaben liegt, um damit eine Iteration passend zum Iterationsmotto zu füllen. Sondern es geht darum, testbare Spezifikationen zu formulieren, die KI verstehen und der*die Stakeholder*in bewerten kann.

Mit Scrum werden die Fragen "Was tun wir?" + "Wie tun wir es?" im agilen Sinne entkoppelt. Gleichzeitig ist der zeitliche Ablauf so gestrickt, dass die Beteiligten eine realistische Umsetzungszeit des Geplanten haben.

Methodenbausteine iterativ anpassen

Der Mensch wechselt dabei aus der Rolle des*der reinen Code-Schreiber*in in die eines*einer strategischen Kurator*in + Qualitätswächter*in. Dabei braucht es zwei Blicke: die zeitlichen Forderungen ändern sich, die Interaktion mit den KI-Agents gilt es ebenfalls zu optimieren. Entsprechend stehen alle Methodenbausteine auf dem LernCheck:

"Dienen uns die Methodenbausteine? Machen sie uns besser? Wie könnte es noch besser gehen?"

Entsprechend sind Methodenbausteine iterativ anzupassen.

Tägliche Implementierungszyklen durchlaufen

In Zeichen von Vibe-Coding ändert sich dieser zeitliche Bedarf. Während die Umsetzungszeiten signifikant sinken, erhöht sich der Bedarf für testbare Spezifikationen. Anforderungen formulieren, umsetzen + testen durchlaufen eher einen Tageszyklus im Lernen als eine gesamte Iteration.

Teams treffen sich in regelmäßig in Retrospektiven, um ihre Effizienz zu steigern. Zusammen mit den KIs herauszubekommen, wie der Arbeitsfluss noch effizienter geht, ist das Gebot der Stunde.

Kurze Lernzyklen für das Optimieren im System sind gefragt. Und so könnten die Entwicklungsteams neben einem täglichen CheckIn zusammen mit ihren KI-Kolleg*innen auch ein gemeinsames CheckOut durchlaufen, in dem gemeinschaftliches Lernen über effiziente Zusammenarbeit stattfindet.

Täglich Lernzyklen durchlaufen

Und so werden die meisten Teams, die fast nur oder ausschließlich auf VibeCoding setzen, einen täglichen Lernzyklus PDCA brauchen.

Im morgendlichen Planning werden die UserStorys bei Bedarf erweitert + zu testbaren Spezfikationen erweitert. Mit diesen UserStorys entwickeln die Teammitglieder zusammen mit ihren KI-Kolleg*innen, deren Ergebnisse nach + nach in die Systeme eingespielt werden. Hieraus ergibt sich bei Bedarf zum Verändern + Nachjustieren weiterer UserStorys. Auch können die Beteiligten direkte Learnings aus dem Arbeitstag ableiten. Die entsprechenden Anmerkungen formuliert das Team zum Schluss des Arbeitstags.

So können die Beteiligten täglich ihr Promptingverhalten + ihre ToolChains optimieren. Die Beteiligten lernen täglich im Kaizen-Modus.

In Retrospektiven regelmäßig lernen, um die Effizienz des Teams zu steigern

Neben den täglichen Learnings im System lohnt sich mit etwas Abstand + Ruhe, einen Blick auf das System zu haben. Hierfür können die Beteiligten eine regelmäßige Retrospektive nutzen. 90 Minuten, klare Phasen + Fragen, unterstützen die Beteiligten dabei, das grundsätzliche Setting + das zielführende Verhalten zu evaluieren + zu verändern.

Orientierung geben

In Eurem bisherigen Scrum-Modus haben Euch (hoffentlich) Iterations-Mottos unterstützt, Euch gut zu orientieren + zu priorisieren. Sprintmottos unterstützen die Selbstorganisation, sie geben Richtung. Die Beteiligten können gut entscheiden, ob + wie sie die jeweilige UserStory interpretieren beziehungsweise mit Leben füllen möchten. Sprintmottos unterstützen nicht nur die Menschen, sondern auch die KI im System, gute Vorschläge zu entwickeln.

Diese übergeordnete Richtung ist fürs Vibe-Coding essenziell, um nicht in einer Flut von generierten, aber unzusammenhängenden Features zu ertrinken.

Ein klares Iterationsmotto dient dabei als semantischer Ankerpunkt für das gesamte Team und sorgt dafür, dass die KI-Prompts nicht nur technisch funktionieren, sondern auch strategisch auf das gemeinsame Ziel einzahlen.

So entsteht ein roter Faden, der Mensch und Maschine synchronisiert und verhindert, dass die hohe Umsetzungsgeschwindigkeit zu Lasten der Produktkohärenz geht.

Definition of Ready + Done KI-gerecht aufbauen

Viele Scrum-Teams arbeiten mit Definitions of Ready + Definitions of Done, um die Selbstorganisation im Team zu unterstützen + für eine gleichbleibend hohe Auslieferungsqualität zu sorgen.

Nicht nur im Zeichen von Vibe-Coding ist es sinnvoll, die DoD und die DoR nicht als kompliziertes Regelwerk zum Abhaken, sondern in Prinzipien zu formulieren.

Die Methode als Solches umstellen

Im Kaizen-Modus ändern die Beteiligten iterativ + inkrementell die Methodenbausteine. Es lohnt sich gleichzeitig auf Grund des Paradigmenwechsel in der Entwicklung die Frage, ob Scrum eigentlich noch die grundsätzliche Aufgabenstellung gut bedient. Vielleicht ist auch der Wechsel in ein anderes Vorgehen wie XP oder Kanban im ersten Kaikaku-Schritt sinnvoller, um dann Iteration für Iteration zu adjustieren.

Auf XP umstellen

Wenn Ihrer Organisation der Prozess einen klaren Namen braucht, ist es vielleicht Zeit, Scrum abzulösen + auf XP ("Extreme Programming") zu setzen.

Extreme Programming bietet mit seinem Fokus auf technische Praktiken genau das Sicherheitsnetz, das beim Vibe-Coding oft fehlt. Während Scrum die Organisation strukturiert, liefert XP mit Ansätzen wie Test-Driven Development (TDD) und Continuous Deployment die notwendige Disziplin, um die hohe Generierungsgeschwindigkeit der KI in stabile Software zu verwandeln. Dabei setzt XP auf unterschiedlich lange Sprintzyklen in Abhängigkeit vom jeweiligen Sprintziel, welches sich aus dem Sprintmotto ergibt.

Auf Kanban umstellen

Da die Umsetzungszeit im Vergleich deutlich an Länge verliert, ist das Entzerren + Komplexität nehmen durch einen Fluss denkbar.

In einem KI-gestützten Workflow wird das klassische Sammeln von UserStorys für einen mehrwöchigen Sprint oft zum künstlichen Hindernis.

Kanban erlaubt es dem Team, die extrem kurzen Umsetzungszyklen von Vibe Coding unmittelbar abzubilden, indem Aufgaben ohne Verzug durch das System fließen (Continuous Delivery). Statt auf das Ende einer Iteration zu warten, werden die durch KI beschleunigten Inkremente sofort validiert und released, was den Fokus von der Einhaltung eines Zeitplans hin zur Maximierung des Durchsatzes und der Wertschöpfung verschiebt. Bei diesem Methodenschwenk erhalten die DoD + DoR große Bedeutung für ein qualitätsvolles Liefern.

Einen dem Erfolg dienlichen Prozess leben

Agile Methodenbausteine sind so auszulegen, dass sie die Beteiligten unterstützen, ihre jeweiligen Teamziele in hoher Qualität + in eher kurzen Zyklen zu erreichen.

Das tägliche Arbeiten mit KI verändert Software-Entwicklung radikal. Diese radikale Veränderung fordert auch eine klare Anpassung Eures Vorgehens. Es ist Zeit, Euer Vorgehen zu hinterfragen + neu zu entdecken.