The Orchestrator

What does the team look like once the meetings thin out? The titles are still settling — this book was written early enough in the shift that most organizations have not finished renaming anything — but the responsibilities underneath are already distinguishable, and a team running an orchestrated outcome needs four of them covered by name.

The orchestrator designs and maintains the delegated system: the boundaries, the instructions, the permission envelope, the evaluation. Parts I and II of this book were mostly about this person.

The reviewer is the new scarcity. When systems produce most of the candidate work, the bottleneck becomes the judgment applied to it. This is a senior role, not a rote one: judging an almost-right prototype against customer consequences is harder than the old job of producing the prototype, and reviewer capacity has to be planned and staffed like a production system, because it is one.

The approval owner maintains the approval map (the next section), routes each proposed change to the right level, keeps the review queues moving, and tends the escalation paths. In a small team the orchestrator holds this; in a larger one it separates, because the map decays if nobody owns it.

The goal owner is the product voice: the person who writes what outcome the system should improve, and who rewrites it when the business changes. The better the system, the more this role matters, because a system that improves relentlessly will optimize toward whatever goals it was given, including stale ones.

Chapter 11 covers the full responsibility map and the ninety-day transition, and Chapter 12 the training paths; the four roles here are the ones the meeting change makes visible first.

Do you still have a scrum?

For the human work that remains — the exceptions, the design judgment, the customer conversations — run whatever cadence helps the humans. People still forget, people still need to synchronize, and a two-week rhythm can still be a perfectly good container for human attention.

For the delegated work, no. A sprint is a rationing mechanism for scarce human throughput; a system that works around the clock does not have sprints, and estimating its work in story points measures the wrong thing in the wrong units. What replaces the sprint cadence for delegated work is the board and the queue: work items claimed, executed, and evidenced in a task system the agents cannot falsify, which is the subject of Chapter 16. The sprint was a solution to a scarcity that has, for this kind of work, ended.

The frontier version of the question is stranger than the office version. There are now open-source frameworks — BMAD is the most popular — that rebuild the agile roles themselves as agent personas: the analyst, the product manager, the architect, the developer, even the scrum master, each written as a markdown file the AI plays.⁴ A team can run a structured agile process with no humans inside the process loop at all, and roughly forty-nine thousand GitHub users had starred the framework by mid-2026. That is what “do we still have a scrum” is becoming: sometimes the scrum is a prompt.

Do you still need a scrum master?

Usually yes, with a changed job — though the title may not survive the change.

The scrum master’s real skills were never the ceremonies. They were facilitation, impediment removal, and making work visible, and those transfer to the new object. The impediments are different now — a stalled approval, an ambiguous boundary, a review queue nobody watches — and the visibility problem is different too: delegated work is legible if someone tends it and invisible if nobody does. The scrum master becomes the steward of the delegation process: maintaining the approval map alongside the orchestrator, scheduling the evidence-review meetings, watching the fence-hit reports from Chapter 8, keeping the queue of one-person reviews moving, and escalating the things that need escalating.

Some organizations will keep the title and change the job. Some will fold it into the orchestrator role. A few will hand the ceremonies to a persona file and keep the human for the part a persona cannot do: noticing when the people around the system are quietly drowning.