Mit DevOps die Digitalisierungsstrategie stärken

DevOps als Element der „New Work” und Teil der Digitalisierungsstrategie

Menschen sind von Natur aus neugierig und erschließen sich kontinuierlich neue Tätigkeitsfelder – und je besser sie diese verstehen, desto bessere Werkzeuge entwickeln sie, um diese Tätigkeiten effizienter zu gestalten. Häufig resultiert das in einer fortschreitenden Automatisierung, einem Grundgedanken des sogenannten New Work. Nach Frithjof Bergmann entsteht New Work insbesondere aus der intrinsischen Motivation von Menschen und deren freier Entscheidung für bestimmte Tätigkeiten, die ihnen wirklich wichtig sind. New Work hat heutzutage viele Ausprägungen angenommen, wie zum Beispiel agiles Arbeiten, Work-Life-Blending, Crowd- und Knowledge-Working.

Die Digitalisierung führt zur Entstehung neuer beziehungsweise zur Veränderung bestehender Geschäftsmodelle. Die konsequente Ausrichtung auf den Kunden-Mehrwert führt häufig dazu, dass sich Produktlebenszyklen respektive Vorlaufzeiten für bedarfsgerechte Veränderungen massiv verkürzen müssen. Dies kann optimal durch eine agile Entwicklung (DEVelopment) unterstützt werden. Ist für diese Produkte beziehungsweise Dienstleistungen eine permanente Interaktion mit Kunden notwendig, sollte auch der Betrieb (OPerationS) integriert werden. Genau dies ist das Konzept von DevOps: Entwicklung und Betrieb von Produkten und Dienstleistungen durch intrinsisch motivierte, heterogene Teams.

Als kleines „Unternehmen-im-Unternehmen“ ist jedes DevOps-Team dabei für seinen abgegrenzten Verantwortungsbereich mit hoher Fertigungstiefe vollumfänglich zuständig, inklusive der Entwicklung eigener Innovationen. Dies resultiert in einer Form der Microservice-Organisation, bei der prozess- und technologieorientierte Fachkräfte heterogene Teams formen, die gemeinschaftlich arbeiten.

Mehrere DevOps-Teams mit angrenzenden Verantwortungsbereichen können gemeinsam eine größere Wertschöpfungskette (Value Stream) erzeugen. Hier kommen skalierte, agile Zusammenarbeitsmodelle zum Tragen. Jeder Wertschöpfungsabschnitt wird von seinem zuständigen Team in angemessener Geschwindigkeit und in einem angemessenen Reifegrad entwickelt und betrieben. So können digitale Produkte und Services wirtschaftlich zur Verfügung gestellt und ständig den Marktbedürfnissen angepasst werden.

Darauf müssen Unternehmen im DevOps-Life-Cycle achten

Es gibt viele Wege, auf denen DevOps-Strukturen in Organisationen entstehen können. Bei Startups entwickeln sich DevOps-Konstrukte häufig „organisch“ und basieren dabei auf der Unternehmenskultur, der Altersstruktur und Ausbildung von Gründern und Belegschaft sowie der Charakteristik der Produkte und Dienstleistungen.

In gewachsenen Organisationen, vor allem, wenn sie hierarchisch organisiert sind und eine entsprechende Führungskultur vorherrscht, gestaltet sich die Transformation oft schwieriger. Aktuelle Herausforderungen und Projektvorhaben oder strategische Initiativen führen auch hier häufig zu der Erkenntnis, dass DevOps eine wünschenswerte und anzustrebende Struktur zumindest in Teilen der Organisation ist.

Entscheider müssen sich in diesen Fällen im Klaren darüber sein, dass die Einführung nicht kurzfristig umgesetzt werden kann und dass es keine Universallösung für die Implementierung von DevOps gibt. Stattdessen bedarf es eines maßgeschneiderten Ansatzes für das eigene Unternehmen, die eigene Kultur und die eigene Belegschaft.

Experten können helfen, den Transformationsprozess individuell anzupassen, und den Teams bei der Umsetzung zur Seite stehen. Insbesondere das Management benötigt oft Unterstützung, um sich vom Managementteam zum Leadership-Team zu entwickeln und Entscheidungskompetenzen an Mitarbeiter zu übertragen. Generell sollte die Leadership-Ebene die gesamte DevOps-Transformation begleiten und fördern – von den konzeptionellen Vorarbeiten über die Einführung bis hin zur kontinuierlichen Optimierung im Betrieb.

Vorbereitungen treffen

Vor Beginn einer solchen Transformation sollte das Leadership-Team eine klare Vision und Mission für die Organisation entwickeln – insbesondere für den Teil der Organisation, der transformiert werden soll. Dann gilt es, diese klar zu kommunizieren und partizipativ in der Belegschaft zu verankern, damit sowohl die intrinsische Motivation als auch das „Wir“-Gefühl entstehen können.

