Scrum & Agile — Practice Q&A
Q: Why isn't the Scrum Master equivalent to a traditional project manager?
A: The Scrum Master doesn't assign tasks, direct day-to-day work, or hold authority over what gets built — that's the Product Owner's domain for prioritization and the Developers' domain for how work gets done. Instead, the Scrum Master serves the team by coaching self-management, removing impediments, and ensuring Scrum events happen and stay productive — a facilitative, servant-leadership role rather than a directive management role.
Q: What are the three pillars of empiricism Scrum is built on, and how do Scrum's events relate to them?
A: The three pillars are transparency (significant process aspects must be visible), inspection (frequently checking artifacts and progress to detect problems), and adaptation (adjusting quickly when inspection reveals a deviation). Scrum's specific events map back to these pillars in a learnable way — Sprint Planning primarily serves transparency, the Daily Scrum primarily serves inspection and adaptation, and the Sprint Review/Retrospective serve inspection of the product and process respectively, leading to adaptation.
Q: Why is the Daily Scrum not a status meeting for the Scrum Master or management?
A: It's a Developer-focused planning and inspection event where the Developers themselves inspect progress toward the Sprint Goal and adapt their plan for the next day. The Scrum Master ensures the event happens and stays within its timebox but doesn't run it as a status-reporting session directed at them — treating it as a status meeting for management directly contradicts the Scrum Master's non-directive role and the Developers' self-management responsibility.
Q: Why does each Scrum artifact have exactly one associated commitment, and what purpose does this serve?
A: The Product Backlog's commitment is the Product Goal, the Sprint Backlog's commitment is the Sprint Goal, and the Increment's commitment is the Definition of Done. Each commitment exists to create shared, objective clarity about what the artifact represents and when related work is genuinely complete — without the Definition of Done, for instance, team members could have different unstated assumptions about whether work is actually finished, undermining the transparency Scrum's empirical process depends on.
Q: What's a "Scrum but" anti-pattern, and why does it undermine genuine Scrum practice?
A: A "Scrum but" pattern is when a team runs Scrum's events on the surface while skipping or watering down key elements that make those events actually function as intended — like a Daily Scrum that becomes a status report to a manager rather than a Developer-led inspection and adaptation session. This undermines Scrum's actual purpose because the ceremonies exist to serve empiricism's three pillars, and watering down their substance while keeping their form defeats that purpose even though the team can claim to be "doing Scrum."
Q: Why does scaling Scrum across multiple teams (via a framework like SAFe) require more than simply running more Scrum Teams in parallel?
A: Scaling introduces coordination challenges — dependency management across teams, portfolio-level prioritization, architectural alignment — that a single Scrum Team's framework isn't designed to address, since Scrum itself is built for one team. SAFe exists as a genuinely distinct framework layered above core Scrum specifically to address these multi-team coordination needs, though this scaling introduces a real tension: added coordination structure can risk reintroducing the kind of top-down process-heaviness the Agile Manifesto's values originally pushed against.