Kommentierte Links (C)

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. Hier ist die mittlerweile hundertste (!!) Monatsübersicht über die erwähnenswertesten unter ihnen. Irre, was da zusammengekommen ist.

Kent Beck: “Friction” >> “Debt”

Carl von Clausewitz wäre begeistert, denn Kent Beck, einer der Erfinder von Extreme Programming, greift hier eine seiner Ideen auf. Ausgangspunkt ist die Überlegung, dass der Begriff der Technischen Schulden mittlerweile etwas in die Jahre gekommen ist, eine gewisse Unschärfe in der Bedeutung entwickelt hat und zum Teil konflikthaft aufgeladen ist. Auf der Suche nach etwas Besserem ist Beck bei der Friktion (Reibung) gelandet, jenem vor langer Zeit von Clausewitz eingeführten Begriff, dessen Aussage ist, dass viele kleinteilige Störungen grosse Vorhaben nachhaltig behindern und verzögern können. Ob dieser neue Begriff tatsächlich besser ist als der alte sei dahingestellt, zumindest kann er aber dort verwendet werden wo technische Schulden vorbelastet sind.

Christoph Roser: On the Team Structure at Toyota

Dafür, dass Toyota als Vorzeigefirma für Lean Management gilt, weiss man in Europa erstaunlich wenig darüber wie es intern strukturiert ist. Christoph Roser lüftet den Schleier an einer kleinen aber bedeutsamen Stelle und lässt uns einen Blick auf die Struktur der Teams auf der untersten Hierarchie-Ebene werfen. Die hier anzutreffenden Einheiten sind relativ klein (vier bis sechs Mitglieder) und werden von einem Vorarbeiter geleitet, der diesen Job nur in Teilzeit ausübt, in seiner restlichen Zeit aber der selben Arbeit nachgeht wie die restlichen Teammitglieder (u.a. als Springer, der dabei hilft Arbeitsspitzen abzufedern). Er hat keine (!) Weisungsbefugnis über die anderen, schreibt aber ihre jährlichen Bewertungen und pflegt die Skill-Matrix des Teams. Für die Methoden-Nerds: der Chapter Lead im Spotify Model ist erkennbar an den Toyota-Teamleiter angelehnt.

Emil: When Scrum Masters and Agile Coaches Unleash Their Team Building Madness

Ich lehne mich weit aus dem Fenster mit der folgenden Einschätzung: Emil von der Sarcastic Society ist zur Zeit der beste Satiriker der gesammten Agile Community. Seine Texte sind extrem überzeichnet, stellen aber gerade dadurch einige unter agilen Teams und Methodikern verbreitete Dysfunktionen ins Rampenlicht. In diesem Text hat er sich die verbreitete Unsitte vorgenommen, Teambuilding-Workshops derartig übermässig verspielt (und für introvertierte Personen latent übergriffig) zu machen, dass das Ergebnis für alle Beteiligten nur noch unangenehm ist. Wer schon ein bisschen in agil arbeitenden Unternehmen herumgekommen ist wird einiges wiedererkennen. Bitterböse und zutiefst witzig.

Philip Rogers: A Fresh Perspective on Forecasting in Software Development

Ob die Perspektive von Philip Rogers auf die Aufwandsschätzungen in der Software-Entwicklung frisch ist, hängt vermutlich vom Stand des eigenen Vorwissens ab, auf jeden Fall ist sie aber ausführlich. Aufbauend auf verschiedenen psychologischen Studien (die sich mit der allgemeinen Fähigkeit befassen, Prognosen abzugeben) identifiziert er drei Faktoren, die zu besseren Ergebnissen bei Aufwands- oder Zeitschätzungen führen: Training, Teamarbeit und Zusammenarbeit mit anderen Menschen, die ebenfalls gut im Aufwandsschätzen sind. Zusätzlich dazu arbeitet er die beiden schwerwiegendsten Ursachen für Fehleinschätzungen heraus, nämlich kognitive Verzerrungen und Signal-Rauschen. Vereinfacht gesagt fasst er nicht zusammen wie man besser schätzt, sondern wodurch. Ein feiner Unterschied.

