• IT-Karriere:
  • Services:

Woran DevOps scheitern kann

Vermutlich bin ich nicht der einzige, der beobachten konnte, wie die Kombination aus DevOps, agilen Arbeitsweisen und Containern nicht von Beginn an funktionierte. Klar: Das ist kein Selbstläufer. Meistens geht der Wunsch nach Änderung von der Belegschaft aus, womit von Beginn an eine hohe Akzeptanz vorhanden ist. Ungeschickt ist es, wenn - wie mehrfach von mir und meinen Kollegen erlebt - Führungskräfte den Trend mit seinen vielversprechenden Möglichkeiten außerhalb der eigenen Organisationen mitbekommen und ihren Abteilungen einfach von oben verordnen wollen. "Wir machen jetzt DevOps", heißt es dann nicht selten.

Stellenmarkt
  1. Hama GmbH & Co KG, Monheim (Bayern)
  2. HYDRO Systems KG, Biberach

Die staunenden Bereichs- oder Abteilungsleiter, die selbst mit ihren Denk- und Arbeitsweisen die bisherigen Methoden vorgelebt haben, sehen sich einer unfairen Erwartungshaltung ausgesetzt. Wie können sie eine Transformation einleiten, wenn die Teamstrukturen, die Silos und Wissensinseln festigen, nicht auch infrage gestellt werden? In einem von meinem Kollegen beschriebenen Fall blieben die Teams mit ihren Silos erhalten. Das hatte zur Folge, dass die Mitarbeiter nicht wussten, was sich konkret für sie ändern soll. Da insbesondere die Techniker dank Online-Ressourcen ein breites Verständnis für DevOps und agile Arbeitsweisen aufbauen konnten, haben sie schnell bemerkt, dass die Implementierung in ihrer Organisation nicht vollständig erfolgt war. Dadurch entstand Frust, die Motivation im Arbeitsalltag sank.

Das genannte Beispiel ist gut geeignet, um einen häufigen Fehler bei der Einführung von DevOps deutlich zu machen.

Die Topologiefalle

In vielen Fällen konnte ich beobachten, wie ein Konzern die Auswirkungen auf die Organisation durch die Einführung von DevOps und agilen Arbeitsweisen so gering wie möglich halten wollte - was schon ein Widerspruch zu den Konzepten an sich ist. Mit der Schaffung einer "DevOps-Abteilung", die als interdisziplinäre Einheit Schnittstellen zu allen möglichen anderen Abteilungen aufbaut und Vorgänge beschleunigen soll, versprachen sich die Führungskräfte einen "sanften" Start.

Tatsächlich hat die "DevOps-Abteilung" langfristig nur ein weiteres Silo geschaffen, in dem zwar fähige Mitarbeiter saßen, diese aber das Wissen und die verbesserten Abläufe im eigenen Team behielten. Dadurch wurden Probleme einfach nur in eine neue Abteilung verlagert und dort ausgesessen.

Die Einführung einer "DevOps-Abteilung" kann höchstens der Beginn einer umfassenden Transformation sein, bei der ein DevOps-Team für ein isoliertes Thema eingeführt und später die Erkenntnisse auf alle Bereiche übersetzt werden. Spätestens zu diesem Zeitpunkt muss das DevOps-Team aufgelöst werden. Eine besonders extreme Variante der DevOps-Abteilung ist die Gründung eines Startups, um sich vom Konzern zu lösen. Das hilft sicher für isolierte Themen, die Gesamtorganisation profitiert dann allerdings nicht von den Neuerungen.

  • Klassische Ausgangslage: Dev und Ops als isolierte Teams (Bild: Matthew Skelton und Manuel Pais auf web.devopstopologies.com/Screenshot: Golem.de)
  • Eine DevOps-Abteilung einzurichten, schafft meist nur ein weiteres Silo. (Bild: Matthew Skelton und Manuel Pais auf web.devopstopologies.com/Screenshot: Golem.de)
  • Ein Unterteam mit DevOps hat meist nur geringen Erfolg. (Bild: Matthew Skelton und Manuel Pais auf web.devopstopologies.com/Screenshot: Golem.de)
  • Ein Etikettentausch löst die ursprünglichen Probleme nicht. (Bild: Matthew Skelton und Manuel Pais auf web.devopstopologies.com/Screenshot: Golem.de)
  • DevOps-Topologie, wenn Dev und Ops zusammenfinden. (Bild: Matthew Skelton und Manuel Pais auf web.devopstopologies.com/Screenshot: Golem.de)
Eine DevOps-Abteilung einzurichten, schafft meist nur ein weiteres Silo. (Bild: Matthew Skelton und Manuel Pais auf web.devopstopologies.com/Screenshot: Golem.de)

