The loop works the same on a team as it does solo. Spec, Build, Review — that doesn't change. What changes is accountability. On a team, the roles separate out. The person setting phase boundaries is not always the person running the session. The person who can answer a Review question is not always the Developer who ran the Build.
That separation is the methodology working correctly. It's also where most teams find the friction.
The Spec File is shared
On a solo project, you are the Spec File. You wrote it, you know it, you update it. On a team, the Spec File is a document everyone reads from and only the Product Owner has sign-off authority on. That distinction matters the moment two Developers are running phases in parallel.
Parallel phases are fine. The Spec File handles them — each phase has its own entry, each entry has its own status, and the Review Records don't interfere. What the Spec File doesn't handle is two Developers writing to the same section of it simultaneously. Keep phase boundaries clean and that won't happen.
A shared Spec File only works if it's treated as the source of truth by everyone on the team.
Product Owner sign-off in practice
On a solo project, you sign off on your own phases. On a team, the Product Owner approves phase entries before Build begins. In practice that doesn't mean a synchronous meeting for every phase — it means the PO reviews the spec entry asynchronously and indicates approval before the Developer runs the Command.
What the PO is checking: is the scope right, is the completeness criterion testable, and does this phase match the ticket's intent. Not the implementation — the outcome. A PO who's approving implementation details is doing the wrong job.
The Escalation Ceremony at scale
In a solo project, an unresolved Review question is a reminder you carry yourself. On a team, unresolved questions accumulate across multiple Developers' Reviews and someone has to route them. That's the Scrum Master.
The Escalation Ceremony isn't a new meeting. It's the Scrum Master inspecting the accumulated unresolved questions from the sprint's Reviews and deciding how each one gets resolved — Three Amigos, a PO decision, a domain expert conversation, whatever fits. The SM doesn't resolve the questions. They route them.
What the ceremony produces
| Question type | Typical resolution path |
|---|---|
| Architectural decision (e.g. token rotation strategy) | Three Amigos — Developer, tech lead, PO |
| Product policy decision (e.g. return 200 or 404 for unknown email) | Product Owner decision, written back into the Spec File |
| Ops/infrastructure decision (e.g. alert vs. silent log on failure) | Assigned to ops lead with context from the Review |
| Security question (e.g. per-user vs. per-IP rate limiting) | Security review — tagged with tradeoffs from the Review |
PRs across a team
The traditional PR review — line-by-line inspection for errors — is no longer where the risk lives. AI-generated code is rarely wrong in the ways that kind of review was designed to catch. The real failure modes are spec divergence and comprehension gaps, neither of which shows up in a diff.
By the time a PR is opened in Agentic Agile, those risks have already been addressed: the spec was written before Build, and the Review verified understanding before the phase closed. The Review Record documents what was built and why. Merging becomes a check against that record — does the PR deliver what the spec said it would? — not a fresh inspection of the code itself.
The anchor file at team scale
On a solo project the anchor file is a convenience. On a team it becomes load-bearing. Multiple Developers running phases in parallel means multiple files being touched across multiple tickets simultaneously. Without the anchor file, the only way to know what a file is for is to find whoever last touched it.
With the anchor file, any Developer can open any file and immediately see which ticket owns it, which phase it belongs to, who the assignee is, and what the acceptance criteria were. Editor tooling can surface this inline — no Jira, no spec file hunting, no asking someone. The context is attached to the code.
The anchor file also makes the PR review faster. The reviewer doesn't need to reconstruct context from commit messages and ticket titles. The anchor entry for each file tells them exactly what was being built and why. The question "does this deliver what the spec said?" becomes answerable without leaving the editor.
Onboarding a Developer
You've onboarded a new Developer to a Scrum team. They don't know the methodology. The fastest path isn't a training session — it's pairing them on a well-scoped phase with an experienced Agent Operator. They shadow the Command authoring, watch the Build, and participate in the Review. One phase is usually enough to make the loop concrete.
What they need to understand before running a phase alone: how to write a spec entry, how to write a Command that constrains the agent, and what a good Review question looks like. The Guide covers all three. Reading it first is worth doing.
In practice
Here's a Scrum Master running the Escalation Ceremony — three unresolved questions from the sprint, each routed to the right person.
What doesn't change
The Scrum ceremonies that exist for human coordination still exist. Sprint planning, sprint review, retrospective — these are not replaced by Agentic Agile. What changes is what they're evaluating. Sprint planning is phase scoping, not story pointing. Sprint review evaluates agent-built output against the Spec File. The retrospective is unchanged — it's human-driven, and Agentic Agile leaves it alone.
The loop is the same at any scale. Spec, Build, Review. The roles separate out. The accountability stays intact.