Mehr als 4 Metriken: SPACE, DevEx und DX Core 4 richtig einsetzen

Die Lücke der vier Metriken

Der DORA-Metriken-Leitfaden auf diesem Blog beschreibt vier Kennzahlen, die zum Goldstandard für Software Delivery Performance geworden sind: Deployment Frequency, Lead Time for Changes, Mean Time to Restore und Change Failure Rate. Diese Metriken sind robust, empirisch validiert und ein hervorragender Ausgangspunkt. Aber sie haben eine systematische Blindstelle, die mit zunehmender Reife einer Organisation immer schmerzhafter wird: Sie messen den Output des Delivery-Systems, nicht das Erlebnis der Menschen, die es betreiben.

Ein Team kann mehrmals täglich deployen, eine Lead Time unter einer Stunde halten und trotzdem ausgebrannt sein. Eine Organisation kann Elite-Werte in allen vier DORA-Dimensionen erreichen und gleichzeitig eine Fluktuation haben, die jede Quartalsbilanz auffrisst. Die DORA-Metriken sehen das nicht. Sie sehen den Durchsatz und die Stabilität der Pipeline — nicht die Reibung, die ein Entwickler erlebt, bevor der Code überhaupt committet wird, und nicht die kognitive Last, die jede Codeänderung in einem schlecht verstandenen System erzeugt.

Diese Lücke ist 2026 kein akademisches Detail mehr. Mit dem flächendeckenden Einsatz von KI-Coding-Assistenten verschiebt sich der Engpass weg vom reinen Schreiben von Code hin zum Verstehen, Reviewen und Integrieren. Throughput steigt — aber Stabilität und Verständnis geraten unter Druck, wenn die unterstützenden Praktiken nicht mitwachsen. Genau hier setzen die ergänzenden Frameworks an: SPACE und DX Core 4 messen das, was DORA strukturell nicht sehen kann.

Dieser Artikel ersetzt DORA nicht — er erweitert es zu einem vollständigen Messsystem. Die These: Top-Quartil-Teams entstehen nicht durch eine einzelne Kennzahl, sondern durch die bewusste Kombination von DORA, SPACE und DX Core 4. Wer alle drei Ebenen zusammen liest, erkennt Engpässe vier- bis fünfmal früher als ein Team, das nur den Pipeline-Durchsatz beobachtet.

Was das SPACE-Framework misst

SPACE wurde 2021 von Forschenden um Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck und Jenna Butler vorgestellt. Es ist kein Konkurrenzmodell zu DORA, sondern ein Rahmen, der bewusst klarstellt: Entwicklerproduktivität ist mehrdimensional und lässt sich nicht auf eine einzige Zahl reduzieren. SPACE ist ein Akronym aus fünf Dimensionen, die zusammen ein deutlich vollständigeres Bild ergeben als reine Durchsatzmetriken.

Satisfaction and Well-being erfasst, wie zufrieden und gesund das Team ist — Burnout-Signale, Fluktuationsabsicht, das Gefühl, mit den richtigen Werkzeugen zu arbeiten. Diese Dimension ist deshalb so zentral, weil unzufriedene Teams ihre DORA-Werte oft noch eine Weile halten, bevor sie kippen. Satisfaction ist ein Frühindikator, dort wo DORA ein Spätindikator ist.

Performance misst das Ergebnis eines Systems oder Prozesses — bewusst nicht die Aktivität einer Einzelperson. Hier docken die DORA-Stabilitätsmetriken an. Activity erfasst die Zahl der Aktionen oder Outputs — Commits, Pull Requests, Reviews. Die ausdrückliche Warnung des SPACE-Modells: Activity allein ist niemals ein Produktivitätsmaß, sondern nur ein Kontextsignal.

Communication and Collaboration macht sichtbar, wie Information durch das Team fließt — wie schnell ein Pull Request einen Reviewer findet, wie auffindbar Dokumentation ist, wie gut das geteilte mentale Modell des Systems ist. Efficiency and Flow schließlich misst die Fähigkeit, Arbeit mit minimalen Unterbrechungen und Wartezeiten abzuschließen — der Anteil ungestörter Fokuszeit, die Wartezeit zwischen Pipeline-Schritten, die Häufigkeit von Kontextwechseln. Das Kernprinzip von SPACE: Wählen Sie Metriken aus mindestens drei der fünf Dimensionen und niemals eine einzelne Zahl, denn jede isolierte Kennzahl wird zwangsläufig manipuliert.

Was DX Core 4 misst

