The organization

Scaling up

When a product outgrows what a single team can deliver, several teams are needed, and new difficulties appear. A Scrum Book offers a series of patterns for growing step by step: splitting a team that has become too large, letting the teams coordinate, aligning their rhythms and giving management a place to influence priorities. The book begins with a warning: most organizations that want to "scale" would gain more by first improving the team they already have.

A team of eleven

A start-up publishes management software for school cafeterias. It began with five developers. Demand grows, and the company hires one person after another. Eighteen months later the team has eleven developers.

The daily meeting now lasts thirty-five minutes. Two groups have formed without anyone deciding it, one around menus and orders, the other around billing families. One morning Léa is surprised: "Who changed the allergen calculation? My tests are failing." Paul raises his hand: "That was me, on Tuesday. I didn't know you were using it." The organization chart shows one team, and daily life shows two.

A Scaling Sequence: do you really need to grow?

A Scrum Book (2019) describes Scrum as a set of patterns: each one sets out a recurring problem, the forces at play and a solution drawn from experience. The text entitled A Scaling Sequence introduces the patterns that follow and sets their order, without being a pattern itself.

Its first message is a warning. People generally want to grow in order to produce more, whereas the best way to achieve that is to remove impediments and improve the way of working. The authors accept only one legitimate case: the product has grown of its own accord to the point where demand exceeds the capacity of a team that already performs very well, meaning stable, steady and getting diminishing returns from its improvement efforts. Growing is not a way to make up for lost time: the book recalls Brooks's law (The Mythical Man-Month, 1975), "Adding manpower to a late software project makes it later."

Before adding a team, it therefore recommends helping the Product Owner (the person who orders the list of what needs to be built, the Product Backlog) to focus the team on what matters most, helping the Scrum Master (who supports the team in its practice of Scrum) to remove impediments, and strengthening the Developers' ability to deliver quality work. Without this, the organization multiplies its dysfunctions along with its teams.

The second message is that you grow Scrum with Scrum. All the teams work from a single Product Backlog, under the responsibility of a single Product Owner, with the same definition of finished work, and their autonomy remains a condition of success.

Mitosis: splitting a team that has grown too large

The Mitosis pattern (named after the division of a cell into two) carries one star: the authors see in it the core of a good solution, without ruling out that others exist.

The problem. A team needs to grow gradually, but it ends up becoming too large to remain effective.

The forces. A single team for a product is the simplest organization, because everyone knows how their work fits into the whole. Adding people one at a time spreads the cost of integrating them, but ends in a crowd. Hiring a second team in one go is expensive, because it takes months for newcomers to know the product. Finally, the book distinguishes the official team, the one on the organization chart, from the real team, the one formed by daily exchanges. When two real teams exist, pretending they are one makes no sense.

The solution. When the team has grown to the point of being ineffective, at around seven people, it splits into two small teams that each take with them the experience and culture of the original team. Each new team brings together all the trades needed and can work on every part of the product. Each has its own Scrum Master. The two keep the same Product Backlog, the same Product Owner and the same workplace.

