Friday, June 29, 2018

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!)


At 1:24 PM, June 29, 2018, Blogger Ron Quartel said...

Hi Ron. Yes I have seen another model for team splitting. Letting teams self-forming around the work using open space (FAST Agile).

Great article!

At 10:10 AM, July 07, 2018, Blogger Ron Lichty said...

Ron Quartel, I'm fascinated by FAST-Agile's short cycles of teams forming around short-lasting value-delivery opportunities. It seems to me that teams that last just two days are the promiscuous teaming analog to promiscuous pairing? But not really another model for team splitting but rather another model for agile that eliminates the need for team-splitting entirely?

At 10:17 AM, July 07, 2018, Blogger Ron Lichty said...

Jay Bazuzi on the AgileSEA Slack channel notes a rule of thumb from Woody Zull that thoughtfully cautions not only against too-large but also too-small teams:

Woody's rule is "If the team gets blocked for more than 2 minutes waiting for an answer to a question, the team is too small. If someone in the team is not learning or contributing, the team is too big."

At 10:24 AM, July 07, 2018, Blogger Ron Lichty said...

Ron Quartel observes, on the AgileSEA Slack channel, that teams that always pair program may be able to grow larger: that a team of 13 that pairs "would be the same as 6-7 channels of communication in scrum with solo devs". I've heard that observation from other XP practitioners. Though Ron adds that many XPers would say that 13 is too big even with pairing. (Which may reflect the rule of thumb that most of us go by, to adapt agile uniquely to every team and every situation based on what works!)

At 7:51 PM, July 23, 2018, Blogger Ron Lichty said...

Blue Cedar Networks VP Eng Zach Sherry notes, "I would argue that 5 is the ABSOLUTE limit for engineers. (excluding product/QE); further I would say that 4 engineers, 1 quality engineer, and a product function is optimal as you can pair up engineers and it's enough to keep the quality engineer loaded. The minimum # of engineers is 2: As you said, you do not have a team with 1. The issue with the split I've found is that the team must feel the pain and force it. They will be open to the separation of function and communication when they see that they don't need to be involved in the details of other team members’ functions; keeping an eye on this is key.

At 6:23 AM, September 25, 2018, Blogger liam Ethan said...

Wonderful illustrated information. I thank you about that. No doubt it will be very useful for my future projects. Would like to see some other posts on the same subject! Software Engineering

At 11:31 PM, November 01, 2018, Blogger Ron Lichty said...

ManagedByQ CTO Phil Sarin espouses three person teams in his blog post at:

At 3:19 AM, July 03, 2019, Blogger SRDV Technologies | Web Development | Mobile App Development said...

what is fantastic post? this is so chock full of useful information I cannot wait to dig deep and start utilizing the resource give me.your exuberance is refreshing.
Software Development

At 2:38 AM, July 23, 2019, Blogger gopipatel said...

Amazing Article, Thanks for sharing!
10 Scrum Developer Best

At 4:14 PM, September 05, 2019, Blogger Michael James (mj) said...

I think nearly everyone agrees we prefer feature teams over component teams for a variety of reasons. But the fatal flaw of the Henrik Kniberg approach is that giving each team a different Product Owner actually reduces big-picture agility.

The main problem I've been seeing in Scrum adoptions in large organizations is too many people called "Product Owner" I tried to illustrate this problem here:

At 5:08 PM, September 05, 2019, Blogger Ron Lichty said...

@Michael, first, I like the comic book.

"I think nearly everyone agrees we prefer feature teams over component teams for a variety of reasons." Actually, your comic book suggests not (slides 8, 9 and 10). And I don't mean to call you out, specifically. I too frequently find teams that divide that way. Even teams that agree that feature teams would be preferable sometimes nonetheless divide into component teams.

I think you've nailed that scaling is hard. Components or features, we can get silo'd leaf nodes (teams). And if silo'd enough, we can see some teams working on $8-profit solutions when there aren't enough people working on the $8000-profit solutions.

A single backlog and a single product owner is certainly one solution. In fact, I kept thinking, as I kept reading, "Wait. Why is Michael James inventing something new? Larman and Vodde already came up with LeSS?" (Good surprise, at the end, discovering that in fact you were writing about LeSS! :-)

On the other hand, there is (imo) entirely too little quality product management being done. If you were to go talk to Marty Cagan, he would agree those product owners who are silo'd and have become TOOs (team output owners, which terminology I rather like) aren't doing product management (see But to expect that a single product owner can adequately deliver product management for scores of developers seems to me pretty developer-centric thinking.

Of course, all of the agile approaches are fundamentally developer-centric thinking. (And while I've managed product management teams and done some product management (in addition to managing testers and project managers in the day and UX designers and pretty much anyone and everyone on product teams), I fundamentally identify more as a developer than anything.)

Which is to say, I'm a fan of LeSS. Where it works. And a fan of Scrum of Scrums. Where it works. And a fan of FAST-Agile. Where it has worked. And a fan of Kniberg's. For it working for them at Spotify.

I'm fundamentally a fan of agile (and the Agile Manifesto) for giving us the values and principles to pick and choose solutions that work. The point is not to do agile. The point is to be effective. Thank you for sharing some of the effective agile solutions you've seen - both via the graphic story-telling and sharing it here! Thank you!


Post a Comment

<< Home