DORA-Metriken ohne Dashboard-Steuer

Alle wollen DORA. Fast niemand hat es.

Die vier DORA-Metriken sind Deployment-Frequenz, Lead Time für Änderungen, Change Failure Rate und Mean Time to Restore. Sie sind zum Goldstandard für die Messung der Software-Delivery-Performance geworden. Die Forschung ist überzeugend. Das Buch Accelerate steht im Regal jeder Engineering-Führungskraft. Der State of DevOps Report 2024 bestätigte erneut, dass Elite-Performer schneller mit weniger Fehlern ausliefern¹.

Und dennoch haben die meisten Teams immer noch kein DORA.

Nicht weil die Metriken schwer zu verstehen sind. Sondern weil das Tooling zu viel verlangt. Eigenständige DORA-Dashboards wollen, dass Sie einen neuen Anbieter einführen, Webhooks konfigurieren, Deployments taggen, Umgebungen definieren und eine weitere Integration pflegen. Die Setup-Kosten sind real. Die laufende Wartung ist real. Und das Ergebnis ist... vier Zahlen auf einem Bildschirm, die Sie einmal im Monat prüfen.

Das ist die Dashboard-Steuer. Sie zahlen mit Setup, Wartung und Kontextwechseln. Sie erhalten Instrumentierung, keine Erkenntnisse.

Das Problem: Vier Zahlen in Isolation

Hier ist, was die meisten DORA-Implementierungen falsch machen: Sie messen vier Zahlen isoliert.

Die Deployment-Frequenz liegt bei 3,2 pro Woche. Die Lead Time bei 4,1 Tagen. Die Change Failure Rate bei 8 %. Die MTTR bei 2,3 Stunden.

Und jetzt?

Diese Zahlen existieren im Vakuum. Sie sind nicht mit Ihrer Sprint-Arbeit verbunden. Sie korrelieren nicht mit der Effektivität Ihres Teams. Sie sagen Ihnen nicht warum die Lead Time gestiegen ist oder was den Anstieg der Fehlerrate verursacht hat. Sie sind Instrumentierung – rohe Messwerte ohne Interpretation.

Es ist wie ein Herzfrequenzmesser, der „72 bpm" anzeigt, aber nicht weiß, dass Sie auf einem Laufband sind. Die Zahl ist korrekt. Der Kontext fehlt.

Die Teams, die von DORA profitieren, sind nicht die mit den schicksten Dashboards. Es sind die, die Deployment-Daten mit dem größeren Bild verbinden: Wie verhält sich die Deployment-Frequenz zur geplanten Arbeit? Korreliert unsere Lead Time mit der Sprint-Vorhersagbarkeit? Wird unsere Change Failure Rate durch überstürzte Features oder Infrastruktur-Fragilität verursacht?

Diese Fragen erfordern Kontext, den ein eigenständiges DORA-Tool nicht hat.

Wie erhalten Sie DORA-Metriken aus Ihrer CI/CD-Pipeline?

Sie erhalten DORA-Metriken, indem Sie auf die Pipeline-Daten hören, die Ihr Team bereits generiert. GitHub Actions Workflow-Runs, GitLab-Pipelines, Bitbucket Pipelines – sie alle geben strukturierte Daten darüber aus, was gebaut, was deployed und was fehlgeschlagen ist. Normalisieren Sie das über Anbieter hinweg und die vier Metriken ergeben sich automatisch. Kein neuer Anbieter. Kein neuer Webhook. Kein neues Konfigurations-Ritual.

Wenn Sie Ihre Code-Repositories mit Simyl Flow verbinden, ziehen wir bereits Commits, Pull Requests und Review-Daten. Ihre CI/CD-Pipeline-Daten liegen direkt nebenan – dieselben APIs, dieselbe Authentifizierung, dieselbe Integration, die Sie bereits konfiguriert haben.

Also hören wir zu.

Die Setup-Kosten sind null. Wenn Sie GitHub verbunden haben, haben Sie bereits DORA. Wenn Sie GitLab verbunden haben, haben Sie bereits DORA. Die Pipeline-Daten fließen neben den Commit- und PR-Daten ein, die Sie bereits nutzen.

Das ist das „Workflow-Exhaust"-Prinzip: Ihre bestehenden Tools generieren bereits die Signale, die Sie brauchen. Das Problem war nie die Datenverfügbarkeit – es war, dass die Daten in Silos saßen, getrennt vom Kontext, der sie bedeutsam macht.

Die wahre Geschichte: DORA als Beleg für Effektivität

Hier wird es interessant. DORA-Metriken allein sind nützlich. DORA-Metriken, die mit dem Effektivitätsbild Ihres Teams verbunden sind, sind transformativ.

Wenn CI/CD-Daten in die Effektivitätsdimensionen von Simyl Flow einfließen, verwandelt sich subjektive Bewertung in datengestützte Narrative:

Deployment-Frequenz ist nicht nur eine Zahl – sie ist Beleg für die Lieferung-Dimension. Ein Team, das häufig mit stabiler Qualität deployed, demonstriert echten Durchsatz, nicht nur das Schließen von Tickets.

Change Failure Rate ist nicht nur eine Metrik – sie ist Signal für Qualität. Wenn wir niedrige Fehlerraten neben den Code-Review- und Bug-Daten sehen, die wir bereits tracken, wird der Qualität-Dimensionsscore präziser. Wenn Fehlerraten steigen, können wir das mit dem korrelieren, was sich im Sprint geändert hat – neue Mitwirkende, überstürzte Zeitpläne, Infrastruktur-Änderungen.

