So generiert DevOps den größten Mehrwert im Kundenprojekt

Eigene Rolle & Organisation des Teams im Projekt

Kürzlich habe ich mich mit meinem Kollegen Alex, DevOps Ingenieur, über meine DevOps-​Erfahrungen in meinem aktuellen Kundenprojekt unterhalten. Dabei ist folgende Abschrift des Gesprächs entstanden.

Wow! Das erfordert sicherlich eine sehr gute Teamorganisation. Wie habt Ihr Euch anfangs organisiert?
Gestartet sind wir mit reinen DevOps-​Teams, die die Weiterentwicklung UND den Betrieb verantworteten. Anfangs führten wir viele Workshops durch, um allen Teammitgliedern das DevOps-​Vorgehen zu verdeutlichen.
Wir nahmen uns als Team vor, Spaß zu haben, Dinge mutig anzugehen und dem Projekt einen eigenen Stempel aufzudrücken. Wir wollen unser Projekt selbst in der Hand haben. Damit war unser Projekt-​Slogan "Mitmach-​Projekt" geboren! Alle im Team hatten Lust, neben der Entwicklung auch den Betrieb zu übernehmen. Die Teams sahen und sehen immer noch einen sportlichen Ehrgeiz darin, knifflige Probleme und Produktionsfehler zu lösen. Damit hatten wir das Wichtigste erreicht: Alle Teammitglieder haben den Ops-​Teil angenommen.

So versuchten wir den Aufwand für den Betrieb zu senken

Das ist eine sehr gute Basis, auf der ihr aufsetzen konntet. Wie waren eure ersten Erfahrungen?
Unser Ziel ist es, wirtschaftlich erfolgreich zu sein. Das heißt, wir mussten neben der effizienten Entwicklung darauf achten, dass der Aufwand für den Betrieb auf einem niedrigen Level ist. Wir investierten viel in die Prozesse und organisierten einen Schichtbetrieb, um die vereinbarten Servicezeiten von 07:00 bis 18:00 Uhr abzudecken.
Schnell stellten wir fest, dass wir mehr Aufwand als geplant für den Regelbetrieb investieren mussten, obwohl wir viele Probleme im Betrieb in den Applikationen fanden und diese über Anforderungen behoben. Wir mussten also etwas verändern!

Und was habt ihr geändert?
Wir haben ein dediziertes Ops-​Team aus unseren vier Feature-​Teams aufgebaut mit dem Ziel, viele Produktionsfehler schneller zu lösen und den Aufwand für den Regelbetrieb zu senken. Gleichzeitig erhofften wir uns eine deutliche Effizienzsteigerung in der Umsetzung von neuen Anforderungen in den Feature-​Teams. 

Ist diese Überlegung denn aufgegangen?
Leider nur teilweise! Das dedizierte Ops-​Team half uns, leichte Produktionsfehler zu lösen und entlastete damit die Feature-​Teams. Komplizierte Produktionsfehler mussten jedoch weiterhin von diesen gelöst werden.
Wir konnten somit das Feature-​Team nicht wie gewünscht entlasten. Das Feature-​Team setzte aufgrund fehlender Einblicke in die Betriebsstabilität nicht die besten Lösungen um und das dedizierte Ops-​Team erkannte deutlich weniger Probleme bzw. potenzielle Betriebsverbesserungen. Wir hatten damit weniger Anforderungen aus dem Betrieb umzusetzen. Dies sorgte folglich dazu, dass wir weniger Betriebsanforderungen umsetzen konnten. Daher bin ich davon überzeugt: Ein guter Betrieb ist gleichzeitig ein guter Vertrieb!

Entscheidende Faktoren für erfolgreiche DevOps-​Teams

Ein dediziertes Ops-​Team war also offensichtlich nicht die Lösung. Wie habt Ihr dann die positiven Effekte vereinen können?
Wir haben uns wieder in reine DevOps-​Teams organisiert. Dieser Schritt lief reibungsloser als gedacht. Die DevOps-​Teams nahmen die Reorganisation schnell an. Ein sehr kurzfristiger, aber deutlich spürbarer Effekt war die erhöhte Lösung von Problems, was zu einer weiteren Stabilisierung aller Applikationen führte. Der Erfolg gibt uns Recht. In den letzten Wochen drückten wir sogar den Betriebsaufwand weiter und sind damit noch effizienter.

Ihr habt viele Erfahrungen im Projekt gemacht. Was waren aus Deiner Sicht die wichtigsten Erkenntnisse und Erfolgsfaktoren?
Wir haben viele positive Erfahrungen gesammelt. Meine drei wichtigsten Erfolgsfaktoren: 

• Wir machen DevOps und nicht Dev+Ops.
  Im Nachhinein betrachtet waren die Umorganisationen nicht notwendig. Reine DevOps-​Teams sind einfach effizienter, weil sie Probleme in der Anwendung erkennen und Produktionsfehler schneller lösen. Zudem musst du – egal in welcher Teamaufstellung – deine Erfahrungen sammeln, um den Aufwand für den Regelbetrieb zu reduzieren.
• Der Projektleiter ist integraler Bestandteil des DevOps-​Teams.
  Ich übernehme im DevOps-​Team auch Aufgaben, verstehe damit die Inhalte, Herausforderungen und Zusammenhänge besser und kann mit dem Kunden einfacher Inhalte und Probleme diskutieren.
  Ein positiver Nebeneffekt ist, dass ich im Team eine andere Akzeptanz genieße und das Team meine Aufgaben bzw. Verantwortungen versteht und mit mir teilt. Das Team fragt im Sprint Planning 1 nicht nur, ob der Kunde, sondern auch ob wir als Dienstleister zufrieden sind. Da kann man nur sagen: Alles richtig gemacht!
• Hab keine Angst vor Ops!
  Grundsätzlich wiederholten sich anfangs viele zum Teil einfache Tätigkeiten, die wir sehr schnell über Anforderungen automatisierten oder behoben. Vor allem unsere jüngeren Kolleginnen und Kollegen vom msg-​Standort im rumänischen Cluj gehen bei uns voran und haben richtig Lust, im DevOps Modell zu arbeiten und Probleme zu identifizieren, um Betriebsaufgaben zu reduzieren. Sie sind sich auch nicht zu schade, die Schicht zur Überwachung der Produktion und Entgegennahme der Produktionsfehler zu übernehmen. Das steckt auch alle anderen in unserem Projektteam an.

Vielen Dank, Thomas. Ich merke, ihr habt Spaß im Projekt und habt vieles richtig gemacht. Habt weiterhin viel Freude in Eurem Kundenprojekt.
Sehr gerne, schönen Tag noch!