Guide: Wie messe ich die Performance meines Engineering Teams in Zeiten von AI Coding Agents richtig?

Im ersten Teil der Reihe haben wir uns die häufigsten Stolperfallen bei der Messung der Performance eines Softwareentwickler-Teams angesehen. Um Performance korrekt zu messen, ist es wichtig, zu wissen, wie man es nicht macht und vor allem, warum zum Beispiel Lines of Code der Klassiker unter den schlechten Metriken ist oder wieso Goodhart’s Law auch gute Metriken nutzlos machen kann.

Mit diesem Vorwissen können wir uns heute anschauen, wie dein Team Performance tatsächlich zielführend messen kann — und das mit so wenig Aufwand wie möglich. Als großer Freund von „Just Do What Works“ zeige ich dir heute das effektivste Set an Metriken, die sich als De-facto-Industriestandard bewährt haben, und erläutere dir, wieso sie auch in Zeiten von Agentic Software Engineering noch relevant sind.

Wichtig: „Performance“ fasst hier Geschwindigkeit und Zuverlässigkeit des Systems zusammen. Das System ist dein Entwicklerteam oder die Art und Weise, wie ihr Software entwickelt und veröffentlicht. Es handelt sich weder um eine Messung der Produktivität noch der Effektivität der Arbeit.

Was sind die DORA-Metriken?

Google veröffentlicht den DORA-Report einmal im Jahr. Datengrundlage für das Jahr 2025 sind knapp 5000 Befragte und zusätzlich mehr als 100 Stunden qualitative Interviews. Erhoben werden dabei im Kern fünf Metriken, die Aussagen über den Throughput (Durchsatz) und die Instability (Instabilität) eines Teams liefern.

Der Report liefert uns ein Vokabular und einen Benchmark-Kontext, um fundiert über Delivery-Performance sprechen zu können.

Wichtig: DORA liefert bewusst keine Messgrundlage für den Business Value der Software, die Produktqualität oder das Wohlbefinden des Teams.

Warum ist DORA Industriestandard?

DORA ist die einzige Messbasis, die auf über einem Jahrzehnt empirischer Forschung mit zehntausenden Teams beruht. Die Metriken, auf die wir unten eingehen, sind bewusst schlank gehalten, sodass kein Team, das mit der Messung beginnen möchte, seinen Stack umbauen muss. Das bedeutet, dass DORA-Metriken für jedes Team zugänglich sind und damit eine Unterhaltung über Maßnahmen zur Verbesserung der Performance eines Produktteams ermöglichen.

Die Metriken im Kurzüberblick

1. Deployment Frequency (Throughput)

Was?

Wie oft Code erfolgreich in Produktion veröffentlicht wird. Je häufiger, umso besser.

Wie messen wir das?

Die einfachste Version ist eine Tabelle, in der dein Team jede Veröffentlichung auf Produktion mit Datum einträgt. Veröffentlicht ihr beispielsweise immer dann, wenn ihr ein Tag in Git erstellt, könnt ihr die Tags pro Woche erheben.

Richtwerte aus dem Report

22,7% der Befragten schaffen ein oder mehr Deployments pro Tag, 23,9% nur einmal im Monat oder seltener.

Warum sind häufigere Deployments besser?

Häufigere Deployments bedeuten eine kleinere Menge an Änderungen. Diese sind leichter test- und verifizierbar, wodurch das Fehlerrisiko pro Veröffentlichung sinkt. Tritt dennoch ein Fehler auf, ist dieser durch die kleineren Änderungen schnell auffindbar und der vorherige Stand der Software leichter wiederherstellbar.

Wie verbessern wir die Deployment Frequency?

Drei Beispiele:

1. Pull Requests klein halten: Kleinere Pull Requests ermöglichen ein leichteres Review und einen schlankeren QA-Prozess und sind damit schneller bereit zur Veröffentlichung.
2. Deployments automatisieren: Je weniger manuellen Aufwand ein Deployment erzeugt, umso leichter und häufiger kann man „aufs Knöpfchen drücken“. Der initiale Aufwand der Automatisierung rechnet sich schnell, da sie Kapazitäten für die eigentliche Produktentwicklung freisetzt und oft einen Blocker aus dem Kalender nehmen kann.
3. Feature Flags nutzen: Feature Flags ermöglichen die Veröffentlichung von Code, der für den Kunden noch nicht sichtbar ist, sodass weniger Änderungen einen Release wirklich blockieren können.

