AI Won’t Fix Agile Until You Redesign the Handover

When people ask how AI will change Agile, the conversation usually starts with speed. LLMs write code faster, so perhaps sprints become shorter. Perhaps we stop calling them sprints and start calling them bolts.

That is the surface change.

While helping multi-team organisations adopt AI, I have noticed a harder problem. Teaching teams to use AI tools is only the beginning. If the flow of work stays the same, every function becomes faster at producing work for the next function. The queues grow. The handovers remain. The customer still waits.

AI can make every silo faster without making the organisation faster.

The deeper opportunity is not to compress Agile ceremonies. It is to make the cross-functional way of working that Agile promised more affordable, by turning specialist knowledge into reusable AI skills and moving that knowledge to the work when it is needed.

Agile Was Designed to Stop Work Being Thrown Over the Wall

Before the Agile Manifesto was published in 2001, much software delivery relied on long planning cycles, extensive documentation and sequential handovers. Requirements moved to engineering, engineering moved work to testing, and testing moved it to operations. By the time a customer saw working software, their needs could already have changed.

Agile offered a different model. Deliver useful slices frequently. Welcome changing requirements. Keep business and engineering close. Judge progress through working software. Those ideas are explicit in the principles behind the Agile Manifesto.

The cross-functional conversation mattered as much as the shorter cycle. A business analyst or product manager, an engineer or architect, and a tester could bring three perspectives to the same piece of work. Often called the Three Amigos, they could agree what value they were trying to deliver, what the boundaries were and what done meant before the work travelled too far.

At its heart, Agile is a structural rebellion against silos.

Why Agile Ceremonies Degrade Inside Functional Silos

Sprint planning, story mapping, release planning, bug triage and backlog refinement all depend on the right perspectives meeting at the right time. That is where the design begins to weaken.

Specialists are booked elsewhere. Calendars collide. Triage falls to whoever is available. Refinement becomes a developer writing acceptance criteria alone. A decision waits because the one person who understands a rule is supporting several teams.

The cost of bringing every relevant specialist into every conversation is a cost many organisations struggle to bear. They pay for it elsewhere through queues, defects, rework and decisions made without enough context.

The scoreboard makes this worse. Business analysts may be measured by tickets approved, testers by defects caught or automation coverage, developers by stories closed, and operations by uptime. Each function can improve its own number while the time between a customer problem and a useful outcome barely changes.

Local efficiency is not the same as value delivered.

What Local KPIs Hide: A Payroll Example

Consider a representative problem: a payroll run calculates overtime tax incorrectly and employees are underpaid.

In a siloed organisation, second-line support logs and escalates the issue. The ticket waits for a business analyst, who writes the requirements and passes them on. A payroll consultant reviews the pay rules. A solution architect designs a configuration change. A delivery team builds it. Testing finds an edge case and sends it back. Operations eventually deploys it.

Four weeks later, the fix ships.

Every function can point to activity. Support handled the escalation. The analyst approved a clean ticket. Testing caught a defect. Operations deployed without incident. Yet employees were underpaid for four weeks.

Each silo succeeded. The customer outcome failed.

The example is simplified, but that is the test leaders need to apply: not whether every stage completed its work, but how long the customer remained inside the problem.

Role-by-Role AI Adoption Can Accelerate the Wrong System

Now add AI without changing that flow.

A colleague experience lead uses AI to generate dozens of Jira tickets in one sitting. They have not broken the process. They have accelerated their own role exactly as instructed. The wall between them and the business analyst expected to refine those tickets was already there.

AI turns a trickle into a flood that the next stage cannot absorb. One KPI rises and the next team drowns. Repeat that pattern across each function and the organisation does not become more responsive. It gets a faster, louder version of the same dysfunction.

This is why AI enablement cannot be measured only through licences, active users, prompts submitted or time saved within a role. Boston Consulting Group’s 10-20-70 model makes a related point. Based on its transformation work, BCG advises organisations to put roughly 10% of their AI effort into algorithms, 20% into technology and data, and 70% into people and process change. It is a consulting rule of thumb, not a universal law, but it is useful because it corrects the usual technology-heavy starting point.

Do not automate a role before you understand the flow around it.

AI Skills Make Cross-Functional Knowledge Easier to Reuse

The point of getting the right people into a room was never the room itself. It was shared context, fast feedback and shared ownership of the outcome.

AI changes the economics of creating that shared context through a mechanism the industry now calls an agent skill. The open Agent Skills format packages instructions, scripts and reference material so an agent can load specialised knowledge when a task needs it. OpenAI describes skills in similar practical terms: reusable, shareable workflows that capture how a task should be performed.

