The fourth team

The product started well. One Scrum team, a committed Product Owner, a sprint rhythm that held. Eighteen months later the product has customers, a roadmap and four teams. Something has changed, and nobody can quite say what.

Every team works from the same Product Backlog, and every team touches the same code. A central object, the order, the patient or the account, has grown to dozens of fields, and each team adds a few more every sprint. Pull requests wait for reviewers from other teams. A change in one feature breaks a report nobody knew depended on it. The Sprint Review shows a collection of items from four teams that do not yet add up to anything a user would notice.

The organisation responds the way organisations do. It adds a coordination meeting, then an integration sprint, then a release manager. Velocity, measured per team, looks stable. Throughput, measured as value reaching users, falls.

Nothing in this story is a failure of Scrum's rules. The Scrum Guide tells growing organisations to form several cohesive teams around one product, with one Product Goal, one Product Backlog and one Product Owner. What it does not say, and was never meant to say, is where the lines between those teams should fall. That question belongs to the structure of the product, and the structure of the product belongs to its domain.

This essay follows Scrum in Name Only, which argued that many Scrum teams drop the accountabilities that make the framework work, starting with architecture. Here I look at the discipline best placed to carry that accountability when the stakes rise.

Scrum tells teams how to learn. Domain-Driven Design tells them what they are learning about, and where one team's learning should end and another's begin. For products too large for one team, or too critical to be allowed to fail, Scrum needs both.