Donnerstag, 30. November 2023

Kommentierte Links (CVII)

Bild: Unsplash / Fabio Bracht - 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.

Patrick McKenzie: Seeing like a Bank

Ein Logread, und dabei einer der es in sich hat. Am Beispiel der Banken-Branche beschreibt Patrick McKenzie wie es dazu kommt, dass in grossen Organisationen Prozesse und IT-Systeme immer wieder dysfunktional wuchernd ausser Kontrolle geraten. Anders als häufig unterstellt stehen normalerweise weder Inkompetenz noch sinistre Absichten dahinter, sondern vor allem Sachzwänge betriebswirtschaftlicher oder juristischer Natur, die jeweils für sich betrachtet auch vollkommen rational und nachvollziehbar sind. Erst die unbeabsichtigten Effekte ihres Zusammenwirkens führen zu den teils bürokratischen und teils chaotischen Zuständen, die in der Aussenwahrnehmung zu Fassungslosigkeit führen können (mit der Postbank gibt es ein anschauliches aktuelles Beispiel).

Karl Scotland: A Simple Resolution to the Agile Transformation Conundrum

Begriffe sorgfältig auszuwählen ist wichtig, denn häufig formen sie unsere Wahrnehmung des jeweiligen Sachverhalts viel tiefer als man denken sollte. Vor diesem Hintergrund sind die Überlegungen von Karl Scotland zu verstehen, der sich entschlossen hat, den Begriff "Agile Transformation" bei sich durch "Strategic Agility" zu ersetzen. Die Benennung Agile Transformation hält er aus zwei Gründen für problematisch: zum einen weil sie den Eindruck von Linearität und Abschliessbarkeit vermitteln kann, zum anderen weil der Eindruck entstehen kann, Agilität wäre das Ziel der Transformation und damit ein Selbstzweck. Dass es gelingen wird, den Begriff der Agilen Transformation auch in der allgemeinen Verwendung abzulösen, kann man bezweifeln (dafür ist er zu etabliert), ein wertvoller Impuls für die eigene Sprachverwendung ist es aber auf jeden Fall.

Roman Pichler: Decoding Product Leadership

Leadership ist immer ein schönes Thema, vor allem im Umfeld selbstorganisierter Teams, in denen eine direkte Weisungsbefugnis nicht mehr oder nur eingeschränkt gegeben ist. Roman Pichler beleuchtet das Konzept von verschiedenen Seiten und beschreibt unter anderem charismatische Führung (allerdings ohne diesen Begriff zu verwenden), informelle Führung und emergente Führung. Interessant sind auch seine verschiedenen Dimensionen von Product Leadership: Trust-building, Empathising, Communication, Goal Setting, Collaborative Decision-Making, Conflict Resolution und Self-Leadership. Was das im Anwendungsfall bedeutet, wird zwar jeder für sich erarbeiten müssen, es ist aber eine gute Übersicht über die Felder, in denen man Führungsqualitäten entwicklen kann.

Chris Alderson: Beyond Scaled Agile Frameworks

Nochmal zum Thema der sorgfältigen Begriffsverwendung und zu der Schwierigkeit, bereits etablierte Begriffe abzulösen. Chris Alderson schlägt vor, anstelle von agilen Skalierungsframeworks von "massgeschneiderten Betriebsmodellen" zu sprechen. Sicherlich vom Ansatz her richtig (eine Umsetzung "by the Book" ist auf Skalierungebene nochmal schwieriger und seltener als auf Teamebene) aber eben auch ein Kampf gegen Windmühlen. Wichtiger als die Benennung ist allerdings die Grund-Idee: sich aus den "Bausteinen" der verschiedenen Skalierungsframeworks ein eigenes Vorgehensmodell zusammenzubauen (z.B. Lean Portfolio Management aus SAFe, Scrum of Scrums aus Scrum@Scale, etc) dürfte den jeweiligen Bedürfnissen in der Regel eher entsprechen als das Ausrollen einer "One Size fits All"-Lösung.

John Cutler: How to Troubleshoot Status Updates and Syncs

Als letztes eine nützliche Liste von Praxistipps zu einem Thema, das in jeder grösseren Organisation immer wieder hochkommt: zu viele und zu ineffektive Meetings. John Cutler teilt eine ganze Reihe möglicher Probleme, bietet zu jedem eine Analyse häufiger Ursachen und eine Idee, wie man zu Verbesserungen kommen kann. Da sollte für jeden etwas dabei sein, das sich im eigenen Unternehmen ausprobieren lässt.

