Zum Inhalt springen

Wissensbasis

Abschied von Agile: McKinseys Studie zum KI-Operating-Model

McKinseys Umfrage unter etwa 300 Großunternehmen zeigt: KI hebt die Produktivität auf Unternehmensebene nur um 5 bis 15 Prozent, weil Teams Größen, Sprints und Rollen aus der Agile-Ära behalten. Bei Top-Performern waren KI-native Workflows 7-mal wahrscheinlicher und KI-native Rollen in kleineren Pods 6-mal wahrscheinlicher.

Verfasst von

Aktualisiert:

Belege 7

Unsere Position. Wir lesen dieses Ergebnis als Effekt des Organigramms, nicht der Tools. Mit Agents wird Koordination zum Bottleneck, nicht Kapazität, deshalb sind kleine Pods die Einheit. Ist die Teamtopologie seit der Zeit vor den Agents unverändert, finanziert das KI-Budget Overhead statt Output (The org-chart effect (öffnet in einem neuen Tab)). Als Hypothese vertreten wir, dass die agilen Werte an Wert gewinnen, auch wenn ihre Artefakte volatil werden (LinkedIn-Post (öffnet in einem neuen Tab)). Die Hypothese stammt aus hycle (öffnet in einem neuen Tab), dem “hyper cycle”. Das ist eine offene, deutschsprachige Skizze eines Operating Models für die Arbeit, sobald KI-Agents die Implementierung übernehmen. Sechs Praktiker:innen haben sie unter CC BY-SA 4.0 veröffentlicht, darunter eine Person von h&w.

McKinseys Bereich SoftwareX stützt die erste Hälfte mit einer globalen Umfrage und mit Interventionen bei einer Bank und einem Tech-Unternehmen (Moving away from Agile: What’s Next (öffnet in einem neuen Tab)). Der Titel klingt nach Abschied von Agile. Die Belege betreffen aber Teamgröße, Rollen und Takt, also die Artefakte statt der Werte.

Warum verlangt KI ein neues Operating Model?

Jeder große Technologiesprung der letzten Jahrzehnte brachte einen Paradigmenwechsel in der Softwareentwicklung mit sich. Agile war der letzte (Kanban-Boards, Standups, Zeremonien). KI ist der nächste. Der Talk konzentriert sich statt auf die Tools auf das, was KI bei Menschen und Operating Model verlangt. Laut McKinsey muss sich dort einiges deutlich ändern.

Warum kommen individuelle Gewinne nicht im Unternehmen an?

Individuelle Produktivitätsgewinne gibt es überall: Aufgaben, die Tage oder Stunden dauerten, brauchen jetzt Minuten. Im Unternehmen kommen diese Gewinne trotzdem nicht an.

  • McKinsey hat weltweit etwa 300 Unternehmen befragt, überwiegend Großunternehmen.
  • Im Schnitt berichten diese Unternehmen insgesamt nur 5 bis 15 Prozent Produktivitätsgewinn.
  • Zwischen dem Potenzial von KI und der realisierten Wirklichkeit auf Unternehmensebene klafft eine Lücke.

Welche Bottlenecks legt schnelleres Coding offen?

Wo Teile der Arbeit schneller werden, zeigen sich Engpässe, die vorher nicht gebremst haben:

  • Die Zusammenarbeit zwischen Menschen und Teammitgliedern hat sich nicht verändert und hält nicht Schritt.
  • Es entsteht weit mehr Code, doch in vielen Unternehmen bleibt das Review manuell.
  • Neuer generierter Code erzeugt verstärkt Tech-Debt und erhöht in manchen Fällen die Komplexität (zitiert nach einem Forschungsbericht der Carnegie Mellon).
  • Die Verteilung der Arbeit bremst: Der Effekt von KI streut stark über Aufgaben (manche gewinnen enorm, manche wenig) und über Menschen (unterschiedlich viel Erfahrung mit den Tools). Für Engineering Manager:innen ist es deshalb nicht trivial, Arbeit und Ressourcen gut zu verteilen.
  • Review-Overhead: Agents bekommen Stories in Prosa mit unscharfen Akzeptanzkriterien. Der zurückgelieferte Code verfehlt deshalb oft die Absicht, und manuelles Review ist der einzige Kontrollmechanismus.

Die meisten großen Unternehmen stecken bei marginalen Gewinnen fest. Sie arbeiten noch unter den Zwängen des menschlichen Entwicklungsparadigmas: Teams aus 8 bis 10 Personen, Sprints von zwei Wochen, Operating Models aus der Agile-Ära. Wer dieses Modell in kleinere Teams, neue Rollen und kürzere Zyklen aufbricht, steigert die Leistung stark.