2. Change Lead Time (Throughput)

Was?

Zeit von Commit in Git bis zur erfolgreichen Veröffentlichung in Produktion. Je kürzer, umso besser.

Wie messen wir das?

In der einfachsten Version zieht man den Zeitstempel des ersten Commits eines Features vom Zeitstempel der Veröffentlichung in Produktion ab oder misst die Zeit zwischen dem Merge eines Pull Requests und der Veröffentlichung.

Richtwerte aus dem Report

Nur 9,4% aller Befragten schaffen weniger als eine Stunde. Alarmierend: 43,5% brauchen länger als eine Woche.

Warum ist eine geringe Change Lead Time besser?

Je weniger Zeit zwischen dem Bau eines Changes und seiner Veröffentlichung vergeht, umso frischer sind die Erinnerungen des Engineers an seine Arbeit und umso leichter ist die Behebung eines Fehlers. Außerdem fördert ein kurzes Intervall zwischen Entwicklung und Veröffentlichung eine schnelle Lernkultur und iterative Weiterentwicklung — zwei Werte, die in den Grundsätzen der agilen Softwareentwicklung verankert sind.

Wie verbessern wir die Change Lead Time?

Drei Beispiele:

1. Review-Prozesse schlank halten: Definiert im Team, welche Anmerkungen in einem Pull Request sofort angegangen werden müssen, und welche nachgearbeitet werden dürfen. Trennt Änderungen am Verhalten der Software strikt von strukturellen Änderungen, um letztere mit nur einem minimalen Review weiterbringen zu können.
2. Pipelines beschleunigen und entschlacken: Wenn jeder Push eine halbe Stunde baut, sorgt das für Stau. Änderungen wandern langsamer von der Entwicklung bis zur Veröffentlichung, Tester warten auf die neueste Version, und Pipeline-Fehler eines Tickets, das vor einer halben Stunde bearbeitet wurde, erzeugen mit hoher Wahrscheinlichkeit einen Kontextwechsel.
3. Review-Verantwortung verteilen: Ein einzelner Senior, der über alle Änderungen wachen muss, ist das vielleicht größte Bottleneck in einem Produktentwicklungsteam. Hier lohnen sich Fragen wie „Kann das wirklich niemand sonst machen?“, „Kann AI uns dabei unterstützen?“ oder „Müssen wir rein strukturelle Änderungen wirklich reviewen?“

3. Failed Deployment Recovery Time (Throughput)

Was?

Zeit, um nach einer fehlgeschlagenen Veröffentlichung wieder einen funktionierenden Zustand herzustellen. Je kürzer, umso besser.

Wie messen wir das?

Tools wie Opsgenie liefern diese Werte automatisch. Wenn dein Team noch kein Incident-Tooling hat, kann man die Zeit zwischen Start des Incidents und der Resolution messen. Wichtig ist, dass hier nur Incidents eine Rolle spielen, die direkt durch ein Deployment verursacht wurden.

Richtwerte aus dem Report

21,3% der Befragten erholen sich innerhalb einer Stunde, mehr als die Hälfte (56,5%) braucht mehr als einen Tag.

Warum ist eine kurze Recovery Time besser?

Je schneller ein Incident behoben wird, umso weniger wirtschaftlichen Schaden richtet er an. Ich kenne Situationen, in denen jede Stunde, in der das System kaputt war, einen Schaden im sechsstelligen Euro-Bereich verursacht hat. Der Umgang mit Incidents lässt sich üben und nimmt Teams die Angst vor dem Deployment (ja, die existiert), weshalb das DORA-Team den Wert zu Throughput zählt und nicht zu Instability.

Wie verbessern wir die Failed Deployment Recovery Time?

Drei Beispiele:

