At a home-robot company, hardware, firmware, app, and cloud work are each owned by separate functional departments that hand work to one another in sequence, so no single Scrum Team can produce a done, working Increment within one Sprint without waiting on another department. Who should address this, and how?
Select an answer to reveal the explanation.
Short Explanation
A departmental relay race where firmware waits on hardware, and app waits on firmware, is exactly the kind of impediment that lives above any one team's paygrade — no Developer can restructure the company, and no Product Owner can reorder a department chart the way they reorder a backlog. That's organizational-impediment territory, which means it's the Scrum Master's job to name it loudly and keep pushing on it, even without the authority to fix it alone.
Full Explanation
Producing a usable, done Increment every Sprint requires the Scrum Team to have (or be able to get) everything needed to do that work, and a hard sequential handoff across separate functional departments is a structural impediment that blocks exactly that. The Scrum Master's service to the organization includes helping it understand and remove obstacles between the Scrum Team and value delivery, which is different from having the formal authority to reorganize departments — the role is to make the impediment and its cost visible and to work toward change, not to personally execute a reorg. Treating sequential handoffs as an unavoidable fact of hardware work ignores that cross-functional collaboration, even across disciplines, is what lets a Sprint produce something done; some coordination can move earlier or in parallel even when full concurrency isn't possible. The Scrum Master reassigning people directly overstates their authority — that decision sits with the organization's management structure, not the Scrum Master. Handing it to the Product Owner misassigns the accountability: the Product Owner manages the Product Backlog's content and order, not the company's department boundaries. A caveat: some physical constraints (a PCB spin, a certification gate) genuinely cannot be parallelized and aren't the impediment being described here. Concrete check: ask whether the current department structure was ever explicitly discussed as a source of Sprint-to-Sprint delay in a Retrospective or with leadership, or whether it's just been assumed to be fixed.