Systems Thinking mit Causal-Loop-Diagrammen

Systems Thinking in lernenden Organisationen

Systems Thinking wird als eine der wichtigsten Charakteristika lernender Organisationen aufgefasst. Peter Senge beschreibt die Fähigkeit, systematisch oder in Systemen zu denken, in seinem Buch „The Fifth Discipline“ (englisches Original, deutsche Übersetzung) als überlebenswichtig für eine lernende Organisation. Diese Fähigkeit hilft, bestehende Probleme ganzheitlich zu betrachten und sämtliche Aspekte der Organisation zu betrachten, auch wenn diese auf den ersten Blick keinerlei Zusammenhang mit dem eigentlichen Problem zu haben scheinen. Neben Systems Thinking als fünfter Disziplin beschreibt Senge vier weitere Disziplinen, auf die es in einer lernenden Organisation ankommt:

1. Personal Mastery. Menschen sind dann motiviert, wenn sie durch ihre Arbeit zu fachlichem und persönlichem Wachstum herausgefordert werden. Hier findet sich zum Einen der Mastery-Aspekt wieder, den Daniel Pink in seinem Buch „Drive“ (englisches Original, deutsche Übersetzung) beschreibt. Zum Anderen entspricht es dem Flow-Konzept von Mihaly Czikszentmihaly (englisches Original). Bei der Anwendung von Systems Thinking hilft Personal Mastery, die eigene Expertise und das eigene Arbeitsumfeld zu verstehen und zu meistern.
2. Mental Models. Wir alle haben unsere blinden Flecken durch einschränkende Glaubenssätze, derer wir uns meist gar nicht gewahr sind. Eine Kultur der Offenheit und des kritischen Hinterfragens soll gelebt werden und sichtbar sein. Niemand soll sich davor fürchten, auf des Kaisers fehlende Kleider aufmerksam zu machen. Für Systems Thinking ist diese Offenheit notwendig, damit auch alle unbequemen Aspekte des Systems einfließen können.
3. Team Learning. Teams sind nur erfolgreich, wenn die Menschen in den Teams gelernt haben, effektiv zusammenzuarbeiten. Die eben genannte Offenheit ist hier im Miteinander notwendig. Fehlendes Vertrauen und Angst vor Verletzlichkeit müssen aus dem Weg geschafft werden. Team Learning beinhaltet sehr viele Aspekte der “Five Dysfunctions of a Team” von Patrick Lencioni (englisches Original, deutsche Übersetzung). Systems Thinking profitiert dabei von der Fähigkeit, ehrliche Einschätzungen und Blickwinkel aus dem Team zu erhalten.
4. Shared Vision. Der gemeinsame Blick aller Beteiligten auf den Sinn und Zweck der Organisation ist entscheidend für das Verständnis, aus welchem Grund an einer Sache gearbeitet wird und wofür dies alles überhaupt gut ist. Für die Identifikation einer Shared Vision sollen alle Mitarbeiter einer Organisation eingebunden werden. Für Systems Thinking ist dies wichtig, damit die Leute die sinngebende Zielsetzung für Lösungsansätze anstreben können.
5. Systems Thinking. Mit Hilfe dieser vier eben genannten Disziplinen wird nun die Anwendung von Systems Thinking erst effektiv möglich.

Nutzen von Systems Thinking

Systems Thinking ermöglicht das gemeinsame Verständnis und den gemeinsamen Blick auf den aktuellen Zustand des eigenen Systems bzw. der eigenen Organisation. Anstelle der individuellen Betrachtung lokaler Symptome durch einzelne Beteiligte fördert Systems Thinking die gemeinsame Erarbeitung eines Modells durch viele Beteiligte. Durch die Einbindung dieser Beteiligten fließen Perspektiven höherer Diversität in das Modell ein. Die Ableitung von Erkenntnissen und Maßnahmen aus diesem Modell erfolgt ebenso durch alle Beteiligten und erzeugt damit eine deutliche höhere Verbundenheit.

Systems Thinking führt vom einfachen, linearen Ansatz hin zu zirkulärem Denken und dem Erkennen von dynamischen Abhängigkeiten innerhalb des betrachteten Systems. So lassen sich Feedback-Schleifen und deren Ursachen identifizieren, welche im Fortgang mit entsprechenden Maßnahmen beseitigt werden können.

Visualisierung durch Causal-Loop-Diagramme

