Das dritte Prinzip von DevOps (Third way of DevOps) || DevOps Series – Episode 6

In diesem Artikel erklären wir das dritte Prinzip von DevOps (Third way of DevOps). Es also darum gehen, wie man eine Kultur im Unternehmen schafft, in der man kontinuierlich Experimente machen kann, um daraus zu lernen und innovativere Produkte zu entwickeln. Wir erklären auch wie man das umsetzen kann und was Chaos Engineering damit zu tun hat.

In der letzten Folge haben wir die wichtigsten Elemente von Kanban und von Scrum erklärt und wie diese zusammen funktionieren und was für Vorteile dadurch entstehen.

Wenn du darüber mehr erfahren willst schau unbedingt hier vorbei.

Das dritte Prinzip von DevOps

Ziel des dritten Prinzips von DevOps ist es eine Kultur zu schaffen, die die folgenden Dinge fördert:

1. Kontinuierliches Experimentieren
2. Das Eingehen von kalkulierten Risiken
3. Aus Fehlern lernen anstatt sie zu bestrafen.
4. Das Verständnis, dass Wiederholung und Übung die Voraussetzungen für Beherrschung einer Technik, Frameworks, Tools,… sind.

Da das, wenn man es unkommentiert stehen lässt, gerne falsch ausgelegt und damit vom Management abgetan wird werden wir auf jeden Punkt eingehen und erklären was damit genau gemeint ist und was nicht.

Kontinuierliches Experimentieren:

Hierbei geht es darum, dass auch bestimmte Szenarien (Corner Cases) abgedeckt werden und nicht nur der Idealfall. So können Fehlerursachen oder andere Lücken im System frühzeitig gefunden werden und dadurch weniger Schaden anrichten. Auch erlauben diese Experimente, dass man alternativen entdeckt, die besser/schneller funktionieren als die aktuellen Lösungen. Es geht also nicht darum einfach irgendetwas auszuprobieren worauf der Entwickler gerade Lust hat, sondern gezielt Problem aufzudecken oder bessere Lösungen zu finden.

Kalkuliert Risiken eingehen:

Oft wird nur gesagt man solle auch mal Risiken eingehen dürfen. Wichtig ist aber dabei das oft vergessene Wort „kalkuliert„. Denn wenn es geht nicht darum einfach etwas zu testen, was das ganze System zum Absturz bringt, sondern kleine berechenbare Änderungen einzugehen, die aber einen Mehrwert haben können für das gesamte Team oder sogar das gesamte Produkt.

Simon Sinek beschreibt das mit dem Beispiel zweier Helikopterpiloten in der Nähe eines feindlichen Luftraums.

Beide sind dafür da, dass falls jemand Treibstoff benötigt, dass man schnell helfen kann. Einer der Piloten kreist nahe an dem feindlichen Luftraum und überquert aus Übermut den Luftraum und löst damit Alarm aus und riskiert, dass er und seine Crew abgeschossen werden. Der andere Pilot macht genau das gleiche, nur wird er in diesem Fall von einem Kampfjet angefunkt, dass er kein Treibstoff mehr hat. Die Crew macht sich Gedanken, wie sie am schnellsten zu diesem Kampfjet kommen und der schnellste Weg ist, dass sie durch den feindlichen Luftraum müssen.

Es handelt sich also zweimal um die gleiche Situation und beide lösen den gleichen Alarm aus. Der einzige Unterschied ist, dass der eine Pilot ein kalkuliertes Risiko eingegangen ist, um dem größeren Ganzen zu helfen (in seinem Fall einem anderen Piloten). Und genau das ist die Form von kalkulierten Risiken, die wir ermutigen und nicht bestrafen sollten.

Einen ausführlicheren Artikel, wie Regeln in einem Unternehmen funktionieren sollten und was das mit Leadership zu tun haben, werden wir bald veröffentlichen 😉 .

Abonnier also unbedingt den Newsletter.

Aus Fehlern lernen:

