Der "First Way of DevOps"

Autor: Oliver Hankeln

Datum:

Schaut Euch Eure gesamte Wertschöpfungskette an und identifiziert das schwächste Glied. Dieses hat höchste Priorität. Entlastet und verbessert es. Messt, welche Effekte Eure Veränderungen haben. Fangt wieder von vorne an.

Einleitung

Gene Kim beschreibt in seinem Buch “The Phoenix Project” drei Wege von DevOps. Diese drei Wege beschreiben die Prinzipien, auf denen DevOps aufbaut. Sie bestehen aus den Werten und Ideen der Prozesse und Praktiken von DevOps.

In dieser Artikelserie wollen wir uns diese drei Wege näher ansehen.

Der erste Weg

Der erste Weg wird “Improve flow from left to right” genannt. Wir verbessern also den Arbeitsfluss von links nach rechts. Links und Rechts sind dabei natürlich nicht räumlich gemeint, sondern beschreiben den Fluss von Arbeit oder Ideen durch die Wertschöpfungskette. Wenn wir eine solche aufmalen, dann wird der Start - die Idee - meist links aufgeschrieben. Das Endergebnis, zum Beispiel laufende Software, wird meist rechts angebracht. Damit folgt eine solche Visualisierung der üblichen Leserichtung. Genau das ist auch mit “links” und “rechts” beim ersten Weg gemeint: Der Fluss von Ideen zu fertigen Produkten soll verbessert werden.

Was heisst das jetzt konkret?

Die drei Wege sind keine konkreten Handlungsanweisungen, denen man einfach folgt, um erfolgreich zu sein. Vielmehr sind es grundlegende Ansätze, wie wir unsere Organisation betrachten und verbessern. Dies ist eine große Stärke und hilft dabei, mechanisches DevOps zu verhindern, bei dem an zu Grunde liegenden Problemen nicht gearbeitet wird, sondern an einfach zu ändernden Symptomen. Ein negativer Nebeneffekt ist allerdings, dass wir selbst nachdenken müssen, wie wir die drei Wege konkret mit Leben füllen können.

Und was nutzt das dann?

Der erste Weg will den Fokus weg von den einzelnen Arbeitsschritten hin zur systemischen Sicht auf die Wertschöpfungskette verschieben. Die Frage, die wir beantworten wollen, lautet nicht mehr: “Wie kann meine Software-Entwicklung schneller Software bauen?” Stattdessen sehen wir uns zuerst einmal an, wo in unserer Wertschöpfungskette der Bottleneck oder Flaschenhals liegt. Der Durchsatz des Bottlenecks ist der einzige Faktor, der den Durchfluss durch das Gesamtsystem bestimmt. Alle Energie, die wir darauf verwenden, etwas Anderes als den Flaschenhals zu verbessern, ist verschwendet.

Wenn in einer Automobilfabrik die Karosseriebauer 20 Karosserien am Tag zusammenschweissen können, die Lackierer 15 Autos lackieren können und die Innenausbauer 25 Autos ausstatten, dann werden 15 Autos am Tag fertig. Eine Verbesserung, die dazu führt, dass plötzlich 30 Karosserien gefertigt werden können, hat keinerlei Einfluss auf das Ergebnis der Fabrik. Diese systemische Sichtweise hilft uns also, zu entscheiden, wohin wir schauen müssen - im Beispiel lohnt es sich auch, den Innenausbau zu verändern, so dass zwar die Arbeit der Innenausbauer etwas langsamer wird, aber die Lackierer ihren Job schneller machen können. Vielleicht können z.B. die Innenausbauer die Abdeckungen aus der Lackiererei entfernen und nicht mehr die Lackierer.

Ausserdem erkennen wir, dass Produktion auf Halde keinen Mehrwert liefert. Wenn die Karroseriebauer wirklich 30 Karosserien am Tag bauen, werden wir plötzlich Geld für das Lagern immer größerer Mengen vorproduzierter Karosserien brauchen, ohne, dass die Fabrik mehr Output liefern würde. Eine lokale Optimerung bei den Schweissern hätte damit eine globale Deoptimierung zur Folge.

Der größte Teil der Durchlaufzeit von Arbeit besteht aus Wartezeiten. Oft lassen sich Flaschenhälse erweitern, indem man unnötige Wartezeiten eliminiert oder zumindest reduziert. Wartezeiten entstehen oft, wenn auf Freigaben und Abnahmen gewartet werden muss. Automatisierte Freigabeprozesse können hier helfen.

Um zu erkennen, wo im System Bottlenecks sind, ist es eine gute Idee, Durchlaufzeiten und Abflugraten (Anzahl der Fertigstellungen pro Zeit) zu messen. Damit können wir auch überprüfen, ob unsere Verbesserungen tatsächlich greifen oder nicht.

Hiermit kommen wir noch einmal zurück zum Anfang: was genau in Eurer Organisation die Bottlenecks sind und wie sich diese entlasten oder verbessern lassen, ist zu individuell, um Patentrezepte geben zu können. Die systemische Sicht auf das große Ganze ist es aber, die Euch weiterhilft und nicht der Fokus auf kleine Teile.

Zum Begriff Bottleneck

In einem Team, das ich einmal geführt habe, kam großer Unmut auf, als das Team als Bottleneck bezeichnet wurde. Zum damaligen Zeitpunkt war das aber unbestreitbar wahr. Der Begriff wurde aber vom Team als Wertung ihrer Arbeit missverstanden. Der Begriff Bottleneck ist keine moralische Wertung, sondern die Feststellung, dass an einer bestimmten Stelle im System die niedrigste Durchsatzkapazität vorhanden ist. In jedem System ist immer zwingend ein Bottleneck enthalten. Käme ein neuer Wunderlack auf den Markt, der es den Lackierern erlaubt, 50 Autos am Tag zu lackieren, so wären plötzlich die Innenausbauer der Flaschenhals (und die Lackierer müssten die Abdeckungen wieder selbst entfernen).