Montag, 27. November 2023

Podcasting (III)

Bild: Unsplash / Will Francis - Lizenz

Vor kurzem bin ich halb im Scherz als "Podcaster ohne Podcast" bezeichnet worden, da ich mittlerweile in mehreren zu Gast gewesen bin. Ganz soweit würde ich zwar nicht gehen (es sind bisher gerade einmal sechs solche Gastauftritte zusammengekommen), aber wer weiss was noch kommt. Hier sind erstmal die beiden neuesten.


Der hier ist schon einige Wochen her, und er dürfte das vielleicht kontroverseste Thema haben, mit dem ich bisher an die Öffentlichkeit gegangen bin. In André Claassens OKR-Podcast habe ich mit ihm darüber gesprochen, warum ein Scrum Master kein Coach sein kann (u.a. wegen keiner Auswahl durch die Coachees und keiner eigenen Agenda-Freiheit). Da viele Inhaber dieser Rolle sich aber explizit als (Agile) Coaches sehen habe ich in Folge einige lebhafte Feedbacks erhalten.

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


Die neueste Aufnahme ist wieder eine zu einem meiner Lieblingsthemen, zu dem ich auch schon Konferenzvorträge und eine andere Podcast-Aufnahme gehabt habe: Transformations-Metriken, an denen das Management auch die Ergebnisse der eigenen Arbeit messen kann, und nicht nur die der Ausführungsebene. Mit Miriam Sasse und Ellen Duwe vom Agile World News-Podcast hatte ich diesesmal gleich zwei Gesprächspartnerinnen um mich darüber auszutauschen.

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

Donnerstag, 23. November 2023

Continuous Integration: That’s Not What They Meant

Das schönste Missverständnis zum Begriff CI habe ich einmal mit einer UX-Designerin erlebt, die der festen Meinung war, die Entwickler in ihrem Team würden über Corporate Identity sprechen. Clare Sudbery dürfte über dieses Level an Verständnis weit, weit hinausgekommen sein. Richtigerweise ist es bei ihr Continuous Integration, oder wie es ihrer Meinung nach heissen müsste "Continuous Trunk Based Development" (CTBD).



Wer CI kennt, wird vor allem nickend vor dem Bildschirm sitzen, einige kleine Erkenntnisse sind aber sicherlich für jeden dabei. Mir war zum Beispiel nicht klar, dass Kent Beck bereits im Rahmen von Extreme Programming CI (noch unter einem anderen Namen) beschrieben hat.

Montag, 20. November 2023

Tech Lead Manager

Bild: Pexels / Ketut Subiyanto - Lizenz

Zu den Überraschungen, die man in grossen Firmen aus dem Silicon Valley erleben kann, gehört die fast vollständige Abwesenheit von Scrum Mastern, Agile Coaches, People Managern und vergleichbaren Rollen. Das erscheint zunächst merkwürdig, schliesslich gelten Google, Facebook, Netflix & Co doch als Vorzeige-Beispiele gelungener Agilität. Und es wirft die Frage auf, welche Führungsrollen es dort stattdessen gibt. Eine auf die man dabei immer wieder stösst, ist die des "Tech Lead Managers" (TLM).


Um diese Rolle einordnen zu können: die klassische Silicon Valley-Rollenteilung ist die in Engineering Manager und Tech Lead.1 Den Engineering Manager kann man sich dabei wie eine Mischung aus Abteilungs-Leiter und Product Owner vorstellen, mit der Besonderheit, dass er selbst einmal Softwareentwickler gewesen sein muss.2 Der Tech Lead oder Lead Developer ist ein teaminterner oder -externer Experte, der den Entwicklern Entwicklungsprozesse und -standards vorgibt.


Beide Rollen haben im Vergleich zu einem Scrum Master, Product Ower, Agile Coach oder People Manager eine relativ hohe Weisungsbefugnis gegenüber ihren Teammitgliedern. Der Grund dafür sind zwei weitere Besonderheiten: die Entwickler sind im Durchschnitt eher jung, und sie wechseln verhältnismässig häufig (mitunter jährlich) den Job. Beides liegt daran, dass für viele das stressige Silicon Valley nur ein "Karriere-Sprungbrett" ist, mit dem sie sich für andere Firmen empfehlen.3


