Botschafter für den Wandel finden

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.

• 

DevOps-Topologie, wenn Dev und Ops zusammenfinden. (Bild: Matthew Skelton und Manuel Pais auf web.devopstopologies.com/Screenshot: Golem.de)

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.