Velocity war immer die falsche Metrik

Im Jahr 2010 habe ich versprochen, die Velocity von Entwicklungsteams innerhalb von sechs Wochen zu verdoppeln. Ich habe das auf meine Website geschrieben. Ich habe es in Vorträgen gesagt. Und ich habe es auch geschafft — regelmäßig.

Heute frage ich mich, ob das ein Fehler war.

Nicht, weil es nicht stimmte. Die Teams wurden tatsächlich schneller. Sie lieferten mehr Story Points pro Sprint. Die Burndown-Charts gingen nach unten, die Velocity ging nach oben, und die Manager waren zufrieden. Alle Zahlen bewegten sich in die richtige Richtung.

Nur: Niemand hat gefragt, ob sich die richtige Sache bewegte.

Eine Zahl, die beruhigt

Velocity war das perfekte Angebot an eine bestimmte Art von Management. Eine Zahl, die nach oben geht. Sichtbar. Vergleichbar. Präsentierbar im Lenkungsausschuss. Man konnte sie in eine PowerPoint-Folie packen und dem Vorstand zeigen: Seht her, das Team liefert.

Ich erinnere mich an ein Estimation Meeting in München - ich nannte damals so, später entschied die Community, dass es Backlog Refinement heißen sollte. Zwölf Entwickler, ein Product Owner, ein ScrumMaster. Wir schätzten Stories in Story Points, relativ zueinander, genau wie Mike Cohn es mit seiner Methode Planning Poker beschrieben hatte. Das Team diskutierte, fand ein gemeinsames Verständnis, einigte sich. Es war ein guter Prozess. Er erzeugte Verständnis.

Aber was dann passierte, passierte in den meisten Organisationen: Die Manager nahmen die Velocity und rechneten rückwärts. Wenn das Team 40 Punkte pro Sprint schafft und das Backlog 200 Punkte hat — dann sind wir in fünf Sprints fertig. Und wenn wir in vier Sprints fertig sein müssen, dann muss die Velocity auf 50 steigen.

Die Velocity war nie als Planungsinstrument gedacht. Sie war ein Resultat. Das habe ich 2009 geschrieben, auf meinem Blog: „Die Velocity wird gemessen, sie kann nicht gemanagt werden." Damals war mir noch nicht klar, wie tief der Reflex sitzt, jede messbare Zahl in ein Ziel zu verwandeln.

Goodharts Gesetz, in Scrum-Sprache

Charles Goodhart, ein britischer Ökonom, hat 1975 ein Prinzip formuliert, das später seinen Namen tragen sollte. Sein Original klang sperrig:

„Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes."

Es dauerte bis 1997, als Marilyn Strathern die Essenz destillierte: „Wenn eine Kennzahl zum Ziel wird, hört sie auf, eine gute Kennzahl zu sein." Goodhart schrieb über die britische Geldpolitik. Aber er hätte auch über Sprint Reviews schreiben können.

Als Velocity zum Ziel wurde, begannen die vorhersagbaren Verzerrungen. Teams schätzten höher, um die Kurve zu halten. Product Owner schnitzten Stories kleiner, damit mehr in den Sprint passten. Manager verglichen Teams miteinander — Team A hat 60, Team B nur 35, warum? — ohne zu verstehen, dass Story Points eine teamspezifische Einheit sind, die sich nicht vergleichen lässt.

Marietta Benko und ich haben damals unterschieden: Tempo ist, wie schnell sich ein Objekt bewegt. Velocity ist Tempo plus Richtung - Wie schnell erreichst du dein Ziel? Die ganze Branche hat das Tempo gemessen und die Richtung vergessen.

Die akademische Forschung bestätigt das Muster. Nicole Forsgren, Jez Humble und Gene Kim haben in „Accelerate" (2018) gezeigt, dass die besten Software-Teams sich nicht über Output-Metriken definieren — Story Points, Lines of Code, Features shipped —, sondern über Outcome-Metriken: Deployment Frequency, Lead Time for Changes, Change Failure Rate, Mean Time to Recovery. Vier Metriken, keine davon misst, wie viel ein Team produziert. Alle vier messen, wie schnell ein Team lernt.

Dann kam die Maschine

Sie ist jetzt da. In diesem Augenblick schreiben Hunderttausende Entwickler mit Codex, der neuen IDE der Wahl, nachdem Peter Steinberger von Open Claw sie populär machte. Andere arbeiten mit Claude Code, wieder andere mit Googles Variante.