Da unweigerlich Fehler passieren werden, da wir nunmal alle Menschen und nicht perfekt sind, sollten wir die Chance aus diesen Fehlern zu lernen nicht einfach verstreichen lassen. Daher gibt es Praktiken wie Post-Mortems oder Chaos Engineering (das wir gleich noch ansprechen werden), um aus diesen Fehlern zu lernen und die Lösung zu dokumentieren, dass sobald jemand anders (egal wo im Unternehmen) das gleiche Problem hat, er (im Idealfall) einfach danach im internen Wiki suchen kann und eine Lösung findet. Bestrafen wir nun die Fehler oder noch schlimmer die Person, die die Fehler gemacht hat, so verhindern wir nicht nur, dass wir daraus lernen, sondern auch, dass der Fehler beim nächsten Mal frühzeitig aufgedeckt wird und schnell gelöst wird.

Übung macht den Meister

Hierbei geht es darum, dass wir unsere Fähigkeiten durch Übung und Wiederholung immer weiter verbessern müssen, dass wir nicht nur besser und schneller Probleme lösen können, sondern auch im Ernstfall uns aus darauf verlassen können, dass wir schnell Herr der Lage werden können, das Team und damit das System also resilienter wird. Dadurch kann z.B. die Mean time to Repair (MTTR) deutlich verkürzt werden.

Aber wie kann man das jetzt umsetzen?

Ein wichtiger Baustein ist natürlich, dass man überhaupt die Zeit hat bzw. einplanen kann, um die tägliche Arbeit zu verbessern. Eine sehr sinnvolle und einfache Methode dafür ist es die regelmäßige Retrospektive aus dem Scrum Framework zu implementieren. Das heißt, dass man am Ende eines bestimmten Zeitraums sich als Team zusammensetzt und schaut, wie man die Arbeit in diesem Zeitraum (zwei Wochen, ein Monat,…) verbessern könnte.

Eine weitere Art das umzusetzen, die wir selbst benutzen ist, dass z.B. der Freitagnachmittag (bei uns: ab 15 Uhr) immer geblockt ist für Verbesserungen und Lernen. Um diese Zeit zu bekommen sollte man dem Management gegenüber klar machen können, dass das aktuelle Thema mit den aktuellen Aufgaben zusammenpasst und welchen Mehrwert man dadurch liefern kann 😉 .

Auch kann ein Hackathon eine gute Möglichkeit sein die Zeit für sichere Experimente oder Innovationen zu bekommen. Hier sollte man am Anfang ein konkretes Problem oder einen Business Case versuchen zu lösen, so ist die Akzeptanz beim Management deutlich höher.

Arbeitet man zusätzlich nach Scrum, so benötigt man für all das ebenfalls die Unterstützung des Product Owners, da er ja die Priorisierung der Aufgaben macht und sicherstellen muss, dass das Sprintziel erreicht wird. Aber auch hier kann man zunächst einmal damit argumentieren, dass man ein bestimmtes, priorisiertes Thema fokussiert abarbeitet (ich weiß das ist noch kein Hackathon im eigentlichen Sinne, aber es ist der erste wichtige Schritt in die richtige Richtung 😉 ). Sobald man dann zeigen konnte, dass die Zeit sinnvoll investiert wurde und man ein konkretes Problem gelöst hat, kann man beim nächsten Mal einen Schritt weitergehen. Wichtig dafür ist, dass man sich ein Thema aussucht, dass in der Zeit auch wirklich abgeschlossen werden kann und keine großen Nacharbeiten auf einmal eingeplant werden müssen.

So ein Hackathon funktioniert übrigens auch super als Teambuilding Aktion.

Photo by Annie Spratt on Unsplash

Ein weiterer Grund, warum ein Hackathon positive Auswirkungen haben kann, ist, dass dadurch das Team belohnt wird fokussiert an einem Thema zu arbeiten oder auch mal ein Experiment zu machen, das zwar schiefgehen kann, aber aus dem mit Sicherheit viel gelernt wird. Genau diese Ermutigung ist was manche Teams dringend benötigen, um innovative Produkte zu liefern. Genau darum sollte jeder Manager solche Events, Kreativität und Experimente unterstützen bzw. müssen wir diese Vorteile für unser aktuelles Produkt klar kommunizieren können.

