Agile ist zu starr für AI-native
Ich sage das als jemand, der Agile ernsthaft gelebt, gelehrt und skaliert hat: Agile war meine zweite berufliche Liebe – und heute nehme ich Abschied. Wie es dazu kam und warum aus der Agilen Bewegung leider nur noch ein Geschäftsmodell wurde, habe ich in AI eats Agile for Breakfast schon erzählt. Heute möchte ich darauf eingehen, warum Agile heute für mich nicht mehr passt.
Warum Agile für AI-native nicht passt
Zu hohes Tempo. Ein AI-native Team liefert an einem guten Tag fünf Features, 10 Chores und 3 Bugfixes. Die Prioritäten ändern sich im Stundentakt. Kein Agiles Framework mit getakteten Events kann da mithalten. Bis zum Daily Scrum sind alle Impediments längst adressiert, gelöst und in Produktion ausgeliefert ;)
Code wird nicht von Teams geschrieben. Niels Pflaeging bringt es in seiner Analyse zu Time-Oriented Software Development auf den Punkt: Software wird in jedem Moment von genau einer Person oder einem Pair gebaut – nie von mehr. Alles, was darüber hinausgeht, ist keine Zusammenarbeit, sondern Batching und eine Barriere für Leistung. Genau deshalb schlägt Solo- oder Pair-Arbeit, gekoppelt mit AI-Agents, jedes Development Team. Teams bedeuten Koordination und grössere Teams noch mehr Koordination. Und Koordination bricht den Flow. Genau deshalb gehören Entwickler-Agent-Teams nicht irgendwo in eine IT-Abteilung vergraben, sondern direkt in die Business-Linie – Niels nennt das «business people who happen to develop software».
Runterskalieren. Wer bei diesem Tempo an mehr Prozess denkt, verschlimmert das Problem. SAFe antwortet auf Komplexität mit riesigen Skalierungsapparaten und starren Release Trains im 8- bis 12-Wochen-Takt – Agilitäts-Theater, das genau in die falsche Richtung skaliert. Mehr Struktur ist die falsche Antwort auf mehr Komplexität. Strukturen abbauen, herunterskalieren, ist bei diesem Tempo das Richtige.
Flow. Der eigentliche Bruch liegt aber tiefer: Daily, Refinement, Planning, Sync, Abteilungen, Handovers, segmentierte Prozess-Ketten – jede Übergabe bricht den Flow. Das lässt sich nicht mit noch einem angepassten Ritual reparieren. Der Engpass ist nicht das Entwickeln selbst, sondern Aufmerksamkeit, Kontext und Verantwortung in Einklang mit Flow zu bringen. Dafür muss der ganze Entwicklungsprozess – von der Idee bis zur Auslieferung in Produktion – auf Flow optimiert werden, organisatorische und prozessuale Hürden müssen weg.
Make time the boss
Wer runterskalieren und Flow optimieren will, findet die Blaupause nicht bei Scrum oder SAFe, sondern in der Fabrikhalle: Niels Pflaeging zieht in seiner Herleitung von Toyota zu Time-Oriented Software Development (TOSD) die Linie vom Toyota Production System zu Software. Der Kern: Nicht die Kapazität ist fix und die Lieferzeit variabel – die Zeit ist der fixe Boss, und die Kapazität schwingt. Einzelstückfluss statt Batches, feste Timeboxen statt Sprint Forecasts, tägliche Fertigstellung statt Sprint-Ziel in der Ferne.
Konkret heisst das: Arbeit fliesst aus einer priorisierten Liste, via Konzept, über einen OK Point, in eine strikt zeitlich fixierte Realisierung – ein Tag ideal, zwei akzeptabel, drei das Maximum. Dauert eine Einheit länger, ist nicht die Timebox falsch, sondern der Zuschnitt.
Keine fixen Sprints, Events, Schätzungen und zentrale Koordination. Eine Liste, Fluss, Rhythmus und das Prinzip «Miteinander reden – Talk to each other» wenn nötig. So einfach kann Fluss sein. KISS – möglicherweise Agile – in Reinform ;)
Was wir mitnehmen, und wo wir abbiegen
Ich bin ein kritischer Geist, und an einem Punkt sind die Autoren von TOSD und ich uns ausdrücklich uneinig. Für Niels sitzt der OK Point «ausschliesslich» zwischen Menschen. Für mich gilt er zusätzlich auch zwischen Menschen und Agents – und genau das lehnt Niels ab: eine Vereinbarung zwischen Mensch und Agent sei Illusion, kein echter OK Point.
Ich erlebe das in meiner täglichen Arbeit anders: Der Agent legt einen Vorschlag vor, ich schärfe nach, wir vereinbaren OK und die Realisierung startet, und am Schluss wird geprüft, ob die Vereinbarung eingehalten wurde. Wie das genau funktioniert, erkläre ich Ihnen in den folgenden Blogs auf diesem Kanal. Stay tuned.
Mir ist wichtig zu betonen, dass mein Abschied von Agile nicht im Sinne von «Pfui – alles ist schlecht» zu verstehen ist. Die Prinzipien hinter Agile – kurze Feedback-Schleifen, funktionierende Software über umfassender Dokumentation, auf Veränderung reagieren über dem Befolgen eines Plans – sind heute richtiger denn je. Ich verabschiede mich nicht von dem, was Agile wollte. Ich verabschiede mich von der Form, die daraus geworden ist.
Der Preis von Flow
Das klingt ja zu schön um wahr zu sein, denken Sie jetzt sicher. Sie müssen aber verstehen, welchen Preis Sie für Abbau von Organisation, Struktur und Prozess, Bürokratie und Regeln bezahlen: «Die Währungen heissen Business-Sense, Können und Verantwortung.» A fool with a tool is still a fool, aber ein verantwortungsvoller Könner mit Business-Sense kann, gekoppelt mit einem AI-Agent Team und einer Plattform, welche die Agents auf Spur hält, wahre Wunder vollbringen.