03Natural allies
Shared roots in empiricism and collaboration, and gaps that each discipline fills for the other.
DDD and Scrum come from different communities and answer different questions, yet they were born from the same frustration with software built far from the people who use it. Their principles fit together with very little friction.
The same roots
The Agile Manifesto was signed in 2001; Evans's book appeared in 2003 and draws on the same culture of iterative development, refactoring and close collaboration. Several of its patterns read like agile principles applied to design. Evans asks for hands-on modelers, people who model and code, rather than architects who hand down diagrams. He describes refactoring towards deeper insight as a continuous activity, not a phase. He treats the model as something discovered through experiments with working software, not specified upfront.
Scrum, in turn, is founded on empiricism: knowledge comes from experience, and decisions are made on what is observed. DDD applies the same empiricism to the model of the domain. Each sprint tests not only the product but also the team's understanding of the business.
| Scrum | DDD | What they share |
|---|---|---|
| Empiricism: transparency, inspection, adaptation | Knowledge crunching and refactoring towards deeper insight | Understanding grows through feedback, not upfront specification |
| Product Owner and stakeholders in every Sprint Review | Domain experts as permanent members of the modelling conversation | The people who know the domain are part of the loop |
| Cross-functional Developers | Hands-on modelers | Those who design also build |
| Product Goal | Core domain | A clear statement of what matters most |
| Working increment | Model expressed in running code | The truth is in what runs, not in documents |
| Small, cohesive teams | One team per bounded context | Cognitive load kept within human limits |
Table 2 · Scrum principles and their DDD counterparts.
Complementary gaps
The fit is not only a matter of shared values. Each discipline is strong where the other is silent. Scrum gives DDD a delivery rhythm, a way to order work by value and a regular moment, the Sprint Review, where the model is confronted with real stakeholders. DDD gives Scrum a structure for the product, a precise vocabulary for the backlog, and a principled way to decide where one team's work ends.
A well-written Product Backlog item already uses the domain's language. A Sprint Goal often describes a capability in one part of the domain. Teams practising Scrum seriously tend to discover DDD's ideas on their own. DDD makes them explicit and repeatable.
A personal note
I came to these ideas through practice before I had names for them. On large public-sector and healthcare projects, the failures I saw most often did not come from technology. They came from the distance between the people who understood the domain and the people who built the software, each group working from its own picture of the product. Long before I could adopt Scrum, the most useful thing I could do as a CTO was to build bridges between subject matter experts, architects and developers. DDD is the discipline that turns those bridges into a method.
Section takeaways
- DDD and Scrum share the same empirical, collaborative roots, so they combine with little friction.
- Scrum gives DDD a delivery rhythm and regular confrontation with stakeholders; DDD gives Scrum structure and precise language.
- Serious Scrum teams often rediscover DDD on their own. Making it explicit saves them the detour.