Kommentierte Links (LXXXVIII)

Bild: Pixabay / Buffik - Lizenz

Das Internet ist voll von Menschen die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Roman Pichler: Product Teams in Scrum

Vor einiger Zeit hatte ich in den kommentierten Links über Brian Milner geschrieben, der der Meinung ist, dass jeder Product Owner ein zweites Team neben seinem Scrum Team hat, sein Stakeholder Team nämlich. Roman Pichler geht hier noch einen Schritt weiter und rät dazu, das Scrum Team durch die Integration der (zentralen) Stakeholder zu einem Product Team auszubauen. Das hat seinen Charme, und wie er richtigerweise schreibt sollte es durch die Einbeziehung der Stakeholder in Sprint Reviews und anlassbezogene Meetings ohnehin gegeben sein. Die Frage für mich ist aber: hat eine derartig vergrösserte Gruppe dann nach die Charakteristiken eines Teams?

Chris Combe: Untangling Organizational Dependencies

Es ist eine Falle in die viele Organisationen getappt sind während sie versucht haben sich in Richtung Agilität zu transformieren - mit der Absicht Bürokratie abzubauen werden mittlere Management-Schichten gestrichen, aber statt die Teams zu befreien werden diese dadurch mit zusätzlicher Abstimmungs- und Koordinationsarbeit überhäuft, die sie jetzt selbst machen müssen. Den Grund darin sieht Chris Combe in einem Denkfehler: der Annahme, dass es sich bei diesen Management-Schichten um Wildwuchs handeln würde, während sie in Wirklichkeit die notwendige Folge einer zu stark arbeitsteiligen Organisation mit Mehrfach-Zuständigkeiten sind. Vor einem Hierarchieabbau empfiehlt er daher mehr Empowerment der Teams.

Robert Galen: Key Differences for Internal vs. External Agile Coaches

In diesem Artikel habe ich vieles aus meinem Arbeitsalltag wiedergefunden, in dem ich als externer Agile Coach immer wieder mit (Kunden-)internen Gegenübern zusammenarbeite. Robert Galen hat eine gute Übersicht über die Unterschiede in Wahrnehmung, Ansehen, Einfluss und weiteren Kategorien zusammengestellt. Was er aufbauend darauf für sinnvoll hält ist die Einbindung beider Typen in den Agile Coaching-Chaptern oder -Gilden von Unternehmen. Die Externen können immer wieder neue Impulse und an anderen Orten gemachte Erfahrungen einbringen, die Internen können langfristig wirken und Netzwerke aufbauen, ausserdem ist durch sie eine langfristige Identifikation mit der Firma gegeben.

Robert Falkowitz: Using 5S to Keep your Kanban Board Organized in Practice

Bei Kunden deren Projekte einen Hardware-Anteil haben bin ich bereits mit 5S in Berührung gekommen, dort wird es u.a. für die Standardisierung, das Aufräumen und das Sauberhalten von Arbeitsplätzen genutzt. Robert Falkowitz schlägt hier einen weiteren Verwendungszweck vor, der bei näherer Betrachtung hochgradig naheliegend ist: den Betrieb von Kanban-Boards. Auch die haben bei nachlässiger Disziplin die Tendenz schnell unaufgeräumt und unübersichtlich zu wirken, genau wie es bei Arbeitsplätzen der Fall ist. Und mit den selben Methoden in denen man dort für Ordnung sorgt können auch Kanban-Boards (wieder) in den Zustand kommen übersichtlich und selbsterklärend zu sein.

Matt K. Parker: Getting Started with Radical Collaboration

Einfache Zusammenarbeit war gestern, jetzt kommt die radikale Zusammenarbeit! Das klingt zwar etwas marktschreierisch, hat aber Substanz. Matt K. Parker versucht unabhängig von den gängigen methodischen Frameworks zentrale Faktoren für die Ein- und Durchführung intensiver Zusammenarbeit zu nennen. Gerade für die den Einsatz bei "Methoden-Muffeln" eine gute Zusammenstellung.

Chaos Engineering

