What is a Scrum of Scrums and what's shared there?
This tests your understanding of scaling Agile. A good answer defines it as a coordination meeting for multiple teams, focusing on sharing inter-team blockers, dependencies, and integration points, not just status.
WHAT THIS TESTS: This question tests your understanding of how Agile principles scale beyond a single team. The interviewer wants to see if you can think systemically about dependencies, integration points, and cross-team communication. They are evaluating your ability to represent your team's technical work and understand its impact on a larger system, which is a key senior-level responsibility. It is not just about knowing the ceremony, but understanding its purpose in reducing risk for a large project.
A GOOD ANSWER COVERS: A strong answer covers four key points. First, define the Scrum of Scrums (SoS) as a coordination point for multiple teams, often 3-9, working on a single product, not a status meeting for managers. Second, explain its purpose: to identify and resolve inter-team dependencies, blockers, and integration risks before they cause delays. Third, as a technical representative, describe the information you would share: upcoming API contract changes, dependencies on another team's library, a planned deployment that might affect a shared environment, or a newly discovered performance issue in a shared service. Fourth, describe what you would listen for: announcements from other teams that might block your team's progress, opportunities for collaboration, or upcoming changes to shared infrastructure.
COMMON WRONG ANSWERS: A major red flag is describing the SoS as just a bigger daily standup where each team gives a status report (what we did yesterday, what we will do today). This misses the point of focusing on cross-team issues. Another mistake is treating it as a project management meeting to report percentage complete or re-estimate timelines. It is also incorrect to view it as a technical design session; problems are identified in the SoS, but the detailed solution is typically worked out by a smaller group afterward. Finally, saying only managers or Scrum Masters should attend is a weak answer; often, a technical lead or senior engineer is the best representative.
LIKELY FOLLOW-UPS: Expect follow-up questions like: "Who from each team should attend?" (The person best equipped to speak to dependencies, often a tech lead or senior IC). "How often should you hold a Scrum of Scrums?" (Typically 2-3 times a week, with frequency adjusted based on the level of inter-team dependency). "What happens if a major blocker is raised that cannot be solved by the people in the room?" (The group identifies the right people to solve it and empowers them to connect immediately after the meeting).
ONE CONCRETE EXAMPLE: Imagine Team A is building a new checkout service and Team B is building a payment processing service. In the Scrum of Scrums, Team A's representative might say, "We plan to deploy our v1 checkout API to the staging environment on Wednesday. We are dependent on Team B's payment API being stable by then. Is that timeline still accurate?" Team B's rep might respond, "We hit an issue with the third-party payment provider and will not be stable by Wednesday. We need your team's help to mock the response so you can continue testing." This allows the teams to coordinate a solution immediately, rather than discovering the conflict on deployment day.
Read the original → agilealliance.org
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.