Eine Frage aus dem Bewerbungsgespräch: Wie viele Metriken hat DORA? Die Antwort „vier“ klingt sicher und ist seit 2025 falsch. Es sind fünf, eine der alten wurde umbenannt, die Stufen Elite bis Low sind abgeschafft, und DORA selbst steht für nichts mehr: Das Akronym wurde aufgelöst und der Jahresbericht von Accelerate State of DevOps in State of AI-assisted Software Development umbenannt.
Kosmetik ist davon nichts. Jede Änderung kommt genau von dort, wo Metriken Teams am häufigsten kaputtmachen.
Fünf Metriken statt vier
Die fünfte ist die Deployment Rework Rate: der Anteil der Deployments, die niemand geplant hat und die wegen eines Vorfalls in Produktion ausgerollt werden mussten. Sie erfasst, was den vier alten Metriken entging. Ein Team mit ordentlicher Release-Frequenz und niedriger Change Fail Rate kann die Hälfte seiner Rollouts damit verbringen, die Folgen der vorherigen aufzuräumen — nach den alten vier Metriken sieht dieses Team gesund aus.
MTTR ist als Bezeichnung verschwunden. An ihrer Stelle steht Failed Deployment Recovery Time: die Wiederherstellung nach einem Deployment, das sofortiges Eingreifen erforderte. Die Formulierung ist enger als zuvor — die Metrik spricht über ein Deployment, nicht über einen beliebigen Vorfall.
Dann folgt das Detail, an dem fast jede Nacherzählung scheitert. Die fünf Metriken teilen sich in zwei Gruppen, und die Aufteilung ist kontraintuitiv:
| Gruppe | Metriken |
|---|---|
| Throughput | change lead time, deployment frequency, failed deployment recovery time |
| Instability | change fail rate, deployment rework rate |
Die Wiederherstellungszeit liegt im Durchsatz, nicht in der Stabilität. Die Logik ist einfach: Einen Fix auszurollen heißt ebenfalls, eine Änderung durch das System zu bewegen, und das Tempo bestimmt dieselbe Pipeline. In der Instabilität bleiben zwei Metriken darüber, wie schlecht die Deployments selbst laufen. Die Wiederherstellungszeit senkt weniger ein eigener „Reaktionsprozess“ als das, was auch ein normales Release beschleunigt, plus die Fähigkeit, die Ursache schnell zu finden — zum Werkzeug dieser Suche gibt es eine eigene Analyse.
Die Stufen gibt es nicht mehr
Elite, High, Medium und Low sind Geschichte. Der Bericht 2025 — eine Clusteranalyse der Antworten von knapp fünftausend Menschen — ergab sieben Teamprofile, in denen Performance, Stabilität und das Befinden der Menschen ineinandergreifen. Am einen Ende stehen die „harmonious high-achievers“, stark bei der Auslieferung wie beim Wohlbefinden. Am anderen Teams mit „foundational challenges“ und solche, die im „legacy bottleneck“ feststecken, wo instabile Systeme an der Moral zehren.
Das neue Etikett ist nicht der Punkt. Die Schwellen der Stufen wurden jedes Jahr neu berechnet: „Elite“ von 2019 und „Elite“ von 2023 sind verschiedene Zahlen. Ein Team, das Jahr für Jahr „wir sind High“ meldete, verglich sich mit einem beweglichen Ziel. Jetzt gibt es kein Ziel, sondern ein Profil, in dem Burnout enthalten ist.
Wo Metriken ein Team kaputtmachen
DORA benennt zwei Wege, eine Messung zu ruinieren, und beide leben im typischen Plattform-Dashboard.
Der erste: die Metrik zum Ziel machen. Goodharts Gesetz greift zuverlässig — die Vorgabe „Deployment Frequency erhöhen“ kuriert man, indem man ein Release in fünf leere zerlegt. Die Zahl steigt, die Auslieferung bleibt, wie sie war. Der gesunde Weg läuft andersherum: den Preis eines Releases senken, damit die Frequenz von selbst steigt. Canary-Rollouts und atomare Deployments bewegen Frequenz und Change Fail Rate zugleich, weil sie die Mechanik ändern und nicht die Berichterstattung.
Der zweite: Unvergleichbares vergleichen. DORA empfiehlt, die Metriken auf eine einzelne Anwendung oder einen Service anzuwenden, und warnt vor Vergleichen zwischen Systemen unterschiedlicher Natur. Die Metriken mehrerer Teams in eine gemeinsame Rangliste zu gießen ist genau das, wofür ein Dashboard üblicherweise gebaut wird.
Daraus folgt die praktische Regel: Die fünf Metriken messen das Liefersystem, nicht die Menschen. Der Trend eines Teams über die Zeit ist eine gültige Anwendung. Eine Rangliste zwischen Teams nicht.
Wo SPACE hineinpasst
Das SPACE Framework (Forsgren, Storey, Maddila, Zimmermann, Houck, Butler; ACM Queue, Februar 2021) beantwortet eine andere Frage: nicht „wie schnell fährt das System“, sondern „wie erleben es die Menschen“. Fünf Dimensionen — Satisfaction, Performance, Activity, Communication, Efficiency & flow. Die zentrale These der Autoren: Produktivität lässt sich nicht auf eine Metrik reduzieren, es braucht mehrere Dimensionen gleichzeitig.
Die gefährlichste Dimension ist Activity. Commits, Pull Requests und Deployments lassen sich am leichtesten zählen und landen deshalb zuerst im Bericht nach oben. Aktivität ist Kontext, kein Ziel: „viele Commits“ heißt nicht „viel Wert“, und diese Zahl zu frisieren ist trivial.
Bis 2025 teilten sich die beiden Modelle die Arbeit: DORA maß die Ergebnisse der Auslieferung, SPACE das Befinden. Die Teamprofile haben diese Grenze gelöscht. Das Wohlbefinden liegt nun in demselben Modell, mit dem die Auslieferung gemessen wird.
Was mit den Zahlen aus den Präsentationen zu tun ist
„Elite-Teams deployen 208-mal häufiger und haben eine 106-mal kürzere Lead Time“ — die Zahlen sind echt, aus Accelerate State of DevOps 2019. Sie sind sieben Jahre alt, und die Cluster, die sie beschreiben, sind abgeschafft. Eine solche Zahl auf einer Folie von 2026 charakterisiert nicht die Branche, sondern das Jahr, in dem die Folie gebaut wurde.
Die Prüfung dauert fünf Minuten. Wenn eine Metrik im Dashboard MTTR heißt, wenn es vier Metriken sind und die Teams auf einer Skala von Elite bis Low einsortiert werden, dann wird nach einer Ausgabe gemessen, die die Autoren bereits ersetzt haben. Bezeichnungen zu korrigieren ist billig. Teurer ist es, sich die Gewohnheit abzugewöhnen, Teams miteinander zu vergleichen: Genau jene Tabelle hat sie hervorgebracht.