On Lean and Agility

Bild: Wikimedia Commons / Anton Heiz - CC BY-SA 4.0

Unter den vielen Berichten über sich verzögernde Infrastruktur-Projekte ist dieser hier kaum aufgefallen: der Bau des Fehmarnsundtunnels (Teil der Fehmarnbelt-Querung) dauert mindestens drei Jahre länger als geplant. Auffällig dabei ist, dass ein Grossteil dieser Verspätung nicht etwa durch Probleme beim eigentlichen Bauvorhaben entsteht (das hat noch gar nicht begonnen), sondern durch Bürokratie: Ausschreibungsprozesse, zu beachtende Fristen, Einspruchsverfahren, Klagemöglichkeiten, etc.

Der Fehmarnsundtunnel ist dabei kein Einzelfall: wer mit Bauträgern und Behördenvertretern spricht bekommt zahllose derartige Geschichten zu hören, bei denen das eigentliche Vorhaben mehr oder weniger im Plan liegt, bei denen aber bürokratische Vorgaben immer wieder zu verzögertem Start oder zwischenzeitlichen Unterbrechungen führen - und das nicht etwa durch Behördenwillkür, sondern nur weil auch die sich an Gesetze und Vorschriften halten müssen.

Wie sehr es tatsächlich die Verwaltungsbürokratie ist, die alles verlangsamt, kann man an einem anderen Beispiel sehen. den LNG-Flüssiggas-Terminals, die ab dem Jahr 2022 an der Nord- und Ostseeküste gebaut wurden. Für deutsche Verhältnisse sind sie in atemberaubender Geschwindigkeit fertig geworden, zum Teil lag zwischen dem Beschluss des Vorhabens und dem Ende der Bauarbeiten weniger als ein Jahr. Und man kann jetzt bereits ahnen, wie das gelungen ist.

Das für diesen Zweck erlassene "Gesetz zur Beschleunigung des Einsatzes verflüssigten Erdgases" (LNG-Beschleunigungsgesetz) macht fast ausschliesslich Eines: es setzt andere Gesetze und Vorschriften ausser Kraft. Formulierungen wie "Abweichend von § X ..." oder "§ Y des Gesetzes Z ist nicht anzuwenden" ziehen sich durch seinen gesamten Text und machen deutlich klar, dass hier ein subtraktiver Wandel stattfindet. Mit anderen Worten: Verbesserung durch Weglassen.

Natürlich heisst das nicht, dass alle bisherigen Gesetze und Vorschriften sinnlos sind und abgeschafft werden sollten, derartige Kettensägen-Methoden gehören (wenn überhaupt) in ganz bestimmte Sektoren der Privatwirtschaft, die entfesselnde Wirkung eines Regulierungs-Rückbaus ist aber an diesem Fall mehr als deutlich zu erkennen. Wenn der Staat wieder handlungsfähig werden soll, ist das temporäre oder dauerhafte Ausserkraftsetzen also ein durchaus gangbarer Weg.

Das hier gefällt mir wirklich: Barry O'Reilly versucht sich an einem philosophischen Blick auf das Konzept der Software-Architektur. Verkürzt gesagt - während sie häufig als ein logischer und konsistenter Ansatz zur Strukturierung von Software gesehen wird, ist sie in Wirklichkeit eine soziale Technik, mit der versucht wird, Ordnung in eine Welt zu bringen, die sich in einem Prozess der permanenten Unordnung befindet.

Alleine die oben genennten Gedanken hätten vermutlich schon für einen eigenen Vortrag gereicht, aber dieser geht deutlich weiter, und berührt unter anderem Essentialismus, Strukturalismus, Determinismus (und dessen Negierung), die Diskrepanz zwischen Sein und Werden, Positivismus, Interpretivismus, naive Kybernetik, Kausalität, Dekonstruktion und die philosophischen Grundlagen der Matrix-Filmreihe. Definitiv sehens- und hörenswert.

Von Zeit zu Zeit lohnt es sich, Bücher heranzuziehen die zwar zu Zeiten des Aufschwungs der agilen Methoden verfasst wurden, sich aber nicht mit ihnen im engeren Sinn befassen, sondern breitere gesellschaftliche Trends zum Gegenstand haben. Da die agile Bewegung Teil der Gesellschaft ist, bietet diese Art der Betrachtung einen interessanten Blickwinkel: ist auch sie von diesen Trends beeinflusst worden, und wenn ja wie? Ein Buch mit dem man derartig vorgehen kann ist The Cult of the Amateur.

Verfasst wurde es im Jahr 2007 vom britisch-amerikanischen Unternehmer und Schriftsteller Andrew Keen. Vordergründig richtete es sich gegen das in dieser Zeit aufkommende partizipative Internet, damals Web 2.0 genannt (heute würde man von User generated Content sprechen). Auf einer grösseren Ebene handelte es sich aber gleichzeitig um eine harte Kritik an der zu dieser Zeit häufigen Verklärung unwissenschaftlicher und autodidaktischer, dafür aber meinungsstarker Diskussionsteilnehmer.