Welches Mensch-Agent-Modell passt zu welcher Arbeit?

Verschiedene Engineering-Funktionen entlang des Produktlebenszyklus brauchen verschiedene Operating Models zwischen Mensch und Agent:

  • Legacy-Codebasen modernisieren: braucht viel Kontext (womöglich die gesamte Codebasis), hat aber klar definierte Ergebnisse. Modell: eine Factory aus Agents, in der Menschen eine erste Spec und das abschließende Review liefern und sonst kaum eingreifen.
  • Neue Features (Greenfield und Brownfield): profitieren von nicht deterministischen Ergebnissen und mehr Variation. Modell: eine iterative Schleife, in der Agents als Mitgestalter mehr Optionen liefern und so schnellere Feedback-Schleifen ermöglichen.

Was unterscheidet Top-Performer vom Rest?

In der Umfrage unter 300 Großunternehmen waren bei Top-Performern:

  • KI-native Workflows 7-mal wahrscheinlicher: Sie skalieren KI über mehr als vier Use Cases entlang des Software Development Life Cycle, statt Einzellösungen nur für Code-Review oder nur für Codegenerierung zu bauen.
  • KI-native Rollen 6-mal wahrscheinlicher: kleinere Pods mit anderen Skill-Sets und neuen Rollen.

Für diese Veränderungen investierten die Organisationen in kontinuierliches praktisches Upskilling, in Wirkungsmessung und in Anreize, die Entwickler:innen und PMs für den Einsatz von KI belohnen. Das Ergebnis: Time to Market und Liefergeschwindigkeit stiegen um das 5- bis 6-Fache, dazu kamen hochwertigere und konsistentere Artefakte.

Was ändert sich bei Workflows und Rollen?

KI-native Workflows:

  • Statt Quartalsplanung gibt es kontinuierliche Planung.
  • Die Arbeitseinheit wechselt von story-getriebener Arbeit zu Spec-driven Development: PMs iterieren mit Agents an Specs statt an langen PRDs.

KI-native Rollen (Talent):

  • Aus dem Two-Pizza-Team werden One-Pizza-Pods mit drei bis fünf Personen.
  • Getrennte Rollen für QA, Frontend und Backend verschmelzen zu Product Buildern. Sie orchestrieren Agents mit Full-Stack-Kompetenz und verstehen die Architektur der gesamten Codebasis.
  • PMs bauen Prototypen direkt in Code, statt an langen PRDs zu iterieren.

McKinsey hat KI-native Startups untersucht, die alle diese Veränderungen umgesetzt haben. McKinseys Artikel dazu beschreibt, wie Cursor intern arbeitet.

Was hat eine Bank auf Teamebene verändert?

Für ein Großunternehmen, das auf dem agilen Modell aufbaut, führte McKinsey eine Studie mit einer führenden internationalen Bank durch. Sie testete Interventionen auf Teamebene, rund um die Reihenfolge der agilen Zeremonien und die Rollenteilung zwischen Agents und Menschen im Sprint-Zyklus:

  • Team Leads verteilen Sprint-Stories mit Agents, gestützt auf Daten zu Team-Velocity und bisherigen Lieferungen.
  • Teams erstellen gemeinsam mehrere Prototypen und iterieren mit Agents an Akzeptanzkriterien für Security und Observability. So entstehen über Teams hinweg konsistentere Artefakte, und spätere Nacharbeit entfällt.
  • Squads haben sich nach Workflow neu aufgestellt: einer für kleine Bugfixes, einer für Greenfield-Entwicklung.
  • Background-Agents prüfen mögliche Auswirkungen über Repositories hinweg und verkürzen so die Debugging-Zeit der Entwickler:innen.
  • Um Abstimmungsaufwand und Sprint-Meetings zu reduzieren, verfolgen PMs Kundenfeedback direkt in Echtzeit, statt auf Input von Data Scientists zu warten. Sie priorisieren Features neu und arbeiten den Backlog im selben Zeitfenster schneller ab.

Gemessene Ergebnisse bei der Bank:

  • Die Agent-Nutzung stieg um mehr als das 60-Fache.
  • Die Liefergeschwindigkeit stieg, direkt gekoppelt an die Geschäftsprioritäten der Bank.
  • 51 Prozent mehr Code-Merges, zugleich höhere Effizienz.

Warum hinken die Rollen hinterher?

