In vielen Organisationen existiert es bereits: das Dashboard zur Lieferfähigkeit. Eingerichtet in einem Projekt, einmal vorgestellt und danach immer seltener geöffnet.
Die Zahlen werden weiter erhoben, aber sie erreichen keine Entscheidung mehr. Das ist der häufigste Endzustand von Mess-Initiativen, und er entsteht selten durch falsche Kennzahlen oder fehlerhafte Berechnung. Er entsteht durch die Einführung selbst.
Ein Messprogramm ist im ersten Jahr kein Datenprojekt, sondern ein Vertrauensprojekt. Ob Zahlen zum Steuerungsinstrument werden oder zur Dekoration, entscheidet sich in den ersten zwölf Monaten. Es entscheidet sich daran, wie das Programm eingeführt wird, wer beteiligt ist und ob die Zahlen jemals sichtbar eine Entscheidung verändern.
Das konzeptionelle Fundament, also die Frage, für wen und warum überhaupt gemessen wird, ist an anderer Stelle gelegt, im Artikel Kennzahlen für Lieferfähigkeit – Wozu und für wen messen wir überhaupt?. Der vorliegende Artikel setzt nun dort an, wo das Konzept auf die Organisation trifft: beim praktischen Verlauf des ersten Jahres, bei den Widerständen, die dabei entstehen, und bei den Fehlermustern, die sich wiederholen.
Der erste Fehler geschieht meist, bevor die erste Zahl erhoben ist: beim Start mit dem vollständigen Kennzahlen-Set. Das komplette Instrumentarium ist attraktiv, weil es vollständig aussieht und nach Gründlichkeit klingt. In der Einführung wirkt es genau gegenteilig. Ein Dashboard mit vierzehn Kennzahlen im ersten Monat überfordert nicht nur, es signalisiert auch „Hier wird alles gemessen“ und nährt damit exakt jene Angst vor Überwachung, die ein Programm zum Scheitern bringt.
Minimum Viable Measurement bedeutet das Gegenteil. Der Einstieg erfolgt über eine einzige Frage, die tatsächlich jemand hat. Aus dieser Frage wird ein Signal abgeleitet und aus dem Signal eine Kennzahl. Das ist die Logik des Goals-Signals-Metrics-Vorgehens.
Die eigentliche Disziplin liegt darin, weniger zu messen, als technisch möglich wäre. Eine einzelne Kennzahl, die eine echte Frage beantwortet und sichtbar in eine Entscheidung einfließt, baut mehr Vertrauen auf als ein vollständiges Dashboard, das niemand liest. Die Erweiterung kommt später und folgt dem tatsächlichen Bedarf, nicht dem Anspruch auf Vollständigkeit. Statt das gesamte Flow-Metrik-Set zu installieren, lohnt sich der Start mit der einen Frage, die die Leitung immer wieder stellt, etwa wann ein Vorhaben fertig ist, beantwortet mit dem Minimum an Zahlen, das dafür nötig ist. Der Rest wartet, bis er nachgefragt wird.
Widerstand wird meist als Hindernis behandelt, das sich mit besserer Kommunikation überwinden lässt. Diese Sichtweise verfehlt, was Widerstand eigentlich ist, nämlich eine Information über das System. Starker Widerstand gegen ein Messprogramm verweist fast immer auf eine reale Angst oder eine zurückliegende Erfahrung. Beides ist es wert, verstanden zu werden, bevor es wegargumentiert wird.
Die inhaltlichen Einwände selbst, also Messung sei schädlich, fehlerbehaftet, lenke ab oder löse nichts, sind samt ihren Antworten bereits im Artikel Widerstände gegen die Messung von Produktivität behandelt. Was dieser Text nicht abdeckt, ist die gelebte Dynamik einer Einführung. Diese hat weniger mit Argumenten zu tun und mehr mit Angst und Macht.
Drei Wurzeln treten wiederholt auf. Die erste und am stärksten programmtötende ist die Angst vor individueller Bewertung. In dem Moment, in dem eine Zahl in einem Leistungsgespräch landen könnte, ändert sich das Verhalten, und das Team schützt sich. Das Gegenmittel ist strukturell statt rhetorisch. Kennzahlen bleiben auf Team- und Systemebene und nie auf der Ebene der einzelnen Person. Diese Zusage muss sichtbar sein und eingehalten werden. Warum Individualmessung die wertschöpfende Einheit zerstört, ist im oben verlinkten Artikel ausgeführt.
Die zweite Wurzel ist der Verlust der Deutungshoheit. Wo Lieferfähigkeit zuvor nach Bauchgefühl beurteilt wurde, besaß derjenige, der dieses Bauchgefühl hatte, ein Informationsmonopol. Eine Kennzahl macht die Grundlage öffentlich und verschiebt diese Macht. Widerstand kommt hier oft nicht aus dem Team, sondern aus einer Ebene, die bislang über Narrative gesteuert hat. Das offen zu benennen, ist ehrlicher, als das Programm als politisch neutral darzustellen.
Die dritte Wurzel sind schlechte Vorerfahrungen. Viele Entwicklerinnen und Entwickler haben erlebt, wie Zahlen zuvor missbraucht wurden, als Druckmittel oder als Vergleich. Das Lehrbuchbeispiel dafür ist die Geschichte der Velocity, nachgezeichnet im Artikel Warum Velocity die falsche Metrik ist (und was wirklich hilft). Diese Erinnerung ist rational und prägt die Aufnahme jedes neuen Programms. Sie anzuerkennen, statt sie als Fortschrittsverweigerung abzutun, ist der schnellere Weg zur Akzeptanz.
Daraus folgt eine praktische Konsequenz. Die betroffenen Menschen müssen in die Auswahl und Definition der Kennzahlen einbezogen werden. Die gemeinsame Erarbeitung verbessert das Kennzahlen-Set und verringert Manipulation und Widerstand zugleich, ein Zusammenhang, der im Artikel zum SPACE-Framework ausgeführt ist.
Neben Fallen wie der Manipulation der Kennzahlen oder des Vergleichs, treten im ersten Jahr einige Umsetzungsfehler immer wieder auf.
Der erste ist die fehlende Nullmessung. Ein Programm beginnt, Zahlen zu erheben, legt aber nie einen Ausgangspunkt fest. Ohne Baseline lässt sich später keine Veränderung zuordnen. Das Programm produziert Zahlen, kann aber nie belegen, dass eine Intervention gewirkt hat. Genau dieser Nachweis ist jedoch die Rechtfertigung, die ein Programm zum Überleben braucht.
Der zweite ist die fehlende Kopplung an eine Entscheidung. Das ist der häufigste leise Tod. Ein Dashboard wird gebaut, sieht gut aus und ist mit keiner Entscheidung verbunden. Ob es grün oder rot zeigt, es folgt nichts daraus. Ein Team richtet ein Cycle-Time-Diagramm ein, das in jedem Statusmeeting gezeigt wird. Die Kurve steigt, sie fällt, niemand leitet daraus je eine Handlung ab. Nach einem halben Jahr ist das Diagramm fester Teil der Tagesordnung, aber kein Teil einer einzigen Entscheidung. Eine Kennzahl, die keine Entscheidung auslöst, ist Dekoration. Die Prüffrage für jede Metrik lautet, welche Entscheidung sich ändert, wenn diese Zahl sich bewegt. Fehlt die Antwort, gehört die Kennzahl noch nicht auf das Dashboard. Wie sich Diagramme entscheidungsreif gestalten lassen, ist im Artikel Visualisierung und Dashboard-Design für Lieferfähigkeit beschrieben.
Der dritte ist das Werkzeug vor der Frage. Tooling wird gekauft oder gebaut, bevor die Frage geklärt ist. Dann diktiert das Werkzeug, was gemessen wird, nämlich das, was es leicht macht. Das Resultat ist, dass das leicht Messbare das Relevante verdrängt. Eine Organisation lizenziert ein Flow-Metrik-Werkzeug, bevor klar ist, welche Frage es beantworten soll. In den ersten Wochen wird gemessen, was das Werkzeug ohne Konfiguration anbietet. Ein halbes Jahr später steht ein Dashboard voller Standarddiagramme, und die ursprüngliche Frage, warum sich Releases verzögern, ist nie gestellt worden. Die Reihenfolge ist Frage, dann Kennzahl, dann Werkzeug. Und nicht umgekehrt.
Der vierte ist der verfrühte Vergleich. Team gegen Team im dritten Monat zerstört verlässlich Vertrauen und löst Gaming aus, aus Gründen, die der oben verlinkte Artikel zu den Widerständen ausführt. Im ersten Jahr ist ein Vergleich fast immer verfrüht, weil das Programm das Vertrauen noch nicht erarbeitet hat, das einen Vergleich als Lernen statt als Urteil lesbar machen würde.
Der fünfte ist das Programm als reines Management-Projekt. Ein Programm, das über die Köpfe der Gemessenen hinweg entworfen und ausgerollt wird, scheitert auch mit technisch sauberen Kennzahlen, wenn die Gemessenen bei der Auswahl keine Stimme hatten. Beteiligung ist keine nette Geste. Sie verbessert das Kennzahlen-Set und ist der wirksamste Hebel gegen Widerstand.
Die folgende Abfolge ist eine grobe Orientierung, kein Plan zum Abschreiben. Sie zerfällt in drei Phasen, deren Übergänge wichtiger sind als ihre genaue Dauer.
Die frühe Phase, etwa das erste Quartal, dient dem Feststellen, nicht dem Steuern. Die ersten Wochen gehören der Baseline, nicht der Intervention. Ein Programm, das zu optimieren beginnt, bevor es einen Ausgangspunkt hat, verliert die Möglichkeit, eine Wirkung zu belegen. In dieser Phase wird eine Frage gewählt, eine Kennzahl abgeleitet und ein Messfenster laufen gelassen, das lang genug ist, um die natürliche Schwankung der Arbeit einzufangen. Die Versuchung, schon nach drei Datenpunkten zu handeln, ist der typische Fehler dieser Phase. Softwarearbeit ist hochvariabel und eine Baseline braucht genug Länge, um Signal von Rauschen zu trennen.
Die mittlere Phase, etwa Monat vier bis acht, bringt die erste Entscheidung. Sobald eine Baseline existiert, erarbeitet sich das Programm seine Berechtigung durch die erste Entscheidung, die sichtbar auf die Daten zurückgreift. Sie muss nicht groß sein. Es geht um den Präzedenzfall, dass eine Zahl eine Wahl verändert hat und diese Veränderung für die Gemessenen sichtbar war. In dieser Phase wird Vertrauen aufgebaut oder leise verspielt. Es ist zugleich die Phase, in der die stärksten Widerstände an die Oberfläche kommen, weil die Zahlen jetzt Folgen haben. Wer bislang nach Bauchgefühl gesteuert hat, bemerkt die Verschiebung genau hier.
Die späte Phase, etwa das letzte Quartal, erlaubt vorsichtige Erweiterung. Erst jetzt, mit Baseline, Routine und Präzedenzfall, ergibt eine Erweiterung Sinn. Und nur jene Erweiterung, nach der jemand fragt. Der Fehler der späten Phase spiegelt den der frühen. Statt zu schnell zu handeln, fügt das Programm nun Kennzahlen hinzu, weil es kann, und rutscht zurück in das überladene Dashboard, das es am Anfang vermieden hat. Das Signal für eine berechtigte Erweiterung ist eine Frage, die die bestehende Kennzahl nicht beantworten kann, nicht eine Lücke in der Symmetrie des Dashboards.
Die Phasen sind nicht scharf getrennt. Worauf es ankommt, ist ihre Reihenfolge: Baseline vor Steuerung, eine Entscheidung vor Erweiterung und der Bedarf vor Vollständigkeit.
Der Erfolg eines ersten Jahres ist kein Kennzahlen-Ziel. Eine reduzierte Cycle Time im elften Monat bedeutet wenig, wenn niemand der Zahl vertraut. Drei Dinge müssen gelingen.
Eine geteilte Frage. Mindestens eine Frage, die mehreren Beteiligten wirklich am Herzen liegt und die das Programm beantwortet. Ohne sie haben die Zahlen keinen Adressaten.
Eine Routine des Hinsehens. Ein wiederkehrender Moment, in dem die Zahlen tatsächlich betrachtet und besprochen werden, nicht als Ritual, sondern weil eine Entscheidung von ihnen abhängt. Zahlen, die erhoben, aber nie angesehen werden, sind bereits auf dem Weg zum Friedhof.
Eine sichtbar veränderte Entscheidung. Der stärkste einzelne Vertrauensbildner ist eine Entscheidung, die nachweislich anders ausfiel, weil Daten vorlagen. Ein solcher Moment bewirkt mehr für die Akzeptanz als jede Präsentation über den Wert von Metriken.
Existieren diese drei Dinge nach zwölf Monaten, hat das Programm ein Fundament. Die genauen Kennzahlen dürfen sich danach weiter ändern. Einmal aufgebautes Vertrauen trägt das Programm durch die unvermeidlichen späteren Anpassungen.
Was ein Messprogramm sinnvoll messen kann, steht gerade auf wackeligem Grund. In dem Maß, in dem KI größere Teile des eigentlichen Bauens übernimmt – nicht nur Code, sondern zunehmend auch Entwurf, Analyse und Test – schrumpft die aktive Bearbeitungszeit pro Arbeitseinheit. Mit ihr schrumpft die Aussagekraft von Kennzahlen, die genau diese Aktivität messen. Commits, Story Points oder Entwickler-Output zu zählen, verliert an Bedeutung, wenn ein großer Teil dieses Outputs nicht mehr aus menschlichen Tastenanschlägen stammt.
In einer Einführung zeigt sich das als Einwand, den es vor wenigen Jahren noch nicht gab. Was messen diese Zahlen überhaupt noch, wenn KI den Code schreibt? Das ist eine berechtigte Frage. Wenn das Bauen schnell und günstig wird, bleibt in der Lieferzeit vor allem das sichtbar, was ohnehin den größeren Anteil ausmachte, nämlich Wartezeit, Übergaben, Entscheidungslatenz und die Reibung zwischen Teams. Die relevante Frage verschiebt sich von der Geschwindigkeit der Teamarbeit hin zu der Frage, wo in der Organisation die Zeit tatsächlich bleibt.
Diese Verschiebung verändert, welche Kennzahl ein Programm ins Zentrum stellen sollte, und sie verdient eine eigene Betrachtung statt einer Randnotiz. Für ein Programm im ersten Jahr ist die praktische Folge enger und lässt sich klar benennen. Ein Programm, das sich um individuelle Aktivitätsmetriken herum aufbaut, baut auf erodierendem Grund. Ein Programm, das sich um Fluss und Wartezeit herum aufbaut, steht auf dem, was KI nicht beseitigt.
Das erste Jahr eines Messprogramms ist eine Vertrauensübung im Gewand eines Datenprojekts. Die Zahlen zählen weniger als die Art, wie sie ankommen. Es gilt, weniger zu messen, als möglich wäre, die Gemessenen früh zu beteiligen und jede Kennzahl an eine Entscheidung zu koppeln. Widerstand wird als Information über das System behandelt statt als Hindernis gegen das System.
Die Organisationen, deren Programme das erste Jahr überstehen, sind selten die mit den besten Dashboards. Es sind die, die sich das Recht erarbeitet haben, geglaubt zu werden, wenn eine Zahl etwas Unbequemes sagt. Die Mathematik ist der einfache Teil. Das Vertrauen ist die Arbeit.
Buchen Sie jetzt Ihre kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.