The organization

The Scrum Team

A Scrum Team is a small team that brings together everything needed to build a product and put it into its users' hands, without depending on another department. Four patterns from A Scrum Book explain this choice: Scrum Team, Conway's Law, Small Teams and Cross-Functional Team.

Six weeks to change one sentence

A mutual health insurer wants to change one sentence on its online membership form, because it misleads members about the date their coverage starts. The request goes from the legal department to the team in charge of specifications, which writes up a ticket. The front-end team changes the page, the data team adds a field, the test team checks everything three weeks later, and the operations team puts it online on the date set for the next batch. Six weeks have gone by, and everyone has done their job properly.

The time was lost between the teams, at each handoff. The request waited its turn in five queues, and each team had to work out again what the previous one already knew.

Scrum Team: a small business within the business

The pattern Scrum Team (two stars) has as its context a person who has the Vision of a product and a few ideas written down, without yet knowing how to build it or whether the ideas are right. Its problem: "Many great Visions are beyond the reach of solo efforts, and to achieve such a Vision you need to build the complex product, bring it to the market and leverage feedback."

The pattern describes several forces.

Too much specialization deprives the team of a skill just when it needs it, because needs vary from one delivery to the next.
Separating those who know the need from those who build creates a handoff. The former place an order, often with a deadline set without knowing what is feasible, and all the latter can do is go faster.
Someone who builds only a small part, as on an assembly line, loses sight of the whole product.
People learn better with fast feedback and different perspectives, and those caught up in building have little time to think about how they work.

The solution: "Form a team that has all the necessary competencies: the people who can make and deliver the product (a Development Team), a Product Owner who guides product direction, and a ScrumMaster who facilitates learning." (The book writes ScrumMaster as one word.) The team works as a small business within the organization, able to make on its own the decisions that respond to its customers. The pattern specifies that it is usually the Product Owner who brings the team into existence, and that the Product Owner and the Developers together choose the Scrum Master.

According to the book, Jeff Sutherland derived this form from the work cell of the Toyota Production System, splitting the role of its Chief Engineer between the Product Owner, for the business focus, and the Scrum Master, for the process focus.

Conway's Law: the organization shows up in the product

In 1968, the computer scientist Melvin Conway published an article in the magazine Datamation entitled "How Do Committees Invent?". Its thesis is that "organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations." Fred Brooks gave this observation the name "Conway's law" in The Mythical Man-Month (1975). The insurer's form illustrates it: it is divided into layers (screens, data and tests) because the company is.

The pattern Conway's Law (two stars) draws from it a rule for designing organizations. Its problem: "Effective communication and feedback are at the heart of effective complex system development, and the organization structure should be optimized for the most crucial paths of communication."

The forces pull in opposite directions. People communicate best with those around them, and small teams are the most effective, which means the work has to be divided up. Yet a team develops an identity and gives less weight to what comes from outside, so that a single way of dividing the work stifles ideas that cross boundaries.

The solution: "Organize the workforce into Small Teams of more or less five people, partitioned according to the most important concerns for the creation of value by the enterprise. Supplement this structure with a small number of cross-cutting structures for secondary but important concerns." What matters most is usually the market. So Scrum teams form around what is delivered to users, not around internal components or areas of expertise. The pattern gives the example of a cell phone maker, with one team for the address book, one for the calendar and one for the calling functions. Cross-cutting groups set common rules, such as the look and feel of the user interface (the Birds of a Feather pattern, see Stable, co-located teams).

The pattern advises against the opposite arrangement, in which each team owns a part of the product. The smallest change then requires several teams to coordinate, decisions are no longer made on the spot and feedback arrives late.

Discharging a surgical patient. In a private hospital, the discharge of a patient after hip surgery depends on five departments: surgery signs the authorization, physiotherapy approves walking with crutches, the pharmacy prepares the prescription, social services arrange home help and the secretariat writes the discharge summary. The patient receives five separate documents, which sometimes contradict one another on when they may start putting weight on the leg, and often stays an extra day because a signature is missing. The discharge file mirrors the organization chart. The hospital then sets up a "hip pathway" team: a lead surgeon, two nurses, a physiotherapist, a social worker and a medical secretary, who meet for ten minutes every morning in front of the list of patients. The patient now receives a single document, and each specialist continues to train with their peers in their home department.

Small Teams: why five people rather than fifteen

The pattern Small Teams (two stars) starts from a temptation: "When there's a ton of work ahead, you are tempted to throw the world at it." Its problem is that complex work, such as product design, demands a high degree of shared knowledge and coordination, and it defies this approach.

