A Part-Time Scrum Master Who Reports on People

Three conflicts, all damaging: the Scrum Master's capacity, the Scrum Master's reporting line, and the absence of the Retrospective.

• The Scrum Master is accountable for the Scrum Team's effectiveness: coaching the team and the organization, facilitating events, removing impediments, and teaching self-management. At one day a week, with four days of delivery pressure, that accountability is structurally squeezed. Part-time Scrum Mastery is not forbidden in a small team, but here the accountability has no real capacity behind it.
• Worse is the Friday report. Individual progress percentages feeding performance reviews make Priya a judge of the people she is supposed to coach. Developers will stop surfacing impediments and bad news, because bad news becomes a performance issue. Transparency collapses and the Scrum Master's core service, safety to inspect honestly, is impossible.
• Line management and Scrum Mastery should be separated, or at minimum the individual reporting must stop. Team-level transparency is available from the Sprint Backlog, the burn-up of Done work, and the Sprint Review; management does not need a per-person percentage.
• The missing Retrospective explains the pattern: two resignations, three missed Sprint Goals, and no mechanism to inspect and adapt how the team works. The team is not 'too busy to improve'; it is too busy not to.

Position: clarify the Scrum Master accountability with the Head of Engineering, remove the individual reporting, and establish the Retrospective before anything else.

Because Scrum requires one accountable ordering authority, and this setup has none that can act.

• The Product Owner is one person, accountable for maximizing value and for Product Backlog management, including ordering. The Product Owner may delegate work but never the accountability.
• If every change needs monthly steering approval, the Product Owner is a messenger. The team receives priorities from several directions with no single decision-maker, so it cannot optimize for value, and the Sprint Goal becomes meaningless.
• Direct requests from the clinical safety lead and the sales director break transparency: work appears in the Sprint without the Product Owner knowing, the Sprint Backlog stops reflecting reality, and Developers are forced to choose between pleasing a stakeholder and protecting the Sprint.
• Clinical safety input is genuinely important, which is exactly why it must enter through the Product Backlog where it can be ordered against everything else. Sales urgency is not automatically priority.

What to do:

• The Scrum Master coaches the organization on the Product Owner's decision rights and helps the Product Owner negotiate a delegated authority with the steering group: for example, a scope or budget range within which the Product Owner decides, with escalation only above a threshold, and a faster cadence than monthly.
• The Product Owner sets a visible route for requests and communicates it to stakeholders.
• Developers are coached to redirect non-Product-Owner requests politely and immediately, and to raise repeated bypassing in the Retrospective.
• The Scrum Master makes the cost of the decision delay visible, in lead time and missed Sprint Goals, because the argument is stronger with data.

The two events inspect different things: the Review inspects the product outcome, the Retrospective inspects how the team works.

• Sprint Review: the team and stakeholders inspect the Increment against the Sprint Goal and the Product Goal, and adapt the Product Backlog. It is a working session, not a sign-off or a one-way demo. For a one-month Sprint the timebox is at most four hours, shorter for shorter Sprints.
• Sprint Retrospective: the team inspects individuals, interactions, processes, tools and the Definition of Done, and identifies the most useful improvements, which should leave the event with an owner. Timebox at most three hours for a one-month Sprint.

Given the symptoms, the Retrospective comes first, because the team currently has no mechanism to fix anything, including the Review.

• Book it, keep it, and make it safe: focus on the system and the process, not on blaming individuals, especially with two resignations fresh.
• Pick one or two improvements with owners and check them at the next Retrospective; improvement that is never followed up teaches the team the event is theatre.
• Then reshape the Sprint Review: invite the real stakeholders, demonstrate the Increment as it actually runs, and spend at least half the time on 'what should we change in the backlog'. Use the Review to rebuild the relationship with the clinical safety lead and sales director, who currently route around the Product Owner.
• Track the improvement actions alongside delivery work so they are not the first thing dropped when pressure returns.

Scrum Master stance: facilitate both events, model candour, and protect the timeboxes. The pattern of missed Sprint Goals and resignations is feedback about the system, and these two events are where that feedback is supposed to be processed.