Bedingt dadurch sind viele Teams eher unerfahren und befinden sich in einer permanenten Storming-Phase, was durch die eher anleitende Ausgestaltung der Rollen kompensiert werden soll. Das kann auch funktionieren, bringt aber das Risiko mit sich, dass die beiden leitenden Rollen sich aufgrund ihrer unterschiedlichen Interessen gegenseitig blockieren. Dort wo Geschwindigkeit wichtig ist, werden sie daher oft zum Tech Lead Manager zusammengefasst, der alle Entscheidungen alleine treffen kann.


Im Vergleich zu den aus dem Osten der USA stammenden Ansätzen Scrum und Extreme Programming mag das auf den ersten Blick wenig agil wirken, da diese Rolle die Selbstorganisation der Teams stark einschränken kann. Wird Agilität aber einfach als schnelle Reaktions- und Lieferfähigkeit verstanden, kann dieser eher hierarchische Ansatz in derartig volatilen Teams der zielführendere sein (was übrigens nicht bedeutet, dass hier Micro-Managing stattfindet, das wäre nochmal etwas Anderes).


Zu bedenken ist dabei allerdings, dass diese Doppelrolle für ihren Inhaber sehr fordernd und belastend sein kann, was auf Dauer zu neuen Problemen führt. Aufgrunddessen ist es z.B. bei Google so, dass sie vor allem in kleinen, neu zusammengestellten, oder in instabilen Umgebungen arbeitenden Teams geschaffen wird, während stabiliere oder erfahrenere Teams eher wieder die klassische Doppelspitze aus Engineering Manager und Tech Lead haben (siehe hier).


Was erkennbar wird: die Rolle des Tech Lead Manager kann durchaus entscheidend für einen agilen Arbeitsmodus sein, sie ist aber so spezifisch für das Silicon Valley, dass sie nur schwer übertragbar ist. Man kann sie zwar auch in Europa oder an der US-Ostküste einführen, hier würde aber das starke Risiko bestehen, dass sie zu einem Flaschenhals wird und das in den Teams vorhandene Wissen nicht ausreichend nutzt, und infolgedessen eine eher anti-agile Wirkung hätte.



1Natürlich gibt es von diesen Rollen zahllose Benennungs- und Ausgestaltungs-Varianten
2Wodurch verhindert werden soll, dass er fachlich richtige aber technisch fragwürdige Entscheidungen trifft
3Für eine bessere Vorstellung von dieser Arbeitswelt empfehle ich das Buch Chaos Monkeys von Antonio García Martínez

Freitag, 17. November 2023

Wie man nichts lernt

Bild: Pexels / Anna Tarazevich - Lizenz

Eigentlich sind Learning & Development-Angebote grossartig: Firmen wollen die Aus- und Weiterbildung ihrer Mitarbeiter fördern und stellen ihnen darum kontinuierlich neue Lerninhalte zur Verfügung. Gerade in grösseren Organisationen kippt dieser eigentlich gute Ansatz aber immer wieder ins Dysfunktionale. Ein aktueller Fall, den man den Medien entnehmen kann, ist der von Slack, bzw. Salesforce. Das Drama, das hier wohl stattgefunden hat, ist leider exemplarisch für vieles was häufig schiefläuft, und verdient daher eine nähere Betrachtung.


Ausgangspunkt ist anscheinend die Digitalisierung und Automatisierung von Lern-Angeboten, die Salesforce irgendwann durchgeführt hat, vermutlich um die Einheitlichkeit der vermittelten Inhalte sicherzustellen, um sich von der Verfügbarkeit von Trainern und Schulungsleitern unabhängig zu machen, um Reiseaufwände zu den Schulungszentren zu sparen und um durch die beliebig häufige Wiederholbarkeit des einmal erstellten Materials Kosten einzusparen. So weit, so gut.


Ebenfalls betriebswirtschaftlich getrieben dürfte eine zweite Entscheidung gewesen sein: als interne Lernplattform wurde Trailhead gewählt, ein bereits vorhandenes Tool, das eigentlich dafür gedacht ist, Anwendern beizubringen, wie die Salesforce-Anwendungen funktionieren. Ein wesentliches Element dieses Tools sind Gamification-Elemente, das heisst, Lern-Punkte, die man für das Bewerten von Kursen und das Abschliessen von Wissenstests sammeln kann. Ebenfalls erstmal ok.


