Skip to content

Knowledge base

Moving away from Agile: McKinsey's AI operating-model research

McKinsey's survey of about 300 enterprises found AI lifts company-level productivity only 5 to 15 percent, because teams keep agile-era sizes, sprints and roles. Top performers were 7x likelier to run AI-native workflows and 6x likelier to have AI-native roles in smaller pods.

Written by

Updated:

Evidence 7

Our position. We read this result as an org-chart effect, not a tool effect: with agents, coordination becomes the bottleneck, not capacity, so small pods are the unit. If the team topology is unchanged since before agents, the AI budget funds overhead, not output (The org-chart effect (opens in a new tab)). We hold, as a hypothesis, that the agile values gain value even as their artifacts turn volatile (LinkedIn post (opens in a new tab)). The hypothesis comes from hycle (opens in a new tab), the “hyper cycle”: an open, German-language sketch of an operating model for work once AI agents take over implementation, published under CC BY-SA 4.0 by six practitioners, one of them from h&w.

McKinsey’s SoftwareX practice supports the first half from a global survey and from client interventions at a bank and a tech company (Moving away from Agile: What’s Next (opens in a new tab)). Its title reads as a farewell to agile; its evidence is about team size, roles and cadence, the artifacts rather than the values.

Why does AI demand a new operating model?

Every major technology breakthrough of the last decades came with a paradigm shift in how software is developed. Agile was the last one (Kanban boards, standups, ceremonies). AI is the next. The talk focuses on the people and operating-model changes AI demands, which McKinsey argues must change significantly, rather than on the tools.

Why do individual gains not reach the enterprise?

Individual productivity wins are everywhere: tasks that took days or hours now take minutes. Yet those wins do not translate to the enterprise.

  • McKinsey surveyed about 300 companies, mostly enterprises, globally.
  • On average these companies report only 5 to 15 percent overall productivity improvement.
  • A disconnect exists between AI’s potential and the realized company-level reality.

Which bottlenecks does faster coding expose?

Speeding up parts of the work exposed constraints that were not binding before:

  • Collaboration between people and team members has not changed to keep pace.
  • Far more code is generated, but review stays manual in many companies.
  • New generated code amplifies tech-debt generation and adds complexity in some cases (cited to a Carnegie Mellon research report).
  • Work allocation is a rate limiter: AI impact is highly uneven across tasks (some see huge gains, some little) and across people (varying experience with the tools), making it non-trivial for engineering managers to allocate work and resources well.
  • Review overhead: agents are given stories in prose with fuzzy acceptance criteria, so returned code often misses intent, and manual review is the only control mechanism.

Most large companies are stuck in marginal gains because they still work under constraints of the human-development paradigm: 8-to-10-person teams, two-week sprints, agile-era operating models. Breaking that model into smaller teams, new roles, and shorter cycles produces large performance improvements.

Which human-agent model fits which work?

Different engineering functions along the product life cycle need different human-agent operating models:

  • Modernizing legacy codebases: needs high context (potentially the entire codebase) but has well-defined outputs. Model: a factory of agents where humans provide an initial spec and final review with minimal intervention.
  • New features (greenfield and brownfield): benefit from non-deterministic outputs and increased variation. Model: an iterative loop where agents act as co-creators, providing more options to enable faster feedback loops.

What separates top performers from the rest?

From the survey of 300 enterprises, top performers were:

  • 7x more likely to have AI-native workflows: scaling AI over more than four use cases across the software development life cycle, rather than point solutions for just code review or just codegen.
  • 6x more likely to have AI-native roles: smaller pods with different skill sets and new roles.

To enable the shifts, these organizations invested in continuous hands-on upskilling, impact measurement, and incentive structures that reward developers and PMs for adopting AI. The result: a 5-to-6x increase in time to market and delivery speed, plus higher-quality and more consistent artifacts.

What changes in workflows and roles?

AI-native workflows:

  • Quarterly planning gives way to continuous planning.
  • The unit of work moves from story-driven to spec-driven development: PMs iterate on specs with agents instead of long PRDs.

