01What Scrum leaves open

Scrum calls itself a framework, and the word is chosen with care. The Scrum Guide describes the minimum needed for empirical work: three accountabilities, five events, three artifacts and their commitments. Everything else is left to the people using it. That restraint is a strength, but it leaves some important questions open.

The Scrum Guide is explicit about what it does not cover. It says nothing about engineering practices, architecture, technology or how the product is built. It expects teams to bring those from elsewhere, and it relies on the Definition of Done and the retrospective to make sure they do.

For a single team on a moderately sized product, that is usually enough. The team can hold the whole product in its head, and its conversations keep the design coherent. As size, criticality and lifespan increase, two questions become impossible to ignore, and Scrum has no answer to either.

How to divide the work

The first question is structural. When one team is no longer enough, the product has to be divided. The Scrum Guide says teams should be cohesive and focused on the same product, and the scaling frameworks, Nexus, LeSS, SAFe and Scrum@Scale, describe how several teams can plan and integrate together. None of them tells you where the lines should fall.

That choice has consequences far beyond the org chart. The way a product is divided determines how many dependencies the teams will have, how often they must coordinate, how much code they share, and therefore how much of Scrum's promised autonomy survives. A poor division can turn five self-managing teams into one large team that pretends to be five.

How to keep meaning

The second question is semantic. Scrum relies on conversations between the Product Owner, stakeholders and Developers to discover what the product should do. Over time those conversations produce a vocabulary, and the vocabulary ends up in the code. If nobody takes care of it, the same word comes to mean different things in different places, and different words come to mean the same thing.

In a small product this is a nuisance. In a large or critical one it is a source of defects that no test catches, because each part of the system is correct according to its own meaning of the word. "Validated" means one thing to the laboratory, another to the pharmacy and a third to the billing module, and the system happily connects all three.

Scrum in Name Only described what happens when architecture has no owner. The two questions above are where that missing ownership hurts most. Domain-Driven Design is the discipline that addresses both of them directly.