Lead Time für Änderungen verbindet sich mit Flow. Lange Lead Times korrelieren oft mit hohem WIP, großen Batch-Größen oder Review-Engpässen – Muster, die die Flow-Dimension bereits aus Ihren Projektmanagement-Daten trackt. CI/CD-Daten fügen den Deployment-seitigen Beleg hinzu.

Mean Time to Restore offenbart operatives Ownership. Schnelle Wiederherstellung signalisiert starke Incident Response und Code-Vertrautheit – Inputs für die Verantwortung-Dimension.

Die Effektivitätsscores erhalten nicht nur neue Datenpunkte. Sie erhalten konfidentere Datenpunkte. Ein Lieferung-Score, der nur auf Sprint-Completion-Daten basiert, ist nützlich. Ein Lieferung-Score, der durch Sprint-Completion und Deployment-Frequenz und Change Failure Rate gestützt wird, erzählt Ihnen eine reichhaltigere, vertrauenswürdigere Geschichte.

Das Konfidenz-Modell: Was wir wissen vs. was wir vermuten

Nicht alle CI/CD-Daten sind gleich zuverlässig. Ein GitHub Actions Workflow namens „deploy-production" mit einem Environment-Target ist eindeutig ein Deployment. Ein Workflow namens „build", der zufällig auf dem Main-Branch läuft... vielleicht? Wahrscheinlich? Wir sind uns weniger sicher.

Wir haben ein Konfidenz-Modell gebaut, das transparent über diese Unterscheidung ist:

• Hohe Konfidenz: Passte zu einer von Ihnen konfigurierten Deployment-Regel, oder die Pipeline-Metadaten identifizieren es explizit als Deployment
• Mittlere Konfidenz: API-Metadaten und Namensmuster deuten stark auf ein Deployment hin
• Niedrige Konfidenz: Heuristik-basierte Inferenz – vernünftige Vermutung, aber nicht sicher

Wenn die Konfidenz hoch ist, fließen die Daten mit vollem Gewicht in die Effektivitätsbewertung ein. Wenn sie niedrig ist, zeigen wir Ihnen die DORA-Metriken mit einem „Geschätzt"-Badge – und wir lassen unsichere Daten nicht Ihre Effektivitätsscores verschmutzen.

Sie können auch Deployment-Regeln pro Team konfigurieren: „Workflows, die auf deploy-* passen und auf die production-Umgebung abzielen, sind Deployments." Einmal konfigurieren, und jede zukünftige Datenaktualisierung nutzt Ihre Regeln. Die Konfidenz steigt. Die Scores werden präziser.

Das ist das Gegenteil des Black-Box-Ansatzes. Wir sagen Ihnen, was wir wissen und was wir vermuten. Sie entscheiden, wie sehr Sie dem vertrauen.

Was dies nicht ist

Seien wir klar darüber, was wir nicht bauen:

Dies ist keine Produktivitätsüberwachung. Wir messen die Lieferfähigkeit des Teams, nicht individuelle Tastenanschläge. Es gibt keine Deployment-Rangliste pro Entwickler. Keine „Shane hat 47-mal in diesem Sprint deployed"-Gamification. Die Messeinheit ist das Team.

Dies ist kein eigenständiges DORA-Dashboard. Wir konkurrieren nicht mit dedizierten DevOps-Analytics-Plattformen. Wenn Sie tiefe Pipeline-Optimierung, Build-Time-Analyse oder Flaky-Test-Erkennung brauchen – diese Tools existieren und sie sind gut in dem, was sie tun. Wir messen Lieferergebnisse, nicht CI-Infrastruktur-Optimierung.

Dies ist keine Strafe für Teams ohne CI/CD. Wenn Ihr Team keine verbundene Code-Integration hat oder Ihre Pipelines keine Deployment-Daten produzieren – nichts ändert sich. Keine Strafe. Keine fehlenden Scores. Kein Drängen. Die Effektivitätsdimensionen, die keine CI/CD-Belege haben, verlassen sich einfach auf die Signale, die sie bereits haben.

Das Prinzip ist additiv: Mehr Daten machen das Bild präziser. Weniger Daten machen es nicht falsch – nur weniger präzise.

Das größere Bild

DORA-Metriken sind ein trojanisches Pferd.

Sie sind für sich genommen wertvoll — jede Engineering-Führungskraft möchte ihre Deployment-Frequenz und Change-Failure-Rate kennen. Aber der eigentliche Wert liegt nicht in den vier Zahlen. Er liegt darin, was passiert, wenn CI/CD-Daten mit dem Rest des Bildes zusammenkommen.

Wir haben mit Retrospektiven-Daten begonnen — worüber das Team reflektiert, welche Muster auftauchen, zu welchen Maßnahmen es sich verpflichtet. Wir haben Standup-Daten hinzugefügt — tägliche Aktivität, Blocker-Muster, Stimmungssignale. Wir haben Projektmanagement-Daten hinzugefügt — Sprint-Planung, Abschlussraten, Schätzgenauigkeit. Code-Repository-Daten — Commits, PRs, Review-Muster.

Jetzt CI/CD-Daten. Jede Schicht macht das Effektivitätsbild vollständiger. Jede Schicht verringert die Lücke zwischen „was wir denken, was passiert" und „was tatsächlich passiert".

Das Ziel war nie, ein DORA-Dashboard zu bauen. Das Ziel ist es, Ihre Workflow-Abgase — alle davon, aus jedem Tool, das Ihr Team nutzt — in ein kohärentes Signal darüber zu verwandeln, wie Ihr Team tatsächlich arbeitet. DORA ist ein weiterer Input für dieses Signal. Ein wertvoller. Aber einer von vielen.

Quellen