Das zweite Prinzip von DevOps (Second way of DevOps) || DevOps Series – Episode 5

In diesem Artikel erklären wir das zweite Prinzip von DevOps (Second way of DevOps). Es geht also darum, wie man Feedback-Schleifen von den Operations-Leuten zu den Entwicklern verkürzt und verbessert. Dazu werden wir auch über Telemetrie sprechen. Wir werden natürlich auch noch verschiedenste Beispiele für Feedback-Schleifen nennen.

In der letzten Folge haben wir die wichtigsten Frameworks für die Skalierung von Scrum vorgestellt. Also LeSS (Huge), Scrum of Scrums, SAFe und Nexus. Dabei haben wir jeweils die Vor- und Nachteile genannt und das – unserer Meinung nach – beste Framework gefunden.

Schau also unbedingt hier vorbei falls du darüber mehr lernen willst.

Das zweite Prinzip von DevOps

Hierbei geht es darum Feedback der Operationsteams so schnell und so gut wie möglich zu den Entwicklerteams zu bringen. Dazu gehört auch diese Schleifen zu verstehen und zu kennen. Nur so können wir können wir Probleme im System viel schneller finden und damit auch viel einfacher beheben.

Das zweite Prinzip von DevOps

Das erste Prinzip von DevOps (Flow) hat sich ja auf den Fluss von den Entwicklern (Devs) zu den Operationsteams (Ops) fokussiert. Im obigen Bild ist das der untere Pfeil. Das zweite Prinzip schließt nun diesen Kreis, indem wir ebenfalls versuchen das Feedback der Operationsteams möglichst schnell und direkt zu den Entwicklern zu bekommen. In obigen Bild ist das der obere Pfeil.

Ziel des zweiten Prinzips ist es zum einen das nötige Wissen auf beiden Seiten zu etablieren, sodass Probleme im Betrieb im besten Fall erst garnicht auftreten oder wenn doch, dass die Operationsteams möglichst viel Verständnis für den Code haben, um diese schnell zu lösen. Zum anderen ist das Ziel, dass, sollte das nicht funktionieren, die Rückmeldung über Störungen, Bugs, … im System möglichst schnell zu den Entwicklern kommen, sodass diese noch wissen, was sie getan haben und damit die Probleme schneller beheben können.

Feedback is the breakfast of Champions. – Ken Blanchard

Je später wir ein Problem entdecken, desto größer ist es sehr wahrscheinlich geworden und desto schwieriger und teuerer wird es dieses Problem zu beheben. Dazu kommt, dass durch ein spät entdecktes Problem der ganze Value Stream blockiert sein kann und damit unnötige und vor allem teure Wartezeiten (Waste) entsteht.

Was bedeutet das nun in der Praxis?

Swarming verstehen:

In den meisten Unternehmen gibt es verschiedene Support-Level. Also z.B. Level 1 Support, die die ersten Analysen machen, dann kommt Level 2 Support, der dann wieder Ticket Ping-Pong spielt und Rückfragen stellt und so verstreicht sehr viel Zeit, bis das eventuell sehr kritische und dringende Ticket beim richtigen Support-Level landet und dann hoffentlich endlich behoben wird.

Tiered Support Levels

Wenn man das Problem aber so schnell wie möglich lösen will, dann kommt Swarming ins Spiel. Swarming bedeutet nichts anderes als wen auch immer man benötigt für die Lösung des Problems zu mobilisieren und fokussiert an dem Problem arbeiten zu lassen, bis es gelöst ist und der gesamte Value Stream wieder weiterarbeiten kann. Gerade wenn man aber in Komponenten-Teams organisiert ist, fällt das schwer und es fehlt auch oft der Überblick, was für Auswirkungen ein Defekt in „meiner“ Komponente auf das Gesamtsystem hat. Dazu werden wir bald noch einen Artikel veröffentlichen, also unbedingt den Newsletter abonnieren 😉 .

Dadurch verhindern wir zusätzlich, dass das Problem sich weiter ausbreitet und dann auch zu Technical Debt wird, weil wir „gerade keine Zeit haben um das zu fixen“.

Aus Problemen lernen:

Das bedeutet das Problem nicht einfach nur zu lösen, sondern auch das Problem zu verstehen, warum das Problem überhaupt erst entstanden ist. Das ist extrem wichtig, weil wir sonst immer und immer wieder das gleiche Problem haben werden.

Technical Debt Quelle: https://www.activestate.com/blog/technical-debt-high-tech-ceos-perspective/

Dazu gehört auch, dass man das Problem und dessen Lösung dokumentiert. Am besten in einer Wiki, damit man danach suchen kann und alle im Unternehmen davon profitieren.