Kurt Bittner, Pierre Pureur: Agility and Architecture

Ein bewusst kontrovers gehaltener Artikel, der sich unter anderem an der unter agil arbeitenden Entwicklern weit verbreiteten Ansicht abarbeitet, dass architektonische Entscheidungen zum letztmöglichen Zeitpunkt gefällt werden sollten. Ohne alle Argumente vorwegzunehmen - ganz so einfach ist es nicht, unter anderem deshalb weil niemals ganz klar ist, was der letztmögliche Zeitpunkt ist. Das an die Idee des Minimum Viable Product (MVP) angelehnte Gegenkonzept ist die Minimum Viable Architecture (MVA). Ein interessanter Ansatz.

Feature Toggles

Ein häufiges Argument gegen iterativ-incrementelle Softwareentwicklung ist, dass diese bei vielen grossen Anwendungen nicht funktionieren würde. Es gäbe zu viele verschiedene Anforderungen, die aufgrund geschäftlicher Zwänge (z.B. dem Beginn des Saison-Geschäfts oder dem Tag des Inkrafttretens eines Gesetzes) alle gleichzeitig in Betrieb genommen werden müssten und nicht nach und nach. Ein Big Bang-Release wäre daher in diesen Fällen unvermeidlich.

Auf den ersten Blick mag das wie ein valides Argument erscheinen, auf den zweiten gibt es aber trotz dieser Vorgaben eine Möglichkeit zum regelmässigen Fertigstellen, Integrieren und Testen neuer Funktionen. Sie basiert auf dem Konzept so genannter Feature Toggles (alternativ auch Feature Flags genannt), deren Funktion vereinfacht gesagt ist, bestimmte Teile einer Anwendung unsichtbar und unbenutzbar zu machen (welche das sind kann bei der Erstellung bestimmt werden).

Bedingt durch diese Technik ist es möglich, auch solche Funktionen live zu schalten, die für sich genommen oder zu diesem Zeitpunkt noch nicht live sein sollten. Ein typisches Vorgehen ist, das zu einem Zeitpunkt zu tun, an dem normalerweise keine Benutzung stattfindet (z.B. tief in der Nacht), die Akzeptanz-, Regression- und Lasttests einmal laufen zu lassen und die neuen Funktionen dann unsichtbar zu machen (man spricht dabei vom sogenannten "Austogglen").

Auch differenzierte Varianten des Austogglens sind möglich, z.B. das sichtbar-, bzw. unsichtbar machen für verschiedene Gruppen, verschiedene geografische Regionen oder verschiedene Zugangsberechtigungen. Bei Bedarf können so der Betrieb der alten Funktionen und das Testen der neuen Funktionen parallel stattfinden, und bei zeitlich versetzten Livegängen für verschiedene Märkte lässt sich das temporäre gleichzeitige Existieren verschiedener Branches vermeiden.

Selbst nach dem jeweiligen Livegang können Feature Toggles noch einen Zweck haben. Wenn einzelne Teile einer Anwendung einen wesentlichen Teil des Traffics erzeugen, kann es beispielsweise Sinn machen, sie auf diese Weise mit einer "Notfallabschaltung" zu versehen. Im Fall von Lastspitzen kann damit dann ein Crash des Gesamtsystems verhindert werden, stattdessen stehen nur einzelne Features vorrübergehend nicht zur Verfügung.

Um negative Seiten nicht zu verschweigen - sobald sie nicht mehr benutzt werden sollten Feature Toggles wieder entfernt werden, sonst blähen sie den Code unnötig auf und machen ihn schwerer verständlich (und ganz abgesehen davon, kann es bei ihnen zu versehentlicher Aktivierung und Bedienfehlern kommen, wodurch Anwendungen unbrauchbar werden können). Das passiert aber häufig nicht, weil anderes gerade wichtiger erscheint. Fehlender Clean Code ist dann die Folge.

