On Lean and Agility

Bild: Unsplash / Jessica Gale - Lizenz

Ich kann es nicht mehr genau nachvollziehen, aber mittlerweile dürfte ich über hundert Job-Interviews mit Scrum Mastern, Agile Coaches und Inhabern ähnlicher Rollen geführt haben, sowohl für meine eigene Firma als auch für verschiedene Kunden. Und selbst wenn es die eine entscheidende Antwort auf sie nicht gibt, mit der Zeit habe ich eine Frage gefunden, mit der sich gut feststellen lässt, ob mein aktueller Gegenüber wirklich verstanden hat, was es mit dem Konzept der Agilität auf sich hat.

Sie ist relativ einfach: "Gibt es irgendeinen Kontext, in dem es nicht sinnvoll ist, agil zu arbeiten?" Erstaunlich viele Bewerber verneinen das und versteifen sich darauf, dass es immer sinnvoll wäre, agil vorzugehen. Und wenn man darum bittet, das zu erklären, erfolgt fast immer die selbe Erläuterung: "Es gibt immer irgendetwas, was man besser machen kann. Deshalb ist es grundsätzlich in jeder Situation eine gute Idee, agil vorzugehen".

Der grundsätzliche Denkfehler, der dieser Argumentation zu Grunde liegt (und durch den man zeigt, die Idee der Agilität noch nicht zur Gänze verstanden zu haben) ist die Gleichsetzung von agilem Arbeiten mit der Suche nach Verbesserungspotential. Dabei handelt es sich allerdings um eine Verwechselung der notwendigen und der hinreichenden Bedingung. Wer agil arbeiten will, muss zwar nach Verbesserungen suchen, aber nicht jeder der nach Verbesserungen sucht, arbeitet agil.

Um das zu erläutern: eine agile Vorgehensweise unterscheidet sich von der blossen Suche nach Verbesserungspotential durch zwei Eigenschaften: sie findet kontinuierlich statt und sie ist potentiell disruptiv. Und auch die lassen sich nochmal besser erläutern, angefangen mit der ersten. Eine Suche nach Verbesserungen könnte auch jährlich oder quartalsweise stattfinden. Um das agil-typische ständige Inspect & Adapt zu erfüllen reicht das aber nicht - kontinuierlich bedeutet hier eher monatlich.¹

Jetzt zur zweiten, etwas schwerer zu erklärenden Eigenschaft: die blosse Suche nach Verbesserungen kann auch lediglich auf Effizienzsteigerungen ausgerichtet sein, also darauf, einfach schneller und reibungsloser zu arbeiten. Agiles Arbeiten ist dagegen auf Effektivitätssteigerung ausgerichtet, also auf die Frage, ob überhaupt noch am richtigen Thema gearbeitet wird, oder ob sich Rahmenbedingungen oder Ziele inzwischen so geändert haben, dass man eine grundsätzlich andere Richtung einschlagen solllte.

Diese Möglichkeit, die bisher verfolgten Zielsetzungen anzupassen, ist das, was agiles Arbeiten disruptiv macht. Und da diese Richtungsanpassung nichts ist, was man bei jeder Verbesserungsbemühung zwangsläufig machen sollte, sondern nur dann, wenn man darin einen Sinn erkennt, ist Agilität nicht zwangsläufig disruptiv sondern lediglich potentiell disruptiv. Es kann zu einer grundsätzlichen Anpassung kommen, es muss aber nicht. Notwendige und der hinreichende Bedingung.

Um auch die anderen Vorgehensmodelle beim Namen zu nennen - seltene (bzw. nicht-kontinuierliche) Veränderungen entsprechen dem klassischen Verbesserungsmanagement, dessen explizites oder implizites Ziel die (Wieder-)Herbeiführung eines stabilen Zustandes ist. Und kontinuierliche, aber nicht disruptive Optimierungen finden sich im Lean Management, das einen gleich bleibenden Ablauf nach und nach immer effizienter machen will.

