In dieser Episode des Ship-It-Podcasts unterhalte ich mich mit Gerhard Lazu ausführlich darüber, wie gutes DevOps in der Praxis aussieht. Wir sprechen über die echten Herausforderungen, mit denen Unternehmen bei Transformationen konfrontiert sind, den Umgang mit Widerstand im mittleren Management, Technologieentscheidungen und wohin sich die Branche mit AIOps und Hyper-Automatisierung entwickelt.
Mein Weg zu DevOps#
Als ich 2002 als .NET-Entwickler bei Zühlke begann, war ich immer neugierig, wie ich die Qualität meiner Arbeit sicherstellen kann. Ich war etwas faul und wollte Dinge automatisieren. So bewegte ich mich in Richtung Continuous Integration und Continuous Deployment. Als die Applikationen grösser und verteilter wurden, wurde ich Architekt und konzentrierte mich auf den Aufbau von Continuous-Delivery-Pipelines. Als die DevOps-Bewegung startete, war ich sofort dabei, denn den Kunden kontinuierlich Wert zu liefern, war schon immer der Kern meiner Arbeit.
Heute leite ich als Head of DevOps bei Zühlke ein Team von etwa 31 DevOps-Engineers und -Consultants, die mit verschiedenen Kunden in unterschiedlichen Branchen an IT- und DevOps-Transformationen arbeiten.
Wie gutes DevOps in der Praxis aussieht#
Eines der besten Beispiele, die ich teilte, stammte von einem Kunden, bei dem wir einen Agile Release Train für die Transformation aufgebaut haben. Verschiedene Teams konzentrierten sich auf Governance, CI/CD-Pipelines und Containerisierung. Die entscheidende Erkenntnis kam durch unseren Umgang mit der Lieferung.
In den ersten Sprints lieferten wir an den Kunden, aber der Kunde nutzte das Gelieferte nicht. Also änderten wir den Ansatz: Der Kunde musste aktiv übernehmen und nutzen, was wir gebaut hatten. Wir nahmen das in die Definition of Done auf. Aber das reichte immer noch nicht. Also gingen wir einen Schritt weiter: In unseren Review-Meetings demonstrierte nicht mehr unser Team die Arbeit. Der Kunde musste zeigen, wie er das Gelieferte nutzt.
„Liefere nicht nur an den Kunden. Lass den Kunden zeigen, was du geliefert hast und wie er es nutzt."
Diese einfache Veränderung machte einen enormen Unterschied bei der Akzeptanz und Wertschöpfung.
Das grösste Hindernis: Das mittlere Management#
Auf die Frage nach den grössten Hindernissen bei DevOps-Transformationen war ich direkt: Es ist das mittlere Management. In vielen Unternehmen gibt es Einheiten, die als Silos organisiert sind, jede mit einem Leiter, der diese Einheit aufgebaut hat und spezifische Ziele verfolgt. Wenn man eine agile oder DevOps-Transformation startet, richtet man die Menschen am Wertstrom aus und bringt sie zusammen. Manche dieser Führungskräfte sehen, dass sie Macht verlieren, und leisten Widerstand.
Die Lösung beginnt an der Spitze. Das Top-Management braucht eine klare Vision und klare Leitlinien. Sie müssen die Ziele des mittleren Managements ändern. Nur durch Änderung der Ziele kann man das Verhalten ändern. Und wenn jemand sich wirklich nicht ändern will? Dann muss diese Person möglicherweise das Unternehmen verlassen. Das ist ein schwieriges, aber manchmal notwendiges Gespräch.
Weniger liefern, häufiger liefern#
Der Kern von gutem DevOps lässt sich auf ein einfaches Prinzip zusammenfassen: Weniger liefern, häufiger liefern und prüfen, ob es funktioniert.
Hinter jeder Geschäftsidee steckt eine Hypothese. Man muss diese Hypothese identifizieren und herausfinden, was das Minimale ist, das man tun muss, um sie zu beweisen. Hier definiert man das Minimum Viable Product und die Frühindikatoren. Dadurch reduziert man die Batchgrössen massiv, und die Arbeit, die durch den Wertstrom fliesst, wird fokussiert und bedeutungsvoll.
Man muss nicht Google, Netflix oder Amazon hinterherjagen. Es kann völlig in Ordnung sein, täglich oder wöchentlich zu liefern. Es geht darum, den Sweet Spot für den eigenen Kontext zu finden. Jeder Code oder jedes Feature, das gebaut, aber nicht draussen ist, ist Inventar. Und null Inventar ist das beste Inventar.
„Hab keine Angst, Entscheidungen zu treffen. Hab keine Angst, eine falsche Entscheidung zu treffen. Lerne, reagiere und passe dich einfach ständig an."
Technologieentscheidungen gehören dem Team#
Bei der Technologiewahl bin ich überzeugt: Das Team, das mit einer Technologie arbeiten muss, sollte die Entscheidung treffen. Wenn jemand anders entscheidet, steht das Team nicht dahinter. Mein Ansatz ist, zuerst den echten Bedarf zu verstehen: Welches Problem versuchen wir zu lösen? Dann die verschiedenen Optionen strukturiert analysieren, Prototypen bauen, um praktische Erfahrung zu sammeln, und das Team entscheiden lassen.
Die Geschichte über den Wechsel von Server-Side Rendering zu Angular illustriert das gut. Wir starteten mit einer alten Technologie, um schnell zu sein, lernten, was der Kunde wirklich brauchte, stiessen an die Grenzen der Technologie und trafen dann die schwierige Entscheidung zu wechseln. Es fühlte sich im Moment wie ein Misserfolg an, aber es war die richtige Entscheidung. Der anfängliche Ansatz ermöglichte es uns, schnell zu lernen, und die versunkenen Kosten sollten nie verhindern, die richtige Entscheidung zu treffen.
AIOps und die DevOps-Trends#
Wir diskutierten die wachsende Rolle von KI im Betrieb. Ich nutze Tools wie Dynatrace und Datadog, die KI für Mustererkennung über verteilte Log-Dateien einsetzen. Bei einem Kunden hatten wir lange mit Performance-Problemen zu kämpfen. Mit Dynatrace wurde der exakte Server mit einem Konfigurationsproblem in Minuten identifiziert. Das ist die Stärke von AIOps.
Bei den Trends sehe ich drei grosse Richtungen:
- Hyper-Automatisierung: Über einfache Automatisierung hinausgehen und nahezu alles in der Delivery-Pipeline automatisieren
- Cyber-Resilienz: DevSecOps mit umfassender organisatorischer Widerstandsfähigkeit gegen Angriffe kombinieren
- Observability: Mit zunehmender Automatisierung wächst auch die Datenmenge, die man überwachen und verstehen muss
Partizipative Budgetierung#
Ein Thema, das mir am Herzen liegt, ist die partizipative Budgetierung. Der traditionelle Ansatz, bei dem jemand an der Spitze das Budget gleichmässig verteilt, ist ineffizient, weil Budgetverantwortliche oft die tatsächliche Auswirkung jeder Initiative nicht verstehen.
Bei der partizipativen Budgetierung kommen alle Mitglieder des Wertstroms zusammen, erhalten einen Budgettopf und pitchen für ihre Initiativen. Sie diskutieren über Wirkung, Ausrichtung an der Strategie und Wertschöpfung. Das weckt unternehmerisches Denken und emotionale Eigenverantwortung, was zu einer besseren Budgetverteilung führt, die die Unternehmensziele wirklich unterstützt.
Kernaussagen#
- Liefere Wert, nicht nur Features. Lass den Kunden zeigen, was du geliefert hast und wie er es nutzt.
- Gehe den Widerstand des mittleren Managements direkt an. Ändere ihre Ziele von oben, um ihr Verhalten zu ändern.
- Liefere weniger, liefere häufiger. Identifiziere Hypothesen, reduziere Batchgrössen und validiere früh.
- Lass Teams ihre Technologie wählen. Sie verantworten sie, sie sollten sie auch entscheiden.
- Nutze AIOps. KI-gestützte Observability-Tools können in Minuten Probleme finden, die manuell Wochen dauern würden.
- Investiere in partizipative Budgetierung. Sie richtet Investitionen an der Strategie aus und schafft Verantwortung in der gesamten Organisation.