1. Rollback-Mechanismen einbauen: Wenn der einzige Ausweg die aktive Behebung des Fehlers ist, muss ein Engineer kognitiv anstrengende Arbeit unter Zeitdruck leisten, die häufig mehr Zeit beansprucht als im Tagesgeschäft und zusätzlich Folgefehler nach sich ziehen kann. Kann man ein Deployment per Knopfdruck rückgängig machen, ermöglicht das deinem Team eine saubere Behebung unter weniger Stress.
2. Monitoring und Alerting einbauen und verbessern: Was, wenn wir einen Incident haben und keiner weiß es? Was, wenn die Support-Hotline heißläuft und sich der Product Owner plötzlich denkt: „Moment mal…“ Unerwartete Fehler auf Produktion müssen eine Benachrichtigung auslösen.
3. Recovery-Mechanismen dokumentieren: Was mache ich, wenn die Datenbank offline geht? Wie kann ich einen Fehler beim Kunden mit minimalem Aufwand nachstellen? Wer hat die nötigen Befugnisse, um ein Deployment zurückzurollen? „Sven ist im Urlaub“ ist ein Satz, den kein Engineer während eines Incidents hören möchte.

4. Change Fail Rate (Instability)

Was?

Anteil der Veröffentlichungen, die unmittelbar einen Fehler in Produktion verursachen, wodurch ein Rollback oder ein Hotfix notwendig wird. Je geringer, umso besser.

Wie messen wir das?

Jedes Deployment nachträglich klassifizieren als clean oder caused incident. Das Verhältnis beider Kategorien über die Zeit liefert den Wert.

Richtwerte aus dem Report

Nur 8,5% erreichen 0-2% Fehlerrate und 39,5% liegen bei einer Fehlerrate über 16%.

Warum ist eine geringere Fail Rate besser?

Eine hohe Change Fail Rate bedeutet, dass ein Deployment mit mehr Risiko verbunden ist. Das verstärkt die bei Metrik 3 angesprochene Angst. Ist die Change Fail Rate gering, weist das auf gute QA-Mechanismen und saubere Arbeit hin und bedeutet weniger Reibung durch Hotfixes und mehr Vertrauen in das Produkt auf Kundenseite.

Wie verbessern wir die Change Fail Rate?

Drei Beispiele:

1. Staging-Umgebung pflegen und nutzen: Eine Umgebung, die der Produktion so ähnlich wie möglich ist, kann Fehler „in der realen Welt“ aufzeigen, die in Entwicklungsumgebungen nicht auftreten. Wichtig ist, dass eine solche Umgebung nicht nur existiert, sondern auch aktiv für Tests genutzt wird, um effektiv zu sein.
2. Kleinere Veröffentlichungen: Rein statistisch ist es wahrscheinlicher, dass eine große Veröffentlichung einen Fehler hat, der Nacharbeiten verursacht. Kleinere Veröffentlichungen beinhalten schlichtweg weniger Fehlerquellen und haben die gleichen Vorteile wie kleinere Pull Requests.
3. Automatisierte Tests in der Pipeline: Je mehr Fehler automatisiert ausgeschlossen werden können, umso besser. Wichtig: Automatisierung und Stabilität von Tests stehen in Wechselwirkung zueinander, insbesondere bei sog. End-to-End-Tests (E2E). Wie erreiche ich das richtige Maß an Testautomatisierung? Kurz: Durch Experimentieren.

5. Deployment Rework Rate (Instability, neu seit 2024)

Was?

Anteil der Veröffentlichungen, die ungeplant und zur Behebung eines Produktionsproblems notwendig sind. Nicht unbedingt nur Hotfixes, sondern generell Nacharbeiten. Je geringer, umso besser.

Wie messen wir das?

Wie beim vorherigen Messwert klassifizieren wir Deployments nach planned/feature und unplanned/fix. Das Verhältnis zwischen ungeplanten Deployments und allen Deployments liefert den Wert. Wichtig: Um ein Deployment als unplanned/fix klassifizieren zu können, muss es eine direkte Folge eines vorhergegangenen Deployments sein.

Richtwerte aus dem Report

Nur 7,3% liegen unter 2%. 26,1%, also mehr als ein Viertel aller Befragten, verbringt erhebliche Zeit mit Hotfixing, nämlich 8-16%.

Warum ist eine geringe Deployment Rework Rate besser?