Rollen zu verändern war eines der stärksten Unterscheidungsmerkmale. Engineers wechseln von Ausführung und Code-Schreiben zu Orchestrierung und verteilen Arbeit auf Agents. Auch die Rolle der PMs verändert sich.

  • Trotzdem haben etwa 70 Prozent der befragten Unternehmen ihre Rollen überhaupt nicht verändert. Die Erwartung, dass Menschen anders arbeiten, besteht, doch die Rollendefinition blieb gleich.
  • Bei einem anderen Kunden testete McKinsey kleinere Pods mit zusammengelegten Rollen. Bei gleicher Personenzahl entstanden so mehr Pods (mehr Teams), und jeder Pod leistete ungefähr so viel wie vorher. Die Codequalität blieb erhalten und stieg teils, der Team-Output beschleunigte sich stark.

Wie skaliert ihr die Veränderung über hunderte Teams?

Viele Unternehmen betreiben nicht ein oder zwei solcher Teams, sondern hunderte Teams mit tausenden oder zehntausenden Menschen. Die größte Lücke zwischen den Festgefahrenen (etwa 10 Prozent Verbesserung) und den herausragenden Performern ist Change Management.

  • Change Management heißt, viele kleine Dinge gleichzeitig richtig zu machen: Kommunikation, Anreize, Upskilling. Skalieren bedeutet oft, 20, 30 oder mehr Dinge zur selben Zeit richtig zu machen.
  • Ein Beispiel aus einem Tech-Unternehmen: Tools wurden über den ganzen Produktlebenszyklus ausgerollt. Die Nutzung kam, brach dann aber ein oder blieb suboptimal, und die Gesamtwirkung blieb gleich, auch als mehr Nutzer:innen dazukamen. McKinsey setzte die Erwartungen neu (was das im Alltag für Entwickler:innen und für PMs heißt). Dazu kamen praktisches Upskilling mit Bring-your-own-Code-Sessions und Coaches, vor allem in den ersten Sprints, bevor sich die Gewohnheit bildet. Außerdem führte McKinsey ein Messsystem ein.
  • Die wichtigsten Interventionen bei einem anderen Kunden: Code Labs und neue Zertifizierungen, die zur Veränderung im Alltag motivieren und sie vorantreiben. Einzeln klein, zusammen entscheidend.

Wie solltet ihr die Veränderung messen?

Messt Ergebnisse, nicht bloß die Adoption, um Fortschritt zu verfolgen, Probleme zu finden und schnell gegenzusteuern.

  • Befund der Umfrage: Die schwächsten Großunternehmen maßen nicht einmal die Geschwindigkeit, und nur 10 Prozent maßen Produktivität.
  • Ein ganzheitliches System erfasst die Wirkung von den Ergebnissen bis hinunter zu den Inputs:
    • Inputs: Investitionen in Coding- und andere KI-Tools, dazu Zeit und Ressourcen für Upskilling und Change Management.
    • Outputs: breitere und tiefere Adoption von KI-Tools, die Velocity und Kapazität treibt; Developer NPS und ob Entwickler:innen ihr Handwerk mehr genießen; ob Code sicherer, hochwertiger und resilienter ist. Proxy für Resilienz bei einem Kunden: die mittlere Zeit bis zur Behebung priorisierter Bugs.
    • Wirtschaftliche Ergebnisse (Priorität der C-Suite): Zeit bis zum Umsatzziel, Preisdifferenz für hochwertigere Features, mehr Kund:innen, um die Nachfrage nach Features zu bedienen, Kostensenkung pro Pod durch insgesamt weniger menschliche Arbeit und Reinvestition in Greenfield- und Brownfield-Entwicklung.
  • Das versteht sich als Ausgangspunkt für ein MECE-Framework. Die Proxies entwickeln sich mit den Tools weiter.

Was sollten Führungskräfte jetzt tun?

Über fünf Jahre lässt sich die Zukunft schwer vorhersagen. McKinsey erwartet trotzdem, dass das Modell aus kürzeren Sprints, kleineren Teams und mehr Teams hält. Das gelte auch, wenn Agents intelligenter und Menschen versierter im Umgang mit KI werden.

Die wichtigsten Erkenntnisse:

  • Fangt jetzt an. Das ist eine menschliche Veränderung, eine große Veränderung und ein Weg, den alle gehen müssen.
  • Findet heraus, welches Operating Model für euch funktioniert.
  • Setzt euch ein mutiges Ziel.

Verwandte Seiten

Quellen

Talks und Videos