As a home-robot company grows from one Scrum Team to three (app, firmware, and cloud), the app team is repeatedly blocked each Sprint waiting for the firmware team to expose a new sensor API before the app team can build anything visible. What is the most useful thing for the Scrum Master to do?
Select an answer to reveal the explanation.
Short Explanation
A recurring block between teams is an impediment with a pattern to it, and patterns are exactly what a Scrum Master should surface rather than shrug off. Naming it out loud — to the people who can actually reorder the work, like the Developers and Product Owners involved — turns an invisible tax into something the organization can choose to fix.
Full Explanation
When teams split along technical lines, cross-team dependencies are a normal and expected result of scaling, but a Scrum Master's job is to make the pattern of blocking visible and help the people who own the work — the affected Developers and Product Owners — decide how to reduce it, whether through reordering Product Backlog items, refining earlier, or adjusting team boundaries over time. Treating the dependency as simply unavoidable abandons that responsibility; visibility and continuous improvement are core to the role even when the Scrum Master can't unilaterally fix the structure. Directing the firmware team's Sprint Backlog oversteps self-management — the Scrum Master doesn't get to dictate another team's work order, even with good intentions; that decision belongs to the firmware Developers together with their Product Owner. Merging the teams is a drastic structural response to what may be a solvable ordering or refinement problem, and it isn't a decision the Scrum Master makes alone or reaches for as a first move. A concrete check: track how many Sprints in a row the app team lists the same firmware dependency as a blocker, and bring that pattern, not just a single incident, to the people who can reprioritize.