Zum Kontext: im ersten Jahrzehnt des dritten Jahrtausends ist es zu einer nie zuvor dagewesenen Demokratisierung des Zugangs einzelner Personen zur Öffentlichkeit gekommen. Services wie Wordpress, Youtube, Twitter, Facebook und Wikipedia erlaubten es jedem Menschen, Beiträge zu jedem beliebigen Thema zu veröffentlichen und damit potentiell den allgemeinen Diskurs zu diesem Thema mitzugestalten. Aus demokratietheoretischer Sicht eine grossartige Entwicklung.

Was Keen an dieser Entwicklung kritisierte, war, dass durch den Wegfall der bisherigen Verlags- und Sender-Oligopole nicht nur die Zugangsbarrieren wegfielen, sondern auch die mit ihnen verbundenen Qualitätssicherungs-Mechanismen. Während vorher vorwiegend Inhalte eine grosse Öffentlichkeit erreichten, die gut begründet, in sich konsistent und überprüfbar waren, verschob sich das plötzlich zu solchen, die auf starken Einzelmeinungen zu aktuellen Themen basierten.

Und an dieser Stelle kommen wir zurück zur agilen Bewegung. Selbst wenn viele der damals noch neuen agilen Frameworks basierend auf Praxiserfahrungen entstanden waren, waren die jeweiligen Entstehungsbedingungen so überschaubar und einzelfallspezifisch, dass sich nicht klar sagen liess, was Kausalität war und was Korrelation. Um ein bekanntes Beispiel zu nennen - Extreme Programming (XP) basierte ursprünglich auf den Erfahrungen eines einzigen Teams, das nur wenige Jahre lang bestand.¹

Dass dieser anfangs eher überschaubare Anwendungsfall es zeitweise schaffte, zum populärsten agilen Famework zu werden,² lag wesentlich an den zuvor erwähnten demokratisierten Zugängen zur Öffentlichkeit, im Fall von XP in Form von Wikis wie wiki.c2.com oder wiki.org, in denen Praktiker und Enthusiasten in selbst gewähltem Umfang und Detailgrad Inhalte veröffentlichen konnten, die weltweit von jedem Inhaber eines internetfähigen Computers gelesen werden konnten.³

In diesem Fall hat die Geschichte zwar ein Happy End, da sich XP mit der Zeit in der Praxis bewährte, in anderen Fällen war der Ausgang aber nicht ganz so gut - dass viele Versuche agile Arbeitsweisen einzuführen kläglich gescheitert sind, liegt ganz wesentlich daran, dass das dafür gewählte Vorgehen lediglich auf starken Meinungen und anekdotischer Evidenz beruhten, verfälscht durch Survivor Biases, Hindsight Biases und ähnliche Phänomene.

Zu den klassischen, immer wieder auftretenden Fehlern gehören dabei Über-Simplifizierung ("man muss nur alle Mitarbeiter schulen"), Personalisierung ("die Personen X, Y und Z wollen sich nicht ändern"), Blaupausen-Gläubigkeit ("Spotify hat das auch so gemacht"), Confirmation Bias ("ich habe schon immer gesagt: einfach machen! Endlich sehen das jetzt alle so.") und Ausblendung von Zusammenhängen ("warum reden wir hier über Budgetierung, wir wollten doch über die agile Transformation sprechen").

Dabei ist keiner dieser Fehler unvermeidbar, in der psychologischen und betriebswirtschaftlichen Forschung und Literatur werden sie seit über hundert Jahren behandelt, einschliesslich der Möglichkeiten sie zu erkennen und zu verhindern. Wer eine wissenschaftliche oder praktische Ausbildung im Produkt- oder Projektmanagement durchlaufen hat, wird sie mit grosser Wahrscheinlichkeit vermeiden oder abschwächen können.⁴

Dass eine Kenntnis dieser Forschungsergebnisse und Fachliteraturen in agilen Transitionenzu selten erwartet wird, liegt schliesslich an etwas, das man in Anlehnung an Keen als "Cult of the agile Amateur" bezeichnen könnte: der Verklärung unwissenschaftlicher und autodidaktischer, dafür aber meinungsstarker Scrum Master und Agile Coaches als "Organisationsrebellen" oder Inhaber eines "agilen Mindsets", deren Expertise keiner Validierung bedarf.

Um Missverständnisse zu vermeiden: dieser Cult of the agile Amateur ist nicht in den verschiedenen agilen Frameworks selbst verankert, sondern ist eher aus den oben erwähnten Besonderheiten der Entstehungszeit zu erklären. Und überall dort wo agile Transitionen langfristig erfolgreich gewesen sind, ist er entweder von Anfang an vermieden worden oder er wurde mit der Zeit erkannt und nach und nach eingedämmt und beseitigt.

Wie eine solche Gegenbewegung vor sich gehen kann ist dann wieder von Einzelfall zu Einzelfall unterschiedlich, so dass es dafür kein Patentrezept gibt (ein empirisch-analytisches Vorgehen ist aber ein guter Startpunkt). Lediglich eines lässt sich mit Sicherheit sagen: was nur in den allerseltensten Fällen helfen wird sind agile Zertifizierungen.

