• 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. OPTIMA pharma GmbH, Gladenbach-Mornshausen
  2. Information und Technik Nordrhein-Westfalen (IT.NRW), Düsseldorf

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
Top-Angebote
  1. 461,01€ (Bestpreis)
  2. (u. a. Hitman 3 - Epic Games Store Key für 34,49€, Medieval Dynasty für 8,99€)
  3. 2.449,00€
  4. gratis (bis 22.04.)

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
       


Outriders angespielt

Im Video stellt Golem.de das von People Can Fly entwickelte Actionspiel Outriders vor.

Outriders angespielt Video aufrufen
Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme

      •  /