Diese drei Typen (agiles Arbeiten, klassisches Verbesserungsmanagement und Lean Management) unterscheiden zu können ist etwas, das jeder Scrum Master oder Agile Coach eigentlich beherrschen sollte - zumindest dann, wenn er in einer beratenden Funktion arbeitet, sei es extern (wie in meiner Firma) oder intern (als Change Agent innerhalb einer Organisation). Kann man das noch nicht ist das zwar kein Drama, aber ein deutlicher Hinweis darauf, wo noch dazugelernt werden muss.

Zu den wichtigsten Praktiken des Extreme Programming gehört der Einsatz von Metaphern, mit deren Hilfe man komplexe Sachverhalte einfach erklären kann. Zu den prominenteren Beispielen der letzten Zeit gehören dabei the Desert and the Forest von Kent Beck und Beth Andres-Beck. Der Wald (Forest) steht dabei für eine Umgebung, in der moderne Software-Entwicklungspraktiken möglich sind, während sie in der Wüste (Desert) nicht angewandt werden können. In diesem Konferenz-Vortrag erklären sie, was sich hinter diesen Metaphern verbirgt.

Erwähnenswert ist dabei ihre Einordnung ihres Konzepts in die Realitäten der Softwareentwicklung in vielen Firmen. Die Wüste gilt bei ihnen nicht als etwas per se Schlechtes, sondern als etwas was historisch gewachsen ist, durchaus Ergebnisse bringen kann (wenn auch relativ langsam) und durch die richtigen Entscheidungen nach und nach zu einem Wald werden kann.

Vor einiger Zeit reifte in einer Behörde, deren IT-Projekte ich begleiten durfte, die Einsicht, dass die eigenen Prozesse zu starr und zu langwierig waren. Um dem zu begegnen wurde ein neues "Referat für den Abbau von Bürokratie" geschaffen, das dem entgegenwirken sollte. Seine erste Amtshandlung bestand darin, alle anderen Referate anzuweisen, alle ihre Arbeitsabläufe detailliert zu dokumentieren. Auf Basis dieser Dokumente sollte dann entschieden werden, wo Bürokratie abgebaut werden könnte.

Dieses widersinnige Vorhaben (das nicht zu weniger sondern zu mehr Verwaltungsaufwand führte) gehört zu einem Trend, den der Soziologie-Professor Stefan Kühl treffend als "Bürokratisierung der Entbürokratisierung" beschrieben hat. Hinter ihm verbergen sich die zunehmend verbreiteten Massnahmen, Bürokratieabbau, Digitalisierung, Effizienzzsteigerung und ähnliche Dinge dezidierten Organisationseinheiten zuzuordnen - und damit versehentlich alles nur noch schlimmer zu machen.

Diese Verschlimmerung ergibt sich aus verschiedenen, mit grosser Wahrscheinlichkeit eintretenden Dynamiken. Zunächst gibt es für die neue Zentraleinheit starke Anreize, Informierungs-, Beteiligungs- und sonstige Pflichten anzuordnen, wodurch es wie im Fall des oben genannten Bürokratieabbau-Referats dazu kommen kann, dass alleine der dadurch notwendige Kommunikationsaufwand zu der perversen Konsequenz führt, dass alles ineffizienter wird statt effizienter.

Wenn es darüber hinaus dazu kommt, dass nicht nur über die eigenen Prozesse berichtet werden muss, sondern Änderungen an ihnen zentral begutachtet und ggf sogar genehmigt werden müssen, wird die dafür zuständige Einheit zu einem verlangsamenden Flaschenhals für alle anderen. Schlimmstenfalls kann es dazu kommen, dass selbst dringende und von allen gewollte Änderungen lange verzögert werden, weil die für die Freigabe zuständigen Personen überlastet sind.