Die Darstellung eines Systems Thinking Modells geschieht durch Causal-Loop-Diagramme. (Diese kursieren fälschlicherweise manchmal auch unter den Namen Cause-Effect-Diagramm oder Ursache-Wirkungs-Diagramm. Dabei handelt es sich jedoch um eine andere Art von Diagramm, die wegen ihrer optischen Ähnlichkeit zu Fischgräten auch als Fischgräten-Diagramme bekannt sind.)

Die visuelle Sprache ist leicht verständlich und kann von allen Beteiligten nach kurzer Übung angewandt werden. Im abgebildeten Beispiel hat die Anzahl der Füchse einen wechselseitigen Einfluß auf die Anzahl der Gänse. Die Anzahl der Füchse wird ebenso durch die Anzahl der Jäger beeinflusst. Durch die graphische Darstellung sind diese Zusammenhänge ersichtlich. In der Kette lässt sich auch leicht erkennen, dass die Anzahl der Gänse mittelbar von der Anzahl der Jäger beeinflusst wird. So werden größere Zusammenhänge sichtbar und lassen in der weiteren Arbeit mit dem Modell weitere Erkenntnisse zu.

Definition der Problemstellung

Bevor wir mit einer Gruppe von Beteiligten ein sinnvolles Modell entwerfen können, benötigen wir das gemeinsame Verständnis der Problemstellung, der wir uns mit dem Modell widmen wollen. Ein allgemeiner Aufruf nach dem Motto „lasst uns mal ein Modell unseres Organisations-Systems erstellen“ ist zwar machbar, jedoch nicht zielführend.

• Welche Aspekte der Organisation sollen überhaupt betrachtet werden?
• Welche Betrachtungsgrenzen können wir für das Modell abstecken?
• Ab wann ergibt eine detaillierte Betrachtung weiter entfernter Aspekte keinen Sinn mehr?

Die Antworten auf diese und ähnliche Fragen müssen den Beteiligten bei der Erstellung des Modells klar sein. Ist dies nicht der Fall, dann werden wir uns relativ bald verrennen und die Arbeit am Modell aufgeben.

Wir müssen also die Frage beantworten, welches Problem mit dem zu erarbeitenden Modell betrachtet werden soll.

Beispiel: „Wir beobachten immer wieder, dass wir nach jedem Release sehr viele, kurz getaktete Hotfixes hinterherschieben müssen. Das verursacht sehr viel Stress in den Teams und wirklich zufrieden sind unsere Anwender offensichtlich auch nicht. Lasst uns mal versuchen, diese Probleme in einem Causal-Loop-Diagramm zu modellieren.“

Identifikation von System-Variablen

Die erste Frage im Modell lautet: „Welche Variablen gibt es in unserem System, die etwas mit unserem Problem zu tun haben könnten?“

Aus unserem Beispiel ergeben sich direkt schon folgende Variablen:

• Anzahl der Hotfixes pro Release
• Druck auf die IT / Stress in den Teams
• Zufriedenheit der Anwender

Eine System-Variable ist also ein ganz spezifischer Aspekt in unserem System, der unterschiedliche Ausprägungen haben kann. Die Anzahl der Hotfixes kann groß oder klein oder sogar null sein, jedoch nie negativ. Der Stress in den Teams, sowie die Zufriedenheit der Anwender können ebenso hoch, viel, groß oder niedrig, wenig, klein sein.

Bei der Identifikation von System-Variablen ist darauf zu achten, dass die verwendete Bezeichnung eindeutig und verständlich formuliert ist. Eine System-Variable „Fehlerbehebung“ ist nicht zweifelsfrei zu interpretieren. Sie könnte „Menge an Fehlerbehebung“, „Notwendigkeit zur Fehlerbehebung“, „Anzahl gemeldeter Fehler pro Woche“ und viele weitere Ausprägungen bedeuten. Ein weiteres Negativbeispiel lautet: „Ausbildung der Mitarbeiter“. Was könnte damit gemeint sein? Das bestehende Ausbildungsniveau der Mitarbeiter, die Menge an durchgeführten Ausbildungsmaßnahmen pro Monat oder vielleicht die Notwendigkeit von Ausbildungen für Mitarbeiter? Hier gilt es, wachsam zu sein und immer wieder mit den Beteiligten zu erörtern, welche Bedeutung die identifizierten System-Variablen tatsächlich haben. Bei Bedarf müssen diese dann verständlicher umformuliert werden.

Dynamik und Veränderungen von System-Variablen

