Es gibt gerade eine merkwürdige Diskrepanz in vielen Entwicklungsteams. Frag die Entwickler, und sie sagen: „Wir sind viel schneller geworden." Frag die Stakeholder, und sie sagen: „Es kommt nicht schneller an."
Beide haben recht. Und genau das ist das Problem.
Das Gefühl und die Messung
Wie weit Gefühl und Realität auseinanderliegen können, hat 2025 ein Experiment von METR gezeigt — ein randomisiert kontrollierter Versuch, das methodisch Härteste, was es zu der Frage gibt. Sechzehn erfahrene Entwickler bearbeiteten 246 Aufgaben in reifen Open-Source-Projekten, die sie seit Jahren kannten. Vorher schätzten sie: Mit KI werden wir rund 24 Prozent schneller sein. Gemessen wurde das Gegenteil — sie waren 19 Prozent langsamer. Und selbst hinterher, mit dem Ergebnis vor Augen, glaubten viele weiterhin, schneller gewesen zu sein.
Zur Fairness: METR selbst nennt das Ergebnis inzwischen historisch, weil es die Werkzeuge vom Frühjahr 2025 abbildet. Ein Nachfolgeexperiment von 2026 zeigte eine Beschleunigung von 4 bis 18 Prozent — das METR aber selbst als weitgehend nicht aussagekräftig einstuft. Der Punkt des Experiments überlebt ohnehin jede Tool-Generation: Das Tempo-Gefühl beim Arbeiten ist kein Messinstrument. Es misst, wie flüssig sich das Erzeugen anfühlt — nicht, wann etwas beim Kunden ankommt.
Wo die Zeit tatsächlich bleibt, zeigt dir dein Board. Man muss nur aufhören, auf die falsche Spalte zu schauen.
Drei Stellen, an denen die Zeit versickert
Faros hat 2026 Telemetriedaten von über 22'000 Entwicklern in mehr als 4'000 Teams ausgewertet — nicht Befragungen, sondern tatsächliche Werkzeugdaten. (Faros verkauft Messwerkzeuge, das gehört dazugesagt; die Richtung deckt sich aber mit dem, was DORA unabhängig erhebt.) Drei Befunde daraus sind im Grunde eine Anleitung, wohin du auf deinem Board schauen musst:
Erstens: die Review-Spalte. Die mediane Zeit, die ein Pull Request im Review verbringt, ist um 441 Prozent gestiegen. Der Code entsteht schneller, aber die Menschen, die ihn prüfen müssen, sind nicht schneller geworden — also wächst die Schlange vor ihnen. Und wo die Schlange zu lang wird, entsteht das nächste Problem: 31 Prozent mehr PRs werden ganz ohne Review gemerged. Die Qualitätsfolgen stehen im selben Datensatz — 54 Prozent mehr Bugs pro Entwickler.
Zweitens: die Tickets, die sich nicht bewegen. 26 Prozent mehr laufende Aufgaben zeigen sieben Tage oder länger keinerlei Aktivität. Angefangen, Kapazität gebunden, liegengelassen. Auf dem Board sehen sie aus wie Arbeit. Sie sind das Gegenteil: Sie sind geparktes Warten.
Drittens: die Rückläufer. „Work Restarts" — Aufgaben, die aus einer späteren Phase wieder auf „in Bearbeitung" zurückfallen — sind um 13,8 Prozent gestiegen. Jeder Rückläufer heisst: Es wurde etwas fertig gemeldet, das nicht fertig war. Das ist die teuerste Sorte Arbeit, weil sie doppelt gemacht und doppelt geprüft wird.
Faros fasst das Muster in einem Satz, der bleiben wird: eine Umgebung, „in der es leicht ist anzufangen und schwer, fertig zu werden".
Die Autobahn-Falle
Das Muster dahinter ist alt, nur die Grössenordnung ist neu. Es ist dasselbe wie beim Strassenbau: Wenn vor einem Tunnel regelmässig Stau ist, und du baust die Zufahrt von zwei auf vier Spuren aus, dann hast du den Stau nicht verkürzt. Du hast ihn verlängert — es stehen jetzt doppelt so viele Autos vor demselben Tunnel.
Der Tunnel in deinem Entwicklungsprozess heisst Validierung: Review, Test, Integration, Freigabe. KI hat die Zufahrt ausgebaut. Der Tunnel ist gleich geblieben.
Der DORA-Report 2025 von Google Cloud — rund 5'000 befragte Entwickler — beschreibt exakt diese Verschiebung: KI-Adoption korreliert klar positiv mit dem Durchsatz der Software-Lieferung, gleichzeitig aber mit höherer Instabilität — mehr fehlgeschlagene Changes, mehr Nacharbeit. Die Engpässe wandern dorthin, wo geprüft wird, weil dieser Teil des Systems auf das neue Tempo nicht ausgelegt ist. Und DORAs übergreifender Befund erklärt, warum es nicht alle gleich trifft: KI wirkt als Verstärker. Organisationen mit disziplinierten Prozessen werden besser, Organisationen mit Schwächen bekommen ihre Schwächen vergrössert. Das Werkzeug entscheidet nicht, in welche Gruppe du gehörst. Dein System entscheidet.
Im Nachfolge-Report von 2026 hat DORA das nachgeschärft und benennt inzwischen ausdrücklich die „versteckten Steuern" der KI-Beschleunigung — allen voran den Verifikationsaufwand, der mit dem Erzeugungstempo nicht mitwächst. DORA-Lead Nathen Harvey bringt es auf eine Formel, die den Tunnel besser beschreibt als jedes Diagramm: Ohne organisatorisches Fundament schafft KI „lokale Produktivitätsinseln, die im nachgelagerten Chaos verloren gehen".
Was das für deine Rolle heisst
Wenn du SM, PO oder RTE bist, ist die Konsequenz unbequem, aber klar: Die Frage „Wie machen wir die Entwickler produktiver?" ist gerade die falsche Frage. Die Produktionsseite ist nicht dein Engpass — vermutlich zum ersten Mal in der Geschichte deiner Organisation.
Die richtige Frage lautet: Wie schnell kommt ein fertig geschriebenes Stück Arbeit durch Review, Test und Freigabe? Dort sitzt die Wartezeit, dort entsteht das Task Switching (wer auf sein Review wartet, fängt das nächste Ticket an), und dort entscheidet sich, ob das neue Tempo beim Kunden ankommt oder in der Schlange steht.
Velocity hilft dir bei dieser Frage übrigens nicht — sie misst, was ins System hineingeht, nicht, was hinten herauskommt. Aber das ist ein eigener Artikel.
Der eine Eingriff
Wenn du nur eine Sache änderst, dann diese:
Miss einen Sprint lang für jedes Ticket zwei Zahlen: Tage in „In Arbeit" und Tage in „Review/Warten". Häng das Verhältnis ans Board.
Kein neues Tool — das Datum, an dem ein Ticket die Spalte wechselt, hat dein Board schon. Kein neues Meeting, keine Diskussion über Arbeitsmoral. Nur zwei Zahlen und ihr Verhältnis.
Die Wirkung kommt aus der Sichtbarkeit: Fast jedes Team glaubt, seine Arbeit verbringe die meiste Zeit im Arbeiten. Fast überall stimmt das nicht — und sobald das Verhältnis am Board hängt, verschiebt sich jede Diskussion von selbst. Nicht mehr „warum seid ihr nicht schneller", sondern „warum wartet das Ding vier Tage auf ein Review von zwanzig Minuten". Das ist die Frage, die den Tunnel weitet, statt die Zufahrt auszubauen.
Dein Team ist vermutlich wirklich schneller geworden. Nur misst niemand Geschwindigkeit an der Stelle, wo sie verloren geht. Schau auf die Wartespalten. Dort steht dein Engpass — sichtbar, zählbar und lösbar.
Nächste Schritte
Wenn deine Entwickler ständig zwischen Tickets springen, während sie auf Reviews warten: Das ist kein Konzentrationsproblem. → Task Switching ist kein Fehler - es ist ein Symptom
Wenn das, worauf gewartet wird, ausserhalb deines Teams liegt: Dann bist du beim eigentlichen Thema. → Der stille Killer deiner Sprints sitzt nicht im Nachbarteam
Wenn schon unklar ist, ob das Richtige gebaut wird, bevor es in die Schlange kommt: → Warum sich Teams in Discovery verlieren - und woran du es erkennst
Wenn der feste Rhythmus fehlt, in dem solche Zahlen regelmässig angeschaut würden: → Heartbeat im Scrum Team: Warum feste Strukturen der Schlüssel zur Effizienz sind
Miss das Verhältnis einen Sprint lang und schreib mir, was rauskam — ich sammle die Zahlen. → Taleon LinkedIn
Quellen
- METR — «Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity», Juli 2025 (randomisiert kontrollierter Versuch, 16 Entwickler, 246 Aufgaben). https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- Faros AI — «AI Engineering Report 2026: The Acceleration Whiplash», Telemetriedaten von über 22'000 Entwicklern in 4'000+ Teams. https://www.faros.ai/research/ai-acceleration-whiplash
- DORA / Google Cloud — «State of AI-assisted Software Development», 2025 (ca. 5'000 Befragte). https://dora.dev/research/2025/dora-report/
- DORA / Google Cloud — «The ROI of AI-assisted Software Development», April 2026 (J-Curve, Verifikationsaufwand als „versteckte Steuer", Zitat Nathen Harvey). https://dora.dev/ai/
