AI Is Rebundling Roles, Shrinking Some Teams, and Raising the Bar for Responsible Delivery
9 min read
My first article for 2026. I’ve been back in my software roots, weeks of looping with Geoffrey Huntely’s Ralph Wiggum, visiting Steve Yegee’s Gastown, and swapping my earlier AI requirements and repo/tasking workflows for tighter, spec-first execution: GSD (Getting Sh*t Done repo) style, with planning modes that actually keep pace.
As much fun as I have been having implementing code, this article is about leadership and software delivery, not a new AI tool. It was sparked by a headline I’ve seen so many times I can almost predict it: “moving away from Agile,” “Agile is obsolete,” “Agile is dead.”
This time it was a YouTube title from a major consulting firm: “Moving away from Agile: What’s Next” (McKinsey). I wasn’t surprised, consulting narratives have a way of “ending” whatever you’re doing to make room for the next wave of services. I’m not here to debate the video. I’m here to challenge the pattern behind that headline, because it keeps coming back, and now it’s being repackaged as an AI-era conclusion.
I keep seeing “Agile is dead” headlines, now repackaged for the AI era. My take: AI isn’t killing Agile. AI is illuminating constraints that were already in the value stream.
If coding gets faster and lead time doesn’t improve, the bottleneck was never engineering output. It was prioritization, dependencies, validation, operability, and decision latency.
That’s the problem with the “Agile is dead” narrative: it confuses a delivery wrapper with a business capability.
Agility is not a sprint calendar, a Jira workflow, or a job title. Agility is a capability: the organizational skill to sense change, make decisions, and deliver value quickly enough to learn and adapt before the market moves again. Put prototypes in customers’ hands sooner. Shorten the time between “we think” and “we know.” Reduce the cost of being wrong. That capability is a competitive requirement in modern software businesses, not a trend we can retire.
In the post, I outline the load-bearing responsibilities that never go away, why roles will rebundle as teams shrink, and why Value Stream Management (VSM) and flow metrics matter more as AI increases delivery capacity. I’m genuinely curious about where others see the constraint shift as AI adoption grows.
In November, I wrote When AI Isn’t Enough to make a simple point: AI accelerates output, but it doesn’t replace fundamentals, judgment, or accountability. This article is a follow-up to that argument, focusing on the delivery operating model. https://rethinkyourunderstanding.com/2025/11/when-ai-isnt-enough/
What is changing, and changing fast, is how teams cover the work. AI compresses execution time, reshapes roles, and makes low-value ceremony impossible to defend. But it does not delete the responsibilities required to deliver software safely in the real world.
So no, Agile isn’t dead. Maybe what’s dying is Agile theater.
The debate is mislabeled
When people say “Agile is dead,” they’re often reacting to dysfunction that deserves to die:
- Standups that are status meetings
- Backlogs that are graveyards
- Sprint plans exist to create the appearance of control
- Story points treated like productivity
- “Agile transformations” where leadership behavior never changed
If that’s your lived experience, the conclusion feels tempting: the system is heavy and slow, and AI just made the contrast painful.
But that doesn’t mean agility is obsolete. It means your organization was using a process to simulate control.
Agility was never about the ceremonies. Agility is the ability to learn fast under uncertainty. Scrum and Kanban are just different ways to manage that learning loop. AI doesn’t remove the need to steer. It raises the stakes on steering because the engine just got bigger.
Team size can shrink. Responsibility surface area does not
AI is making smaller, stream-aligned teams more feasible in some contexts. You can feel it in the language: “builders” is becoming a popular label precisely because it implies broader ownership, people who can take an idea and move it forward end-to-end with help from tools and agents.
But here’s the part leaders keep getting wrong:
Shrinking the team does not shrink the work that must be covered to deliver and operate software responsibly.
Roles can be consolidated. Responsibilities do not disappear.
AI is collapsing traditional role boundaries within cross-functional teams.
Product managers can now use AI to do meaningful slices of work that used to require separate specialists: synthesize customer feedback at scale, interrogate trends in quantitative data, draft PRDs and acceptance criteria, and produce “good enough” prototypes that accelerate discovery and alignment.
On the delivery side, engineers are increasingly being pulled both upstream and downstream, tightening requirements, exposing edge cases, and improving the spec-to-task chain, while also generating test ideas, acceptance scenarios, and risk-based coverage faster.
This compresses cycle time and rebundles work into fewer hands, but the obligations don’t change: decisions still need evidence and judgment, and shipped changes still must be secure, validated, and operable. AI accelerates artifact creation, it doesn’t shift accountability when those artifacts are wrong.
If you reduce staffing without deliberately reallocating responsibilities, you don’t get a faster team. You get a fragile one that ships wrong faster.
This is the core misunderstanding in the “AI killed Agile” narrative. AI can take on more of the production of work. drafting, synthesizing, generating, and executing. It cannot take on accountability. And it absolutely cannot eliminate the need for clear ownership of the full delivery lifecycle.
The delivery “load-bearing system” that never goes away
No matter what toolchain you use, AI agents, copilots, code generators, a mature product team still has to cover the same end-to-end responsibility surface area across the value stream. AI can accelerate pieces of it, but it doesn’t delete the categories.
It is like the load-bearing structure of a building. You can renovate the interior all you want, swap tools, shrink teams, rebundle roles, automate entire phases, but you don’t get to remove the beams and call it innovation. If you take out the load-bearing parts, the building might look fine for a moment, right up until you add speed, scale, and real customer demand. Then it fails in expensive, public ways.
AI changes the finishing work and the pace of construction. It doesn’t change what’s structurally required for software delivery to hold up under pressure.
You still need outcome clarity: what problem you’re solving, for whom, and what success means.
You still need discovery and validation: evidence, constraints, and signals that the work is worth doing.
You still need work design: thin slicing, sequencing, WIP discipline, and dependency management.
You still need engineering coherence: architecture, contracts, data correctness, security, and privacy-by-design, tradeoffs that hold under change.
You still need verification and resilience: automated tests, performance and reliability checks, security validation, and confidence in recovery.
You still need delivery and operations: CI/CD, safe rollouts, observability, incident readiness, and cost hygiene.
And you still need learning loops: feedback into priorities, retrospectives with teeth, continuous improvement grounded in bottlenecks rather than opinion.
Call it Scrum, call it Kanban, call it flow. This surface area of responsibility is the reality of software delivery. The framework doesn’t change the reality. It changes how you manage it.
What AI actually changes: distribution, not elimination
AI is changing delivery systems in a few predictable ways.
First, it reduces the cost of producing executable clarity. PRDs, briefs, acceptance criteria, architecture options, test cases, runbooks, and documentation can be drafted quickly. That doesn’t remove the need for these artifacts. It changes who can draft them and how fast teams can iterate.
Second, it makes verification loops cheaper and more continuous. This is where the conversation should be. AI does not make quality automatic. It makes quality automation easier if you design for it. The winning pattern isn’t “AI wrote it, ship it.” The winning pattern is “AI drafted it, then the system verified it repeatedly until it earned release confidence.”
Accountability doesn’t move to the model. It stays with the team.
Third, it moves the bottleneck upstream. When execution gets cheap, delays show up where they have always lived, but were easier to ignore when coding was slow:
- Unclear priorities
- Slow decision-making
- Messy dependency networks
- Environment and access friction
- Data quality and migration risk
- Compliance and governance
- Weak observability
- Unclear ownership
AI makes building faster. It makes those problems louder.
So if your end-to-end lead time doesn’t improve after “AI productivity gains,” don’t assume you outgrew Agile. You just discovered that engineering output was never your constraint. Your value stream was.
One-pizza teams still need full coverage, so roles rebundle
This is where AI is forcing the real change, and it’s also where the “Agile is dead” headline is most misleading.
In larger teams, you can afford specialists. In smaller teams, the same responsibilities exist, but fewer people are responsible for them. That forces rebundling, and it demands clearer ownership.
Even the smallest stream-aligned team needs a few capability anchors, whether those anchors are full-time roles or shared hats:
- An outcome anchor who protects clarity and success measures
- A technical anchor who owns coherence, integration risk, and tradeoffs
- A quality anchor who owns the verification strategy and release confidence
- A flow anchor or delivery manager who owns WIP discipline, bottleneck visibility, and learning loops
- An operability anchor who owns SLOs, observability, and incident readiness
In a two-pizza team, these might be separate people. In a one-pizza team, one person may cover multiple anchors, with AI agents often taking on more of the drafting, research, and execution within each area. But the anchors still need named ownership. Otherwise, the responsibilities become “everyone’s job,” which quickly turns into “no one’s job.”
This is also where the “builder” identity can go right or wrong. “Builder” can mean end-to-end ownership and tighter loops. Or it can become a euphemism for “we removed roles and hoped the work disappeared.”
With AI, the work doesn’t disappear. It redistributes.
Scrum and Kanban are not obsolete (they are context tools)
A lot of “Agile is dead” takes quietly translate to: “timeboxes feel slow, therefore Scrum is obsolete.” That’s not how mature teams think about frameworks. Mature teams choose mechanisms based on context.
Scrum is useful when a team needs a forcing function for planning cadence, stakeholder inspection points, and a regular rhythm of alignment, especially while decision rights and trust are still maturing.
Flow-based systems become more attractive when deployments are continuous, work items are consistently small, WIP limits are respected, and dependencies are visible and actively managed.
AI nudges many teams toward flow because small batch size and fast verification become even more powerful. But “nudges” is not “replaces.” What AI really kills is ceremony without outcomes.
VSM matters more as AI adoption rises
Here’s the test I keep coming back to: If AI speeds up coding and your end-to-end lead time stays the same, your constraint is not engineering output. Your constraint is the value stream.
That’s why Value Stream Management and product operating models matter more, not less, in an AI-shaped world. You need visibility into where work actually waits. You need clarity on decision rights. You need an operating system that can absorb higher delivery capacity without increasing rework and production risk.
AI is an accelerator. The product operating model is the steering and the guardrails. If steering and guardrails are weak, AI doesn’t create agility, but creates faster confusion.
That’s why, in an AI adoption wave, VSM and the product operating model become non-negotiable: it converts raw delivery capacity into aligned outcomes through visibility, ownership, decision rights, and investment boundaries.
AI can starve your teams upstream if discovery and prioritization can’t keep up.
AI can jam your teams downstream if validation and operational readiness can’t keep up.
When the loops get out of sync, speed doesn’t feel like acceleration. It feels like chaos.
What to keep, what to drop, what to add
If you want a more useful conversation than “after Agile,” try “after Agile theater.” Keep what preserves learning and reduces risk. Drop what exists to create the appearance of control.
Add what makes teams AI agent-ready without surrendering judgment: engineered clarity, continuous verification loops, guardrails by design, and flow metrics that expose constraints across the full value stream, not just inside engineering.
The claim I’ll keep making in 2026
Agile isn’t dead unless someone can point to a genuinely new delivery model that eliminates the core responsibilities of building software fast, safely, and under uncertainty.
AI changes speed and redistributes responsibilities, and who does the work. It does not remove the obligation to make sound decisions, validate rigorously, and operate reliably. Accountability has not changed.
So yes, teams will shrink in some contexts. Roles will rebundle. Titles will evolve. “Builders” will become a common identity. AI agents will take on more implementation, research, and drafting. But the delivery foundation remains.
And if you’re tempted to post “Agile is dead,” I’ll offer a challenge instead: Tell me what will replace an organization’s benefit of becoming more agile? Or which responsibility set disappeared? Or tell me you’re really talking about theater.
Either way, we’ll have a more honest conversation.
Poking Holes
I invite your perspective on my posts. What are your thoughts?.
Let’s talk: phil.clark@rethinkyourunderstanding.com
References
- Moving away from Agile: What’s Next – Martin Harrysson & Natasha Maniar, McKinsey & Company (YouTube).