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.

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.

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.

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?

"Wir haben sehr gute Erfahrungen mit DevOps gemacht", habe ich bei einem meiner letzten Projekte gehört. Das hat mich gefreut, doch wie kann man zu diesem Punkt kommen? Selten startet die Wandlung im oberen Management; meist sind es Produkt- oder Projektverantwortliche oder Techniker, die erkennen, wie sie von anderen Arbeitsweisen, Technologien und Mentalitäten profitieren können. Wie so oft gilt, dass man erst einmal beweisen muss, dass etwas Neues funktionieren kann, bevor andere dem folgen.

Klein anfangen