On Lean and Agility

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.

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.

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.

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.

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.

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.

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.

Bild: Unsplash / Fabio Bracht - Lizenz

Nathan Furr, Kate O’Keeffe : The Hybrid Start-Up

Lucas Fernandes da Costa: How processes are born, why they can be damaging, and how to fix them

Johanna Rothman: How to Measure All Your Work in Progress to Make Better Decisions

Dan North: But what about the BAU work?

Willem-Jan Ageling: SAFe Scrum — Is it actually Scrum?