The companion-app team and the firmware team, both working on the same home-robot product, spend a Sprint Review blaming each other for a Bluetooth pairing feature that never integrated successfully. What is the most effective facilitation move for the Scrum Master?
Select an answer to reveal the explanation.
Short Explanation
Blame is a signal pointing at a broken process, not a broken person — chasing down whose fault it was just burns time that could go toward fixing the actual gap. A facilitated joint conversation, especially in a shared Retrospective, turns finger-pointing into a real look at how the two teams' work fits together.
Full Explanation
This tests the Scrum Master's facilitation role when the friction sits between two teams rather than inside one: the effective move is to create a structured space — a joint Retrospective works well — where both teams inspect the collaboration itself, not each other's competence. Asking the Product Owner to quietly assign blame misapplies that accountability; the Product Owner owns value and ordering of the Product Backlog, not adjudicating interpersonal disputes, and a private verdict does nothing to fix the underlying coordination gap. Separating the teams onto different schedules avoids the symptom by making integration even harder, which is the opposite of what a product built from firmware and an app actually needs. Letting the blame play out unfacilitated in the Sprint Review wastes stakeholder time and lets the conversation degrade into accusation instead of inspection, since Sprint Review is meant to focus stakeholders on the product, not team conflict. A concrete check afterward: confirm the joint session produced at least one concrete change to how or when the two teams share increments before the next Sprint, not just an apology.