Two firmware Developers disagree about whether to use interrupt-driven or polling-based sensor reads for the new vacuuming robot's obstacle detection. Both approaches are technically workable. What should the Scrum Master do?
Select an answer to reveal the explanation.
Short Explanation
A disagreement about how to build something technical is exactly the kind of call the Developers are equipped and accountable to make, so the Scrum Master's default move is to stay out of the technical content. If the conversation itself gets stuck, that's worth helping with — the decision underneath it isn't.
Full Explanation
How to implement a feature — interrupt-driven versus polling, in this case — is a technical decision squarely inside the Developers' accountability for how they do their work, and the Scrum Master's role doesn't include making or ruling on that call. The most appropriate response is to let the Developers work it through themselves, offering process help (like facilitating a stuck conversation) only if the disagreement is getting in the way of moving forward, not offering a technical verdict. The first wrong option assumes the Scrum Master owns technical quality directly, but the Scrum Guide's accountability for the Developers' craftsmanship rests with the Developers, not the Scrum Master, who serves the team rather than directing its engineering choices. Routing the decision to the Product Owner is a mismatch of accountabilities — the Product Owner manages the Product Backlog and value, not implementation technique, and pulling in a non-technical decision-maker for a technical question doesn't fit either role. Postponing the work and waiting for an outside party to resolve it introduces an unnecessary external dependency for a decision the team is fully capable of making on its own. A useful check: ask whether the disagreement is about what to build (Product Owner territory) or how to build it (Developer territory) before deciding whether it even needs input from outside the two Developers.