Trotz dieses Risikos: grundsätzlich sind Feature Toggles sehr nützliche Werkzeuge, durch die auch das iterativ-incrementelle Ausliefern grosser Anwendungen möglich wird. Und dank ihnen kann man auch wunderbare Sätze formulieren, wie diesen hier: Wenn das austogglebare Feature eingetoggelt ist, der Feature-Toggle aber ausgetoggelt, dann ist das austoggelbare eingetoggelte Feature nicht mehr austoggelbar. So sieht es nämlich aus.

Dark Constraints

Bild: Unsplask / Jan Baborák - Lizenz

Egal ob es um Produkt-, Organisations- oder Personalentwicklung geht, jedem, der eines dieser Vorhaben angeht, muss bewusst sein, dass ihnen Begrenzungen (englisch: Constraints) gegeben sind. Das können ganz schlicht Budget-Begrenzungen sein, aber auch Grenzen der zulässigen Selbstorganisation. Auch Abhängigkeiten zu anderen Teams gehören dazu, ggf. sogar solche zum Wetter oder zu Jahreszeiten (Stichwort Weihnanchtsgeschäft).

Die Gemeinsamkeit all dieser Constraints ist, dass sie bekannt und erkennbar sind, in den meisten Fällen sogar dokumentiert. Dass das nicht selbstverständlich ist, kann man am Beispiel von anderen sehen, die zwar existieren und eine Wirkung haben, aber bestenfalls einen halboffiziellen Status haben und in manchen Fällen sogar überhaupt nicht thematisiert werden, so dass es eine gewisse Zeit dauern kann bevor man bemerkt, dass sie da sind.

Ein Beispiel für diese unsichtbaren Begrenzungen ist der Grad an Perfektionismus, der in der Organisation verbreitet ist. Ist er hoch, werden viele neue Ideen und Konzepte selbst dann nicht freigegeben und noch "fertig entwickelt" werden, wenn sie schon vorher vorführbar gewesen wären. Umgekehrt kann ein niedriger Grad an Perfektionismus dazu führen, dass letzte Entwicklungsschritte fast immer ausgelassen werden, da das Ergebnis ja "gut genug für den Moment" ist.

Auch der Grad an vorhandenem Vertrauen kann eine derartige Begrenzung sein, vor allem wenn es um Veränderungsvorhaben oder Konfliktklärungen geht. Weitere Beispiele wären Risiko-Affinität oder -Aversion, das (Nicht-)Vorhandensein von Hierarchiegläubigkeit, die grundsätzliche (Nicht-)Offenheit für Neues oder das Ausmass der gewohnheitsmässigen Verknüpfung von Pausen oder Tätigkeits-Durchführungen mit bestimmten Uhrzeiten oder Wochentagen.

Dave Snowden hat für diese Art von Begrenzungen den Begriff der Dark Constraints erfunden. Gemeint ist damit nicht dark (dunkel) im Sinn von böse sondern eher im Sinn von "im Dunkeln liegend". Wenn man sie kennt und weiss wo sie sind, kann man mit ihnen umgehen, wenn nicht wird man zu Beginn nicht merken, dass sie da sind, um dann irgendwann in einem ungünstigen Moment über sie zu stolpern, im Zweifel gerade dann, wenn man es am wenigsten gebrauchen kann.

Bei einer Bestandsaufnahme am Anfang eines Produkt-, Organisations- oder Personalentwicklungs-Vorhabens sollte die Suche nach Dark Constraints daher ein wesentlicher Punkt sein. Das ist nicht immer einfach (selbst den von ihnen Betroffenen ist die Existenz dieser Beschränkungen nicht immer bewusst), macht aber vieles, was später kommt, einfacher und nachvollziehbarer. Es ist also gut investierte Zeit.