Some forces push toward growth: several pairs of eyes correct the biases of one, deadlines encourage adding people, and a manager's status is sometimes measured by the size of their team. Others push back. The bigger a group gets, the more communication costs, and some people contribute less than they would alone, which psychologists call social loafing. The pattern cites Ivan Steiner (1972), for whom the actual productivity of a group is its potential productivity minus the losses due to coordination.

A simple calculation shows the scale of the effect. In a group of n people, the number of one-to-one relationships is n × (n − 1) / 2. Five people have 10 relationships to maintain, seven have 21, ten have 45 and fifteen have 105. In 1975 Fred Brooks drew from this a famous rule: adding people to a late software project makes it later still.

The solution: "Use Small Teams of people working on serialized work rather than striving for false parallelism." The pattern speaks of "around five or so people" without setting a number, and it advises experimenting. Among the studies it cites, an experiment by Tatsuya Kameda and colleagues (1992) on groups of two, four, six and twelve people found the best performance per member in groups of four, and a 2012 study of software projects found lower productivity from nine people up. If the team grows nonetheless, the Mitosis pattern describes how to split it (see Scaling up).

Cross-Functional Team: all the skills inside the team

The pattern Cross-Functional Team (two stars) has as its problem a team that "is not able to work autonomously because it does not have all the skills required to complete a complex network of tasks." When it depends on people from outside, it controls neither its lead times nor the quality of the result, and it cannot take ownership of finishing.

On the side of the forces, a complex product calls for varied talents, which are rarely found in a single team. Organizations readily group people by function, which makes each function efficient on its own ground and coordination between groups costly: departments write "contracts" with one another, with request forms and response times, and the product as a whole slows down while each department improves. Conversely, adding one person to the team for each missing skill would make it too big, and learning a new skill takes time.

The solution: "Each Scrum Team should include all talent necessary to deliver Done functionality", that is, work that is finished in the sense of its Definition of Done. The requirement applies to the team as a whole, and it does not ask every member to be able to do everything. When putting the team together, the pattern advises looking at skills, and even more at enthusiasm for the Vision and a track record of learning new things, because needs will change.

Over time, members train one another, which lets one stand in for another and several work together on the same item (see Swarming). When a skill is still missing, the pattern falls back on common sense: the team asks another team for help or subcontracts a piece of work. If this becomes frequent, it should be treated as an impediment and remedied by training, reorganization or hiring.

The insurer, a year later. The insurer has formed two teams around two customer journeys, membership and reimbursement. Each includes a Product Owner from the contracts department, two front-end developers, a data developer and a tester. One Scrum Master divides their time between the two. In the membership team, the data developer is at first in constant demand, and the team decides that the two other developers will make every database change in a pair with him for two months. Tests no longer wait three weeks: the tester writes the test cases with the Developers before work begins. Putting changes online, at first reserved for operations, was added to the list of impediments, then handed to the team for the pages of the form. A sentence that needs correcting is now dealt with in the current Sprint.

What the 2020 Scrum Guide says

The 2020 Guide takes up the essence of these patterns in a few sentences. The Scrum Team, the fundamental unit of Scrum, consists of one Scrum Master, one Product Owner and Developers. It is cross-functional, "meaning the members have all the skills necessary to create value each Sprint", and it is self-managing. Three differences from the book are worth knowing.

Size. The Guide speaks of ten people or fewer for the whole Scrum Team. The book aims smaller: about five people, and no more than about seven Developers.
The team within the team. In the book, the Developers form a Development Team that has its own identity within the Scrum Team. The 2020 Guide removed this notion and states: "Within a Scrum Team, there are no sub-teams or hierarchies."
Growth. When the team becomes too large, the Guide asks for it to be reorganized into several Scrum Teams that share the same Product Goal, the same Product Backlog and the same Product Owner. The book handles this case with the patterns Mitosis and Scrum of Scrums.

Limits and pitfalls

"Cross-functional" is often taken to mean "everyone can do everything". The pattern does not say that: specialists remain necessary, and cross-training takes time, during which the team produces less.

There is nothing magic about the number five. The studies cited point the same way, but several of them concern short laboratory tasks, far removed from the work of a team over months.

Organizing by delivered features has a cost. When several teams touch the same parts of the product, technical consistency does not look after itself. That is what the cross-cutting groups are for.

The image of a small business within the business runs up against the reality of many organizations, where the budget, hiring and the right to put things into production remain elsewhere. The book then points to other patterns, among them Involve the Managers (see Protecting the Sprint from interruptions).

Finally, Conway's law is a practitioner's observation. Later work, such as that of Alan MacCormack, John Rusnak and Carliss Baldwin (2012) on software produced by different kinds of organization, supports it without making it a law in the scientific sense. None of these studies measures the effectiveness of Scrum itself (see Criticism and the state of the evidence).