The Scrum Master Who Decides Everything

Self-management means the team decides how to turn the Product Backlog into value - who does what, how work flows, how conflicts are resolved, how quality is protected. Each of her behaviours moves that authority to her: writing the Sprint Backlog removes the team's planning judgement, the round-robin Daily Scrum turns a synchronisation event into upward reporting, and being the sole channel to the Product Owner removes the direct conversations where developers learn what the problem actually is. The weekly individual report adds a second layer, making her the team's performance auditor.

The dependency test is in the data given: when she left, the teams missed their goals and blocked items went unescalated with no one owning the escalation. That is the clearest evidence that self-management has not developed - the teams are compliant, not self-managing, and 'it's faster when she decides' describes short-term throughput bought with long-term capability.

Change first at the Daily Scrum and Sprint Planning, because they happen constantly and set the pattern. At Planning the team selects and decomposes the work; she stays quiet and coaches with questions. At the Daily Scrum the team inspects progress toward the Sprint Goal and re-plans; nobody reports to her. Expect a productivity dip and pushback - say openly why it is happening and what capability is being built.

She should not treat this as an administrative request to be quietly satisfied or refused. First, find the question behind it: is the manager worried about delivery predictability, headcount, cost, or a specific person? Each has a better instrument than per-person story points.

Story points are a team-level, relative estimate of size; they are not comparable across teams and are meaningless per person, because work is done collaboratively and much of the value sits in refinement, pairing and unblocking that produces no 'completed items'. Published per-developer, the chart becomes a target, and the predictable behaviours follow: items split to inflate counts, help withheld because it does not show up on the chart, estimates gamed, and seniors quietly penalised for the mentoring that makes the team work.

A constructive counter-offer: team-level transparency on Sprint Goal achievement, throughput and cycle time trends, escaped defects, release frequency, and the outcome measures the Product Owner cares about - with the caveat that trends across Sprints are informative and comparisons between two different teams are not. If the organisation insists on individual data, she should say plainly what damage it will do and escalate it as an impediment to self-management through the appropriate channel rather than implementing it silently.

Look at what happens without the Scrum Master, and at who holds decision rights. Positive signals: the team runs its own Daily Scrum and changes its format when it stops working; developers talk directly to the Product Owner and to users about what to build; the team negotiates scope when it discovers more than expected instead of waiting to be told; conflicts get surfaced and resolved inside the team; the working agreements are revisited in Retrospectives and actually change behaviour; impediments get escalated by whoever owns them, not by the Scrum Master by default. A useful test is a week of leave - does the Sprint still reach its Goal?

Negative signals are equally diagnostic: everything stalls in her absence, Retrospective actions are assigned to her, the Daily Scrum is a status round when she is not there either, or the team asks her to arbitrate every disagreement.

The mistake to avoid is treating self-management as the absence of structure. These teams need more structure, not less: a clear Sprint Goal, explicit working agreements reviewed regularly, and a shared understanding of who decides what. The measure is not whether the Scrum Master is busy, but whether the team's decisions get better without her in the room.