Eher humanistisch motiviert war vermutlich die dritte Entscheidung: Im Sinn eines Studium Generale wurden auch Inhalte in die "Lehrpläne" einbezogen, die keinen unmittelbaren Bezug zur täglichen Arbeit haben, etwa Eräuterungen der "vierten Industriellen Revolution" (Industrie 4.0) oder zur gesunden Ernährung. Auch daran kann man für sich genommen nur Gutes finden, ein Blick über den Tellerrand schadet nie und beugt dem Entstehen von Fach-Idiotie vor.


Was anscheinend nicht bedacht wurde, war der durch diese Art der Wissensvermittlung entstehende Zeitaufwand. Die verschiedenen Inhalte erreichten in Summe einen bemerkenswerten Umfang, und durch die Gamification-Elemente liessen sie sich nicht mehr im Hintergrund abspielen, sondern erforderten ständige Interaktion. Um die vorgegebenen Lernziele zu erreichen musste daher Zeit im Umfang von mindestens 40 Stunden investiert werden.


Man kann jetzt versuchen, sich in die Mitarbeiter der Salesforce-Tochtergesellschaft Slack hineinzuversetzen. In ihrem Learning & Development-Portal fanden sie Inhalte, die zum Teil generisch und zum Teil beruflich irrelevant waren, nur mit hohem Zeitaufwand konsumierbar waren, in einem Tool angeboten wurden, das eigentlich erkennbar einem anderen Zweck dienen sollte, ohne die Möglichkeit Verständnis- oder Vertiefungsfragen zu stellen. Kaum einer nahm diese Lern-Angebote an.


Peinlich wurde das aus Sicht des Unternehmens dadurch, dass es für jeden offensichtlich war. Die Gamification Elemente sorgten nicht nur dafür, dass die einzelnen Mitarbeiter Lern-Punkte sammeln konnten, dadurch dass die Ranglisten intern öffentlich waren, wurde klar, dass kaum jemand Punkte sammelte, was im Umkehrschluss bedeutete, dass kaum jemand die Learning & Development-Angebote wahrnahm. Ein offensichtliches und verheerendes Feedback.


Ebenfalls verheerend war die Reaktion des Unternehmens: das Lernen wurde erzwungen, indem angeordnet wurde, dass alle anderen Tätigkeiten eingestellt werden mussten, bis vorgegebene Mindest-Punktzahlen im Lern-Tool erreicht waren. Und das am Ende des Jahres, mitten in der Phase, in der viele damit voll ausgelastet gewesen sein dürften, an der Erreichung ihrer (gehaltsrelevanten) Jahresziele zu arbeiten. Die Nicht-Begeisterung angesichts dieses "Lern-Zwangs" kann man sich vorstellen.


Aber wo Frustration entsteht, da wird nach Auswegen gesucht. Und da Software-Entwickler das Lösen technischer Probleme als Beruf haben, kam es bald zur absehbaren Pointe der Geschichte: die Mitarbeiter programmierten sich ihre eigenen Tools, die automatisiert die Gamification-Elemente in Trailhead durchklickten. So konnten die geforderten Lern-Punkte erzeugt werden, ohne dass man sich mit den aufgezwungenen Themen beschäftigen musste. Formalismus erfüllt, Lerneffekt gleich null.


Man kann sich jetzt überlegen, an welcher Stelle der eigentlich gute Learning & Development-Ansatz entgleist ist. Vielleicht bei der Idee, generische Inhalte für alle Mitarbeiter festzulegen, vielleicht beim Versuch, durch die Wiederverwendung eines für einen anderen Zweck konzipierten Tools Geld zu sparen, vielleicht bei der Erstellung einer Punkte-basierten "Lern-Planwirtschaft", vielleicht beim Versuch, den Erfolg des Vorgehens zu erzwingen. Vermutlich war es eine Kombination von allem.


Selbst wenn dieser Fall vermutlich ein extremer ist, die verschiedenen Entgleisungs-Ursachen finden sich in unterschiedlicher Ausprägung in sehr vielen grossen Organisationen wieder, was auch erklärt, dass die internen Lernangebote einen nicht besonders guten Ruf haben. Und ich kann es aus eigener Erfahrung sagen: selbstgebaute Tools, mit denen Entwickler lästige Pflichtkurse "wegautomatisieren", gibt es nicht nur bei Salesforce, sondern auch in anderen Firmen.


Wie immer bleibt zum Schluss die Frage, wie es besser ginge. Die verblüffend einfache Antwort: man kann die Mitarbeiter fragen, wie ihnen Lern-Angebot und Lern-Tools gefallen und beides basierend auf diesem Feedback so anpassen, dass es den Bedürfnissen entspricht. Das ist nicht immer die billigste Lösung, aber dafür eine, die wirklich für Learning & Development sorgt. Und ganz nebenbei ist es auch ein schöner Test dafür, wie ernst die propagierte Nutzer-Zentrierung wirklich gemeint ist.

