The Impediment Nobody Owns

Yes - this is squarely in remit. The Scrum Master serves the team by removing impediments to progress, and serves the organization by helping it adopt Scrum effectively. An impediment that both teams hit every Sprint, that costs most of a developer-day per build, and that is now causing batching and a 30% defect rise is not a team-level coaching issue. It is an organizational impediment, and the Scrum Master is the person accountable for surfacing and pursuing it.

The manager's 'focus on team-level coaching' framing sets up a false choice. Coaching the teams to 'cope' with a 4-6 hour build would be coaching them to work around a problem the organization should fix - and the workaround (batching) is already degrading quality. A servant-leader removes the obstacle rather than teaching people to live with it.

What the Scrum Master should not do is try to fix the build infrastructure personally or demand budget. The role is to make the impediment visible, find the owner, and facilitate resolution - not to become the platform team.

Escalate the problem, not the person, and bring the cost with you.

1. Quantify. Convert the impediment into the organization's language: two teams × 6 weeks × builds per day × hours lost = developer-days per quarter; plus the 30% defect rise and the batching risk. A one-page cost statement beats a complaint.
2. Find the real decision-maker. The platform lead has effectively declined ownership; the question is who sets the platform team's priorities this quarter. That is a leadership/prioritization decision, so go to that person - with the platform lead informed, not bypassed. 'I'm escalating the cost, not your team; I'd like you in the room.'
3. Give leadership a choice, not a demand. Present options: (a) prioritize build infrastructure this quarter, (b) fund a short-term fix (e.g., caching/parallelization) owned jointly, (c) accept the cost explicitly and record it. Option (c) is legitimate if made consciously - the Scrum Master's job is to make the trade-off visible, not to force a particular answer.
4. Respond to the manager. Explain that this is the servant-leader duty to remove impediments, that you are not asking for budget, and that you will timebox the escalation. Ask the manager to sponsor the conversation with leadership - a manager's voice often opens the door a Scrum Master's cannot.
5. Keep the teams informed. Tell both teams what you are doing and what you are not able to promise, so they don't conclude the Scrum Master is ignoring them.

If leadership consciously accepts the cost, the Scrum Master has still succeeded: the impediment is now owned and visible, not orphaned.

Treat the workaround as a symptom to make transparent, not a discipline problem to punish.

• Name it in the Retrospective: the teams are batching because the build is slow. That is a rational response to a real constraint. Acknowledging it keeps the Retrospective honest.
• Make the cost visible in the team's own data: larger batches mean later feedback, which shows up as the 30% defect rise. Let the teams see the link, and let them decide whether to accept larger batches knowingly or find a smaller mitigation (e.g., build only affected modules, run a fast smoke build per change and a full build nightly).
• Protect the Definition of Done: whatever workaround is chosen, it must not let 'done' slip. If batching means integration defects escape, the DoD needs to reflect that until the build is fixed.
• Do not let the workaround become permanent by silence. Record it as an accepted risk with an owner and a review date, so that when leadership revisits priorities, the cost is on the table.

The Scrum Master's stance: 'We are working around a constraint we do not own. Here is what it is costing us, here is what we are doing in the meantime, and here is who needs to decide.' That is servant leadership - serving the team's progress while serving the organization's ability to see the truth.