When AI Agents Need a Scrum Master, and When They Need a Spec
Output is up but the metric has not moved. The reflex is to add a standup. Often the stall is an under-defined result, not a coordination gap. The shape of the stall tells you which lever to pull, and they are not interchangeable.
There is a moment most delivery leads hit a few months into an AI-agent rollout. Output is up. The agents write more code, draft more tickets, propose more changes than the team used to produce in a quarter. And the number that was supposed to move, cycle time or throughput, has not. So the lead reaches for what the org already knows how to do: add a standup, tighten the sprint, put a coordinator on the work.
Sometimes that is the right move. Often it changes nothing, because the stall was never a coordination problem. A workflow can also stall for reasons that have little to do with either lever: a model that cannot do the task, a flaky environment, a governance gate, too much work in progress. Rule those out first. What is left is a pair that hides behind the same standup and is easy to confuse: a definition problem and a flow problem.
Quick answer: A stalled AI-agent workflow is often one of two things, and they need different first moves. If completed work keeps coming back substantively wrong, the work was under-defined, and the fix is a tighter specification of the intended result. If acceptable work spends most of its life waiting between people and states, the flow is the constraint, and the fix is to change how work moves, by clearing decisions, owning handoffs, and limiting what is in progress. A specification reduces uncertainty about the result. Flow management reduces waiting while producing it. Many stalls carry both. The shape of the stall, not the standup, tells you where to start.
Most writing in this space skips this decision. Spec-driven-development pieces define the term and hand you a toolkit. Agile-and-AI pieces argue ceremony still matters. Few address the reader's actual problem: you are probably pulling one of two levers when the stall calls for the other, and there is a test to tell which. I will assume you already know what a spec is in the spec-driven development sense. The contribution here is the decision rule, not the mechanism.
The two failures look the same at the standup
Walk into the standup of a team whose agent workflow has stalled and you hear the same three sentences whatever the cause. The work is not shipping. The agent produced something, but it is not right. The change is stuck.
That is the trap. Both problems present with the same surface symptoms, so the management instinct reaches for the same fix, and the fix is whichever lever the org already runs well. For most delivery orgs that lever is agile ceremony, the management layer's comfort zone. So a definition problem and a flow problem get the same prescription, and only one of them is helped by it.
Agents made this sharper, for a mechanical reason. When a human developer was the bottleneck, under-definition surfaced slowly: a developer reading an ambiguous ticket would get uneasy and ask before writing a thousand lines against a guess. That friction was an implicit definition gate. Agents removed it. Hand an agent an ambiguous goal and it does not get uneasy, it builds, fast and at volume, against whatever interpretation it inferred. Under-defined work that used to produce a clarifying question now produces a finished, wrong artifact, fast enough that the wrongness scales before anyone notices. Agents amplify the flow problem too, by pushing more work through the same human handoffs. The standup sees the amplified symptom and cannot, on its own, tell you which amplifier is running.
A loose definition makes a fast agent build the wrong thing
The definition problem has a precise shape. Completed work is technically finished and substantively wrong. The agent did what was asked. The request was wrong, or ambiguous enough that the agent filled the gap with a guess that was not yours. This is not limited to a lone agent on a single task: several agents, or several people, can build confidently against the same defective definition and produce a coherent, wrong whole.
The symptoms are recognizable once you look. Acceptance criteria live in the head of whoever wrote the prompt, not in the work. The agent finishes and the reviewer's first reaction is "that is not what I meant." Rework loops form, each one another round of discovering, after the fact, a constraint nobody wrote down. The agents are not failing to execute. They are executing against a definition that does not exist.
A spec is that definition written down: what the thing must do, what it must not do, which interfaces it has to honor, what counts as done. A real one is usually a chain, requirements to a plan to discrete tasks, with explicit approval points where a human confirms the intended result before the agent acts on it. That chain is what spec-driven development installs once AI agents are doing the building. A specification can coordinate more than one agent and more than one role, because it reduces everyone's uncertainty about the same target. The mechanism is covered elsewhere; the point for the diagnosis is narrow: when the failure is an under-defined result, tighten the definition before reaching for coordination.
This is the lever teams reach for least, because writing a precise definition is slower and less visible than scheduling a meeting. But the cost of skipping it is real. Decades of software-defect research, going back to Barry Boehm's work on the economics of software engineering, hold that the cost to fix a flaw tends to rise the later it is caught, though the slope varies with architecture, test automation, and review burden. Agent velocity does not flatten that curve, it steepens it, because the agent manufactures the downstream consequences of an upstream ambiguity faster than a human would.
The Monday-morning version is concrete. The person writing prompts for the agent stops opening the day by describing a goal in a sentence and watching the agent run. They write the acceptance criteria, the interface contract, and the explicit not-this list first, and only then hand the agent something it can be held to.
A correct build still waits between people
The flow problem has a different shape, and mistaking it for a definition problem is the more expensive error, because tightening a definition does nothing for it.
Here the build is correct. The work is stuck anyway, because it is sequenced across people and the people are the constraint. The PM waits on the BA to confirm scope. The Dev waits on the PM to unblock a decision. QA waits on the Dev. Nothing is wrong with any single piece. The work is correct and motionless, waiting for the next person to pick it up.
The fix is to change how work moves, and a scrum master is one way to facilitate that in a Scrum team, not the definition of the fix. The actual interventions are concrete: give stuck decisions a clear owner and a deadline, define the trigger for each handoff so it stops waiting on a hallway conversation, limit how much work is in progress at once, automate the transitions that do not need a human, and remove approval gates that no longer earn their delay. A scrum master can surface these blockers and help clear them; accountable ownership of the decisions themselves usually sits with product, engineering, or delivery leadership. Calling the intervention "add a scrum master" is shorthand that hides what is really being redesigned, which is the flow.
Agents change the flow problem in a way that is easy to miss. They can remove some handoffs, by consolidating steps or automating a review, but more often they raise the volume of work flowing through the handoffs that remain. More correct builds arrive at the QA queue, more changes at the release queue, and the same people now sequence a larger flow. A coordination structure that was merely strained before the agents becomes the binding constraint after them. Output rose; throughput did not, because throughput was never limited by how fast work got built. It was limited by how fast it moves between states and people. This is the same dynamic, at the role level, as the one where AI speeds up coding and the bottleneck simply moves to wherever the humans still are.
The test that tells which lever you need
If the two failures look the same at the standup, you need a test that does not rely on it. Read the shape of the stall along four signals, none of which is the number of agents, because agent count does not track the cause. A single agent can sit blocked on an approval; a fleet of agents can all build the wrong thing from one bad definition.
| Signal | Definition problem | Flow problem |
|---|---|---|
| Artifact quality | Completed work fails the intended outcome or a constraint | Completed work is acceptable |
| Where time is lost | Clarification and corrective rework | Queues, dependencies, approvals, decisions |
| Where the failure sits | Before or during execution | Between states or owners, after the work is right |
| Repeat pattern | The same misunderstanding recurs | Correct work repeatedly waits |
Read it as a diagnosis, not a menu. Work that comes back wrong, with time lost to rework and the same misunderstanding recurring, is under-defined: tighten the definition. Work that is right but waits, with time lost to queues and unowned decisions, is a flow problem: change how it moves. When the qualitative signals are mixed, one measurement settles it. Pull a sample of twenty to thirty recently stalled items and tag where each one's lost time went: rework against missing acceptance criteria, queue age, blocked time on an unowned decision, failed validation, a broken environment, a governance review. Rework dominating points to a definition problem. Queue age and blocked-decision time dominating points to a flow problem. A pile of failed-validation, environment, or governance time means the stall was one of the more visible causes after all.
These two mechanisms are distinguishable, but they are not cleanly separable and they are not opposites. A workflow often carries both, and you address each with its own move rather than swapping one for the other. They also interact: a sharper definition can reduce coordination load by making handoffs and interfaces explicit, and better flow can expose a definition gap faster. The point is not that the levers are independent. It is that applying coordination to an under-defined result, or a tighter definition to a pure waiting problem, leaves you with activity and no movement, which is the most expensive state a delivery org can be in, because it reads as progress on the standup and shows up as nothing on the metric.
This is an operating-model decision, not a tooling decision
Teams reach for the wrong lever because they read the choice as tooling: pick a spec toolkit or pick an agile framework. Framed as tooling, the default wins, which is why ceremony keeps getting bolted onto definition problems.
It is an operating-model choice, and naming it that way is what makes the decision legible. An operating model for a delivery org is the set of components that govern how work gets done: roles and responsibilities, decision rights, workflows and handoffs, review and control standards, information and system access, incentives, and operating cadence. Neither a spec nor a coordinator is the operating model. Each redesigns a different subset, and the two diagnoses map to different subsets.
A definition fix mostly touches workflows and handoffs, because the spec is the criterion the next stage reads, and review and control standards, because the spec is what review gates against instead of an unwritten intention. It maps onto the early phases of an AI-enabled delivery lifecycle where the contract is set. A specification can also state the scope an agent is intended to work within, but stating scope is not enforcing it: what an agent can actually read and modify is set by runtime authorization, credentials, and sandboxing, an adjacent control surface that the spec informs but does not implement. Keep those separate, or you will write a scope sentence and believe you changed a permission.
A flow fix touches three different components. It changes roles and responsibilities, because clearing handoffs requires each role to have a defined contract with the next. It changes decision rights, because the work is stuck on decisions nobody owns. And it changes operating cadence, the rhythm at which work moves between roles. A facilitator like a scrum master makes those blockers visible and helps clear them, while accountable ownership of the decisions usually still sits with product, engineering, or delivery leadership. It is one component of the operating model, not the whole of it.
Seen this way the decision is sharper than "which tool do we buy." It is which operating-model components you redesign first. The cleanest check on which redesign actually happened is to read the artifact it was supposed to produce. A fixed definition problem leaves a specification precise enough that the work comes back right. A fixed flow problem leaves a sequence with an owner and decisions with deadlines. That read, the artifact as evidence of real change, is the Shift Harness Artifact Test applied to a single decision: do not ask whether the team feels more organized, read what actually moved.
Common mistakes that keep the metric flat
The diagnostic is simple to state and easy to get wrong under pressure, so it is worth naming the failure modes directly.
The most common is bolting more ceremony onto a definition problem. The work keeps coming back wrong, and the response is a tighter sprint and a daily check-in. It feels like control. It produces more meetings and the same wrong output, because the definition feeding the agent did not change.
The inverse is rarer but real: over-investing in specs when the constraint is flow. A team fluent in spec-driven development sees a stall and writes a beautiful, precise contract for a build that was already correct and already stuck in a queue. The contract is excellent. The work still waits three days for a decision, because a contract does not move work between people.
The third is treating activity as performance. More standups are activity. A quiet improvement in the definition, or in the flow, is what moves the metric. The two are easy to confuse because activity is visible and the improvement is not.
The fourth is the skim risk, the one to flag for any reader who got this far and felt the urge to nod along with "ceremony bad." That is not the argument. A coordination problem is a real failure that needs a real flow intervention, and ceremony, a standup or a planning ritual, is one way to sense and facilitate that flow, not the remedy itself. A standup can reveal that work is waiting without changing why it waits; the change comes from owning the decision, defining the handoff, limiting the work in progress. A team that throws out its coordination because an article told them ceremony does not work has made the wrong-lever mistake in the other direction. The levers are not good and bad. They fix different failures, and the contribution is the test that tells you which you have.
Key takeaways
- A stalled AI-agent workflow is often a definition problem (completed work comes back wrong because it was under-defined) or a flow problem (correct work waits between people and states), and frequently both. Rule out the more visible causes first: a weak model, a broken environment, a governance gate, too much work in progress.
- The test is the shape of the stall, not the number of agents: artifact quality, where time is lost, where the failure sits, and whether the same misunderstanding recurs or correct work repeatedly waits.
- A specification reduces uncertainty about the intended result. Flow management reduces waiting while producing it. The two interact but are not interchangeable: applying one to the other's failure gives you activity without movement.
- It is an operating-model decision. A definition fix mostly redesigns workflows and review standards, and informs but does not enforce access scope. A flow fix redesigns roles, decision rights, and cadence, which a scrum master can facilitate while product, engineering, or delivery leadership still owns the decisions.
- Read the artifact to check the fix. A fixed definition problem leaves a precise specification; a fixed flow problem leaves a sequence with an owner and decisions with deadlines.
