Coaching the team and the wider organisation

What the accountability actually is

A Scrum Master is accountable for two things and neither of them is the work. The first is establishing Scrum, discharged by helping everyone understand Scrum theory and practice — inside the Scrum Team and in the organisation around it. The second is the Scrum Team's effectiveness, discharged by enabling the team to improve its own practices within the framework. Both are stated as a mechanism rather than a power: helping, and enabling.

That wording is what disposes of the mandate a new Scrum Master is most often handed. Told to enforce the process and to escalate the names of people who ignore it, he has been given a job the framework does not contain: there is no disciplinary tool anywhere in the accountability, and there could not be, because a team that follows Scrum under supervision stops reporting the problems empiricism runs on. Enforcement buys attended events and a tidy board and quietly costs the honesty that made them worth having. His first organisational student is often his own manager.

The other half of the accountability is the half candidates forget. The Guide calls Scrum Masters "true leaders who serve the Scrum Team and the larger organization", which makes the organisation a party the Scrum Master serves rather than an optional extra once the team is running well. So a marketing department that keeps sending requests straight to individual Developers is squarely her business, and a manager who says her job stops at the team boundary is describing a job description rather than an accountability. Nor is the time she spends outside the team the Developers' to grant: they self-manage their own work, not her accountability, and an option in which they vote to release her is offering an approval body Scrum does not have. When an option confines the Scrum Master to the team, suspect it.

Effectiveness is also not delivery. A programme manager who wants the Scrum Master to guarantee twelve forecast items and to sign off their quality is asking him to take on what the Developers hold — the plan for the Sprint, quality through adherence to the Definition of Done, the daily adaptation of that plan. A forecast is not a commitment in Scrum, the Sprint's commitment is the Sprint Goal, and no agreement between people moves an accountability from one to another. Scrum has no sign-off gate at all: an item either meets the Definition of Done or it returns to the Product Backlog — not released, and not even presented at the Sprint Review — and neither the Scrum Master nor the Product Owner accepts it into existence.

Coaching the team: teaching the decision, not making it

The named services to the Scrum Team are coaching the members in self-management and cross-functionality, helping the team focus on creating high-value Increments that meet the Definition of Done, "Causing the removal of impediments", and ensuring all Scrum events take place and are positive, productive and inside their timebox. Every one of them is about the conditions the work happens in; none of them is the work.

Self-management is the fact this paper hammers. The Developers internally decide who does what, when and how, so a department head who wants the Scrum Master to assign the outstanding work three days in — because the team is clearly not ready to organise itself yet — is offering the most convincing wrong answer on this objective. It sounds phased and responsible, and it is self-defeating: a team organised from outside never gets the practice that makes it capable, so the temporary measure becomes the permanent one. Rebalancing the Sprint Backlog quietly and telling the Developers afterwards is the same error with better manners, and handing the allocation to the Product Owner is a real accountability applied to the wrong decision. Read every option for who is deciding.

The same line runs through the small moments. A Developer asks in refinement how to split an item and the Scrum Master could answer in a sentence — and answering teaches the Developers to bring the next decomposition question to him too. Offering two ways to cut it and asking which one serves the Sprint Goal is coaching; letting his preference settle it is not. The over-correction is equally wrong: declining to engage because a Scrum Master must never influence how the Developers work is not neutrality, it is simply not serving, and teaching and advising are explicit parts of the accountability.

Events belong to the team as well. A Scrum Master who chairs the Daily Scrum every morning, works through a fixed set of questions and notes the blockers has turned re-planning into reporting, and the symptom is that the Developers now speak to her instead of to each other. The Daily Scrum is a fifteen-minute event for the Developers, who select whatever structure and techniques they want; her accountability is that it happens and is productive, not that she runs it, and she takes part as a Developer only when she is actively working on items in the Sprint Backlog. Handing the chair to the Product Owner instead solves nothing: the Developers are then reporting to a different outsider, in an event held for their own re-planning.

Ensuring the events happen is not negotiable either. A team that wants to skip two Retrospectives before a launch is invoking self-management to delete part of the framework, and self-management governs how a team works inside Scrum rather than which bits of it survive. The event is held, and the pressure the team is under is what it inspects. But ensuring it happens is not holding it in the team's absence: the Retrospective is the Scrum Team inspecting itself, so a Scrum Master running it alone while the Developers keep working has held a meeting rather than the event, and an anonymous survey in its place collects opinions without producing either the shared inspection or the improvement the next Sprint is meant to start with.

Serving the Product Owner without becoming one

Service to the Product Owner is help with the how and never a share of the what. The Guide lists helping find techniques for effective Product Goal definition and Product Backlog management, helping the Scrum Team understand the need for clear and concise items, helping establish empirical product planning, and "Facilitating stakeholder collaboration as requested or needed" — where the qualifier is doing real work, because facilitating on request is not owning the stakeholder relationship. Offering to write the backlog items so the Product Owner can concentrate on stakeholders is a kind offer and not on this list; she may delegate that work to whomever she likes, but it is not the Scrum Master's named service, and deciding which stakeholder requests earn a place in the backlog is hers alone.

