Engineering-Produktivität messen ohne Vanity-Metrics
Wie misst man Engineering-Produktivität richtig?
Nicht über eine einzelne Zahl. Wer Engineering-Produktivität ehrlich messen will, kombiniert drei Ebenen: Flow (wie schnell und stabil liefert das System — DORA), Outcome (entsteht Business Value oder nur Beschäftigung) und Experience (können Entwickler überhaupt produktiv arbeiten — SPACE). Einzelmetriken wie Lines of Code, Commit-Zahlen oder Story Points sind Vanity-Metrics: leicht zu erheben, leicht zu manipulieren und fast immer irreführend.
Die Vanity-Metrics-Falle
Fast jede Engineering-Organisation misst irgendetwas. Das Problem ist selten „zu wenig Daten" — es ist, dass die falschen Dinge gemessen werden, weil sie leicht zu zählen sind. Lines of Code, Anzahl der Commits, geschlossene Tickets, Story-Point-Velocity, geleistete Stunden: Sie alle haben dasselbe Muster. Sie messen Aktivität, nicht Wirkung.
Sobald eine dieser Zahlen zum Ziel wird, hört sie auf, ein gutes Maß zu sein — das ist Goodharts Gesetz, und in Engineering-Teams greift es schneller als überall sonst. Belohnen Sie Commits, bekommen Sie viele kleine Commits. Belohnen Sie Velocity, werden Schätzungen aufgebläht. Belohnen Sie geschlossene Tickets, wird der schwierige, wertvolle Bug liegengelassen.
| Vanity-Metrik | Was sie vorgibt zu messen | Was wirklich passiert |
|---|---|---|
| Lines of Code | Produktivität | Belohnt aufgeblähten Code; die beste Lösung löscht oft Zeilen |
| Commit-Zahl | Engagement | Lässt sich trivial gamen; sagt nichts über Wert |
| Story-Point-Velocity | Output-Geschwindigkeit | Relative Schätzung, kein Maß — als KPI führt sie zu Inflation |
| Geschlossene Tickets | Durchsatz | Bevorzugt viele kleine Aufgaben gegenüber wenigen wichtigen |
| Geleistete Stunden | Einsatz | Misst Anwesenheit; korreliert nicht mit Ergebnissen |
Ebene 1 — Flow: Was DORA richtig macht
Die vier DORA-Metriken (aus dem DevOps Research and Assessment Programm) sind das beste verfügbare Maß für die Lieferfähigkeit eines Systems — und entscheidend: Sie sind Team-Metriken, keine Einzelpersonen-Rankings. Sie messen das System, nicht den Menschen.
Deployment-Frequenz
Wie oft bringen Sie Änderungen in Produktion? Häufige, kleine Deployments sind ein Zeichen für gesunde Automatisierung und geringes Risiko pro Release.
Lead Time for Changes
Wie lange vom Commit bis in Produktion? Kurze Lead Times bedeuten kurze Feedback-Schleifen — die eigentliche Quelle von Geschwindigkeit.
Change-Failure-Rate
Welcher Anteil der Deployments verursacht einen Fehler? Hält die Wahrheit im Blick: Tempo ohne Stabilität ist nur verschobene Arbeit.
Time to Restore (MTTR)
Wie schnell erholen Sie sich von einem Ausfall? Resilienz ist eine Fähigkeit — und sie ist messbar.
Warum funktioniert das, wo LoC versagt? Weil die vier Metriken in Spannung zueinander stehen. Man kann nicht einfach schneller deployen, ohne dass die Failure-Rate die Rechnung präsentiert. Genau diese eingebaute Balance macht DORA schwer zu gamen.
Warum DORA-Metriken allein nicht reichen
DORA misst, wie gut Sie liefern — aber nicht, ob Sie das Richtige liefern, und nicht, wie es sich anfühlt, in diesem Team zu arbeiten. Ein Team kann exzellente DORA-Werte haben und trotzdem am Markt vorbei bauen oder leise ausbrennen. Deshalb braucht es zwei weitere Ebenen.
Outcome statt Output
Die Frage ist nicht „Wie viel wurde gebaut?", sondern „Wohin floss die Energie?". Ein ehrlicher Investment-Mix — Features vs. Bugs vs. Maintenance vs. Ops, gerollt nach Produktbereich — ist oft die aufschlussreichste Zahl im ganzen Unternehmen.
Sie beantwortet die CFO-Frage „Wo ist das Engineering-Budget geblieben?" mit verteidigbaren Daten statt mit einem Schulterzucken.
Experience: das SPACE-Framework
SPACE (von den Autorinnen und Autoren hinter DORA) erinnert daran, dass Produktivität mehrdimensional ist: Satisfaction, Performance, Activity, Communication, Efficiency & Flow.
Kernidee: Kombinieren Sie immer mindestens zwei Dimensionen — und mischen Sie objektive Signale (System-Daten) mit subjektiven (Entwickler-Sentiment). Eine einzelne Dimension lügt.
Der 2026er-Twist: KI bricht die alten Velocity-Zahlen
Mit Claude Code, Cursor und internen Copilots haben sich die alten Annahmen aufgelöst. Wenn ein Entwickler in einer Stunde produziert, wofür früher ein Tag nötig war, sind Commit-Zahlen und LoC endgültig wertlos — sie steigen, während ihre Aussagekraft auf null fällt.
KI verschiebt den Engpass von Code schreiben zu Code prüfen, integrieren und verantworten. Wer 2026 ehrlich messen will, muss zwei Dinge zusätzlich sehen: wo KI tatsächlich eingesetzt wird (und zu welchen Kosten) und ob die Qualität mithält — sonst optimieren Sie Geschwindigkeit auf Kosten der Change-Failure-Rate, ohne es zu merken.
Velocity-Metriken, die KI ignorieren, sind 2026 schlicht falsch. Die richtigen Maße bleiben dieselben — Flow, Outcome, Experience — aber die Signalquellen müssen die KI-augmentierte Realität einschließen.
Die wichtigste Regel: Metriken nicht zu Waffen machen
Selbst die besten Metriken richten Schaden an, wenn man sie auf die falsche Ebene zieht. Drei Leitplanken, die wir in jedem Team durchsetzen:
System-Metriken nicht auf Einzelpersonen anwenden. DORA bewertet die Lieferpipeline, nicht „Entwickler X". Individuelle Rankings aus Aktivitätsdaten erzeugen Angst und falsches Verhalten — kein besseres Engineering.
Metriken sind Gesprächsanlässe, keine Urteile. Eine ungewöhnliche Zahl ist eine Frage („Was blockiert hier?"), nicht eine Antwort. Der Wert entsteht im 1:1, nicht im Dashboard.
Faire Reviews brauchen mehrere Quellen. Code, Reviews, Kollaboration und Wachstum gehören zusammen betrachtet — mit Bias-Checks. Eine einzige Zahl als Grundlage einer Beförderung ist nie fair.
Vom Konzept zur Praxis
Das alles lässt sich von Hand bauen — viele Teams ziehen sich DORA-Werte aus GitHub-Exporten, pflegen Sentiment in einer Tabelle und mischen 1:1-Notizen aus einem privaten Notizbuch dazu. Das funktioniert, kostet aber jede Woche Zeit, die eigentlich ins Coaching gehört. Genau dafür haben wir DevInsight gebaut — das Visibility-Modul unserer Engineering Intelligence Platform.
DevInsight zieht DORA aus echten Repository-Daten, verbindet Git, Jira, Claude Code, Cursor, 1:1-Notizen und Peer-Feedback in vier Linsen (Individual, Team, Department, Business Value) und schlägt über den Manager Copilot konkrete 1:1-Themen vor — geerdet in tatsächlichen Arbeitsmustern. Gehostet als SaaS in Frankfurt, EU-Datenresidenz, DSGVO by Design. Sie müssen die Frameworks oben also nicht selbst verdrahten — oder Sie tun es, und nutzen diesen Artikel als Bauplan.
Die Kurzfassung für Ihr nächstes Review
- ✓ Keine Einzelmetrik zum Ziel machen — Goodharts Gesetz schlägt zuverlässig zu.
- ✓ Drei Ebenen kombinieren: Flow (DORA), Outcome (Investment-Mix), Experience (SPACE).
- ✓ System-Metriken auf Teams anwenden, nie als Einzel-Ranking.
- ✓ Objektive und subjektive Signale mischen — eine Dimension lügt.
- ✓ KI-Nutzung und Qualität explizit messen — alte Velocity-Zahlen sind 2026 wertlos.
- ✓ Metriken als Gesprächsanlass behandeln, nicht als Urteil.
Diese Ebenen ohne Tabellen-Chaos sehen?
DevInsight ist im Closed Alpha — erster Monat kostenlos, geführtes Onboarding, SaaS in Frankfurt. Oder buchen Sie eine Demo und wir gehen Ihre konkreten Signale gemeinsam durch.
