Moving Away from Agile: What’s Next? (Category Processes)
I watched a rather grandly framed McKinsey talk from the recent AI Engineer conference. Its main ideas were:
- Current Agile-based operating models do not realise AI tools’ full potential.
- AI-native teams use different workflows, roles and metrics.
- Moving beyond the existing Agile setup is primarily organisational and cultural change, not a matter of installing tools.
The speakers support this with several observations:
- Individual engineers can compress work from days to minutes, while companies see only 5–15% average productivity gains because the surrounding process has not changed.
- AI creates new bottlenecks: allocating work between people and agents, manually reviewing a flood of generated code, and faster accumulation of technical debt and complexity.
- The familiar setup of 8–10 people, two-week sprints, story-driven development and separate frontend, backend and QA roles was designed for human-only development and fits agents poorly.
The title feels like bait. They do not actually propose abandoning Agile, but moving away from a particular implementation: two-week sprints, two-pizza teams and associated rituals. Their replacement is shorter cycles, smaller teams, specification-driven development and changed roles for product managers and engineers.
It is amusing to watch consultants discuss development. I am not sure they have ever written code, so their high-level analysis rests on many studies and cases. They think in terms of portfolios of hundreds of teams, with plenty of attention to change management, measurement, training and organisational redesign. That consulting perspective can still be useful for large corporations :).
More specifically, they propose:
- Moving from quarterly to continuous planning.
- Moving from story-driven to specification-driven development. The PM or lead first works out a sound specification with an agent, then people and agents implement it, reducing refactoring and regeneration.
- Teams of 3–5 people, acting more like full-stack engineers, orchestrating agents and owning architectural areas rather than just one layer.
- Product managers prototyping with coding agents themselves instead of only writing long product requirements documents, or PRDs.
They propose several layers of measurement:
- Investment in tools, training and coaching.
- Adoption, velocity, capacity, recovery time for critical bugs, security and code quality.
- Business outcomes: time to revenue, cost–benefit analysis and opportunities to reinvest in new or existing systems.
The proposal is to change the whole process, rather than attach agents and Copilot to an unchanged Agile workflow.
#Engineering #AI #Metrics #Software #DevEx #Productivity #Management #Leadership