Das erste Prinzip von DevOps (First way of DevOps) || DevOps Series – Episode 4

In diesem Artikel erklären wir das erste Prinzip von DevOps (First way of DevOps). Es geht also darum, wie man den Fluss (Flow) von den Entwicklern zu den Operations-Leuten versteht und verbessert. Dazu werden wir auch über die Theory of Constraints sprechen, zu der wir aber natürlich auch noch einen ausführlichen Artikel veröffentlichen werden. Zunächst sprechen wir aber über die Wall of Confusion, um zu erklären, wo die Probleme eigentlich herkommen.

In der letzten Folge haben wir die wichtigsten Tipps, Links, Bücher, Fragen und Beispielquiz für die Professional Scrum Master 2 (PSM2) Prüfung von scrum.org vorgestellt für dich, dass du diese wichtige Prüfung erfolgreich meistern kannst.

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

Die Wall of Confusion:

Um zu verstehen, wie viel der Probleme in der IT beim Entwickeln und Bereitstellen von Software entstehen, müssen wir uns zunächst einmal die sogenannte Wall of Confusion anschauen.

Wann immer wir Software entwickeln und dann betreiben (z.B. Software as a Service; SaaS) gibt es häufig zwei unterschiedliche Interessengruppen (um nicht Silos zu sagen 😛 ) in einem Unternehmen.

Auf der einen Seite gibt es natürlich die Entwickler, die die neue Software schreiben und neue Features entwickeln müssen, um konkurrenzfähig zu bleiben. Das heißt die Entwickler wollen natürlich Veränderung, da sie sonst nichts weiterentwickeln können und dem Kunden Mehrwert liefern können.

Dem gegenüber stehen die Operationsteams, die dafür sorgen müssen, dass die Software/Anwendung für den Nutzer so stabil und problemlos läuft wie nur möglich. Das heißt sie wollen Stabilität und möglichst keine Veränderung, da Veränderung ja wieder ein erhöhtes Risiko für Ausfälle, Bugs, Rollbacks, etc bedeutet.

Es gibt hier also einen ganz eindeutigen Interessenskonflikt zwischen den beiden Parteien. Die Entwickler schreiben neue Features und werfen diese dann einfach über die Mauer, während eines neuen Releases z.B., und die Operationsteams dürfen sich dann damit wieder „herumschlagen“. Da in den meisten Firmen (da sie noch kein DevOps Mindset haben) zwischen diesen beiden Parteien nur ein Austausch stattfindet, wenn es brennt bzw. die Operationsteams ein massives Problem haben (faktisch also 2 Silos) sind Probleme vorprogrammiert (Vorsicht der kommt flach 😀 ).

Die Wall of Confusion

Die Probleme die hierdurch entstehen sind z.B., dass die Operationsteams sich im neuen Code gar nicht auskennen und damit Probleme und Bugs viel schwieriger finden.

Nun wird das erste Prinzip von DevOps diese Probleme erstmal verstärken und damit nochmal deutlicher aufdecken. Erst das zweite Prinzip (der Artikel dazu erscheint am 16.5., also auf jeden Fall Newsletter, etc abonnieren 😉 ) bietet dann eine Lösung für diese Probleme. Nichtsdestotrotz ist das erste Prinzip extrem wichtig, da es die Probleme die wir haben erst aufdeckt und uns damit die Möglichkeit gibt das Problem überhaupt zu lösen. Denn diese Silo-Kultur beeinflusst den Fluss der Arbeit und verhindert damit die Möglichkeit kontinuierlich Innovationen zu liefern.

Allerdings hat es auch viele Vorteile, wenn wir den Fluss der Arbeit besser verstehen und verbessern. Kommen wir also zuerst einmal zum ersten Prinzip von DevOps.

Das erste Prinzip von DevOps

Hierbei geht es darum den Fluss (Flow) der Arbeit der Entwickler hin zu den Operationsteams so gut wie möglich zu verstehen. Nur so können wir können wir den Flow erhöhen, indem wir bestimmte Einschränkungen (Constraints) aus dem Weg schaffen.

Das erste Prinzip von DevOps

