Is Five the Optimal Team Size?

Some projects are just too big for even the best 7 people on the planet to do.

At that point, when you need to have more people, and multiple teams, this kind of guidance isn't particularly helpful.

There also isn't any discussion about the team makeup - broken down by skill (dev team, test team, dba team, etc) or cross-functional (each team with members from all disciplines - dev, test, db, etc).

There's also the issue of organizational dynamics to be taken into account, legacy to be maintained, etc that will impact the above. In green-field projects cross-functional teams tend to work best and minimize risk, yet brown-field in matrixed organization can bring constraints forcing skill-based teams.

As Conway's law states, the structure of the system will reflect the structure of the organization which built it. The corollary of that law is that to effectively change the architecture of a system, the organizational structure must be changed as well. This requires people to act as change agents - risky business for people inside certain organizations; external consultants often have better success not being perceived as a political threat.

As an architectural consultant I've seen the full gamut - there really is no silver bullet, not even 5 plus-minus 2.

Udi Dahan - The Software Simplist

I would agree with you Udi, you would need multiple teams for larger projects. I think Jurgen's proposal is to have a huge team split up into smaller teams of 5 people each.

This gets us to the problem of allocating the specialized functions like DBA etc that you talk about. There are several approaches that work for generalized-specialized functions. The one that we use is that the DBAs do not belong to any team but their services are used by multiple Scrum teams as and when required.
For the more traditional roles there is a suggested mapping defined here.

Again, there isn't a silver bullet. It would depend a lot on the people, environment both internal and external to the organization etc etc, to see what works for them.

I would agree with you Udi, you would need multiple teams for larger projects. I think Jurgen's proposal is to have a huge team split up into smaller teams of 5 people each.

I think one of the underlying issues with the post is that it does not address what is optimal. Time to market is often a key factor - and more important than development cost. The cost of development might be relatively insignficant compared to the additional revenue or cost saving of the project. So running a team that in itself is less efficient might be irrelevant in the larger measure of cost/benefit of the project.

Imagine a project which saves a company $100,000 per month in operational costs. Delivering it 6 months earlier saves the company $600,000. Lets say developers cost this company $1000 per day. That means the project can deliver exactly the same result at 500 extra man days effort (that's additional, inefficient, effort) if they bring it in 6 months earlier and still be ahead of the game.

So although smaller teams within themselves might be more efficient - and hence companies ought to prefer them - they might not deliver results as quickly and the benefits of early delivery often outweigh the additional cost of doing so.

Hi,
I believe Jurgen's last name is spellt 'Appelo'.
cheers,
nico

I agree with the main discussion in the article about not writing reusable code until there is a need. But there is an option of having(managing) reusable code across project(only when there is a probability of code redundency or functional redundency) by having test coverage. So whenever someone in the project uses code used as a utility, he has to write a test for that usage so that if someone changes the reused code(utility), then the test fails indicating that there is a break of a functionality that is using the utility.

sorry this belongs to some other discussion.

"The more team members you have, the more communication channels you will have, and this thing goes exponentially. If you have 3 team members, then you will have 4 communication channels, if you have 4 then you have 9. I think the formula is m-1^2."

Can someone explain what "one communication channel" is here? I first thought it was the number of possible 1-to-1 communications possible in the team. That would equal the number of possible pairs in the team, which is not growing exponentially. A team of 3 has 3 channels, a team of 4 has 6 channels and so on, using the binomial coefficient.

Can some one clarify please.

Cheers,
Matt

My understanding of the growth of communications channels is it is the number of POSSIBLE communications links between nodes (people on the team).

2 nodes (people)A & B have one possible communication link: A-B
3 nodes A B C have 3 links: A-B B-C A-C
4 nodes A B C D have 6 links: A-B A-C A-D B-D B-C C-D
etc

I hope this helps ...

Shane

Matt,

You can safely ignore the math. Like statistics, it is used to prove a foregone conclusion. People can perform many-to-many communication: overheard conversations, meetings, all that.

hmm nice catch ;) but I guess inter team communication would be limited to something like a Scrum of Scrums which might not be that bad.

What are your recommendations and observations on the teams on which you have worked?

Good to see some updated statistics. But the really interesting question is, "Why do we persist with these large teams". Nothing in this article was a surprise to me - there have been similar papers and the results of team size have been well documented since I started in the industry - on System 360 with PL/I in 1968! Brook's law - adding more people to a late software project makes it later" was published in 1974, and demonstrations such as Harlan Mill's "Chief Programmer Team" in the early 70's should have nailed it. Yet 30 or 40 years later we continue to employ large teams and Waterfall methodology, in spite of the massive evidence that this is the worst way to develop software. Why? Are managers especially slow learners? Or is the reason more subtle.

Robert Barnes

Thanks Nicolas, corrected the typo.

I think one of the underlying issues with the post is that it does not address what is optimal.

Jurgen cautioned that instead of going with a recommendation on team size, the teams should first try to self organize and gradually arrive at an optimal team size.

It depends on the team structures I described above.

Skill based teams require huge amounts of communication as the software components they work on are necessarily tightly coupled (UI, BL, DAL, DB).

Cross-functional teams working on autonomous business services (SOA) require much (MUCH) less inter-team communication.

For larger projects, I would recommend against self-organization unless the team has already worked together enough, and on those kinds of projects, to know what will and won't work.

I've seen teams "self organize" in ways unsuitable to the project they're working on. All sorts of problems start popping up but the team doesn't necessarily have the experience (or perspective) to attribute those problems to their self-organization, so persists - and often fails as a result.

I would strongly recommend getting somebody in with experience in the project scale/style to avoid these kinds of costly self-organizing mistakes. As attributed above in Conway's law, both team structure/methodology and software architecture need to be put into alignment - something ignored by many "agile consultants".

Udi,

yes, I agree that the actual maths can be ignored.

When I see a formula presented I want to understand it and see how I can make use of it. And there is a difference to claim that communication grows exponentially or by its dimensions.

In an ideal world where this team would only be working on one project at a time, I would agree that a team size of 5 (not including the scrummaster and PO) is a good size. We have a small team of 4 developers and it's great for dedicated projects and focused work but throw in supporting the existing application and it gets very difficult very quickly. It can be extremely difficult to get an actual work done without constant sprint interruptions when your team can't focus on the project.