Bild: Public Domain Pictures - CC0 1.0

Unter den verschiedenen agilen Frameworks gehört das Chaos Engineering zu den weniger bekannten, was vermutlich auch so bleiben dürfte. Es gibt keine bekannten Gründer-Figuren wie im Fall von Scrum, keine dahinterstehende kommerzielle Organisation wie im Fall von SAFe und (leider ein wesentlicher Punkt) keine Zertifikate, durch die der agil-industrielle Komplex zu seiner Verbreitung beitragen würde. Dafür hat Chaos Engineering etwas ganz Anderes: praktische Relevanz.

Entwickelt wurde der Ansatz ca. 2010 bei Netflix, dem amerikanischen Video-Streamingdienst. Den Entwicklern dort wurde über die Zeit schmerzhaft klar, dass sie auf ihren Test-Umgebungen weder das Systemverhalten noch das Anwenderverhalten genau so simulieren konnten wie es in der unberechenbaren Realität auftrat. Wiederholt kam es dort daher zu Fehlern. Ihre Lösung: die Verlagerung einer Grossteils der Qualitätssicherung in den Live-Betrieb.

Die dahinterstehende Logik: wenn Störungen der Live-Umgebungen schon nicht zu vermeiden sind, dann sollten sie zumindest schnell entdeckt werden können und sofort behebbar sein. Und wenn möglich sollten Fehler während der Arbeitszeit auftreten, wenn jemand da ist der sie schnell beheben kann und nicht irgendwann in der Nacht. Um das zu erreichen sollten die Systeme tagsüber ständigen Stresstests ausgesetzt werden, um diese Fehler so auslösen und beheben zu können.

Since we knew that server failures are guaranteed to happen, we wanted those failures to happen during business hours when we were on hand to fix any fallout. We knew that we could rely on engineers to build resilient solutions if we gave them the context to expect servers to fail. If we could align our engineers to build services that survive a server failure as a matter of course, then when it accidentally happened it wouldn’t be a big deal. In fact, our members wouldn’t even notice. This proved to be the case.

Netflix Tech Blog, 2015

Der technische Kern des Chaos Engineering ist die so genannte Affen-Armee, eine Gruppe von Programmen die diese Tests durchführen. Die bekanntesten unter ihnen sind der Chaos Monkey, der nach Zufallsprinzip Live-Server kurzzeitig abschaltet und der Chaos Gorilla, der das Gleiche mit ganzen Rechenzentren macht. Darüber hinaus existieren u.a. der Latency Monkey, der Conformity Monkey und der Security Monkey, die meisten von ihnen als Open Source veröffentlicht.

Den methodischen Rahmen um die Technik bilden die Principles of Chaos Engineering, die ein grober Leitfaden für die Anwendung des Frameworks sind. Im Kern stehen dabei die vier Grund-Prinzipien:

1. Start by defining ‘steady state’ as some measurable output of a system that indicates normal behavior.
2. Hypothesize that this steady state will continue in both the control group and the experimental group.
3. Introduce variables that reflect real world events like servers that crash, hard drives that malfunction, network connections that are severed, etc.
4. Try to disprove the hypothesis by looking for a difference in steady state between the control group and the experimental group.

Mit anderen Worten: definiere einen messbaren, stabilen Ausgangszustand, lass die Affen-Armee auf ihn los und wenn etwas kaputtgeht finde heraus warum. Wichtig ist an dieser Stelle, dass in diesen Prinzipien von dem bei Netflix im Mittelpunkt stehenden Testen auf der Live-Umgebung noch nicht die Rede ist. Dadurch wird Chaos Engineering auch für kritische Anwendungen nutzbar, etwa den Betrieb von Stromnetzen, die man nicht testweise abschalten sollte.

Für andere Anwendungen, bei denen eine Ausfallzeit von wenigen Sekunden oder Minuten unkritisch ist gibt es die "Advanced Principles", deren Umsetzung schwieriger ist, dafür aber auch einen deutlich  höheren Mehrwert bringt:

1. Build a Hypothesis around Steady State Behavior.
2. Vary Real-world Events.
3. Run Experiments in Production.
4. Automate Experiments to Run Continuously.
5. Minimize Blast Radius.

Auch das in vereinfachten Worten: definiere in der Live-Umgebung einen messbaren, stabilen Ausgangszustand, lass die Affen-Armee in immer neuen Variationen auf ihn los und arbeite daran, dass die Auswirkungen immer geringer werden. Der letzte Punkt ist dabei das grosse Ziel - durch immer bessere Ausweichmechanismen und immer grösser werdende Unabhängigkeit von Komponenten und Regionen wird die Auswirkung von Fehlern und Ausfällen immer kleiner (hier ein Beispiel).

Podcasting

Bild: Pixabay / Connie_SF - Lizenz

Wer wissen möchte was ich denke und wie ich schreibe kann das auf dieser Zeite in ausreichendem Ausmass erfahren. Mehrere hundert Texte sind über die Jahre zusammengekommen, das sollte für einen halbwegs soliden Eindruck reichen. Auch wie ich aussehe ist mittlerweile klar, auf mehrfachen Wunsch habe ich auch ein Bild hochgeladen. Nur wie ich mich anhöre blieb unklar - bis dieses Jahr. In den letzten Monaten war ich in zwei Podcasts zu Gast, natürlich auch in Folgen zum Thema Agilität.

Der neuere der beiden Auftritte fand bei den Produktwerkern statt, wo ich mit Oliver Winter über Agilität im Konzern sprechen durfte. Mein Spezialgebiet gewissermassen, den Grossteil meiner Einsätze als Berater, Agile Coach und Scrum Master hatte ich in Banken, Versicherungen, Handelskonzernen und den Herstellern von Strom und Autos. Ohne den Inhalt vorwegnehmen zu wollen - es ist nicht alles so schlimm wie viele denken, in einigen Aspekten ist Agilität im Konzern sogar einfacher als in kleinen Firmen.

Anhören bei: Apple Podcasts, Google Podcasts, Spotify

Auch der zweite, schon etwas zurückliegende, Podcast-Auftritt dreht sich um dieses Thema. In André Claassens OKR-Podcast habe ich darüber gesprochen welche Metriken man benutzen könnte um in agilen Transitionen nicht nur die Effektivität der Teams zu messen sondern auch die Wirksamkeit des Managements. Das Thema war ursprünglich ein Text auf dieser Seite, daraus wurde später ein Konferenz-Vortrag auf der Manage Agile und darüber dann eine Podcast-Folge bei André.

Anhören bei: Apple Podcasts, Google Podcasts, Spotify

Open Space-Meetups

Bild: Wikimedia Commons / Plain Schwarz - CC BY-SA 2.0

Wer öfter in der agilen Community im Raum Köln/Bonn unterwegs ist wird herausgefunden haben, dass ich hier regelmässig auf verschiedenen lokalen Meetups und Konferenzen anzutreffen bin. Und wer noch genauer hinschaut wird merken, dass die alle eine Gemeinsamkeit haben. Es ist nicht das Thema Agilität (obwohl das zumindest bei den meisten der Fall ist) sondern etwas Anderes: praktische alle Events auf denen man mich trifft sind als Open Space organisiert.

Diese in den 80er Jahren vom Amerikaner Harrison Owen entwickelte Methode ist anders als die meisten anderen, da sie auf zentrale Elemente verzichtet die sonst auf jeder halbwegs organisierten Zusammenkuft anzutreffen sind: es gibt keine vorher feststehende Agenda (mitunter nicht einmal ein festgelegtes Thema), keine Pausen und keine klar erkennbare Trennung zwischen passiven und aktiven Teilnehmern (bzw. Besuchern/Zuhörern und Rednern/Referenten).

