The Scrum Master as coordinator, and a retrospective that repeats itself
A newly appointed Scrum Master takes over a team of seven in a company that recently renamed its project managers to Scrum Masters. In her first three weeks she is copied on 30 emails a day asking her to update a Gantt chart, approve leave, and chase test environments. The Daily Scrum runs 22 minutes, dominated by a principal engineer who reports to the group and to whom two juniors defer; the remaining four speak only when asked. The Retrospective has produced the same action for four Sprints - "improve communication between developers and testers" - with no owner and no follow-up, and the team rates it 3 out of 5 in her anonymous check. In the last Retrospective the principal engineer said the testers "should just ask if they need something", after which nobody raised the topic again. The Test Manager has separately asked her to institute a weekly defect triage meeting with mandatory attendance, saying the team's defect escape rate of 12 percent is unacceptable.
1. How do you handle the 30 emails a day - Gantt updates, leave approvals, environment chasing - without becoming the team's administrator?
Read the worked answer
Sort the requests before answering any of them, because they are not the same kind of request.
- Environment chasing is a genuine impediment: removing it is core Scrum Master work. I would take it, then fix the cause rather than the symptom.
- Gantt updates and status reporting are coordination work that belongs with the Product Owner and the team, and are derived from the Product Backlog. The right answer is not a hand-maintained Gantt but a view generated from the backlog, plus a conversation with the requestor about what decision they are actually trying to make. Forecasts should come from the team, empirically, not from one person's spreadsheet.
- Leave approvals are line-management administration. Routing them to a renamed project manager is an organisational habit; redirect to the line manager.
None of that works if it is delivered as refusal. The real move is upward coaching: meet the manager who renamed the project managers, agree in writing what the role is for, and show evidence - three weeks of calendar data with the proportion of time spent on coordination versus coaching and impediment removal. Then negotiate a transition rather than announce one.
Servant leadership does not mean absorbing every request. It means making the team's ability to self-organise the priority, and being willing to say that a request is not the Scrum Master's to fulfil - while helping the requestor find who it belongs to.
2. Diagnose why the retrospective action never changes anything, and design the intervention for the next retrospective.
Read the worked answer
Diagnosis: the action is a symptom stated as an abstraction ("improve communication"), with no owner, no observable change, no follow-up, and - most importantly - a safety problem. The principal engineer's remark closed the topic down, and nobody reopened it. A retrospective that cannot discuss the room it is held in will keep producing safe, useless actions. The 3-out-of-5 rating and the 22-minute Daily Scrum with four silent members are the same signal.
Intervention design:
- Before the event: short one-to-ones with each person, including the principal engineer and at least two testers, asking what makes handoffs slow and what would need to be true for them to say it in the room. With the principal engineer, use specific observed behaviour and its impact, not character judgement.
- In the room: silent individual writing first, then 1-2-4-all, then dot voting - structure that gives the quieter four a contribution before the dominant voice frames the discussion.
- Narrow to one experiment: written as a hypothesis with an owner, a measure and a review point ("testers join refinement for the two highest-risk items; measure defect age and questions raised per Sprint; review at the next retrospective").
- Open with the previous action - reviewing it first is what makes follow-up real.
- Put it on a visible improvement board the team sees during the Sprint.
- Look at the data: defect age, wait time between handoff and first response. "Communication" may actually be a queueing or a Definition of Done problem.
3. The Test Manager wants a mandatory weekly defect triage meeting because of a 12 percent escape rate. How do you respond?
Read the worked answer
Treat the request as a proposed solution to a legitimate problem, and separate the two. A 12 percent escape rate is a real quality signal and I would not dismiss it; mandatory attendance at a new meeting is a specific, costly solution that may or may not address the cause.
First, get the data: which defect types escape, at what stage they are being caught, and how long they sit. Then check the system rather than the meeting: does the Definition of Done include the test types that would have caught these defects? Is there test automation? Are testers a separate silo receiving finished work, which would explain both the handoff friction and the escapes? Is the team under pressure that makes skipping verification rational?
Then respond with a counter-proposal rather than a no. Options include: the team owns a short daily or per-Sprint quality check with a rotating two-person attendance rather than a whole-team weekly hour; strengthened Definition of Done and automated checks; and a joint session where the team and the Test Manager agree the countermeasures and the measure that will show whether they worked.
I would also name the boundary explicitly. A mandatory meeting imposed from outside the team conflicts with self-management. The Test Manager is entitled to set the quality goal and to see the data; the team should design the mechanism. If the escapes persist after the team's own countermeasures, that is the moment to accept a standing triage forum - as a deliberate choice with evidence, not as an imposed ritual.