Der Umgang mit „Fehlern“ muss sich im Arbeitsalltag erlebbar verändern. Statt Schuldige zu suchen und anzuprangern, gilt es, Chancen für Verbesserungen („Lessons learned“) zu erkennen und diese zu nutzen. Idealerweise werden organisatorische und fachliche Experimente zum Teil des Arbeitsalltags. Für solche Experimente müssen sowohl Budget als auch eine klare ROI-Planung inklusive einer Exit-Strategie bereitstehen, damit Mitarbeiter angstfrei agieren können und sich Eigeninitiative entfalten kann.

Entsteht beispielsweise aus einer Retrospektive eine Idee für ein neues DevOps-Tool (zum Beispiel Infrastruktur-Monitoring, Software-Pipeline oder Entwickler-Test), muss klar sein, welches Ziel das Team mit diesem Tool erreichen möchte und wann die Zielerreichung überprüft wird, um über die weitere Nutzung zu entscheiden. Ist das Experiment nicht erfolgreich, wird das Tool wieder abgeschafft, ohne dass dies persönliche Konsequenzen für einen Mitarbeiter oder eine Mitarbeiterin hat oder das Team sich rechtfertigen muss.

Ein weiterer Erfolgsfaktor ist der frühzeitige Aufbau eines Netzwerkes mit wichtigen Stakeholdern. Beispiel aus der Praxis: Ein multinationaler Öl- und Gaskonzern wollte eine neue Software-Lösung für seine Tankstellen einführen und hierfür agile Arbeitsweisen nutzen. Dafür war es im Vorhinein nötig, die bestehende Umgebung zu untersuchen. Dies hatte zum Ziel, Abhängigkeiten und Schnittstellen sowie wiederverwendbare Lösungen und Prozesse im Unternehmen zu identifizieren, um den initialen Umfang des Projektes zu definieren. Im Zuge dessen wurden die wichtigsten Stakeholder frühzeitig identifiziert und nachhaltige Beziehungen zu ihnen aufgebaut. Die daraus entstandene Unterstützung dieser Führungskräfte für das Projekt war ein entscheidender Erfolgsfaktor, um auftretende Hindernisse schnell zu adressieren und zu lösen.

Gerade die von der Transformation betroffenen Stakeholder aus dem mittleren Management stellen häufig bei der Implementierung von DevOps einen kritischen Erfolgsfaktor dar. Die Transformation stellt potenziell ihr Rollenverständnis infrage, da mehr Entscheidungsverantwortung in die Teams übertragen wird. Hier liegt es am Leadership-Team, die Bereitschaft für ein neues Rollenverhalten beziehungsweise sogar für die Übernahme anderer Rollen zu wecken und zu unterstützen. Die Reorganisation von Teams resultiert schließlich in neuen fachlichen Aufgaben und bietet durch zielgerichtete Weiterbildung Chancen für neue Führungsrollen (zum Beispiel Product/Service Owner beziehungsweise Product Manager, Agile Coach).

DevOps: die Implementierung

Die Implementierung von DevOps hat signifikante Auswirkungen auf die Struktur der Organisation. Die Teams werden an Wertschöpfungsketten (Value Streams) ausgerichtet und decken in diesen alle fachlichen und technischen Aufgaben der benötigten Fertigungstiefe in Entwicklung und Betrieb ab.

Beispielsweise identifizierte ein führender Schweizer Telekommunikationsbetreiber eine Schwachstelle in der Softwareentwicklung und deren Betrieb. Aufgrund von zwei getrennten Teams wurde der Workflow häufig unterbrochen, da die Arbeit von einem zum anderen Team geschoben wurde. Nach der Zusammenführung dieser Teams zu einer DevOps-Unit und der Neuausrichtung entlang von Value Streams konnte der Release-Zyklus von der quartalsweisen Auslieferung auf monatlich umgestellt werden – operative Anpassungen und Fehleranpassungen wurden zudem außerhalb dieser Fenster eingespielt.

Ein wichtiger Schritt ist häufig das Aufbrechen des Silo-Denkens. Gerade zu Beginn der Transformation kann es aufgrund unterschiedlicher Arbeitsweisen, beispielsweise hinsichtlich des Agilitätsniveaus oder der fachlichen Ausrichtung, zu Kommunikationsproblemen kommen. An dieser Stelle können interne oder externe Mediatoren helfen, ein gegenseitiges Verständnis und im nächsten Schritt eine effektive Zusammenarbeit zu erreichen. Einmal mehr sind auch die gemeinsame Vision und die korrespondierenden Werte gefragt, die von der Führungsriege vorgelebt werden müssen.

Im Falle des Telekommunikationsanbieters wurde die DevOps-Transformation beispielsweise mit Plakatkampagnen und Erklärvideos der C-Suite begleitet, um in der Breite für Verständnis und Akzeptanz zu sorgen.

Neben dieser Top-Down-Kommunikation gehört es zu den grundlegenden Erfolgsfaktoren der Implementierung, die Umsetzung des DevOps-Frameworks zu überprüfen und gegebenenfalls anzupassen. Diese Aufgaben sollten möglichst früh in der Transformation in die Hände der Beteiligten übergehen und vom Leadership-Team lediglich begleitet und unterstützt werden. Das „Warum?“ und die allgemeine Richtung („Was?“) kommen von der Leadership-Ebene, die Details der Produkte und Services, das „Wie?“ und „Womit?“, entscheiden die Experten iterativ auf ihrer Arbeitsebene selbst.