Als Folge dessen kann es sogar zu nochmals weiteren Verschlechterungen kommen: um eine eigene Überlastung zu verhindern oder abzubauen neigen viele Zentraleinheiten dazu, der restlichen Organisation einheitliche Vorgehensmodelle oder Berichtsformate vorgeben zu wollen, um deren Lage einfacher verstehen und vergleichen zu können. Diese Vereinheitlichung kann oft nur auf Kosten der optimalen Bedienung der lokalen Bedürfnisse erreicht werden.

Gleichzeitig entstehen demotivierende Auswirkungen für die dezentralen Einheiten. Wenn plötzlich alle eigenen Verbesserungsbemühungen zu Dokumentations- und Kommunikationsmehraufwand führen und darüber hinaus befürchtet werden muss, dass von aussen gut gemeinte Verschmlimmbesserungen stattfinden, dann ist das ein Anreiz, solche Bemühungen gar nicht mehr (oder nur lokal, unangekündigt, unabgestimmt und intransparent) durchzuführen.

Zuletzt stehen Bürokratieabbau-Einheiten aufgrund der mit ihnen verbundenen Erwartungen und Aufwände unter hohem Erfolgsdruck, der (vor allem dann wenn die Erfolge Voraussetzung für Gehalts-, Karriere- und Statusverbesserungen sind) dazu führen kann, dass Fortschritte aufgebauscht und voreilig oder wahrheitswidrig verkündet werden, mit der Folge, dass vordergründig Verbesserungen stattzufinden scheinen, während in Wahrheit Verspätung, Stillstand und Verschlechterungen vorherrschen.

Die Zuordnung von Bürokratieabbau, Digitalisierung, Effizienzzsteigerung, etc. zu dezidierten Organisationseinheiten ist aus all diesen Gründen mit dem hohen Risiko verbunden, das Gegenteil des Angestrebten zu erreichen. Ein wesentlich besserer Weg kann es sein, dezentrale Freiräume für Verbesserungsbemühungen (incl. Zeit und Budget) zu schaffen, alleine verbunden mit der Bedingung einer transparenten Durchführung, um auf versehentliche Fehlentwicklungen hinweisen zu können.

Bild: Wikimedia Commons / JCS - CC BY 3.0

Sobald agiles Arbeiten über die Teamebene hinaus in einem Unternehmen etabliert werden soll, stossen praktisch alle agilen Frameworks auf das immer gleiche Problem: oberhalb der Teams und um die Teams herum gibt es vor allem in grösseren Firmen eine unberschaubare Zahl von Management-Rollen. Teilprojekt-, Projekt- und Programmleiter, Test-, Release- und Security Manager, Heads of Legal, Product und Sales, Team- Abteilungs- und Bereichsleiter und viele, viele mehr. Was macht man jetzt mit denen?

In den meisten Fällen gibt es darauf keine klaren Antworten; Scrum, Kanban, DevOps und fast alle weiteren agilen Vorgehensmodelle befassen sich einfach nicht mit diesem Thema, was Unklarheit und Unsicherheit zur Folge hat. Schlimmstenfalls erwächst aus dieser Unklarheit sogar ein Konflikt - wenn den verschiedenen Managern gesagt wird, dass sie im Umfeld selbstorganisierter Teams bald nicht mehr benötigt werden, werden die meisten von ihnen natürlich um ihren Status und ihre Karriere kämpfen.

Und auch das gehört dazu: viele der bisherigen Management-Aufgaben können nicht so einfach dezentral in alle Teams delegiert werden. Irgendjemand muss die grossen strategischen Entscheidungen treffen, irgendjemand muss Ansprechpartner für Gehaltsverhandlungen, Beförderungen, Versetzungen und Eskalationen sein, und irgendjemand muss letzten Endes die Verantwortung tragen, wenn es um zivilrechtliche Haftungsfragen geht, etwa wegen Verstössen gegen Arbeitsschutz oder Compliance.

Das meines Wissens nach einzige agile Framework, dass diese Umstände in seinem Regelwerk berücksichtigt (wenn man von einigen offensichtlich nur halb-ernst gemeinten Management-Rollen in Extreme Programming absieht) ist das Scaled Agile Framework/SAFe, in dem eine Rolle enthalten ist, die einen Grossteil der oben genannten Verantwortungen enthalten kann - wenn auch nicht in jedem Fall enthalten muss. Die Rede ist von dem Business Owner (BO).