Dienstag, 14. November 2023

Velocity (II)

Noch einmal zum Thema Velocity. Obwohl diese Metrik kein offizieller Teil von Scrum ist, ist sie in vielen Teams ein wesentliches Element der Umsetzung dieses Frameworks. Was dabei im Mittelpunkt steht, ist in der Regel der Planungs-Aspekt, also die Ableitung zukünftiger Arbeitsleistung aus der durchschnittlichen Story Point-Menge der letzten Sprints (siehe hier). Es gibt aber auch einen zweiten, seltener thematisierten Aspekt: eine Velocity erzeugt auch ein Work in Progress Limit (WIP Limit).


WIP Limits kennt man eigentlich aus Kanban und anderen Lean-Ansätzen, wo sie verwandt werden, um Überlastung und Multitasking zu vermeiden und den Arbeitsfluss zu verbessern. Die Idee ist eigentlich einfach: dadurch, dass eine Obergrenze für gleichzeitig bearbeitete Aufgaben eingeführt wird, werden weniger Arbeitspakete gleichzeitig begonnen, Multitasking und Koordinationsaufwände gehen zurück und Ergebnisse werden schneller fertig.


Das klingt erstmal gut, in der Realität kommt es allerdings regelmässig dazu, dass diese Obergrenzen zu hoch angesetzt werden. Wenn ihre Festlegung durch das Management erfolgt kann das z.B. daran liegen, dass die Kapazität der Umsetzungsebene zu optimistisch eingeschätzt wird (oft verbunden mit Wunschdenken in Bezug auf Fertigstellungstermine), oder dass möglichst vielen Stakeholdern das Gefühl gegeben werden soll, dass ihre Anliegen bearbeitet werden.


Aber auch wenn die Verantwortung für das Setzen der WIP Limits bei den jeweiligen Umsetzungsteams liegt, sind diese häufig zu hoch. Auch das kann daran liegen, dass versucht wird, möglichst viele Stakeholder zu befriedigen, mindestens genauso häufig ist aber eine unrealistisch optimistische Einschätzung der eigenen Leistungsfähigkeit oder eine Unterschätzung des mit bestimmten Tätigkeiten verbundenen Arbeitsaufwands.


Die Verwendung der Velocity sorgt dafür, dass die WIP-Obergrenzen realistischer werden. Wenn der durchschnittliche  Output der letzten Sprints (Yesterdays Weather) bei 18 Punkten liegt, und demzufolge auch maximal diese Menge für den nächsten eingeplant werden soll, dann verschwinden "politische" Handlungsmotive und unsichere Faktoren wie die Selbst- und Fremdeinschätzung der Leistungsfähigkeit eines Teams aus dem Planungsprozess. Alleine dadurch werden die Planungen besser.


Der Vollständigkeit halber sei noch angemerkt, dass Scrum Teams die Planung ihrer Sprints eigentlich nicht an einem Output (in diesem Fall der Velocity) sondern an einem Outcome orientieren sollten, also an dem fachlichen Sprint-Ziel, dessen Umsetzungsaufwand eine gewisse Variabilität haben sollte, um auf ungeplante Entwicklungen reagieren zu können. Wenn aber (warum auch immer) eher Outcome-orientiert gearbeitet wird, kann ein auf der Velocity beruhendes WIP Limit eine gute Idee sein.

Donnerstag, 9. November 2023

The Agile Bookshelf: Work, Sleep, Repeat

Bild: Pexels / Yan Krukau - Lizenz

Seit einigen Jahren werde ich regelmässig auf mein Buch angesprochen und darauf, dass ich es erstaunlich selten erwähne. Der Grund dafür ist einfach - es ist gar nicht von mir. Wie es der Zufall will gibt es einen zweiten Felix Stein, der eine Zeit lang als Unternehmensberater gearbeitet und ein Buch darüber geschrieben hat. Um zumindest zu wissen worum es geht, habe ich es gekauft und muss sagen, es gefällt mir wirklich gut.


Der Name des Buches ist Work, Sleep, Repeat: The Abstract Labour of German Management Consultants, und anders als man angesichts der Einleitung denken könnte ist es weniger ein subjektiver Erfahrungsbericht und mehr eine wissenschaftliche Arbeit geworden, die man in die Disziplinen der Antropologie, Soziologie oder Sozialpsychologie einordnen könnte. Neben eigenen Erfahrungen basiert es auch auf empirischen Erhebungen unter deutschen Management-Beratern.


