DORA-Delivery-Diagnose
Wann Sie diese Methode brauchen
Aussagen über die eigene Lieferfähigkeit beruhen fast immer auf Eindruck. Die Entwicklung hält sich für schnell, das Geschäft hält sie für langsam, und keine Seite hat eine Zahl. Wo künstliche Intelligenz in die Entwicklung einzieht, verschärft sich das: Sichtbar wird, dass mehr Code entsteht, unsichtbar bleibt, ob mehr davon in den Betrieb gelangt und dort hält. Ohne Basislinie lässt sich zwei Quartale später weder belegen noch widerlegen, dass die Investition etwas gebracht hat.
Vorgehen
- 1Den Gegenstand festlegen. Gemessen wird eine Anwendung oder ein Dienst, nicht das Unternehmen als Ganzes und nicht ein Team im Vergleich zu anderen Teams.
- 2Die Größen erheben: Durchlaufzeit einer Änderung von der Versionsverwaltung bis in den Betrieb, Auslieferungsfrequenz, Wiederherstellzeit nach einer fehlgeschlagenen Auslieferung, Anteil der Auslieferungen mit sofortigem Eingriff, Anteil der ungeplanten Nacharbeit nach Störungen.
- 3Die Zahlen aus Versionsverwaltung und Auslieferungswerkzeugen ziehen statt aus Selbsteinschätzung. Umfragen liefern zu wenige Datenpunkte, um eine Entwicklung über Wochen zu erkennen.
- 4Durchsatz und Stabilität gemeinsam lesen. Ein Zuwachs beim Durchsatz, der Fehlerquote oder Wiederherstellzeit verschlechtert, ist keine Verbesserung, sondern eine Verlagerung der Kosten nach hinten.
- 5Vor jedem größeren Eingriff in die Lieferkette eine Basislinie festhalten, ausdrücklich auch vor der breiten Einführung von KI-Werkzeugen, und nach einigen Wochen erneut messen.
- 6Genau einen Engpass benennen und dort ansetzen, meist bei automatisierter Prüfung, Freigabeweg oder Rückmeldegeschwindigkeit, statt an allen Größen gleichzeitig zu arbeiten.
Typische Anwendung
Ein typisches B2B-SaaS mit rund siebzig Entwicklerinnen und Entwicklern führt KI-Assistenz flächendeckend ein und misst den Erfolg an der Zahl übernommener Vorschläge. Nach zwei Quartalen berichtet die Entwicklung, sie arbeite spürbar schneller, während der Vertrieb über verschobene Zusagen klagt. Die Diagnose erhebt für den Hauptdienst die fünf Größen aus Versionsverwaltung und Auslieferungswerkzeugen. Auslieferungsfrequenz und Durchlaufzeit haben sich tatsächlich verbessert. Zugleich ist der Anteil der Auslieferungen mit sofortigem Eingriff deutlich gestiegen und die Wiederherstellzeit länger geworden. Der Engpass liegt damit nicht im Schreiben von Code, sondern in einer automatisierten Prüfung, die für das frühere Änderungsvolumen ausgelegt war. Das Team stoppt die weitere Werkzeugausweitung, baut die Testabdeckung an den Bruchstellen aus und misst nach einem Quartal erneut.
Grenzen und Gegenindikationen
Die Größen beschreiben die Lieferstrecke, nicht den Wert des Gelieferten. Ein Team kann schnell und stabil das Falsche ausliefern. Als Zielvorgabe oder als Vergleich zwischen Teams richtet die Erhebung Schaden an, weil sich Auslieferungsfrequenz durch das Zerlegen von Auslieferungen und die Fehlerquote durch das Umdeklarieren von Vorfällen leicht schönen lassen. Wer manuell und quartalsweise ausliefert, erzeugt zu wenige Datenpunkte für eine belastbare Aussage. Außerhalb der Softwarelieferung trägt die Diagnose nicht, etwa in Beratung oder Hardware. Und die Befunde zur künstlichen Intelligenz stammen aus Querschnittsbefragungen mit Selbstauskunft: Sie zeigen Zusammenhänge, keine Ursachen, und die Richtung des Durchsatz-Befunds hat sich zwischen zwei Erhebungsjahren bereits einmal umgekehrt. Der eigene Messwert ersetzt hier die Branchenzahl, er wird nicht durch sie belegt.
Woran Sie Wirkung messen
Führen Sie je Dienst eine Basislinie der fünf Größen und lesen Sie Durchsatz und Stabilität immer als Paar. Als Fortschritt zählt nur, was Durchlaufzeit oder Auslieferungsfrequenz verbessert, ohne Fehlerquote, Nacharbeitsquote und Wiederherstellzeit zu verschlechtern.
Verwandte Methoden
Werkzeuge dafür
Quellen
- 1.Forsgren, Rothenberger, Humble, Thatcher, Smith: A Taxonomy of Software Delivery Performance Profiles: Investigating the Effects of DevOps Practices, AMCIS 2020 (öffnet in neuem Tab) · Association for Information Systems, AIS Electronic Library (AMCIS 2020 Proceedings, Systems Analysis and Design) · 2020 · Wissenschaft und Fachliteratur · belegt den WirkmechanismusTrägt den Kern der Diagnose: Lieferleistung wird aus Durchsatzgrößen (Auslieferungsfrequenz, Durchlaufzeit) und einer Stabilitätsgröße (mittlere Wiederherstellzeit) zusammengesetzt. In einer Stichprobe von 7.522 Fachleuten ergibt eine hierarchische Clusteranalyse drei unterscheidbare Leistungsprofile, wobei Durchsatz und Stabilität sich gemeinsam bewegen statt gegeneinander. Grenze: Querschnitts-Selbstauskunft aus einer freiwilligen Stichprobe, keine Kausalaussage und keine Zeitreihe je Team.
- 2.Sallin, Kropp, Anslow, Quilty, Meier: Measuring Software Delivery Performance Using the Four Key Metrics of DevOps, XP 2021 (öffnet in neuem Tab) · 22nd International Conference on Agile Software Development (XP 2021), Volltext offen über ZHAW digitalcollection, CC BY 4.0 · 2021 · Wissenschaft und Fachliteratur · beschreibt das VerfahrenTrägt das Erhebungsverfahren: Auslieferungsfrequenz, Durchlaufzeit einer Änderung, Wiederherstellzeit und Fehlerquote von Änderungen lassen sich aus Versionsverwaltung und Auslieferungsdaten automatisch bestimmen. Die Autoren halten fest, dass die übliche Messung manuell und per Umfrage erfolgt und dabei nur wenige Datenpunkte liefert, und bauen dafür einen Prototyp, den sie in der Praxis erproben. Grenze: die Erprobung stützt sich auf einen einzelnen Anwendungsfall, ein Wirksamkeitsnachweis für die abgeleiteten Maßnahmen fehlt.
- 3.DORA: Software delivery performance metrics (Guide) (öffnet in neuem Tab) · DORA (dora.dev), Google Cloud · 2026 (abgerufen) · Praxisquelle · liefert den AnlassLiefert die aktuellen Definitionen und die Anwendungsregeln der Forschungsgruppe selbst. Erfasst werden inzwischen fünf statt vier Größen, weil neben der Fehlerquote von Änderungen zusätzlich der Anteil ungeplanter Nacharbeit nach Störungen erhoben wird. Ausdrücklich gilt: Die Erhebung wird je Anwendung oder Dienst angewendet und nicht als Vergleich zwischen Teams. Grenze: eine Anleitung des Herausgebers der Kennzahlen, kein unabhängiger Beleg und keine Wirksamkeitsmessung.
- 4.DORA: Balancing AI tensions, Moving from AI adoption to effective SDLC use (State of AI-assisted Software Development 2025) (öffnet in neuem Tab) · DORA (dora.dev), Google Cloud · 2025 · Praxisquelle · liefert VergleichszahlenTrägt den KI-Bezug der Diagnose. In der Erhebung 2025 hängt eine höhere KI-Nutzung sowohl mit höherem Lieferdurchsatz als auch mit höherer Lieferinstabilität zusammen. 90 Prozent der Befragten nutzen KI bei der Arbeit, über 80 Prozent halten sich dadurch für produktiver, 30 Prozent vertrauen dem erzeugten Code wenig bis gar nicht. Die Autoren deuten KI als Verstärker vorhandener Stärken und Schwächen, nicht als Lösung struktureller Probleme. Grenze: Zusammenhänge aus einer Querschnittsbefragung mit Selbstauskunft, keine Kausalität.
- 5.Google Cloud: Announcing the 2025 DORA Report (öffnet in neuem Tab) · Google Cloud Blog · 2025 · Praxisquelle · begrenzt das VerfahrenDient als Vorbehalt gegen die Übernahme von Branchenzahlen. Die Erhebung stützt sich auf knapp 5.000 Fachleute und über 100 Stunden Interviews. Der Zusammenhang zwischen KI-Nutzung und Lieferdurchsatz war im Vorjahr negativ und ist 2025 positiv, während der Zusammenhang mit der Lieferstabilität in beiden Jahren negativ bleibt. Damit ist die Richtung des Durchsatz-Befunds über die Jahre nicht stabil, und die Branchenzahl ersetzt die eigene Messung nicht. Grenze: eine Ankündigung des Herausgebers, ohne ausgewiesene Effektstärken.
Ursprung: Forsgren et al. / DORA