What AI is doing to Agile teams, and what nobody is saying out loud

Let me start by saying the obvious thing that some Agile practitioners seem reluctant to admit: AI coding tools work. GitHub's own research showed developers completing tasks up to 55% faster with Copilot. McKinsey's 2024 analysis of developer productivity put the uplift from AI pair programming at between 20 and 45 percent depending on task type. When a developer can describe a feature in natural language and get a working first draft in seconds, something has genuinely changed.

Spec Code Development, the practice of writing detailed specifications or prompts and letting the AI implement, is the logical extension of this. Developers are no longer writing every line; they are directing, reviewing, correcting, and composing. The role has shifted. The throughput has increased. For certain categories of work, particularly well-understood, bounded tasks, a single developer with good prompting skills can now produce what used to require a team.

I have watched developers who were previously mid-range contributors become extraordinarily productive almost overnight, once they learned how to work with these tools effectively. The ceiling has moved. If you are leading an Agile team and you are not taking this seriously, you are not paying attention.

Here is what I am observing underneath the productivity story, and it concerns me far more than any question about code quality or technical debt.

When a developer has an AI model as their primary collaborator, the pull toward working alone becomes very strong. The model is available at any hour. It does not push back on your framing in uncomfortable ways. It does not have ego investment in a different approach. It does not need you to explain your reasoning before it helps you. It is, in a purely practical sense, an extraordinarily frictionless working partner.

The problem is that the friction was doing something important. The pull request review where your colleague asks why you did it that way is not just a quality gate; it is a knowledge transfer mechanism, a trust-building moment, a check on your blind spots. The quick conversation with the designer before you start implementing is not just alignment; it is shared ownership. When these moments are replaced by a developer and their AI working in a self-contained loop, the team becomes a collection of parallel solos. The work ships faster. The team, in any meaningful sense, stops existing.

Amy Edmondson's research on psychological safety, which remains the most reliable predictor of high-performing teams, is built on the premise that people are interdependent: that they need each other to do the work. When AI tools make individual contributors genuinely less dependent on their colleagues, you do not automatically lose psychological safety, but you lose the daily conditions that maintain it. Safety atrophies when it is not exercised.

This is the question I am hearing more and more from coaches and engineering leaders, and I think it deserves a direct answer rather than the usual hedge.

Scrum was designed around a specific assumption: that knowledge work of meaningful complexity takes days, not minutes, to complete. The two-week sprint is a container sized for that reality. Sprint planning, the daily standup, the review, the retrospective: all of these ceremonies are calibrated to a world where a story moves through a predictable arc of design, build, review, and test over the course of several days.

Spec Code Development breaks that assumption. A task that used to be three days of work can now be done in two hours by a developer who knows how to prompt effectively. The sprint container suddenly feels enormous for some work and still too small for genuinely complex problems. Sprint planning becomes difficult to do honestly when one developer's capacity effectively triples while another's remains unchanged. Velocity, the metric Scrum teams use for forecasting, becomes nearly useless when the same story can take forty minutes or two days depending on how well-scoped the AI's input was.

The DORA 2024 research observed exactly this: AI adoption was increasing average throughput while making individual item predictability worse. Elite teams were faster but less forecastable at the ticket level. Scrum, which depends on relatively stable velocity for its planning rhythm, struggles to absorb that kind of variance.

My honest view: Scrum, applied without modification to a team doing Spec Code Development at scale, will create more friction than it removes. The ceremonies will feel disconnected from the actual rhythm of the work. Developers will stop treating standups as useful. Sprint reviews will either be underwhelming because everything is done early or chaotic because the last-minute complexity arrived unpredictably. The form will persist but the purpose will drain out of it.

Kanban is a serious answer to this question, and I want to treat it as such rather than dismissing it as a consolation prize for teams that 'cannot do Scrum properly.'

The core of Kanban, limiting work in progress and optimising for flow, maps well onto what AI-assisted teams actually need. When a developer can implement quickly but review and integration become the bottleneck (which they often do, because the AI generates more code faster than the team can thoughtfully absorb), a WIP-limited flow system surfaces that bottleneck immediately. A fixed sprint does not. It hides it until the end of the iteration, when everything piles up at review.

