Der erste Weg, DevOps einzuführen, besteht darin, den Value Flow von Development über Operations bis zum Kunden zu optimieren. Das ist der First Way im Three-Ways-Framework von Gene Kim — und genau dort sollte jede Transformation starten.
Wert entsteht beim Kunden#
Diese Erkenntnis muss sitzen: Wert entsteht erst, wenn der Kunde das Feature nutzen kann. Code auf einem Entwickler-Laptop ist kein Wert. Ein gemergter Pull Request ist kein Wert. Ein Binary in der Artifact Registry ist kein Wert. Die ganze Strecke von “wir hatten eine Idee” bis “der Kunde nutzt sie” ist der Value Flow — und das Ziel des First Way ist, diesen Flow so schnell und vorhersehbar wie möglich zu machen.
Braucht ein Feature sechs Monate für diese Strecke, hast du ein Flow-Problem. Die Lösung ist nicht, die Entwickler härter rangzunehmen. Die Lösung ist, die gesamte Pipeline anzuschauen — Handoffs, Queues, Approvals, Environment Provisioning, Deployments — und alles zu entfernen, was den Flow bremst.
Arbeit sichtbar machen#
Was du nicht siehst, kannst du nicht verbessern. Der erste konkrete Schritt: Mach die Arbeit über den gesamten Value Stream sichtbar. Jedes Stück Arbeit, in jedem Schritt, auf einem Board, das alle sehen. Nicht nur Dev-Tickets — auch Ops-Tickets, Deployment-Requests, Change-Approvals, Security-Reviews. In dem Moment, in dem alles an einem Ort sichtbar ist, werden die Bottlenecks offensichtlich. Es gibt immer eine Spalte, in der sich Karten stapeln.
Hier beginnt auch der Kulturwandel. Wenn Dev und Ops dasselbe Board sehen, hören sie auf, ihre lokale Queue zu optimieren, und denken anfangen, in Systemen zu denken.
Batch Size verkleinern#
Grosse Batches sind langsame Batches. Ein Release, das 80 Features bündelt, dauert länger im Test, länger im Deployment, länger im Debugging, wenn etwas schiefgeht — und länger im Rollback. Ein Release mit einem Feature ist auf jeder dieser Dimensionen schnell.
Die Batch Size zu verkleinern ist der mit Abstand wirkungsvollste Flow-Hebel, den du hast. Kleinere Commits, kleinere Pull Requests, kleinere Deployments, kleinere Releases. Mit sinkender Batch Size sinkt die Lead Time, steigt die Qualität und steigt das Vertrauen des Teams — weil jede Änderung klein genug ist, um durchdacht zu werden.
Arbeitsintervalle verkürzen#
Neben der Batch Size lohnt der Blick auf die Arbeitsintervalle. Wie oft deployst du? Wie oft releaset du? Wie oft läuft die Test Suite? Lautet die Antwort “wöchentlich” oder “monatlich”, ist jedes Intervall eine Warteschlange, in der Arbeit liegt. Kürzere Intervalle — tägliche Deployments, kontinuierliche Test-Runs, On-Demand-Releases — verwandeln diese Queues in Flow.
So wird Deployment zum Non-Event. Wenn du zehnmal am Tag deployst, ist Deployment Routine. Wenn du einmal im Quartal deployst, wird Deployment zur High-Stakes-Zeremonie mit War Room und Rollback-Plan.
Qualität an der Quelle#
Flow optimieren heisst nicht, Abkürzungen nehmen. Es heisst, Qualität dort einzubauen, wo sie hingehört — an der Quelle. Automatisierte Tests, Code Review, Static Analysis, Security Scans bei jedem Commit. Ein Defekt beim Commit zu erwischen kostet Minuten. Denselben Defekt in Produktion zu erwischen kostet Tage, plus Kundenkosten, plus Vertrauenskosten. Flow wird gerade deshalb schneller, weil Qualität von Anfang an drin ist, nicht am Ende drangeflanscht.
Key Takeaways#
- Wert entsteht beim Kunden, nicht im Repo. Optimiere die gesamte Strecke von der Idee bis zur Kundennutzung.
- Arbeit über den gesamten Value Stream sichtbar machen. Bottlenecks bleiben verborgen, bis alles auf einem Board steht.
- Batch Size aggressiv verkleinern. Kleinere Commits, kleinere Deployments, kleinere Releases — jede Dimension gewinnt.
- Intervalle verkürzen. Häufige Deployments machen Deployment zur Routine. Seltene Deployments machen es gefährlich.
- Qualität an der Quelle einbauen. Schnellerer Flow funktioniert nur, wenn Defekte nicht mitfliessen.
- Der First Way bereitet den Second vor. Sinnvolles Feedback (Second Way) gibt es erst, wenn Wert tatsächlich fliesst.