On Lean and Agility

Die Entwicklung einer negativen Weltsicht durch viele "agile Methodiker" (Agile Coaches, Scrum Master, etc.) ist ein bedauenswertes, aber auch menschlich verständliches Phänomen - wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann leicht in Frustration abrutschen. Um nicht selbst in dieses Muster verfallen, veröffentliche ich ab und zu selbst erlebte "agile Erfolgsgeschichten", um zu zeigen, dass vieles auch gut läuft.

In dieser hier geht es um das Durchführen einer Konzern-Reorganisation. Besagter Konzern hatte in den Jahren zuvor bereits mehrere Reorganisationen durchgeführt, und alle Beteiligten waren sich einig, dass sie nur mittelgut verlaufen waren. Am Anfang hatte es zwar jedesmal gut durchdachten Pläne gegeben, sobald die auf die Realität trafen, hatten sie sich aber jedesmal als lückenhaft erwiesen. Die Anpassung an die Realität hatte dann jedesmal zu Bürokratie, Unordnung und Unzufriedenheit geführt.

Das neue Vorgehen, mit dem es diesesmal anders werden sollte, sah zunächst vor, die Veränderungen in Arbeitspakete aufzuteilen, die nach und nach, in Abständen von wenigen Wochen, ausgeliefert werden sollten. Das Besondere daran: spätere Schritte wurden bewusst noch nicht ausdetailliert, stattdessen wurde nach jeder Auslieferung ein Feedback-Prozess gestartet, auf dessen Basis die Detaillierung angepasst wurde. Sogar das Rückgängigmachen früherer Reorganisationsschritte war ggf. möglich.

Um es an Beispielen konkret zu machen: ein erstes Arbeitspaket war die grundsätzliche Aufteilung und Bündelung von Zuständigkeiten, ein zweites der darauf aufbauende Zuschnitt der Bereiche und Abteilungen, ein drittes die Besetzung der Leitungspositionen, ein viertes die Zuordnung derjenigen Mitarbeiter, deren Tätigkeitsprofil das eindeutig zuliess, ein fünftes die Zuordnung der nicht ganz so eindeutigen Fälle, ein sechstes die Verteilung der neuen Einheiten auf die Büros.¹

Der Feedback-Prozess, der nach der Fertigstellung von jedem dieser Arbeitspakete folgte, bestand aus mehreren Dimensionen. Zum einen gab es Versammlungen der (bisherigen) Standorte und Abteilungen, in denen Fragen, Bedenken und Hinweise geäussert werden konnten. Parallel dazu wurden Mitarbeiter aus allen Organisationseinheiten zu Teilzeit-Change Managern ernannt, die dort Ansprechpartner waren und Rückmeldungen sammelten. Zuletzt gab es physische und virtuelle Feedback-Briefkästen.²

Die Erkenntnisse aus diesen Feedbacks waren zum Teil sehr wertvoll. An einer Stelle wurde z.B. darauf hingewiesen, dass beim Abteilungsschnitt eine Zuständigkeitslücke gelassen wurde, an einer anderen Stelle, dass die Aufteilung bestimmer Aufgaben auf zwei Abteilungen zwar theoretisch möglich, in der Realität aber schwierig umzusetzen sein würde, da sie bisher von den selbem Personen durchgeführt wurden. Mehrfach führte das zu Anpassungen, die ebenfalls wieder Gegenstand von Feedback wurden.

Dass diese Anpassungen mit verhältnismässig gerigem Aufwand durchgeführt werden konnten, war vor allem dem Verzicht auf zu frühe Detailplanung zu verdanken. So wären in den beiden erwähnten Beispielen die Korrekturen der suboptimalen Abteilungsschnitte deutlich schwieriger gewesen, wenn zu dem Zeitpunkt bereits alle Versetzungen in diese Einheiten stattgefunden hätten. Da die Versetzungen jetzt erst in einem nächsten Schritt stattfanden, entstanden die Probleme gar nicht erst.

Als Nebeneffekt wurde auch die Kommunikation der Veränderungsmassnahmen deutlich einfacher. Statt alle Veränderungen auf einmal konsistent erklären und als Ganzes verstehen zu müssen, wurde jeweils nur auf das aktuelle Arbeitspaket vertieft eingegangen, bei den späteren reichte eine kurze Ankündigung des Inhalts und des geplanten Zeitpunkts. Sowohl im Kommunikationsteam als auch in der Belegschaft wurde das im Vergleich zu früheren Reorganisationen als deutliche Verbesserung empfunden.