DX Core 4 ist das jüngste der drei Frameworks und entstand mit dem Ziel, die wissenschaftliche Tiefe von SPACE mit der Anschlussfähigkeit von DORA an die Geschäftsführung zu verbinden. Es konsolidiert DORA und SPACE in vier Dimensionen, die sich bewusst auch an ein nicht-technisches Führungspublikum kommunizieren lassen — ohne die analytische Substanz zu verlieren.

Speed erfasst die Geschwindigkeit der Wertlieferung, gemessen vor allem an der Zahl ausgelieferter Pull Requests pro Entwickler und Woche sowie an der Lead Time. Diese Dimension verlängert die DORA-Throughput-Logik konsequent. Effectiveness misst, wie wirksam die Arbeitsumgebung ist — wie reibungslos Entwickler ihre Arbeit erledigen können, prominent über den sogenannten Developer Experience Index, der Feedback-Loops, kognitive Last und Flow-Zustand zu einer interpretierbaren Kennzahl verdichtet.

Quality erfasst die Stabilität und Wartbarkeit des Ausgelieferten — hier leben die DORA-Stabilitätsmetriken weiter, ergänzt um die wahrgenommene Codequalität und die operative Belastung durch Incidents. Business Impact schließlich schlägt die Brücke zum Geschäftswert: Welcher Anteil der Engineering-Kapazität fließt tatsächlich in neue, kundenwirksame Funktionalität gegenüber Wartung, ungeplanter Arbeit und Reibung? Diese vierte Dimension ist der Grund, warum DX Core 4 in Vorstandsgesprächen funktioniert, wo reine DORA-Werte oft als „technisch" abgetan werden.

Der entscheidende konzeptionelle Beitrag von DX Core 4 sind drei Wirkfaktoren, die quer zu den vier Dimensionen liegen und erklären, warum Teams trotz guter DORA-Werte stagnieren: Feedback-Loops (wie schnell ein Entwickler erfährt, ob seine Änderung funktioniert), Cognitive Load (wie viel mentale Anstrengung das Verstehen und Ändern des Systems kostet) und Flow State (wie häufig ungestörtes, konzentriertes Arbeiten gelingt). Diese drei Faktoren sind genau das, was DORA strukturell nicht erfassen kann — und genau das, was über Top-Quartil-Performance entscheidet.

DORA, SPACE und DX Core 4 im direkten Vergleich

Die drei Frameworks sind keine konkurrierenden Schulen, sondern aufeinander aufbauende Abstraktionsebenen. DORA liefert die belastbarste, am leichtesten zu instrumentierende Basis. SPACE liefert die wissenschaftliche Breite und schützt vor dem klassischen Fehler, eine einzige Zahl zu optimieren. DX Core 4 liefert die geschäftsfähige Synthese, die in Budget- und Strategiegesprächen Bestand hat. Die folgende Tabelle stellt die drei Modelle nach ihrer Funktion, ihrem Messgegenstand, ihrer Stärke und ihrer strukturellen Grenze gegenüber.

Lesen Sie die Tabelle nicht als Auswahlhilfe, bei der ein Framework gewinnt. Lesen Sie sie als Schichtenmodell: Sie brauchen alle drei, weil jede Schicht eine Schwäche der darunter liegenden kompensiert. Ein reines DORA-System ist blind für Burnout. Ein reines SPACE-System ist schwer zu instrumentieren und in der Geschäftsführung schwer zu kommunizieren. Ein reines DX-Core-4-System ohne saubere DORA-Datenbasis schwebt argumentativ in der Luft.

Die Verschiebung von Usage zu Adoption

Eine der wichtigsten Verschiebungen in der Messpraxis 2026 betrifft die Frage, was als Erfolg eines internen Werkzeugs oder einer Plattform gilt. Lange galt Usage als ausreichender Beleg: Wie viele Teams nutzen die neue CI-Pipeline, wie viele Repositories liegen auf der internen Entwicklerplattform, wie hoch ist die Loginrate des neuen Self-Service-Portals? Diese Logik ist trügerisch, weil erzwungene oder alternativlose Nutzung als Erfolg fehlinterpretiert wird.

Adoption ist der strengere Maßstab. Adoption fragt nicht, ob ein Werkzeug genutzt wird, sondern ob es freiwillig, wiederkehrend und mit messbarem Produktivitätsgewinn genutzt wird — und ob die Entwickler die Nutzung weiterempfehlen würden. Der prägnante Leitsatz dieser Verschiebung lautet: Adoption muss verdient werden. Eine Plattform, die nur deshalb hundertprozentige Nutzung hat, weil es keine Alternative gibt, hat keine Adoption erreicht, sondern lediglich einen Zwang etabliert.