Wenn man Aussagen sucht, auf die die agile Bewegung sich einigen kann, dann wird man schnell auf die stossen, dass agiles Arbeiten Empirie- und Evidenz-getrieben sein sollte, oder mit anderen Worten: wissenschaftlich. Ernst genommen bedeutet das zum Einen, dass man im Kleinen selbst versuchen sollte, so vorzugehen, zum Anderen aber auch, dass man sich für wissenschaftliche Erkenntnisse interessieren sollte, die das eigene Arbeitsfeld betreffen - und wer danach sucht, findet Einiges.

Ich bin mit der Zeit auf eine ganzen Reihe wissenschaftlicher Papers gestossen und spiele gerade mit dem Gedanken, eine Beitragsreihe zu starten, in der ich jeweils einige von ihnen vorstelle. Ob es wirklich dazu kommt wird sich zeigen, für den Moment habe ich aber zumindest fünf, die mir erwähnenswert erscheinen. Sie gehen quer durch alle möglichen Themen durch und sind natürlich eine subjektive Auswahl, aber eine die ich empfehlen möchte. Hier sind sie:

Takeuchi, Hirotaka; Nonaka, Ikujiro: The New New Product Development Game

Eine der Initialzündungen dessen, was wir heute agile Produktentwicklung nennen. Vereinfacht gesagt haben Takeuchi und Nonaka Feldforschung betrieben um herauszufinden, warum manche Firmen effektiver Produkte entwickeln als andere. Ihre Forschungsergebnisse sind zwar schon 40 Jahre alt, haben aber nichts von ihrer Aktualität eingebüsst.

Verwijs, Christiaan; Overeem, Barry: The Double-Edged Sword Of Diversity In Teams

Manchmal tun Erkenntnisse weh. Verwijs und Overeem haben versucht, den in der agilen Bewegung verbreiteten Glaubenssatz zu validieren, dass Diversität in Entwicklungsteams etwas grundsätzlich Gutes ist. Ihre Erkenntnis - ganz so einfach ist es nicht. Zwar gibt es eindeutig positive Effekte, in einigen Dimensionen ist Diversität aber ohne Auswirkungen oder führt sogar zu Nachteilen.

Eilers, Karen; Peters, Christoph; Leimeister, Jan: Why the agile mindset matters

Diese Arbeit ist wirklich verdienstvoll. Zum ersten mal habe ich hier gesehen, wie versucht wird, den umstrittenen Begriff des "Agilen Mindset" neutral und sachlich einzuordnen und zu untersuchen. Ein wohltuender Kontrast zu dem eher esoterischen und zum Teil sogar übergriffigen Umgang, der sonst in der Beschäftigung mit diesem Begriff vorherrschend ist.

Flyvbjerg, Bent; Budzier, Alexander: Why Your IT Project May Be Riskier than You Think

Der bemerkenswerte Forschungsschwerpunkt von Bent Flyvbjerg sind (scheiternde) Grossprojekte. Dass die häufig ausser Kontrolle geraten ist zwar bekannt, er differenziert es aber entscheidend aus. Vereinfacht gesagt: es geht nicht immer schief, aber wenn es schiefgeht, dann richtig. Und: die Gründe dafür sind identifizierbar und es gibt erfolgsversprechende Gegenmassnahmen.

Kühl, Stefan: Das Scharlatanerieproblem – Zwischen Professionsbildung und Professionalisierung

Gitte Klitgaard und  Jakob Wolman sagen es in diesem Vortrag völlig zu Recht: die Ablehnung, die den Management-Rollen von weiten Teilen der agilen Community entgegenschlägt, ist nicht gerechtfertigt. Um als Team wirklich selbstorganisiert arbeiten zu können braucht es die richtigen Rahmenbedingungen, die jemand setzen muss, der sich mit Systemdesign auskennt - mit anderen Worten, es braucht einen guten Manager. Nur dann kann die für Selbstorganisation notwendige Ausgewogenheit zwischen Autonomie und Alignment entstehen.

Ganz nebenbei habe ich beim Anhören dieses Vortrags noch etwas dazugelernt: der Begriff der Selbstorganisation wurde 1790 von Immanuel Kant erfunden. Einmal mehr zeigt sich, was wir der Aufklärung alles verdanken.

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.

Ein Hoch auf die Wissenschaft! Heute auf den amerikanischen Wirtschaftswissenschaftler Jason Furman, der am Peterson Institute for International Economics in Washington DC eine vielbeachtete Vorlesung zum Thema des aktuellen Zustands seines Fachgebiets gehalten hat, die den schönen Namen In Defense of the Dismal Science trägt. Daraus ist vor allem ein Aspekt interessant, der des unterschiedlichen Umgangs mit Change-Projekten duch unterschiedliche Gruppen.