Nate B Jones rechnet es vor: Lovable, elf Leute, fünf Millionen Dollar Jahresumsatz. Elf. Die erledigen, wofür eine klassische Agentur zweihundert bräuchte. Midjourney: dreißig Leute, zweihundert Millionen.

Die Produktivität pro Kopf explodiert. Das ist kein Hype. Das passiert gerade.

Aber Jones sagt auch den Satz, den die Velocity-Fans nicht hören wollen: Der Code kommt jetzt von der Maschine.

Was knapp wird, ist nicht Output. Was knapp wird, ist Urteil.

2023 hat eine kontrollierte Studie gezeigt, dass Entwickler mit GitHub Copilot eine isolierte Aufgabe 55 % schneller lösten. Im Labor. Eine Aufgabe. Wohldefiniert. Bei komplexen Projekten schrumpfte der Effekt auf unter 10 %. Eine Uplevel-Studie von 2024 fand das Gegenteil: Entwickler mit KI-Tools brauchten 19 % länger — glaubten aber, sie seien 20 % schneller gewesen.

Das muss man sich auf der Zunge zergehen lassen. Die Maschine erzeugt das Gefühl von Geschwindigkeit. Und die Menschen verwechseln das Gefühl mit der Realität.

Genau wie bei Velocity.

Ich habe 2008 auf meinem Blog geschrieben:

„Bugs reduzieren die Velocity. Schließlich hat man bereits Story Points für die fehlerhafte Story eingeheimst."

Das hat in jedem Training für Mißfallen und große Augen gesorgt. Das wollte wirklich niemand hören. Es machte Sinn, musste jede:r zugeben, aber hören wollte das keiner, denn es war zu offensichtlich. Das hier der Selbstbetrug aufgedeckt wurde.

Die Metrik belohnte Durchsatz, nicht Qualität. 17 Jahre später produziert die Maschine Durchsatz im Überfluss. Und eine falsche Architekturentscheidung, die früher zwei Wochen gedauert hätte, ist jetzt in zwei Stunden implementiert. Der Schaden wird erst nach drei Monaten sichtbar.

Velocity misst Output. KI maximiert Output. Das Problem war nie der Output.

Der Beobachter, der den Beobachter beobachtet

Hier wird es ernst. Denn der naheliegende Einwand lautet: Dann lassen wir die KI halt auch das Urteil fällen. Code Review durch die Maschine. Architekturentscheidungen durch die Maschine. Priorisierung durch die Maschine. Jeff Sutherland — Miterfinder von Scrum — bewirbt auf scrum-ai.com genau das: KI als „kollaborativen Partner", der Sprint Planning, Estimation und Backlog Management übernimmt. Sein „Scrum Sage" soll Teams durch den gesamten Prozess führen.

Ich habe das ausprobiert. Jeder, der ernsthaft mit diesen Werkzeugen arbeitet, hat das ausprobiert. Und ja — die Maschine kann urteilen. Manchmal besser als ich.

Aber dann stehe ich da mit einem Urteil der Maschine und muss entscheiden: Ist dieses Urteil gut?

Gregory Bateson hat das in den Siebzigern beschrieben. Er nannte es Deutero-Lernen, Lernen zweiter Ordnung. Der Beobachter, der den Beobachter beobachtet. Nicht die Frage „Was ist die richtige Antwort?", sondern die Frage „Ist die Art, wie ich zu dieser Antwort komme, die richtige?"

Wenn ich die Maschine frage, ob mein Code gut ist, und sie sagt Ja — dann muss ich beurteilen, ob ihr Ja etwas taugt. Das ist keine technische Kompetenz. Das ist ein epistemisches Problem. Ein Problem des Erkennens über das Erkennen.

Jones nennt es „Judgment Density" — wie viel relevante Mustererkennung trägt ein Mensch in sich. Nicht wie viel er produziert, sondern wie gut er beurteilt, was produziert wurde. Seine außerordentlichsten Leute, sagt er, operieren in den meisten Organisationen bei 25 % ihrer Kapazität. Nicht weil sie nicht können. Sondern weil sie in Meetings, Abstimmungen und Genehmigungsschleifen feststecken.