Für das Messsystem hat diese Verschiebung konkrete Folgen. Ergänzen Sie reine Nutzungszähler um Adoptionssignale: den Anteil der Teams, die ein internes Werkzeug freiwillig gegenüber einer Eigenbaulösung wählen, die Weiterempfehlungsbereitschaft im Entwickler-Survey, und vor allem die Differenz der DX-Core-4-Effectiveness zwischen Teams mit und ohne Plattformnutzung. Wenn die Plattform Adoption verdient hat, ist dieser Unterschied messbar positiv. Wenn nicht, deckt genau diese Differenz die Illusion auf, die eine reine Usage-Zahl verschleiert hätte.

Dieser Punkt verbindet den Messdiskurs direkt mit dem DevOps-Maturity-Cluster: Eine reife DevOps-Organisation erkennt man nicht an der Existenz einer internen Plattform, sondern daran, dass deren Adoption messbar verdient ist und sich in den Effectiveness- und Flow-Signalen niederschlägt.

Der pragmatische Mess-Bauplan

Die häufigste Art, dieses Thema zu verfehlen, ist der Versuch, alle drei Frameworks gleichzeitig vollständig einzuführen. Das Ergebnis ist ein überladenes Dashboard, das niemand interpretiert. Der folgende Bauplan ist bewusst sequenziell und baut auf einer bereits etablierten DORA-Basis auf, wie sie der DORA-Metriken-Leitfaden beschreibt. Wer noch keine DORA-Baseline hat, beginnt dort — nicht hier.

Jeder Schritt liefert für sich genommen Wert. Brechen Sie nach Schritt drei ab, wenn die Kapazität fehlt: Sie haben dann immer noch ein deutlich besseres Messsystem als reine DORA-Werte. Vollständigkeit ist ein Ziel, kein Eintrittspreis.

1. 1DORA-Basis verifizieren: Bestätigen Sie, dass die vier DORA-Metriken seit mindestens vier Wochen sauber und automatisiert erhoben werden. Diese Daten bilden die Quality- und Speed-Säule der späteren DX-Core-4-Sicht — ohne sie ist jeder weitere Schritt fundamentlos.
2. 2Eine SPACE-Wohlbefindens-Sonde ergänzen: Führen Sie einen kurzen, wiederkehrenden Entwickler-Survey ein (vier bis sechs Fragen, monatlich), der Satisfaction and Well-being erfasst — Zufriedenheit mit Werkzeugen, wahrgenommene Reibung, Burnout-Signal. Das ist der billigste Frühindikator, den es gibt, und füllt die größte DORA-Blindstelle.
3. 3Den DX-Core-4-Effectiveness-Index aufsetzen: Verdichten Sie aus dem Survey plus zwei, drei Systemmetriken einen Developer Experience Index, der explizit Feedback-Loop-Geschwindigkeit, kognitive Last und Flow-Zustand abbildet. Dieser eine zusammengesetzte Wert ist die wirksamste einzelne Ergänzung zu DORA.
4. 4Communication und Flow instrumentieren: Messen Sie aus vorhandenen Systemdaten zwei Reibungssignale — die Zeit, bis ein Pull Request seinen ersten Review erhält, und den Anteil ungestörter Fokuszeit pro Entwicklerwoche. Beide Werte erklären DORA-Lead-Time-Ausreißer, die die Pipeline allein nicht erklärt.
5. 5Business Impact verankern: Schätzen Sie die Kapazitätsaufteilung zwischen neuer kundenwirksamer Funktionalität, Wartung und ungeplanter Arbeit. Diese eine Zahl übersetzt das gesamte Messsystem in eine Sprache, die in Budget- und Strategiegesprächen Bestand hat.
6. 6Von Usage auf Adoption umstellen: Ersetzen Sie auf jedem Plattform- und Werkzeug-Dashboard reine Nutzungszähler durch Adoptionssignale — freiwillige Wahl, Weiterempfehlungsbereitschaft, gemessener Effectiveness-Unterschied zwischen Nutzern und Nicht-Nutzern.
7. 7Im Dreiklang reviewen, nicht isoliert: Etablieren Sie einen monatlichen Review, der DORA, die SPACE-Sonde und die DX-Core-4-Sicht nebeneinander liest. Eine isolierte Zahl löst keine Entscheidung aus — nur das Muster über alle drei Ebenen tut das.

Anti-Muster, die das ganze System entwerten

Die Erweiterung des Messsystems über DORA hinaus vergrößert auch die Angriffsfläche für Fehlanwendungen. Drei Anti-Muster zerstören den Wert zuverlässiger als jede Messlücke.

