Scrum Master

Importing scrum wholesale often left the ceremonies as form without function. A daily scrum fixed at 15 minutes stretches to 40 and becomes everyone reporting what they did yesterday, with the listeners waiting for their turn. In the retrospective, the same item recurs every cycle because nobody was named to fix it, so it appears again next time. A ceremony that produces no change stops being attended honestly within a month.

Clearing blockers was empty too. While an engineer waits two weeks for another team's answer, nobody treats that wait as their own work. The person waiting doesn't think it's their job, and the other team doesn't know a request arrived. Asked at the end of the cycle why something didn't finish, the answer is always that they were waiting. Nobody is lying, and nothing in the process assigns that wait to anyone.

Putting the work on a manager broke somewhere else. When the person holding performance and compensation runs the retrospective, nobody speaks candidly. "Priorities keep changing" doesn't get said in front of the person changing the priorities.

So a seat appeared that tends the process without evaluating people. It has no authority to assign work, and in exchange it gets the team to keep the rules the team set for itself. Those two properties are what make the seat work at all.

Running meetings takes under an hour a day. The rest goes to clearing blockers, preparing the next ceremony, and filtering incoming requests outside the team. Six kinds of work move through a day.

1. Running the daily scrum. Holding the 15 minutes is this seat's job, and what the meeting looks for is blockers rather than status. When two people start a detailed discussion, they get cut off and pointed at a conversation after the meeting.
2. Clearing blockers. You keep a separate list and work a few items a day: chasing another team's answer, pulling a legal review forward, rescheduling with an outside vendor. It's work that costs an engineer half a day when they do it themselves, and most of it is knowing who to ask.
3. Preparing and running the cycle's ceremonies. Checking in sprint planning that the committed amount doesn't exceed real capacity, making sure the right people are in the sprint review, and attaching an owner and a date to every retrospective item. The owner and the date are what separate a retrospective from a complaint session.
4. Tending the metrics. Showing velocity and the shape of work remaining to the team — with the accompanying rule that these numbers don't go into evaluations. The moment they do, the team starts producing the numbers rather than the work.
5. Tracing why work carried over. When spillover happens three cycles running for the same reason, that's a process problem rather than an individual one.
6. Blocking mid-cycle requests. When another team speaks directly to an engineer, the request gets routed to the product owner. Not refusing it — making the door a single door, so that what got added is visible at the end of the cycle.

What the seat doesn't hold is equally clear. It doesn't assign work, doesn't touch performance or compensation, and doesn't decide what gets built first. Take on any of those three and candid talk disappears from the retrospective.

Four people a day.

1. The product owner. What comes first is their call, and keeping that decision from shifting mid-cycle is the scrum master's. At Pagedeck, Mia holds that seat alongside her own.
2. Engineers and designers. When Theo or Noa names a blocker, it goes on the list and gets cleared from outside. How something gets built isn't decided here.
3. The same role on other teams. Past three teams, you attend the scrum of scrums where team representatives align on what they're waiting on from each other.
4. Managers and executives. When Grace asks about progress, you answer on the team's behalf but never as per-person progress. Once individual reporting starts travelling upward, the daily scrum becomes a status meeting again the following cycle. The distinction sounds pedantic until the first time it isn't kept.

Holding the seat alongside another is common. A 45-person company can't staff it separately, so a product manager or an engineer doubles up. The doubling isn't the problem by itself; overlapping with the person who sets priorities is. It removes the place where "priorities change too often" could be raised. Which is why doubling on the engineering side works better than on the product management side.

"Take that discussion after the meeting, you two. We're past fifteen minutes."

Facilitation that protects the purpose of the meeting.

"You've been waiting two weeks on the auth team? I'll chase it today."

Taking a wait off an individual.

"Send that request to me and I'll talk to Mia first."

Keeping the incoming door single.

Spillover is what made Pagedeck staff this seat at all. For three cycles running, more than half the committed work carried over, and the retrospective produced the same reason every time: they were waiting on another team or an outside vendor.

Theo took the role alongside his own, built a separate blocker list, and walked that list every morning. Two cycles later, carried-over work was down to a sixth. No new rule had been introduced; the only change was that the waiting had an owner, and an owner who could spend a morning on it.

The most common reading is that this is the person who runs meetings. Facilitation is the visible part, so the assumption comes naturally. But facilitation is under an hour a day, and clearing blockers in the remaining hours is what the seat actually is. Treat it as facilitation and you staff it only on days with ceremonies, which returns clearing waits to nobody's hands. The ceremonies keep happening and the spillover keeps happening with them.

The other frequent belief is that it's another name for team lead. Something sits in front of the title and the person runs meetings, so it reads that way. But the seat has no authority to assign work or evaluate anyone. It works through influence rather than authority, which is why the way it gets rules kept is by pointing at agreements the team made rather than by instruction. Treat it as a team lead and the retrospective becomes a one-on-one and the daily scrum becomes a report.