Inhaltlich beginnt es mit einem kurzen geschichtlichen Überblick über die Entstehung des Berufs des Unternehmensberaters, der aber nicht bloss Daten und Ereignisse aufzählt, sondern bereits Zusammenhänge herstellt, etwa den, dass im frühen 20. Jahrundert die Entkoppelung leitender und ausführender Arbeiten dafür gesorgt hat, dass nicht nur das Management als Berufsgruppe entstanden ist, sondern durch seine Entfremdung von der Ausführungsebene mit ihm der Beratungsbedarf.


Aufbauend darauf konzentriert es sich auf die bereits im Titel prominent genannte "abstrakte Arbeit", die den wesentlichen Teil von Management-Beratung ausmacht. Herausgearbeitet wird, dass es sich bei den "Liefergegenständen" um Dinge wie Organisiertheit, Legitimität und Wissen handelt, deren Wert zwar unbestreitbar ist, die aber schwer zu fassen und zu beschreiben sind, so dass Gegenstand, Ausmass und Wert der damit verbundenen Tätigkeiten von Aussen mitunter schwer nachvollziehbar sind.


In einem parallelen "Erzählstrang" ziehen sich Beobachtungen der Auswirkung dieser Art der Arbeit und des Arbeitens auf die jeweiligen Berater durch das Buch. Effekte wie Gruppen-Identität, -Konformität und -Abgrenzung gehören dazu, aber auch negative Folgen wie Entfremdung von der Arbeit und anderen Menschen, Stress, Krankheiten und Verlust des Privatlebens. Ein ganzes Kapitel widmet sich dann der naheliegenden Frage, warum so viele Menschen trotzdem diesen Beruf ergreifen.


Als jemand der selbst bereits als Management-Berater tätig war, kann ich das was der andere Felix Stein in seinem Buch schreibt verstehen und bestätigen. In vielen der Beispiele und Zitate erkenne ich eigene Erlebnisse wieder. Als Geisteswissenschaftler kann ich ausserdem nur anerkennen, dass er ein Kunststück auf der Meta-Ebene vollbringt: abstrakte Arbeit wird hier aus einer nochmals höheren Abstraktionsebene betrachtet, beschrieben und eingeordnet.


Auch allen die keinen derartigen Hintergrund haben kann ich Work, Sleep, Repeat empfehlen. Wie in ihm beschrieben wird, kann die Arbeit von Management-Beratern massive Auswirkungen auf alle Menschen in einer Organisation haben, ist für die meisten aber unsichtbar oder unverständlich. Vor allem wenn man in grösseren Organisationen arbeitet (wo es nur eine Frage der Zeit ist, bis externe Berater auftauchen), kann es ein wesentlicher Beitrag zu einem verbesserten Systemverständnis sein.

Montag, 6. November 2023

Ein Bild sagt mehr als 1000 Worte (XXXVIII)

Quelle: Twitter

Agile in a Nutshell, von Alistair Cockburn, einem der Unterzeichner des Manifest für agile Softwareentwicklung.

Freitag, 3. November 2023

The Paradox of Stasis

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.


Die zweite grundlegende Bedingung dürfte darin bestehen, dass die "Grundform" eine gewisse Flexibilität hat, die wechselnde Ausgestaltungen ermöglicht. So wie Anolis-Echsen auch bei stark unterschiedlichen Bein-Längen noch der selben Gattung zugerechnet werden, gelten Löschzüge und Löschgruppen auch dann noch als solche, wenn ihre Kommunikationswege und -techniken sich ständig ändern (z.B. von Glocken über Signalhörner, Lautsprecher und Telefone hin zu Funkgeräten).


Aus unternehmerischer Sicht ist es hochgradig attraktiv, eine Organisation zu sein, in der das Paradox of Stasis ausgeprägt ist, nicht nur wegen der kurzfristigen Anpassungsfähigkeit, sondern auch weil sinnvolle Kontinuitäten einfacher gewahrt werden können und die grossen und teuren regelmässigen Reorganisationen unnötig werden. Ein rudimentär stabiles Geschäftsfeld zu finden, dürfte dabei die einfachere Herausforderung sein, mit der Flexibilität der Ausgestaltung dürften sich viele schwerer tun.


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.