Verträgt sich DevOps mit der deutschen Arbeitskultur?
DevOps-Prinzipien und die deutsche Arbeitskultur sind nicht leicht zu vereinbaren. Aber es lohnt sich, die Herausforderung anzugehen.
- Justin Vaughan-Brown
Eine DevOps-Welle schwappt durch die Unternehmenswelt – aktuell arbeiten länderübergreifend bereits 27 Prozent aller IT-Fachleute in einem DevOps-Team, meldet Puppet in seinem aktuellen State of DevOps Report. Eine Studie, die die konkrete Verbreitung des neuen Ansatzes in deutschen Unternehmen untersucht, steht noch aus.
Dass jedoch hierzulande der Zuspruch immens ist, zeigen unter anderem die in fast allen großen Städten etablierten DevOps-Meetup-Gruppen. Die Gruppe in Berlin hat mehr als 2700 Mitglieder, die in Stuttgart immerhin 1200. Das wirft die Frage auf, wie gut DevOps wirklich in deutsche Unternehmen passt. Wer die hiesige Arbeitskultur und die Prinzipien von DevOps miteinander abgleicht, stößt schnell auf vier potenzielle Reibungspunkte:
- Hang zum Expertentum
- Bürokratismus
- Strenge Hierarchien
- Perfektionismus
Hang zum Expertentum
Das deutsche Bildungssystem ist auf Spezialisierung getrimmt. Sowohl an der Universität als auch im Rahmen einer dualen Ausbildung sind Blicke über den Tellerrand unüblich. Die Bildungseinrichtungen produzieren Fachexperten, keine Generalisten. Dieser besondere Ausbildungsfokus ist nicht etwa ein Fehler im System, sondern wahrscheinlich eine logische Fortführung der Traditionen des deutschen Gilden- und Meisterwesens. Und sicherlich trägt er durchaus seinen Teil zum wirtschaftlichen Erfolg der deutschen Industrie bei.
In agilen Arbeitsumgebungen fühlen sich viele Spezialisten jedoch fremd. Im typischen Scrum-Team etwa gibt es keine fest verteilten Rollen, sondern der Theorie nach sollten alle Teammitglieder funktionsübergreifend die vielfältigen Aufgaben eines Sprints bearbeiten können. Wenn Mitarbeiter sich selbst ausschließlich in der Position des Architekten, Programmierers oder Testers sehen, wird es ihnen schwerfallen, sich auf das neue Vorgehensmodell einzulassen.
Bei Kanban sind funktionsübergreifende Teams hingegen optional. Stattdessen kann die Arbeitsteilung etwa derart gestaltet sein, dass ein Product Owner die Prioritäten festlegt, ein funktionsübergreifendes Entwicklungsteam sich um Entwicklung und Tests kümmert und anschließend ein Spezialistenteam die Auslieferung übernimmt.
Überbordende Bürokratie
"Working software over comprehensive documentation" lautet einer der Grundwerte des Manifests für Agile Softwareentwicklung. Hierzulande gehören lückenlose Buchführung und gewissenhafte Dokumentation jedoch fast zur Lebensart. Was nicht schriftlich festgehalten wurde, ist nicht passiert, und was kein Papierdokument belegen kann, ist nicht wahr.
DevOps erfordert jedoch ein pragmatischeres Vorgehen – und entgegen der Traditionen des deutschen Vereinswesens haben agile Teams weder einen Schriftführer noch einen Kassenwart. Im Gegenteil: Für die kleinen, selbstorganisierten Gruppen erweist sich überbordende Bürokratie oft als Hemmschuh, der sie von der Erfüllung ihrer eigentlichen Aufgaben abhält. Die Autonomie der Teams besteht eben auch darin, dass sie nicht jeden ihrer Handgriffe dokumentieren und rechtfertigen müssen.
Strenge Hierarchien
DevOps versammelt Angehörige unterschiedlichster Fachabteilungen und Hierarchieebenen an einem Tisch. Dabei setzt es voraus, dass alle Beteiligten auf Augenhöhe arbeiten können: Offene Kommunikation und ein gleichberechtigter Meinungsaustausch gelten als Schlüssel zum Erfolg. In deutschen Unternehmen aber herrschen zwischen Mitarbeiter und Chef zumeist noch klare Verhältnisse, wer das Kommando hat und wer ausführt.
Das wirft die Frage auf, wie gut das etablierte Führungspersonal in einer flacheren Hierarchie zurechtkommt, in der agile, autonome Teams die Hauptlast der Arbeit stemmen. Bei Kanban ist beispielsweise "Leadership auf allen Ebenen" eins von sechs Grundprinzipien, die der Begründer der Methode David Anderson beschreibt. Im Klartext bedeutet das, dass Initiativen nicht mehr nur von oben ausgehen, sondern fortan alle Mitarbeiter mitgestalten und -bestimmen sollen.
Dem anfangs zitierten State of DevOps Report zufolge verlangt der neue Ansatz Vorgesetzten überdies spezielle Qualitäten ab, darunter visionäres Denken und die Fähigkeit, ihre Kollegen zu inspirieren. Mit Führungskräften, die das neue Anforderungsprofil nicht erfüllen und überdies auf strengen Hierarchien beharren, wird die Umsetzung der DevOps-Prinzipien nicht einfach.
Hang zum Perfektionismus
Continuous Delivery ist ein fester Bestandteil von DevOps. Anstatt etwa pro Quartal ein großes Release zu bringen, sollen Kunden in einer hohen Frequenz ein Minimum Viable Product erhalten. Der sogenannte "Fail-fast"-Ansatz zielt darauf ab, Anwendungen schnellstmöglich an neue Anforderungen anzupassen.
Um die sich wandelnden Bedürfnisse der Kunden zu erfüllen, eignet sich ein brandaktuelles, vielleicht nicht vollständig ausgereiftes Produkt oftmals besser als ein akribisch ausgearbeitetes, aber letztlich verspätet eintreffendes Release – zumal sich eventuell auftauchende Fehler schnell ausbügeln lassen. Der deutschen Vorstellung von Wertarbeit aber läuft das zuwider – und zwar nicht nur aus Anbietersicht, sondern potenziell ebenfalls aus der des Kunden.
An DevOps führt kein Weg vorbei
Die geschilderten Reibungspunkte sind real und lassen sich nicht wegdiskutieren, die vielfältigen Gründe für eine Einführung von DevOps und agilen Methoden aber genauso wenig. Letztlich kommt es für Unternehmen darauf an, den Ansatz und die eigene Arbeitskultur unter einen Hut zu bringen.
Dem deutschen Hang zum Perfektionismus etwa lässt sich durch die flächendeckende Überwachung von Anwendungen in der Produktivumgebung entgegenkommen. Wenn das Team Störungen und Ausfälle frühzeitig entdeckt, sinkt die Mean Time to Resolution (MTTR), also die durchschnittliche Zeit bis zur Behebung von Fehlern. Im Idealfall lassen sich dadurch viele Probleme beheben, bevor die Endnutzer von ihnen Notiz nehmen.
Ein exaktes Reporting kann ebenfalls weiterhelfen: Statt die agilen Teams in ein bürokratisches Korsett zu zwängen, können zugeschnittene Dashboards den einzelnen Stakeholdern im Unternehmen jeweils die Informationen liefern, die sie benötigen. Während die Entwickler sich vor allem für technische Kennzahlen interessieren, auf deren Grundlage sie ihren Code optimieren und erweitern können, liegt der Fokus der Geschäftsleitung mehr auf den Auswirkungen der Anwendungsperformance auf den geschäftlichen Erfolg.
