Wertströme in DevOps
Wie soll man mit DevOps starten?
Gute Frage, aber als IT-Anwendungsentwickler kennt man da schon eine Lösung: Die Einführung von Continuous Integration und Continuous Delivery (CI/CD). Vielleicht benutzt man dazu neue Tools wie Bamboo oder Tools von CloudProvidern wie Azure DevOps. Und natürlich alles mit Microservices in Kubertnetes Container. Fertig.
Klingt einfach, oder? Und das Tolle: Es steigert das Glücksgefühl! Ja, wirklich! Bei Aussagen wie „Wir machen DevOps“ schwingt immer auch eine Portion Glück oder Stolz mit. Und teilweise auch zurecht, denn die Beteiligten haben durch die Einführung von CI/CD ihre Arbeitsprozesse vereinfacht. Folglich können sie können nun schneller entwickeln und schneller deployen. Alles läuft wie geschmiert.
Falls Sie jetzt zweifeln: Gut so. Die Praxis in vielen Unternehmen zeigt: so einfach ist es natürlich nicht. Wer kennt nicht die Situation, wenn eine neue Version fertiggestellt wird, die Mail ans Testteam verschickt wird und … nichts passiert. Warten ist angesagt. Vielleicht mal ein Tag, vielleicht eine Woche. Und dann kommt das Feedback und wenig überraschend muss doch noch mal etwas geändert werden. Tja, einfach freudig zu behaupten „Wir machen DevOps!“ reicht halt nicht wirklich.
Was ist überhaupt DevOps?
DevOps beschreibt einen Ansatz, wie die Zusammenarbeit zwischen Softwareentwicklung und IT-Betrieb verbessert werden kann. Der Begriff selbst ist ein Kofferwort aus den Begriffen Development und IT Operations. Verkürzt basiert DevOps auf drei Bausteinen:
- Verstehen und erhöhen Sie den Fluss.
- Verkürzen Sie Feedbackzeiten und reagieren schneller darauf.
- Lernen Sie kontinuierlich und experimentieren Sie.
Werfen wir einen Blick auf den 1. Punkt: Welcher Fluss ist hier gemeint?
Frage: Für wen produzieren Sie Software? Antwort: Für Ihre Nutzerinnen. Wenn Sie also den Fluss erhöhen wollen, geht es um die Erzeugung von „Nutzen“ für und bei Ihren Nutzerinnen. Und zwar nicht um die reine Erzeugung (hm, das wäre jetzt typisch Scrum), sondern um die permanente, kontinuierliche Erhöhung des Kundennutzens (vielleicht denken Sie mal kurz an Tesla).
Vielleicht ist Fluss nicht die richtige Bezeichnung. Wir wollen schließlich mehr erreichen. Lassen Sie uns daher einfach von Strom sprechen. Von Nutzenstrom.
Wertschöpfend ist…
Im klassischen Lean gilt der Leitsatz „Wertschöpfend ist das, was der Kunde zu zahlen bereit ist“. Die Kundin drückt ihren Nutzengewinn in ihrer Zahlungsbereitschaft aus.
Das klingt jetzt aber sehr akademisch, oder? Einfach ausgedrückt: es geht darum, den Nutzenstrom kontinuierlich zu erhöhen und dabei die Zahlungsbereitschaft der Kundin zu erhöhen oder wenigstens über die Zeit gleich hoch zu halten. (Vielleicht sollten wir hier kurz mal an Apple denken.)
In der Wertstromanalyse ist es wichtig, den Entstehungsstrom des Produktes erst einmal im Detail zu verstehen. Was passiert in den vielen Zwischenschritten? Warum braucht es 10 Tagen, um einen Fehler zu korrigieren, den eine Kundin in der App gemeldet hat? Warum dauert es 30 Tage, um einen Finanzreport zu veröffentlichen? Dieses SEHEN und VERSTEHEN ist der zentrale Punkt der Wertstromanalyse.
Und mit DevOps verhält es sich genauso. SEHEN geschieht durch BEOBACHTEN der tatsächlichen Prozesse. Früher ist man dazu in Produktionshallen gegangen, heute funktioniert dies durch die Beobachtung von Teams oder die Durchführung von strukturierten Interviews. Es geht jedoch nicht darum, Lösungen zu finden, es geht darum, Teams bei ihrer Reflexion zu unterstützen. Ziel ist es, dass die Teams selbst Verbesserungen in der Zusammenarbeit erkennen und diese in die Tat umsetzen.
Wie sehen Wertstromanalysen aus?
Werfen wir einen Blick auf eine Wertstromanalyse. Im Grunde geht es um das Aufzeigen von Prozessschritten auf dem Weg zum finalen Produkt. Es geht um die Dauer dieser Prozessschritte (auch als Process Time (PT) bezeichnet) und die Wartezeit zwischen den Prozessschritten (die sogenannte Lead Time (LT)).
Hier im Beispiel dauert es 15 Tage bis das Produkt erstellt ist, wobei 8 Tage Arbeitszeit und 7 Tage Wartezeit sind.
Nachdem sich eine ganze Generation von BWL’lern mit der Idee herumgeschlagen hat, einzelne Prozessschritte zu optimieren (Schlagwort: Operations Research), gehen die Wertstromanalyse und idealerweise auch DevOps einen anderen Weg: Verschiedene Teams, die für einzelne Prozessschritte verantwortlich sind, setzen sich zusammen, um gemeinsam den gesamten Wertstrom über sämtliche Prozessschritte hinweg zu optimieren. In der Unternehmensrealität reicht es nicht mehr, den Schritt vom Code Check-in zur Aktivierung des Build-Prozesses zu optimieren, wenn die nachfolgende Lead Time ignoriert wird. Die ganzheitliche Betrachtung des Wertstroms rückt in den Fokus; nicht die Optimierung von Prozessschritt 1 von 5 auf 3 Tage, sondern die Reduzierung der 15 Tage für die Erstellung des finalen Produkts.
Zusammengefasst: Bei der Wertstromanalyse geht es darum, Prozesse mit ihren Prozessschritten und den Wartezeiten als Ganzes zu begreifen. Und die Praxis zeigt, dass es viel effizienter ist – basierend auf einem gemeinsamen Verständnis der Beteiligten – den Wertstrom und nicht einzelne Elemente getrennt voneinander zu optimieren.
Die Verbesserung von Wertströmen bei Swiss Re
Auch bei meinem Arbeitgeber Swiss Re beschäftigen wir uns mit Wertströmen bei DevOps. Nachfolgend beschreibe ich Ihnen einen kleinen Auszug unseres Vorgehens:
- Durchführung von strukturierten Interviews.
- Aufbereitung der Erkenntnisse und Beschreibung des Ist-Zustands.
- Durchführung von Workshops zur Identifikation und Priorisierung von Verbesserungen.
- Bei Bedarf situative Begleitung einzelner Teams.
Vorausschicken möchte ich, dass ein gewisses Engagement und Interesse der Teams wichtig ist. Es hilft wenig, einen Top Down Ansatz zu wählen, denn die Optimierung von Wertströmen ohne die Unterstützung und die Mitwirkung von Teams kann nicht gelingen. Tatsächlich hatten wir bei uns sogar einen Fall, bei dem ein Team so große Zweifel an der Vorgehensweise hatte, dass wir es vorgezogen haben, einen Workshop kurzfristig abzusagen. Bei der Wertstromanalyse und auch bei DevOps geht es darum, Teams zu unterstützen und nicht dogmatisch zu belehren oder zu bekehren. Leider passiert dies aus meiner Sicht sehr oft bei Scrum und agilen Transformationen.
Begonnen haben wir mit der Durchführung von strukturierten Interviews. Wichtig war dabei, einen Vertrauensraum zu bilden. Wir wollten nicht bewerten, wir wollten verstehen. Die involvierten Personen kamen aus unterschiedlichen Bereichen:
- Kernproduktteam (Entwickler, Scrum Master, Business Analyst, etc.)
- Change Management Prozess Owner
- Generelle IT-Spezialisten (z.B. für die Build Tools, oder Datenbankspezialisten – je nach Gebiet)
- Repräsentanten von anderen Teams mit engen Schnittstellen
- Benutzer des Produktes, umgangssprachlich meist mit „Business“ tituliert
Für jeden Themenbereich wurden standardisierte Fragen definiert, die in den Interviews „abgearbeitet“ wurden. Auffällig dabei: unterschiedliche Typen von Mitarbeitenden zu erleben (siehe Literaturempfehlung). Bspw. wurden im Bereich „Requirements Definition“ u.a. folgende Fragen gestellt:
- Wer formuliert Anforderungen?
- Wie werden Anforderungen gesammelt und dokumentiert?
- Wie werden die Anforderungen priorisiert?
- Welche Ressourcen sind beteiligt?
- Was sind typische Vorlaufzeiten?
- …
Aus diesen Interviews haben wir als Vorbereitung für den Workshop den Ist-Zustand visualisiert:
Im Workshop selbst wurde die Visualisierung thematisiert und durch das Feedback der Teilnehmerinnen verändert. Was auf den ersten Blick einfach klingt, hat auf den zweiten Blick eine große Wirkung: es geht bei der Optimierung um die Teams und deren Sicht auf mögliche Verbesserungen. Es geht um die Reflexion der Zusammenarbeit und nicht um ein verstecktes Top-Down-Management.
Nachdem wir Einigkeit über den Ist-Zustand herstellen konnten, ging es um die Verbesserung des gesamten Wertstroms. Jede Teilnehmerin konnte Verbesserungen einbringen und vorstellen. Unternehmerische Hierarchien spielten keine Rolle und wurden im Workshop ausgeblendet. Schnell wurde Energie freigesetzt. Und wenn sich Teams gegenseitig inspirieren – wunderbar!
Am Ende galt es die Verbesserungen zu priorisieren und ins Backlog einfließen zu lassen. Einige Teams haben wir im Anschluss an den Workshop begleitet und bei der Implementierung von Verbesserungen unterstützt.
Fazit
Aus meiner Sicht sind Wertströme und DevOps gute Bekannte. Wertstromanalysen lassen sich hervorragend in die DevOps Transformation einsetzen. Sie sollten regelmäßig – bspw. wie bei unserem Vorgehen – eingesetzt werden, um einen kontinuierlichen Verbesserungsprozess am Leben zu erhalten. Wichtig dabei: Das Erkennen und Verbessern darf nicht im Elfenbeinturm geschehen, sondern ist gemeinschaftliche Aufgabe der beteiligten Teams.
Hinweise:
Interessieren Sie sich für weitere Erfahrungen aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.
Literatur:
Tom DeMarco, Peter Hruschka, Timothy Lister: Adrenalin Junkies & Formular Zombies – Typisches Verhalten in Projekten
Mike Rother, John Shook: Sehen Lernen – Mit Wertstromdesign die Wertschöpfung erhöhen und Verschwendung beseitigen
Klaus Leopold, Siegfried Kaltenecker: Kanban in der IT
Justus Graumann hat einen weiteren Beitrag im t2informatik Blog veröffentlicht:
DevGreenOps – Klimawandel meets DevOps
