John und Paul tragen diesen Vortrag gemeinsam vor, sie sind gleichberechtigte Partner. Der eine ist Entwickler, der andere kommt aus dem Operating. Und so beginnen sie ihre Erläuterungen nicht mit technischen Dingen, sondern mit einer Liebeserklärung. Sie zeigen ein Herz in dem steht: “Dev and Ops”. Zwar nimmt die Technik in dieser Präsentation einen sehr grossen Raum ein, doch betonen sie immer wieder, dass die Zusammenarbeit der wichtige Teil ist. Werkzeuge und Methoden, die sie entwickelt haben, sind aus diesem voneinander Lernen entstanden.
Als Zuhörer kann man spüren, welche Freude sie an dieser Zusammenarbeit hatten und wie Stolz sie auf das Erreichte sind. Man hört die Wertschätzung und den Respekt, den sie einander entgegenbringen und wie fruchtbar diese gemeinsame Arbeit war. Neben den technischen Dingen, die sie erreicht haben, betonen sie wie wichtig die Kultur bei solch einer Zusammenarbeit ist. Sie erwähnen unter anderem Vertrauen, Respekt, ein gesundes Verhältnis zu Fehlern und das Vermeiden von Schuldzuweisung als Voraussetzung.
10 und mehr Auslieferungen pro Tag haben sie schon im Jahr 2009 erreicht. Erstaunlich, oder? Was das ermöglicht hat, ist die Einsicht, dass es für die Entwicklungsabteilung nicht primär darum geht, neue Funktionen hinzuzufügen und das Ops nicht nur für einen stabilen Betrieb sorgen muss. Nein, schlussendlich ist die Aufgabe Business zu ermöglichen. Und wenn das Geschäft eins braucht, dann ist es schnelle Anpassungen an Veränderungen. Diese Einsichten haben dazu geführt, dass beide Bereiche gemeinsam an der Sache arbeiten.
Um schneller reagieren zu können, wird es als Softwareentwickler dann schon fast logisch, dass man vieles automatisiert, überall Versionskontrolle einführt, sowie Bauen und Ausliefern vereint. Abkürzungen zu erkennen, wie z.B. Feature Flags und Metriken zu teilen, um gleiche empirische Daten als Grundlage für Entscheidungen zu haben, wird zur Notwendigkeit.
Viele Auslieferungen und damit viele Änderungen am System erhöhen aber auch die Möglichkeit eines Ausfalls. Dieses Risiko haben sie dadurch gemanagt, dass sie den Umfang der Auslieferungen verkleinert haben. Aus heutiger Sicht und den Daten, die wir heute haben (vgl. dazu z.B. State of Dev Ops Reports), erscheint das schon banal, damals war es durchaus ein Augenöffner.
Mir gefällt auch wie sie die Wichtigkeit von Respekt vor den Erfahrungen, Meinungen, Prioritäten und Verantwortungen anderer Personen herausstreichen. Kollegen kommen mit anderen Lösungen, als man es selber umsetzen würde. Und ja, manchmal sind diese schlechter als die eigenen Ideen (oder sehen nur aus der eigenen Perspektive schlechter aus). Diesen kulturellen Aspekt kann man nicht deutlich genug betonen. Er ist wichtig, wenn man motivierte Mitarbeiter haben und langfristig zu besseren Lösungen kommen möchte. Über die Zeit wird ein Austausch und ein gegenseitiges voneinander Lernen stattfinden und das ist viel wichtiger als die heute ‘schlechtere’ Lösung. Und ja, Fehler passieren! Es ist wichtig zu lernen mit diesen Fehlern umgehen zu können. Jeder sollte bereit sein den anderen zu helfen und gemeinsam daraus zu lernen. Es ist wichtiger den Fehler zu beseitigen, als herauszufinden wer jetzt genau verantwortlich war.
So, jetzt hoffe ich genug Neugier geweckt zu haben. Viel Spass beim Anschauen!