Die Velocity dieser Menschen zu messen wäre absurd gewesen. Ihr Urteil zu messen ist es auch. Aber ohne ihr Urteil ist jede Velocity wertlos.

Was wir stattdessen brauchen

Forsgren, Humble und Kim haben in „Accelerate" (2018) gezeigt, dass die DORA-Metriken — Deployment Frequency, Lead Time, Change Failure Rate, MTTR — bessere Prädiktoren für Geschäftserfolg sind als jede Output-Metrik. Nicht weil sie klüger sind. Sondern weil sie eine andere Frage stellen: Nicht „Wie viel?", sondern „Wie schnell lernt das System?"

Aber selbst DORA reicht nicht mehr. Denn DORA misst noch immer das Team. Was wir messen müssten — wenn wir es könnten —, ist die Qualität der Entscheidungen. Wie oft sagt jemand Nein und hat recht? Wie oft wird ein Feature gestrichen, das zwar fertig implementiert war, weil es das Produkt nicht besser gemacht hätte? Wie oft bemerkt jemand, dass die Maschine zwar eine elegante Lösung gebaut hat, aber für das falsche Problem?

Das lässt sich nicht in Story Points ausdrücken. Das lässt sich in gar nichts ausdrücken. Und genau das macht Führungskräften Angst. Weil es bedeutet: Vertraut den Menschen. Nicht den Zahlen.

Business vs. Consulting

Ich habe Velocity verkauft. Um das Argument zu bekommen überhaupt Scrum in Unternehmen einführen dürfen. (Ja ich weiss, der Zweck heiligt nicht die Mittel - aber manchmal doch.)

Ich habe Teams schneller gemacht und dafür Geld bekommen - genommen hatte ich es, weil ich bessere Arbeitsbedingungen und höhere Zufriedenheit generiert hatte. Die Velocity-Verdopplung war mein Pitch. Zufriedenere Menschen mein Ziel - und das half mir den Motor, der das ermöglichte, mein Consulting Business aufzubauen.

Und sie funktionierte — nicht weil ich ein genialer Berater war, sondern weil die Teams anfingen, miteinander zu reden. Sie schätzten gemeinsam, weil sie verstehen wollten. Sie lieferten häufiger, weil kürzere Zyklen schnelleres Feedback ermöglichten. Die Velocity stieg, weil alles andere besser wurde.

Aber verkauft habe ich die Zahl. Nicht das Verstehen. Nicht das Feedback. Die Kurve, die nach oben ging - weil der Markt es so wollte. Beschleunigung klang gut.

Jetzt sehe ich den gleichen Mechanismus, eine Generation weiter. „55 % schneller Code" — im Labor. „Einsparpotenzial 20 bis 45 Prozent" — auf dem Papier einer Beratung.

Was dort nicht steht - was jetzt möglich wäre: Menschen, die nicht stundenlang Bugs fixen müssen, Fehler finden in altem Spaghetti Code, oder Features über Tage zu implementieren, die dann doch keiner braucht. Wir stehen vor einer wunderbaren Chance. Verkaufen kann man aber scheinbar wieder nur - schneller höher weiter.

Gehen die Zahlen nach oben. Dann sind die Manager zufrieden.

Und ich stehe daneben und denke: Das kenne ich. Das habe ich selbst gemacht. Ewig grüsst das Murmeltier.

Und die Frage, die damals niemand stellen wollte, u.a. weil oft rauskam, das einfach nur gebaut wurde, um zu zeigen, man hat etwas gemacht.

Stellt wieder niemand: Baut ihr das Richtige? Für die richtigen Menschen? Und wer beurteilt das — jetzt, wo die Maschine den Code schreibt, die Tests schreibt und auf Wunsch auch gleich das Review?

Bateson würde sagen: Wer beobachtet den Beobachter? Juvenal fragte es vor zweitausend Jahren schärfer: Quis custodiet ipsos custodes? Wer bewacht die Wächter?

Ich glaube, das ist die eigentliche Führungsfrage der nächsten Jahre. Nicht wie schnell. Nicht wie viel. Sondern: Wer traut sich zu urteilen — und wer hält das aus, wenn das Urteil lautet: Das war falsch, obwohl es schnell ging?

Denn wir erleben gerade in großen Organisationen, wie sich immer weniger Menschen trauen, etwas zu entscheiden — trotz des Geredes von psychologischer Sicherheit.