On Lean and Agility

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.

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.