Eine Pointe dieser Geschichte hier ist, dass das in ihr beschriebene Vorgehen, nie offiziell als "agil" konzipiert oder bezeichnet wurde. Stattdessen ging es nach Ansicht aller Beteiligten lediglich auf Common Sense und Erfahrungswerte zurück, aus denen sich ganz selbstverständlich die hier beschriebenen Schritte ergaben. Erst ganz zum Schluss fiehl einem Vorstand auf, dass es offensichtliche Parallelen zur agilen Produktentwicklung gab. Grösser thematisiert wurde das aber nie.

Dass es von jedem agilen Framework in der Realität sehr unterschiedliche Ausprägungen gibt, dürfte jeder wissen, der verschiedene agil arbeitende Unternehmen gesehen hat. Zu den Gründen dafür gehört zum einen ein bewusst offen gelassener Gestaltungsspielraum, zum anderen aber auch versehentliche oder absichtliche Verfremdungen der ursprünglichen Idee. Das trifft auf Scrum zu, auf Kanban, auf OKRs, aber auch auf das Scaled Agile Framework (SAFe).

SAFe ist dabei aber in einem Aspekt deutlich anders als die anderen Frameworks: während sich deren Variantenvielfalt u.a. daraus ergibt, dass sie sich in einem Spannungsfeld zwischen einem praxisnahen Graswurzel-Ursprung und einer später entstandenen starken Kommerzielisierung bewegen, ist SAFe bereits in seinen Ursprüngen kommerziell angelegt. Sämtliche seiner Varianten sind dadurch Teil des Beratungs- und Zertifizierungs-getriebenen agil-industriellen Komplexes.¹ Hier sind sie:

The Little Agile Release Train

Die vielleicht häufigste Variante, wenn auch oft mit anders benannten Namen und Rollen.² Drei bis zehn Teams arbeiten in synchronisierten Sprint-Rhythmen, es gibt eine übergreifende Quartalsplanung und oberhalb der Product Owner und Scrum Master einen Produktmanager / Chief Product Owner und Release Train Engineer / Chief Scrum Master, der ihnen jeweils übergeordnet ist. Für sich genommen eine noch relativ schlanke, agile und halbwegs unbürokratische SAFe-Umsetzung.

The Feature Factory

Die Grössenordnung, die die Aussenwahrnehmung von SAFe am stärksten prägt. Ab einer Größe von mehr als zehn Teams ist ein Release Train nicht mehr ausreichend, es werden mehrere parallel zueinander eingerichtet, über denen dann eine zusätzliche Hierarchieebene mit einem Solution Manager und einem Solution Train Engineer entsteht. Feedback-Schleifen und Nähe zwischen Entwicklern und Anwendern sind nur noch schwer möglich, es werden vor allem Feature Requests abgearbeitet.

Disruptive SAFe

Während der einzelne Release Train und die Feature Factory die alten Strukturen einer Firma noch weitgehend unangetastet lassen, hat SAFe einige optionale Elemente, deren Anwendung einiges durcheinanderwerfen würde, z.B. die Koppelung der Budgetierung an Teams statt an Features oder die Ausrichtung der Planungen an Value Streams statt an Roadmaps. Aus einer "agilen Perspektive" sehr wünschenswert, kommt aber in der Realität nur sehr selten vor.

Absorbed SAFe

Dort, wo (warum auch immer) alles in einem einzigen, grossen agilen Framework organisiert werden soll, die Auswirkungen von disruptivem Safe den Verantwortlichen aber zu weit gehen, ist es eine häufige Reaktion, so lange Anpassungen vorzunehmen, bis zentrale Elemente des bisherigen Vorgehens nicht mehr angetastet werden. Das Ergebnis können Hybrid-Frameworks wie SpotiSAFe sein, ggf. aber auch einfach eine Erweiterung oder Beschneidung des SAFe-Umfangs an entscheidenden Stellen.

Post-SAFe

Mittlerweile erstaunlich häufig anzutreffen sind Unternehmen, die sich irgendwann entschlossen haben, nicht mehr nach SAFe zu arbeiten, da die damit verbundenen Erwartungen nicht erfüllt werden konnten. Mitunter werden aber einzelne funktionierende Elemente beibehalten, z.B. das PI Planning oder die Rolle des Release Train Engineers. Man erkennt durch sie noch, dass SAFe hier einmal im Einsatz gewesen ist, der aktuelle Zustand hat aber nur noch eingeschränkt damit zu tun.

