DevOps-Prinzipien: Flow und in Systemen denken

Im ersten Teil dieser Serie hatte ich angeschnitten, dass das grundlegende Prinzip in einer DevOps-Herangehensweise darin besteht, das Unternehmen als System zu sehen.

Heute möchte ich zunächst beleuchten, was damit denn eigentlich gemeint ist, welche Konsequenzen das hat und ob man daraus eventuell Praktiken ableiten kann.

Was macht ein Unternehmenssystem aus?

Einsame Helden retten die Prinzessin

Die Arbeit in Unternehmen kann einem manchmal wie eine High Definition-Version von Super Mario vorkommen.

Überall gibt es Hindernisse zum Drüberspringen und Rohre, bei denen man gar nicht so genau weiß, wieso man da jetzt durch klettern muss. Hier und da gibt es pilzköpfige Verbündete, die dich schulterzuckend von Level zu Level schicken und dir die Schuld geben, wenn was schief geht.

Doch das eigentliche Ziel – die Rettung der Prinzessin mit dem fruchtigen Namen – erreichst du nur auf Umwegen, weil sie aus unerfindlichen Gründen immer in einem anderen gottverdammten Schloss ist.

Während die Helden in Videospielen selten einen Moment für Reflektion ihrer Handlungen finden, können wir in Unternehmen einen anderen Weg einschlagen.

Wir können uns zum Beispiel fragen:

• Was ist eigentlich das übergeordnete Ziel unserer Unternehmung?

• Was tragen wir mit unseren Teams und Abteilungen, unseren Vertrieblern, Managern, Supportern und Entwicklern dazu bei?

• Wie müssen wir zusammenarbeiten, um das Ziel mit möglichst wenig Reibungsverlusten zu erreichen?

• Welche Hindernisse und Schwierigkeiten können wir aus dem Weg räumen?

Sind wir dabei auf uns allein gestellt?

Wohl kaum. Anders als bei Videospielen und im Roman, wo der Held gerne als einsamer Streiter für das höhere Ziel charaktisiert wird und auch das ihn umgebende System einzig dem Zweck dient, der Geschichte die nötige Würze zu geben, geht es bei unserem Handeln nicht um Aufrechterhaltung eines Spannungsbogens oder darum auf einen Höhepunkt zuzusteuern, ab dem die Handlung eine Wendung nimmt und erst dann zufriedenstellend zu Ende geführt wird.

Wir könnten zusammen daran arbeiten, jeden sinnlos drapierten Stein beiseite zu schaffen, wenn er uns im Weg liegt. Daran, die Spannung aus dem System zu nehmen, wenn sie keinem anderen Zweck dient als uns das Leben schwer zu machen.

Hier kommt der „Systems thinking“-Ansatz ins Spiel.

In einem System spielt die Interaktion zwischen allen Beteiligten eine große Rolle

Ein Team ist mehr als die Summe seiner Teile, heißt es.

Diese Aussage bedeutet, dass ein Ergebnis nicht allein auf einzelne Handlungen zurückzuführen, sondern erst durch die Interaktionen der Teammitglieder untereinander (also Wechselwirkungen) zustande kommt.

Die Betrachtungsweise des Unternehmens als ein (komplexes) System fügt eine weitere Dimension hinzu: nicht nur die Interaktion der Teammitglieder untereinander spielt eine Rolle sondern auch die Bedingungen unter denen das Arbeiten stattfindet.

Dabei gilt: manche Bedingungen können wir nicht beeinflussen, andere schon.

So sind beispielsweise die Wechselwirkungen zwischen den verschiedenen Teilen eines Systems eine feststehende Tatsache.

Eine Entscheidung an der einen Stelle kann kaum vorhersehbare Auswirkungen an anderen Stellen im System haben. Die praktische Konsequenz ist, dass Fehler beziehungsweise Abweichungen vom vermeintlich Erforderlichen (siehe auch den Artikel „Was ist schon falsch?“ von Daniel Dubbel) unvermeidlich sind.

Andererseits können wir zumindest das Risiko minimieren, dass Abweichungen das übergeordnete Ziel gefährden.

Dafür können wir:

1. Ein gemeinsames Verständnis für das Ziel der Unternehmung entwickeln und welche Wertströme dazu beitragen.

2. Gemeinsam dafür sorgen, dass der „Fluss“ in diesen Wertströmen gewährleistet ist und sich dabei alle optimal einbringen können.

3. Sicherstellen, dass Hindernisse und Probleme so früh wie möglich erkannt, aus dem Weg geräumt werden – und dass wir daraus lernen ohne widerrum (zum Beispiel durch Schuldzuweisungen) neue Probleme für das System zu produzieren.

Die Quintessenz der DevOps-Philosophie: von lokalen Optimierungen auf Kosten der Gesamtleistung Abstand nehmen

Eine hohe Bedeutung zum Erreichen von „Flow“ hat dabei die Vermeidung von Verschwendung. Bedeutet das: ganz auf Tätigkeiten zu verzichten, die keinen direkten (finanziellen) Gegenwert produzieren?

Darum kann es bei einem Denken in Systemen gerade nicht gehen, weil manche Tätigkeiten letztlich für die „Gesamtleistung“ des Systems wichtig sind.

Wenn wir beispielsweise einen einseitigen Fokus auf die wertschöpfenden Prozesse richten (z.B. Kundenarbeit) und dabei unterstützende Tätigkeiten vernachlässigen, bewirken wir langfristig eine Verschlechterung des gesamten Systems.

Der Verschwendungsbegriff umfasst in der DevOps-Sichtweise demzufolge auch Faktoren wie die Folgenden:

• Umständliche Bearbeitung (zum Beispiel manuelle Prozesse, die automatisiert werden könnten)