Abhängigkeiten

Grafik: Pixabay / user1518572209 - Lizenz

Eines der stärksten und gleichzeitig am häufigsten unterschätzten Hindernisse für agiles Projekt- oder Produktmanagement sind Abhängigkeiten zwischen Organisationseinheiten. Während für ein Arbeitspaket auf externe Zulieferungen gewartet wird, kann nicht weitergearbeitet werden, der Fortschritt steht still und mit ihm auch die Liefer- und Reaktionsfähigkeit. Aber sind Abhängigkeiten ein einheitliches Problem, sind sie alle gleich? Natürlich nicht, es gibt Unterschiede.

Der Abhängigkeits-Typ von dem wir meistens sprechen wenn wir das Wort Abhängigkeit benutzen ist die asynchrone Abhängigkeit. Diese ist dann gegeben wenn die Zulieferung durch ein anderes Team, die eigene Arbeit und die nachgelagerte Arbeit eines wiederum anderen Teams sequentiell angeordnet sind. Erst wenn die Zulieferung erfolgt ist kann die eigene Arbeit beginnen, erst wenn diese abgeschlossen ist kann die Übergabe zum nachgelagerten Team erfolgen.

Wesentlich seltener denken wir bei Abhängigkeiten an den zweiten Typ, die synchronen Abhängigkeiten. Diese erfordern eine zeitgleiche Erledigung der eigenen Arbeit und der Arbeit der jeweils anderen Teams, z.B. dann, wenn in einem Markt der Euro eingeführt wird und alle Systeme gleichzeitig umgestellt werden müssen. Ggf. können die Arbeiten auch versetzt begonnen werden, abgeschlossen werden müssen sie aber möglichst gleichzeitig.

Wenn wir diese beiden Typen betrachten,¹ lässt sich erahnen, welcher der beiden im Kontext angestrebter Agilität das grössere Problem ist: es sind die asynchronen Abhängigkeiten. Wenn asynchron voneinander abhängige Teams für ihre Arbeitspakete die Statustypen Waiting und Blocked erfassen und aktuell halten, machen diese meistens bei den Durchlaufzeiten einen so grossen Anteil aus, dass man die Prozesseffektivität auf niedrigste Werte sinken sieht.

Als weitere Folge kommt dazu, dass die Erstellung von Produkt-Incrementen in überschaubaren Zeiträumen schwierig bis unmöglich wird. Durch die sequentielle Anordnung, die notwendigen Übergaben und die Tatsache, dass beim Eintreffen von Zulieferungen in der Regel noch eigene Tätigkeiten unvollendet sind und abgeschlossen werden müssen, kann sich die Erstellung nutzbarer Funktionalität (und deren Validiereung) in erstaunliche Längen ziehen.

Wenn es sich nicht vermeiden lässt, Abhängigkeiten zu haben, sind synchrone Abhängigkeiten deutlich besser. Bei ihnen ist Arbeit parallelisierbar, was bedeutet, dass sie gleichzeitig ausgeführt werden können und die Teams nicht aufeinander warten müssen. Die Waiting- und Blocked-Zeiten gehen so zurück, die Auslieferung beschleunigt sich und mit ihr die Reaktionsfähigkeit. Es ist aber wichtig zu verstehen, dass es auch bei den synchronen Abhängigkeiten nochmal zwei Untertypen gibt.

Technische synchrone Abhängigkeiten bedeuten, dass die Teams zwar parallelisiert arbeiten können, dass ihre Ergebnisse ohne die Kombination mit denen jeweils anderen aber noch keinen nutzbaren Mehrwert ergeben. Der vermutlich häufigste derartige Fall sind separate Komponenten-Teams für Frontend und Backend. Das ist besser als eine komplett sequentielle Anordnung, erfordert aber immer noch hohen Abstimmungsaufwand und gemeinsame Release-Termine.

