DevOps-Transformationen sehen auf dem Papier einfach aus. Man nehme eine bestehende Umgebung, füge das Spotify-Modell hinzu, werfe SAFe dazu, streue etwas Team Topologies ein, packe DevOps und Platform Engineering obendrauf, rühre gut um, füge so viele Tools wie möglich hinzu und rühre nochmal. Was passiert? Es kracht. Und die Leute sagen: “DevOps ist Quatsch.”
Das Problem ist nicht DevOps. Das Problem ist, wie Organisationen die Transformation angehen. In diesem Video teile ich die Anti-Patterns und Erfahrungen aus meinen Jahren von DevOps-Transformationen in verschiedenen Branchen bei Zühlke.
Was Unternehmen erreichen wollen#
Bevor wir in die Anti-Patterns eintauchen, lassen Sie mich klären, was Unternehmen tatsächlich von einer DevOps-Transformation erwarten. Die fünf häufigsten Ziele, die mir begegnen:
- Mehr Wert fürs Geld (gesteigerte Effizienz)
- Schnellere Time-to-Market
- Höhere Qualität
- Höhere Kundenzufriedenheit
- Top qualifizierte Mitarbeitende (den Kampf um Talente gewinnen)
Und die Herausforderungen? Legacy-Systeme und -Prozesse, Budgetbeschränkungen, Talentmanagement, Kultur und Change Management sowie die Abstimmung zwischen IT und Business.
Anti-Pattern 1: Fehlendes Dringlichkeitsgefühl#
Die erste Erfahrung betrifft das Dringlichkeitsgefühl auf C-Level. Wenn dem Top-Management die Dringlichkeit fehlt, wird die Transformation zu einer Serie von Meetings mit vielen PowerPoints, aber ohne Entscheidungen. Themen werden endlos diskutiert ohne Fortschritt.
Das Dringlichkeitsgefühl kann aus zwei Quellen stammen: eine brennende Plattform (das Unternehmen muss sich jetzt ändern) oder eine sichtbare zukünftige Bedrohung (ein Herausforderer kommt). Wenn das Management eine DevOps-Transformation will, frage ich immer mindestens fünfmal “Warum?”, um zur Wurzel zu gelangen.
Ich verwende Dr. John P. Kotters Acht Schritte des Change Managements, wobei der erste Schritt das Schaffen eines Dringlichkeitsgefühls ist. Wenn man keine Dringlichkeit auf C-Level etablieren kann, kann man gleich aufhören. Man wird nur eine kleine Transformation erreichen, weil das Mandat für grosse Veränderungen fehlt.
«Wenn man kein Dringlichkeitsgefühl auf C-Level hat, wird man nur eine kleine DevOps-Transformation erreichen.»
Anti-Pattern 2: Fehlendes Führungscommitment#
Selbst wenn das C-Level das Dringlichkeitsgefühl hat, kann das mittlere Management den Fortschritt blockieren. Sie mögen den Status quo. Sie fürchten den Verlust von Kontrolle und Einfluss. Sie fokussieren auf kurzfristige Erfolge und haben möglicherweise gar kein Verständnis dafür, was eine DevOps-Transformation erreichen soll.
Die Lösungen:
- Peer Learning: Die eigenen Manager mit Gleichgesinnten aus Unternehmen verbinden, die die Transformation bereits durchgeführt haben. Das ist eine meiner besten Empfehlungen.
- Ausbildung und Training: Das mittlere Management muss DevOps verstehen, um den Wandel zu führen.
- Klare Erwartungen: Das C-Level muss explizite Ziele, KPIs und Messgrössen für die Transformation setzen.
- Business-Alignment: Die Transformation über die IT hinaus auf das Business ausweiten, sonst droht massiver Widerstand.
- Externe Experten: Menschen einbeziehen, die das schon durchgemacht haben.
Anti-Pattern 3: Einheitslösung für alle#
“Wir haben das Spotify-Modell implementiert.” “Bei Google machen sie es so.” Das ist ein gefährlicher Weg. Euer Kontext ist anders. Wenn man ein Framework unreflektiert nach Lehrbuch implementiert, bekommt man Verwirrung, Widerstand und Umetikettierung. Der Drei-Monats-Releasezyklus wird zum “PI” (Program Increment). Der Projektmanager bekommt den neuen Titel “RTE” oder “Scrum Master.” Tatsächlich ändert sich nichts.
Die Lösung: Eigene Werte definieren, nicht die Werte eines Frameworks. Eigene Prinzipien definieren, die Entscheidungen leiten. Outcomes definieren, nicht Outputs. Einen klaren Zweck etablieren, der die Frage der Mitarbeitenden beantwortet: “Was habe ich davon?” Und immer Inspect und Adapt betreiben.
«Nutzt Frameworks als Werkzeugkasten. Nehmt heraus, was zu eurem Bedarf passt und euer Problem löst. Wendet sie nicht nach Lehrbuch an.»
Anti-Pattern 4: Ein DevOps-Team bilden#
Das passiert auf der unteren Managementebene: “Wir wollen ein bisschen DevOps machen, also erstellen wir ein DevOps-Team.” Dieses DevOps-Team wird nur ein weiteres Silo zwischen Entwicklung und Betrieb und fügt dem Wertstrom weitere Mauern der Verwirrung hinzu.
Die Ursache ist Widerstand gegen Veränderung. Die Lösung: ein klares Ziel haben, ein Produkt-Mindset übernehmen, sich über den Wertstrom organisieren und die Budgetierung nach Wertströmen statt nach Abteilungen ausrichten.
Anti-Pattern 5: Geschäftigkeit#
Alle sind beschäftigt. Kalender sind komplett voll. Alles wird nur zu 60% erledigt. Es gibt keine Exzellenz. Und die Burnout-Raten sind hoch.
Die Ursache ist Multi-Loading: Menschen, die gleichzeitig mehreren Rollen, mehreren Produkten und mehreren Projekten zugewiesen sind. Ich begegne regelmässig Menschen, die zu 10% auf zehn verschiedenen Projekten eingeteilt sind. Sie können an Meetings teilnehmen und abstimmen, aber keinen echten Wert schaffen.
Meine Regel: Menschen, die zu einem Produkt oder Projekt beitragen, müssen mindestens 60% ihrer Zeit auf dieses eine Produkt oder Projekt verwenden. Wenn das nicht möglich ist, sind sie nicht Teil des Teams (sie können Fachexperten sein, aber sie sind keine Wertschöpfer). Wenn man nicht genügend Leute mit 60% oder mehr findet, startet man das Projekt nicht, oder man stoppt zuerst ein anderes. Das ist nichts anderes als Work in Process begrenzen durch Kapazitätslimitierung.
Anti-Pattern 6: Volles DevOps ohne Plattform#
“Alle Produkt-Teams machen jetzt You-Build-It-You-Run-It und kümmern sich um alles selbst.” Das Ergebnis: Inkonsistenz, Redundanz, schlechte Time-to-Productivity und Burnout. Die kognitive Belastung ist schlicht zu hoch, wenn jedes Team Infrastruktur, CI/CD, Monitoring, Security, Tooling und Kostenmanagement selbst managen muss.
Die Lösung ist Platform Engineering. Ein Plattform-Team baut eine zentralisierte Plattform mit standardisiertem Tooling, gesicherten Umgebungen und Self-Service-Fähigkeiten. Produkt-Teams bauen auf dieser Plattform auf. Sie besitzen weiterhin ihre Produkte, aber die Plattform reduziert ihre kognitive Belastung, damit sie sich auf die Wertschöpfung konzentrieren können.
Das ist kein neues Silo. Das Plattform-Team erstellt ein Produkt, das andere Teams nutzen wollen.
Die digitale Fabrik: Alles zusammenfügen#
Wenn man all diese Erfahrungen anwendet, gelangt man zum Modell der digitalen Fabrik:
- Vorstandsebene: Lean Portfolio Management mit einer klaren Vision und priorisierten Initiativen basierend auf Monitoring-Daten
- Produktebene: Produktmanagement, das Strategie mit Ausführung verbindet
- Teamebene: Befähigte Produkt-Teams, die ihre Produkte bauen, betreiben und warten
- Plattformebene: Ein Plattform-Team, das das Fundament mit standardisiertem DevSecOps, Laufzeitumgebung, Security, Monitoring und CI/CD bereitstellt
Das Plattform-Team schafft Wert für die Teams. Die Produkt-Teams schaffen Wert für die Kunden. Daten fliessen vom Monitoring zurück an die Teams zur Verbesserung und zurück an den Vorstand für strategische Entscheidungen.
Erfolgskriterien für DevOps-Transformationen#
- Wissen, was man erreichen will. Rückendeckung vom C-Level holen, klare Ziele und Outcomes (nicht Outputs) definieren und eine ganzheitliche Sicht einnehmen.
- Euer Kontext ist anders. Frameworks als Werkzeugkasten nutzen, nicht als Rezept. Den eigenen Kopf einsetzen.
- Führung, Führung, Führung. Führungskräfte müssen mit gutem Beispiel vorangehen und ein agiles Mindset haben. Wenn die Führung nicht vorangeht, funktioniert es nicht.
- Das Richtige bauen. Lean Portfolio Management nutzen, um Initiativen zu priorisieren und auf Outcomes zu fokussieren.
- Die Sache richtig bauen. In Platform Engineering, Standards und Qualität investieren.
- Software Engineers einstellen, keine Programmierer. Man braucht Engineering-Disziplin, nicht nur Coding-Fähigkeiten.
- Man ist nie fertig. Eine DevOps-Transformation ist kein Projekt. Sie erfordert kontinuierliche Verbesserung auf Dauer.
Kernaussagen#
- Dringlichkeitsgefühl ist nicht verhandelbar. Ohne Dringlichkeit auf C-Level erreicht man nur marginale Verbesserungen.
- Führungscommitment auf jeder Ebene ist essenziell. Peer Learning nutzen, um zögerliche Manager mitzunehmen.
- Nie Frameworks blind anwenden. Eigene Werte, Prinzipien und Outcomes definieren. Kontinuierlich Inspect und Adapt betreiben.
- DevOps-Silos vermeiden. Sich über den Wertstrom mit befähigten Produkt-Teams organisieren.
- Geschäftigkeit mit Fokus bekämpfen. Mindestens 60% Zuordnung pro Person pro Produkt durchsetzen. Work in Process begrenzen.
- Platform Engineering verhindert kognitive Überlastung. Eine standardisierte Plattform ermöglicht Produkt-Teams, DevOps im grossen Massstab zu betreiben.
- Wir treten in das Zeitalter der industrialisierten Softwareentwicklung ein. Digitale Fabriken, aufgebaut auf Platform Engineering, sind der Weg, wie Organisationen kontinuierlich Wert liefern.