DORA-Metriken: was Entwicklungszyklen wirklich verkürzt

In fast jedem Delivery-Review, in das ich als Berater komme, liegt zuerst eine Velocity-Kurve auf dem Tisch. Story Points pro Sprint, ein Burndown, vielleicht ein Trend nach oben. Und dann die Frage, warum trotz "grüner" Velocity die Releases zäh sind, Hotfixes sich stauen und niemand sich traut, freitags zu deployen. Meine Antwort ist meist unbequem: Velocity misst, wie viel ein Team von sich behauptet – nicht, wie schnell eine Änderung tatsächlich sicher in Produktion kommt. Wer wissen will, wo der Entwicklungszyklus wirklich klemmt, braucht andere Zahlen.

Genau dafür gibt es die vier DORA-Keys. Sie stammen aus der DevOps-Research-and-Assessment-Arbeit rund um Nicole Forsgren, Jez Humble und Gene Kim, im Buch Accelerate (2018) statistisch unterfüttert und seither jährlich im State of DevOps Report fortgeschrieben. Ich benutze sie seit Jahren nicht als KPI-Dashboard fürs Management, sondern als Diagnosewerkzeug. In diesem Artikel zeige ich, warum die vier Kennzahlen ehrliche Hebel sind, wo sie den Engpass sichtbar machen und wie man sie so verdrahtet, dass sie den Zyklus verkürzen statt ihn zu einem neuen Zahlenspiel zu machen.

Zwei Achsen statt einer Zahl

Der erste Denkfehler ist, Delivery-Performance als eine einzige Größe zu behandeln. Die vier Keys spannen bewusst zwei Achsen auf.

Auf der Throughput-Achse liegen Deployment Frequency – wie oft geht Code in Produktion – und Lead Time for Changes – wie lange dauert es vom Commit bis zum erfolgreichen Deploy. Das ist die Tempo-Seite: kleine Batches, kurze Wege.

Auf der Stability-Achse liegen Change Failure Rate – welcher Anteil der Deploys eine Störung oder einen Rollback auslöst – und Time to Restore Service – wie schnell ein Ausfall behoben ist. Das ist die Seite der Robustheit: wie teuer ein Fehler wird.

Die zentrale, kontraintuitive Erkenntnis aus Accelerate: Diese beiden Achsen stehen nicht im Gegensatz. Die Daten zeigen, dass Elite-Teams auf beiden gleichzeitig gewinnen – häufiger deployen und seltener scheitern und schneller wieder online sind. Der alte Reflex "Wenn wir schneller liefern, sinkt die Qualität" ist empirisch widerlegt. Genau deshalb ist es fahrlässig, nur zwei der vier Metriken zu messen. Wer allein Deploy-Frequenz und Lead Time trackt, optimiert Tempo und blendet die Stabilität aus – und produziert exakt die Vanity-Illusion, gegen die die DORA-Keys eigentlich antreten.

quadrantChart
  title Throughput vs. Stability
  x-axis Low Throughput --> High Throughput
  y-axis Low Stability --> High Stability
  quadrant-1 Elite
  quadrant-2 Slow but Safe
  quadrant-3 Low Performer
  quadrant-4 Fragile Speed
  Elite Team: [0.85, 0.85]
  Big-Batch Team: [0.2, 0.6]
  Move-Fast-Break-Things: [0.8, 0.25]
  Stuck Team: [0.2, 0.2]

Die Matrix macht klar: Das Ziel ist rechts oben, nicht ein Kompromiss auf der Diagonale. Und sie erklärt, warum eine einzelne Zahl in die Irre führt – ein Team im Quadranten "Fragile Speed" sieht auf einer reinen Tempo-Metrik glänzend aus und brennt trotzdem.

Wo der Zyklus klemmt

Der eigentliche Wert der Keys liegt nicht im Benchmark, sondern in der Lokalisierung. Jede Metrik hängt an einem anderen Segment der Wertschöpfungskette vom Commit bis zur Produktion – und zeigt damit, an welcher Stelle es hakt.

flowchart LR
  A[Commit] --> B[CI Build]
  B --> C[Test]
  C --> D[Deploy Gate]
  D --> E[Production]
  E -->|Incident| F[Restore]
  F --> E
  A -. Lead Time for Changes .-> E
  D -. Deployment Frequency .-> E
  E -. Change Failure Rate .-> F
  F -. Time to Restore Service .-> E
  style D fill:#e8543f,color:#fff

Ein Beispiel aus der Praxis: Ein Team klagt über "langsame Releases". Die Lead Time liegt im Median bei elf Tagen. Zerlegt man sie, stecken davon neun Tage zwischen "Feature fertig" und "Deploy Gate" – die Pipeline und der manuelle Freigabeschritt sind der Engpass, nicht das Programmieren. Ein anderes Team hat eine gute Lead Time, aber eine Change Failure Rate von 30 Prozent und eine Restore-Zeit von Stunden: Hier ist nicht das Tempo das Problem, sondern die Umkehrbarkeit von Änderungen. Dieselben vier Zahlen, völlig unterschiedliche Therapie. Eine aggregierte Velocity hätte in beiden Fällen nur "das Team ist ausgelastet" gesagt.