In einer bewussten Vereinfachung teilt Furman alle an Veränderungen Beteiligten Menschen in zwei Gruppen ein, die er die Progressivenen ("the Liberals")¹ und die Konservativen nennt. Beiden wirft er dabei ein jeweils spezifisches Laster (englisch: Vice) vor, womit er meint, dass beide Gruppen beim Umgang mit Veränderungen zu bestimmten Denkfehlern neigen, die beide dazu führen, dass es ihnen schwer fällt, für ihre Sichtweisen Mehrheiten zu gewinnen.

The way in which this happens often varies between liberals and conservatives. I am going to overgeneralize in describing what I call the “liberal vice” and “conservative vice” in policy analysis. But disclaimer: many liberals and conservatives do not suffer from these vices and moreover some liberals suffer from the conservative vice and vice versa.

Jason Furman, 2024: In Defense of the Dismal Science

The Conservative Vice

Das konservative Laster besteht darin, in allen Veränderungen vor allem die damit verbundenen Risiken zu sehen und sie in Folge dessen derartig mit Befürchtungen zu überladen, dass am Ende ein unrealistisch bedrohliches Zerrbild entsteht, aufgrunddessen alles Neue abgelehnt wird. Wie gesagt überzeichnet Furman bewusst, aber der Kern seiner Aussage ist nachvollziehbar.

The Liberal Vice

Das progressive Laster besteht darin, dass in allen Veränderungen vor allem die dadurch potentiell möglichen Verbesserungen gesehen werden, während die ebenfalls möglichen Verschlechterungen ausgeblendet oder sogar negiert werden. Das so entstehende gedankliche Konstrukt ist letztendlich genauso realitätsfern wie das Konservative.

In beiden Fällen ist das jeweilige Denkmuster mit dem Risiko verbunden, die Unterstützung aller anderen Beteiligten zu verlieren. Beim konservativen Laster, weil der Wunsch nach Veränderungen unterschätzt wird, bem progressiven Laster, weil berechtigte Sorgen und Ängste ignoriert werden. Und an der Stelle kommt jetzt die Transferleistung - lässt sich Furmas Idee der konservativen und progressiven Laster auf andere Themenfelder übertragen oder einengen? Ja, das geht.

The Agile Vice

Übertragen auf die agilen Transitionen, um die es auf dieser Seite ja im Wesentlichen geht, ist es so, dass sich vor allem ein Blick auf das progressive Laster lohnt, denn die Parallelen zu den in vielen dieser Transitionen gemachten Fehlern sind offensichtlich - so sehr, dass man in Anlehnung an Furman sogar von einem "agilen Laster" sprechen könnte.

Sowohl vom Management als auch von den "agilen Berufsmethodikern" wird die Umstellung des Arbeitsmodus auf Scrum, Kanban, SAFe und Co. meistens als ausschliessliche Win-Win-Rechnung verkauft: alles soll dadurch schneller, einfacher und besser werden und dabei auch noch mehr Spass machen als vorher. Was dabei unterschlagen wird: Agilität kommt mit einem Preis, dessen sollte man sich bewusst sein. Und er kommt oft in einer erstaunlichen Form: vielen zusätzlichen Regeln.

Wer jetzt innerlich protestiert, da er überzeugt ist, dass agiles Arbeiten keineswegs mit zusatzlichen Regeln verbunden ist, der ist dem agilen Laster bereits verfallen. Denn natürlich gibt es sie: WIP-Limits, Definitions of Done and Definitions of Reday, begrenzte Meeting-Dauern, mindestens ein Increment pro Sprint, gleichlange Sprints von maximal einem Monat Länge, kontinuierliche Integration, kontinuierliche Verbesserung, keine geteilte Product Owner Rolle, etc. Passend dazu noch einmal Jason Furman:

The more common problem is not that people who commit the liberal vice rule out too many policies because they reject anything with a tradeoff. Instead they are more likely to rule these policies in by getting the analysis wrong and denying the tradeoffs. People suffering from the liberal vice can be tempted to think that companies systematically make mistakes that, if corrected, would advance whatever other goals they have.

Jason Furman, 2024: In Defense of the Dismal Science

Und spätestens hier dürfte beim Einen oder Anderen eine Selbsterkenntnis eintreten: wenn nicht alles problemlos läuft, dann liegt es nur an einer fehlerhaften Umsetzung; würden alle sich einfach verhalten wie gedacht, würde alles sofort gut werden - genau das ist es, was Agile Coaches und Scrum Master sich regelmässig gegenseitig versichern, wenn die erwarteten Verbesserungen ausbleiben und es ggf. sogar zu Verschlechterungen kommt.

Um es zu einem versönlichen Ende zu bringen - nicht jeder agilen Berufsmethodiker ist dem agilen Laster verfallen, und genau wie bei Furmans konservativen und progressiven Lastern handelt es sich dabei um eine Übertreibung. Was aber auch klar sein muss: diese Übertreibung veranschaulicht ein reales Problem, nämlich das (bewusste oder unbewusste) Ignorieren und Kleinreden des Preises, den man zahlen muss, wenn man agil arbeiten möchte.