Interessant wird es auch, wenn ein bestehendes Team einfach um eine Untereinheit erweitert wird und man sich erhofft, dass die Arbeitsweisen der DevOps auf die übrigen Kollegen übergehen. In der Praxis konnte ich einmal beobachten, wie sich dadurch eine dauerhafte Unterstruktur gebildet hat, die es nicht schaffen konnte, mehrere Abteilungen zusammenzuführen. Hier war der Wandel schlicht zu niedrig in der Organisation aufgehängt.

  • Klassische Ausgangslage: Dev und Ops als isolierte Teams (Bild: Matthew Skelton und Manuel Pais auf web.devopstopologies.com/Screenshot: Golem.de)
  • Eine DevOps-Abteilung einzurichten, schafft meist nur ein weiteres Silo. (Bild: Matthew Skelton und Manuel Pais auf web.devopstopologies.com/Screenshot: Golem.de)
  • Ein Unterteam mit DevOps hat meist nur geringen Erfolg. (Bild: Matthew Skelton und Manuel Pais auf web.devopstopologies.com/Screenshot: Golem.de)
  • Ein Etikettentausch löst die ursprünglichen Probleme nicht. (Bild: Matthew Skelton und Manuel Pais auf web.devopstopologies.com/Screenshot: Golem.de)
  • DevOps-Topologie, wenn Dev und Ops zusammenfinden. (Bild: Matthew Skelton und Manuel Pais auf web.devopstopologies.com/Screenshot: Golem.de)
Ein Unterteam mit DevOps hat meist nur geringen Erfolg. (Bild: Matthew Skelton und Manuel Pais auf web.devopstopologies.com/Screenshot: Golem.de)

In einem Projekt habe ich erlebt, wie eine unternehmensinterne DevOps-Initiative damit startete, dass die Systemadministratoren plötzlich DevOps auf der Visitenkarte stehen hatten. Die Änderung des Etiketts alleine ist aber nicht hilfreich und sogar destruktiv, denn die betroffenen Kollegen weckten insbesondere bei anderen Abteilungen Erwartungen, denen sie niemals gerecht werden konnten. Hilfreich war auch nicht, von den ehemaligen Systemadministratoren plötzlich Entwicklungsarbeit einzufordern.

Auch umgekehrt wäre es beispielsweise falsch von den Entwicklern zu erwarten, dass diese sich Fähigkeiten von Operations aneignen und deren Aufgaben nebenbei mitübernehmen. DevOps heißt nicht, dass Individuen plötzlich interdisziplinär alles machen - vielmehr geht es darum, Mitarbeiter aus allen Disziplinen zu versammeln, damit sie Hand in Hand arbeiten.

Es ist durchaus in Ordnung, wenn beide klassischen Gruppierungen (Dev und Ops) ein gegenseitiges Verständnis aufbauen und für Teilbereiche Verantwortung übernehmen, wo bisher eine klare Trennlinie verlief, so lange sie die Aufgaben der anderen nicht vollständig übernehmen müssen. Mehr über klassische Topologiefallen und mögliche funktionierende Varianten finden sich übrigens hier.

  • Klassische Ausgangslage: Dev und Ops als isolierte Teams (Bild: Matthew Skelton und Manuel Pais auf web.devopstopologies.com/Screenshot: Golem.de)
  • Eine DevOps-Abteilung einzurichten, schafft meist nur ein weiteres Silo. (Bild: Matthew Skelton und Manuel Pais auf web.devopstopologies.com/Screenshot: Golem.de)
  • Ein Unterteam mit DevOps hat meist nur geringen Erfolg. (Bild: Matthew Skelton und Manuel Pais auf web.devopstopologies.com/Screenshot: Golem.de)
  • Ein Etikettentausch löst die ursprünglichen Probleme nicht. (Bild: Matthew Skelton und Manuel Pais auf web.devopstopologies.com/Screenshot: Golem.de)
  • DevOps-Topologie, wenn Dev und Ops zusammenfinden. (Bild: Matthew Skelton und Manuel Pais auf web.devopstopologies.com/Screenshot: Golem.de)
Ein Etikettentausch löst die ursprünglichen Probleme nicht. (Bild: Matthew Skelton und Manuel Pais auf web.devopstopologies.com/Screenshot: Golem.de)

Ein weiteres häufiges Problem bei der Einführung von DevOps ist, dass zu stark auf neue Tools gesetzt wird.

Neue technische Werkzeuge alleine reichen nicht aus

In einem Fall habe ich erlebt, dass alle "DevOps" und "Agilität" wollten, aber niemand die für einen Wechsel benötigte Zeit eingeräumt bekam. Nachdem das Thema lange vor sich hingedümpelt hat, wechselten IT-Verantwortliche plötzlich einfach das Tooling aus: Wo es zuvor klassische Ticketsysteme gab, wurde nun Jira eingesetzt; der alte Chat wurde abgeschaltet, dafür konnten nun alle Mattermost nutzen. Der Quellcode wurde vom uralten SVN in durch Bitbucket bereitgestellte Git-Repositories umgezogen. Der Rollout der selbstgeschriebenen Anwendungen erfolgte nicht mehr durch einen manuellen rsync, sondern durch eine - zugegebenermaßen recht gute - CI/CD-Pipeline, die Anwendungen automatisch paketierte und in der ersten Teststufe verteilte.