Business-basierte synchrone Abhängigkeiten sind technisch unabhängig voneinander und eher fachlich oder kommerziell miteinander verbunden. Um beim oben genannten Beispiel der Euro-Einführung zu bleiben: dass sowohl der Webshop als auch das Redaktionssystem der Werbeprospekte auf die neue Währung umgestellt werden müssen wäre eine derartige fachliche Abhängigkeit, eine mit der Umstellung verbundene Werbekampagne auf allen Kanälen wäre eine kommerzielle.

Gerade vor dem Hintergrund, dass es möglich ist, technisch vollständige Features integriert und getestet auf Produktion zu bringen und dort durch ein Feature Toggle bis zu einem Stichtag unsichtbar zu machen, wird klar, wie weit die Konzentration auf business-basierte synchrone Abhängigkeiten dazu beitragen kann, Teams unabhängig voneinander zu machen. Stillstand durch gegenseitiges aufeinander Warten lässt sich so weitgehend verhindern.

¹Es gibt natürlich noch weitere Abhängigkeiten, z.B. finanzielle oder emotionale, die sind im Kontext von Projekt- oder Produktmanagement aber nicht von Bedeutung

Ein Bild sagt mehr als 1000 Worte (XXXVI)

Grafik: Vincent Deniel - CC BY NC 4.0

Vielleicht die prägnanteste Art den Grund dafür zu visualisieren, dass irgendwer irgendwann mal DevOps erfunden hat. Passiert wie hier zu sehen leider immer noch viel zu häufig.

Und ganz nebenbei: der Künstler hinter dieser Zeichnung feiert gerade das dreijährige Jubiläum seines Schaffens. Seinem Drawing-Blog zu folgen ist sehr zu empfehlen.

Small rule tweaks can have unintended consequences

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.

Lean-Metriken (II)

Bild: Pixabay / Prawny - Lizenz

Zweiter Teil der Übersicht über die Lean-Metriken (Teil 1 ist hier). Auch mit dieser Erweiterung ist die Aufzählung sicher noch nicht vollständig, irgendwann kommt mindestens noch ein dritter Teil (Nachtrag: hier ist er). Zunächst aber soll es hier um die Fluss-Effektivität gehen, also um Metriken, mit deren Hilfe sich erkennen lässt, ob überhaupt die richtigen Tätigkeiten stattfinden oder ob gerade unnötig Geld und Zeit verbraucht werden. Wichtig ist dabei, dass sie im Zusammenhang mit den Durchlaufmetriken des ersten Teils gesehen werden können, und zwar sowohl für die Lead Time/Gesamtdurchlaufzeit als auch für ihre einzelnen Teilstrecken (dazu am Ende mehr).

Value Adding Time

Der Idealfall. In etwa als "Wertschöpfungszeit" übersetzbar sollte die Value Adding Time eigentlich den grössten Teil der Durchlaufzeiten ausmachen. Was dort geschieht kann je nach Art des Produkts oder der Dienstleitung sehr unterschiedlich sein, im Normalfall sind aber Tätigkeiten enthalten, die zur Erstellung, Vermarktung und Inbetriebnahme von Produkt oder Dienstleitung gehören, ggf. einschliesslich von Vorarbeiten wie dem Einkauf oder nachgelagerter Tätigkeiten wie dem Kundenservice. Die Wichtigkeit ergibt sich daraus, dass es im Wesentlichen diese Tätigkeiten sind, für die Kunden Geld bezahlen.

Transportation Time

Der erste zu vermeidende Typ und gleichzeitig ein alter Bekannter. Transporte sind eine der klassischen Mudas des Toyota Production System (TPS), also eine nicht gewinnbringende aber Ressourcen verbrauchende Tätigkeit. Je nachdem, in welchem Rahmen sie gemessen wird, kann auch die Transportation Time sehr unterschiedlich aussehen, angefangen vom Werkstoff-Transport zum anderen Ende der Firma bis zum Containerschiff, dass das Produkt rund um die Erde fahren muss. Eine weitere Variante wäre das langsame Herunterladen eines digitalen Produkts durch eine schlechte Telefonleitung.

