Two senior developers clash on implementation, derailing sprint planning. Your role?

WHAT THIS TESTS: This question tests whether you understand that an Advanced Scrum Master or facilitator does not eliminate conflict but channels it into collaborative tension. The interviewer wants to see that you can protect Scrum event timeboxes while preserving psychological safety, and that you have concrete facilitation techniques rather than generic platitudes about communication.

A GOOD ANSWER COVERS: Four things in order. First, immediate timebox protection: you explicitly park the deep technical debate to preserve sprint planning, either by creating a follow-up session or by allocating a strict timebox within the current event. Second, reframing the conflict: you separate people from problems, acknowledging that both developers care about product success but have different risk tolerances or constraints. Third, structured dialogue: you describe a specific technique such as timebox-driven dialogue with phases for uninterrupted perspective sharing, clarifying questions only, common-ground identification, and integrative brainstorming; or conflict mapping to visualize positions versus underlying interests. Fourth, decision mechanism: you explain how to move forward without false consensus, whether through a spike, prototype evaluation, decision criteria weighted by the team, or escalation with clear data rather than emotion.

COMMON WRONG ANSWERS: Three red flags stand out. One is letting the meeting derail while you act as a passive observer, which signals weak facilitation. Another is forcing a quick vote or overruling one developer to end discomfort, which creates winners and losers and drives resentment underground. The third is proposing that the two developers simply talk it out later without structure, which ignores power dynamics and often lets dominant voices win.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle the same situation if the two developers report to you as an engineering manager rather than as peers in Scrum. They might also ask what you do if the conflict reappears in every retrospective or if one developer consistently dominates. Another follow-up is how you measure whether team psychological safety has improved.

ONE CONCRETE EXAMPLE: You might say that in a recent sprint planning session, two senior engineers disagreed on whether to build a custom queuing system or use a managed service. I paused the debate, validated both concerns, and proposed a fifteen-minute timebox. I used a whiteboard to map each position to the underlying need: one needed throughput guarantees for peak load, the other needed faster time to market. We discovered the real question was whether peak load would occur in the next two sprints. The team agreed to a two-day spike to measure realistic traffic patterns, and we finished sprint planning on time.

Source: agileseekers.com