Beiträge

Euer Team liefert schneller mit KI. Deshalb braucht ihr Retros mehr denn je

Eure Entwicklerinnen und Entwickler nutzen Copilot, Claude Code, Cursor oder eine Kombination aus allen dreien. Pull Requests werden schneller gemergt. Pro Sprint wird mehr Code ausgeliefert als je zuvor. Nach allen individuellen Kennzahlen wirkt euer Team produktiver. Aber schaut auf die Zahlen: 70 % der Entwicklerinnen und Entwickler sagen, KI steigert ihre persönliche Produktivität, während nur 17 % sagen, sie verbessert die Teamzusammenarbeit. Diese Lücke sollte euch zu denken geben. KI-Coding-Tools lösen den falschen Engpass. Die meisten Teams waren nicht durch Tippgeschwindigkeit blockiert. Sie waren blockiert, weil sie das Falsche bauten und technische Schulden anhäuften, über die niemand sprach. KI macht beide Probleme schlimmer, indem sie euch schneller vorankommen lässt, ohne die Richtung zu prüfen. Sprint-Retrospektiven sind die Lösung. Nicht weil sie ein nettes agiles Ritual sind, sondern weil sie einer der wenigen strukturierten Momente sind, in denen ein Team aufhört zu bauen und anfängt zu fragen, ob die Arbeit eigentlich sinnvoll ist.

Das Produktivitätsparadox, über das niemand spricht

Die Schlagzeilenzahlen zu KI-Coding-Tools sehen beeindruckend aus. GitHub berichtet, dass Copilot-Nutzerinnen und -Nutzer Aufgaben 55 % schneller erledigen. Accenture verzeichnete nach der Einführung einen Anstieg erfolgreicher Builds um 84 %. McKinsey fand bei Hochleistungsteams Effizienzgewinne von 20–30 %. Doch wer tiefer schaut, sieht ein kompliziertes Bild. Eine randomisierte kontrollierte Studie von METR ergab, dass erfahrene Entwicklerinnen und Entwickler, die KI-Tools nutzten, 19 % länger für Aufgaben brauchten, während sie glaubten, 20 % schneller zu sein. Das ist eine Lücke von 40 Prozentpunkten zwischen Wahrnehmung und Realität. Der DORA 2024-Bericht von Google stellte fest, dass eine 25-prozentige Zunahme des KI-Einsatzes mit einem Rückgang der Lieferstabilität um 7,2 % korreliert. GitClears Analyse von 211 Millionen Codezeilen zeigte, dass Code Churn (neu geschriebener Code, der innerhalb von zwei Wochen überarbeitet wird) zwischen 2020 und 2024 von 3,1 % auf 7,9 % gestiegen ist, während Refactoring von 25 % auf unter 10 % fiel. Es wird mehr Code ausgeliefert. Ob es der richtige Code ist, ist eine andere Frage.

KI übernimmt das „Wie", Retros klären das „Ob"

KI-Tools sind gut in einem begrenzten Aufgabenbereich: Boilerplate generieren und Muster vervollständigen. Sie übernehmen das „Was" und „Wie" des Softwarebauens schneller als jeder Mensch. Was sie nicht können: euch sagen, ob das, was ihr baut, es wert ist, gebaut zu werden. Dieses Urteil liegt in den Gesprächen zwischen Menschen. Sollen wir dieses Feature bauen? Ist das der richtige Ansatz? Lösen wir das eigentliche Kundenproblem? Retrospektiven sind der Ort, an dem diese Gespräche stattfinden. Wenn ein Team den Sprint reflektiert, fragt es, ob die ausgelieferte Arbeit tatsächlich etwas bewegt hat – nicht nur, was gut lief. Während KI den Build-Zyklus verkürzt, muss die Feedbackschleife mit Kunden enger werden, nicht weiter. Ihr könnt ein Feature in zwei Tagen statt zwei Wochen ausliefern. Das ist nur wertvoll, wenn es das richtige Feature war.

Mehr Entscheidungen pro Sprint, mehr Spielraum für Abweichungen

Stellt es euch so vor. Wenn KI eurem Team erlaubt, doppelt so viel pro Sprint zu liefern, trefft ihr auch ungefähr doppelt so viele Entscheidungen pro Sprint. Welche Stories aufgenommen werden, wie sie umgesetzt werden, welche Kompromisse akzeptiert werden, welche Ecken abgeschnitten werden. Jede Entscheidung ist ein Punkt, an dem Teammitglieder still in verschiedene Richtungen driften können. Vor der KI haben die natürlichen Coding-Pausen organische Synchronisationspunkte geschaffen. Pair Programming, PR-Reviews, Flurgespräche über knifflige Implementierungen. Diese informellen Kontrollpunkte haben Probleme frühzeitig erkannt. Eine zweijährige Longitudinalstudie über Entwicklerinnen und Entwickler, die KI-Tools nutzen, ergab, dass der KI-Einsatz die Arbeit in Richtung individualisierter Coding-Aufgaben und weg von kollaborativer Koordination verlagert. Entwicklerinnen und Entwickler verbringen mehr Zeit im Flow-Zustand mit ihrem KI-Assistenten und weniger Zeit damit, miteinander zu sprechen. Die Kollaborationsprobleme, die vor der KI bestanden (Wissenssilos, Kommunikationsabbrüche, unklare Verantwortlichkeiten), blieben vollständig ungelöst. Wenn euer Team 90 % des Sprints mit einem KI-Pair-Programmer verbringt, könnten die 60 Minuten in einer Retro die wichtigste Stunde des gesamten Sprints sein.