The trap is set by an absent Product Owner. He has been pulled onto something else, has missed three Sprint Plannings, has told the Developers to take whatever is on top, and the backlog has not been reordered in six weeks. The Scrum Master ordering it herself is fast, helpful, popular and wrong: it moves a value decision to someone who does not hold it, while the Product Owner remains accountable for an ordering he never made. The work of backlog management may be delegated; the accountability never is. So the move is to make the absence visible and to work with the Product Owner and his management on an arrangement that can actually be met, including what he delegates and to whom. Putting the ordering to a vote of the Developers fails the same test — an order nobody is accountable for stops being a defensible view of value. Cancelling Sprints in protest is not available either: only the Product Owner may cancel a Sprint, and only when the Sprint Goal has become obsolete.

The mirror case is a steering committee that hands the Product Owner a fixed ordering each month. A committee that dictates the order is acting as Product Owner, and funding a product does not confer that accountability. Scrum already gives stakeholders a route — convince the Product Owner — and it is a real one, which is why the Guide states that for Product Owners to succeed the entire organisation must respect their decisions. That is an obligation on the organisation, not a courtesy from it. Note where the Scrum Master's work sits: with the committee and the Product Owner, teaching both how influence is meant to travel. Attending to argue the Product Owner's corner leaves the committee still deciding and adds a second voice claiming the backlog.

Serving the organisation: four verbs of help

The organisational list is short and every entry is a verb of help: leading, training and coaching the organisation in its Scrum adoption; planning and advising Scrum implementations within it; helping employees and stakeholders understand and enact an empirical approach for complex work; and removing barriers between stakeholders and Scrum Teams. None is a verb of authority. Options that give the Scrum Master power to approve which teams may change how they work, or to report to management which teams are following Scrum correctly, are wrong on their grammar alone — and the second is the one an audit-minded organisation picks, because compliance reporting turns a servant leader into an inspector and spends the trust the coaching depends on.

Impediments are where this bites hardest. The phrase is causing the removal, not removing, and the difference is the whole answer. When test environments take nine days because a central platform team works by ticket, the Scrum Master could raise and chase every ticket herself; it works immediately and makes her popular, and it makes her the permanent workaround while the queue survives untouched for every other team. Coaching the Developers to forecast less normalises the impediment and hides it from the people who could end it, and putting the delay on the Sprint Backlog makes another department's process the Developers' problem to route around. Causing removal means working on the provisioning process with the platform team and their management, while helping the team cope in the meantime.

Barriers have the same shape. A programme office that routes every stakeholder question through a liaison who forwards a weekly summary installed it for perfectly good reasons, and two Sprints later the Developers no longer know who they are building for. Making the relay daily does not restore a conversation, and making the Product Owner the sole channel rebuilds the same wall with a nicer name. Naming it in a Retrospective is a start and not the end of an accountability, because the team cannot remove this one by itself; the work is with whoever built the layer.

The structural version of the same problem is a team with no tester whose work waits in a central QA queue and finishes after the Sprint has ended: cross-functionality means the members between them have all the skills necessary to create value each Sprint, so the answer runs in two directions — help the team acquire the skill, and help the organisation see why a team that cannot finish its own work cannot produce a Done Increment. Trimming the forecast to fit the queue accepts the dependency for good, and moving the Definition of Done so that hand-off counts as finished is a loss of transparency dressed as progress.

The requests that arrive from outside share one pattern, and it is worth carrying as a rule: neither comply nor refuse, but find the decision behind the request and show the organisation where Scrum already answers it. A portfolio director who wants a weekly percentage-complete and a RAG rating wants confidence, and an inspectable Increment at the Sprint Review — where the results of the work are shown to key stakeholders and progress toward the Product Goal is discussed — answers that better than a summary of a summary. Writing the report makes the Scrum Master a reporting function, and asking the Developers to write it buys his time with theirs while still teaching the directors that a document is where the truth lives. Refusing on the grounds that Scrum permits no reporting outside the Sprint Review is the opposite failure: it invents a prohibition the framework does not contain and leaves a real need unmet.

A line manager who wants each Developer's completed points for the appraisal round is asking for a measure Scrum does not produce. The entire Scrum Team is accountable for a valuable, useful Increment every Sprint, and scoring people separately sets them competing inside a unit designed to be collective; the Developers' consent does not repair that mechanism. Nor does the word transparency rescue the request — transparency in Scrum is the artefacts and the progress toward a goal being visible, not individuals held up for comparison. It is the same instinct that has a team counting closed items while three of them miss the Definition of Done.

A finance director who will not release a budget without a signed twelve-month feature list is best served by an empirical approach — a Product Goal, funding a team rather than a list, steering the year on real Increments. Inventing the dates destroys the transparency his own decisions rest on, and estimating harder does not turn a projection of unstarted work into knowledge.