Auf der entsprechenden Website beschreibt SAFe fünf Aufgabenbereiche, die ein BO haben kann: Leading by Example, Engaging in Lean Portfolio Management, Aligning Priorities & PI Planning, Realizing Business Outcomes und Sponsoring Relentless Improvement. Wie vieles andere in diesem Framework ist das im Folgenden gleichzeitig hinreichend unkonkret um individuell ausgestaltet zu werden und spezifisch genug um "agile Puristen" zu provozieren.

Zu den hinreichend unkonkreten Formulierungen, mit denen die fünf Aufgabenbereiche beschrieben werden, gehören beispielsweise mehrere, in denen davon die Rede ist, durch eigenes Verhalten ein Vorbild zu sein, Visionen zu kommunizieren, anderen Führungsrollen zu helfen, den Geschäftskontext zu vermitteln, den Teams Feedback zu geben und andere zu motivieren. Dahinter kann sich alles Mögliche verbergen, von der Sonntagsrede bis zur Hands On-Unterstützung.

Provozierend für agile Puristen sind weitere Formulierungen, die implizieren, dass die Business Owner Aufgaben übernehmen können, die auch von selbstorganisierten Teams direkt übernommen werden könnten. Das Vermitteln bei internen Konflikten und Widerständen gehört dazu, das Organisieren teamübergreifender Communities of Practice, Stakeholdermanagement, Abhängigkeitsmanagement, die Beseitigung von Impediments, die Definition von KPIs und die Optimierung von Arbeitsflüssen.

Während diese beiden Aufgabenbereiche diskutierbar und ggf. verzichtbar sind, gibt es aber einen dritten, der unverzichtbar und entscheidend ist - das Schaffen optimaler Rahmenbedingungen: Business Owner sind zuständig für die Bereitstellung von ausreichend Budget, Personal und Ressourcen, für das Setzen und Anpassen strategischer Ziele sowie für das Beseitigen demotivierender Vorschriften und Prozesse. Das sind Schlüsseltätigkeiten, auf deren Basis Selbstorganisation überhaupt erst möglich ist.

Insgesamt ergibt sich so ein für SAFe typisches Bild: mit der BO-Rolle werden Dinge thematisiert und formalisiert die wichtig sind, in anderen agilen Frameworks aber nicht erwähnt werden. Gleichzeitig sind sie aber eingebettet in eine Menge weiterer derartig unscharf formulierter Vorgaben, dass auf deren Basis praktisch alles möglich ist, unterstützender von Hilfe zur Selbstorganisation bis hin zu übergriffigem Hineinregieren in die Teams.

Um das Positive darin zu sehen - wenn man im Unternehmen ein Management mit einer (aus einer "agilen Perspektive") "richtigen" Einstellung hat, kann man seine Mitglieder als Business Owner auf passende, hilfreiche und sinnstiftende Weise einbinden. Wenn auf der anderen Seite eine eher "falsche" Einstellung vorherrscht, würde auch ein methodischer Rahmen ohne diese Rolle nur in begrenztem Ausmass für Verbesserung sogen. In diesem Sinn: gebt den BOs eine Chance.

Es kommt nicht mehr oft vor, dass eine neue Art der Software-Programmierung erfunden wird, aber es kommt vor, zuletzt im Februar 2025 durch Andrej Karpathy, einen slowakisch-kanadischen Software-Entwickler und ehemaligen Manager von Tesla und OpenAI. Der neue Programmier-Stil wurde von ihm in einem Posting im Social Nework X zum ersten mal beschrieben und Vibe Coding genannt. In kurzer Zeit erreichte er weitgehende Bekanntheit. Hier ist seine Beschreibung:

Zu Deutsch: Vibe Coding benötigt eine künstliche Intelligenz mit Spracherkennung. In der Interaktion mit dieser gibt man sich ganz seiner gegenwärtigen Stimmung (den Vibes) hin, äussert Wünsche und Vorstellungen und und lässt die KI auf diese Weise fast ausschliesslich durch Spracheingabe ein Stück Software erstellen, das dann irgendwann mehr oder weniger fertig und lauffähig ist. Mit Karpathys eigenen Worten: "just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works".

Aufbauend auf diesen Beitrag kam es in kurzer Zeit zu zahlreichen Artikeln in Medien wie Fortune, Forbes, TechCrunch und New York Times, die grossteils den selben Tenor hatten: Programmieren lernen ist nicht mehr nötig, auch als Laie kann man jetzt Software erstellen. Viele dieser Beiträge waren ausserdem verbunden mit marktschreierischen Verheissungen (jeder kann jetzt ein Startup gründen und reich werden) oder Untergangsszenarien (alle Entwickler werden bald arbeitslos sein).

Dass all das erkennbar an der Realität vorbeigeht hätte man dabei bei einem sorgfältigeren Lesen von Karpathys Post leicht erkennen können. Wie er selbst schreibt und wie kritische Stimmen bald anmerkten führt Vibe Coding dazu, dass selbst der "Urheber" nicht mehr genau sagen kann, wie sein Code entstanden ist und was er im Detail tut. Im besten Fall führt dieser Blindflug zu vielen kleinen Bugs, im schlechtesten Fall zu schweren Fehlfunktionen. Zum Herumspielen ist das gut, zu mehr aber nicht.

In diesem Herumspielen steckt allerdings auch eine Potential, das man nicht verachten sollte: mit Vibe Coding erstellte Anwendungen taugen zwar nicht für echte Markt- oder Produktions-Anwendungen, was sie aber sein können sind erstaunlich realitätsnahe Prototypen, mit denen man in Product Discovery oder Lean Startup Nutzerbedürfnisse und Nutzungsbereitschaft evaluieren kann, um sich dann schnell dem Bedarf anzupassen - frühe Entwicklungsphasen lassen sich so deutlich beschleunigen.

Und was ebenfalls oft nicht ausreichend beachtet wird: das "Programmieren" mit Hilfe gesprochener Prompts führt dazu, dass Anforderungen wesentlich klarer und präziser formuliert werden müssen als das in den meisten klassischen Anforderungs-Dokumenten der Fall ist, die oft eher kryptisch, verschachtelt und inkonsistent sind. Am Ende hat man im Vibe Coding also gleich zwei Ergebnisse - einen vorführbaren Prototyp und klarer formulierte Wünsche und Anforderungen.

Grafik: Pixabay / Brian Penny - Lizenz

Lavaneesh Gautam: Behind the Bottlenecks - The Root Causes of Dependencies in Teams

Roman Pichler: Setting up Product Teams for Success

Militarnyi: Saab Develops Anti-Aircraft System in Record 84 Days

Pawel Rola: Product Backlog Management with Upstream Kanban – From Chaos to Clarity

John Ward: Agile marketing - The source of enterprise agility

Bild: Flickr / McKinney75402 - CC BY 2.0