According to a rule of thumb from the authors, two teams made up of the same people lose about 40% of velocity (the amount of work finished per Sprint, Scrum's fixed-length working period) to coordination. In our example, the eleven developers form a team of five and a team of six. They avoid following the existing split between menus and billing, so that each team remains able to work anywhere.

The 2020 Scrum Guide provides for the same move: "If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner." Two differences are worth noting. The Guide puts the usual size of a Scrum Team (the whole team) at ten people or fewer, and where the book describes one Scrum Team containing several "Development Teams", the Guide speaks of several Scrum Teams.

Coordinating several teams

Scrum of Scrums: the teams coordinate themselves

The problem in the Scrum of Scrums pattern (one star) is that teams each working on their own focus on their own concerns and lose sight of the shared goals.

The forces. The book rules out four tempting answers. Returning to hierarchical control adds delays. Cutting the product into independent pieces brings unforeseen dependencies to light, because optimizing each part does not optimize the whole. Merging everyone into one big team makes the cost of communication explode. Handing coordination to a manager equipped with an overall plan takes away the teams' autonomy and commitment. Conversely, autonomous teams without alignment each go off in their own direction.

The solution. The teams of Developers are given the right and the responsibility to collaborate in reaching the shared goals set by the Product Owner, and they choose for themselves how to coordinate. The usual means are simultaneous Sprints, a shared definition of finished work, start-of-Sprint and end-of-Sprint meetings held together, and a regular meeting between teams, possibly daily, after the Daily Scrums (each team's daily meetings). The book insists on one point: the teams do not wait for this meeting to talk to each other, and the true measure of the Scrum of Scrums is the spontaneous collaboration between them.

According to the book, the practice was first put in place at IDX Systems in 1996, where Jeff Sutherland headed engineering, and described in a publication in 2001. The Scrum Guide does not mention it.

Organizational Sprint Pulse: beating to the same rhythm

The problem in the Organizational Sprint Pulse pattern (no star, meaning one good solution among others according to the authors) is that the team and the rest of the organization are out of step, which produces waiting or interruptions.

The forces. Teams depend on finance, sales, support and suppliers, which often follow a monthly rhythm. If Sprints start and end on dates that do not line up, or if their lengths differ from one team to another, work waits. Imposing a common length, however, takes a little freedom away from each team.

The solution. The organization adopts a monthly rhythm, and the teams choose Sprints of one, two or four weeks that fit into it. According to the book, this common rhythm reduces unevenness and overburden, which Lean calls mura and muri (in French), and it allows the teams to hold their Sprint events together.

Value Areas: organizing teams by area of value

The Value Areas pattern (no star) concerns a product that serves increasingly varied audiences.

The problem. When one product has to serve several customer segments, a team cannot gain a deep understanding of each one fast enough.

The forces. Making teams bigger slows them down. Splitting the product into several products, each with its own Product Owner and list, leads each part to optimize itself at the expense of the whole and prevents doing the most valuable work first. Organizing teams by technical component lengthens lead times, because a feature useful to the customer nearly always cuts across several components.

The solution. The product is organized into Value Areas: parts of the product that meet the needs of a customer segment but have no existence outside the product. Each group of teams only needs to know certain segments well, and each team still delivers items that are useful to the customer. There is still only one Product Backlog and one Product Owner, helped by people who each specialize in one area. The book gives the example of an energy supplier organized into three areas, signing up new customers, billing and support, each entrusted to four to six teams.

The authors present this organization as temporary: in time, the teams should again become able to work in every area. If the product drifts too far from its original Vision, the sequence ends with the Value Stream Fork pattern, which splits it into several products and which the article on the release plan presents.

MetaScrum: a place for management

The problem in the MetaScrum pattern (no star) is that the management inherited from the old organization keeps giving instructions about product content, which blurs the question of who decides. Managers change the list or step in with the Developers in the middle of a Sprint.

The forces. Management's concerns are legitimate, whether they involve competition, contracts or budgets, and they must be visible. Yet mixing them with market demands in the same meetings creates confusion, and products need to be aligned with one another.

The solution. The company creates a regular forum, the MetaScrum, which brings together the Product Owners and senior management, chief executive included, to align the whole company behind the Product Backlogs. A Product Owner of the MetaScrum facilitates it. Teams use it to ask for the support or resources they lack, and management uses it to argue for the changes it wants. At the end of the meeting, the Product Backlogs are closed to management intervention until the next MetaScrum, and in the meantime the teams work without interference.

The book makes clear that the MetaScrum is not a tool for management to steer the products, since each Product Owner keeps authority over their own. It acknowledges that one much-publicized MetaScrum was used to impose management's will. The first published description, by Jeff Sutherland in 2005, concerns the company PatientKeeper, where the arrangement had been running since 2003. The Scrum Guide does not mention it.

Limits and pitfalls

The first pitfall is the one the book itself denounces: adding teams to rescue a late product or a team that works badly. Coordination is then added to the existing difficulties.

Each pattern has its own drift. The Scrum of Scrums becomes a status meeting in front of a coordinator. The split follows specialties and creates teams that depend on one another for the smallest feature. Temporary Value Areas become permanent and turn into walls. The MetaScrum turns into a steering committee.

The figures put forward, such as the 40% loss of velocity, are rules of thumb given without published measurement. The examples come mostly from companies where the authors worked, and they count as testimony. Other frameworks answer the same problems differently, notably LeSS, Nexus, Scrum@Scale and SAFe, which the article Agility at scale in the Agility corpus (in French) presents. The article Criticism and the state of the evidence returns to what is known about their effectiveness.