Die Inhalte und die Agenda entstehen stattdessen selbstorganisiert. Nach einer kurzen Erklärung des Vorgehens (oft durch eine spontan im Raum ermittelte Person die es kennt) kann jeder vortreten, sein Vortrags- oder Diskussions-Thema vorstellen und es an eine Sammelwand hängen. In einem anschliessenden "Marktplatz" können die Themen Zeit-Fenstern und Räumen zugeordnet und ggf. zusammengelegt werden. Auch das geschieht hierarchiefrei durch eine Gruppendiskussion (wobei Themen nur von ihrem Verfasser bewegt werden sollten). Das Ergebnis sieht dann z.B. so aus:

An diesem Fall (aufgenommen auf dem Scrumtisch Bonn) ist gut zu sehen was im Marktplatz passieren kann: Themen-Zusammenlegungen, Uhrzeit-Änderungen und das spontane Hinzufügen eines weiteren Raumes ("Woanders") um noch ein zusätzliches Thema unterbringen zu können. Auch die einfache und schnelle Organisation mit Flipcharts (oder Wänden), Post-Its und Filzstiften ist typisch, sie ist eine Reminiszenz an die Entstehung des ersten Open Space in einer Kaffeepause einer Tagung.

Während der Vorträge gilt dann das Gesetz der zwei Füsse: jeder Teilnehmer kann und darf jederzeit zwischen den Räumen wechseln egal ob es nur zum Zuhören ist (dann spricht man von einem "Schmetterling") oder um Ideen und Impulse hin- und herzutragen (dann spricht man von einer "Hummel"). Auch das dauerhafte Verbleiben in einem Raum ist aber möglich, und sogar das durchgehende Führen von Spontangesprächen im Flur oder vor der Tür.

Der einzige formale Teil auf den in der Regel geachtet wird ist das Closing am Ende, in dem alle Teilnehmer aus ihren Runden berichten können, wobei es egal ist ob es in diesem Bericht um Ergebnisse, Eindrücke, offen gebliebene Fragen oder neue Erkenntnisse geht. In Firmen-internen (oder aus sonstigen Gründen in langfristige Prozesse eingebundenen) Open Spaces können hier auch Folge-Aktivitäten vereinbart werden, auf Meetups und Konferenzen ist das eher selten.

Warum das Open Space-Format auf die agile Community so anziehend wirkt dürfte offensichtlich sein, in beiden Fällen nimmt die Selbstorganisation von Gruppen einen zentralen Platz ein. Und auch eine problemlose Skalierung ist möglich, neben den Scrumtischen, die hier im Rheinland meistens eine Teilnehmerzahl im niedrigen oder mittleren zweistelligen Bereich haben, ist auch die Agile Cologne-Konferenz mit hunderten Teilnehmern ein Open Space.

Esoterik

Bild: Wikimedia Commons / M. Pierre Morissoneau - CC BY 4.0

Für die meisten Menschen dürfte das jetzt überraschend kommen, aber wenn wir über Projekt- oder Produktmanagement sprechen müssen wir uns auch über Esoterik unterhalten. Anders als man denken könnte wird dieser Themenkomplex nämlich nicht nur von harten Zahlen, überprüfbaren Berechnungen und empirischer Kontrolle geprägt, in weiten Teilen ist das genaue Gegenteil der Fall - selbst weitreichende Entscheidungen beruhen auf etwas was man nur als Esoterik bezeichnen kann.

Zum besseren Verständnis eine kurze Begriffserklärung: Esoterik ist ursprünglich vom altgriechischen ἐσωτερικός (Esōterikós) abgeleitet und bedeutet in etwa "nur von innen verstehbar", man könnte es mit "Geheimlehre" übersetzen. In einer moderneren Interpretation versteht man darunter alle möglichen Glaubenssätze die zwar für sich genommen wenig Sinn ergeben, denen aber unterstellt wird, dass das nur daran liegt, dass sie nicht gut genug erklärt oder verstanden wurden.

Derartige Glaubenssätze bestehen sowohl im Umfeld klassischer Management-Lehren als auch in den New Work- und Agile-Bewegungen. Da Menschen aber dazu neigen derartige Phänomene vor allem bei anderen wahrzunehmen und bei sich selbst zu verdrängen (man spricht vom Blind Spot Bias) tritt oft das kuriose Phänomen auf, dass die Vertreter der alten und neuen Vorgehensmodelle sich gegenseitig Esoterik vorwerfen, sich selbst aber als nicht betroffen ansehen.