Und viele mehr ...

Wie immer bei solchen Aufzählungen ist auch diese hier nicht vollständig, in den Unternehmen dieser Welt kann man mit Sicherheit noch weitere SAFe-Varianten finden. Wichtig ist an dieser Stelle vor allem die zentrale Botschaft: es gibt verschiedene Ausprägungen dieses Frameworks, die sich z.T. sehr deutlich voneinander unterscheiden, wodurch es viel weniger eindeutig und einheitlich ist, als es auf den ersten Blick erscheinen mag.

Bild: Strassen NRW

Ab und zu wird man von der staatlichen Verwaltung positiv überrascht, in diesem Fall vom Landesbetrieb Straßenbau Nordrhein-Westfalen. Der ist u.a. verantwortlich für den Neubau einer Brücke, die ich in den letzten Jahren ab und zu benutzt habe, der Wupperbrücke Blombacher Bach in Wuppertal. Dieser Neubau wurde dieses Jahr in einer rekordverdächtigen Geschwindigkeit von nur wenigen Wochen abgeschlossen, und das mit Massnahmen, die jetzt zum Standard in NRW werden sollen.

Die erste dieser Massnahmen ist ein frühes Beteiligungsverfahren, an denen sich alle betroffenen Gruppen (in diesem Fall Anwohner, Pendler, Unternehmen, etc.) beteiligen und ggf. ihre Bedenken einbringen können. Das mag auf den ersten Blick wie eine Verzögerung wirken, sorgt aber später im Prozess für Geschwindigkeit, da durch die Einbeziehung derartiger Stakeholder die Wahrscheinlichkeit von Fehlplanungen und Gerichtsprozessen geringer wird.

Über die zweite Massnahme habe ich bereits an anderer Stelle etwas geschrieben: es ist die Modulbauweise. Die einzelnen Bauelemente können an einer anderen Stelle im Voraus gefertigt werden und werden vor Ort nur noch zusammengesetzt und durch eine so genannte Ortbetonergänzung verbunden (was für ein schönes deutsches Wort). Neben der Geschwindigkeit ergibt sich dadurch ein zweiter Vorteil - beschädigte Brückenteile können später einfacher ersetzt werden.

Die dritte Massnahme ist vermutlich für die deutsche Bürokratie am revolutionärsten, es handelt sich um die so genannte funktionale Ausschreibung der Bauvorhaben. Bei derartigen Ausschreibungen wird kein detaillierter Leistungskatalog mehr vorgegeben, sondern es wird nur das zu erreichende Ziel definiert (z.B. Abriss und Neubau einer Brücke) ggf. verbunden mit in diesem Rahmen zu erreichenden Kennzahlen (z.B. der Traglast dieser Brücke).

Dieses Vorgehen hat gleich mehrere positive Effekte: der Umfang der zu erstellenden und zu bearbeitenden Ausschreibungs-Unterlagen wird geringer, den Bauträgern wird es möglich gemacht, neue und innovative Bautechniken einzusetzen, ohne die Bauämter davon überzeugen zu müssen, diese in die Pläne aufzunehmen, und durch die geringeren Aufwände in diesen Ämtern ist der dort spürbare Fachkräftemangel ein weniger starker Verlangsamungsfaktor für Planungs- und Genehmigungsprozesse.

Mir fällt gerade auf, dass ich noch nie etwas zum Thema Site Reliability Engineering (der Schaffung einfach skalierbarer und trotzdem hochzuverlässiger Softwaresysteme) geschrieben habe. Hole ich irgendwann nach, für den Moment nimmt mir Heinrich Hartmann diese Arbeit aber ab, in dem er gut darstellt, wie das bei seiner Firma (Zalando) gemacht wird.

Was mir besonders gut daran gefällt: er streicht deutlich heraus, dass es sich bei Site Reliability Engineering nicht nur um ein rein technisches Thema handelt, sondern um ein technisch-soziales, das ohne Berücksichtigung der Anwender, bzw. ihrer Wünsche und Reaktionen, nicht zu denken ist.