KI-generierter Code schafft Probleme, die nur Menschen erkennen können

CodeRabbits Analyse von 470 Open-Source-Pull-Requests ergab, dass KI-mitverfasster Code 1,7-mal mehr schwerwiegende Probleme, 75 % mehr Logikfehler und 2,74-mal mehr Sicherheitslücken enthielt als von Menschen geschriebener Code. Gleichzeitig geben über 40 % der Juniorentwicklerinnen und -entwickler zu, KI-generierten Code zu deployen, den sie nicht vollständig verstehen. Das ist keine Krise. Es ist ein Muster, das teamweite Gespräche erfordert. Einzelne Entwicklerinnen und Entwickler können das nicht allein lösen, weil die Probleme systemisch sind. Wenn die KI-generierte Hilfsfunktion einer Person still die bestehende Bibliothek eines anderen Teammitglieds dupliziert, ist das ein Problem auf Codebase-Ebene. Wenn KI-vorgeschlagene Abkürzungen technische Schulden erzeugen, die sich über mehrere Sprints anhäufen, sieht niemand das Gesamtbild, solange das Team nicht darüber spricht. Retrospektiven sind der Ort, an dem diese Muster sichtbar werden. „Überprüfen wir KI-Output sorgfältig genug?" ist eine Retro-Frage. „Wo wachsen Wissenslücken?" ist eine Retro-Frage. „Häufen wir Schulden schneller an, als wir merken?" ist eine Retro-Frage.

Was ihr in Retros wirklich besprechen solltet, wenn euer Team KI nutzt

Standardmäßige Retro-Formate funktionieren weiterhin, aber die Fragen müssen aktualisiert werden. Diese fünf Themen kommen bei KI-unterstützten Teams am häufigsten vor.

Effektivität der KI-Tools

Wo hat KI in diesem Sprint tatsächlich geholfen? Wo hat sie euch verlangsamt oder in Kreisen geschickt? Teams, die das verfolgen, entwickeln ein gemeinsames Gespür dafür, wann man auf KI setzen sollte und wann man einen Schritt zurücktreten sollte.

Wissensverteilung

Wer versteht den ausgelieferten Code? KI macht es leicht, dass eine Person ein ganzes Feature allein generiert. Das ist ein bus factor-Risiko. Nutzt die Retro, um Bereiche zu markieren, in denen Wissen bei einer einzigen Person konzentriert ist.

Kundenbezug

Haben sich die Geschwindigkeitsgewinne in Kundenwert umgewandelt? Doppelt so schnell zu liefern bedeutet nichts, wenn ihr Features liefert, die niemand gewollt hat. Die Retro sollte Sprint-Output mit Kundenfeedback und Produktzielen verbinden.

Signale zur Codequalität

Nimmt Churn zu? Werden PRs abgenickt, weil das Volumen für eine gründliche Überprüfung zu hoch ist? Seht ihr mehr Bugs in der Produktion durch KI-generierten Code? Das sind Frühindikatoren, die Teamdiskussionen erfordern, keine individuellen Heldenleistungen.

Teamnormen rund um KI

Jedes Team entwickelt informelle Regeln zur KI-Nutzung: wann man sie einsetzt, wann nicht, wie viel Überprüfung erwartet wird. Die Retro ist der Ort, an dem ihr diese Normen explizit macht und auf Basis des tatsächlichen Geschehens anpasst. Probiert eine Retrospektiven-Vorlage aus, die für diese Gespräche konzipiert wurde, oder passt euer bestehendes Format mit KI-spezifischen Impulsen an.

Die Meetings, die man nicht automatisiert, sind die, die am meisten zählen

Googles DORA 2025-Bericht bringt es auf den Punkt: „KI macht gute Teams besser. Und schlechte Teams schneller schlechter." Die Praktiken, die diese beiden Kategorien voneinander trennen – wie psychologische Sicherheit und ehrliches Feedback – sind genau das, worum Retrospektiven gebaut sind. Es gibt eine Versuchung, alles zu automatisieren, wenn KI im Spiel ist. KI-generierte Standup-Zusammenfassungen. KI-analysierte Retro-Boards. Einiges davon ist nützlich. Aber der Wert einer Retrospektive ist das Gespräch selbst. Es ist der Moment, in dem eine Juniorentwicklerin sagt: „Ich habe diese Architekturentscheidung nicht verstanden" oder eine Senioringenieurin zugibt: „Ich glaube, wir haben diesen Sprint überdimensioniert." Diese Momente passieren nicht in Slack-Threads oder Jira-Kommentaren. Sie passieren kaum bei PR-Reviews. Sie passieren in Retros, wenn das Team sich den Raum genommen hat, ehrlich darüber zu sein, wie die Arbeit läuft. Während KI immer mehr der mechanischen Arbeit des Softwarebauens übernimmt, werden menschliche Gespräche seltener. Und seltener bedeutet wertvoller.