Unter den verschiedenen "Gesetzmässigkeiten", die in Projektmanagement-Kreisen gerne zitiert werden, nimmt das Gesetz der unbeabsichtigten Konsequenzen eine Sonderstellung ein. Anders als fast alle anderen (Conway's Law, Gall's Law, Goodhart's Law, etc) ist es nicht nach einer Person benannt, die es erfunden und popularisiert hat, sondern ist nach und nach in den Wirtschafts- und Sozialwissenschaften entwickelt worden, u.a. von John Locke, Adam Smith und Friedrich Hayek.

Sie alle hatten unabhängig voneinander die folgende Einsicht: wer in komplexen, vernetzten oder volatilen Systemen Veränderungen vornimmt, der wird nicht nur den Effekt erzielen den er beabsichtigt,¹ sondern auch andere, unbeabsichtigte. Zu einem "Gesetz" wird es dadurch, dass diese ungewollt eintretenden Konsequenzen praktisch unvermeidbar sind, einzig ihre Art und Intensität kann von Fall zu Fall anders sein. Vereinfacht gesagt sind mindestens sechs verschiedene Varianten möglich:

Unerwartete positive Konsequenzen

Der beste Fall der eintreten kann, in ihm treten positive Effekte auf, mit denen man gar nicht gerechnet hatte. Ein Beispiel wäre ein Sparkurs, durch den ein Grossprojekt auf nur noch wenige Teams zusammenschrumpft. Da diese jetzt jeweils mehr Themengebiete abdecken müssen, werden sie crossfunktionaler und weniger arbeitsteilig, wodurch nicht nur die Personalkosten sinken, sondern auch der bisherige Koordinationsaufwand und mit ihm weitere Kosten.

Unerwartete negative Konsequenzen

Das Gegenteil des ersten Falls. Ein Beispiel dafür wäre die Neueinführung gehaltsrelevanter Ziele für einzelne Mitarbeiter. Die arbeiten dann zwar mit gesteigerter Motivation an diesen Zielen, aber das im Zweifel auch auf Kosten der gemeinsamen Team- oder Unternehmensziele. Ein Sicherheitsbeauftragter, der für jeden gefundenen Regelverstoss belohnt wird, hat etwa einen starken Anreiz, seine Kollegen mit einer lähmenden und demotivierenden Kontroll-Bürokratie zu überziehen.

Unerwartete perverse Konsequenzen

Eine derartige Übersteigerung der negativen Konsequenzen, dass es sogar zu einer Verschlechterung in dem Bereich kommt, der eigentlich verbessert werden sollte. Ein bekannter Fall der Versuch, durch die Einführung von gemeinsamen Grossraumbüros die Kommunikationsbarrieren zwischen Mitatarbeitern abzubauen. Forschungsergebnisse zeigen, dass das Gegenteil der Fall ist - um den Geräuschpegel auszublenden werden Headsets aufgesetzt, wodurch die Kommunikation sogar zurückgeht.

Unerwartete positive Seitenauswirkungen

In diesem Fall treten unbeabsichtigte positive Effekte auf, die ihre Auswirkungen in einem anderen Bereich entfalten als dem, in dem die Veränderungen stattgefunden haben. So können Programme zur Förderung von Achtsamkeit und Sorgfalt nicht nur zu geringeren Fehlerquoten bei der Arbeit führen, sondern auch zu einem generell bewussteren und verantwortungsvolleren Konsumverhalten, wodurch im Privatleben der Beteiligten weniger Haushaltsmüll erzeugt wird.

Unerwartete negative Seitenauswirkungen

Wieder das Gegenteil des letzten Falls, hier tretennegative Effekte in einem anderen Bereich auf als dem, in dem die Veränderungen stattgefunden haben. Wenn eine Firma beispielsweise Kosten senken will indem sie von externen Mitarbeitern Gebühren für die Nutzung des eigenen Parkhauses verlangt, wird sie dadurch die Verkehrs- und Parkplatz-Situation in der Nachbarschaft verschlechtern, da auf die hier befindlichen Pakkplätze ausgewichen wird.

Sonstige unerwartete Seitenauswirkungen

Auch das gibt es - unbeabsichtigte Auswirkungen auf andere Bereiche als den, in dem die Veränderungen stattgefunden haben, die weder positiv noch negativ sind. Ein anschaulicher Fall dafür wäre eine Firma, die im Rahmen eines Corporate Design-Relaunch die Farbe ihrer Dienstwagen von Gelb zu Grün ändert. Das Strassenbild der Umgebung wird das zwar verändern, allerdings nicht zum Besseren oder Schlechteren, es sieht einfach nur anders aus.

Welche auch immer es sind, die Gemeinsamkeit der verschiedenen unbeabsichtigten Konsequenzen ist, dass sich weder ihre Art noch die Schwere ihrer Auswirkungen vorhersagen lassen. Dort wo in komplexen, vernetzten oder volatilen Systemen Veränderungen vorgenommen werden, ist es daher eine gute Idee, regelmässig zu überprüfen, ob derartige Effekte auftreten. Nur dann ist es möglich ggf. schnell Gegenmassnahmen zu ergreifen. Auch hier gilt also wieder: Inspect & Adapt.

Bild: Pexels / Moe Magners - Lizenz

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, etc.) mit der Zeit eine eher negative Weltsicht entwickeln ist schade, aber erklärbar. Wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht in Frustration und Fatalismus abrutschen. Um nicht selbst in dieses Muster verfallen, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Diese hier habe ich mehrfach in ähnlicher Form erlebt, aber die an die ich gerade denke, begann damit, dass ich als externer Scrum Master oder Agile Coach in eine Firma gekommen bin und dort Teams vorgefunden habe, die mir gleich zu Beginn Eines unmissverständlich klar machen wollten: dass es agiles Arbeiten bei ihnen nicht geben würde. Sie hätten das bereits versucht gehabt, es sei furchtbar gewesen und sie wären heilfroh, es zugunsten eines besseren Vorgehens  hinter sich gelassen zu haben.

