Scaling Teams by Ron Lichty

Ask any scrum coach about ideal team size and you’ll likely get the same answer: 7 plus or minus 2. That is, 5 to 9 team members doing the actual planning and work of the sprint: developers, testers, sometimes designer or writer or some other role in the 7 +/- 2, maximum-9-sized team (actually 11 with the scrum master and product owner).

So what do we do when we grow from maximum-9 to a 10th team member?

Splitting into two (or three!) teams seems fractious, siloing, so why do we want to cap teams at nine? Why would we split them?

First, let’s recognize that suggesting that the ideal team size is “7 +/- 2” is just plain wrong. Even the smallest of those is too many for “ideal.” By a lot.

The ideal team is much smaller. Software development is a team sport. Team sports are gated by collaboration and communication (the daily scrum: gee, a team sport, maybe we should all talk with each other once a day, huh?). So given communication is gating, what’s the ideal team size?

One. By that definition 1 person is the ideal team. When the team is a single person, all the communication is internal to a single brain - neuron-to-neuron.

But not much software these days gets built by teams of one! In fact, you can argue that one is not a team. My coauthor Mickey Mantle observes, from his dozens of years managing software development, that the number of programmers on an ideal team is 3-4.  “Assuming the teams are competent, a small team will usually outperform a larger team, hands down, and by a significant amount,” he notes. And former Medium VP Engineering Daniel Pupius, now co-founder & CEO of Range, protests that for team sports, diversity of perspectives is as vital as communication. “A sole genius isn't going to solve problems in the way a group can.” But to reduce the noise and friction while driving toward lossless communication, Daniel, like Mickey, would opt for teams of just 3 if 3 were enough to solve the problem at hand.

So agile’s “7 +/- 2” is a maximum “ideal” team size.

Where’d maximum-9 come from? Team theory. Again, team sports are gated by collaboration and communication, so think about the number of lines of communication required for various-sized teams: two people require only one line of communication; three people require three lines of communication; four people, six lines of communication; five people, ten lines of communication… Lines of communication are triangular. Somewhere around 8 or 9 or 10 people, and lines of communication have exceeded any and all likelihood that necessary communication will take place.

Mickey observes, “Rarely have I seen productive cross functional teams that number more than a dozen people.”

Daniel notes that his experience is more aligned “with 3 to 7, or 5 +/- 2 as ideal team size. And I think there are papers that suggest group dynamics shift at 8 people.”

So what do we do when we grow beyond our “maximum 7” or “maximum 8” or “maximum 9” team-size boundary – when we add one more team member?

There are several things that can be done:

1.    Keep the team intact

2.    Split the team

3.    Cell division

4.    Hybrid split

1.  Keep the team intact

First recognize that the “maximum of 9” is really just a guideline – it’s not a law!

In certain cases it may make more sense to simply add an additional team member. When this is done consciously, and recognizing the increased communication burden that an additional team member adds, you can take steps to make communication as effective as possible.

This may not be the best solution, but it is one to consider.

2.  Split the Team

How do we split into two (or three) teams?

There’s an (unfortunate) tendency to split by components. It’s a tendency because it seems to make sense to put like-minded, like-tooled, common-best-practices people together, and because it makes for a management model: We can have a team of database developers managed by a former database developer; a team of front-end developers managed by a former front-end developer; a team of business logic developers managed by a former business logic developer. In that way, each of those teams gets a manager, mentor and coach who understands them.

But our goal is not to deliver components. We were (almost every single one of us) hired to deliver customer functionality that delights users. Component groups cannot deliver features or epics or stories without multiple component teams working together to do so. The lines of communication within component teams are optimized for sharing best practices within the specialty; but the teams end up having fundamental dependencies on each other. The communications overhead - the high bandwidth communication required to deliver delight to customers - is between teams. Expensive. Ouch.