Die Konsequenz sollte klar sein: ständiges Hinterfragen der eigenen Positionen, ständiges Überprüfen der eigenen Positionen auf Fehlannahmen, Einholen von Feedback der von den Veränderungen Betroffenen, Bereitschaft zur Einsicht der eigenen Fehlbarkeit. Oder mit anderen Worten - Anwendung von Inspect & Adapt auf die eigenen Überzeugungen. Eigentlich etwas, was im Umfeld agiler Arbeitsweisen das Normalste der Welt sein sollte.

Heute ein etwas abseitiges Thema: COBOL. Es handelt sich dabei um eine Programmiersprache aus den 50er Jahren (!), auf der bis heute (!!) der Grossteil der Kern-Anwendungen in Banken, Versicherungen, der öffentlichen Verwaltung und vielen anderen grossen Organisationen beruht. In Coding mit Dee gibt es dankenswerterweise einen Überblick darüber was COBOL ist, und was man zu seiner Geschichte und Anwendung wissen muss.

Was mir an Dees Ausführungen besonders gefällt ist die neutrale Einordnung, samt aller Vor- und Nachteile. Sie legt Wert darauf, dass nicht die veraltete Programmiersprache selbst das Problem ist, sondern dass es stattdessen Faktoren wie fehlende Dokumentation, die Verrentung der Wissensträger und die "historisch gewachsenen" Systemstrukturen sind, die zu den Schwierigkeiten führen, über die sich bei COBOL häufig beklagt wird (und wegen denen oft behauptet wird, COBOL-Anwendungen nicht agil weiterentwickeln zu können).

Bild: Wikimedia Commons / Andrea Westmoreland - CC BY-SA 2.0

Wer hier häufiger mitliest weiss es: zu meinen Angewohnheiten gehört es, Erkenntnisse aus den verschiedensten Wissensgebieten zu nehmen und auf mein berufliches Umfeld zu übertragen. Heute geht es dabei um eine Studie von James Stroud, einem amerikanischen Evolutionsbiologen. Sie trägt den schönen Namen "Fluctuating selection maintains distinct species phenotypes in an ecological community in the wild" und handelt von der Untersuchung von Anolis-Echsen.

Ausgangspunkt der Studie ist das Phänomen, dass diese Eidechsen-Art seit 20 Millionen Jahren existiert, ohne sich in dieser Zeit verändert zu haben (!). Dieser lange Zeitraum stellt scheinbar die Evolutionstheorie in Frage, schliesslich müssten Lebewesen sich ihr zufolge immer wieder an die sich ändernde Umgebungsbedingungen anpassen und dadurch ihre Erscheinung verändern. Dass das bei Tierarten wie den Anolis-Echsen nicht passiert, ist daher wissenschaftlich hochinteressant.

Strouds Langzeit-Beobachtungen führten zu einer überraschenden Erkenntnis: evolutionäre Veränderungen (z.B. der Beine) kommen bei Anolis-Echsen nicht nur vor, sondern sogar extrem häufig, zum Teil finden sie sogar im Jahresrhythmus statt. Da die Umgebungsbedingungen (z.B. das Nahrungs-Angebot) sich allerdings ständig innerhalb eines bestimmten Spektrums hin- und herverändern, entwickeln die Echsen sich immer wieder zur Ursprungsform zurück und von da wieder auseinander.

Dieses Phänomen einer permanenten Anpassung bei gleichzeitiger langfristiger Beibehaltung der grundlegenden Erscheinugsform wird in der Studie The Paradox of Stasis genannt, also das widersprüchlich erscheinende Konzept, gerade durch langfristige Unveränderbarkeit besonders anpassungsfähig zu sein. So viel zur Eidechsen-Forschung, weiter zur Übertragung: gibt es das Paradox of Stasis auch in menschlichen Organisationen?

Die Antwort: ja, man findet es. Die Beispiele reichen von grossen Industriekonzernen wie Toyota, die trotz sich massiv ändernder Märkte und Technologien seit Jahrzehnten eine ähnliche Organisations-Struktur haben, bis hin zu den Feuerwehren, die trotz ständiger Modernisierung noch immer in Feuerwachen, Löschzüge und Löschgruppen unterteilt sind. Da es aber auch zahlreiche Gegenbeispiele gibt, stellt sich die Frage, in welchen Zusammenhängen diese Stabilität möglich ist (und wann nicht).

Die erste grundlegende Bedingung dürfte sein, dass veränderte Umgebungsbedingungen zwar möglich, aber nicht zu weitreichend sein sollten. Genau wie das komplette Abholzen ihrer Heimat-Wälder die Anpassungsfähigkeit von Anolis-Echsen an ihre Grenzen bringt, würde z.B. die Verdrängung der Autos durch andere Verkehrsmittel mit Sicherheit auch an Toyota nicht ohne grössere und dauerhafte Veränderungen vorbeigehen. Eine zumindest rudimentäre Stabilität braucht es also.

