Wenn du ein Entwicklungsteam fragst, wo Wert entsteht, bekommst du ein Dutzend unterschiedliche Antworten. Im Planning-Workshop. Im Sprint. Beim Demo. Beim Deployment. Sie liegen alle falsch — und genau dieser Denkfehler ist der Grund, warum die meisten DevOps-Business-Cases beim CFO auseinanderfallen.
Der Value Stream, Schritt für Schritt#
Jede Software beginnt als Idee. Die Idee wird zu einer User Story verfeinert. Die User Story wird entwickelt. Der Code wird gebaut und getestet. Das Artefakt wird in eine Umgebung deployed. Und irgendwann wird das Feature für einen Kunden released. Diese gesamte Kette — von der Idee bis zum Kunden — ist der Value Stream.
Dass es Stream heisst und nicht Prozess, ist kein Zufall. Ein Stream ist etwas, durch das Dinge fliessen. Die spannende Frage ist nicht “wie ausgelastet ist jede Stufe?”, sondern “wie schnell kommt eine Idee von der Quelle ins Meer?”. Lead Time — nicht Auslastung — ist die Kennzahl, die zählt.
Wo kein Wert entsteht#
Hier kommt der Teil, den die meisten Teams übersehen. Vom Moment, in dem eine Idee in den Value Stream eintritt, bis zu dem Moment, in dem sie den Kunden erreicht, entsteht kein Wert. Null. Nicht beim Grooming, nicht beim Coden, nicht beim Deployment auf Staging, nicht im Release-Queue. Diese Arbeit ist notwendig — aber sie ist Kosten, nicht Wert.
Wert entsteht an genau einem Punkt: wenn der Kunde das Feature tatsächlich nutzen kann. Bis dahin hast du Geld investiert. Bis dahin ist die Idee Inventar im Lager, das beim Warten an Wert verliert.
Warum dieses Umdenken etwas verändert#
Sobald du akzeptierst, dass Wert nur auf der Kundenseite entsteht, ändern sich zwei Dinge in der Art, wie du Engineering führst.
Erstens: Alles, was die Zeit zwischen “Idee” und “Kunde kann es nutzen” verkürzt, ist wertschöpfende Arbeit — auch wenn es sich nicht so anfühlt. Die Build-Pipeline verbessern, ein manuelles Approval-Gate entfernen, einen flaky Test rauswerfen — keines davon liefert Features, aber alle verkürzen die Lead Time. Es sind direkte Investitionen in Wert.
Zweitens: Alles, was diese Lücke vergrössert, vernichtet Wert — auch wenn es nach Fortschritt aussieht. Ein Drei-Monats-Release-Train. Eine Staging-Umgebung, die eine Woche zum Provisionieren braucht. Ein Change Advisory Board, das mittwochs tagt. Sie alle halten Ideen im Value Stream fest, wo sie Kosten erzeugen, ohne Wert zu erzeugen.
Der Test#
Hier ist ein einfacher Test für jede DevOps-Initiative: Bewegt sie Ideen schneller durch den Value Stream — oder macht sie einfach eine Stufe des Streams für die dort arbeitenden Menschen bequemer? Lokale Optimierungen, die die End-to-End-Lead-Time nicht verkürzen, sind eine Falle. Sie fühlen sich wie Verbesserungen an. Sie tauchen in Team-Metriken auf. Sie bewegen den Business Case nicht.
Genau deshalb ist DevOps keine Tool-Diskussion. Tools sind wichtig, aber nur als Mittel, um die Zeit zwischen Idee und Kunde zu komprimieren. Wenn ein neues Tool den Build schneller macht, die Änderung aber zwei Wochen auf ein Release-Fenster wartet, hast du den Value Stream nicht verbessert. Du hast einen Teil davon verbessert, der nicht der Bottleneck war.
Key Takeaways#
- Wert entsteht beim Kunden, nicht in der Entwicklung. Alles vor dem Release ist Investition, nicht Wert.
- Der Value Stream geht von der Idee bis zum released Feature. Es zählt die Lead Time über die gesamte Kette, nicht die Produktivität einer einzelnen Stufe.
- Arbeit, die Lead Time verkürzt, ist wertschöpfend. Pipeline-Verbesserungen und das Entfernen manueller Gates zählen — auch wenn sie kein neues Feature liefern.
- Lokale Optimierungen sind eine Falle. Eine Stufe zu beschleunigen, die nicht der Bottleneck ist, bewegt den Business Case nicht.
- DevOps ist eine Value-Stream-Diskussion, keine Tool-Diskussion. Tools zählen nur insoweit, als sie die Zeit von der Idee bis zum Kunden komprimieren.