A home-robot company's cloud team decides to stop holding Daily Scrums and Sprint Reviews, arguing that inspecting the work too often just interrupts focused engineering time. What tension in the empiricism pillar of inspection does this decision ignore?
Select an answer to reveal the explanation.
Short Explanation
There's a real balance here, and the cloud team is only seeing one side of it. Check too rarely and problems fester; check constantly and you never get anything done — Scrum's five events exist precisely to hit that middle point without either extreme. Cutting the Daily Scrum and Sprint Review doesn't remove overhead, it just removes the early-warning system.
Full Explanation
The Scrum Guide's inspection pillar calls for artifacts and progress toward agreed goals to be inspected frequently enough to detect undesirable variance, while cautioning against inspecting so frequently that inspection itself gets in the way of the work. Scrum resolves that tension by concentrating inspection into a deliberately small number of timeboxed events — the Daily Scrum, Sprint Review, and Sprint Retrospective chief among them — rather than continuous monitoring. Removing those events doesn't free up more focused time in any sustainable way; it removes the team's only formal opportunities to catch drift before it compounds, which tends to cost far more time later. Reducing inspection to once a year abandons the 'frequently enough' half of the balance entirely, especially for a Sprint-based cadence measured in weeks. Assuming adaptation can happen without inspection gets the causal order backwards — adaptation is the response to what inspection reveals, so skipping inspection removes the trigger adaptation depends on. And handing inspection entirely to automated dashboards removes the human judgment and conversation the events are built around; dashboards can support inspection but the Guide's events are about people examining progress together, not passive monitoring. A concrete check: if a team drops an inspection event, look at whether undetected problems (missed dependencies, scope drift) start showing up later and bigger than they would have at the event's natural cadence.