Hierbei ist es extrem wichtig, nicht den Flow eines Bereichs oder Silos nur zu betrachten, sondern des gesamten Systems. Dieses System kann dabei von einem einzelnen Entwickler bis hin zu einem gesamten Department reichen. Es geht dabei auch nicht nur um einen einzelnen Value Stream (Wertstrom), sondern um alle Wertströme, die von der IT ermöglicht werden. Und das von Anfang bis zum Ende. Also von der Idee bis zum Kunden.

Alle Wertströme des gesamten Systems müssen betrachtet werden.

Was bedeutet das nun in der Praxis?

Den Fluss der Arbeit verstehen:

In der Regel kommt neue Arbeit von der Business Seite in Form von Feature Requests (z.B. als User Story) und endet damit, dass das neue Feature sicher und zuverlässlich beim Kunde oder in Production ausgerollt wurde und stabil läuft. Allerdings kann Arbeit z.B. auch in Form von Defects, Bugs oder als Support für Deployments entstehen.

Egal woher die Arbeit kommt, sei es aus einem Feature Request, User Stories oder Bugs, sollte der Fluss sich, im Idealfall, niemals umkehren oder gar stillstehen. Dies sind klare Indikatoren für Probleme, die gelöst werden müssen.

Erhöhen des Flows:

Das Ziel hier ist es den Fluss im gesamten System (End-2-End) zu maximieren. Hierzu wurden viele verschiedene Möglichkeiten entwickelt, wie z.B. die Theory of Constraints, das Toyota Production System, Six Sigma oder Lean. Einige der wichtigsten Tools bzw. Techniken hieraus sind z.B. Reduzierung der parallel ausgeführten Aufgaben (Limiting Work in Progress (WIP)), kleinere Release (reducing batch size) oder das vermeiden von Verschwendungen (waste), wie z.B. Wartezeiten, Handovers,etc.

Gib niemals wissentlich einen bekannten Fehler weiter:

Um den Fluss zu maximieren und gleichzeitig Nacharbeiten zu minimieren, muss jeder einzelne darauf achten höchste Qualität von Anfang an zu leisten.

Commitment and build in Quality.

Dadurch wird, idealerweise, alle Arbeit nur einmal gemacht. Das bedeutet aber auch, dass die Nacharbeiten sichtbar und transparent gemacht werden müssen, nur so kann man Konsequenzen und damit Verbesserungen daraus ziehen, sodass dieses Problem nicht nochmal auftaucht.

Lokale Optimierung darf niemals zu globaler Verschlechterung führen:

Lokale Verbesserungen der Effektivität sind natürlich gut, aber dürfen niemals im Weg des größeren Ziels stehen oder gar verhindern, dass der Kunde bekommt, was er braucht. Hier kommt nochmal die Theory of Constraints von Dr. Eliyahu Goldratt zu tragen. Diese Konflikte auf Grund von lokaler Optimierung finden am häufigsten zwischen Abteilungen statt, also z.B. der Entwicklung und der IT Operations, kann aber auch oft innerhalb von Abteilungen stattfinden wie z.B. Release Management vs. Production.

Ein grundlegendes Verständnis für das System entwickeln:

In unserer heutigen Zeit ist es wichtiger denn je ein tiefes Verständnis des Systems zu haben, um zu verstehen, was der Grund für ein Problem war und kompetente Entscheidungen treffen zu können, die über das Fortbestehen der Firma entscheiden können.

A bad system will beat a good person every time. – W. Edwards Demming

Um dieses grundlegende Verständnis zu erlangen, muss man das Business Ziel kennen und verstehen. Man muss verstehen, wie Wert für den Kunden (intern oder extern) generiert wird und die Menschen, nötigen Prozesse (wie z.B. DevOps) und Technologien (z.B. CI/CD Pipelines) kennen.

Fazit

Das Ziel des ersten Prinzips von DevOps ist es den Fluss (Flow) des gesamten Systems zu verbessern. Hierzu ist ein grundlegendes Verständnis für das System, aber auch für die Methoden/Frameworks (DevOps, Lean, Agile) und die nötigen Prozesse und Technologien (CI-/ CD-Pipelines) nötig.

Der klare Mehrwert dadurch ist aber, dass die Mitarbeiter weniger Nacharbeiten machen müssen und weniger Bugs entstehen. 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.

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, die unterschiedlichen Frameworks zu Skalierung von Scrum. Also wie funktioniert LeSS, Nexus, Scrum of Scrums und SAFe.

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