On Lean and Agility

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.

Aus diesem Talk von Robert-Jan Huijsman kann man die folgende Idee mitnehmen: es gibt zwei Vorgehensmodelle, zwischen denen ein Entwicklungsteam hin- und herwechseln kann - einen der auf hohen Durchsatz optimiert ist, und einen der auf schnelle Reaktionen optimiert ist (ich würde das als Lean und Agile bezeichnen). Und es ist möglich, zwischen ihnen je nach Bedarf zu wechseln.

Was man bei dem von ihm vorgestellten Ansatz bedenken sollte ist, dass er in einem kleinen Startup entwickelt wurde. Er zeigt aber auch Ideen auf, mit denen eine Integration in grössere Organisation möglich ist, spezifisch solche zur Reduzierung von Frustrationsfaktoren und Unklarheiten.

Manche Ideen scheinen rund um die Welt ähnliche Assoziationen hervorzurufen, was man als Indikator dafür nutzen kann, dass tatsächlich etwas Relevantes dahintersteckt. Eine dieser Assoziationen ist auf den ersten Blick abwegig bis erschreckend, hat auf den zweiten aber eine gewisse Zwangsläufigkeit: es ist die Heranziehung von Terror-Zellen als "Idealbild" für Organisationen, die "Purpose-driven" sind, sich also ganz einem bestimmten Zweck verschrieben haben.

Die Gedanken dahinter sind folgende: der Purpose, also der über allem schwebende sinnstiftende Zweck, wird seit einigen Jahren als ein zentraler Erfolgsfaktor für Teams oder Unternehmen gesehen und findet sich explizit oder implizit in vielen Konzepten wieder, von der Produktvision über die North Star Metrics, die Customer Obsession und die Unternehmensmission bis hin zu den Big Bets. Grosser Erfolg wird (angeblich) dadurch möglich, dass alles andere dem Purpose untergeordnet wird.

Das klingt erstmal nach einer brauchbaren Arbeitshypothese, wird aber zu etwas Kontroversem wenn man sich fragt, was es denn bedeutet, wenn wirklich alles Andere untergeordnet wird. Denn "alles Andere" umfasst ja (unter anderem) die Gesetze, die Moral, die Gesundheit, die Wirtschaftlichkeit und die Verhältnismässigkeit. Hat man sich das erstmal bewusst gemacht, ist es relativ offensichtlich, dass Terrorzellen (von der RAF bis zur Al Quaida) Purpose-driven sind wie kaum jemand sonst.

Ich habe diese Vergleiche zwar schon mehrfach gehört, in Erinnerung geblieben sind mir aber vor allem zwei Personen, welche die gegensätzlichen Enden des Meinungsspektrums abbilden: Stefan Kühl, Soziologieprofessor aus Bielefeld, nutzte die Gleichsetzung um die drohenden Risiken einer Purpose-Instrumentalisierung herauszustellen, während Peter Sellis, ein Produktmanager aus dem Silicon Valley, Teams mit einer Selbstwahrnehmung als Terroristen-Organisation für erstrebenswert hält.

Die Ansicht von Kühl dürfte bei allen anschlussfähig sein, die irgendwo miterlebt haben, dass eine übergreifende Sinnstiftung so stark überhöht wird, dass eine Abweichung oder Nichtbefolgung als moralisch verurteilenswert erscheint. Vor allem in Gesinnungsbetrieben wie Kirchen und Gewerkschaften, aber auch in manchen Startups oder NGOs lässt sich eine an Fanatismus grenzende Überidentifikation immer wieder beobachten.

Die Ansicht von Sellis braucht dabei etwas mehr Erläuterung: sie ist im Kontext der extrem kompetitiven IT-Branche der US-Westküste zu sehen, die geprägt von Schlagworten wie Disrupt yourself oder Move fast and break things davon ausgeht, dass man ständig daran arbeiten sollte, das eigene Geschäftsmodell durch neue Ideen obsolet zu machen - um auf diese Weise noch innovativer zu sein als die Konkurrenz. Es gewissermassen das Ziel, ständig Teile der eigenen Strukturen wegzusprengen.

Am Ende glaube ich, dass es sich bei den Aussagen von Kühl und Sellis um zwei zusammengehörige Seiten der selben Medaille handelt. Die erste Sicht zeigt auf, dass eine Überhöhung einer Idee fast immer in einer ungesunden Destuktivität münden muss, die zweite hebt hervor, dass der Prozess einer schöpferischen Zerstörung im Sinn des Fortschritts von den Profiteuren des Ist-Zustandes als übertrieben und destruktiv empfunden werden kann und vielleicht sogar so empfunden werden muss.