Lead Time for Changes ist dabei mein wichtigster Frühindikator. Sie ist definiert als die Zeit vom Code-Commit bis zum erfolgreichen Lauf in Produktion und korreliert eng mit der Batch-Größe. Große Batches verlängern das Feedback, erhöhen das Fehlerrisiko und machen jedes Deployment zum Event – ein Argument, das Donald Reinertsen und Jez Humble seit Jahren machen und das Accelerate mit Daten belegt. Kurze Lead Time zwingt fast automatisch zu kleinen, kontinuierlichen Änderungen.

Change Failure Rate und Restore-Zeit sind gekoppelt

Ein verbreitetes Missverständnis ist, Stabilität heiße "keine Fehler". Das ist nicht die Aussage der DORA-Daten. Die Kopplung aus Change Failure Rate und Time to Restore Service sagt etwas Feineres: Nicht die Abwesenheit von Fehlern zählt, sondern deren Preis. Hohe Deploy-Frequenz plus niedrige Change Failure Rate plus kurze Restore-Zeit bedeutet, dass Änderungen klein und umkehrbar sind. Ein Fehler, den ich in Minuten zurückrolle, ist billig. Ein Zero-Defect-Anspruch, der jeden Release zur Zitterpartie macht, ist teuer – gerade weil er selten geübtes, riskantes Deployen erzwingt.

Deshalb schlägt eine kurze Restore-Zeit in der Praxis den Anspruch auf Fehlerfreiheit. Und deshalb gehören die Nachbar-Techniken hier direkt dazu: Feature Flags, um Änderungen ohne Deploy scharf oder wieder unscharf zu schalten; Canary- und Blue-Green-Releases, um Blast-Radius zu begrenzen; Circuit Breaker und Bulkheads aus Michael Nygards Release It!, um Ausfälle einzudämmen. Das sind keine Buzzwords, sondern die konkreten Hebel, mit denen man Change Failure Rate senkt und Restore-Zeit verkürzt.

Im Code sieht die Kopplung von umkehrbarem Rollout und automatischem Recovery zum Beispiel so aus:

// Canary rollout gated by the live error rate.
// Ties Change Failure Rate and Time to Restore together in one control loop.
interface RolloutConfig {
  canaryPercentage: number;
  maxErrorRate: number;      // e.g. 0.02 -> roll back above 2%
  observationWindowMs: number;
}

async function progressiveRollout(
  release: Release,
  config: RolloutConfig,
): Promise<RolloutResult> {
  await featureFlags.enableForCohort(release.id, config.canaryPercentage);

  const errorRate = await metrics.observeErrorRate(
    release.id,
    config.observationWindowMs,
  );

  if (errorRate > config.maxErrorRate) {
    await featureFlags.disable(release.id); // instant, no redeploy
    return { status: "rolled_back", observedErrorRate: errorRate };
  }

  await featureFlags.enableForCohort(release.id, 100);
  return { status: "promoted", observedErrorRate: errorRate };
}

Der Punkt ist nicht die konkrete Bibliothek, sondern das Prinzip: Recovery passiert per Flag-Toggle in Sekunden, nicht per Notfall-Deploy. Genau das drückt sich später in einer niedrigen Restore-Zeit aus.

Die Metriken messen, ohne sie zu erfinden

Damit die Keys ehrlich bleiben, müssen sie aus Systemen kommen, die man nicht von Hand pflegt. Lead Time zum Beispiel lässt sich vollständig aus zwei Quellen ableiten: dem Commit-Timestamp im Versionskontrollsystem und dem Deploy-Event der CD-Pipeline. Keine Schätzung, keine Selbstauskunft.

// Lead Time for Changes, derived from VCS + deploy events.
// leadTime = deployedAt(prodDeployment) - firstCommitTime(changeSet)
function leadTimeForChange(deployment: ProdDeployment): number {
  const firstCommit = deployment.changeSet
    .map((commit) => commit.authoredAt.getTime())
    .reduce((min, t) => Math.min(min, t), Infinity);

  return deployment.deployedAt.getTime() - firstCommit;
}

// Aggregate as a median over a rolling window -- means get skewed by outliers.
function medianLeadTime(deployments: ProdDeployment[]): number {
  const values = deployments.map(leadTimeForChange).sort((a, b) => a - b);
  const mid = Math.floor(values.length / 2);
  return values.length % 2 === 0
    ? (values[mid - 1] + values[mid]) / 2
    : values[mid];
}

