„Wir brauchen ein Dashboard zur Lieferfähigkeit unserer Entwicklungsteams.“ Diese Anforderung landet früher oder später in fast jeder IT-Organisation auf dem Tisch.
Die Reaktion ist meist reflexartig: Welche Metriken nehmen wir? Lead Time? Cycle Time? Deployment Frequency? Velocity? Throughput? Die Diskussion dreht sich schnell um technische Details und Tool-Auswahl. Doch eine entscheidende Frage wird selten gestellt: Wozu messen wir überhaupt? Und noch wichtiger: Für wen?
Das Problem ist nicht, dass zu wenig gemessen wird. Das Problem ist, dass zu oft gemessen wird, ohne zu verstehen, was das Ziel der Messung sein soll. Metriken werden eingeführt, weil „man das halt so macht“, weil ein Artikel darüber geschrieben wurde oder weil der Konkurrent auch ein Dashboard hat. Das Ergebnis sind Zahlenkolonnen, die niemand versteht, die keiner nutzt oder die – im schlimmsten Fall – aktiv schaden, weil sie falsche Anreize setzen.
Eine Metrik ist nicht gut oder schlecht an sich. Sie ist ein Werkzeug. Und wie bei jedem Werkzeug gilt, dass man wissen muss, wofür man es benutzt, bevor man es in die Hand nimmt. Ein Hammer ist perfekt für Nägel, aber katastrophal für Schrauben. Genauso verhält es sich mit Metriken zur Lieferfähigkeit. Was für die Geschäftsführung sinnvoll ist, kann für das Entwicklungsteam irrelevant sein. Was dem Product Owner hilft, kann den CTO in die Irre führen.
Dieser Artikel legt das Fundament für die Auswahl konkreter Kennzahlen. Keine Listen von Metriken, keine Dashboard-Vorlagen, keine Tool-Empfehlungen. Stattdessen liegt der Fokus auf den Grundfragen. Wer braucht welche Informationen? Was sind legitime Gründe für Messungen? Wo liegen die Fallstricke? Und wie wählt man Metriken aus, die tatsächlich helfen, statt zu schaden? Erst wenn diese Fragen geklärt sind, hat es Sinn, über konkrete Zahlen zu sprechen.
„Das Management will wissen, wie schnell wir liefern.“ Dieser Satz klingt einfach, ist aber irreführend. „Das Management“ ist keine homogene Gruppe mit einem einheitlichen Informationsbedürfnis. Die Geschäftsführung interessiert sich für völlig andere Aspekte als der VP Engineering. Der Product Owner braucht andere Daten als das Entwicklungsteam. Wer Metriken auswählt, ohne zu verstehen, für wen sie gedacht sind, produziert Rauschen statt Signale.
Die Geschäftsführung operiert auf strategischer Ebene. Ihre Fragen drehen sich um das große Bild: Können wir unsere Roadmap-Commitments gegenüber Kunden und Investoren einhalten? Wie schnell können wir auf Marktveränderungen reagieren? Rechtfertigt die Softwareentwicklung ihr Budget? Wo sind strukturelle Bottlenecks, die das Wachstum bremsen? Diese Zielgruppe braucht hoch aggregierte Daten, die Trends über Quartale zeigen und einen klaren Zusammenhang zu Geschäftszielen haben. Details über einzelne Features oder Teams sind hier nicht nur unnötig, sondern lenken nur ab. Der Zeitrahmen ist quartalsweise, manchmal monatlich. Die Frage ist nicht „Warum dauert Feature X so lange?“, sondern „Werden wir im nächsten Quartal lieferfähiger?“.
Der CTO oder VP Engineering steht eine Ebene tiefer und trägt operative Verantwortung. Hier werden Fragen konkreter: Welche Teams performen gut, welche brauchen Unterstützung? Wo liegen systemische Probleme, die mehrere Teams betreffen? Wie wirken sich technische Investitionen aus, wie in CI/CD-Pipelines oder Test-Infrastruktur? Wie schneiden wir im Vergleich zu Benchmarks ab? Diese Ebene braucht Daten auf Team-Ebene, idealerweise mit der Möglichkeit, tiefer zu bohren. Der Zeitrahmen ist wöchentlich bis monatlich. Die Aufgabe ist operative Steuerung: Ressourcen umverteilen, Investitionen priorisieren, Hindernisse aus dem Weg räumen. Aber Vorsicht, denn hier lauert die Gefahr des Team-Vergleichs. Jedes Team ist unterschiedlich und hat unterschiedliche Domänen, Technologien und Komplexitäten. Ein direkter Vergleich ohne Kontext führt in die Irre.
Product Owner und Product Manager haben einen anderen Fokus: Planbarkeit. Ihre Fragen sind: Wann ist Feature X fertig? Wie zuverlässig sind unsere Prognosen? Wo blockieren Dependencies die Auslieferung? Wie können wir den Durchsatz erhöhen, ohne Qualität zu opfern? Diese Rolle lebt davon, Stakeholdern verlässliche Aussagen zu machen. Transparenz über den aktuellen Stand und realistische Vorhersagen sind Gold wert. Der Zeitrahmen ist kurz: iterationsbasiert, manchmal täglich. Die Detailtiefe geht bis auf Feature- oder Epic-Ebene. Hier helfen aggregierte Team-Daten wenig. Es geht um konkrete Items und deren Fortschritt.
Team Leads und Coaches kümmern sich um Prozessverbesserung und Team-Entwicklung. Ihre Fragen: Wo hakt es im Prozess? Welche Impediments tauchen strukturell immer wieder auf? Verbessern sich unsere Durchlaufzeiten? Sind wir im Flow, oder gibt es ständige Unterbrechungen? Diese Rolle nutzt Metriken, um Input für Retrospektiven zu liefern und Verbesserungsmaßnahmen zu priorisieren. Der Zeitrahmen ist täglich bis wöchentlich. Die Detailtiefe ist hoch. Oft geht es um einzelne Items und deren Weg durch den Prozess. Das Ziel ist nicht Kontrolle, sondern Befähigung, um dem Team zu helfen, besser zu werden.
Das Entwicklungsteam selbst ist oft die vergessene Zielgruppe. Dabei sind Teams diejenigen, die am meisten von guten Metriken profitieren können, wenn sie Ownership über ihre Daten haben. Ihre Fragen sind praktisch: Wo verlieren wir Zeit? Werden wir besser? Was blockiert uns konkret? Wo können wir mit wenig Aufwand viel gewinnen? Teams brauchen Transparenz über ihre eigene Arbeit, in Echtzeit oder zumindest täglich. Die Daten sollten granular sein und dem Team helfen, autonom Entscheidungen zu treffen. Wichtig: Wenn Metriken nur „von oben“ konsumiert werden, entsteht das Gefühl von Kontrolle statt Unterstützung. Teams müssen die ersten Nutznießer ihrer eigenen Daten sein.
Die zentrale Erkenntnis: Es gibt nicht „die eine Metrik“ oder „das eine Dashboard“ für Lieferfähigkeit. Unterschiedliche Stakeholder haben unterschiedliche Fragen, unterschiedliche Zeithorizonte und unterschiedliche Detailbedarfe. Wer versucht, alle mit den gleichen Zahlen zu bedienen, bedient am Ende niemanden richtig.
Die Frage „Wozu messen wir?“ klingt banal. Die Antworten sind es nicht. Denn hinter jeder Messung steht eine Absicht und diese Absicht bestimmt, ob die Metrik hilft oder schadet.
Beginnen wir mit den legitimen Gründen. Der offensichtlichste ist Transparenz. Softwareentwicklung ist komplex und für Außenstehende oft eine Black Box. Stakeholder sehen Input (Budget, Menschen, Zeit) und Output (Features), aber nicht, was dazwischen passiert. Metriken machen Arbeit sichtbar. Sie zeigen, wo Zeit hingeht, wo Engpässe liegen und warum manche Dinge länger dauern als erwartet. Das schafft Verständnis für Komplexität und Unsicherheit. Transparenz ermöglicht ehrliche Gespräche über Kapazität, Prioritäten und realistische Commitments. Sie verhindert, dass „Warum dauert das so lange?“ zur Standardfrage wird, weil die Antwort bereits sichtbar ist.
Ein weiterer guter Grund ist Verbesserung. Ohne Daten ist Verbesserung Glückssache. Wo liegen Bottlenecks? Welche Prozessänderungen haben gewirkt? Wo verschwenden wir Zeit? Continuous Improvement braucht Daten als Grundlage. Nicht um zu bewerten, sondern um zu lernen. Teams, die ihre Durchlaufzeiten messen, können gezielt Experimente machen: Was passiert, wenn wir Work-in-Progress begrenzen? Wie wirkt sich Pair Programming auf Qualität und Geschwindigkeit aus? Daten ersetzen Bauchgefühl durch Evidenz. Das ist besonders wertvoll in Diskussionen über Investitionen: Lohnt sich der Ausbau der Test-Infrastruktur? Die Antwort zeigt sich in den Metriken.
Vorhersagbarkeit ist ein dritter zentraler Grund. Stakeholder wollen wissen, wann etwas fertig wird. Nicht aus Ungeduld, sondern weil sie darauf aufbauen müssen: Marketing plant Kampagnen, Vertrieb macht Zusagen, andere Teams warten auf Features. Metriken ermöglichen verlässlichere Forecasts. Statt „irgendwann im nächsten Quartal“ kann es heißen „mit 70 % Wahrscheinlichkeit in Kalenderwoche 23“. Das ist nicht Hellseherei, sondern Empirie: Wenn die letzten 50 Features im Durchschnitt 8 Tage dauerten, ist das eine bessere Basis als Daumendrücken. Vorhersagbarkeit erleichtert Stakeholder-Management erheblich und reduziert Druck auf Teams.
Der vierte legitime Grund ist Koordination. In Organisationen mit mehreren Teams entstehen Dependencies. Team A wartet auf Team B. Feature X blockiert Feature Y. Ohne Transparenz über den Stand der Arbeit wird Koordination zum Ratespiel. Metriken können sichtbar machen, wer auf wen wartet und wo Synchronisation nötig ist. Das ist kein Micromanagement, sondern Ermöglichung von Autonomie: Teams können selbst sehen, wo sie andere blockieren oder blockiert werden.
Doch nicht alle Motive sind legitim. Manche Gründe für Messungen sind aktiv schädlich.
Individuelle Performance-Messung steht ganz oben auf dieser Liste. „Wer ist der produktivste Entwickler?“ Diese Frage wird erschreckend oft gestellt. Das Problem: Softwareentwicklung ist Teamarbeit. Einzelleistungen zu messen, zerstört Kollaboration. Wenn Entwickler an individuellen Metriken gemessen werden, hören sie auf, sich gegenseitig zu helfen. Code Reviews werden oberflächlich, weil sie nicht zur eigenen Metrik beitragen. Wissenstransfer leidet, weil Mentoring nicht gemessen wird. Das SPACE-Framework warnt explizit davor, Produktivität auf Individualebene zu messen. Teams sind die relevante Einheit und nicht Einzelne.
Teamvergleiche ohne Kontext sind ähnlich problematisch. „Warum ist Team A schneller als Team B?“ Die Frage suggeriert, dass Teams vergleichbar sind. Das sind sie nicht. Team A arbeitet vielleicht an neuer Funktionalität in einem modernen Stack. Team B pflegt Legacy-Code in einer 15 Jahre alten Codebasis. Team A hat drei Seniors, Team B ist frisch zusammengestellt. Das sind Äpfel und Birnen. Vergleiche ohne Kontext schaffen perverse Anreize: Teams wählen bewusst einfache Aufgaben, um in Rankings besser dazustehen. Und die Folge ist, dass niemand mehr an schwierigen, aber wichtigen Problemen arbeiten will.
Mikromanagement ist ein weiteres problematisches Motiv. „Warum ist Ticket X noch nicht fertig?“ Diese Frage täglich zu stellen, ist kein Management, sondern Belästigung. Wenn Metriken dazu genutzt werden, ständig nachzufragen und Druck aufzubauen, entsteht Overhead: Teams verbringen mehr Zeit mit Reporting und Rechtfertigungen als mit Arbeit. Das Vertrauen schwindet. Und die Metriken selbst werden unbrauchbar, weil Teams anfangen, sie zu manipulieren, um Ruhe zu haben.
Bonus- oder Gehaltskopplung ist der sichere Weg, Metriken zu zerstören. Sobald eine Kennzahl die Grundlage für finanzielle Incentives wird, hört sie auf, aussagekräftig zu sein. Das ist Goodharts Law in Reinform: Wenn ein Maßstab zum Ziel wird, hört er auf, ein guter Maßstab zu sein. Teams werden kreativ darin, Zahlen gut aussehen zu lassen, ohne dass sich die zugrunde liegende Realität verbessert. Widerstände gegen Messungen sind oft eine direkte Folge solcher Praktiken.
Der letzte problematische Grund sind Cargo Cult Metrics: „Wir messen, weil alle messen.“ Metriken ohne Ziel, nur weil „man das halt so macht“, weil es in einem Blog-Post empfohlen wurde oder weil der Konkurrent auch ein Dashboard hat. Das Ergebnis sind Daten, die niemand nutzt, die aber dennoch Aufwand verursachen für die Erhebung, die Pflege, die Diskussion. Metriken brauchen einen Zweck. Ohne Zweck sind sie Verschwendung.
Die Absicht hinter der Messung ist entscheidend. Die gleiche Metrik kann hilfreich oder zerstörerisch sein, je nachdem, wofür sie genutzt wird.
Selbst mit guten Absichten können Metriken nach hinten losgehen. Es gibt typische Fallstricke, die immer wieder auftreten und die sich vermeiden lassen, wenn man sie kennt.
Goodharts Law ist der Klassiker: „When a measure becomes a target, it ceases to be a good measure.“ Sobald eine Metrik zum Ziel erklärt wird, verliert sie ihre Aussagekraft. Ein Beispiel: Lead Time soll reduziert werden. Teams reagieren, indem sie Tickets künstlich kleinspalten. Aus einem komplexen Feature werden zehn Micro-Tasks. Die Lead Time sinkt. Aber nicht, weil der Prozess besser wurde, sondern weil das Spiel verändert wurde. Ähnlich bei Deployment Frequency: Wird sie zum Ziel, gibt es plötzlich viele bedeutungslose Deployments. Ein Tippfehler in der Dokumentation? Deploy. Eine Logging-Anpassung? Deploy. Die Zahl steigt, aber die tatsächliche Lieferfähigkeit nicht. Die Lösung: Metriken als Indikatoren nutzen, nie als Ziele. Sie zeigen, ob man auf dem richtigen Weg ist. Sie sind nicht der Weg selbst.
Der Streetlight-Effekt beschreibt die Tendenz, das zu messen, was einfach zu messen ist, und nicht das, was wichtig ist. Das ist die Geschichte vom Betrunkenen, der seinen Schlüssel unter der Laterne sucht, weil es dort heller ist, obwohl er ihn woanders verloren hat. In der Softwareentwicklung wäre das z. B. die Zählung von Commits, was einfach ist, aber aussagelos. Code-Zeilen als Produktivitätsmaß zu nehmen, ist trivial, aber absurd. Schwer messbare Faktoren – Code-Qualität, Wissenstransfer, Teamdynamik – werden ignoriert, weil sie keine schöne Zahl in einem Dashboard ergeben. Das Problem: Was nicht gemessen wird, wird nicht beachtet. Wenn nur das Einfache gemessen wird, wird das Wichtige unsichtbar. Die Lösung: Bewusst auch qualitative Aspekte einbeziehen, auch wenn sie aufwendiger zu erheben sind.
Vanity Metrics sind Zahlen, die gut aussehen, aber nichts bedeuten. „Wir haben 200 Features ausgeliefert!“ klingt beeindruckend. Aber wenn niemand sie nutzt, ist es irrelevant. „Velocity ist um 30 % gestiegen!“ Aber wenn nichts in Produktion geht, weil alles in QA hängt, ist es eine Illusion. Vanity Metrics fühlen sich gut an, weil die Zahlen nach oben gehen. Aber sie korrelieren nicht mit echtem Fortschritt. Die Lösung: Fokus auf Outcomes, nicht Outputs. Nicht „Wie viel haben wir gebaut?“, sondern „Wie viel davon wird genutzt und bringt Wert?“.
Fehlende Kontextualisierung macht Zahlen bedeutungslos. „Lead Time: 12 Tage“ – ist das gut oder schlecht? Die Antwort ist wie so oft: Es kommt darauf an. Bei einer einfachen CRUD-Anwendung sind 12 Tage vielleicht zu lang. Bei einer hochregulierten Finanz-Software mit komplexen Compliance-Anforderungen sind 12 Tage vielleicht schnell. Ohne Kontext – Domäne, Komplexität, Teamgröße, technische Schulden – sind absolute Zahlen nutzlos. Ein Team, das von 20 Tagen auf 12 Tage kommt, hat sich massiv verbessert. Ein Team, das konstant bei 12 Tagen liegt, ist vielleicht stabil oder stagniert. Die Lösung ist die Beobachtung von Trends statt absoluter Werte. Ist es besser oder schlechter als letztes Quartal? Das ist die relevante Frage. Benchmarks mit Vorsicht nutzen. Sie können orientieren, aber nie definieren, was „gut“ ist.
Zu viele Metriken führen zu Dashboard-Overload. Niemand kann 20 Kennzahlen im Kopf behalten. Wenn jede Woche neue Zahlen präsentiert werden, verliert sich der Fokus. Was ist wirklich wichtig? Worauf soll reagiert werden? Zu viele Metriken erzeugen Rauschen statt Signale. Die Lösung: Fokus auf wenige, wesentliche Metriken. Lieber drei gut verstandene und aktiv genutzte Kennzahlen als zehn, die niemand interpretieren kann. Das Goals-Signals-Metrics-Framework hilft, von einem klaren Ziel aus die wirklich relevanten Metriken abzuleiten.
Fehlende psychologische Sicherheit ist vielleicht der gefährlichste Fallstrick. Wenn Metriken als Waffe genutzt werden – um Teams zu bewerten, zu vergleichen oder unter Druck zu setzen – wird nicht mehr ehrlich gemessen. Teams fangen an zu gamen: Tickets werden geschönt, Daten werden manipuliert, Probleme werden versteckt. Die Metriken zeigen nicht mehr die Realität, sondern eine inszenierte Version davon. Das ist nicht böswillig, sondern Selbstschutz. Wenn ehrliche Zahlen zu Sanktionen führen, hören Teams auf, ehrlich zu sein. Die Lösung: Eine Kultur schaffen, in der Probleme offen angesprochen werden können, ohne dass Schuldzuweisungen folgen. Metriken sollten Lernen ermöglichen, nicht Bestrafung.
Die meisten Probleme mit Metriken entstehen nicht durch die Metriken selbst. Sie entstehen durch ihren Missbrauch, durch fehlenden Kontext oder durch eine Kultur, die Zahlen wichtiger nimmt als Menschen.
Wie wählt man die richtigen Metriken aus? Nicht durch Nachahmung, nicht durch Bauchgefühl, sondern durch strukturiertes Nachdenken. Ein einfaches Framework hilft.
Der erste Schritt sind drei Schlüsselfragen, die vor jeder Metrik gestellt werden müssen.
Frage 1: Für wen ist diese Metrik? Siehe die Stakeholder-Übersicht oben. Eine Metrik, die dem CTO hilft, ist vielleicht für das Team irrelevant. Eine Metrik, die dem Product Owner Planungssicherheit gibt, interessiert die Geschäftsführung nicht. Unterschiedliche Zielgruppen brauchen unterschiedliche Informationen. Die Versuchung ist groß, ein Dashboard für alle zu bauen. Aber ein Dashboard für alle ist ein Dashboard für niemanden. Besser: Unterschiedliche Dashboards für unterschiedliche Bedürfnisse. Das bedeutet nicht mehr Arbeit, sondern mehr Fokus.
Frage 2: Welche Entscheidung soll die Metrik unterstützen? Das ist die entscheidende Frage. Wenn keine konkrete Entscheidung von einer Metrik abhängt, sollte sie nicht erhoben werden. „Nice to know“ ist kein triftiger Grund. Jede Metrik verursacht Aufwand für die Erhebung, die Pflege und die Interpretation. Dieser Aufwand muss sich lohnen. Ein Beispiel: Lead Time kann die Entscheidung unterstützen, ob in Prozessoptimierung investiert wird. Deployment Frequency kann die Entscheidung unterstützen, ob CI/CD-Verbesserungen priorisiert werden. Wenn die Antwort auf „Welche Entscheidung?“ nur ein Schulterzucken ist, ist die Metrik überflüssig.
Frage 3: Was ist die gewünschte Veränderung? Metriken beeinflussen Verhalten. Die Frage ist: Welches Verhalten soll gefördert werden? Welches soll vermieden werden? Könnte die Metrik manipuliert werden? Und wenn ja, wie? Diese Frage schützt vor unbeabsichtigten Konsequenzen. Wenn eine Metrik dazu führen könnte, dass Teams Qualität opfern, um schneller zu sein, ist sie gefährlich. Wenn sie dazu führen könnte, dass Kollaboration leidet, ist sie schädlich. Die gewünschte Veränderung muss klar sein und die möglichen unerwünschten Nebenwirkungen ebenso.
Der zweite Schritt ist der bereits erwähnte Goals-Signals-Metrics-Ansatz. Dieser Ansatz, entwickelt von Google, verhindert, dass Metriken zum Selbstzweck werden. Er beginnt nicht mit der Metrik, sondern mit dem Ziel.
Schritt 1: Goal definieren. Was soll erreicht werden? „Wir wollen die Lieferfähigkeit erhöhen.“ „Wir wollen die Termintreue verbessern.“ „Wir wollen Bottlenecks identifizieren.“ Das Ziel muss konkret genug sein, um daraus etwas ableiten zu können, aber nicht so spezifisch, dass es bereits eine Metrik vorgibt.
Schritt 2: Signal identifizieren. Was würde zeigen, dass das Ziel erreicht wird? Das Signal kann auch subjektiv sein: „Teams fühlen sich weniger gehetzt.“ „Stakeholder sind zufriedener mit der Planbarkeit.“ Wichtig: Das Signal ist nicht die Metrik. Es ist das, was die Metrik einfangen soll.
Schritt 3: Metrics ableiten. Erst jetzt kommt die konkrete Metrik. Wie kann das Signal gemessen werden? Vielleicht durch Lead Time. Vielleicht durch Umfragen. Vielleicht durch Forecasting Accuracy. Die Metrik ist das Werkzeug, um das Signal zu erfassen, und nicht das Ziel selbst.
Dieser Ansatz zwingt zu klarem Denken. Er verhindert, dass Metriken eingeführt werden, nur weil sie existieren oder weil andere sie nutzen.
Der dritte Schritt ist Minimum Viable Measurement, also ein schlanker Ansatz. Es ist verlockend, direkt ein umfassendes Metriken-System aufzubauen. Aber das ist riskant. Lieber mit einer einzigen, gut verstandenen Metrik beginnen. Sie richtig erheben, richtig interpretieren, richtig nutzen. Daraus lernen. Und dann iterativ erweitern. Was funktioniert? Was wird ignoriert? Was führt zu Gaming? Diese Erkenntnisse sind Gold wert. Minimum Viable Measurement bedeutet: eine Metrik gut machen, statt zehn halbherzig. Später kann erweitert werden, basierend auf echten Learnings, nicht auf Annahmen.
Metriken sind Werkzeuge zur Entscheidungsfindung, keine Selbstzwecke. Das Framework hilft, sie als das zu behandeln, was sie sind: ein Mittel zum Zweck.
Die besten Metriken nützen nichts, wenn die Kultur um sie herum toxisch ist. Es braucht Prinzipien, die sicherstellen, dass Messungen helfen statt schaden.
Prinzip 1: Metriken sind für Teams, nicht über Teams. Metriken sollten in erster Linie den Teams selbst nützen. Teams sollten Zugriff auf ihre Daten haben, sie interpretieren können und darauf basierend Entscheidungen treffen. Wenn Metriken nur „von oben“ konsumiert werden, entsteht das Gefühl von Überwachung. Wenn Teams die ersten Nutznießer sind, entsteht Ownership. Das bedeutet nicht, dass nur Teams Zugriff haben. Aber sie müssen die primäre Zielgruppe sein. Ein Team, das seine eigenen Durchlaufzeiten nicht sehen kann, während das Management täglich darauf schaut, ist falschherum aufgesetzt.
Prinzip 2: Transparenz über die Absicht. Warum wird gemessen? Diese Frage muss offen beantwortet werden. Keine heimlichen Dashboards, keine versteckte Agenda. „Diese Metrik nutzen wir, um Bottlenecks zu identifizieren, nicht um Teams zu bewerten.“ Klarheit über die Absicht schafft Vertrauen. Wenn Teams wissen, wozu Daten erhoben werden, sinkt die Angst vor Missbrauch. Transparenz bedeutet auch: Wenn sich die Absicht ändert, wird das kommuniziert. Und wenn Metriken nicht mehr genutzt werden, werden sie abgeschafft und nicht still und heimlich weitererhoben.
Prinzip 3: Mehrere Perspektiven. Nie nur eine Metrik betrachten. Jede Kennzahl hat blinde Flecken. Eine einzige Metrik kann optimiert werden, ohne dass sich die zugrunde liegende Realität verbessert. Das SPACE-Framework arbeitet bewusst mit fünf Dimensionen, nicht mit einer. Die DORA-Metriken nutzen vier Kennzahlen, nicht eine. Mehrere Perspektiven schaffen Balance. Wenn die Lead Time sinkt, aber gleichzeitig die Fehlerrate steigt, ist das kein Erfolg. Metriken müssen sich gegenseitig in den Kontext setzen.
Prinzip 4: Trends statt Absolutes. „Werden wir besser?“ ist die wichtigere Frage als „Sind wir gut?“. Absolute Zahlen ohne Kontext sind schwer zu interpretieren. Aber Entwicklung über Zeit zeigt klar, ob Veränderungen wirken. Ein Team, das seine Cycle Time von 15 Tagen auf 10 Tage reduziert hat, hat sich verbessert, unabhängig davon, ob 10 Tage „gut“ sind. Trends zeigen die Wirkung von Experimenten, von Prozessänderungen, von Investitionen. Sie machen Continuous Improvement messbar. Und sie sind ehrlicher: Statt zu behaupten „Wir sind die Besten“, zeigen sie „Wir werden besser“.
Prinzip 5: Qualitatives nicht vergessen. Zahlen sind wichtig, aber sie sind nicht alles. Retrospektiven, Gespräche und Beobachtungen ergänzen quantitative Daten. Warum ist die Lead Time gestiegen? Die Zahl zeigt das „Was“, nicht das „Warum“. Vielleicht gab es viele Urlaubstage. Vielleicht ist ein kritisches Teammitglied ausgefallen. Vielleicht wurde bewusst in Refactoring investiert. Ohne qualitative Einordnung führen Zahlen in die Irre. Das SPACE Framework betont: Mindestens eine Metrik sollte sich auf Wahrnehmungen beziehen – Zufriedenheit, Wohlbefinden, gefühlte Produktivität. Das Subjektive ist nicht weniger wichtig als das Objektive.
Prinzip 6: Regelmäßige Reviews. Metriken sind nicht in Stein gemeißelt. Sie müssen regelmäßig überprüft werden: Sind sie noch relevant? Haben sich die Fragen geändert? Werden sie manipuliert? Welche Metriken nutzt niemand mehr? Ein jährliches Portfolio-Review – nicht nur für Projekte, sondern auch für Metriken – hilft beim Aufräumen. Metriken, die nicht mehr dienen, werden abgeschafft. Neue Metriken, die gebraucht werden, kommen hinzu. Das verhindert, dass Dashboards zu Friedhöfen werden: voll mit Zahlen, die niemand mehr anschaut, aber alle weiter pflegen müssen.
Diese Prinzipien schaffen eine Kultur, in der Metriken als das genutzt werden, was sie sein sollten. Nämlich Werkzeuge für Transparenz, Lernen und Verbesserung. Nicht Waffen für Kontrolle, Vergleich und Druck.
Metriken zur Lieferfähigkeit sind wichtig, jedoch nur mit dem richtigen Fundament. Die Frage ist nicht „Welche Metriken sollen wir messen?“, sondern „Für wen messen wir, warum, und wozu?“. Diese Fragen klingen banal, werden aber erschreckend selten gestellt. Das Ergebnis sind Dashboards voller Zahlen, die niemand versteht, die niemand nutzt oder die aktiv schaden, weil sie falsche Anreize setzen.
Unterschiedliche Stakeholder haben unterschiedliche Informationsbedürfnisse. Die Geschäftsführung braucht strategische Übersicht. Der CTO braucht operative Steuerungsinformationen. Product Owner brauchen Planbarkeit. Team Leads brauchen Prozess-Insights. Und Teams brauchen Transparenz über ihre eigene Arbeit. Ein Dashboard für alle funktioniert nicht. Wer das versucht, bedient am Ende niemanden richtig.
Die Gründe für Messungen sind entscheidend. Legitime Motive – Transparenz, Verbesserung, Vorhersagbarkeit, Koordination – helfen. Problematische Motive – Performance-Messung, Mikromanagement, Bonus-Kopplung, Cargo Cult – schaden. Die gleiche Metrik kann hilfreich oder destruktiv sein, je nachdem, wofür sie genutzt wird. Die Absicht ist wichtiger als die Kennzahl selbst.
Die typischen Fallstricke sind bekannt: Goodharts Law verwandelt Indikatoren in Ziele und macht sie nutzlos. Der Streetlight-Effekt führt dazu, dass nur das Einfache gemessen wird, nicht das Wichtige. Vanity Metrics sehen gut aus, bedeuten aber nichts. Fehlende Kontextualisierung macht Zahlen uninterpretierbar. Zu viele Metriken erzeugen Rauschen statt Signal. Und fehlende psychologische Sicherheit führt zu Gaming statt zu ehrlicher Messung. Wer diese Fallstricke kennt, kann sie vermeiden.
Ein Framework hilft bei der Auswahl: Drei Schlüsselfragen klären, für wen, für welche Entscheidung und mit welcher gewünschten Veränderung eine Metrik eingeführt wird. Der Goals-Signals-Metrics-Ansatz zwingt zu klarem Denken: Erst das Ziel, dann das Signal, dann die Metrik. Und Minimum Viable Measurement bedeutet: Start small, lerne, iteriere. Lieber eine Metrik richtig als zehn halbherzig.
Die Kultur um Metriken herum ist wichtiger als die Metriken selbst. Prinzipien schaffen Leitplanken: Metriken sind für Teams, nicht über Teams. Transparenz über die Absicht schafft Vertrauen. Mehrere Perspektiven vermeiden blinde Flecken. Trends zeigen Entwicklung besser als Absolutes. Qualitatives ergänzt Quantitatives. Und regelmäßige Reviews halten das Metriken-Portfolio aktuell.
Metriken sind Werkzeuge. Und wie bei jedem Werkzeug gilt: Man muss wissen, wofür man es nutzt, bevor man es in die Hand nimmt. Das Fundament steht. Jetzt kann gebaut werden.
Buchen Sie jetzt Ihre kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.