Was beide Sichtweisen gemeinsam haben, ist ein hohes Ausmass an Polemik und bewusst herbeigeführter Kontroversität. Gerade weil der Begriff des Terrorismus (zu Recht) so negativ belegt ist führt seine Verwendung zur Selbst- oder Fremdbeschreibung fast zwangsläufig zu emotional aufgeladenen Debatten. Wenn man die auslösen möchte, ein brauchbares Mittel. Wenn man differenziert diskutieren möchte, empfiehlt sich dagegen ein eher dosierter Einsatz.

Bild: Flickr / CoCreatr - CC BY-SA 2.0

Jeder Mensch hat irgendwo in seiner Wahrnehmung der Welt blinde Flecken, und bei vielen Menschen, die beruflich mit dem Managen von Veränderungen beschäftigt sind, betreffen diese blinden Fecken paradoxerweise die Veränderungen selbst. Sie werden wie selbstverständlich als etwas Positives oder zumindest Natürliches wahrgenommen, und dass andere Personen eine ganz andere Sicht auf dieses Thema haben könnten, wird gar nicht in Betracht gezogen.

Das Buch The Problem with Change, geschrieben vom amerikanischen Manager und Unternehmensberater Ashley Goodall setzt an dieser Stelle an. Goodall ist nicht per se gegen Veränderungen, er sieht sie aber nur als Mittel zum Zweck und nicht als etwas Erstrebenswertes an sich. Und er weist darauf hin, dass die Ablehnung von Veränderung durch viele Menschen nichts Irrationales ist, sondern auf psychischen Bedürfnissen (bzw. deren Missachtung) beruht.

Zu den Problemen, die seiner Beobachtung nach die Veränderungen in Organisationen für deren Angehörige mit sich bringen, gehören Ungewissheit über die (berufliche Zukunft), Gefühle von Kontrollverlust und verlorengehender Zugehörigkeit, der Verlust gewohnter Umgebungen und der Verlust von sinnstiftenden Grundlagen der eigenen Arbeit  (Zielen, Missionen, erreichten Erfolgen, etc.). All das wirkt sich negativ auf die Psyche der Betroffenen aus.

Dabei sieht Goodall im Eintreten dieser Effekte keineswegs eine Zwangsläufigkeit. Er beschreibt eine Reihe von Massnahmen, mit denen das Management ihnen entgegenwirken kann, u.A. die Gewährung von Freiräumen bei der Mitgestaltung der Veränderungen, das Aufzeigen von Selbstwirksamkeit, Transparenz und Ehrlichkeit (auch wenn das anstrengend und unangenehm sein kann) und das Erhalten von Stabilität gebenden Elementen (Routinen, Umgebungen, Zugehörigkeiten, etc.). 

Der aus meiner Sicht spannendste Ansatz ist der, der im Buch die "Radikalisierung von HR" genant wird. Statt sich bei in Veränderungsprozessen auftretenden Konflikten zwischen Management und Belegschaft auf eine Seite zu schlagen, sieht er die Aufgabe der Personalabteilungen darin, beiden Seiten zu vermitteln, dass ihre Ziele sich ergänzen und überlappen, weshalb beide ein Interesse daran haben sollten, zusammenzuarbeiten, statt gegeneinander - auch jenseits der Komfortzonen.

Ich habe eine ganze Reihe von Change Managern, HR-Kräften, Agile Coaches, Unternehmensberatern und sonstigen veränderungsbegleitenden Berufen erlebt, denen das Lesen von The Problem with Change gutgetan hätte, und ebenfalls vielen, die ohne das Buch zu kennen seine Grundideen verstanden und angewandt haben. Wenig überraschend haben die Ersten ihre Veränderungsvorhaben regelmässig vor die Wand gesetzt, während die Zweiten sie meistens erfolgreich gestalten konnten.

Original-Grafik: XKCD.com - CC BY-NC 2.5

Wir erleben bei diesem Bild die Magie der Creative Commons: jemand hat die unter der CC BY-NC 2.5-Lizenz veröffentlichte ursprüngliche Grafik von XKCD genommen, um einen dritten Teil ergänzt und sie damit um eine weitere Dimension bereichert (gefunden in irgendeinem Forum).

Bild: Pexels / Ekam Juneja - Lizenz

Ralph Jocham: Scrum's Protocol Is Easy to Copy. Its Agenda Is Not.

Steve Blank: AI Killed the MVP – Long Live the IUP

Maarten Dalmijn: Mastering the Four Abstraction Levels of Refinement

Chee-Hong Hsia: Hi Scrum Masters, if your goal is to make yourself obsolete, then you're doing it all wrong.

Christoph Laskowski: Warum Mikel Arteta sein eigenes Team sabotiert