The most effective scaling models I’ve seen leverage cross-functional teams. Each cross-functional team has all the skillsets, from interface layer to business logic to data, all on the same team, to deliver customer functionality that delights users. While same-skilled folks are scattered across cross-functional teams, we still need managers who understand and can mentor and coach them, so we assign managers not to teams but to same-skilled folks.

I know several models that leaders and teams have found workable. All typically divide developers into cross-functional teams based on interface or functionality - most easily by how the interface splits functionality to present it to users.

Henrik Kniberg: Splitting teams based on how the interface exposes functionality.

Henrik Kniberg draws a picture of dividing up Spotify’s interface in just this way in his paper on scaling at Spotify.

Henrik Kniberg: Squads and Chapters

Notice in his organizational drawing that teams (which he calls squads) are vertical and don’t have managers; same-skilled folks (whom he organizes horizontally into “chapters” that span squads), on the other hand, are led by a same-skilled manager. So database developers are each assigned to teams, but all the database developers are also members of one of those chapters, and formally report to a database manager for mentoring, HR, best practices sharing, and assignment purposes.

3.  Cell Division

One approach to split a growing team is what my former Razorfish colleague Steve Gray calls cell division; as he describes the typical scenario, when a team has exceeded its effective size, a smaller area of functionality is identified that a smaller part of the team can be spawned off to address.

Former Medium VP Engineering Daniel Pupius notes, “I do feel the 9-12 person range is a really awkward size for an engineering team. I've had success with the "cell division" model, where instead of creating even splits at each point in time you peel off more stable islands, while a larger core group deals with a larger and less-defined surface area. In Medium's case it was a small team peeling off to focus on the needs of the professional publisher. That small team eventually grew to be 25 people and went through its own sequence of cell-division.

4.  Hybrid Split

When I was interim VP Engineering for a Portland company last fall, I inherited one of those larger teams and we invented a “team/subteams” hybrid model that both kept the larger team intact and split it into smaller ones. The team numbered half again more than the ideal max. Product management had identified three workstreams of customer functionality that needed addressing. The team divided into three sub-teams, each of which was (mostly) cross-functional and could deliver the three feature areas.

But it wasn’t clear that the three feature areas would be long-running streams of features that would support long-running, stable teams. Not only was stability at the larger team level, still, but team members were all working within a pretty monolithic code base. And large as it was, there was good sharing in a highly functional standup that the larger team held each morning.

So we kept the large-team standup for the sharing phase (the standup’s three questions, and identifying resolution discussions that needed to occur, particularly cross-subteam ones; this phase of the standup took the larger team of 15-18 typically 11-12 minutes). It was followed immediately by the (re)planning phase of the standup: a few minutes of (re)planning by sub-teams, each in front of its own physical card wall, in which each small team viewed its own backlog and discussed how it was doing on its sprint plan and who needed help, and moved cards across its board. The approach maintained the camaraderie and transparency of the larger team, while accomplishing (re)planning work in smaller teams.

The Take-Away

Given software development is a team sport, and team sports are gated by communication, we should all be constantly observing how our teams are communicating, and we should expect that we’ll need to evolve our team structures as we add (or subtract) people.

Have you seen effective models for splitting teams other than those I called out?

The models I’ve called out subdivide into cross-functional teams that take on lifetime ownership of functions users want to accomplish. By so doing, we give teams end-to-end ability to deliver those functions and avoid dependencies, handoffs and high-bandwidth communication overhead that is characteristic of dividing into component teams.

Regardless of approach, remember that it is communication that prevents siloing. Keeping the larger team intact while breaking out sub-teams - the hybrid model - is one mechanism that worked for one team. It will likely work for them for a while, until they grow their team too large for that model, too. At that point keeping communication flowing becomes a challenge both to product management (translating vision to features to stories) and to engineering management (translating customer wishes to design approach and architecture). Daniel Pupius notes, “The next super awkward phase hits around 30 persons.”

(Many thanks to Daniel Pupius, Rich Mironov, Steve Gray and Mickey Mantle for their insights and thoughts on this stuff!)