Chaos Engineering als sicheres Experiment:

Das Konzept des Chaos Engineerings (manchmal auch als „Simian Army“ bezeichnet) wurde als erstes von Netflix angewendet. Der sogenannte Chaos Monkey war dabei ein Prozess, der zufällig bestimmte Production Instanzen beendet hat. Natürlich kommt jetzt als erste Frage: „Warum brauchen wir das?“ oder „Das passiert doch sowieso, dass mal was ausfällt, warum sollen wir das selbst machen?“

Und das trifft es sehr genau und daher sollten wir auch die passenden Antworten auf diese Fragen haben.

Die Antwort auf die erste Frage ist, dass wir in unserem aktuellen System unweigerlich Ziel von Angriffen oder Ausfällen von Produktionsinstanzen sein werden. Sei es durch einen Fehler oder durch eine Migration, die nicht wie geplant läuft oder … Damit wir in so einem Fall nicht zum ersten Mal mit dem Problem konfrontiert sind und feststellen, dass unser Monitoring, etc nicht richtig/gut funktioniert sollten wir diesen Fall vorher schon getestet haben.

Denn eines dürfen wir nie vergessen:

Jede Downtime unseres Produkts bzw. Services kostet Geld und verärgert Kunden/Nutzer.

Das heißt je früher und öfter wir das in einem sicheren und kontrollierten Experiment geübt haben, desto kürzer wird das Problem bei einem echten Notfall nicht verfügbar sein.

Die Antwort auf die zweite Frage ist auch relativ klar zu beantworten. Da es unweigerlich Probleme mit dem System geben wird, sollten zumindest wir bestimmen, wann diese Probleme auftreten. Nämlich am besten, wenn die ganzen Entwickler und Operationsteams noch in der Firma sind. Oder wirst du lieber nachts um 3 Uhr von einem Anruf geweckt, dass der Service ausgefallen ist und gefixt werden muss? Dass das ebenfalls auf lange Sicht für die Mitarbeiter nicht (er)tragbar ist, sollte jedem Manager klar sein.

Die Vorteile

Viele der sich daraus ergebenden Vorteile haben wir bereits angesprochen, aber wir wollen sie hier nochmal zusammenfassen, dass du alle Argumente an einem Ort hast 😉 .

Ein Vorteil ist, dass wir durch Experimente, Hackathons oder Chaos Engineering Flaschenhälse oder andere Einschränkungen im System frühzeitig finden und daher schnell lösen können.

Ein weiterer Vorteil ist, dass wir uns aussuchen können, wann die Probleme entstehen und in welchem Rahmen. Dadurch wir der Einfluss eines Ausfalls und die Kosten für Downtimes deutlich reduziert. Dies führt natürlich auch direkt zu zufriedeneren Kunden.

Durch die Möglichkeit für Experimente erreichen wir ein deutlich höheres Maß an Innovationen und damit Business Value oder auch eine schnellere Zeit bis zur Markteinführung.

Das übergeordnete Ziel

Ziel ist es also eine Kultur des Lernens zu erzeugen, die unserem Produkt bzw. Service die oben genannten Vorteile einbringt. Um den Bedarf für solch eine Kultur des Lernens zu verdeutlichen möchten wir Andrew Shafer zietieren:

You are either a learning organization or you are losing to somebody who is. – Andrew Shafer in „Beyond the Phoenix Project“

Das bedeutet, das wir aus Fehlern lernen müssen und dieses Gelernte auch verfügbar für andere machen müssen. Das bedeutet aber auch, das wir Trainings, Fortbildung, Zeit für die eigene Entwicklung in den Prozess mit einplanen müssen, um nicht von jemand anderem, der genau das macht, überholt zu werden.

Ganz wichtig ist auch, dass wir das Wissen und die guten Erfahrung aus den Trainings weitergeben, denn je mehr Leute im Unternehmen diese Trainings absolvieren und damit auch das Mindset haben, desto besser ist es für alle.