Waiting Time

Ebenfalls eine Muda, und dazu die vielleicht die am weitesten verbreitete. Überall dort, wo die Menschen oder Maschinen mehr Arbeit zu erledigen haben als sie bewältigen können, werden sich Aufgaben aufstauen und auf ihre Erledigung warten, was in grossen Organisationen auch Monate und sogar Jahre dauern kann. Als Zusatzeffekt erzeugen Wartezeiten, sobald sie auftreten, noch weitere Aufwände, da die wartenden Aufgaben aktuell gehalten und ggf. verworfen, neu formuliert, neu verhandelt oder repriorisiert werden müssen.

Blocked-Time

Die Blocked Time wird häufig mit der Waiting Time verwechselt, hat aber eine andere Natur. Wartende Aufgaben könnte man selbst erledigen, wenn man denn die Zeit hätte. Geblockte Aufgaben müssen durch jemanden anderen erledigt werden, der dafür zuerst seine gegenwärtige Tätigkeit abschliessen und sich die Aufgabe erklären lassen muss (ggf. kommen noch Preisverhandlungen und Beauftragungen dazu). Besser wäre es, diese Tätigkeiten selbst erledigen zu können, wodurch die Blocked Time verschwinden würde.

Repair Time

Noch eine Muda. Wenn man Repair Time nicht als den Reparaturaufwand nach einem Unfall versteht, sondern als die Zeit die für die Behebung von Hardware-Produktionsfehlern und Software-Bugs nötig ist, ist klar, dass sie so gering wie möglich sein sollte. Auch hier kann es zu negativen Zusatzeffekten kommen, da auch Reklamationen und Umtausche Aufwände erzeugen und die mit den Reparaturen betrauten Menschen dadurch aus ihren aktuellen Tätigkeiten herausgerissen werden, mit Verlangsamungen durch Context Switching und Rüstzeiten als Folge.

Red Tape Time

Hinter der Red Tape Time verbirgt sich die letzte Muda dieser Übersicht, das Overprocessing. Red Tape ist im Englischen ein Sammelbegriff für unnötig komplizierte Prozesse und unnötig bürokratische Vorschriften, und wer bereits in grossen Organisationen gearbeitet hat wird wissen, dass sie dort weit verbreitet sind (hier ein besonders verstörendes Beispiel aus einer deutschen Behörde). Und dass derartige Tätigkeiten nichts zur Wertschöpfung beitragen dürfte ebenfalls offensichtlich sein.

Process Effectivity

Setzt man jetzt die Value Adding Time und die ressourcenverbrauchenden aber nicht wertschöpfenden Varianten Transportation Time, Waiting Time, Blocked Time, Repair Time und Red Tape Time in Verhältnis zueinander, erhält man die Prozess-Effektivität. Wenn die gesamte Durchlaufzeit nur aus Value Adding Time besteht ist das Ergebnis ideal, wenn die Zeit überwiegend für die anderen Typen verbraucht wird ist es eher schlecht. In diesen Fällen macht es sinn, den Prozess so zu verändern, dass diese Aufwände zurückgehen.

Von der Prozess-Effektivität zu unterscheiden ist übrigens die Prozess-Effizienz. Dazu ein anderes mal mehr (Nachtrag: und zwar hier, im dritten Teil der Lean-Metriken).

Chaos Engineering (III)

Bild: Pixabay / GlauchauCity - Lizenz