Noch einmal zum Thema Unternehmenskultur. Wie bereits an anderer Stelle geschrieben hat jedes auch nur halbwegs grosse Unternehmen nicht nur eine Kultur, sondern mehrere, die parallel zu einander existieren: eine in der Fertigung, eine im Vertrieb, eine in der Finanzabteilung, eine in der Software-Entwicklung, etc. Das gilt übrigens auch dort, wo offiziell etwas anderes behauptet wird, wo die "offiziell verkündete Kultur" total positiv erscheint oder wo sie von allen gewollt wird.

Das wirft aber weitere Fragen auf: sind diese verschiedenen Kulturen überhaupt miteinander kompatibel? Wiedersprechen sie nicht ggf. sogar in ihren Grundannahmen und Werten? Ist es auf dieser Basis überhaupt möglich, eine gemeinsame (Firmen-)Identität zu schaffen und sich auf gemeinsame Ziele zu einigen? Oder muss man nicht befürchten, dass die verschiedenen kulturellen Gruppen eher gegeneinander als miteinander arbeiten? Alles berechtigte Punkte.

Die gute Nachricht an dieser Stelle ist, dass es bereits seit langem eine umfangreiche wissenschaftliche Beschäftigung mit diesem Thema gibt, nämlich in der Soziologie, genauer gesagt in der Kultursoziologie. Zwar beschäftigt die sich eher mit Gesellschaften als Unternehmen, die Ergebnisse sind aber übertragbar. Bekannte Forscher sind hier Milton M. Gordon, John Rex oder Alf Mintzel (der in seinem Buch Multikulturelle Gesellschaften in Europa und Nordamerika eine gute Übersicht über das Thema gibt).

Das (vereinfachte) Ergebnis dieser Forschungen ist, dass Menschen in der Lage sind, in multikulturellen Umgebungen ihre Kultur temporär zu wechseln. In der Gesellschaft könnte dieser Wechsel z.B. zwischen Familie und Beruf stattfinden, in einem Unternehmen z.B. zwischen Projekt und Linie. In beiden Umfeldern werden dabei jeweils (bewusst oder unbewusst) die Verhaltensmuster an den Tag gelegt, von denen angenommen wird, dass sie in der jeweiligen Situation Kultur-konform sind.

Natürlich sind mit dieser Art von Multikultur Risiken verbunden. Zum einen kann es beim Aufeinandertreffen der jeweiligen kulturellen Gruppen für den, der zwischen ihnen wechselt, zu Rollenkonflikten kommen (zu wem verhält man sich jetzt kompatibel?), zum anderen sind während der temporären Zugehörigkeit zur einen Gruppe die Anliegen der anderen Gruppe nicht mehr so einfach zu erklären, ohne aus der Rolle zu fallen (die Folge ist der so genannte Kontext-Kollaps).

Um derartige Missverständnisse und daraus folgende potentielle Konflikte zu entschärfen, neigen multikulturelle Gesellschften (bzw. Unternehmen) dazu, selbstorganisiert jeweils zwei Varianten jeder einzelnen ihrer Teil-Kulturen herauszubilden: die primäre, die nur innerhalb der jeweils gleichartig ausgeprägten Gruppen ausgelebt wird, und die sekundäre, die dort ausgelebt wird, wo sich der Wirkungs- und Wahrnehmungsraum verschiedener kultureller Gruppen überschneiden.

Dabei kann es dazu kommen, dass die von den verschiedenen Einzelgruppen herausgebildeten Sekundär-Kulturen sich so ähnlich sind, dass sie sie kaum noch unterscheiden lassen. In einer Betrachtung von aussen kann dadurch der Eindruck entstehen, dass es doch eine gemeinsame, einheitliche Unternehmenskultur gäbe. Da diese Annahmen die parallel existierenden Primär-Kulturen nicht beachten, halten sie einer näheren Betrachtung aber kaum stand.

PS:

Grafik: Pixabay / Geralt - Lizenz

John Utz: Delete to Accelerate: Transforming Your Product with a Reverse Roadmap

Doc Norton: Opportunity Solution Trees

Stefan Kühl: Disruption

Maarten Dalmijn: Are Scrum Masters Too Much Overhead? / Are Product Owners Too Much Overhead?

Lisa Crispin: The Agile Testing Quadrants