Der nächste Schritt ist dann, dass die Prozesse so angepasst (adapt) werden, dass der Fehler garnicht mehr auftreten kann in Zukunft.

Dies ist aber nur möglich, wenn im Unternehmen eine Kultur herrscht, in der man Fehler offen ansprechen und gemeinsam lösen kann. Stichwort Psychological Safety 😉 . Nur so werden die Mitarbeiter ermutigt, dass sie sich melden sobald ein Problem entsteht.

Ziel ist es das Problem zu lösen und nicht jemanden zu bestrafen, da Fehler in einem komplexen System unvermeidbar sind.

Nur wenn man diese Fehler früh identifizieret und löst, kann man als Unternehmen konkurrenzfähig bleiben.

Built-in Quality

Dies bedeutet, dass die Verantwortlichkeit für die Qualität des Produkts möglichst nah bei der Person sein sollte, die das Produkt entwickelt. So sind zum Beispiel Peer Reviews viel effektiver als eine Genehmigung eines Qualitätsmanagers oder ähnlichem, der aber nicht das Verständnis hat, was er gerade genehmigt.

Ebenso sind Pull-Request (PR) Reviews eine sehr gute Möglichkeit die Qualität so hoch wie möglich zu halten. Hier gilt es aber auch diese zeitnah durchzuführen, um die Entwickler nicht zu lange warten zu lassen. Um schnelles Feedback zu ermöglichen sollte die Batch Size möglichst klein sein.

Häufig haben wir dazu nach den Dailies einen Sync etabliert in dem spätestens über die offen PR Reviews gesprochen wird.

Blameless Post-Mortems

An dieser Stelle darf man natürlich sogenannte Blameless Post-Mortems nicht vergessen. Wichtig ist hierbei der Zusatz „Blameless“, der leider all zu oft vergessen wird. Es geht nämlich, wie oben bereits erwähnt, nicht darum irgendjemand die Schuld zuzuweisen, sondern das Problem zu lösen.

Schuldzuweisungen lösen nämlich keine Problem, sondern verschlimmern diese nur.

Das gilt für alle Beteiligten im Prozess. Egal ob Entwickler, Manager,….!

Ein blameless Post-Mortem kann quasi als eine sehr technische und sehr spezifische Retrospektive bezeichnet werden. Es wird der Kontext analysiert, in dem der Fehler aufgetreten ist und die Entstehung des Fehlers. Dies, die Lösung und abgeleiteten Maßnahmen werden dann in einem Dokument festgehalten und veröffentlicht, dass möglichst alle im Unternehmen darauf zugreifen können.

Automatisierte Kontrollen

Unnötige, manuelle Kontrollen können sehr viel Verzögerung in ein, an sich, gut funktionierendes System bringen. Dazu gehören z.B. auch Genehmigungen von vielbeschäftigten Linemanagern.

Das bedeutet nicht, dass wir keine Qualitätskontrolle oder Gates benötigen. Ganz im Gegenteil. Die Kontrollen sollten alle stattfinden, aber so weit es geht automatisiert sein, um schnell Feedback zu kommen. Hier kommen Techniken, wie CI/CD-Pipelines ins Spiel, da diese helfen möglichst viel zu automatisieren und dadurch sehr schnell Feedback liefern.

Wenn du mehr zum Thema CI/CD-Pipelines wissen willst schau unbedingt hier vorbei!

Fazit

Das Ziel des zweiten Prinzips von DevOps ist es Feedback-Schleifen im gesamten Systems zu etablieren und zu  verbessern. Ziel ist es dabei diese so kurz und so früh einzubauen, wie nur möglich, sodass erst gar kein Technical Debt entsteht. Voraussetzung dafür ist, dass man möglichst viele dieser Schleifen automatisiert, indem man z.B. CI/CD-Pipelines einführt.

Der eindeutige Mehrwert dadurch ist, dass Fehler viel früher gefunden werden, bevor sie kritisch werden und dadurch auch viel einfacher zu lösen sind. Dies führt wiederum dazu, dass das Unternehmen qualitativ hochwertigere und innovativere Produkte ausliefern kann und damit auch mehr Wert für die Kunden schaffen kann, was direkt zu gesteigerten Gewinnen und mehr Kunden führt.

Voraussetzungen dafür sind aber ein Verständnis, auf allen Ebenen im Unternehmen, für DevOps, CI/CD-Pipelines, aber auch für eine Kultur, die Wert auf Psychological Safety legt.

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, wie Scrum und Kanban zusammen funktionieren und was das für Vorteile hat.

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