Dem regelmässigen Leser dieser Seite dürfte es aufgefallen sein, dass ich ein Fan von Chaos Engineering bin. Als technische Praktik kann es entscheidend dafür sorgen, dass die in den methodischen Frameworks vorgesehehene kontinuierliche Liefer- und Reaktionsfähigkeit tatsächlich auch stattfinden kann. Darüber hinaus lässt sich Chaos Engineering aber auch von der Technik lösen und selbst als methodischer Ansatz einsetzen.

Noch einmal kurz zur Erinnerung: Chaos Engineering stellt die Resilienz (und damit auch die Liefer- und Reaktionsfähigkeit) eines Systems sicher indem auf Produktion nach Zufallsprinzip wichtige Ressourcen temporär abgeschaltet werden (Server, Übertragungskapazitäten, etc.). Übersteht das System diesen Stresstest ist alles gut, übersteht es ihn nicht, wird klar, an welcher Stelle an Kompensations-Automatismen gearbeitet werden muss.

Auf dieser Abstraktionsebene beschrieben lässt sich die Idee problemlos auf soziele Systeme übertragen, also auf Teams, Abteilungen oder Projekte. Auch hier lassen sich einzelne Ressourcen (→ Personen) temporär aus den Arbeitsabläufen herausnehmen, um festzustellen ob die anderen diesen Ausfall kompensieren können. Ist das nicht der Fall, ist ein Problem identifiziert, das beim nächsten Urlaub oder Krankheitsfall für Störungen oder Stillstand sorgen würde.

Die Problembehebung ist dann relativ einfach, denn in fast allen Fällen liegt einer von zwei Root Causes vor: entweder fehlen den anderen Mitarbeitern die Kenntnisse, um die Tätigkeiten des ausfallenden Kollegen zu übernehmen. Das kann kompensiert werden, indem sie sich in Richtung T-Shape oder Full Stack entwickeln. Oder ihnen fehlen Zugriffsberechtigungen auf die vom ausfallenden Kollegen verantworteten Systeme, was sich lösen lässt, in dem diese erteilt werden.

Ein zum Glück seltener werdender dritter Root Cause liegt vor, wenn der ausfallende Kollege Code Ownership in Teilen der Anwendung hat, also vereinbart wurde, dass er als Einziger dort Änderungen vornehmen darf. Eine andere Variante dieses Problems ist es, wenn nur eine Person für bestimmte Bereiche Pull Requests annehmen, also Änderungen genehmigen darf. Die Lösung ist in beiden Fällen einfach - man muss nur diese limitierenden Regeln abschaffen.

Die Ergebnisse von "sozialem Chaos Engineering" sind häufig überraschend, da Wissensmonopole, Berechtigungs-Engpässe und Code Ownership nicht immer explizit gemacht werden. Oft sind sie eher unbemerkt entstanden und werden selbst von den Beteiligten in ihrer Tragweite unterschätzt. Um so wichtiger ist es herauszufinden, ob sie vorliegen. Und einen netten Nebeneffekt gibt es auch noch: die temporär abwesenden Kollegen haben Zeit für Weiterbildung oder Überstunden-Abbau.

Politik im Konzern

Bilder: Wikimedia Commons / Luke Fildes (1, 2) - Public Domain

Wenn in grossen Unternehmen Entscheidungen getroffen werden, bei denen es weniger um die Sache und mehr um die Wahrung von Partikular-Interessen geht, spricht man von politischem Verhalten. Worauf sie beruhen bleibt dabei aber meistens unklar. Verständnis für diese Motivationen schaffen kann passenderweise die Politikwissenschaft, und hier ein eher unerwarteter Zweig: das Teilgebiet der Internationalen Beziehungen.

Nicht ohne Grund werden die Abteilungen, Bereiche und Ressorts eines Konzerns immer wieder als "kleine Königreiche" bezeichnet. Nach innen sind sie hierarchisch gegliedert, nach aussen konkurieren sie um Ressourcen, gehen Bündnisse ein oder tragen Konflikte aus. Die Parallelen zu Staaten sind offensichtlich. Und da das Fach der Internationalen Beziehungen verschiedene Deutungsmodelle für Handlungs-Motivationen entwickelt hat liegt es nahe sie zu übertragen. Hier sind die Wichtigsten:

Idealismus

Wie es der Name sagt - der Idealfall. Der Idealismus geht davon aus, dass alle Beteiligten vernunftbegabt sind und rational handeln, was im Ergebnis dazu führt, dass alle kooperieren und an einem gemeinsamen grösseren Ziel arbeiten. Der Idealismus basiert auf einem positiven Menschenbild, kann aber bei häufiger Enttäuschung durch das nächste Deutungsmodell ersetzt werden.

Realismus

Der Realismus sieht in der Politik vor allem einen Kampf um Macht, was fast zwangsläufig in Konflikten enden muss, schliesslich kann nicht jeder gleichzeitig der Mächtigste sein. Sowohl in der internationalen Politik als auch in Konzernen scheinbar häufig anzutreffen, allerdings mit Vorsicht zu behandeln. Nicht nur der Realismus sondern auch seine Unterstellung basieren auf problematischen Menschenbildern.

Neo-Realismus

Naheliegenderweise eine Weiterentwicklung des Realismus. Als zentrales Handlungsmotiv wird nicht mehr Machtstreben unterstellt sondern ein Sicherheitsbedürfnis, das (basierend auf einem eher negativen Menschenbild) dazu führt, dass man einen zu grossen Machtzuwachs anderer verhindern will und in alle relevanten Entscheidungen einbezogen werden möchte. Kann in die Thukydides-Falle führen.

Institutionalismus

Der Institutionalismus baut auf den vorherigen Ansätzen auf und entwickelt sie weiter. Er geht davon aus, dass Zusammenarbeitsstrukturen (egal ob sie auf Rationalität, Machtstreben oder Sicherheitsbedürfnis beruhen) Eigendynamiken und Selbsterhaltungs-Bestrebungen entwickeln und sich so immer mehr verfestigen. Eine häufige (positive und negative) Folge ist die Herausbildung von Bürokratie.

Funktionalismus

Nochmal eine Weiterentwicklung. Im Funktionalismus wird davon ausgegangen, dass es die Funktion von Kooperation ist, noch mehr Kooperation zu erzeugen. Dort wo bereits zusammengearbeitet wird kommt es daher mit hoher Wahrscheinlichkeit dazu, dass das in Nachbar-Bereiche überschwappt (Spill Over-Effect). Das ist grundsätzlich positiv, kann aber auch in die Verflechtungsfalle führen.

Konstruktivismus

Abweichend von den anderen Ansätzen sieht der Konstruktivismus nicht (zweck)rationales Handeln als politisches Hauptmotiv, sondern die Ideen und Glaubenssätze mit denen die Beteiligten ihre Realitäts-Wahrnehmung konstruieren. In der Politik sind das z.B. Demokratie und Kommunismus, in Konzernen können es u.A. der Glaube an Mitbestimmung oder an geniale Anführer (Jobs, Musk, etc.) sein.

Natürlich gibt es noch zahlreiche weitere Theorien der Internationalen Beziehungen, die meisten sind aber nur Vorstufen oder Ableitungen der hier dargestellten (oder gelten als überholt, wie z.B. der zum Kommunismus gehörende historische Materialismus von Karl Marx), weshalb die hier genannten einen recht vollständigen Überblick über die zentralen Ideen bieten.

Wie bei allen abstrakten Denk- und Deutungsmodellen können auch die aus der internationalen Politik nicht alles erklären, sie bieten aber bewährte Erklärungsmuster mit deren Hilfe die Analyse komplexer (Konzern-)politischer Strukturen leichter fallen kann. Und in jedem Fall sind sie differenzierter (und damit brauchbarer) als die Zuweisung (un)moralischer Motive, mit denen sonst häufig versucht wird politische Hundlungen zu erklären.