Conway's Law ist ein grosser Klassiker wenn es darum geht, die Zusammenhänge zwischen Organisationsstruktur und Software-Architektur zu erklären (oder aufzuzeigen, dass die überhaupt existieren). Ian Miell macht zu Recht darauf aufmerksam, dass diese Ableitung der Architektur aus der Struktur aber nur ein unvollständiges Bild bietet - auch die Struktur orientiert sich nämlich an etwas, und zwar an den Finanzströmen des Unternehmens. Mit anderen Worten: die Gestaltung der Finanzströme definiert über die Organisationsstruktur die Software-Architektur.

Über diese Erkenntnis hinaus geht Miell aber noch weiter und erklärt anhand von realen Beispielen, wie die Finanzströme mit Projekten, Produkten, DevOps, Site Reliability Engineering und Unternehmenspolitik zusammenhängen. Ein grosser Rundumschlag, aber ein lohnender und aufschlussreicher.

Es ist gerade wieder eine dieser Phasen, in denen der "State of Agile" lebhaft diskutiert wird. Auf der einen Seite werden fehlgeschlagene agile Transitionen und die Entlassung der Scrum Master in manchen Unternehmen als neuer Beleg für die seit ca 2005 periodisch auftauchende "Agile ist tot"-These genommen, auf der anderen Seite werden verschiedene Transitions-Erfolgsgeschichten und die zahlreichen Scrum- und Agile-Stellenausschreibungen als Beweis des Gegenteils betrachetet.

In meiner Wahrnehmung sind beide Standpunkte richtig, und zwar nicht so, dass die Wahrheit in der Mitte liegt. Genau wie Schrödingers Katze ist agiles Arbeiten gleichzeitig tot und am Leben, für beides gibt es eindeutige Anzeichen. Und genau wie im Fall von Schrödingers Katze wird eine konkrete Überprüfung eines einzelnen Sachverhalts zwar für diesen Einen eine Antwort für die Frage tot oder lebendig bringen, die aber die grundlegende Gleichzeitigkeit nicht auflöst.

Werden wir etwas konkreter. Über die Zeit haben sich verschiedene Spielarten der "real existierenden Agilität" herausgebildet, deren aktueller Zustand höchst unterschiedlich sein kann. Nimmt man die jeweils für sich genommen unter die Lupe, kann alles dabei sein, von erstaunlich lebendig bis kurz vor dem Ableben. Diese Einschätzungen sind alle natürlich hochgradig subjektiv, wobei ich schon glaube, durch Kunden, Akquise und Meetups einen überdurchschnittlich breiten Einblick zu haben.

Technische Agilität

Alive and kicking. Egal ob Oldschool (Extreme Programming), zeitgemäss (DevOps, CI/CD) oder avantgardistisch (Chaos Engineering, AI Driven), die technische Dimension des agilen Arbeitens ist der de facto-Standard in der Softwareentwicklung geworden. Tatsächlich tritt hier gerade ein, was ich vor fast 10 Jahren geahnt habe: die Verbreitung ist soweit fortgeschritten, dass oft nicht mehr von agiler Softwareentwicklung die Rede ist, sondern nur noch von zeitgemässer Softwareentwicklung.

Business-Agilität

Alive and kicking. Produktzentrierung, Design Thinking, Lean Startup, Business-Experimente, AB-Testing, MVPs, Low Code-Prototypen und mehr sind selbst in Grosskonzernen und traditionellen Familienunternehmen mittlerweile weit verbreitet - sogar so sehr, dass mitunter die Fach- und Marketingabteilungen ein genauso gutes, manchmal sogar besseres Verständnis von Agilität haben als die IT-Abteilungen. Das wäre noch vor wenigen Jahren undenkbar gewesen.

Agiles PMO ("Team-Sekretariat")

Polytrauma. Ein Grossteil der Agile Coaches und Scrum Master dieser Welt hat leider das Klischee erfüllt, vor allem Meetings zu moderieren, Jira zu konfigurieren und die Teamkalender zu verwalten. Darin wird in vielen Firmen, aber auch in vielen Teams, kein Mehrwert mehr gesehen, und auch die Betroffenen selbst sind meistens unglücklich. Viele Entlassungen haben hier stattgefunden. Dort wo es "agile PMO-Kräfte" noch gibt, haben sie in der Regel zwei, drei oder noch mehr Teams zu betreuen.

Agiles Hands Off-Coaching

