On Lean and Agility

Du hast irgendeinen Job in der IT? Du möchtest Dich als Thought Leader profilieren? Du erklärst Agile schon seit so Langem für tot, dass es langsam unglaubwürdig wird, und Du brauchst daher einen neuen Spin für Deine Botschaft? Dann kannst Du Dich freuen, denn es gibt jetzt einen neuen Aufhänger, mit dem Du begründen kannst, dass Agile tot ist (und zwar dieses Mal wirklich) - Künstliche Intelligenz!! Hier erfährst Du, wie Du Deine Botschaft auf diese Weise neu formulierst.

I. Vergleiche mutig Äpfel mit Birnen

Dass die Aussage "Agile wird durch KI obsolet" in gleichem Ausmass verschiedene Sachverhalte zusammenwirft wie es bei "die Strassenverkehrsordnung wird durch autonomes Fahren obsolet" der Fall wäre, braucht Dich nicht zu bekümmern. Trage es einfach mit ausreichender Überzeugung vor, und ergänze es mit Behauptungen wie der, dass das für jeden, der sich näher damit befasst hat, offensichtlich wäre. Viele Zuhörer werden sich dann nicht mehr trauen, diesen Zusammenhang zu hinterfragen.

II. Setze KI kategorisch mit Zukunft und Fortschritt gleich

Fang nicht damit an, die Begriffe "Agile" und "KI" in all ihrer Vieldeutigkeit zu erklären, das würde Dich nur zwingen, zu differenzieren und einzuordnen. Hau stattdessen auf die Pauke - behaupte einfach, dass KI die grösste Disruption seit der Erfindung des Rades ist, und dass sie Alles verändert was vorher da war. Da die agilen Frameworks und Praktiken inzwischen einige Jahrzehnte alt sind, sind sie damit implizit als etwas markiert, was nicht zur Zukunft gehört.

III. Setze agiles Arbeiten kategorisch mit einer zu überwindenden Vergangenheit gleich

Hier kannst Du zwischen verschiedenen Varianten wählen: entweder erklärst Du gönnerhaft, dass die die agilen Frameworks und Praktiken "damals" Sinn gemacht haben, aber mit der "heutigen" Geschwindigkeit nicht mehr mithalten können, oder Du behauptest, dass sie schon immer eine schlechte Idee waren, was spätestens jetzt offensichtlich wäre. Zur Verstärkung kannst Du auch Einzelfälle von falscher Umsetzung einzelner Praktiken aus dem Kontext reissen und als Beweis präsentieren.

V. Tu so, als würden Sachzwänge nicht mehr existieren

Dass auch jetzt noch auf irgendeine Weise geplant werden muss, wer wann in welcher Reihenfolge an was arbeitet, kannst Du genauso ignorieren wie die Frage, wann und wie die Wirksamkeit und Wirtschaftlichkeit der Arbeitsergebnisse eigentlich überprüft werden soll. Du kommst erstaunlich weit mit weitgehend inhaltsleeren Aussagen wie "Die Frage stellt sich heute nicht mehr", oder "Mit KI müssen wir uns nicht mehr für eine Option entscheiden, sondern können alle umsetzen".

IV. Verkaufe alten Wein in neuen Schläuchen

Falls irgendjemand hartnäckig darauf beharrt, dass er gerne Vorschläge oder Beispiele für die neuen Arbeitsweisen hätte, kannst Du ihm einfach die alten agilen Vorgehensmodelle unter neuem Namen verkaufen. Ein "Pod" aus einem Domain Expert, einem Delivery Lead und drei bis vier Entwicklern, die in "Bolts" von wenigen Tagen arbeiten, ist zwar praktisch das Gleiche wie ein kleines Scrum Team mit einwöchigen Sprints, klingt aber viel moderner.

V. Anthropomorphisiere die KI-Programme

Sollte jemand doch erkennen, das ein Pod und ein agiles Team praktisch das Gleiche sind, hast Du ein letztes As im Ärmel: behaupte einfach, dass anders als im "alten" agilen Arbeitsmodus KI-Agenten vollwertige Teammitglieder eines Pods sind. Dir wird dabei der Eliza-Effekt zu Gute kommen, also die unbewusste menschliche Neigung, interaktiven Computer-Programmen menschliche Eigenschaften zuzuschreiben. Ein unschlagbares Differenzierungsmerkmal, auch wenn es inhaltlich Quatsch ist.