• Wartezeiten, wie sie durch (künstliche) Phasenübergänge oder der Abhänigkeit von einzelnen Entscheidungsträgern entstehen

• Ungenutztes Mitarbeiterpotenzial, wenn sich Mitarbeiter mit Aufgaben und Prozessen beschäftigen müssen, für die sie überqualifiziert sind, oder ihre Weiterentwicklung nicht gefördert wird

• Demotivation von Mitarbeitern, wenn beispielsweise ihr Beitrag zum Gesamtergebnis nicht richtig wertgeschätzt oder sie an Faktoren gemessen werden, die sie nicht beeinflussen können (siehe auch Die 14 Punkte guten Management gemäß Deming)

Kurz und knapp: Das System als Ganzes optimieren sollte oberste Ziel sein.

Welche Praktiken uns unterstützen können

Die Systemdenkweise stellt an sich schon ein gutes Werkzeug dar, weil wir unsere alltäglichen Entscheidungen aus dem Blickwinkel des uns umgebenden Systems betrachten und hinterfragen können.

„Erfahrung ohne Theorie lehrt das Management kein bisschen darüber, was zu tun ist, um die Qualität und Wettbewerbsstellung zu verbessern.“ — W. Edwards Deming

Genauso können wir aus diesem Blickwinkel vermeiden, beim Eintreten von negativen Ereignissen auf die erstbesten Schlüsse reinzufallen und stattdessen möglichst alle beitragenden Faktoren ermitteln (etwa mittels einer Technik wie der Root-Cause-Analyse).

Ansonsten können uns folgende Praktiken unterstützen:

Das System besser kennen lernen

Da Arbeit in manchen Bereichen (zum Beispiel in der Wissensarbeit) nicht so sichtbar ist wie beispielsweise in der Produktion, ist Visualisierung der Arbeit und Prozesse hilfreich.

Dabei unterstützen beispielsweise folgende Techniken/Methoden:

• Value Stream Mapping

• Kanban-Boards

Damit aus der Nutzung dieser Tools auch wertvolle Erkenntnisse gewonnen werden, hilft auch einen Blick auf relevante wissenschaftliche Theorien zu werfen.

So vermittelt uns beispielsweise die Theory of Constraints, dass die Gesamtleistung unseres Systems von limitierenden Faktoren abhängt.

Dazu gehören beispielsweise:

• Entscheidungen, die nur von einzelnen Personen getroffen werden können (oder dürfen)

• Vorgänge, die nur von einzelnen Personen durchgeführt werden können (beispielsweise wegen schlechter Wissensverteilung)

• Teams, die Unterstützungsprozesse für andere Teams erbringen und gleichzeitig durch Kundenarbeit voll ausgelastet werden

• manuell durchgeführte Prozesse, die genauso gut oder sogar besser automatisiert werden könnten

Die Psychologie klärt uns beispielsweise über Kognitive Verzerrungen auf, die unser Denken und Handeln beeinflussen: Bewusstsein für das Vorhandensein dieser Effekte ist wichtig. Nicht grundlos misst beispielsweise Google dem Unbiasing eine große Bedeutung bei.

Den Flow im System optimieren

Mit einem besseren Verständnis des Systems können wir Maßnahmen zur Verbesserung ergreifen.

• Verwendung von „Work in Progress“-Limits, um Reibungsverluste durch Kontextwechsel zu vermeiden und sicherzustellen, dass angefangene Aufgaben auch beendet werden

• Entscheidungen möglichst dort treffen, wo sie benötigt werden, um Wartezeiten zu reduzieren und fehlerhafte Entscheidungen aufgrund unzureichender Informationen zu vermeiden.

• Probleme möglichst an ihrer Quelle beseitigen und bevor sie Auswirkungen auf andere Teile des Systems oder den Kunden haben. Im Idealfall sehen alle im Unternehmen das als ihre Aufgabe an und sind mit den nötigen Befugnissen dafür ausgestattet.

• Prozesse vereinfachen oder sogar abschaffen, wo das möglich und sinnvoll ist und ansonsten dafür sorgen, dass das Wissen darüber nicht nur im Kopf von Einzelpersonen ist (siehe auch: Vom Wert Prozessregeln explizit zu machen)

Ein guter erster Schritt?

Wovon hängt alles im System ab?

Welche Prozesse müssen von der Mehrzahl der Personen in unserem System auf täglicher Basis durchgeführt werden? Welche Systeme und Werkzeuge müssen dafür benutzt werden – und was können wir daran kurzfristig verbessern?

Wenn wir uns diese Frage stellen und daraufhin auch tätig werden, können wir selbst mit kleinen Schritten einen großflächigen Nutzen erzielen.

Und womit den Erfolg kontrollieren?

Gerade die Faktoren, die wir nur schwer messen können, haben einen erheblichen Einfluss auf das Gesamtergebnis.

Die Zufriedenheit unserer Mitarbeiter lässt sich beispielsweise nur schwer erheben, ebensowenig wieviel Zeit und Motivation bei der Arbeit mit schlechten Werkzeugen oder frustrierenden IT-Systemen verloren geht. Dennoch ist es ein Fakt, dass solche Faktoren eine Rolle spielen, weil Menschen nunmal Menschen sind.

Letztlich können wir zur Steuerung zunächst mal nur auf den Durchfluss des Systems schauen: im DevOps-Umfeld wird der Blick dabei vor allem die „Lead time“ gerichtet, also die Zeit, die von Anfrage bis abschließender (zufriedenstellender) Erledigung vergeht. Weil uns das aber rein gar nichts über die Qualität unserer Leistung verrät, ist die Optimierung der Lead Time allerhöchstens Mittel zum Zweck.

Feedback ist daher (wieder mal) ein großes Thema, dem sich der nächste Artikel widmet.