Ein Beispiel für esoterische Glaubenssätze im klassischen Management ist die Überzeugung, dass Menschen in grossen Organisationen nicht in der Lage sind ohne Anleitung und Überwachung zu arbeiten. Obwohl schon seit Jahrhunderten von der Realität widerlegt bildet sie die Grundlage dafür, dass der Führungsstil des Top-Down-Management immer wieder hartnäckigt verteidigt oder unter neuem Namen wiederbelebt wird (z.B. "Führung" statt "Management").

Auch in den neueren, eher hierarchiefreien Ansätzen kann man Esoterik antreffen, zum Beispiel in Form des umgekehrten Glaubenssatzes, dass man einer Gruppe von Menschen nur Selbstorganisation ermöglichen muss um die optimale Lösung aller Probleme zu erhalten. Dass das ohne Vorbereitung und Begleitung in den vielen Fällen in die Autonomie-Falle oder zu Kompetenzüberschreitungen (mit nachfolgenden Konflikten) führt wird dabei ignoriert oder sogar in Abrede gestellt.

Bei näherer Betrachtung gibt es zahllose weitere Beispiele für esoterische Überzeugungen im Projekt- oder Produktmanagement. Von detaillierten Umsetzungsplänen als Vorbeugung für ungeplante Veränderungen über Retrospektiven als universales Heilmittel für alles bis hin zu "magischen Gegenständen" wie Status-Reports oder Kanban-Boards die alleine durch ihre blosse Existenz schon zu Verbesserung führen sollen.

Dass es sich bei diesen Grundsätzen um Esoterik handelt kann man deutlich an ihrer üblichen Begründung (bzw. Nicht-Begründung) sehen. Statt mit Fakten oder empirischen Belegen wird hier in der Regel mit inneren Erkenntnissen argumentiert die man eben hat oder nicht hat. Im Rahmen eher klassischer Vorgehensweisen ist das "der gesunde Menschenverstand", bei den neueren "das (agile) Mindset". Was genau das ist wird in beiden Fällen praktisch nie erklärt. Es ist einfach da.

Die Realität ist natürlich deutlich komplexer als das. Kein einfacher Glaubenssatz kann die zahlreichen Wechselwirkungen und Dynamiken in grossen Systemen abbilden, alleine deshalb nicht weil es kaum zwei gibt die wirklich gleich sind (selbst bei gleichgrossen Unternehmen des selben Branche). Was stattdessen vorkommt sind Mischtypen und Annäherungswerte, die ständigen Veränderungen unterliegen und daher ständig neu betrachtet und behandelt werden müssen.

Technische Schulden (II)

Bild: Pixabay / Raten-Kauf - Lizenz

Wir müssen noch einmal über das Thema der technischen Schulden sprechen, genauer gesagt über eines der grössten damit verbundenen Probleme: die Unklarheit darüber was mit diesem Begriff eigentlich gemeint ist. Wie bereits gesagt ist nicht jeder Fehler oder jeder Qualitätsmangel im Code automatisch eine technische Schuld, das ist nur dann der Fall wenn diese Missstände bewust in Kauf genommen wurden um ein anderes Ziel zu erreichen. Aber auch das ist noch nicht alles.

Tatsächlich kann es auch technische Schulden geben die nicht bewusst "aufgenommen" wurden sondern mehr oder weniger versehentlich entstanden sind oder von jemand anderem (einem anderen Team, einem Zulieferer, einem aufgekauften Wettbewerber, etc) übernommen wurden. Das Entscheidende ist in diesen Fällen nicht mehr der Entstehungskontext sondern etwas Anderes - der Beschluss die Behebung in die Zukunft zu verschieben.