Zwei Details sind wichtig. Erstens der Median statt des Mittelwerts – ein einzelner liegengebliebener Branch würde jeden Durchschnitt ruinieren. Zweitens das rollierende Zeitfenster: Die Zahl ist ein Trend, kein Tagestreffer.

Noch wirksamer wird das Ganze, wenn man eine Metrik nicht nur anzeigt, sondern in die Pipeline zurückkoppelt. Neal Ford, Rebecca Parsons und Patrick Kua nennen das in Building Evolutionary Architecture eine Fitness Function – eine ausführbare Regel, die eine Architektur-Eigenschaft überprüfbar macht. Eine DORA-Fitness-Function kann die Pipeline rot färben, wenn die Change Failure Rate über der Schwelle liegt:

# Executable fitness function: assert a DORA metric as a CI gate.
def assert_change_failure_rate(window_days: int = 30, threshold: float = 0.15):
    deployments = metrics_db.query_deployments(window_days)
    failed = [d for d in deployments if d.caused_incident or d.rolled_back]

    if not deployments:
        return  # nothing to assert yet

    change_failure_rate = len(failed) / len(deployments)
    assert change_failure_rate < threshold, (
        f"Change Failure Rate {change_failure_rate:.0%} "
        f"exceeds threshold {threshold:.0%} over {window_days}d"
    )

So verbindet sich DORA mit der Idee der evolutionären Architektur: Die Metrik ist keine Folie fürs Quartalsmeeting mehr, sondern eine Bedingung, die das System an sich selbst stellt.

Der Fallstrick: Metriken als Ziel

Und damit zur wichtigsten Warnung, die ich in jedem Engagement wiederhole. Sobald eine Metrik zum Ziel wird, hört sie auf, ein gutes Maß zu sein – Goodhart's Law in Reinform. Deployment Frequency lässt sich mit trivialen Leer-Deploys aufblähen. Change Failure Rate lässt sich schönen, indem man "Failure" so lange umdefiniert, bis kaum noch etwas hineinfällt. Wer die Keys als Team-Ranking oder Bonus-KPI benutzt, bekommt genau dieses Gaming – und DORA selbst warnt ausdrücklich davor, Teams damit zu vergleichen. Die vier Zahlen sind Diagnose, nicht Wettbewerb.

Zwei weitere Verwechslungen sehe ich häufig. Erstens: Die Keys sind kein Ersatz für Story-Point-Velocity im Sinne von "gleiche Sache, bessere Zahlen". Es ist ein anderes Konstrukt – Velocity misst den Output eines einzelnen Teams und ist weder vergleichbar noch fälschungssicher; die Keys messen den Fluss vom Commit bis Produktion über das ganze Delivery-System. Zweitens: Schnelle Deploys ohne Wirkung sind "faster to nowhere". Deshalb hat DORA in den Reports 2021 und 2022 eine fünfte Dimension ergänzt, die Reliability beziehungsweise operative Performance. Die Aussage von 2022: Hohe Delivery-Performance zahlt nur dann auf den Organisationserfolg ein, wenn auch die Zuverlässigkeit im Betrieb stimmt. Ich behandle Reliability bewusst als jüngere, weichere Ergänzung – nicht als fünften, gleichrangigen Kanon. Aber der Gedanke gehört ins "ehrlich statt Vanity"-Framing: Tempo ohne Betriebsstabilität ist eine Vanity-Metrik mit besserem Marketing.

Fazit

Der rote Faden ist einfach. Velocity misst, was ein Team von sich behauptet. Die vier DORA-Keys messen, was tatsächlich passiert – vom Commit bis Produktion und zurück, wenn es kracht. Sie tun das auf zwei Achsen, Tempo und Stabilität, und die Kernaussage von Accelerate ist, dass diese Achsen kein Tradeoff sind: Die guten Teams gewinnen auf beiden.

Praktisch nutze ich die Keys als Suchscheinwerfer. Lange Lead Time zeigt große Batches oder eine verstopfte Pipeline. Hohe Change Failure Rate zeigt fehlende Umkehrbarkeit. Lange Restore-Zeit zeigt, dass Recovery nicht geübt ist. Jede Zahl deutet auf eine konkrete, technische Gegenmaßnahme – kleine Batches, Trunk-Based Development, Feature Flags, Canary-Releases, Circuit Breaker. Das ist der Unterschied zwischen einer Metrik, die den Zyklus verkürzt, und einer, die nur ein Dashboard füllt.

Und die Disziplin dabei: Die Keys diagnostizieren, sie belohnen nicht. In dem Moment, in dem sie zum Ziel werden, verlieren sie ihren Wert. Wer das aushält – Zahlen anschauen, ohne sie zu jagen – bekommt etwas Seltenes: einen ehrlichen Blick darauf, wo der eigene Zyklus wirklich klemmt.