Drei Fehler bei der Einführung von DevOps

Hey Leute,

seit mehr als zwei Jahren arbeite ich in einem der größten deutschen IT Projekte und unser Fokus ist ganz klar: Wir haben eine historisch gewachsene IT Landschaft, welche dringend modernisiert und neu gebaut werden muss. Die Gründe dafür sind vielfältig und ich muss an dieser Stelle wahrscheinlich nicht erwähnen, dass wir noch Relikte längst vergangener Zeiten kundenwirksam in Produktion haben. Wir sprechen von Hard- und Software, die vor 30 Jahren „state of the art“ war und mit der heutigen Entwicklungs- und Innovationsgeschwindigkeit nicht mehr mithalten kann.

Der konsequente Neubau dieser IT Plattform ist der einzige Weg für unser Unternehmen, um langfristig erfolgreich neue Funktionen für unsere Kunden bereitzustellen. Dabei haben wir auf IT Seite das ganz klare Ziel, im Durchschnitt fünf Mal häufiger Software liefern zu können.

Lass uns kurz das Wort „liefern“ definieren. Am Anfang steht immer eine Idee, welche durch eine Business-Einheit definiert wird. Diese wird dann gemeinsam mit der IT umgesetzt. Am Ende einer jeden Softwareentwicklung wird die Software vom Rechner des Entwicklers in die Produktion (die Umgebung, auf die der Endkunde zugreifen kann) geliefert. In der agilen Softwareentwicklung sprechen wir von continuous integration and continuous delivery (kurz CI / CD).

Fünf mal schneller liefern bedeutet, dass wir uns von einem Vorgehen nach dem Wasserfallmodell und somit von nur sechs möglichen Softwarelieferungen im Jahr verabschieden und im Ideallfall jeden Tag Software liefern können.

Damit wir häufiger Software liefern können, wurde bei uns auf einmal von DevOps gesprochen und da ich nun seit über einem halben Jahr in einem DevOps Team arbeite, möchte ich mit euch die drei größten Fehler bei der Einführung von DevOps teilen, die ich kenne.

Fehler 1: DevOps wegen DevOps einführen

Warum? Seitdem ich im Berufsleben bin, stelle ich mir immer öfter die Frage „Warum machen wir das?“ und ganz oft lässt sich die Antwort darauf nicht direkt finden. Wenn es keine Antwort auf das Warum gibt, wie wollen wir dann unsere Kollegen und Mitarbeiter begeistern und davon überzeugen mit uns eine Veränderung zu bewirken?

Ich möchte eine These aufstellen: Als Ken Schwaber und Jeff Sutherland das Scrum Framework entwickelt haben, war das Ziel, Unternehmen bei der Umsetzung von komplexen IT Projekten zu helfen. Das „Warum“ war ganz klar. Als Ergebnis ihrer Bestrebungen kam Scrum und damit eine Revolution in der Softwareentwicklung dabei heraus.

Mit DevOps wurde ein neues „Warum“ ausgelöst. Wir waren zwar in der Lage, in kleinen unabhängigen Teams Software zu entwickeln, aber in größeren IT Firmen, war die Einführung von agilen Methoden immer noch hauptsächlich von der Entwicklung und nicht vom Betrieb geprägt. Wir wollen und müssen aber Wertschöpfungsketten etablieren, in denen jedes Softwareentwicklungsteam in das produktive System für den Endkunden liefern kann. Damit wir dies mit einem guten Gefühl tun können, müssen Business, Dev und Ops wie Zahnräder ineinander greifen.

Daher der erste Tipp aus meiner Erfahrung: Sei dir klar, welches Problem du lösen möchtest. DevOps bedeutet für mich, dass wir unsere Wertschöpfungskette kontinuierlich verbessern.

Fehler 2: Starten ohne Management Support

Oft sehen wir Probleme zuerst auf operativer Ebene und zu oft fangen wir dann an uns zu überlegen, wer an den Problemen und Fehlern Schuld hat. Natürlich ist es dabei am leichtesten auf andere zu zeigen. Bevorzugt auf die sowieso ungeliebte Abteilung. Dieses verhalten erlebe ich jeden Tag und wir wissen es alle – es bringt niemandem etwas. Wenn du DevOps wirklich einführen möchtest, dann brauchst du einen starken Support aus dem Top Management. Die meisten Probleme in großen Firmen werden durch zwischenmenschliche Konflikte und historisch gewachsene Prozesse produziert. Nur, wenn dein Team Rückendeckung bei Fehler und beim Ausprobieren neuer Dinge hat, werdet ihr euch kontinuierlich verbessern können.

Daher der zweite Tipp: Such dir Unterstützung im Top Management.

Fehler 3: Starten ohne Hilfe

Stell dir vor, du kennst dein Zielbild und hast absolute Unterstützung vom Top Management. Jetzt ist alles bereit und du kannst sofort loslegen. Wäre es nicht gut, wenn du jetzt jemanden an deiner Seite hättest, der den Weg schon mal gegangen ist und der dir Tipps und Tricks geben könnte? Von der Erfahrung anderer Menschen zu profitieren ist und bleibt einer der besten Wege, um selbst zu lernen und zu seinem eigenen Ziel zu kommen.

Daher mein dritter Tipp: Such dir einen Coach, der schon einmal in einem performanten Team nach DevOps gearbeitet hat.

Euer Fabian

Leave a Reply

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.