04The limits of a single team

The Scrum Guide sets a Scrum Team at typically ten people or fewer. The limit is not arbitrary. It reflects constraints on human communication and cognition that no framework can lift. When a product needs more people than that, the question is not whether to split, but how.

Communication does not scale

Fred Brooks observed in The Mythical Man-Month (1975) that the number of communication paths in a group grows much faster than the group itself. A team of seven has 21 pairs of people who may need to talk. A group of forty has 780. Past a certain size, a growing share of everyone's time goes into keeping each other informed, and Brooks's law follows: adding people to a late project makes it later.

Scrum's answer is to keep teams small and to multiply them. That solves the problem inside each team, but it moves it to the boundaries between teams. Every dependency between two teams is a communication path that must be managed, usually through meetings, shared boards and integration work. The number of those dependencies depends almost entirely on how the product was divided.

Cognitive load

Matthew Skelton and Manuel Pais, in Team Topologies (2019), add a second constraint: a team can only own as much software as it can understand. When the part of the product a team is responsible for exceeds its cognitive capacity, quality falls, changes slow down and knowledge concentrates in a few individuals. Splitting the code base without splitting the understanding of it does not help; a team that must understand everything to change anything is not really a separate team.

Conway's law

In 1968 Melvin Conway observed that organisations design systems that mirror their own communication structure. The observation works in both directions. If teams are organised by technical layer, the system will have strong layers and weak business boundaries. If teams are organised by business capability, the system will tend to follow those capabilities.

This is why the choice of team boundaries is an architecture decision, whether or not anyone treats it as one. Many organisations make it by default, following existing departments, technologies or available people, and then live for years with the architecture that results.

The deliberate alternative, sometimes called the inverse Conway manoeuvre, is to decide what structure the product should have and to organise the teams accordingly. That requires a principled view of the product's natural seams. DDD provides one.