Die identifizierten System-Variablen in unserem Modell unterliegen einer gewissen Dynamik und können ihre jeweilige Ausprägung im Laufe der Zeit verändern. Die Zufriedenheit der Anwender kann sich anfänglich auf höchstem Niveau befinden. Durch die Beeinflussung anderer Variablen kann sie sich jedoch auf ein geringeres Niveau absenken. Es gilt nun, diese beeinflussenden Variablen zu identifizieren und in unserem System-Modell in Relation zu den bereits identifizierten Variablen zu setzen.

Folgende Fragen helfen bei der Identifizierung:

• Welcher Zusammenhang lässt sich zwischen einzelnen System-Variablen herstellen?
• Beeinflussen sich zwei System-Variablen direkt oder sind weitere Variablen beteiligt?
• Welche weiteren Aspekte spielen eine Rolle im Umfeld einer identifizierten Variable?

In unserem Beispiel könnten wir vorschnell einen direkten Zusammenhang zwischen der Zufriedenheit der Anwender und der Anzahl der Hotfixes pro Release herstellen. Diese beiden Variablen stehen jedoch in keiner direkten Verbindung. Erst durch die Auswirkung weiterer Variablen lassen sich Rückschlüsse ziehen. Welche Einflüsse könnten für die Zufriedenheit der Anwender also eine Rolle spielen?

Wir können ein paar Variablen definieren, die zur Anwenderzufriedenheit beitragen. Wie hängen diese nun wiederum mit der Anzahl der Hotfixes pro Release zusammen? Betrachten wir der Einfachheit halber nur die neu definierte Variable „Aufwand für Updates für die Anwender“. Hier gibt es nun mindestens zwei Varianten der Beeinflussung. Der Aufwand für Updates kann für die Anwender bei jedem Hotfix sehr hoch sein, wenn dafür das System gestoppt, Workflows unterbrochen und evtl. explizit Zeit für das Update eingeplant werden muss. In extremen Fällen bedeutet das, eine Fabrik für eine ganze Woche in den Wartungsmodus zu bringen und die Produktion anzuhalten. Im einfachsten Fall hat es für einzelne Anwender zur Folge, eine Desktop-Applikation oder das Smartphone-Betriebssystem für wenige Minuten den Update-Prozess durchlaufen zu lassen. In beiden Fällen bedeutet die Durchführung eines Updates einen gewissen Aufwand für die Anwender. Je öfter dieser Aufwand entsteht, desto unzufriedener werden die Anwender. Wir können hier also einen unmittelbaren Einfluß von der Anzahl der Hotfixes pro Release zum Aufwand für Updates für die Anwender darstellen.

Betrachten wir nun eine zweite Variante. Wenn unser System in der Lage ist, Veränderungen für den Anwender völlig unsichtbar verfügbar zu machen, dann existiert kein Zusammenhang zwischen der Anzahl der Hotfixes und dem Aufwand für Updates für die Anwender. Dies ist beispielsweise der Fall in einer Online-Anwendung, die durch Continuous Deployment jederzeit auf dem neuesten Stand gehalten wird. Im Extremfall haben die Anwender nach jedem einzelnen Klick eine neue Version des Systems vor sich.

Eine sehr wichtige Erkenntnis daraus für die Arbeit mit System Thinking und System Modeling lautet daher: es existiert kein allgemeingültiges System-Modell, das für alle oder ähnliche Organisationen einsetzbar ist! Wir müssen stets die jeweiligen Realitäten in der betrachteten Organisation wahrnehmen und in ein plausibles System-Modell transferieren. 

Bleiben wir für den weiteren Verlauf beim ersten Beispiel mit einem System, das Aufwände durch Updates nach sich zieht.

Verstärkung und Abschwächung von System-Variablen

Wir betrachten nun die Zusammenhänge zwischen den einzelnen Variablen in unserem System-Modell etwas genauer und stellen dabei die Frage: „Wenn sich Variable A nach oben verändert, also in ihrer Ausprägung stärker, höher oder mehr wird, wie verändert sich dann Variable B?“

Wenn die Anzahl der Hotfixes steigt, dann steigt damit auch der Aufwand für Updates. Dies veranschaulichen wir mit einem einfachen Pfeil von der ersten zur zweiten Variable. Gleichzeitig stellen wir fest, dass mit einem Anstieg der Anzahl der Hotfixes die Verfügbarkeit des Systems sinkt. Diese negative bzw. inverse Auswirkung zeigen wir im System-Modell durch einen Pfeil mit einem annotierten Kreis. Die folgende Abbildung zeigt diese und weitere Verbindungen zwischen unseren identifizierten System-Variablen.