Auch da gilt (wie so oft): wenn es einfach wäre, würde es jeder machen. Überspitzt gesagt: nicht jedes Unternehmen kann wie eine Anolis-Echse sein. Auch als Dinosaurier kann man ein ziemlich gutes Dasein fristen. Man ist dann gross, berühmt und beeindruckend - nur muss man sich irgendwann radikal verändern um weiterbestehen zu können.

Es ist nicht ganz klar wann es begonnen hat, aber seit über 10 Jahren wird in der agilen Community die Monte Carlo-Simulation als ein Weg angesehen, im Rahmen von propabilistic forecasting voraussichtliche Lieferzeitpunkte zu berechnen. Vereinfacht gesagt handet es sich dabei um die Ermittlung von Eintrittswahrscheinlichkeiten auf Basis randomisierter historischer Daten. In diesem Video wird erklärt wie das stattfindet.

Die Frage, die sich nach derartigen Einführungen jeder sofort stellt, ist - funktioniert das wirklich? Die Antwort ist wie so oft, dass es auf den Kontext ankommt. Die Aussagekraft ist höher (wenn auch komplizierter zu verstehen) als die von reinen Durchschnittswerten. Man muss sich aber bewusst machen, dass mehrere Voraussetzungen gegeben sein müssen: der Umfang der Anforderungen muss stabil sein, das umsetzende Team muss stabil sein und es darf keine Änderung der für die Umsetzungsgeschwindigkeit relevanten Umgebungsfaktoren geben. Ob das in einer Umgebung, in der agil gearbeitet wird, der Fall ist?

In vielen Entwicklungsteams ist Compliance (die Ausführung, Überwachung und Dokumentation von regelkonformem Verhalten) etwas das sie zutieft verabscheuen, da es bürokratisch und aufwändig ist. Effy Elden zeigt auf, dass das nicht so sein muss. Integriert in den Code kann Compliance zu einem Teil der Entwicklung werden, der ähnlich zu entwickeln ist wie die restliche Anwendung.

Was sie hervorhebt, und was aus meiner Sicht auch richtig ist, ist, dass Compliance as Code nicht ohne Vertrauen in die Entwicklungsteams machbar ist. Im Quelltext vorhandene Kontrollen können nur von Entwicklern auf Konsistenz und Wirksamkeit überprüft werden. Allerdings: klassische Compliance-Prozesse der IT bestehen häufig auch nur aus Checklisten, in denen Entwickler durch das Setzen von Haken bestätigen müssen, dass sie sich an alle Regeln gehalten haben. Auch in dem Fall muss man darauf vertrauen, dass sie wissen, was sie tun.

Ich bin mir ziemlich sicher, dass ich irgendwann mal etwas über das Arisoteles-Projekt von Google geschrieben habe, eine Studie mit 180 teilnehmenden Teams, deren Ergebnis war, dass Hochleistung vor allem dann möglich ist, wenn die folgenden Dinge gegeben sind: Psychologische Sicherheit, Verlässlichkeit der Kollegen, Struktur und Klarheit der Ziele, Sinnhaftigkeit der Arbeit und Selbstwirksamkeitserwartung. Ich finde meinen Text gerade nicht, daher ist es um so besser, dass Talia Lancaster einen Vortrag zu dem Thema gehalten hat, den man sich ansehen kann.

Der Vortrag fasst dabei nicht nur die Ergebnisse des Aristoteles-Projekts zusammen, sondern zeigt auch auf wie im eigenen Unternehmen überprüft werden kann ob die verschiedenen Faktoren gegeben sind. Man kann sich also direkt für eine eigene Anwendung inspirieren lassen.

Nigel Bakers Vortrag "Playing Games with Scrum" ist ein interessanter Ansatz zur Erklärung agiler Frameworks, und vor allem einer den nahezu jeder sofort nachvollziehen können wird. Selbst wenn man nicht alle Spiele kennt die er hier als Analogie verwendet, einige dürfte jeder bereits gespielt haben, und die anderen werden nachvollziehbar erklärt.

Was darüber hinaus noch erwähnenswert ist, ist der lebhafte Vortragsstil, der alleine für sich genommen ein ausreichender Grund ist, sich das Video anzusehen.

Als ursprünglicher Geisteswissenschaftler, den es irgendwann in IT und Projektmanagement verschlagen hat, bin ich grosser Fan von Stefan Kühl. Als Soziologie-Professor der zum Thema Agilität forscht dürfte er einer der wenigen Kenner der Thematik sein, der selbst ausserhalb der Gruppe der Anwender und Erfinder der agilen Frameworks steht, weshalb er eher als viele andere zu einer neutralen Betrachtungsweise in der Lage ist.

Was ihn gleichzeitig von den meisten in seinem Bereich forschenden Wissenschaftlern unterscheidet ist die Fähigkeit pointiert und unterhaltsam zu sprechen. Dieser Talk zum Thema der Formalitäts-Affinität oder Formalitäts-Aversion agiler Organisationen ist ein schönes Beispiel dafür.

