Measure ist der Schritt des SAFe for DevOps Health Radar, in dem alles zusammenkommt. Nach dem Deployment in die Produktion und der Stabilisierung sammeln wir nun qualitative und quantitative Informationen über unsere Epics und Features. Das Ziel ist es, unsere Hypothesen zu validieren und fundierte strategische Entscheidungen zu treffen. In diesem Video erkläre ich, was der Measure-Schritt umfasst und warum er essenziell ist, um das Richtige zu bauen.
Der gesamte Weg zum Measure-Schritt#
Bevor wir zum Measure-Schritt gelangen, haben wir die gesamte Continuous Delivery Pipeline durchlaufen. Alles beginnt mit guten Ideen vom Kunden oder Business. Wir nehmen diese Ideen, fassen sie in Epics zusammen und identifizieren die echte Hypothese hinter jedem Epic mithilfe des Epic Hypothesis Statements.
Von dort aus forschen wir gemeinsam, um den echten Marktbedarf oder Kundenbedarf zu ermitteln. Dann entwerfen wir die minimale Architektur, die nötig ist, um die Hypothese zu beweisen. Im Synthesize-Schritt brechen wir das Epic in Features herunter, priorisieren sie auf einem Backlog, erstellen eine Roadmap und arbeiten unsere Vision aus.
Mit diesen Features gehen wir in die Entwicklung. Wir brechen Features in User Stories herunter, entwickeln sie, committen Quellcode in die Versionskontrolle und bauen deploybare Artefakte. Diese Artefakte werden End-to-End getestet und in eine Staging-Umgebung für die abschliessende Verifikation deployed. Dann deployen wir in die Produktion mit dem Feature Toggle ausgeschaltet.
Wir verifizieren mit einer Teilmenge der Tests, dass alles in der Produktion funktioniert, und monitoren das System kontinuierlich. Wenn etwas passiert, werden wir alarmiert und reagieren als ein Team. Wenn das Business sagt, der Zeitpunkt ist richtig, schalten wir den Feature Toggle ein, stabilisieren die Produktionsumgebung und prüfen, ob alles gemäss den SLAs funktioniert.
Jetzt betreten wir den Measure-Schritt.
Was im Measure-Schritt passiert#
Im Measure-Schritt sammeln wir sowohl qualitative als auch quantitative Informationen über unsere Epics und Features in der Produktion. Der Kernzweck ist es, den Geschäftswert hinter unseren Epics und Features zu identifizieren und die Hypothesen zu beweisen oder zu widerlegen, die wir ganz am Anfang aufgestellt haben.
Diese Daten ermöglichen es uns, fundierte strategische Entscheidungen zu treffen. Zum Beispiel können wir entscheiden, in bestimmte Epics oder Features nicht mehr zu investieren, oder wir bestätigen, dass eine Hypothese wahr ist, und entscheiden, mehr zu investieren.
Zurück zur Hypothese#
Im Hypothesize-Schritt haben wir Epics und ihre zugrunde liegenden Hypothesen mithilfe des Epic Hypothesis Statements definiert. Hinter jeder bedeutenden Initiative steht eine Hypothese, und mit dem Lean-Startup-Zyklus versuchen wir, das minimale brauchbare Produkt zu identifizieren, das wir bauen können, um zu beweisen, ob die Hypothese wahr oder falsch ist.
Der Schlüssel zu dieser Validierung sind die Leading Indicators. Mit Leading Indicators können wir identifizieren, ob wir das Richtige bauen. Um diese Indikatoren zu erfassen, nutzen wir die Application Telemetry, die wir in unsere Lösung eingebaut haben.
Natürlich müssen wir die Geschäftsergebnisse mit der Telemetrie korrelieren, um festzustellen, ob die Hypothese wahr oder falsch ist. Wichtig ist, auf Vanity Metrics zu achten. Die Anzahl der Downloads zum Beispiel könnte nicht die richtige Metrik oder der richtige Leading Indicator in Ihrem Fall sein. Was als Vanity Metric gilt, kann auch vom spezifischen Kontext abhängen, in dem man sich befindet.
Feature-Benefit-Hypothesen messen#
Wir messen nicht nur die Hypothese unserer Epics. Wir messen auch die Benefit Hypothesis unserer Features und Enabler Features. Im Synthesize-Schritt haben wir das Epic in Features heruntergebrochen. Jedes Feature hat einen Titel, eine Reihe von Akzeptanzkriterien und wichtige nicht-funktionale Anforderungen. Aber das Wichtigste an einem Feature ist die Benefit Hypothesis, und genau diese validieren wir im Measure-Schritt.
Die Reifegrade#
Der SAFe DevOps Health Radar bietet ein Reifegradmodell für den Measure-Schritt:
- Sit: Wir definieren oder messen den Wert von Features nicht.
- Crawl: Wir haben definiert, was “Wert” ist, wissen aber nicht, wie man ihn misst.
- Walk: Wir erfassen qualitatives Feedback vom Business über den Wert unserer Features.
- Run: Wir erfassen qualitatives und quantitatives Feedback vom Business und unseren Monitoring-Systemen über den Wert unserer Features.
- Fly: Wir aggregieren das quantitative und qualitative Feedback, um die ursprüngliche Hypothese objektiv zu validieren und Pivot-or-Persevere-Entscheidungen zu informieren.
Wo steht Ihr Team auf dieser Skala? Das Ziel ist, zu einem Zustand zu gelangen, in dem Daten Ihre Hypothesen objektiv validieren und direkt Ihre Investitionsentscheidungen informieren.
Tools für den Measure-Schritt#
Beim Blick auf die periodische Tabelle der DevOps-Tools fallen die relevanten Tools für den Measure-Schritt in die Kategorie AIOps und Analytics. Drei Beispiele:
- Matomo: Eine gute Wahl, wenn man sich in einer On-Premises-Umgebung befindet.
- Google Analytics: Eine weit verbreitete Option, wenn man in der Cloud ist.
- Dynatrace: Eine umfassende Observability-Plattform für Monitoring und Analytics.
Was der Measure-Schritt liefert#
Das Ergebnis des Measure-Schritts ist klar:
Validierte Hypothesen: Für Epics können wir feststellen, ob die Hypothese wahr oder falsch ist. Für Features prüfen wir, ob die Benefit Hypothesis erfüllt wurde.
Fundierte Entscheidungen: Mit qualitativen und quantitativen Daten können wir strategische Entscheidungen darüber treffen, wo wir mehr investieren, wo weniger, und wo wir ganz aufhören.
Identifikation des Geschäftswerts: Wir erhalten ein klares Bild davon, ob unsere Epics und Features den erwarteten Geschäftswert liefern.
Kernaussagen#
- Measure ist der Schritt, in dem alles zusammenkommt. Alle vorherigen Schritte des SAFe DevOps Health Radar führen zu diesem Punkt, an dem wir validieren, ob wir das Richtige gebaut haben.
- Sowohl qualitative als auch quantitative Daten sammeln. Beide Arten von Feedback sind nötig, um ein vollständiges Bild des gelieferten Werts von Features und Epics zu erhalten.
- Hypothesen mit Leading Indicators validieren. Application Telemetry nutzen und mit Geschäftsergebnissen korrelieren, um Hypothesen zu beweisen oder zu widerlegen.
- Auf Vanity Metrics achten. Nicht jede Metrik, die beeindruckend aussieht, ist wirklich aussagekräftig. Leading Indicators wählen, die den tatsächlichen Wert widerspiegeln, den man liefern möchte.
- Fundierte strategische Entscheidungen ermöglichen. Die Daten aus dem Measure-Schritt befähigen Teams und Führung, objektive, faktenbasierte Entscheidungen über Investitionen und Richtung zu treffen.
- Dieser Schritt führt in den Learn-Schritt. Die hier gesammelten Erkenntnisse fliessen direkt in den Learn-Schritt, wo Pivot-or-Persevere-Entscheidungen getroffen werden.