Kanban also sidesteps the estimation problem entirely. Lead time and cycle time, the metrics Kanban teams use for forecasting, are derived from actual flow data. You are not asking people to estimate how long something will take; you are measuring how long comparable things have actually taken. In a world where AI makes effort highly variable and difficult to predict in advance, probabilistic forecasting from historical cycle time data (as advocated by Daniel Vacanti and the broader #NoEstimates movement) is genuinely more honest and more accurate than story point estimation.

For teams doing continuous delivery, where work flows in a steady stream rather than discrete batches, Kanban is a natural fit. If your team is shipping multiple times a day and the concept of a sprint review feels artificial given that the product is always live, the sprint model is adding ceremony without adding value.

That said, Kanban has its own demands. It requires disciplined management of the board, genuine commitment to WIP limits (which teams routinely violate when under pressure), and explicit policies about how work enters and exits each stage. It is not simpler than Scrum; it is differently structured. Teams that drift to Kanban because they have given up on process, rather than because they have deliberately chosen flow, tend to end up with neither discipline nor delivery.

Beyond the Scrum-or-Kanban binary, there are approaches that I think deserve more attention in the context of AI-assisted development.

Shape Up, the method developed at Basecamp and described in Ryan Singer's book, works from an entirely different premise: instead of estimating stories, teams commit to an appetite, a fixed amount of time they are willing to spend on a problem, and then shape the work to fit that appetite. There is no backlog in the traditional sense. There are no story points. There are six-week cycles and a deliberate cooldown between them. For teams doing Spec Code Development, the appetite model is interesting because it shifts the conversation from 'how long will this take?' to 'how much is this worth to us?' That is a far healthier question in a world where AI makes duration unpredictable.

Flow-based Scrum is another option that I have seen work well for teams that want to keep the social structure of Scrum (the shared cadence, the review, the retrospective) while dropping what no longer fits. Keep the sprint as a shared heartbeat and a forcing function for collaboration. Drop story points entirely. Use the sprint goal as the unit of commitment rather than a set of sized tickets. Measure cycle time rather than velocity. This preserves what Scrum does best, which is create regular moments of collective alignment, while releasing the estimation ritual that AI has made unreliable.

The thread connecting all of these alternatives is the same: move forecasting from prediction to observation. Stop asking people to estimate how long things will take. Start measuring how long things actually take, and use that data to have honest conversations about what is achievable. AI does not make forecasting impossible; it makes estimation-based forecasting obsolete. Those are different problems with different solutions.

Whatever framework you choose, the harder question is how you keep a genuine team, rather than a group of high-performing individuals, while everyone is working increasingly with AI.

The answer is not to restrict AI tool usage or to force pairing that feels artificial. That creates resentment without solving the problem. The answer is to redesign the team rituals so that they are doing work that AI cannot substitute.

Shared specification writing is one of the most effective approaches I have seen. Before anyone picks up an AI tool to implement, the team writes the specification together. Not in the AI. In a room, or a shared document, or a structured conversation. Who is this for? What problem are we actually solving? What does done look like, and how will we know? This is the work that requires human judgment, domain knowledge, empathy for the user, and the kind of constructive disagreement that a model will not generate. Make this a team activity, not an individual one.

Shared review of AI-generated code is equally important. Not just code review in the traditional sense, but deliberate conversations about the design choices the AI made and whether the team endorses them. This builds collective understanding of the codebase at a time when individual developers risk developing knowledge silos around the code only they and their AI have touched.

Retrospectives need to evolve too. Add questions specifically about AI use: where did the AI help us think more clearly, and where did it steer us wrong? What did we learn this cycle that the AI did not know going in? These questions keep learning collective rather than individual.

And finally, do not underestimate the value of the conversations that have nothing to do with delivery. The team lunch. The end-of-cycle moment of acknowledgement. When individual productivity increases, the temptation is to cut everything that is not directly output-generating. This is exactly backwards. The human connective tissue matters more, not less, when the tools are making everyone more capable of going it alone.

The leaders I am most impressed by right now are not the ones asking how to get the most productivity out of AI tools. They are asking a harder question: how do we use AI to make our teams more capable without making our teams less necessary to each other?

That question does not have a simple answer. But asking it is the difference between an organisation that comes out of the AI transition with stronger teams and one that comes out of it with faster individuals who have forgotten how to genuinely collaborate.

Kent Beck, one of the original authors of the Agile Manifesto and the creator of Extreme Programming, observed recently that programming is changing fundamentally, and that the skills that will matter most are the human ones: judgment, communication, and the ability to articulate a problem clearly enough that both humans and AI can work on it. I think he is right. And I think teams that invest in those human skills now, even as they adopt AI tools enthusiastically, will be the ones that still function as teams five years from now.

The tools are not the threat. Forgetting why the team existed in the first place is the threat.