Völlig unrepresentative Gespräche bei unterschiedlichen Getränken haben ergeben, dass unabhängig vom Getränk die Einschätzung vorherrscht, dass es in vielen Unternehmen viele Abhängigkeiten gäbe.
Was dran ist und was gegen diesen Zustand getan werden kann, beleuchtet dieser Artikel. Er ist quasi eine Suchtberatung für die Organisation. Wider die Abhängigkeit!
Jetzt mal langsam! Was ist das überhaupt, dieses Abhängigkeit?
Vielleicht reicht das Bild doch nicht zur Erklärung. Gibt’s halt mehr Text und weniger Bild zur Erklärung. Eine Abhängigkeit ist eine kausale Referenzialität zweier oder mehrerer Entitäten. Das bedeutet, dass für eine Abhängigkeit mindestens zwei Dings miteinander verbunden sind. Zwei Dings können dabei alles mögliche sein, von Mensch und Alkohol über Mond und Tide hin zu Arbeitspaket A und Arbeitspaket B. Die kausale Referenzialität besagt, dass mindestens in eine Richtung eine notwendige Verbindung zwischen den Entitäten besteht, möglicherweise auch in beide. Sprich: Tritt A ein, folgt B. Möglicherweise folgt vice versa A auch, falls B zuerst eintritt.
Spezifischer für Abhängigkeiten im Kontext von Arbeit gibt es eine minimalistische Definition:
Furthermore, we define dependency as a situation that occurs when the progress of one action relies upon the timely output of a previous action or the presence of a specific thing.
Strode & Huff: A Taxonomy of Dependencies in Agile Software Development
Die Abhängigkeiten können unterschiedliche Ausprägungen haben. Das folgende Bild zeigt mögliche Kategorien, es können auch mehrere dieser Abhängigkeiten vermischt sein.
So weit, so theoretisch.
Abhängigkeit in der Praxis
In der Entwicklung und Service können Abhängigkeiten fast immer auf einen einzelnen Faktor reduziert werden: Wissen.
Die Herausforderung wächst, je wissenintensiver die Entwicklung wird. In diesem Artikel habe ich die zunehmende Wissensintensität in der Wertschöpfung hergeleitet.
Ich habe ein paar Mal “fast” geschrieben, daher ein Blick auf die Ausnahmen: In der Produktion und Logistik gibt es physische Abhängigkeiten, eine Palette kann ich nicht versenden, wenn die Güter nicht vorher gepackt wurden. Ebenso gibt es in der Produktion schlichtweg physische Abhängigkeiten; eine Karosserie kann erst verzinkt werden, wenn sie geschweisst/geklebt wurde.
In der Entwicklung sind es weitaus weniger Fälle, in denen diese physischen Abhängigkeiten nicht prozessual zu lösen wären.
Beispiele: Für die Entwicklung eines Roboterarmes wurde ein 3D-Drucker für Metalle, insbesondere für das Drucken von Titanlegierungen benötigt. Diese Ressource war im Unternehmen über die meiste Zeit belegt und daher eine zeitliche Abhängigkeit.
In einem anderen Fall habe ich die Schmierstoffentwicklung begleitet (spannend: Hydrocarbon mit Graphen) und die Nutzung des Testlabors war nur eingeschränkt möglich.
Im Unterschied zu diesen physischen Abhängigkeiten, können die Abhängigkeiten in wissensintensiven Umfeldern können meist leichter vermieden und gelöst werden!
Vier Möglichkeiten mit Abhängigkeiten umzugehen
- Ignorieren. Davon geht die Abhängigkeit zwar noch nicht weg, aber sie beansprucht zumindest eine zeitlang keine Energie.
- Koordinieren. Indem Abhängigkeiten als solche erkannt werden, können Handlungen daran angepasst werden.
- Vermeiden. Durch bessere Organisation und Technologie können Abhängigkeiten ex ante vermieden werden.
- Lösen. Wenn die kausale Referenzialität aufgehoben wird, kann jede Entität für sich existieren.
Ich hoffe, es ist nur meine Erfahrung aber in der Organisation von Arbeit begegnen mir die Optionen eins und zwei leider am häufigsten. Warum leider? Das ist schnell erklärt. Koordinieren erzeugt Aufwand, der nicht direkt zur Wertschöpfung beiträgt. Und damit ist es streng genommen Verschwendung. Glaubst Du nicht?
Alternative 1: Du kannst regelmässig ein grosses Koordinationsevent durchführen. Auf diesem hast Du zwei bis drei Tage Zeit alle Abhängigkeiten in Deiner Softwarearchitektur und das Releasemanagement abzustimmen.
Alternative 2: Durch die technologischen und organisatorischen Fähigkeiten ermöglichst Du eine Vielzahl von ausgerichteten und zugleich unabhängigen Aktionen zugleich; die Softwarearchitektur erlaubt kontinuierliche Deploys.
Welches Szenario wählst Du?
Klar, in der Praxis ist die zweite Alternative wünschenswert aber wegen der technischen und organisationalen Legacy Alternative eins noch notwendig. Mein Punkt ist: Das aufrecht Erhalten von Alternative eins kostet über die Zeit vermutlich mehr als Alternative zwei. Sicher kostet es Nerven, und manchmal sogar die Chance eine neue Entwicklung überhaupt anzugehen. Es ist die wiederkehrende Abwägung, wie viel muss ich in die Lieferfähigkeit investieren, damit ich angemessen liefern kann?
Ignorieren ist interessanterweise nicht unbedingt die schlechteste Option. Wenn ich eine Abhängigkeit ignoriere und dennoch für alle abhängigen Entitäten das individuelle Ziel erreiche, dann war die Abhängigkeit doch keine, nicht so wichtig oder irgendjemand ist ein Meister der Improvisation. Sollte Ignorieren doch nicht helfen, kann immer noch koordiniert werden. Eine Dunkelziffer für nicht erkannte und deshalb ignorierte Abhängigkeiten wäre mal spannend!
Daraus ist ein weiterer Nachteil ersichtlich: Abhängigkeiten, die nicht ignoriert werden können, verursachen Verzögerungen. Die durch sie bedingte Wartezeit ist meist grösser als die Zeit, die zum Koordinieren notwendig ist.
Abhängigkeiten Lösen ist silber, Vermeiden ist gold
Nachdem wir uns angesehen haben, wie mit Abhängigkeiten umgegangen werden kann, fokussiere ich den übrigen Artikel auf das Vermeiden und auf Lösen von Abhängigkeiten.
Starten wir mit einem einfachen Bild. Es gibt drei Features (A, B, C), je Zeile wird eine mögliche Reihenfolge der Fertigstellung dargestellt. Fügen wir eine Abhängigkeit ein: A muss vor B fertiggestellt werden. Mit (A vor B) sind die Abfolgen in den Zeilen 3, 4, 6 nicht mehr möglich.
Die eine Abhängigkeit (A vor B) halbiert die Zahl der Möglichkeiten!
Ich verzichte auf die Formel der Berechnung, die mathematische Ableitung für drei Entitäten ergibt:
| Anzahl Abhängigkeiten | Optionen in der Abfolge |
| 0 | 100% |
| 1 | 50% |
| 2 | 16.667% |
| 3 | 4.167% |
| 4 | 0.833% |
| 5 | 0.278% |
Krass, oder? Hat auch einen positiven Aspekt: Allein das Reduzieren von fünf auf vier Abhängigkeiten erhöht den Freiheitsgrad um etwa einen Faktor drei!
Schauen wir uns das nochmal in einem realistischen Set an, einem Backlog von acht Items. Das ist eine Anzahl von Stories in einem Sprint Backlog, die für ein Team durchaus im Bereich des Üblichen ist.
Bei zehn Abhängigkeiten über alle acht Backlog-Items (Datenpunkt ganz rechts) gibt es fast keinen Freiheitsgrad in der Umsetzung mehr!
Wie sieht das Ganze aus, wenn mehrere Teams zusammenarbeiten? Schauen wir uns das Bild dazu an:
Hier habe alle vier Teams Abhängigkeiten. Von allen Abfolgemöglichkeiten ist nur die eine, erste Zeile möglich. Es bleibt also genau eine von 16 Möglichkeiten. Die Wahrscheinlichkeit einer reibungslosen Auslieferung sinkt auf 6.25% (f=1/2^4=1/16)
Falls es möglich wäre, ein Team aus dieser Abhängigkeit heraus zu nehmen, sähe das Bild gleich doppelt so gut aus:
Genau eine aus acht Möglichkeiten bietet eine reibungslose Auslieferung, die Wahrscheinlichkeit liegt bei 12.5%. Merke: Eines von vier Teams, das nicht von den anderen abhängig ist, verdoppelt die Wahrscheinlichkeit der anderen drei reibungslos liefern zu können! Plus, das unabhängige Team selbst hat 100% der Optionen!
Warum SOLID nach wie vor solide ist
Jetzt ist also klar, Abhängigkeiten sollten möglichst früh vermieden werden. Lösen, ignorieren, koordinieren, das kommt danach.
SOLID ist ein Akronym, das sich der Mnemotechnik bedient; es bildet die Anfangsworte der folgenden fünf Prinzipien für objektorientierte Programmierung ab. SOLID lässt sich auch dazu nutzen, die grundlegenden Tricks zur Vermeidung von Abhängigkeiten zu verstehen. Als Container für Arbeit wähle ich eine Story, letztlich ist dies nur ein Begriff, der ein Paket von Handlungen beschreiben soll.
- Single Responsibility Principle: Gestalte die Story so, dass eine Änderung der Story keine weiteren Stories beeinflusst. Wenn also in einer Story Anpassungen notwendig werden, sollten nicht andere Stories davon betroffen sein.
- Open Closed Principle: Deine Entwicklung sollte offen für Erweiterungen aber geschlossen gegen Modifikationen sein. Im Grunde ist das die Idee des Inkrements. Auf der Story kann aufgebaut werden, ohne dass die Story dazu geändert werden müsste.
- Liskov Substitution Principle: Verweist eine Story auf eine früher fertig gestellte, dann ist für das Funktionieren nicht bestimmend, ob die ursprüngliche Story wieder auf andere verweist. Das bedeutet insbesondere: Wenn eine frühere Story ersetzt wird, muss die nachfolgende Story als Substitut funktionieren. Dieses Prinzip baut auf den ersten beiden auf.
- Interface Segregation Principle: Schneide Stories so, dass sie möglichst spezifisch sind. Generische Stories würden stets mehr Verweise haben, weil spezifische auf sie zugreifen. Bei zukünftigen Änderungen müssten dann immer alle generischen und die mit ihnen zusammen hängenden spezifischen Stories geändert werden. Stattdessen können entkoppelte Stories leichter an zukünftige technische Entwicklungen angepasst oder ausgetauscht werden.
- Dependency Inversion Principle: Nicht immer sind vollständig entkoppelte Stories möglich. Wenn eine Kopplung sinnvoll ist, weil mit einer Story viele Bedingungen für andere Stories erklärt werden, dann sollte aber wenigstens diese generische Story nicht von anderen abhängig sein, sondern die Details immer von dieser Abstraktion.
Das Ganze geht auf (relativ) uralte Programmierregeln zurück. Auf die Prinzipien des objektorientierten Designs, um genauer zu sein. Der gute alte Onkel Bob hat’s erfunden. Kurzer Exkurs: Onkel Bob heißt eigentlich Robert Cecil Martin und wer das agile Manifest morgens und abends liest, wird wissen, dass eben dieser Robert C. Martin auch daran beteiligt war!
Slicing ist die halbe Miete, Splitting die andere Hälfte!
Gut, und jetzt wieder in die Praxis. Alle fünf Prinzipien lassen sich in einem Bild zusammen fassen. Stories sollten so geschnitten sein, dass jede von ihnen ein vollständiges Abbild der Architektur/durch den Kundenpfad ergibt – auf dem Bild als “Vertical Slices” beschrieben.
Wie geht das? Dazu zwei Ansätze. Einen schweren und einen schwereren.
Beginnen wir mit dem schwereren Ansatz: Wenn die Architektur auf den fünf SOLID-Prinzipien aufbaut, dann sind zukünftige Entwicklungen leichter. Dazu muss allerdings oftmals eine historische Architektur angepasst werden. Dazu braucht es technologisches, technisches und prozessuales Wissen.
Der schwere Ansatz ist das Schneiden geplanter Stories, sodass sie unabhängig sind. Es gibt dieses eine Bild, was ich in jedem Training und Coaching mit Product Owners auftische. Auch nachdem ich jahrelang selbst damit Stories erstellt habe, bleibt es schwer. Zugleich ist dieses Bild immer wieder hilfreich!
Es ist ganz einfach erklärt: Beginne mit dem Schritt eins, dann zwei, dann drei. Die letzten beiden Schritte sind iterativ.
Was würde Dir noch helfen?
Der Artikel ist schon ziemlich lang und vielleicht auch intensiv. Aber das Thema ist noch nicht erschöpft. So habe ich noch gar nicht darüber geschrieben, wie Abhängigkeiten organisatorisch vermieden oder gelöst werden können. Oder darüber, wie sie koordiniert werden können.
Ich würde zum Thema einen zweiten Teil schreiben, dazu möchte ich nur wissen: Was würde Dir noch helfen?
Write a comment