Bedingt dadurch, dass ich diese Erfahrung wie gesagt bereits mehrfach gemacht habe, lasse ich mich in derartigen Situationen zunächst noch auf keine Diskussion über das zukünftige Vorgehen ein, sondern lasse mir zuerst erklären, warum der agile Arbeitsmodus als so furchtbar empfunden wurde und was den stattdessen gewählten so viel besser macht. Und es stellte sich dabei heraus, dass hier zwei aufeinander aufbauende Missverständnisse vorlagen.¹

Das erste dieser Missverständnisse betraf das, was dort irgendwann mal unter dem Namen "Agile" eingeführt worden war. Mit der zugrundeliegenden Idee hatte das eher wenig zu tun, stattdessen wurden lediglich zusätzlich zu den bereits bestehenden (und z.T. unverändert gültigen) Prozessen einzelne aus Scrum oder SAFe entlehnte Meetings, Titel und Begriffe eingeführt, die aber ohne geänderte Rahmenbedingungen nichts verbessert sondern nur alles verkompliziert hatten. Cargo Cult also.

Aufbauend darauf war das zweite Missverständnis entstanden. Da "Agile" als komplizierter, unverständlicher und bürokratischer Prozess wahrgenommen wurde, hatten die Teams stattdessen ein Alternativvorgehen entwickelt, dass auf direkter Kommunikation, crossfunktionaler Zusammenarbeit, wenigen Regeln, kurzen Lieferzyklen und regelmässigen Prozessverbesserungen beruhte.² Folgerichtig hielten sie dieses Vorgehen für nicht-agil und dem agilen Arbeiten überlegen.

Als ich auf diese beiden Missverständnisse hinwies, und darauf, dass der "nicht-agile Arbeitsmodus" in Wirklichkeit sehr agil war, waren zunächst Überraschung und Unglaube gross. Erst nachdem sich einige Teammitglieder bereiterklärten, einige der Originalquellen (Scrum Guide und Agiles Manifest) zu lesen, setzte sich langsam die Erkenntnis durch, dass sie die Idee falsch verstanden hatten, und durch die Abwehr der Cargo Cult-Methode "versehentlich" agil geworden waren.

Wirklich warm geworden sind sie mit dem Begriff zwar nicht mehr, dafür hatten sie sich bereits zu sehr auf ihn eingeschossen. Aber ganz ehrlich - sie waren nah am Kunden, lieferten regelmässig Mehrwert aus, passten das eigene Vorgehen regelmässig an und arbeiteten gut zusammen. Angesichts dessen war die Ablehnung des Wortes "Agil" ein Thema, das man mit gutem Gewissen vernachlässigen konnte. Wenn das Ergebnis stimmt, ist der Name des Prozesses nicht so wichtig.