Um das besser zu verstehen ein kurzer Einschub: eigenlich ist es Best Practice Good Practice Fehler in der Software sofort zu beheben sobald sie entdeckt werden (🡪 Zero Bug Policy). Unterbleibt das besteht ein erhebliches Risiko, dass es zu einem "Jenga-Effekt" kommt: weitere, neue Funktionen bauen (bewusst oder unbewusst) auf den bestehenden, fehlerhaften auf, und wenn diese repariert und dadurch verändert werden stürzt das ganze Konstrukt in sich zusammen.

Es kann  aber Gründe dafür geben diese Reparaturen nicht sofort vorzunehmen, vor allem dann wenn ein wichtiger Liefertermin anliegt und für die entdeckten Fehler ein kurzfristiger Workaround möglich, eine sofortige Behebung dagegen relativ aufwändig wäre. Um den Termin einhalten zu können kann es in solchen Situationen Sinn machen die mit einer späteren Reparatur verbundenen Mehraufwände zu akzeptieren - und genau das ist nichts anderes als das Aufnehmen technischer Schulden.

Ist das ein realistisches Szenario? Es kommt darauf an, wie so oft. Bei stabilen Teams die langfristig an einem Produkt arbeiten ist diese Art der technischen Schuld eher ein Ausnahmefall, in Organisationen in denen Software in einer Abfolge von Projekten mit wechselnder Personalbesetzung entwickelt wird ist es eher die Regel, genauso in Systemlandschaften mit vielen Legacy-Anwendungen. Und seien wir ehrlich, die beiden letzten Typen sind in Konzernen der Normalfall.

Das Ergebnis dieser "Normalität" ist eine Art von Generationenvertrag - die aktuelle Entwicklergeneration hält ihre Systeme durch die Aufnahme technischer Schulden irgendwie am Laufen und kann sie so (mehr oder weniger) funktionierend an ihre Nachfolger übergeben, die dann vor der Wahl stehen sie in Form von Reparatur- und Aufräumarbeiten abzubezahlen oder noch mehr aufzunehmen und das Problem an die übernächste Generation weiterzugeben.

Und nochmal, auch dieses Weitergeben von immer schlimmer werdenden technischen Schulden über mehrere Generationen hinweg ist leider nicht unrealistisch, verbunden mit Wassermelonen-Projekten und Arschkarten-Lücken tritt es immer wieder auf. Um aber auch die andere Option zu nennen: ich habe es auch erleben dürfen, dass "geerbte" technische Schulden nach und nach abgebaut wurden. Das war anstrengend und fühlte sich ungerecht an, dafür wurde ab diesem Zeitpunkt alles wieder leichter.

Agilität, dort wo man sie nicht vermutet (II)

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.

Scaling with Scale-free Networks

Mal wieder ein origineller Blick darauf wie in Organisationen Agilität skaliert werden kann. Die hier von Jim Coplien vorgetragene Sichtweise beruht auf der Idee, dass in einem weitgehend hierarchiefreien System netzwerkartige Verbindungen zwischen den einzelnen Einheiten bestehen, die auf den jeweils kommunikativsten Teammitgliedern beruhen. Diese bilden die Knotenpunkte eines organisationsweiten Netzwerks und formen gleichzeitig mit ihren weniger kommunikativen Kollegen kleinere lokale Netzwerke, in denen jeweils die Wertschöpfung stattfindet.

Was Copliens Ausführungen besonders macht ist ihre wissenschaftliche Fundierung. Seit den frühen 90er Jahren erforscht er Organisationen und verdichtet die in diesem Rahmen erhobenen Daten zu wiederkehrenden Mustern. Das auch auf die eigene Organisation anzuwenden könnte spannend sein, das Tool stellt er zur Verfügung.

Der Sog der Addition

Bild: Wikimedia Commons / Tony Hisgett - CC BY 2.0

Jeder der mit einer Gruppe von "Agilisten" zu tun hat, von der Scrum Master-Gilde eines beliebigen Unternehmens bis hin zu den Teilnehmern eines beliebigen Agile Meetups, kann einen Versuch wagen: wenn man mit den Gruppenmitgliedern in den Gedankenaustausch geht über die Themen für deren Verwirklichung sie sich einsetzen - werden alle von ihnen einen wirklichen Agilitäts-Bezug haben? Die Antwort ist in den meisten Fällen nein, und dafür gibt es auch Gründe.

