Systems Thinking: Warum dieselben Probleme wiederkommen
Das Release kann raus. Eine Entwicklerin hat die abweichende Konfiguration gefunden, den fehlenden Wert nachgetragen und die Anwendung noch einmal geprüft. Das Team bedankt sich. Für heute ist das Problem gelöst.
Nehmen wir dieses Team als Beispiel und verfolgen die nächsten Auslieferungen. Mal fehlt eine Umgebungsvariable, mal ist eine manuelle Vorarbeit vergessen worden. Es sind verschiedene Fehler. Sie landen trotzdem bei derselben Entwicklerin, weil sie die Zusammenhänge kennt und schnell helfen kann.
Im Backlog steht längst, dass die Konfiguration verlässlich geprüft und bereitgestellt werden soll. Gerade ist dafür wenig Zeit. Die nächsten Auslieferungen warten schon.
Systems Thinking hilft, solche Verläufe über einzelne Vorfälle hinaus zu untersuchen: Welche Beziehungen zwischen Arbeitslast, Eingriffen und Verbesserungen könnten das wiederkehrende Verhalten erklären? Rückkopplungen und zeitliche Verzögerungen geben dafür eine Sprache. Ob die Erklärung im eigenen Fall stimmt, muss anschließend geprüft werden.
Die schnelle Hilfe hat eine längere Geschichte
Die Entwicklerin macht zunächst etwas Sinnvolles. Ein akutes Problem verlangt eine Reaktion. Wäre sie nicht eingesprungen, hätte das Release warten müssen. Aus dem einzelnen Vorfall folgt deshalb noch keine Kritik an ihrem Handeln.
Interessant wird die Zeit danach. Die wiederholten Eingriffe verbrauchen Aufmerksamkeit, die auch in eine robustere Bereitstellung fließen könnte. Bleibt diese Arbeit liegen, entstehen weiter Situationen, in denen die Entwicklerin gebraucht wird. Ihr Wissen wird durch jeden Einsatz größer; andere haben weniger Gelegenheit, die Aufgabe selbst zu übernehmen.
So kann ein Key-Person Risk entstehen: Ein Teil der Lieferfähigkeit hängt an der Verfügbarkeit einer bestimmten Person. Dass diese Person sehr gut arbeitet, kann die Abhängigkeit im Alltag schwer erkennbar machen. Von außen sieht man vor allem die gelungenen Auslieferungen.
Eine brauchbare Untersuchung nimmt deshalb auch die dafür nötigen Eingriffe auf. Wer musste wann helfen? Was hat gefehlt? Welche geplante Arbeit wurde dafür verschoben? Diese Informationen verändern das Bild eines scheinbar problemlosen Releases.
Eine Rückkopplung schließt den Kreis
Für unser Beispiel lässt sich eine mögliche Schleife beschreiben: Mehr manuelle Rettungsarbeit lässt weniger Zeit für verlässliche Konfiguration. Die anfällige Konfiguration erzeugt weiteren Bedarf an manueller Rettung. Der dritte Zusammenhang führt zurück zum ersten. Das macht aus einer Folge von Problemen eine vermutete Rückkopplung, einen Feedback Loop.
In ihrem Text über Eingriffspunkte in Systemen unterscheidet Donella Meadows unter anderem verstärkende und ausgleichende Rückkopplungen sowie die Bedeutung von Verzögerungen. „Verstärkend“ beschreibt dabei die Wirkung einer Schleife; es ist kein positives Werturteil.
Die akute Hilfe kann im Beispiel eine Störung ausgleichen und den Betrieb wiederherstellen. Gleichzeitig kann sich über mehrere Releases eine andere, verstärkende Dynamik entwickeln: Die Rettung verdrängt die Arbeit, die ihren künftigen Bedarf verringern könnte. Unterschiedliche Wirkungen können zur selben Zeit bestehen.
Ein Causal Loop Diagram, also ein Diagramm vermuteter Wirkungsbeziehungen, kann diese Annahme sichtbar machen. Für das erste Gespräch reicht bereits die Beschreibung in Worten. Wichtig ist, jede Verbindung einzeln erklären und infrage stellen zu können.
Das ist noch keine quantitative System-Dynamics-Simulation. Dafür müssten weitere Größen, Beziehungen und Annahmen ausgearbeitet und geprüft werden. Ein überzeugend gezeichneter Kreis allein sagt weder die nächste Störung noch ihre Wahrscheinlichkeit voraus.
Eine gute Geschichte kann trotzdem falsch sein
Vielleicht habt ihr zuletzt wesentlich mehr Releases durchgeführt. Vielleicht betreffen die manuellen Eingriffe überwiegend neue Umgebungen. Vielleicht wird die geplante Verbesserung aus einem ganz anderen Grund verschoben. Dann könnte eure erste Erklärung wichtige Ursachen übersehen.
Ihr geht deshalb vorhandene Auslieferungen durch und vergleicht ähnliche Fälle. Wie häufig war derselbe Konfigurationsschritt betroffen? Wurde die Verbesserungsarbeit tatsächlich für diese Einsätze unterbrochen? Konnten andere Personen den Schritt ausführen, wenn die Entwicklerin nicht verfügbar war? Woher stammen die Antworten: aus Tickets, Protokollen oder Erinnerung?
Beobachtung und Erklärung bleiben dabei getrennt. „Für diese Releases sind manuelle Korrekturen dokumentiert“ wäre beispielsweise eine belegbare Beobachtung. „Unsere Rettungsarbeit hält die Schwäche aufrecht“ wäre zunächst eine zu prüfende Erklärung. Erst die Verbindung zu verschobener Arbeit und wiederkehrenden Fehlern kann diese Erklärung stützen.
Diese Unterscheidung schützt auch das Team. Ein strukturelles Problem lässt sich sonst schnell als persönliche Schwäche erzählen: jemand delegiere zu wenig, jemand arbeite unsauber. Die Untersuchung muss zeigen, welche Bedingungen das Verhalten tatsächlich begünstigen.
Ein Eingriff, aus dem ihr etwas lernen könnt
Angenommen, die Unterlagen stützen den Verdacht. Dann wäre ein begrenzter Versuch sinnvoll: Ihr nehmt genau einen wiederkehrenden Konfigurationsschritt und reserviert vor den nächsten Auslieferungen Zeit, um ihn reproduzierbar bereitzustellen und automatisch zu prüfen.
Die erfahrene Entwicklerin erklärt zunächst, worauf sie bisher geachtet hat. Eine zweite Person führt den Schritt anhand der neuen Grundlage aus. Der Versuch braucht dafür reale Zeit im Plan. Wenn diese Arbeit beim ersten Dringlichkeitssignal wieder gestrichen wird, bleibt ein wesentlicher Teil der vermuteten Schleife bestehen.
Vorher legt ihr fest, was ihr über die nächsten vergleichbaren Auslieferungen beobachten wollt: Eingriffe an genau dieser Stelle, gebundene Arbeitszeit und die Möglichkeit, den Schritt ohne die bisherige Schlüsselperson auszuführen. Auch Ausfälle oder Mehrarbeit an anderer Stelle gehören dazu. Sonst könntet ihr eine Verschiebung des Problems für eine Verbesserung halten.
Die Wirkung darf Zeit brauchen. Die erste gemeinsame Ausführung kann sogar länger dauern. Eine Wirkungsverzögerung ist aber kein Grund, unbegrenzt an einem erfolglosen Versuch festzuhalten. Ihr vereinbart einen passenden Beobachtungszeitraum und eine erneute Bewertung. Gefährdet der neue Weg die Auslieferung, greift die vorher geklärte Rückfallmöglichkeit.
Beim nächsten Release schaut ihr genauer hin
Diese verborgene Stabilisierungsarbeit behandelt auch die Lektion „Signal: Menschliche Kompensation“ im Modul „Ordnen lernen“ von THINK FIRST Individual. Der Kurs setzt dort an, wo persönlicher Einsatz Lücken im System ausgleicht, und hilft, solche Zusammenhänge für das eigene Handeln zu erkennen. Die Parallele zum Systemdenken ist eine fachliche Verbindung, keine Schulung in System Dynamics.
Wenn ihr für den Versuch zwischen akuter Arbeit und einer strukturellen Verbesserung abwägen müsst, hilft außerdem die Frage nach den bewusst akzeptierten Trade-offs. Auch technische Schulden werden greifbarer, wenn der wiederkehrende Aufwand und die Voraussetzungen einer Verbesserung benannt sind.
Das nächste Release kann wieder gelingen. Diesmal bleibt euer Blick länger darauf: Welche Eingriffe waren nötig? Was konnte eine weitere Person übernehmen? Was hat sich gegenüber dem bisherigen Ablauf verändert?
Die Entwicklerin darf weiterhin helfen. Ihr Beitrag wird jetzt auch dafür genutzt, die Bedingungen ihrer Hilfe zu verstehen. Daraus kann ein System entstehen, das weniger häufig auf dieselbe Rettung angewiesen ist. Ob ihr dorthin kommt, zeigt die beobachtete Wirkung eures nächsten Schritts.