Container, DevOps, Agilität: Runter von der Insel!
(Bild: Arist Creathrive/Pexels)
Ein Erfahrungsbericht von Valentin Höbel veröffentlicht am
Konzerne führen DevOps, agiles Arbeiten und Container gerne im Paket ein. Das soll helfen, auch den trägsten Konzern von innen heraus fit für die Zukunft zu machen. Was dabei jedoch alles schieflaufen kann und wie echte Erfolge erzielt werden, erzählt ein IT-Consultant aus eigenem Erleben.
Wer schon einmal für einen Konzern gearbeitet hat, weiß um die enormen Möglichkeiten solcher Organisationen: Tausende Menschen arbeiten unter einem Dach und verfügen über riesige Ressourcen nicht nur, aber vor allem, finanzieller Natur. Spezialisierte Fachkräfte werden in spezialisierten Abteilungen gebündelt, was für eine klassische Arbeitsverteilung sorgt: Wer ein neues Netz braucht, wendet sich an die Netzwerk-Gurus, wer neue Datenbank-Cluster braucht, fragt beim DB-Team an.
Die klassischen Strukturen, die sich in Konzernen herausbilden, bringen aber auch Nachteile mit sich. Denn so eine Organisation kann unglaublich träge sein. Wenn ein neues Vorhaben begonnen wird, können Jahre bis zur Fertigstellung eines Produktes vergehen. Betriebsteams, Security, Compliance, Management, Marketing, Vertrieb - alle wollen und müssen involviert werden.
Durch die hohe Fragmentierung der Belegschaft auf zahlreiche Abteilungen entsteht ein gewaltiger Kommunikations-Overhead - und wer einmal an einer wichtigen und vielleicht auch mächtigen Position sitzt, hält gerne an seiner Rolle fest. Alte Gewohnheiten manifestieren sich nicht selten so stark, dass sie auch nach zehn Jahren noch Bestand haben, während anderswo mit moderneren oder effizienteren Methoden schneller Fortschritt möglich ist.
Wenn beispielsweise Software nach dem klassischen Modell entwickelt wird, werden andere Teams als das Entwicklerteam erst einbezogen, wenn sich das Produkt der Fertigstellung nähert. Kommen dann Probleme auf, verzögert sich die Auslieferung. Im schlimmsten Fall müssen sogar Änderungen vorgenommen werden, damit alle Vorgaben erfüllt werden. Abhängig von der Größe des Projekts kann es zu absurden Situationen kommen, in denen zum Release-Zeitpunkt beispielsweise der Bedarf oder die Nachfrage am Produkt gesunken sind, das Produkt aber durch nachträgliche Anpassungen teurer wird. Kein Wunder, dass sich motivierte Mitarbeiter oder Führungskräfte in Konzernen für DevOps und agile Methoden begeistern können, denn damit passiert so etwas nicht.
DevOps to the rescue!
Das träge Konzerngebilde kann damit aufgebrochen werden. Wo immer ich als IT-Consultant bei einer Einführung von DevOps dabei war, lag ein Hauch von Neustart in der Luft. In den meisten Fällen kam Schwung in das Unternehmen, wo zuvor über Jahre hinweg organisatorischer Stillstand geherrscht hatte.
Endlich gab es auch für die Führungskräfte wieder einen Anlass, Mitarbeiter zu motivieren, ihr Wissen und ihre Verantwortung besser zu streuen und die Kommunikation zu verbessern. Die durch Agilität und DevOps gewonnene Flexibilität wird oft auch dazu genutzt, Nutzer oder Kunden früh um Feedback zu bitten, so dass das fertige Produkt bei Veröffentlichung genau den Bedarf trifft und vielleicht sogar schon neue Aspekte berücksichtigt, die dem Team während der Entwicklungszeit bekanntgeworden sind.
Doch was ist eigentlich DevOps? Und wie kann das mit Agilität und Containern zusammenhängen?
"Was bedeutet DevOps für euch?", habe ich kürzlich Mitarbeiter einer großen Firma gefragt, als wir am Rande einer Konferenz zusammensaßen. Die Antworten fielen so vielfältig aus, als hätte ich nach einer Definition von "Glück" oder "Erfolg" gefragt. DevOps, Agilität, Container - all diese Begriffe wurden meist in einem Atemzug genannt, aber nicht jeder wusste sie voneinander abzugrenzen.
Während es sich bei Containern um eine Technologie handelt, sind agile Methoden und DevOps organisatorische Konzepte. Insbesondere die Idee hinter DevOps kann, richtig angewandt, meiner Erfahrung nach ungeahnte Energien freisetzen. In klassischen Organisationseinheiten arbeiten verschiedene Teams wie Dev, Ops, Sec, Q&A und UX zwar an einem gemeinsamen Ziel, etwa einem Produkt, sind aber im Alltag - nicht nur räumlich - getrennt voneinander.
Kommunikation und Wissensaustausch finden zwischen den Teams nur wenig statt. Es bilden sich Inseln, im DevOps-Kontext auch Silos genannt. So etwas konnte ich in fast jedem Konzern beobachten, für den ich bisher arbeiten durfte. DevOps macht es sich nun zur Aufgabe, diese Silos aufzubrechen, etwa indem Menschen aus verschiedenen Bereichen, wie eben Dev, Ops, Sec und so weiter, zu einem (virtuellen) Team zusammengeführt werden.
Die Organisation verspricht sich davon eine bessere Kommunikation, mehr Flexibilität und Geschwindigkeit, eine breitere Streuung von Wissen, eine höhere Qualität der Arbeit und nicht zuletzt eine höhere Qualität des Produkts, beispielsweise von Software oder einer Dienstleistung.
DevOps sind also nicht nur ein organisatorisches Thema, sondern auch eine Frage der Arbeitsphilosophie, -kultur und -mentalität, denn Offenheit und Zusammenarbeit stehen im Vordergrund. Die Grundsätze lauten: Arbeitet mit den gleichen Umgebungen, egal ob während der Entwicklung oder im Betrieb. Bezieht jeden mit ein, der ein Interesse an dem Endergebnis hat, und das schon möglichst früh. Und: Es ist normal, dass Dev, Ops und andere Teams sehr eng zusammenarbeiten und nicht, wie oft üblich, nur über Tickets miteinander kommunizieren.
Klassische Projektmethoden passen zu DevOps nicht, da sie zu starr, träge und unflexibel sind. Bei "gelebten DevOps" gibt das Management einen Teil der Verantwortung an eigenständig agierende Teams ab und muss sich nun darauf verlassen, dass diejenigen, die auf technischer Ebene die Aufgaben umsetzen, in vielen Bereichen eher wissen, welche Lösungen zum Ziel führen.
Agile Arbeitsweisen und DevOps gehen daher Hand in Hand. Gerade weil bei DevOps die klassische Trennung zwischen Dev, Ops, Sec und Q&A aufgeweicht wird, können DevOps-Teams neue Produkte vergleichsweise schnell entwickeln. Hilfreich ist dabei das Prinzip der MVPs ("Minimum Viable Products"), bei dem agile Teams ein kleinstes, funktionierendes Produkt schon sehr früh als Zwischenstand im Entwicklungszyklus dem Endanwender zur Verfügung stellen können.
Jedes weitere Sprint-Intervall legt neue Schichten (Fortschritt) um das MVP, wodurch dieses Stück für Stück zum fertigen Produkt heranreift. Durch die Anwendung von DevOps sind nicht nur Entwickler, sondern auch Kollegen aus Operations und anderen Teams früh involviert. Beide Konzepte, also Agilität und DevOps, profitieren bei richtiger Anwendung voneinander.
Container machen das Leben leichter
Bei meiner Arbeit mit den Konzernen beobachte ich oft, wie die internen Kollegen dankbar die Gelegenheit ergreifen und, ganz im Sinne von DevOps, propagieren: Alle in der Kette - von der Entwicklung bis zur Auslieferung - müssen von nun an mit der gleichen Laufzeitumgebung arbeiten. Im Sinne der Agilität fordern Product Manager häufigere und schnellere Deployments, da sie sich durch die Anwendung von agilen Arbeitsmethoden natürlich häufigere Releases versprechen.
Organisationen tun sich im Alltag allerdings schwer, ihren Entwicklern und dem Betrieb identische Systeme mit Laufzeitumgebungen für die Anwendungen zur Verfügung zu stellen. Nicht selten erlebe ich, wie Entwickler sogar in einem anderen Rechenzentrum arbeiten müssen, in denen die Server anders gepflegt werden als in der Produktion. Die Folge sind oft unterschiedliche Versionsstände von Softwarebibliotheken oder sogar unterschiedliche OS-Versionen.
Container lösen dieses Problem auf elegante Art und Weise: Durch Templates (bei Containern Images genannt) wird die Laufzeitumgebung für eine Anwendung - unabhängig vom Host-Betriebssystem - standardisiert und, so oft es geht, auch in anderen Projekten wieder verwendet. Das Image wird nur einmalig gebaut und dann in jeder Phase der Produktentwicklung (Entwicklung, Testing, Deployment) verwendet.
Damit alles reproduzierbar bleibt und auch die Ausbringung standardisiert ist, lässt sich das Verfahren durch CI/CD-Pipelines automatisieren. Ein Tool, wie beispielsweise Jenkins, lädt die Software-Quellen aus der Versionsverwaltung, zum Beispiel Git, herunter, baut automatisch das Image und schiebt es in die Registry. Automatisierte Jobs bringen die Anwendung in den verschiedenen Stages der Pipeline aus, so dass sie verschiedene Tests durchlaufen können. Nach Bestehen aller Tests und/oder der Freigabe durch das Team wird das Image in Form von laufenden Containern in der Produktion ausgebracht. Monitoring-Tools helfen dabei zu überwachen, ob die Vorgänge wie gewünscht ablaufen und sich das Produkt wie erwartet verhält.
Dank Kubernetes und Co. gibt es zudem immer mehr Möglichkeiten, so ein Container-Image, beziehungsweise die darin befindliche Anwendung, hochverfügbar und skalierbar zu betreiben. Freilich, man muss dafür nicht zwingend Container verwenden. Die Orchestrierungswerkzeuge für Container-Landschaften stellen allerdings die oftmals benötigten Features - wie Verschlüsselung, Load Balancing, Skalierung, Automatisierung, Scheduling, Self-Healing, Service Registry und so weiter - bereit, so dass man diese nicht selbst umsetzen muss.
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.
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
Es gibt sicher viele Strategien, um DevOps, agiles Arbeiten und Co. in Organisationen zu bringen. Eine häufig erfolgreiche Variante ist die Einführung unter dem Radar "von ganz oben". Es ist unrealistisch, von Topführungskräften zu erwarten, dass sie Strukturen ändern, wenn man nicht klar genug aufzeigt, wo die Schwächen des aktuellen Systems liegen und wie konkret man anders, und vor allem erfolgreicher, vorgehen kann.
Schon häufig habe ich daher die Herangehensweise beobachtet, dass eher kleine Teams die Köpfe zusammenstecken und für ein isoliertes Thema sowohl DevOps als auch agile Methoden einführen. Manchmal sind beides Folgethemen, da Technik-Enthusiasten eigentlich ihre Anwendungen auf Container umstellen wollen, aber damit nur erfolgreich sein können, wenn IT anders gedacht wird.
Wenn wir beim Szenario der selbstgeschriebenen Software bleiben, kann es eigentlich egal sein, ob eine Einführung von DevOps und Co. anhand einer neuen oder bestehenden Anwendung erfolgt, so lange alle an Bord sind.
Wichtig ist, dass die Beteiligten ein gleiches Verständnis dafür entwickeln, was für sie DevOps und agiles Arbeiten bedeutet. Auf dieser Grundlage lässt sich Schritt für Schritt ein Wandel einleiten:
1. Um nicht zu viel Widerstand zu erzeugen, sollte in diesem frühen Stadium nicht an Abteilungen, Zuständigkeiten und Organisationsstrukturen gerüttelt werden. Stattdessen ergänzen die Beteiligten das Bestehende um eine neue Ebene.
2. Aus den beteiligten Abteilungen heraus werden motivierte Kollegen "entsendet", ein virtuelles Team bildet sich.
3. Dieses virtuelle Team lebt und arbeitet nach agilen Methoden und wendet DevOps an, wo es vorteilhaft und sinnvoll ist. Die Mitglieder des virtuellen Teams erhalten von ihren Abteilungsleitern genug Zeit für ihr neues Vorhaben.
4. Beteiligte Führungskräfte, zum Beispiel Projektleiter, entwerfen grobe Ziele oder gerne auch Visionen, was als Erstes in Angriff genommen werden sollte. Das kann beispielsweise ein neues Produkt oder eine neue Version einer bestehenden Anwendung sein.
5. Ein Kick-off-Meeting mit allen Beteiligten stimmt auf die Ziele ein, gibt einen groben zeitlichen Horizont vor, zum Beispiel ein halbes oder ein ganzes Jahr, und legitimiert die neuen Arbeitsweisen. Alle verpflichten sich für "die Sache". Product Owner und Scrum Master werden festgelegt und verkündet.
6. Sprint-Wechsel, Standups, Reviews und Retros werden regelmäßig abgehalten.
Schon nach dem ersten oder wenigen Sprint-Wechseln sollte ein Ergebnis sichtbar sein, das man vorzeigen oder benutzen kann. Jeder weitere Sprint-Wechsel baut auf dem vorherigen auf, Stück für Stück wächst der Fortschritt zum gewünschten Endergebnis heran.
Mit dieser Erfolgsgeschichte können die Beteiligten an höhere Management-Ebenen herantreten. In offenen und ehrlichen Gesprächen werden die gelernten Lektionen offengelegt, womit Vor- und Nachteile der Thematik deutlich werden. Je nach Organisation kann es sinnvoll sein, Handlungsempfehlungen auszusprechen: Wie lässt sich dieser Erfolg nun im größeren Maßstab wiederholen?
DevOps zur Chefsache machen
Spätestens zu diesem Zeitpunkt müssen sich die höheren Führungsebenen intensiver mit der Thematik DevOps und agiles Arbeiten beschäftigen. Es muss bewusst werden, dass eine konsequente Einführung nichts weniger als eine Transformation der Organisation herbeiführen muss, da diese Themen alle möglichen Ebenen berühren. Die Transformation wird mehrere Jahre in Anspruch nehmen und sicher nicht geradlinig verlaufen.
Um in großen Organisationen den Überblick zu behalten und alles irgendwie einzuordnen, ist es sinnvoll, sich für agile Arbeitsweisen ein bewährtes Modell anzueignen und dieses auf die eigene Struktur anzuwenden. Schon mehrfach bin ich dabei auf das SAFeFramework gestoßen, das einen guten roten Faden für die Strukturen bietet. Warum alles neu erfinden, wenn sich solche Modelle bereits bei großen Organisationen bewährt haben? Als Framework stellt SAFe Vorgaben für die Organisation und Rollen bereit, die sich gut in der Praxis anwenden lassen.
Sehr wichtig sind dabei Mitarbeiter, die die Umstellung gegenüber ihren Kollegen mit Begeisterung vertreten.
Alle Führungsebenen müssen auf den Wandel eingestimmt werden, da sich früher oder später die Erkenntnis durchsetzen wird, dass ein Teil der Verantwortung an die Teams mit ihren Product Ownern übergehen wird. Da aber nicht jeder DevOps, agiles Arbeiten und etwaige neu eingeführte Technologien wie Container kennt, müssen insbesondere die Mitarbeiter abgeholt werden. Es ist sinnvoll, besonders motivierte Individuen zu Botschaftern für den Wandel zu bestimmen. Gemeinsam mit anderen tragen sie die Themen in die einzelnen Teams hinein. In kleinen Workshops wird erklärt, was sich ändert und wie DevOps und Co. funktionieren. Besonders wichtig ist es aufzuzeigen, welche Vorteile genutzt werden können.
Gerade in Konzernen sitzen einige Kollegen schon seit Jahren auf ihrer Verantwortlichkeit und Aufgabe. Ihnen muss erklärt werden, dass dieser Wandel keinen Bedeutungsverlust für sie bedeutet und es kein Nachteil für sie ist, wenn ihre Arbeit für andere Kollegen transparenter wird. Ganz im Gegenteil: Wer sein Wissen und seine Erfahrung gemäß DevOps mit anderen teilt und sein Wirken transparent macht, verbessert sein Standing im Unternehmen und gewinnt womöglich Zeit für neue, spannende Aufgaben hinzu.
Gerade Sprint-Wechsel laden dazu ein, Storys an sich zu ziehen, um neue Themen kennenzulernen.
Kein Fingerpointing, kein Blaming
Meiner Erfahrung nach ist DevOps vor allem auch ein Kommunikationsthema: Die Mitarbeiter stimmen sich häufiger und intensiver ab, gleichzeitig leben sie anderen Kollegen im Konzern die neue Mentalität vor und agieren damit als eine Art Botschafter. Meiner Beobachtung nach ist es für Konzerne eine Herausforderung, die Kommunikation in der Breite zu organisieren. Recht gut bewältigen Konzerne meistens Vorgaben, die auf alle Bereiche angewandt werden, wie etwa tägliche Standups mit einer bestimmten Länge oder lange Tage mit Sprint-Wechsel und Retrospective.
Wie schon bei anderen Themen gilt aber: Es muss nicht die reine Lehre sein. Tägliche Standups können auch - in Abstimmung mit den Teams - auf drei Standups pro Woche reduziert werden. Die Kollegen sollten dafür sensibilisiert werden, die Standups für Hinweise auf Probleme und Konflikte zu nutzen. Neuerungen, Errungenschaften und Änderungen sollten möglichst früh aufgezeigt und proaktiv kommuniziert werden. Daher ist es sinnvoll, wenn Konzerne den einzelnen agilen Teams Freiheiten einräumen und sie selbst bestimmen lassen, wie oft und wie intensiv der Austausch erfolgt, so lange ein Austausch stattfindet.
Leider ist es gar nicht so selten, dass in Konzernen Fingerpointing oder Blaming von Einzelnen, beispielsweise wegen unerwarteter Downtimes, zu beobachten sind. Das gilt vor allem für Bereiche, in denen die Strukturen schon lange feststehen und die Mitarbeiter oft unter Stress sind. Ganz im Sinne der Offenheit von DevOps - also Offenheit für Neues und Offenheit, immer etwas zu lernen - sollte von Führungskräften eine andere Mentalität vorgelebt werden. Es hilft, ein Klima zu schaffen, in dem Mitarbeiter offen über Fehler reden können, ohne gleich Anschuldigungen ausgesetzt sein zu müssen. Das Lernen aus früheren Erfahrungen steht im Vordergrund, Offenheit ist ausdrücklich erwünscht.
Die modernsten Arbeitsmethoden helfen jedoch nichts, wenn die eingesetzten Tools veraltet sind und beispielsweise nicht über Schnittstellen verfügen, um sie automatisiert ansprechen zu können. Es muss möglich sein, dass alte Werkzeuge infrage gestellt werden dürfen.
Moderne Systeme für Projektverwaltung/Tickets, Wissensdatenbank, Source-Code- beziehungsweise Versions-Management, Entwicklung, Testing, Rollout und Monitoring helfen bei der erfolgreichen Umsetzung von DevOps und agilen Methoden. Ideal ist es, wenn - insofern es möglich und vernünftig ist - Anwendungen nicht mehr in Form von Monolithen via Paket oder rsync verteilt werden.
Vielmehr sollte das Ziel sein, dass möglichst kleine Einheiten (Microservices) zum Zug kommen. Container-Images helfen dabei, die Laufzeitumgebung zu standardisieren und Software reproduzierbar sowie automatisiert aus der Entwicklung in das Testing und die Produktion zu bringen.
Die Menge an neuen Technologien kann viele überfordern. Jeden auf eine umfassende Schulung zu schicken, ist unrealistisch. Stattdessen sollte das Interesse der Mitarbeiter geweckt und Eigeninitiative gefördert werden. Selbstverständlich werden E-Books und andere Materialien zentral bereitgestellt, ergänzt um die Dokumentation von Findings der einzelnen Kollegen.
Für den großen Einstieg in komplexere Technologien bietet es sich auch hier an, von Beteiligten der ersten Stunde Workshops einzufordern. Diese können aufgenommen werden, zum Beispiel als Video oder Screencast, und damit allen in der Organisation zur Verfügung gestellt werden.
Wer einmal agil gearbeitet hat, will nicht mehr zurück
DevOps ist als reines Buzz-Word verschrien, dabei verbergen sich dahinter eine Sammlung an sinnvollen Konzepten, eine bestimmte Mentalität und Arbeitskultur. In Kombination mit agilem Arbeiten und gegebenenfalls Containern können sinnvolle Verbesserungen erzielt werden. Wer einmal DevOps und Agilität gelebt hat, will in der Regel nicht mehr zurück - das ist zumindest meine Beobachtung nach mehreren Jahren Projekterfahrung.
Konzerne haben aus nachvollziehbaren Gründen die aktuellen Strukturen und Arbeitsweisen und diese sind ja nicht per se schlecht. Allerdings können große Organisationen meiner Meinung nach besonders gut von einer Transformation profitieren, da sie die Flexibilität, Entwicklungsgeschwindigkeit und (Produkt-)Qualität verbessern könnte.
Agiles Arbeiten hält in der Regel auch wirtschaftlichen Vergleichen gut stand: Produkte, die nach langer Entwicklungszeit aufgrund geänderter Kundenanforderungen nachträglich angepasst werden müssen, werden teurer. Die kurzen Sprint-Zyklen helfen, diese Falle zu vermeiden. Ein Fehlschlag dort betrifft dann nur eines oder wenige Sprint-Intervalle, was wirtschaftlich vergleichsweise weniger schlimm ins Gewicht fällt.
Die große Transformation erreicht man in der Regel nicht, indem man schon früh an den etablierten Strukturen rüttelt. Hier ist Feingefühl gefragt: Ein kleineres Vorhaben, womöglich sogar ein U-Boot, kann recht schnell zeigen, dass DevOps und agile Methoden in der Organisation funktionieren. Mit der ersten großen Erfolgsmeldung kann das Management womöglich überzeugt werden. Erst danach können Strukturen und Arbeitsweisen in der Breite hinterfragt werden.
Der Wandel findet bei jedem Konzern anders statt, meist sehe ich aber immer wieder ähnliche Fehler und Erfolgsgeschichten. Hier hilft ein häufiger Austausch mit anderen Organisationen, gerne auf mehreren Ebenen. Konferenzen und Meetups bieten dafür eine gute Plattform.
Valentin Höbel ist Teil des Solution Providers open*i GmbH aus Stuttgart. In Kundenprojekten arbeitet er mit modernen Open-Source-Technologien. DevOps und agile Methoden gehören dort immer mehr zum Alltag. Abseits der Arbeit beschäftigt er sich mit neuen Technologien und erkundet ferne Galaxien mit seinem Teleskop.