In diesem Video gehe ich im Detail auf Hypothesize ein, den ersten Prozessschritt des SAFe DevOps Health Radar und der Continuous Delivery Pipeline. Die zentrale Frage ist einfach: Woher wissen wir, dass wir das Richtige bauen?
Der SAFe DevOps Health Radar als Prozess#
Der SAFe DevOps Health Radar ist nicht nur ein Assessment-Tool. Er ist auch ein Prozess, der beim Kunden beginnt und beim Kunden endet. Der Prozess umfasst die vier Dimensionen der Continuous Delivery Pipeline: Continuous Exploration, Continuous Integration, Continuous Deployment und Release on Demand. Hypothesize ist der allererste Schritt in dieser Pipeline.
Warum Epics und nicht Projekte#
Ein zentrales Konzept im Hypothesize-Schritt ist das Epic. Ein Epic unterscheidet sich grundlegend von einem Projekt:
- Epic: Ein Container für eine bedeutende Initiative. Man definiert eine Hypothese dahinter und baut dann ein MVP, um diese Hypothese zu validieren.
- Projekt: Hat einen klaren Start und ein klares Ende, ein festes Budget, einen Zeitplan und einen definierten Satz an Anforderungen oder Aufgaben.
Das Problem mit Projekten ist, dass sie davon ausgehen, man wisse bereits, was gebaut werden soll. Epics hingegen akzeptieren Unsicherheit und bieten einen Mechanismus, um zu testen, ob eine Idee tatsächlich Wert liefert, bevor man sich auf eine vollständige Umsetzung festlegt.
Das Epic Hypothesis Statement#
Um ein Epic sauber zu definieren, erstellt man ein Epic Hypothesis Statement. Dieses Dokument beschreibt:
- Den Kunden: Für wen bauen wir das? (Interne oder externe Kunden)
- Das Problem: Was möchte der Kunde tun?
- Die Lösung: Was werden wir bauen?
- Das Business Outcome: Was wollen wir wirklich erreichen?
- Die Leading Indicators: Wie messen wir den Erfolg frühzeitig?
- Die Non-Functional Requirements: Welche Rahmenbedingungen gelten?
Die Erstellung dieses Statements dauert etwa ein bis zwei Stunden. Es zwingt das Team, klar darüber nachzudenken, was es erreichen will, bevor eine einzige Zeile Code geschrieben wird.
Der Lean Business Case#
Nach dem Epic Hypothesis Statement folgt der Lean Business Case. Das ist ein zweiseitiges Dokument, das definiert:
- Was das MVP ist und wie die vollständige Lösung aussehen könnte
- Was das MVP kosten wird und was die vollständige Umsetzung kosten wird
Die Erstellung des Lean Business Case dauert etwa zwei bis vier Stunden. Er liefert gerade genug Information für eine gute Investitionsentscheidung, ohne monatelange Vorausplanung.
Der Lean Startup Cycle#
Mit dem definierten MVP treten Teams in den Lean Startup Cycle ein:
- Build: Das MVP bauen
- Evaluate: Die Hypothese anhand der Leading Indicators bewerten
- Decide: Wenn die Hypothese bestätigt wird, mehr investieren und weitere Features bauen. Wenn sie widerlegt wird, einen Pivot machen. Das bedeutet entweder, komplett aufzuhören, oder ein neues Epic mit einer neuen Hypothese zu erstellen und den Zyklus erneut zu durchlaufen.
Leading Indicators und Vanity Metrics#
Leading Indicators sind Metriken, die frühzeitig messen, ob man das Richtige baut und ob es die gewünschte Wirkung hat. Sie müssen schnell messbar sein, nicht erst in sechs Monaten oder einem Jahr.
Vorsicht bei Vanity Metrics. Das sind Metriken, die beeindruckend aussehen, aber den tatsächlichen Business-Wert nicht wirklich messen. Beispiele sind die Anzahl der Downloads oder die Anzahl der Nutzer. Diese Zahlen können steigen, während der eigentliche Geschäftswert stagniert. Vanity Metrics können sich zudem je nach Kontext verändern. Daher sollte man immer prüfen, was eine Metrik wirklich aussagt.
Die Reifegrade#
Der SAFe DevOps Health Radar bietet ein Self-Assessment für Hypothesize mit fünf Reifegraden:
- Sit: Ideen sind nur vage und nicht definiert.
- Crawl: Ideen sind definiert (zum Beispiel als Epic), enthalten aber kein Hypothesis Statement.
- Walk: Einige Ideen sind als Hypothesis Statements mit messbaren Ergebnissen formuliert.
- Run: Die meisten Ideen sind als Hypothesis Statements mit messbaren Ergebnissen formuliert und beinhalten MVPs.
- Fly: Alle Ideen sind als Hypothesis Statements mit messbaren Ergebnissen formuliert und beinhalten MVPs.
Kernaussagen#
- Validieren vor dem Bauen. Der Zweck von Hypothesize ist sicherzustellen, dass man das Richtige baut, indem man eine Hypothese definiert und testet, bevor Ressourcen eingesetzt werden.
- Epics statt Projekte verwenden. Epics akzeptieren Unsicherheit und ermöglichen die Validierung von Ideen durch MVPs. Projekte setzen voraus, dass man die Antwort bereits kennt.
- Das Epic Hypothesis Statement ist schnell erstellt. In ein bis zwei Stunden definiert man Kunde, Problem, Lösung, Business Outcome und Leading Indicators.
- Leading Indicators messen frühzeitig den Erfolg. Sie zeigen schnell, ob die Hypothese stimmt, sodass man investieren oder pivotieren kann, ohne Monate zu verlieren.
- Vorsicht vor Vanity Metrics. Metriken wie Download-Zahlen können gut aussehen, ohne den tatsächlichen Geschäftswert widerzuspiegeln. Immer prüfen, was eine Metrik wirklich misst.
- Reifegrade von Sit bis Fly. Teams können sich selbst bewerten und ein klares Ziel setzen, wie konsequent sie ihre Ideen validieren wollen.