Sprints are not purely for construction. In a broad sense, producing a little bit of product is a goal of every Sprint. But not the *narrow* sense of production or construction people are traditionally thinking of. Sprints 1, 5, 19, and 100 should all contain planning, design, choosing tools, (re-)evaluating the best ways to work together, etc., not just the heads down stuff like coding and testing. I think we’ve all seen the hazards of teams having their heads down too much of the time: a pile of bad code written around faulty assumptions.
One or two architecture “experts” still advocate an initial phase for architecture/design work without the empirical feedback of building and testing a product within that architecture. This is misnamed “Sprint Zero,” but cannot honestly be called a Sprint. As a recovering software architect, I don’t mind saying the notion of architecture as a separate activity ultimately leads back to Frederick Taylor’s idea that we need smart people making decisions for dumb people to execute. The risk of the Sprint Zero idea is its implication we should make our most important decisions on the days we know the least about the project, rather than continuously revisit those decisions.
Another way to look at it: product development is primarily about knowledge creation, and the empirical feedback from the production we do each Sprint is a means toward that end. If we’re trying to foster a learning organization — rather than a pile of bad code — most teams could stand to “produce” a little less and learn a little more each Sprint.