Von uns empfohlene Bücher für DevOps:

Hier sind nur Bücher, die wir selbst gelesen haben und uns in unserer Karriere geholfen haben!

Wir verlinken* hier (falls möglich) immer das deutsche, gedruckte Buch. Falls du dich für E-Books bzw. die englische Fassung interessierst, dann schau bitte auf der Seite, nach dem passenden Format für dich 🙂 .

Einfach auf das Bild klicken und direkt bestellen. Und das alles inklusive kostenlosem Versand innerhalb Deutschlands (ohne Mindestbestellwert) 😉 .

Fazit

Der Schritt um das dritte Prinzip von DevOps zu erreichen ist sehr schwer, aber es lohnt sich, da noch kaum Unternehmen dies erreicht haben.

Dafür dürfen wir aber Fehler nicht mehr als Problem sehen, sondern als Chance zu lernen und unser System besser zu machen. Wenn wir das geschafft haben können wir durch kalkulierte Experimente und Risiken unser System resilienter machen und gleichzeitig unsere Markteinführungszeit verkürzen und Innovation fördern. Dafür müssen wir es aber schaffen eine Kultur des kontinuierlichen Lernens im Unternehmen zu etablieren, die uns hilft unsere Stellung im Markt zu behalten oder sogar auszubauen.

Voraussetzung dafür ist aber wieder ein Verständnis (z.B. durch gute Trainings), auf allen Ebenen im Unternehmen, für die Prinzipien von DevOps!

Du willst noch mehr wissen und hast noch Fragen oder bist anderer Meinung?

Schreib uns das auch unbedingt in die Kommentare und wir werden dir gerne und ausführlich antworten!

Da das jetzt alles wieder sehr viel Input auf einmal war, haben wir eine einfache Übersicht über alles was zum Scrum Rahmenwerk gehört, für dich in einem kostenlosen Poster dargestellt. Du findest es hier:

Damit du all die gelernten Begriffe auch schnell nachschauen kannst, haben wir dir zusätzlich einen kostenlosen Glossar auf Deutsch mit +230 Begriffen zu DevOps, Agile und Lean mit den entsprechenden englischen Fachbegriffen (macht das Googeln meist einfacher, da es noch sehr wenige vollständige deutsche Blogs zu diesen Themen gibt) erstellt.

Und auch der ist komplett kostenlos. Du findest den Glossar hier:

Ausblick

In der nächsten Folge erklären wir dir, was das Framework von Kanban  genauer. Hierbei gehen wir gezielt auf die verschiedenen Prinzipien und Praktiken ein, die dabei angewendet werden.

Falls du das nicht verpassen willst und ein noch besserer Scrum Master/Agile Coach/Product Owner/Entwickler oder Leader werden willst, melde dich jetzt für unseren kostenlosen Newsletter an:

Unser Podcast

Und falls du unsere Experteninterviews und alle anderen Podcast-Folgen als erster bequem unterwegs hören willst, abonnier einfach unseren Podcast mit folgendem RSS-Feed:

Podcast RSS-Feed

Unser YouTube-Channel

Du stehst auf bewegtes Bild und zusätzliche Grafiken und Visualisierungen? Dann ab auf unseren YouTube-Channel „Agile Coach Academy“.

Abonniere den Channel und verpasse kein Video oder Experteninterview mehr.

Wie immer freuen wir uns auch wenn du diesen Artikel mit deinen Freunden, Kollegen und Bekannten teilst und uns dein ehrliches Feedback in den Kommentaren schickst.

Wir freuen uns auf dich in der nächsten Folge.

Deine Agile Coach Academy Gründer Ben und Alex

Mit * markierte Links sind Affiliate-Links mit denen du uns unterstützt dir weiterhin so guten Content zu liefern.

Vielen Dank für deinen Support 🙂

Note: Wir gehen keine Affiliates mit Amazon ein (auch wenn es hier mehr Möglichkeiten gäbe für uns), da die Mitarbeiter hier nicht fair behandelt werden und wir das nicht unterstützen!