Wer viel Zeit mit Nacharbeit verbringt, hat ein instabiles System. Da diese Nacharbeiten nicht unbedingt dringlich sind und nicht unter Stress geschehen, sind sie nicht so stark sichtbar wie die Auswirkungen der Metrik Change Fail Rate, reduzieren aber die echte Produktivität auf eine subtile Weise. Eine geringere Deployment Rework Rate bedeutet, dass Themen sauberer abgeschlossen werden und viel Zeit in die echte Weiterentwicklung des Produkts investiert werden kann.

Wie verbessern wir die Deployment Rework Rate?

Drei Beispiele:

1. Definition of Done aufstellen oder schärfen: Wann ist eine Änderung abgeschlossen und kann veröffentlicht werden? Erstaunlich häufig können Teams diese Frage nicht klar beantworten, wodurch fehlende Puzzleteile nicht während der Entwicklung auffallen, sondern vielleicht erst beim Kunden.
2. Beobachten, ob AI-generierter Code die Rework Rate hochtreibt: Die Metrik wurde 2024 neu eingeführt und erste Zahlen weisen darauf hin, dass Code, der von einem AI Agent generiert wurde, diesen Wert deutlich ansteigen lässt. Wenn die AI-Nutzung in deinem Team noch gering ist, lohnt es sich also, so früh wie möglich mit der Messung zu beginnen, um anschließend herauszufinden, ob ihr AI Agents effektiv einsetzt.
3. Fehler analysieren statt nur beheben: „Wie kam es dazu?“ ist eine Frage, die wir uns im hektischen Alltag nicht oft stellen. Wir beheben Symptome als Teil unserer täglichen Arbeit, fragen uns aber selten, was die Ursache dahinter war. „Hätte das früher auffallen sollen?“ und „Waren die Anforderungen unklar?“ sind nur zwei der interessanten Fragen. Wichtig ist, dass dein Team eine Kultur verinnerlicht hat, in der solche Fragen nicht als Schuldzuweisung verstanden werden, sondern als ein Impuls, um besser werden zu können.

Wie kann ich die Messungen automatisieren?

Die gute Nachricht: Grundsätzlich geht das sehr gut. Die schlechte Nachricht: Die tatsächliche Empfehlung hängt — im Gegensatz zur Aussagekraft der Metriken selbst — dann doch von dem Tool Stack ab, den ihr nutzt.

Kurzgesagt:

• Nutzt ihr sowohl für euer Issue Tracking als auch für eure gesamte Entwicklungspipeline GitLab Ultimate, bekommt ihr die ersten vier Metriken inkl. Dashboard von GitLab geschenkt (Analyze → Analytics Dashboards → DORA metrics dashboard).
• Nutzt ihr GitLab in einem der anderen Tiers oder GitHub, oder nutzt ihr ein zusätzliches Tool für Issue Tracking (Jira, Linear, usw.), ist eure beste Anlaufstelle klar Apache DevLake als Open-Source-Lösung. Wenn ihr weniger Setup- und Verwaltungsaufwand haben wollt, stehen SaaS-Lösungen wie CodePulse oder DX zur Verfügung.
• Alternativ lohnt es sich, den Klassiker Google Four Keys anzuschauen, auch wenn das verlinkte Repository inzwischen archiviert ist.

Meine Empfehlung: Die DORA-Metriken nicht zu erheben, ist keine gute Idee. Dementsprechend rate ich dir, entweder direkt auf die Automatisierung der Messungen zu schauen, oder aber schlank und manuell zu starten und die Einrichtung der Automatisierung zeitnah fest in eure Roadmap einzuplanen.

Wichtig: Die neue Metrik, Deployment Rework Rate, wird von den unterschiedlichen Tools (Stand: Juni 2026) leider noch nicht oder nicht vollständig unterstützt.

Wie lange muss ich messen und was mache ich mit den Ergebnissen?

Die DORA-Metriken sind erst aussagekräftig, wenn sie über einen Zeitraum von drei bis sechs Monaten kontinuierlich erhoben werden. Kürzere oder einmalige Messungen haben das Problem jeder Statistik: Einzelne Messungen alleine sind nicht relevant und können Ausreißer sein. Manche Jahreszeiten sind für einige Produkte wesentlich stressiger als andere: Eine Software zur Garderobenverwaltung wird in heißen Sommern weniger häufig genutzt als in eisigen Wintern und erlebt dementsprechend in der warmen Jahreszeit weniger Incidents.