Bevor wir auf diese eingehen eine kurze Erklärung: Agilität im Sinn der Verfasser des Agilen Manifests dreht sich um eine schnelle Liefer- und Reaktionsfähigkeit in der Produktentwicklung. Das Verständnis das man in Firmen und Communities antrifft umfasst oft wesentlich mehr: Innovations- und Kreativitäts-Förderung, Diversität, Inklusion, New Work (was auch immer darunter verstanden wird), betriebliche Mitbestimmung, Ablehnung bestimmter Management-Praktiken und vieles mehr.

Die Ursache für dieses Phänomen liegt darin, dass die Vertreter der agilen Arbeitsweisen zu Beginn ihrer Tätigkeiten meistens eine kleine Minderheit sind und später zwar zahlreicher werden, in vielen Fällen aber in die Thukydides-Falle tappen und sich einen Abnutzungskampf mit den Vertretern des "klassischen Managements" liefern. Um Gehör und Mehrheiten für ihre Ideen zu finden liegt es daher nahe Koalitionen mit den Vertretern ähnlicher Ideen einzugehen.

Diese Koalitionen kommen allerdings mit einem Preis: um für ihre verschiedenen Fraktionen attraktiv zu sein muss jede von ihnen bereit sein die Interessen des jeweils anderen zu unterstützen. Bedingt dadurch weitet sich das Themenspektrum der "agilen Bewegung" - zu dem Wunsch nach schlankeren und flexibleren Strukturen kommt z.B. der nach neuen Produktideen, einem Recht auf Heimarbeit oder der Förderung gesellschaftlicher Minderheiten.

Zu Beginn haben diese zusätzlichen Themen in der Regel noch gemeinsame Schnittmengen mit der Agilität, irgendwann kann die Koalition aber so gross werden, dass Teile von ihnen Ziele aus völlig anderen Bereichen verfolgen und auf die gemeinsame Agenda setzen, z.B. Anti-Kapitalismus.¹ Der Soziologe Sven Hillenkamp, der derartige Tendenzen in der Klima-Bewegung untersucht hat, nennt sie den "Sog der Addition", durch den immer weitere Ziele entstehen und ggf. sogar die alten überlagern.

Eine derartige fortlaufende Erweiterung des Themenspektrums hat Folgen: zum einen kommt es zu der zu Beginn beschriebenen Begriffsüberfrachtung, durch die es immer unklarer wird was eigentlich gemeint ist wenn jemand den Begriff der Agilität benutzt. Zum anderen werden die Vertreter des agilen Vorgehens in Konflikte hineingezogen an denen sie eigentlich gar nicht interessiert sind, z.B. zwischen dem Top-Management und dem Betriebsrat.

Um sich nicht in derartigen, für das eigene Anliegen eigentlich unwichtigen, Konflikten aufzureiben und um dieses eigene Anliegen wieder klarer und trennschärfer beschreiben zu können, macht es Sinn regelmässig zu überprüfen ob die Koalition in der man als agile Bewegung gelandet ist noch immer die Richtige ist oder ob es eine nicht länger nötige Zweckgemeinschaft war. Ein Beispiel: man mag den Kampf für mehr Home Office für sinnvoll halten, zwingend verbunden mit Agilität ist er aber nicht.

Natürlich kann eine derartige Refocussierung zu Streitigkeiten und Trennungsschmerzen führen, schlimmstenfalls verbunden mit persönliche Zerwürfnissen zwischen Kollegen und Freunden. Dieser Schritt sollte also nicht unüberlegt gegangen werden. Wird er vermieden sollte man sich allerdings der oben genannten Konsequenzen bewusst sein und diese intern thematisieren. Und ganz im Sinne von Inspect & Adapt sollte das Thema regelmässig auf die Wiedervorlage.