Mit diesem Talk hole ich mich gewissermassen selbst aus meiner Komfortzone, denn die Gleichsetzung von Agilität und Mindfulness (Achtsamkeit) löst in mir eigentlich spontanen Widerspruch aus. Das eine ist (im der Form in der es heute verstanden wird) etwas Systemisches, das andere eher etwas vor allem Personenbezogenes. Von daher habe ich bisher immer gesagt, dass Mindfulness zwar etwas Gutes ist, aber unabhängig von und ohne grosse Verbindung zur Agilität, und dass die Vermischung der beiden nur zu einer Verwässerung und Konfusion dieser Konzepte führt. Was Markus Wittwer herausarbeitet sind aber durchaus nachvollziehbare Parallelen: das Herstellen von Focus, das Maximieren von sinnhaften Aspekten der (eigenen) Tätigkeiten, die Bewältigung von Komplexität und der gelassene Umgang mit Veränderungen sind bei beiden zentrale Elemente. Zwar ist der Kontext ein anderer, aber die Herangehensweise ist vergleichbar.

Seit einiger Zeit bin ich der Meinung, dass alle agilen Mindsets und Methoden zwar schön und gut sind, dass der wahre Schlüssel zu mehr Agilität aber in der Auflösung der Abhängigkeiten zwischen Teams, Abteilungen und anderen organisatorischen Silos liegt (zumindest ab Grössenordnungen von 50 Mitarbeitern oder mehr). Jim Benson vom Modus Institute schlägt hier in die gleiche Kerbe und fügt dem Ganzen noch einige originelle Gedanken hinzu.

Ein Sekundär-Nutzen dieses Videos: wir haben mit ihm ein schönes Beispiel dafür, wie man mit minimalen Mitteln (Miro, einer Webcam und einem einfachen Editierprogramm) ein vernünftiges Erklär-Video inclusive Visualisierungen hinbekommen kann.

Bilder: Wikimedia Commons / Lambert van Kleef / U.S. Information Agency - Public Domain

Zu den Texten von mir die auch nach Jahren noch zuverlässig Diskussionen und Unglauben auslösen gehört Agilität, dort wo man sie nicht vermutet, in dem ich erwähnt habe, dass ich in einer deutschen Behörde agile Arbeitsweisen vorfinden konnte (wenn auch unter anderen Namen). Die bei den meisten Menschen verbreiteten Vorstellungen der Art wie dort gearbeitet wird gehen anscheinend komplett in die andere Richtung. Aber - sind staatliche Verwaltung und Agilität tatsächlich solche Gegensätze?

In Diskussionen zu diesem Thema mache ich mittlerweile zu Beginn eine noch weitgehendere Aussage: die ersten Organisationseinheiten die im modernen Europa agil gearbeitet haben waren Teile der staatlichen Verwaltung. Und nicht nur das, viele dieser Einheiten haben diesen Arbeitsmodus bis heute durchgehend beibehalten und setzen ihn mindestens genauso konsequent um wie die an den modernen agilen Frameworks orientierten Softwareentwicklungsteams.

Ein erstes Beispiel dafür ist die preussische Armee, die im 19. Jahrhundert die Auftragstaktik einführte, bei der zwar übergreifende Ziele vorgegeben werden, für deren Umsetzung die einzelnen Einheiten aber autonom vorgehen können. Dieser Führungsstil wurde später von fast allen westlichen Armeen übernommen und beibehalten, u.a. ist er anscheinend ein zentraler Grund für die Erfolge der ukrainischen Armee gegen die im Frühling 2022 gestartete russische Invasion.

Ein zweites Beispiel sind die modernen Berufs-Feuerwehren, die erstmals im 17. Jahrhundert in Wien gegründet wurden und sich im Folgenden überall in Europa und Amerika und später im Rest der Welt etablierten. Die Löschzüge als kleinste Feuerwehr-Einheit haben von Beginn an alle Charakteristiken agiler Team gehabt: klein, crossfunktional, im Brandfall zu schnellen Reaktionen in der Lage, autonom und selbstorganisiert (zumindest während der Einsätze).

Ein weiterer Fall sind die Teams in den Notaufnahmen und Operationsräumen der modernen Krankenhäuser, die ebenfalls seit dem 17. Jahrhundert in Europa entstanden sind. Auch sie sind klein, crossfunktional, reaktionsfähig, autonom und selbstorganisiert. Eine andere Arbeitsweise wäre auch nicht vorstellbar, im Fall von Herzstillständen oder akuten Blutungen würden Befehlsketten oder Aufgabenteilung schliesslich den Tod der Patienten zur Folge haben.

Es liessen sich noch weitere Beispiele finden, vom Katastrophenschutz über die Stromnetz-Dispatcher, die Presse-Referate und die Einsatzgruppen der Polizei bis zur Flugverkehrskontrolle, die zentrale Erkenntnis ist aber klar: dort wo Dezentralisierung, Selbstorganisation, Autonomie, und Reaktionsgeschwindigkeit von Bedeutung sind ist auch (und gerade!) die staatliche Verwaltung dazu in der Lage, und das nicht nur seit Kurzem sondern bereits seit Jahrhunderten.