VI. Immunisiere Dich

Wenn Du es bis hierhin geschafft hast, bist Du eigentlich durch, und hast den Thought Leader-Status erreicht. Du musst jetzt nur noch dafür sogen, dass niemand Dir vorhalten kann, er hätte Deine Ratschläge befolgt, und sie hätten nicht funktioniert. Aber auch das ist einfach: Du musst nur hervorheben, dass der technische Fortschritt gerade so schnell ist, dass alle aktuellen Erkenntnisse ständig durch noch neuere und bessere obsolet gemacht werden. So hast Du immer eine Ausrede.

[Ironie off] Mit diesem Text will ich nicht sagen, dass KI-getriebene Software-Entwicklung unnötig oder nicht machbar wäre. Was ich sagen will ist aber, dass den meisten "AI killed Agile" -Marktschreiern sowohl in Bezug auf agile Softwareentwicklung als auch in Bezug auf KI-getriebene Softwareentwicklung in bemerkenswertem Ausmass Stringenz und Substanz fehlen. Die Ironie dieser Geschichte: in der Hype-Phase von Agile traten viele der damaligen "Thought Leader" sehr ähnlich auf.

Code Reviews gehören zu den besseren Praktiken der Softwareentwicklung, werden aber in vielen Teams kritisch gesehen, da sie einen verzögernden Flaschenhals im Entwicklungsprozess bilden können. Thierry de Pauw berichtet davon, wie es besser gehen kann: durch eine Integration in den täglichen Entwicklungsflow von Features, statt einer Durchführung in einer nachgelagerten Phase.

Was darüber hinaus bemerkenswert ist, ist die aus dem Lean Management abgeleitete Reduzierung der Wartezeiten und parallelen Arbeiten, die dieser Ansatz beinhaltet. Ein Sichtweise, die noch immer viel zu selten stattfindet.

Bild: Wikimedia Commons / Армія Інформ - CC BY 4.0

Wenn grosse Organisationen durch grosse technische Erneuerungsprogramme gehen (egal ob im Hardware- oder Software-Bereich) ist das mit einer Komplexität behaftet, die man sich als Aussenstehender kaum vorstellen kann. Vereinfacht gesagt gibt es dabei aber zwei Ansätze: zum einen eine zentrale Steuerung aller damit verbundenen Vorhaben, zum Anderen ein dezentrales Vorgehen, bei dem den einzelnen Organisationseinheiten grosse Freiheiten gelassen werden.

Eine aussergewöhnliche Gegenüberstellung dieser beiden Ansätze kann man im Paper Evolvement of C2/C4ISR during the Russo-Ukrainian War, veröffentlicht von der Universität der finnischen Armee nachlesen (Kapitel 14 dieses Dokuments). Zu den aussergewöhnlichen Umständen gehören dabei der hohe Erfolgsdruck, das hohe Tempo der technischen Innovation und die Tatsache, dass beide Seiten genau unterschiedlich vorgingen - die Russen zentralisiert, die Ukrainer dezentral.

Beide Vorgehensweisen sind dabei mit einer zugrundeliegenden Erwartungshaltung verbunden: das dezentrale Vorgehen verspricht schnelle Ergebnisse, die dafür mit einer Uneinheitlichkeit erkauft werden, die Integration und Betrieb schwieriger macht. Das zentralisierte Vorgehen dauert dagegen länger, dafür sind die Ergebnisse einheitlicher und dadurch einfacher zu integrieren und reibungsloser zu betreiben - zumindest in der Theorie.

In der Realität führten dagegen beide Ansätze zu einem hohen Ausmass an Uneinheitlichkeit, Problemen und Improvisation, nur die Gründe dafür waren unterschiedlich: während diese Zustände bei den dezentral agierenden Ukrainern bewusst in Kauf genommen worden waren, wurden sie bei den Russen unbeabsichtigt durch das zentralisierte Vorgehen erzeugt, das damit genau das Gegenteil dessen erreichte, wofür es eigentlich vorgesehen war.