Mit den Ergebnissen machst du am besten das, was das DORA-Team selbst auch macht: Regelmäßig anschauen und neu bewerten. Bis 2024 kategorisierte der Report die einzelnen Abstufungen in den Messwerten zwischen „Elite“ und „Low“, seit 2025 wird hingegen eine Cluster-Analyse durchgeführt und Teams finden sich in benannten Gruppen wie „Harmonious High Achievers“ oder „Legacy Bottleneck“ wieder.

Was heißt das? Die Metriken liefern eine Diskussionsbasis. Sie liefern Benchmark-Werte, mit denen man sich vergleichen kann. Sie liefern Hinweise auf Schwachstellen in der eigenen Delivery-Performance und Impulse für mögliche Verbesserungen.

Für dich und dein Team bedeutet das: Ihr müsst nicht mehr raten, ob eine große Veränderung — wie die Einführung von AI Agents in euren Entwicklungsprozess — eure Performance verbessert oder verschlechtert. Aus Bauchgefühl werden belastbare Werte. Über die kann man sprechen, und auch die Effektivität von Gegenmaßnahmen leitet sich einige Monate später aus den gleichen Werten ab.

Was ist mit Goodhart’s Law?

Die Metriken stehen nicht für sich: Eine hohe Deployment Frequency ist kein Indiz für eine hohe Performance, wenn die Change Fail Rate ebenfalls sehr hoch ist (zur Erinnerung: Performance = Geschwindigkeit + Zuverlässigkeit). Es ergibt schlichtweg keinen Sinn, eine einzelne Metrik zum Ziel auszurufen. Dementsprechend greift Goodhart’s Law hier nicht.

Man könnte jetzt ganz schlau sein und sagen: „Naja, dann rufe ich eben die Gruppe der DORA-Metriken zum Ziel aus — dann greift doch jetzt Goodhart’s Law bei der Gruppe, oder?“ Kurz: Nein, denn eine einzelne Metrik kann man manipulieren, aber wenn all deine DORA-Werte mit der Zeit besser werden, kannst du davon ausgehen, dass die Performance deines Teams tatsächlich gestiegen ist und es nicht geschafft hat, die gesamte Benchmark zu manipulieren.

Sind die DORA-Metriken in Zeiten von Claude und Codex noch relevant?

Mehr als je zuvor. Dadurch, dass wir (größtenteils) lauffähigen Code jetzt generieren können, indem wir 60 Sekunden lang in ein Mikrofon reden und anschließend „Enter“ drücken, entsteht viel mehr Code als vorher. Der Output steigt. Mit dem richtigen System kann es dein Team schaffen, dass auch der Code der AI Agents in kleinen Iterationen und kleinen Pull Requests nach Produktion läuft. Deployments steigen vielleicht an. „Wir schaffen mehr“ ist das logische Bauchgefühl.

Die DORA-Metriken verbinden sowohl Messungen, die das „Wir schaffen mehr“-Gefühl stützen oder widerlegen können (wie häufig veröffentlichen wir?), als auch solche, die uns sagen, welche Auswirkungen die neuen Workflows auf die Stabilität haben.

Heißt: Wenn dein Engineering Team AI Agents nutzt, müsst ihr die DORA-Metriken erheben. Sie sind die solideste Diskussionsgrundlage, die ihr habt.

Sind die DORA-Metriken die einzigen Werte, die ich erheben sollte?

Die DORA-Metriken sind dein erster sehr wichtiger Schritt, um Licht ins Dunkel zu bringen. Sie liefern dir hilfreiche Hinweise zur Performance deines Teams. Was sie dir nicht liefern, ist ein Überblick darüber, wie dein Team miteinander arbeitet und welche konkreten Auswirkungen das hat.

In Teil 3 der Reihe schauen wir uns an, wie du die DORA-Metriken um ein entsprechendes Framework erweitern kannst, um einen Gesamtüberblick über die Performance und wesentliche Aspekte wie Zufriedenheit und Kommunikation deines Engineering Teams zu erhalten. Lass dich benachrichtigen, sobald der Artikel verfügbar ist.

×