Tot. Bis zur Corona-Pandemie hat es einen weit verbreiteten Typ von Agile Coaches und Scrum Mastern gegeben, der durchgehend mit dem Team zusammensass, wenig selbst gemacht hat, aber regelmässig Beobachtungen geteilt und Feedback gegeben hat. Das war auch deutlich wertvoller als man auf den ersten Blick denken könnte, hat aber durch den Umschwung zur Remote-Arbeit 2020 schlagartig aufgehört zu funktionieren und zu existieren.

"Agiles" Life Coaching / Personal Coaching

Mausetot. Während der zuletzt genannte Typ für wertstiftendes Feedback mindestens ein Grundniveau an Wissen über Softwareentwicklung, Projektmanagement und Produktmanagement gebraucht hat, gab es daneben einen weiteren weitverbreiteten Typ, der dieses Wissen weder hatte noch wollte, und sich stattdessen auf (häufig ungefragtes) Life Coaching und Personal Coaching beschränkt hat ("Was macht das mit Dir?"). Diese Personen gehörten nicht nur in Krisenzeiten zu den ersten Personalabbau-Zielen.

Esoterisches Agile Coaching

Mausetot. Bei diesem Typ von Agile Coaches und Scrum Mastern fragt man sich rückwirkend, wie die sich jemals in nennenswerter Menge am Markt etablieren konnten. Pseudo-wissenschaftliche Ansätze wie neurolinguistische Programmierung, Eneagramme und Spiral Dynamics und extreme Überspitzungen grundlegend sinnvoller Konzepte, wie z.B. von gewaltfreier Kommunikation, waren schon immer schwer zu vermitteln, mittlerweile sind sie es gar nicht mehr.

Agiles Hands On-Coaching

Auf dem Weg der Besserung. Im Rahmen mancher Personalabbauprogramme sind zahlreiche agile Methodiker, die einen guten Job gemacht haben, mit den zuvor genannten in einen Topf geworfen und entlassen worden. In vielen Fällen ist danach aufgefallen, was plötzlich fehlt, so dass diese Stellen wieder aufgebaut wurden. Und bei vielen weiteren war die Wertschätzung so gross, dass ihre Positionen behalten konnten (wenn auch z.T. mit geändertem Jobtitel aber ähnlichen Aufgaben).

Agiler Zertifizierungsmarkt

Polytrauma. Über lange Jahre waren die Scrum-, SAFe- und Kanban-Zertifizierungslehrgänge sowohl Einnahmequelle als auch Vertriebskanal für viele Agile Coaches und agile Beratungen. Seit einiger Zeit wird der Wert dieser Zertifikate aber immer kritischer gesehen, während gleichzeitig immer neue Anbieter ein Überangebot geschaffen haben. Da für viele Zertifizierungs-Lizenzen eine Mindestmenge an Trainings nötig ist, sind die mitunter nur noch schlecht gebucht und dadurch ein Verlustgeschäft.

Agil-industrieller Komplex

Alive and kicking. Die meisten agilen Idealisten würden es sich anders wünschen, aber dem agil-industriellen Komplex geht es erstaunlich gut. Die Konzerne schmeissen zwar nicht mehr ganz so viel Geld aus dem Fenster um agile (Pseudo-)Transitionen und Skalierungsvorhaben durchzuführen, die Einführung von SAFe oder dem Spotify Model in Grossorganisationen ist aber immer noch ein solider Business Case, und das vermutlich noch lange.

Agile beyond IT

Den Umständen entsprechend. Die Zeit in der auch Einheiten wie HR, Hausmeisterdienst und Rechtsabteilung unbedingt Sprints, Dailies und OKRs haben wollten sind zwar vorbei, auf der anderen Seite haben Firmen wie Mercadona, Cleveland Clinics und SpaceX agile Praktiken weit aus der Softwareentwicklung herausgeführt und gelten in ihren Branchen sogar als Vorbilder. Darüber hinaus tritt Agilität unter z.T. anderem Namen noch in vielen weiteren Bereichen unentdeckt auf.

Was durch diese Übersicht klar wird: pauschale Aussagen wie "Agile ist tot" oder "Agile hat gewonnen" gehen an der vielschichtigen Realität vorbei.¹  Und diese Situation wird dadurch, dass es zwischen einzenlen Unternehmen grosse Unterschiede gibt, nochmal vielschichtiger. Aus einer gewissen Distanz betrachtet muss man also grundsätzlich davon ausgehen, dass agiles Arbeiten sowohl lebendig als auch von uns gegangen sein kann. Was stimmt, sieht man nur im Einzelfall.