Zum einen lag das daran, dass der Versuch einer zentralen Steuerung zu Einheitslösungen führte, die dann in vielen lokalen Kontexten den dort gegebenen Herausforderungen nicht gerecht wurden, und zum anderen daran, dass dieses Vorgehen zu langen und teilweise bürokratischen Entscheidungswegen führte, die mit der Geschwindigkeit der technischen Entwicklungen nicht mithalten konnten. In beiden Hinsichten funktionierte das dezentrale ukrainische Vorgehen besser.

Wie weiter oben geschrieben ist dieser Fall (russische und ukrainische Armee) aussergewöhnlich, es gibt aber Parallelen zu anderen, sich schnell ändernden Umgebungen. Auch in denen kann es nicht nur zu schnelleren sondern auch zu besseren Ergebnissen führen, wenn Entscheidungen (und Budget) in die einzelnen Organisationseinheiten delegiert werden, wo schnelle und unbürokratische Entscheidungen getroffen werden können, ohne durch zentrale Vorgaben zu sehr eingeschränkt zu sein.

Bild: Pexels / Ekam Juneja - Lizenz

John Cutler: The Feature Factory - A 10-Year Retrospective

Dave Snowden: We Need to Talk About Taylor

Stefan Norrvall: Complexity Is Not in the Eye of the Beholder

Dorothea Herrmann: Jenseits der „Change-Kurve“ - Wie wir das Gestalten und Erleben von Veränderung besser verstehen können

Mehdi Hoseini: How To Create A Team Wall For Your Scrum Team

