Before writing any code, a robotics company's leadership insists the entire hardware-and-software architecture for the whole product line be fully specified and locked down up front, arguing this avoids rework later, so how does this align with Scrum's approach to architecture and design?
Select an answer to reveal the explanation.
Short Explanation
Locking the whole architecture in stone before the first Sprint is like designing every room of a house down to the outlet placement before you've moved in and learned how you actually live — you're guessing at answers you don't have yet. Scrum expects architecture and design to emerge and adjust over time as the Scrum Team learns more from real Sprints, not to be frozen upfront.
Full Explanation
Scrum treats software development as inherently unpredictable, which is why it relies on empiricism — transparency, inspection, and adaptation — rather than trying to plan every detail before work begins. Architecture and design are expected to be emergent: they take shape and evolve across Sprints as the Scrum Team gains real feedback from working software, changing requirements, and hardware constraints that only become clear once actual integration is attempted. Fully locking down an entire product line's architecture before any Sprint starts assumes a level of upfront certainty that rarely holds, especially for a product spanning firmware, hardware, and a companion app, where early assumptions frequently turn out wrong once real devices are involved. This does not mean there is no early architectural thinking at all — some foundational decisions are unavoidable early on — but treating that early sketch as final and unchangeable removes the team's ability to adapt when reality disagrees with the plan. Splitting the rule by hardware versus software, or making it a single approval step for the Product Owner, misses the point entirely, since the issue is not who signs off but whether the design is allowed to keep changing at all. A practical check is to look back after a few Sprints and ask how much of the original architecture document still matches what was actually built — a large gap is normal and expected, not a sign of failure.