Agile improved software development by shortening feedback loops, delivering incrementally, and keeping teams close to changing needs. Those principles remain useful. What changes in an AI-assisted lifecycle is the machinery used to put them into practice.
Keep the principles, inspect the rituals
A standup, sprint, refinement session, or retrospective is a mechanism. The purpose is coordination, commitment, feedback, or learning. Teams should preserve the purpose while testing whether the mechanism still matches the speed and shape of work.
A ceremony that exists only because information was previously hard to assemble is a candidate for automation or asynchronous replacement. A conversation that resolves ambiguity, conflict, or consequential tradeoffs remains valuable.
Planning shifts from tasks to intent
Traditional planning often decomposes work into implementation tasks because human capacity is the binding constraint. Agent-assisted execution puts more weight on the specification: objective, boundaries, affected systems, acceptance evidence, and decisions that require human authority.
The plan becomes an execution contract. It should tell an agent what it may change, what it must verify, where authoritative context lives, and when it must stop.
Execution becomes continuous, authority does not
Agents can inspect, implement, test, and prepare changes outside a meeting cadence. This enables work to progress asynchronously, but it does not imply continuous authorization. Risk-based gates still determine who can approve architecture, data migration, security policy, or production impact.
The distinction is important: execution speed is a technical property. Authority is an organizational property.
Review focuses on evidence
When implementation becomes abundant, reviewing every line with equal attention does not scale. Review should begin with intent and evidence: what changed, why, which assumptions were used, which tests passed, what remains uncertain, and which policies apply.
Humans concentrate on disagreements and judgment. Deterministic systems handle repeatable proofs. The result is still iterative delivery, but the iteration spans specifications, context, implementation, and verification.
Change a team’s week, not its vocabulary
The Agile principles emphasize working software, frequent delivery, reflection, and sustainable work. The proposal here is to preserve those purposes while testing the mechanisms. AI does not make a particular meeting obsolete by definition.
In the fictional Northstar case, the team keeps a weekly prioritization conversation because it needs to compare customer problems. It replaces a daily status recital with a visible state board. It retains a short live discussion when Checkout and Orders disagree about key retention. Each change has a reason beyond enthusiasm for automation.
| Mechanism | Proposed change | Evidence to inspect |
|---|---|---|
| Backlog refinement | Resolve executable-ticket gaps before admission | Clarification and rework after execution starts. |
| Daily status | Publish owner, blocked reason, and next decision | Whether dependencies actually receive responses. |
| Review | Limit concurrent patches to review capacity | Queue age, review effort, and escaped defects. |
| Retrospective | Choose one correction and an owner | Whether the correction affects later work. |
The board does not need a new tool. It needs trustworthy state. An agent-generated update that claims a blocked task is nearly done is worse than no update because it consumes the team’s attention budget under false pretenses.
Admission and interruption
Suppose the team can review two consequential changes a day. It should not start ten simply because execution is available. Define a small work-in-progress limit, make blocked work visible, and let people finish verification before admitting another batch.
Incident response needs a separate, explicit priority path. Record what was interrupted and revalidate context before resuming it. A task that began under yesterday’s API decision should not continue under today’s assumptions by accident.
Keep estimates where they help investment and dependency decisions. Stop treating generated-code volume as evidence that commitments became easier. The uncertainty may have moved into investigation, review, or adoption.
Run one reversible process experiment
Choose one recurring ceremony and name the job it performs. Try a replacement for two team cycles, with an owner and a review date. Track an outcome such as unresolved dependencies, not merely meetings removed. Ask a new team member whether they can still discover decisions and raise an objection.
If coordination or learning gets worse, restore the interaction. Record which function the replacement failed to serve before trying another change.