Da sich aber außerhalb des Toolings nichts veränderte, blieben die alten Probleme bestehen: Operations hatte nach wie vor viel zu wenig Kontakt zur Entwicklung, und Entwickler schrieben ihre Anwendungen in selbstgestrickten Entwicklungsumgebungen, die zum Teil komplett andere Versionen als die Produktion benutzen. In diesem Fall hatte der Wandel nur einen begrenzten Effekt; immerhin können die Techniker aber dauerhaft von neuen und modernen Werkzeugen profitieren.

Gut gemeint, nicht so gut gemacht

Die Erkenntnis, dass agile Arbeitsweisen und DevOps meist gut zusammenpassen, sickert meiner Erfahrung nach irgendwann überall durch. In einem Projekt habe ich allerdings erlebt, wie es die Führungskräfte zu gut gemeint haben: Täglich "durften" sich alle DevOps der Tochterfirma eines Konzerns in ein großes Standup einwählen. Wenn das tägliche Standup jedoch in zu großem Rahmen stattfindet und gleich mehrere Teams umfasst, dauert es viel zu lange und die Zahl der relevanten Informationen sinkt für jeden Einzelnen auf ein Minimum.

Konsequenterweise sinkt die Motivation an einer Teilnahme, und wer seine Mitarbeiter zur Anwesenheit zwingt, muss mit hohem Desinteresse rechnen. Auch wenn viele im Team Frühaufsteher sind, sollte der tägliche Austausch nicht unbedingt vor 10 oder 11 Uhr beginnen. Andernfalls haben die Kollegen nur wenig Zeit, den Tag zu planen oder in Ruhe zur Arbeit zu kommen. Abgehetzte Mitarbeiter, die sich von der U-Bahn aus einwählen müssen, möchte man eher vermeiden. In diesem mir bekannten Fall ging es gleich morgens um 9 Uhr los.

So weit zu häufigen Fehlern. Doch wie macht man es nun richtig?

Bitte aktivieren Sie Javascript.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
  • ohne Werbung
  • mit ausgeschaltetem Javascript
  • mit RSS-Volltext-Feed
 DevOps: ein ErklärungsversuchWie DevOps gelingt 
  1.  
  2. 1
  3. 2
  4. 3
  5. 4
  6. 5
  7. 6
  8.  


Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)

eechauch 09. Mär 2020

Was für ein Blödsinn. Ich kann dir garantieren, dass wir im Sicherheitsbereich seit...

konsolent 06. Mär 2020

Der (durchaus lesenswerte) Beitrag beginnt mit diesem erstaunlichen Satz: "Konzerne...

dermamuschka 06. Mär 2020

Jo, verstehe auch nicht, für mich ist das offensichtliche Akquise. Euer Großkonzern ist...

VigarLunaris 05. Mär 2020

Aber auch wenn Abteilungen auch schon ohne DevOps und dem ganzen Agile gerede zusammen...

demonkoryu 05. Mär 2020

Hat mir sehr geholfen mein Verständnis zu erweitern und präzisieren. Danke!


Folgen Sie uns
       


iPad 8 und iPad OS 14 im Test: Kritzeln auf dem iPad
iPad 8 und iPad OS 14 im Test
Kritzeln auf dem iPad

Das neue iPad 8 ist ein eher unauffälliger Refresh seines Vorgängers, bleibt aber eines der lohnenswertesten Tablets. Mit iPad OS 14 bekommt zudem der Apple Pencil spannende neue Funktionen.
Ein Test von Tobias Költzsch

  1. iPad-Betriebssystem iPadOS 14 macht Platz am Rand
  2. Zehntes Jubiläum Auch Microsoft hat das erste iPad überrascht

Amazon: Der Echo wird kugelig
Amazon
Der Echo wird kugelig

Zäsur bei Amazon: Alle neuen Echo-Lautsprecher haben ein komplett neues Design erhalten.

  1. Echo Auto im Test Tolle Sprachsteuerung und neue Alexa-Funktionen
  2. Echo Auto Amazon bringt Alexa für 60 Euro ins Auto

Facebook, Twitter und Youtube: Propaganda, Hetze und Manipulation
Facebook, Twitter und Youtube
Propaganda, Hetze und Manipulation

Immer stärker wird im US-Wahlkampf mit Falschnachrichten, Social Bots und politischen Influencern auf Facebook, Twitter oder Youtube um Wähler gebuhlt.
Eine Analyse von Sabrina Keßler

  1. Rechtsextremismus Wie QAnon zum größten Verschwörungsmythos wurde

    •  /