So tragen eine hohe Verfügbarkeit des Systems, eine hohe Geschwindigkeit der Problemlösung, sowie eine hohe Qualität zur gesteigerten Zufriedenheit der Anwender bei. Ein hoher Aufwand für Updates verringert jedoch die Zufriedenheit. Oder anders formuliert: geringe Qualität sorgt für geringe Zufriedenheit, wenig Aufwand für Updates sorgt für höhere Zufriedenheit.

Verzögerter Einfluß von System-Variablen

Wir können nun weitere Ursachen identifizieren, die zu Update-Aufwand und der Systemqualität beitragen. Wie oben schon beschrieben, kann der Anteil der System-Komponenten mit Continuous Deployment in unser Modell einfließen. Diese verbinden wir mit einer abschwächenden Verbindung zum Aufwand für Updates. Je mehr Continuous Deployment wir haben, desto geringer ist der Update-Aufwand. Um diesen Anteil zu erhöhen, benötigen wir eine entsprechend hohe Kapazität der Entwicklungsteams zur Umsetzung von Continuous Deployment. Nun ist es leider nicht so, dass sich der Anteil an Continuous Deployment sofort erhöht, wenn wir die Entwicklungskapazität nach oben setzen. Der Effekt tritt erst mit einer gewissen Verzögerung ein. Diese Tatsache verdeutlichen wir im graphischen Modell durch einen verstärkenden Pfeil mit zwei parallelen Linien.

Ein analoges Beispiel findet sich in der Abbildung bezüglich des Anteils an Test-Automation. Auch diese erhöht sich erst verzögert, nachdem die Teams ihre Kapazität zum Ausbau der Test-Automation erhöht haben.

Folgende Abbildung zeigt die graphische Sprache, mit der wir in System-Modellen arbeiten und visualisieren.

Kreisläufe von System-Variablen

Die folgende Abbildung zeigt ein erweitertes System-Modell unseres Beispiels. Hier sei nochmals darauf hingewiesen, dass dieses Modell auf den ersten Blick den Anschein eines allgemein gültigen Modells für jegliche Software-Entwicklungsorganisation erzeugen kann. Tatsächlich ist dieses Modell ausschließlich für unsere betrachtete Beispiel-Organisation gültig, auch wenn in einzelnen Aspekten parallelen zu anderen Organisationen gezogen werden können.

In diesem Modell lassen sich Kreisläufe von sich beeinflussenden System-Variablen erkennen. Alle Kreisläufe sind im Uhrzeigersinn dargestellt.

Einer der Kreisläufe lässt sich wie folgt beschreiben. Eine geringe Zufriedenheit der Anwender sorgt für eine hohe Anzahl an Support-Ticket, die wiederum eine lange Bug-Liste nach sich zieht. Somit steigt die Anzahl der dringenden Aufgaben, wodurch der Druck auf die IT wächst. Durch den hohen Druck verringert sich die Einhaltung der Definition of Done und damit sinkt der Fokus auf die Qualitätssicherung. Dieses geringe Maß an Qualitätssicherung verursacht mehr Fehler im Release und die Qualität des Systems sinkt für die Anwender, wodurch deren Zufriedenheit weiter absackt. Wir haben es hier mit einem sich selbst verstärkenden Kreislauf zu tun, gerne auch Teufelskreis genannt.

Dieser Kreislauf ist in der folgenden Abbildung vereinfacht ohne die umliegenden System-Variablen dargestellt.

Angriffspunkte und Maßnahmen

Schaffen wir es, solche Kreisläufe in unserem System-Modell zu finden und darzustellen, dann haben wir im nächsten Schritt die Möglichkeit, geeignete Angriffspunkte zu identifizieren und Maßnahmen abzuleiten, um das gesamte System zu verbessern.

Mehrere Hebel lassen sich in diesem Beispiel finden. Wie oben bereits skizziert, ließe sich der Anteil an Test-Automation im System erhöhen. In der Kette findet sich eine Idee, die dafür notwendige Kapazität im Team durch weitere Teammitglieder zu steigern. Dies wäre eine eher langwierige Maßnahme. Außerdem sehen wir, dass die notwendige Entwicklungskapazität für Test-Automation auch durch die Einhaltung der Definition of Done erreicht werden kann. Damit haben wir als mögliche Maßnahme identifiziert, die Effektivität des Scrum Masters zu erhöhen. Dies kann durch den Scrum Master auf Grund der Erkenntnis aus diesem System-Modell selbst erfolgen. Vielleicht steht auch ein agiler Coach zur Verfügung, der hier unterstützen kann, oder eine Scrum Master Community of Practice hilft im gegenseitigen Austausch mit Praktiken für mehr Effektivität der Scrum Master Rolle.