Wer geglaubt hat, dass mit dem Aufkommen KI-gestützter Softwareentwicklung die Zeit der agilen Frameworks vorbei ist, wird sich mittlerweile wundern. Schon bald sind neue entstanden oder es wurden bestehende angepasst. Nachdem Mitte 2025 AI-DLC den Anfang gemacht hat und Mitte 2026 AI-Native SAFe nachgefolgt ist, wurde im Herbst 2026 ein drittes veröffentlicht, das das Potential hat, weite Verbreitung zu finden: Impatient Programming/IMP (https://impatientprogramming.org).

Alleine die vom Hauptverfasser Obie Fernandez aufgestellte Grundprämisse ist spannend: genau wie in den 90er Jahren das damals vorherrschende "Cowboy Coding" durch Extreme Programming/XP (das erste agile Framework mit grösserer Bekanntheit) disziplinierter und verantwortungsvoller wurde, gibt es auch für das KI-basierte Vibe-Coding einen Bedarf nach Struktur und Verlässlichkeit. Als einer der Pioniere von XP versucht Fernandez dessen Kern auf die KI-gestützte Entwicklung zu übertragen.

In weiten Teilen ist in IMP das alte XP enthalten, wenn auch mit einer zentralen Modifikation: es ist ein auf enger, täglicher Zusammenarbeit basierendes Vorgehensmodell, mit dem in kurzen Abständen Incremente benutzbarer Software erstellt werden. Anders als im den 90er und 2000er Jahren arbeiten aber nicht nur Menschen eng zusammen, sondern autonom handelnde KI-Agenten werden in diese Zusammenarbeit einbezogen (z.B. in Form eines Ergebnisberichts eines Agenten im Daily).

Gleichzeitig entfallen durch die Leistungsfähigkeit der KI bestimmte Limitierungen. Im klassischen XP wurde z.B. die Anzahl der Spikes (technischer Machbarkeitsstudien) bewusst gering gehalten, um möglichst viel Arbeitskapazität für die Umsetzung der Anforderungen übrig zu haben. In IMP treten an ihre Stelle die bereits bekannten Vibe-gecodeten Wegwerf-Prototypen, deren Erstellungsaufwand so gering ist, dass man sie in beliebiger Menge und Frequenz produzieren kann.

An anderer Stelle kommen dafür neue Limitierungen dazu. So bleibt beispielsweise Test First und eine hohe Testabdeckung wichtig, um zu verhindern, dass die Token-Kosten ausser Kontrolle geraten, wird aber versucht, die Anzahl der Tests möglichst gering zu halten, indem redundante oder irrelevante Tests automatisiert ermittelt und entfernt werden. Im Grunde kann man in diesem Zusammenhang von permanentem Refactoring der Test Suite sprechen - einer alten XP-Praktik, neu interpretiert.

Ebenfalls wichtig ist der Aspekt der KI-Governance, der in IMP in Form des so genannten "Contract" vorliegt, worunter hier die hart vorgegebene Summe aller funktionalen und nicht funktionalen Anforderungen (Architektur, Performance, Regulatorik, etc.) besteht, deren Einhaltung von den KI-Agents im Rahmen ihrer Arbeit ständig validiert werden muss. Das Risiko von halluzinierten und schlechten Ergebnissen soll so minimiert werden.

XP-typisch ist zuletzt der Minimalismus des vorgegebenen Prozess-Umfangs. Während der in XP im Wesentlichen aus der Definition gleichlanger Iterationen in Länge weniger Wochen bestand, in denen jedesmal Funktionalität geliefert und deren Mehrwert validiert werden sollte, gibt IMP einen "Heartbeat" von jeweils einwöchigen Zeiträumen vor, an deren Ende in einem Meeting namens "Showcase" die in dieser Zeit fertiggestellten Ergebnisse präsentiert werden.

In einer ersten Bewertung würde ich sagen, dass IMP (in dessen Rahmen die Entwickler übrigens "Imps" genannt werden) das Potential hat, XP sowohl im Guten als auch im Schlechten nachzufolgen. Im Guten dahingehend, dass es unter vielen Entwicklern eine enthusiastische und treue Gefolgschaft finden kann, im Schlechten dahingehend, dass es durch eine starke technikzentrierung wenig Management-kompatibel ist, und von kommerziellen Ansätzen verdrängt werden könnte.

Alles in allem ist es aber eine spannende Weiterentwicklung klassischer agiler Prinzipien und Praktiken, durch die allen KI-zentriert arbeitenden Entwicklungsorganisationen eine weitere Option zur Selbstorganisation zur Verfügung steht. Und selbst wenn (wie im Fall von XP) am Ende nur einzelne Praktiken eine weitere Verbreitung erreichen sollten, wäre auch das schon eine deutliche Verbesserung im Vergleich zum im Vibe Coding wiedergeborenen Cowboy-Vorgehen.

Bild: Wikimedia Commons / Ralf Roletschek - CC BY-SA 3.0

Einer der Vorteile des Beraterlebens ist, dass man regelmässig Einblicke in verschiedene Unternehmen erhält. Wenn sich dabei bestimmte Beobachtungen wiederholen, kann man daraus auf entstehende Trends schliessen, und im Moment passiert genau das. Aus verschiedenen Firmen (genauer gesagt aus deren Softwareentwicklungs-Abteilungen) habe ich von einem Vorgehen gehört, dass man am Besten als eine Wette auf den Fortschritt beschreiben kann.

Konkret geht es dabei um den Einsatz von künstlicher Intelligenz (KI) in der Softwareentwicklung und noch konkreter um den Umgang mit dem dadurch drohenden Kontrollverlust. Der Trend besteht darin, diesen bis zu einem gewissen Grad zuzulassen, es also hinzunehmen, dass der erzeugte Code nicht allen internen Standards entspricht (von Architektur bis Benennungskonventionen), quantitativ aufgebläht ist, und im Extremfall nicht zur Gänze verständlich ist.

Dieses Zulassen eines derartigen Kontrollverlustes (ein Phänomen übrigens, das es auch vor KI-gestützter Softwareentwicklung gab, das jetzt aber deutlich schneller entstehen kann) ist natürlich hochgradig riskant. Im Fall, dass aus irgendeinem Grund einmal schnelle Anpassungen an den Software-Systemen notwendig werden sollten, kann es sein, dass diese nicht mehr zeitnah oder mit vertretbarem Aufwand durchgeführt werden können. Daraus können ernsthafte Probleme entstehen.

Die Wette auf den Fortschritt besteht jetzt daraus, dass die Entwicklung der letzten Jahre extrapoliert wird, also davon ausgegangen wird, dass sich die Fähigkeiten der KI-Modelle genauso schnell und innovativ weiterentwickeln werden wie in den letzten Jahren. Um diese Wette "zu gewinnen" werden zukünftige KI-Modelle in der Lage sein müssen, den wenig verständlichen und regelkonformen Code der alten Modelle zu überarbeiten - und zwar bevor zum nächsten mal schnelle Anpassungen nötig werden.

Ein derartiges Vorgehen ist optimistisch und mutig (um das Geringste zu sagen), und es wird spannend sein zu beobachten, ob es zum angestrebten Ergebnis führen wird. Wenn ja, werden sich erhebliche Aufwände praktisch in Luft auflösen, wenn nicht werden sie mit erheblichem Aufwand nachgeholt werden müssen. Um es methodisch zu beschreiben: hier werden technische Schulden aufgenommen, in der Hoffnung, dass ein Schuldenerlass kommen wird. Mal sehen ob er kommt, und wann.

In manchen grossen Firmen (vor allem solchen, die kurz zuvor eine Strategieberatung im Haus hatten) kann man merkwürdige Vorgänge beobachten. Immer wieder werden Effizienzsteigerungsprogramme ausgerufen, die aber ihre Ziele deutlich verfehlen. Um das zu kompensieren gibt es neue Programme, die wieder ihr Ziel verfehlen, etc. Mit zunehmender Intensität und Frequenz wird versucht, die Abläufe zu beschleunigen, bis am Ende ein Eindruck von atemlosen Aktionismus entsteht.

Dieses Phänomen ist von Forschern der Universität St. Gallen im Rahmen einer Langzeitbeobachtung von hunderten Unternehmen identifiziert worden und wurde von ihnen die Beschleunigungs-Falle, bzw. the Acceleration Trap genannt (siehe hier). Dieser Name liegt zum einen darin begründet, das eine Beschleunigung der Abläufe das Ziel ist, zum anderen darin, dass die Veränderungsprogramme immer schneller vorbei waren und durch ständig neue ersetzt wurden.

Ausgelöst wurde die Beschleunigungs-Falle von den folgenden Zusammenhängen: angetrieben von ständigen Beschleunigungs-Forderungen nahmen die Mitarbeiter sich (freiwillig oder unfreiwillig) unrealistisch viel Arbeit vor, begannen zu viel davon gleichzeitig und begannen mit neuen Arbeiten noch bevor die alten richtig abgeschlossen waren. Die St. Gallener Forscher nannten diese Verhaltensweisen Overloading, Multiloading und Perpetual Loading.

Durch dieses Verhalten entstand ein konstanter Zustand der Überlastung, der von den Betroffenen auf unterschiedliche Weise kompensiert wurde: zum Teil durch Dienst nach Vorschrift, zum Teil durch verstärkte (und meistens berechtigte) Krankmeldungen, zum Teil aber auch durch Selbstschutz in Form von absichtlich langsamem Arbeiten bei gleichzeitiger Erzeugung eines Eindrucks hoher Geschäftigkeit, wodurch der Eindruck vermieden werden sollte, eine weitere Optimierung wäre noch möglich.

Im Verlauf ihrer Feldforschung haben die schweizer Wissenschaftler aber nicht nur die Beschleunigungs-Falle entdeckt und beschrieben, sie haben auch Unternehmen identifiziert, die zwar von ihr betroffen waren, sich aber auch irgendwann von ihr befreien konnten, darunter so namhafte wie ABB, Lufthansa, Microsoft, Lidl und Otto. Und das Gegenmittel, das in allen Fällen wirksam gewesen ist, ist (wenig überraschend) die Entschleunigung gewesen.

In einer Umkehr von Overloading, Multiloading und Perpetual Loading begannen diese Firmen nicht mehr "ambitionierte" sondern realistische Planungen zu belohnen, ihre Teams anzuweisen, sich auf einzelne Vorhaben zu focussieren und nach dem Abschluss von Projekten ruhigere Phasen vorzusehen, in denen Reflektion, Regeneration, Abbau von Überstunden und die Planung und Vorbereitung zukünftiger Vorhaben stattfinden konnten.

Die Schlusspointe: obwohl diese Unternehmen nicht mehr ständig Druck auf ihre Mitarbeiter ausübten, schneller zu arbeiten, schneller zu Ergebnissen zu kommen und schneller neue Arbeit zu beginnen, wurden sie gerade dadurch produktiver, während diejenigen, die sich nicht aus der Beschleunigungs-Falle befreien konnten, stagnierten oder sogar ineffizienter und ineffektiver wurden. Ein Ergebnis, das allen Managern zu denken geben sollte, die den Wunsch verspüren, ihre Untergebenen anzutreiben.