DevOps im laufenden Betrieb

Die Umorganisation von Teams führt zwangsläufig auch zu einer Umgestaltung von Verantwortlichkeiten und Arbeitsweisen innerhalb und außerhalb dieser Teams. Basierend auf dieser Rollenveränderung kann die benötigte Belegschaft während des Betriebs in der Regel weiter verschlankt werden. Alle Teammitglieder müssen dabei die Bereitschaft für Cross Skilling mitbringen, um den Erfolg der DevOps-Transformation zu unterstützen.

Auf der Prozessebene werden die vormals parallel eingesetzten Scrum- und ITIL-Workflows zu einem gemeinsamen Kanban-Workflow fusioniert. Wo sinnvoll, werden die ITIL-Prozesse weiter automatisiert, um menschliche Interaktion zu minimieren und damit eine Beschleunigung und Fehlervermeidung in den technischen Prozessen zu erreichen.

So läuft in einem weiteren Fallbeispiel, einer großen deutschen Behörde, der ursprüngliche Betrieb weiterhin nach ITIL. Innerhalb der Betriebsorganisation hat sich zusätzlich ein Bereich etabliert, der Querschnittsleistungen für alle DevOps-Teams erbringt. Diese Unit hat eine Private Cloud aufgebaut und die Schnittstelle zum klassischen ITIL-Betrieb automatisiert.

So können alle Änderungen per Knopfdruck beauftragt, vollautomatisch genehmigt, dokumentiert und ausgeführt werden. Dadurch haben die DevOps-Teams eine zuverlässige Hardware- und Betriebseinbindung und übernehmen die volle Verantwortung für den laufenden Betrieb. Als weitere Leistung berät dieser Querschnittsbereich neue DevOps-Teams bei der Ausgestaltung der projektspezifischen Infrastruktur sowie bei Security-Themen.

Schritt für Schritt in die Zukunft – die Optimierung

Eine DevOps-Transformation ist nach der ersten Implementierung nicht abgeschlossen. Es gilt, den Kulturwandel voranzutreiben und die internen und externen Prozesse kontinuierlich zu verbessern. Hier ist erneut die Leadership-Ebene gefragt, einen entsprechenden Führungsstil vorzuleben. Zielkonflikte innerhalb und außerhalb der Teams müssen erfolgreich gelöst werden, Teams müssen „zusammenwachsen“ und „zusammen wachsen“.

Die Product Owner stehen im permanenten Kontakt mit den Nutzern – intern wie extern – und analysieren „ihren“ Markt. Mit der inkrementellen Weiterentwicklung der Produkte und Services wird auch deren „Produktion“ und „Betrieb“ ständig weiterentwickelt. Skaleneffekte erzeugen einerseits Synergiepotentiale, zeigen aber auch auf, welche manuellen Ausnahmen noch zu häufig auftreten und noch zu automatisieren sind. Neue Technologien bieten neue Ansätze für unzulänglich, instabil oder ungenau gelöste Teilaufgaben. Sowohl die Produkte als auch die betrieblichen Lösungsbausteine stehen ständig auf dem Prüfstein, werden verbessert, umgebaut oder ersetzt.

Zusammenfassung und Ausblick

DevOps kann ein essenzieller Bestandteil einer funktionierenden Digitalisierungsstrategie sein. Besonders die C-Suite und das mittlere Management sind gefragt, transparent zu führen und gleichzeitig den DevOps-Units den nötigen Freiraum zu lassen. In gewachsenen Organisationen stellen neben fundamentalen organisatorischen Umgestaltungen häufig die notwendigen individuellen Verhaltensänderungen eine große Herausforderung dar.

Für eine skaliert agile Entwicklung (Dev) gibt es bereits ein breites Spektrum gut ausgearbeiteter Methoden, aber der skalierte Betrieb (Ops beziehungsweise DevOps) ist nach wie vor bestenfalls ansatzweise entwickelt. Dabei sind gerade hier Themen wie Sicherheit (DevSecOps), Performance, Skalierbarkeit oder Compliance naheliegender in den selbstorganisierten Teams zu integrieren als bei reinen Entwicklungsteams. Auch die vollständige Übernahme der Verantwortung für Geschäftsmodelle (BizDevOps) durch die Teams stellt eine vielversprechende Perspektive dar. Hier sind weitere Entwicklungen und Erfahrungen aus experimentellen Ansätzen in verschiedenen Organisationen notwendig.

Über den Autor:
Jochen Estorff, Head of Talent & Organization Germany bei Infosys Consulting, verfügt über mehr als 26 Jahre Erfahrung in der Unternehmensberatung. Zusammen mit seinem Team hilft er Firmen dabei, strategische wie operative Strategien zur effizienten Umgestaltung zu implementieren.