AI-native roles (talent):

  • The two-pizza team gives way to one-pizza pods of three to five people.
  • Separate QA, frontend, and backend roles consolidate into product builders who orchestrate agents with full-stack fluency and understand the full codebase architecture.
  • PMs create prototypes directly in code rather than iterating on long PRDs.

McKinsey studied AI-native startups that implemented all these shifts; their article describes how Cursor operates internally.

What did a bank change at team level?

For a large enterprise built on the agile model, McKinsey ran a study with a leading international bank, testing team-level interventions around the sequencing of agile ceremonies and the split of roles between agents and humans in the sprint cycle:

  • Team leads assign sprint stories using agents, based on team velocity and delivery-history data.
  • Teams co-create multiple prototypes and iterate with agents on acceptance criteria for security and observability, producing more consistent artifacts across teams and preventing downstream rework.
  • Squads reorganized by workflow: one for small bug fixes, one for greenfield development.
  • Background agents check potential cross-repository impacts to cut developer debugging time.
  • To reduce collaboration overhead and sprint meetings, PMs observe real-time customer feedback directly instead of waiting for data-scientist input, reprioritizing features and accelerating the backlog in the same time window.

Measured results at the bank:

  • Agent consumption increased by over 60x.
  • Delivery speed rose, tied directly to the bank’s business priorities.
  • 51 percent increase in code merges, alongside an efficiency increase.

Why do roles lag behind?

Changing roles was one of the biggest differentiators. Engineers move from execution and writing code to orchestration and dividing work among agents; the PM role is also changing.

  • Yet about 70 percent of surveyed companies have not changed their roles at all: the expectation that people work differently exists, but the role definition has not changed.
  • In another client, McKinsey tested smaller pods with consolidated roles. With the same number of people, this created more pods (more teams) while each pod performed at roughly the prior level, maintaining and in some cases improving code quality, with a high speed-up in team output.

How do you scale the change across hundreds of teams?

Many companies run not one or two of these teams but hundreds of teams and thousands or tens of thousands of people. The biggest gap between the stuck (about 10 percent improvement) and the outsized performers is change management.

  • Change management is getting many small things right at once: communication, incentives, upskilling. Scaling often means getting 20, 30, or more things right at the same time.
  • A tech-company example: tools were rolled out across the product life cycle, usage appeared but dropped off or stayed suboptimal, and overall impact did not change even as users were added. McKinsey reset expectations (what this means day-to-day for a developer, for a PM), added hands-on upskilling with bring-your-own-code sessions and coaches, especially in the first few sprints before the habit forms, plus a measurement system.
  • Another client’s top interventions: code labs and a new set of certifications to motivate and drive day-to-day change. Individually small, together decisive.

How should you measure the shift?

Measure outcomes, not just adoption, to monitor progress, pinpoint issues, and course-correct fast.

  • Survey finding: bottom-performing enterprises were not even measuring speed, and only 10 percent were measuring productivity.
  • A holistic system captures impact from outcomes down to inputs:
    • Inputs: investment in coding and other AI tools, plus time and resources spent on upskilling and change management.
    • Outputs: increased breadth and depth of AI-tool adoption driving velocity and capacity; developer NPS and whether developers enjoy their craft more; whether code is more secure, higher quality, and more resilient. Resiliency proxy used with a client: mean time to resolve priority bugs.
    • Economic outcomes (C-suite priority): time to revenue target, price differential for higher-quality features, expanding customers to meet feature demand, cost reduction per pod from reduced human labor in aggregate, and reinvestment in greenfield and brownfield development.
  • This is offered as a MECE framework starting point; the proxies will evolve as tools evolve.

What should leaders do now?

The future is hard to predict over five years, but McKinsey expects the model of shorter sprints, smaller teams, and a larger number of teams to hold even as agents get more intelligent and humans get more AI-fluent.

Key takeaways:

  • Start now. This is a human change, a big change, and a journey everyone needs to go on.
  • Figure out which operating model works for you.
  • Set a bold ambition.

Resources

Talks and videos