A ticket-refinement skill might contain the questions a strong business analyst asks, the organisation’s definition of ready, examples of good acceptance criteria and the boundaries the agent must not cross. A testability skill might turn those criteria into candidate scenarios and flag missing edge cases. A deployment-readiness skill might check that monitoring, rollback and ownership have been considered.

These skills do not replace the specialist. They make part of the specialist’s repeatable thinking available earlier in the work. The specialist can review the output, handle exceptions and make the judgement calls that should remain theirs.

Skills carry reusable practice. People retain accountability and judgement.

A skill is still only guidance until the agent can reach the systems involved. The Model Context Protocol, for example, provides an open standard for connecting AI applications to external systems, tools and data. A refinement skill may need Jira and Confluence. A testability skill may need the test framework and CI results. A deployment skill may need monitoring and rollback controls.

Access is not a minor implementation detail. Every connection needs appropriate permissions, review points and auditability. The ability to act should follow the risk of the action.

Move Skills to the Work, Then Put Humans at the Checkpoints

Imagine the payroll issue again, but with the relevant skills attached to the work from the start.

The analyst’s refinement skill identifies missing pay-rule context and drafts acceptance criteria. The testing skill creates candidate scenarios, including thresholds and employee categories that might be overlooked. The engineering agent inspects the relevant code or configuration. Architecture guidance checks the proposed change against known constraints. Deployment guidance prepares verification and rollback steps.

Some of this can happen in parallel. Each specialist reviews the material that falls within their responsibility, corrects it and makes the decisions only they can make. When AI contributes evidence or a draft, the team still needs a deliberate checking practice. That responsibility does not disappear because the output arrived quickly, as I explain in how to check AI output before you trust it.

This does not eliminate collaboration or guarantee that the first answer is right. It reduces the need to reconstruct the same context at every boundary. People still meet when ambiguity, risk or disagreement requires a real conversation. They no longer need a meeting simply to discover information that could have travelled with the work.

The aim is not to remove the room. It is to reserve the room for judgement.

The Real Change Is the Quality of the Handover

Many Agile ceremonies respond to a coordination problem. Refinement moves business context towards engineering. Planning aligns priorities with team capacity. Stand-ups share changes and impediments. Reviews connect the team with stakeholders. Retrospectives carry learning into the next cycle.

Each interaction can lose context at a functional boundary.

When reusable skills travel with the work, the handover becomes a checkpoint rather than a wall. Business reasoning can be present before implementation starts. Testability can be considered before code is written. Operational constraints can shape the change before deployment.

The handover does not disappear. It becomes richer, earlier and easier to inspect.

Skills flow to the work. Humans flow to the judgement.

Three Leadership Decisions Determine Whether This Works

Measure customer value across the flow

If every function is rewarded for its local KPI, AI will strengthen those boundaries. Measure the outcome that crosses them: time to restore correct payroll, time from customer need to usable change, escaped failure, rework, or another measure tied to the value stream.

The team that restores the outcome should share the result. A silo should not win because it moved the ticket fastest.

Adopt AI across a value stream, not one role at a time

The colleague experience lead and the business analyst cannot adopt AI independently and assume the flow between them will cope. Start with one customer outcome. Map where work waits, where context is recreated, and where judgement is required. Then decide which skills should assist each point and which tools they may safely use.

The unit of AI adoption is the value stream, not the job title.

Design the work before you design the rollout

Most programmes begin with tools, licences and training cohorts. A skills-enabled organisation begins with the work.

Ask what value the team exists to create. Identify the knowledge and judgement that value requires. Decide which repeatable practices can be encoded as skills, who owns those skills, how changes are reviewed, and where a human must approve the result.

Only then should AI be connected to the flow.

A Skills-Enabled Organisation Can Finish What Agile Started

Agile gave organisations a blueprint twenty-five years ago: deliver in small slices, keep feedback close and give teams end-to-end responsibility for value. The idea was sound. The cross-functional attention it required was difficult to sustain at scale.

AI does not complete that blueprint by writing more code or filling the backlog more quickly. It helps when organisations capture repeatable expertise, move it to the point of work and keep people responsible for the decisions that matter.

That is the practical test for any AI rollout. Pick one customer outcome and follow it across the organisation. If AI makes each stage busier but leaves the queues, handovers and local incentives untouched, you have accelerated the old system.

If the value does not flow faster and more safely, the organisation has not become more agile.