Die Velocity-Metrik, die unseren Kunden leise kaputtgemacht hat
Bei der Entstehung dieses Beitrags kamen keine Story Points zu Schaden. Sie waren schon tot.
Ein Gründer, mit dem wir arbeiten, holte uns letzten Sommer in ein Meeting. Auf seinem Bildschirm war ein Diagramm. Abgeschlossene Story Points pro Sprint, zwei Jahre zurück. Die Kurve zeigte steil nach oben.
„Sehen Sie sich das an“, sagte er. „Wir sind 40 % produktiver als vor achtzehn Monaten. Warum fühlt es sich dann an, als würde alles auseinanderfallen?“
Wir sahen uns das Diagramm an. Dann seinen Bugtracker. Dann die Kundenabwanderung der letzten sechs Monate.
Das Diagramm log. Nicht mit Absicht. Es maß das Falsche.
Wie eine Zahl zum Evangelium wird
Dieser Kunde begann Anfang 2024, die Velocity zu messen. An sich vernünftig. Die meisten Teams, die irgendetwas Scrum-Artiges betreiben, tun das. Ihr VP of Engineering richtete es ein, präsentierte es im monatlichen Board-Meeting, und dem Board gefiel es. Zahl geht hoch, Board glücklich.
Sobald eine Zahl einem Board gezeigt wird, hört sie auf, eine Zahl zu sein. Sie wird zur Zielvorgabe.
Der VP ging sechs Monate später. Die Zahl blieb. Sein Nachfolger erbte das Dashboard, die Erwartung des Boards und die unausgesprochene Regel, dass die Velocity weiter steigen muss.
Was in diesem Team niemand laut aussprechen würde: Jeder Entwickler wusste genau, wie man die Zahl nach oben treibt. Großzügig schätzen. Arbeit in kleinere Tickets zerlegen. Die Aufräumaufgabe auslassen. Sich nicht freiwillig für den fiesen Bug melden, weil er den Sprint-Durchschnitt ruiniert.
Das Diagramm stieg weiter. Alle wussten, was passierte. Niemand konnte es stoppen, weil das Board zusah.
Was wir fanden, als wir wirklich hinsahen
Wir verbrachten zwei Tage damit, ihre Codebasis und ihre Tickets durchzugehen. Nicht das Dashboard. Die tatsächliche Arbeit.
Die Test-Suite brauchte 47 Minuten. Vor achtzehn Monaten waren es 9. Niemand hatte Zeit, das zu beheben, weil es keine Story Points wert war.
Drei ihrer fünf Kerndienste liefen auf einer Node-Version, deren Support acht Monate zuvor ausgelaufen war. Das Upgrade-Ticket existierte. Lag seit über einem Jahr im Backlog. Elf Story Points. Nie angefasst. Elf Punkte für drei kleine Features bewegten das Diagramm weiter als elf Punkte dafür, den Produktivbetrieb nicht kaputtzumachen.
Die Zahl der Bugs war im Jahresvergleich um das 3-Fache gestiegen. Aber Bug-Tickets wurden mit ein oder zwei Punkten geschätzt, Features mit fünf oder acht. Technisch gesehen „leistete“ das Team also mehr, während es ein schlechteres Produkt an weniger zufriedene Kunden auslieferte.
Die Zahl im Diagramm und der Zustand des Produkts hatten nichts miteinander zu tun. Schlimmer noch: Sie entwickelten sich in entgegengesetzte Richtungen.
Warum wir ihnen nicht einfach sagen konnten, sie sollen aufhören
Wir sagten dem Gründer: Weg mit der Metrik.
Er sah uns an, als hätten wir vorgeschlagen, das Büro anzuzünden.
„Das Board sieht diese Zahl jeden Monat. Ich kann nicht einfach aufhören, sie zu zeigen. Womit soll ich sie ersetzen?“
Darüber spricht niemand, der Ihnen erklärt, eine Metrik sei schlecht: Sie können keine Metrik abschaffen, an die sich ein Führungsgremium gewöhnt hat. Sie müssen sie durch etwas ersetzen, dem es mehr vertraut. Und wenn Sie das nicht parat haben, stecken Sie fest.
In dieselbe Falle haben wir Senior-Entwickler tappen sehen, wenn sie gegen Velocity-Tracking argumentieren. Sie haben recht, aber nichts, was sie an die Stelle der Zahl setzen könnten. Nichts ändert sich, die Zahl steigt weiter und das Produkt wird weiter schlechter.
Wir mussten den Ersatz bauen, bevor wir das Original anfassen konnten.
Womit wir sie ersetzt haben
Wir haben nicht eine Zahl gewählt, sondern vier. Keine davon ist perfekt. Alle lassen sich schwerer manipulieren als Story Points.
Erstens: die Zeit von „Bug gemeldet“ bis „Bug im Produktivbetrieb geschlossen“ für die schlimmsten 10 % der Bugs. Nicht der Durchschnitt. Der Durchschnitt lügt. Im Long Tail sitzt der Schmerz. Wenn Ihre schlimmsten Bugs drei Monate brauchen, bis sie geschlossen sind, sagt Ihnen das, ob Ihr Team wirklich Qualität liefert.
Zweitens: die Zahl der pro Woche ausgelieferten Änderungen, die Code anfassen, der älter als ein Jahr ist. Das haben wir uns von einer Gewohnheit abgeschaut, die wir intern entwickelt hatten. Wenn niemand alten Code anfasst, meidet Ihr Team ihn entweder oder versteht ihn nicht. Beides ist schlecht. Ein gesundes Team kehrt immer wieder zu altem Code zurück, verbessert Kleinigkeiten, löscht Dinge, refaktoriert nebenbei.
Drittens: von Kunden gemeldete Probleme pro aktivem Nutzer und Monat. Nicht die rohe Bug-Zahl. Die Bug-Zahl steigt, wenn Sie mehr Features ausliefern. Probleme pro Nutzer rechnen das Wachstum heraus. Wenn diese Zahl steigt, während Ihre Nutzerbasis wächst, haben Sie ein Problem, das die Velocity nie sichtbar machen wird.
Viertens: das Vertrauen der Entwickler in die Codebasis, von ihnen selbst berichtet. Einmal im Monat abgefragt. Eine einzige Frage: „Wie viel Vertrauen haben Sie in den Code, den Sie diesen Monat ausliefern, auf einer Skala von 1 bis 5?“ Anonym. Wir zählen aus und zeigen den Trend. Wenn das Vertrauen sinkt, stimmt etwas nicht, und das zeigt sich meist Wochen früher als in jeder anderen Metrik.
Wir präsentierten diese Zahlen dem Board drei Monate lang neben dem alten Velocity-Diagramm. Dann ließen wir die Velocity weg. Niemand im Board fragte, wo sie geblieben war.
Der Teil, in dem wir uns selbst ertappt haben
Wir schreiben das nicht aus der sicheren Warte des externen Experten.
Etwa vier Monate nach Beginn dieses Auftrags fiel uns etwas Unangenehmes an unserem eigenen Tracking bei Norveon auf. Wir hatten pro Woche gemergte PRs gezählt, als groben Pulsmesser für den Output des Teams. Nicht für ein Board, nicht für irgendjemanden von außen, nur für uns selbst.
Der Fall des Kunden brachte uns dazu, uns unsere eigene Zahl anzusehen.
Zwei Entwickler mergten konstant die meisten PRs. Sie waren auch diejenigen, bei denen am ehesten ein kleiner Fix zwei Wochen später etwas anderes kaputtmachte. Ein Entwickler mergte die wenigsten PRs. Er war zugleich der, dessen Code nie als Bug zurückkam, dem die anderen ihre Reviews anvertrauten und der im Jahr davor still und leise drei der schlimmsten Stellen unserer Codebasis in Ordnung gebracht hatte.
Unsere interne Zahl belohnte die falschen Leute. Viel stand dabei nicht auf dem Spiel. Niemand wurde deswegen gefeuert oder befördert. Aber sie prägte, wie wir in Retros übereinander sprachen, und die Leute, die mehr Anerkennung verdient hätten, bekamen weniger.
Wir haben sie abgeschafft. Zwei Monate lang durch nichts ersetzt, während wir herausfanden, was wir eigentlich wissen wollten. Heute erfassen wir die PR-Zahl überhaupt nicht mehr. Stattdessen gibt es eine monatliche Runde, in der jeder Entwickler eine Sache teilt, die er ausgeliefert hat und auf die er stolz ist, und eine Sache in der Codebasis, für deren Behebung er gern Zeit gehabt hätte. Weniger präzise. Ehrlicher.
Der Teil, der schwer zu akzeptieren ist
Eine schlechte Metrik ist schlimmer als keine Metrik.
Keine Metrik heißt, Sie müssen urteilen, mit Leuten reden, sich die tatsächliche Arbeit ansehen. Das ist langsam und passt auf keine Folie. Eine schlechte Metrik heißt, Sie haben eine Zahl, die Zahl fühlt sich objektiv an, und die Zahl steuert Sie leise auf Entscheidungen zu, die Ihnen schaden.
Story Points pro Sprint sind nicht der einzige Übeltäter. Wir haben erlebt, wie die Testabdeckung in Prozent dasselbe anrichtet. Codezeilen. Deployment-Frequenz. Sogar Uptime, wenn sie isoliert gemessen wird. Jede Zahl, die leicht zu manipulieren und leicht zu präsentieren ist, wird irgendwann manipuliert und präsentiert.
Bevor wir heute irgendetwas messen, stellen wir uns eine Frage: Wenn wir sechs Monate lang hart auf diese Zahl hin optimieren würden, wäre das Produkt dann wirklich besser? Oder wären wir nur besser darin, die Zahl zu produzieren?
Wenn wir das nicht ehrlich beantworten können, messen wir es nicht.
Wo dieser Kunde heute steht
Sie arbeiten noch immer mit den vier Metriken. Ihr Bug-Long-Tail ist über acht Monate um etwa 60 % gesunken. Die von Kunden gemeldeten Probleme pro Nutzer ebenfalls. Die Vertrauenszahl erholte sich am langsamsten. Es dauerte fast ein Jahr, bis sie wieder dort war, wo sie vor der Ära der Velocity-Jagd gestanden hatte.
Diese Verzögerung ist aufschlussreich. Das Vertrauen eines Teams in die eigene Arbeit wächst über Jahre und ist in Monaten beschädigt. Keine Metrik warnt Sie in Echtzeit davor. Bis das Dashboard es erfasst, haben Sie die Leute, die es behoben hätten, schon verloren.
Wir helfen ihnen weiterhin. Sie sind noch nicht fertig.
Derzeit helfen wir einem anderen Kunden, sich von seiner Fixierung auf die „Deployment-Frequenz“ zu lösen. Fragen Sie uns in sechs Monaten, ob das neue Dashboard den Kontakt mit dem Board überlebt hat.