Bilder: Flickr / OSCEPA - CC BY-SA 2.0 + Pexels / Christina Morillo - Lizenz

Dass die Berufe des (agilen) Softwareentwicklers und des Politikers mehr Verbindendes haben als man auf den ersten Blick denken sollte hatte ich am Beispiel des "agilen Redens" schon einmal erwähnt, die Parallelen gehen aber weit über derartige Einzel-Aspekte hinaus. Sobald man diese beiden Tätigkeiten abstrahiert betrachtet zeigen sich grosse Gemeinsamkeiten in Herausforderungen, Rahmenbedingungen und Lösungsansätzen - sogar so grosse, dass der eine Beruf eine Analogie des anderen sein kann.

Zunächst finden beide in einem Umfeld statt das bestenfalls komplex und oft genug sogar chaotisch ist. In beiden Fällen müssen Systeme verändert werden die hochgradig unübersichtlich, vernetzt und durch schwer vorhersehbare Dynamiken geprägt sind, was in beiden Fällen dazu führt, dass die Folgen der eigenen Handlungen nur eingeschränkt absehbar sind. Um sicherzugehen, dass die eigenen Ziele erreicht werden ist daher eine kontinuierliche Validierung und Anpassung des Vorgehens nötig.

Sowohl die Politik als auch die Softwareentwicklung erfordern weitgehende Spezialisierungen, z.B. in Wirtschafts-, Innen- und Finanzpolitik oder in Frontend-, Backend- und Middleware-Entwicklung. Zwar gibt es Idealvorstellungen wie den in allen Fachgebieten bewanderten Politiker oder den Fullstack-Developer, in der Realität sind es aber praktisch immer Teams von mehr oder weniger ausgeprägten Spezialisten, die nur gemeinsam Ergebnisse liefern können.

Darüber hinaus haben beide Berufe ein Problem mit Legacy Code. Sowohl der Quelltext (englisch Source Code) in der IT als auch die Gesetzestexte (englisch: Law Code) in der Politik sind in einer z.T. weit zurückligenden Vergangenheit von Personen geschrieben worden die sich mittlerweile in Rente befinden oder den Job gewechselt haben. Sowohl die ursprüngliche Intention als auch die Lesbarkeit, die Ausführung oder die Verknüpfung zu anderen Code-Stellen sind häufig eine Herausforderung.

Die vielleicht grösste Gemeinsamkeit der beiden Berufswelten ergibt sich aber in ihrer Aussenwahrnehmeng. Beide werden kontinuierlich umlagert von einer Vielzahl an unterschiedlichsten Interessenvertretern, die mit nicht nachlassender Vehemenz darauf bestehen, dass ihr jeweils aktuelles Problem das wichtigste von allen wäre und sofort gelöst werden müsste. Und bekommen sie nicht ihren Willen sind sie im Zweifel schnell bereit zur Eskalation.

In meinen fünf Jahren in der politischen Verwaltung und meinen über 10 Jahren in der Softwareentwicklung ist mir im Rahmen dieser regelmässig stattfindenden Eskalationen eine weitere Übereinstimmung immer wieder aufgefallen: wenn Interessenvertreter ihre Wünsche nicht sofort erfüllt bekommen neigen viele dazu, den Grund dafür in einer Unfähigkeit des anderen zu sehen - "die Politik" oder "die IT" werden dann beschuldigt ihren Job nicht machen zu können oder zu wollen.

 Die Gründung einer irgendwie digitalen, agilen, innovativen oder sonstwie zukunftsgerichteten Tochter-Firma ist eine Idee auf die viele Konzerne gekommen sind, alleine im Rheinland dürfte es eine zweistellige Zahl derartiger Fälle geben. Rewe Digital ist eine der bekannteren unter ihnen, auch weil sie immer wieder auf vorbildliche Weise ihre Erfolge, Erkenntnisse und Wachstumsschmerzen in Vorträgen öffentlich gemacht haben. So auch hier in diesem Fall, indem die Firmengeschichte aus methodischer Sicht zusammengefasst wird:

Und da ich gerade dabei bin Gutes über andere Firmen zu sagen: auch bei der Telekom, die dieses Video (aufgenommen auf einer ihrer internen Veranstaltungen) öffentlich gemacht hat, kann man sich nur bedanken.

Das Konzept der brauchbaren Illegalität hat mich schon als Student fasziniert, und bis heute hat sich das nicht geändert. Stefan Kühl weist in diesem Vortrag auf einen Aspekt hin der oft heimlich verschwiegen wird: in vielen Organisationen ist diese Art des Regelbruchs Teil der Organisationskultur, ist also ein üblicher Weg des täglichen Arbeitens.

Für das tiefere Eintauchen in das Thema der Gesetzes- und Regelbrüche empfiehlt sich ein längerer Text den Kühl vor einiger Zeit geschrieben hat: Zur Entstehung, Durchsetzung und Regulierung von Regelabweichungen. Nicht nur wegen seines Inhaltes zu empfehlen sondern auch wegen seines umfangreichen Literaturverzeichnis.