Der Drift, der es nie in die Retro schaffte
Wie ein Team aufhörte zu streiten, ob sich die Delivery „langsamer anfühlt" — weil die vier DORA-Zahlen bereits berechnet, eingestuft und auf die exakten Pull Requests gerichtet waren.
DIENSTAG, 10:04 — SPRINT PLANNING
Die Velocity sieht gut aus. Das Board ist grün. Aber die Lead Time kriecht seit zwei Wochen nach oben — von 26 auf 41 Stunden — verteilt über drei Tools, die niemand zusammenführt. Die Retro, die es auffangen könnte, ist drei Sprints entfernt und wird mit Anekdoten geführt.
DIENSTAG, 09:00 — #ENG-HEALTH
Der Drift-Alert kam an, bevor das Planning überhaupt begann: „Lead Time for Changes: 41h, +58 % in 14 Tagen — Band High → Medium", mit den drei Pull Requests verlinkt, die den Schnitt nach unten ziehen. Das Gespräch dreht sich um den Fix, nicht um das Gefühl.
Niemand hat einen neuen Prozess eingeführt. Die Pipeline hat einfach angefangen mitzuzählen.
Vor den Zahlen gab es „es fühlt sich langsamer an"
Wer mehr als ein Delivery-Team führt, kennt dieses Meeting:
- Die Daten lebten in drei Tools. Deployments im CI, Lead Time in Git, Incidents in Jira — überall echte Zahlen, nirgends eine gemeinsame.
- Performance-Gespräche liefen über Anekdoten. „Es fühlt sich langsamer an" gegen „alles gut" — und wer selbstbewusster auftrat, gewann.
- Drift zeigte sich erst im Quartalsreview — da steckte die Verlangsamung längst in zwei Releases, und niemand wusste mehr, welche Änderung sie ausgelöst hatte.
- Die Tools, die messen konnten, wollten Entwickler ranken. Ein No-Go fürs Team — und für den Betriebsrat.
Also wurden die vier Zahlen vom Quartalsstreit zur stündlichen Auswertung.
Die Tour — von Rohdaten zu einer Zahl, die man hinterfragen kann
Den vorhandenen Stack anschließen
Jira, GitHub, GitLab, Linear, Azure DevOps und Jenkins sind in Minuten verbunden — Webhook oder Polling, keine Agents, keine Workflow-Änderung für Entwickler. Historische Aktivität füllt die erste Baseline innerhalb einer Stunde — nicht nach einem Quartal Datensammeln.
Vier Zahlen, für jedes Team gleich berechnet
Deployment Frequency, Lead Time for Changes, Change Failure Rate, Time to Restore — stündlich berechnet und von Elite bis Low eingestuft, gegen die DORA-Forschungsbenchmarks und Ihren eigenen gleitenden Durchschnitt. Dieselbe Mathematik für jedes Team — damit ein Vergleich etwas bedeutet.
Drift-Alerts, die die Verursacher benennen
Verschlechtert sich eine Metrik über Ihre Schwelle hinaus, landet der Alert in Slack oder Teams — mit den exakten Pull Requests und Issues verlinkt, die den Schnitt ziehen, nicht nur einer rot gewordenen Zahl. Das Fix-Gespräch beginnt am selben Morgen.
Team-Ebene by design — und Gates, wenn es zählt
Jede Zahl lässt sich bis auf Work Items aufschlüsseln, nie bis auf Personen: Eine Pro-Entwickler-Ansicht gibt es bewusst nicht. Und wenn ein Release bei verschlechterter Delivery-Gesundheit nicht ausgeliefert werden soll, hält ein Readiness-Gate es, bis sich das Band erholt.
Pro-Entwickler-Scorecards: nicht gebaut. Und auch nicht auf der Roadmap.
Dieselbe Retro, ein Quartal später
Vorher
- —Drift zeigte sich im Quartalsreview — zwei Releases zu spät
- —„Es fühlt sich langsamer an" gegen „alles gut" — Selbstbewusstsein gewann, nicht Daten
- —Die Baseline war Folklore: „normal für uns" hieß, was die lauteste Person erinnerte
- —Metrik-Tools scheiterten an der Angst vor Entwickler-Überwachung
Nachher
- ✓Drift landet in Slack in der Woche, in der er beginnt — Verursacher-PRs verlinkt
- ✓41h, +58 %, diese drei PRs — gestritten wird über den Fix
- ✓Elite/High/Medium/Low-Einstufung gegen die DORA-Forschung und den eigenen Verlauf
- ✓Nur Team-Ebene, by design — nichts, was der Betriebsrat ablehnen müsste
Ein ehrlicher Fit-Check
Das passt, wenn
- ✓Ihre Delivery läuft über Jira + GitHub, GitLab, Linear oder Azure DevOps
- ✓Sie haben mehr als ein Team und keine gemeinsame Delivery-Kennzahl
- ✓Die Führung fragt „werden wir schneller oder langsamer?" — und die ehrliche Antwort ist ein Schulterzucken
- ✓Sie wollen DORA-Metriken, ohne dafür eine Datenpipeline zu bauen
Und ehrlich gesagt, wenn
- ·Sie wollen Rankings einzelner Entwickler — bewusst nicht gebaut, und das bleibt so. DORA misst den Fluss durch ein System, nicht Personen.
- ·Sie mergen nicht über PRs und deployen nicht über CI — dann gibt es nichts zu messen.
- ·Sie suchen die EU-Verordnung DORA — das ist der Digital Operational Resilience Act, ein Finanzsektor-Gesetz und etwas völlig anderes. Die Compliance-Seite decken unsere DSGVO- und EU-AI-Act-Seiten ab.
Eine zweite Meinung zu Ihren Delivery-Metriken
Eine erfahrene Engineering-Führungskraft prüft die Metriken Ihres Teams und gibt eine Einschätzung je Metrik. Das ist eine Engineering-Prüfung, keine Rechtsprüfung.
So funktioniert Expert Review →DORA-Metriken FAQ
Welche DORA-Metriken erfasst PulseCheck, und wie werden sie berechnet?
Alle vier: Deployment Frequency, Lead Time for Changes, Change Failure Rate und Time to Restore. Berechnet aus Ihren tatsächlichen Delivery-Ereignissen — Merges, Deployments, Incident-Issues — stündlich aktualisiert, mit identischer Berechnung für jedes Team.
Welche Tools speisen die Metriken?
Jira, GitHub, GitLab, Linear, Azure DevOps und Jenkins. Die meisten Teams verbinden zwei Quellen in unter zehn Minuten; der historische Backfill liefert noch am selben Tag eine brauchbare Baseline.
Hat das etwas mit der EU-Verordnung DORA zu tun?
Nein — auf dieser Seite geht es um DORA-Delivery-Metriken (DevOps Research & Assessment): Deployment Frequency, Lead Time, Change Failure Rate und Time to Restore. Der Digital Operational Resilience Act der EU ist eine Finanzsektor-Regulierung und etwas völlig anderes. PulseChecks Compliance-Funktionen finden Sie auf unseren DSGVO- und EU-AI-Act-Seiten.
Was unterscheidet das von anderen DORA-Tools?
PulseCheck verbindet die vier Metriken mit Compliance-Monitoring und Engineering-Investment-Analytik in einer Plattform — und jede Metrik lässt sich bis auf die zugrunde liegenden Pull Requests und Issues aufschlüsseln. Eine Zahl, die man hinterfragen kann, statt einer Scorecard, der man glauben muss. Expert Review ergänzt eine Engineering-Prüfung durch eine erfahrene Engineering-Führungskraft (keine Rechtsprüfung).
Kann man damit einzelne Entwickler tracken?
Nein, bewusst nicht. Metriken werden ausschließlich auf Team-Ebene berechnet und angezeigt. Genau diese Grenze macht DORA nützlich — die Forschung handelt vom Fluss durch ein System, nicht von individueller Leistung.