Das erste ist die Individualbewertung. Sobald SPACE-Satisfaction oder DX-Core-4-Speed an einzelne Personen geknüpft und in Beurteilungen verwendet werden, kippt das System sofort. Entwickler optimieren dann die beobachtete Zahl statt das zugrunde liegende System — ein Effekt, der bei den weichen SPACE-Dimensionen noch schädlicher ist als bei DORA, weil Wohlbefindens-Surveys nur ehrlich beantwortet werden, wenn sie folgenlos für die Person bleiben. Diese Metriken sind ein Kompass für das System, niemals ein Bewertungsinstrument für Menschen.

Das zweite ist die Einzelzahl-Verdichtung über alles. Der Developer Experience Index ist innerhalb der Effectiveness-Dimension nützlich, aber die Versuchung, ihn zu einer einzigen Produktivitäts-Gesamtnote zu verschmelzen, widerspricht dem Kernprinzip von SPACE direkt. Eine einzige Zahl ist immer manipulierbar und immer kontextlos.

Das dritte ist der Kontextvergleich ohne Kontext. Ein Plattform-Team und ein produktnahes Feature-Team haben naturgemäß unterschiedliche Profile über alle drei Frameworks hinweg. Der einzig valide Vergleich ist der eines Teams mit seinem eigenen Trend über die Zeit — exakt dieselbe Disziplin, die schon der DORA-Metriken-Leitfaden einfordert, hier nur über mehr Dimensionen.

So entstehen Top-Quartil-Teams

Die belastbare Beobachtung aus der Forschung hinter diesen Frameworks ist nicht, dass eine bestimmte Metrik gut sein muss. Sie ist, dass Teams im obersten Quartil systematisch über mehrere Dimensionen gleichzeitig führen — und dass dieser kombinierte Vorsprung sich auf einen Faktor von rund vier bis fünf gegenüber dem Mittelfeld summiert. Dieser Vorsprung entsteht nicht durch eine einzelne Optimierung, sondern dadurch, dass die unterstützenden Praktiken — schnelle Feedback-Loops, niedrige kognitive Last, geschützte Flow-Zeit — gleichzeitig adressiert werden.

Genau das erklärt, warum reine DORA-Optimierung irgendwann an eine Decke stößt. Ein Team kann seine Deployment Frequency durch Automatisierung verbessern, bis die Pipeline schnell ist — danach liegt der Engpass nicht mehr in der Pipeline, sondern davor: im Verständnis des Systems, in der Wartezeit auf Reviews, in der zerstückelten Fokuszeit. Diese Engpässe sieht ausschließlich die SPACE- und DX-Core-4-Schicht. Wer nur DORA misst, optimiert weiter an einer Pipeline, die längst nicht mehr der Flaschenhals ist.

In einer Welt, in der KI-Assistenten den reinen Schreibakt beschleunigen, verschärft sich dieser Effekt. Der Schreibengpass schrumpft, der Verständnis- und Integrationsengpass wächst. Throughput-Metriken können dabei sogar besser aussehen, während das geteilte mentale Systemmodell erodiert. Genau diese Divergenz — DORA steigt, Effectiveness und Flow sinken — ist das wertvollste Frühwarnsignal, das ein kombiniertes Messsystem liefern kann, und es ist mit reinen DORA-Werten strukturell unsichtbar.

Die praktische Konsequenz ist nüchtern: Behalten Sie die DORA-Basis, wie sie der DORA-Metriken-Leitfaden beschreibt, und nutzen Sie den DORA-Report 2025 als aktuelle Referenz dafür, warum Stabilität und Verständnis unter KI-Einsatz unter Druck geraten. Legen Sie dann die SPACE-Wohlbefindens-Sonde und den DX-Core-4-Effectiveness-Index darüber. Verankern Sie den Dreiklang im DevOps-Maturity-Verständnis Ihrer Organisation. Der Vorsprung der Top-Quartil-Teams ist kein Geheimnis — er ist die Summe konsequent zusammen gelesener Dimensionen.

Quellen & Referenzen

Die in diesem Artikel referenzierten Frameworks, Definitionen und Befunde basieren auf den folgenden Quellen:

• The SPACE of Developer Productivity — Forsgren, Storey, Maddila, Zimmermann, Houck, Butler (ACM Queue, 2021)
• DX Core 4 — A Unified Framework for Engineering Productivity (DX / getDX): https://getdx.com/research/measuring-developer-productivity-with-the-dx-core-4
• DORA — DevOps Research and Assessment (Google): https://dora.dev/
• State of DevOps Report 2025 — DORA / Google Cloud: https://cloud.google.com/devops
• Platform Engineering 2026 — Verschiebung von Usage zu Adoption (Branchenanalysen): https://platformengineering.com/