Es lassen sich weitere Optionen an Maßnahmen ablesen. Aus diesen Optionen können nun Experimente abgeleitet werden, um heraus zu finden, welche der Maßnahmen dem gesamten System tatsächlich weiterhilft. Die Abwägung der einzelnen Optionen bezüglich Machbarkeit, Hebelwirkung und nötigem Aufwand sollte von den Beteiligten des Systems besprochen werden, ebenso die Entscheidung über den konkreten, nächsten Schritt.

Iteratives Modellieren

Es reicht nicht aus, unser System einmalig zu analysieren und ein für alle Zeit gültiges System-Modell zu erzeugen. Nach jeder Maßnahme, nach jedem Experiment, nach jeder Veränderung am System muss das Modell erneut geprüft, hinterfragt und auf den aktuellen Stand gebracht werden. Die System-Variablen verändern sich im Laufe der Zeit und Zustände, die einmal negative Auswirkungen auf das Gesamtsystem hatten, können zwischenzeitlich in positive Aspekte umgeschlagen haben. Wir müssen immer wieder überprüfen, welche Erkenntnisse sich aus der aktuellen Situation unseres Systems ergeben, welche kritischen Faktoren im System existieren und welche Maßnahmen sich daraus ableiten lassen.

Nachteile und Pitfalls von Causal-Loop-Diagrammen

Für die an der Entstehung Beteiligten ist ein Causal-Loop-Diagram leicht nachvollziehbar. Jeder weiß, welche Bedeutung die einzelnen Variablen im Gesamtkontext besitzen und wie die Variablen miteinander zusammenhängen. Deswegen verstehen die Beteiligten auch die Schlussfolgerungen, die sich aus dem Causal-Loop-Diagram ergeben und in Maßnahmen umgesetzt werden sollen. Im Gegenzug ist dieses Verständnis für alle Nicht-Beteiligten oftmals leider nur schwer zu erlangen. Ein typischer Kommunikationsfehler im Umgang mit Causal-Loop-Diagrammen entsteht, wenn das visuelle Ergebnis Unbeteiligten übergeben wird in der Annahme, dass diese das Diagramm ohne intensive Erklärung nachvollziehen könnten. Da sich im Regelfall niemand die Blöße von Unverständnis geben möchte, wird diese Art der Kommunikation stillschweigend entgegengenommen oder im schlimmsten Fall kopfnickend akzeptiert. Damit entsteht wiederum auf der Senderseite die Annahme, dass eine gelungene Kommunikation stattgefunden hat und die überbrachte Nachricht verstanden wurde.

Die Entstehung von Causal-Loop-Diagrammen bedingt die Einbindung der Betroffenen und Beteiligten, damit ein gemeinsames Verständnis durch die gemeinsame Erarbeitung des Modells entstehen kann.

Übung macht den Meister

Für alle, die sich nun dem Thema Systems Thinking widmen wollen, habe ich einen wichtigen Hinweis: einfach machen und immer wieder üben! Egal in welcher Rolle Du Dich befindest, fang damit an, eine kleine Fragestellung in Deinem umgebenden System zu modellieren. Nimm ein wiederkehrendes Hindernis aus Deinem Team und finde heraus, welche System-Variablen zu diesem Hindernis beitragen. Nimm gerne auch einen positiven Aspekt aus Deiner Organisation, eine Sache, die bereits gelingt, und identifiziere einen sich selbst bestärkenden Kreislauf von System-Variablen dazu.

Bring dieses Werkzeug in eine Retrospektive und binde die Beteiligten des Systems bei der Erstellung des System-Modells ein.

Es gibt viele Möglichkeiten, Causal-Loop-Diagramme für die agile Inspektion zu nutzen. Experimentiere damit und setze die gewonnenen Erkenntnisse um. Die Resultate dieser Maßnahmen werden sich im nächsten System-Modell auswirken und es ist immer wieder interessant, zu sehen, wie sich das System-Modell im Laufe der Zeit verändert.

Welche Erfahrungen hast Du mit System-Thinking und Causal-Loop-Diagrammen gemacht? Was hat gut funktioniert? Welche Schwierigkeiten sind bei der Anwendung aufgetreten? Welche Unklarheiten oder Fragen haben sich für Dich ergeben?

Hinterlasse gerne einen Kommentar und berichte über Deine Erfahrungen.