People have been trying to answer this question for ages, and there seems to be little consensus. At the SPA 2009 conference this week I attended a very inspiring session by Joseph Pelrine, who told his audience that the sizes 5, 15 and 150 have been mentioned in (or can be derived from) scientific research, as being optimal sizes for social groups.

The agile movement, with Scrum as the leading method at this time, often mentions a preferred team size of 7 plus or minus 2 (which is just a software developer’s way of saying between 5 and 9).

And recently I read about the results of interesting new research into optimal group size for decision making, which revealed that anything below 20 can work well, except 8. That’s because eight people frequently find themselves in a deadlock situation on their decisions.

Considering all this we can easily see that there’s only one optimal team size that satisfies all research.

Five

Five is one of the three preferred sizes mentioned by Joseph Pelrine. Five also falls within the preferred range of sizes for agile teams. And five is less than 20, yet unequal to eight.

Five is also my lucky number. It is my default answer to any question that I am unable to answer without more information. Five is my personal 42.

You see, I really can’t tell you what the optimal team size is! Here’s why…

In his SPA 2009 session Joseph Pelrine wrote Kurt Lewin’s equation on the whiteboard:

B = f(P,E)

It means: a person’s behavior is a function of the person and his or her environment. My own version of this equation would look like this:

C = f'(P,E)

It means: a person’s communication is a function of his or her personality and the possibilities that the environment allows for. And when we’re talking about a whole group of people, it might look like this:

S = f’’({P},E)

Meaning: the optimal size of a team (being a communication issue) is a function of the set of people’s personalities and their environment.

The value of S can be anything! The precise optimum for team size depends on the people and their environment. Statistically it is more likely to be five than eight (though eight is possible). And the optimum is probably more likely to be between 5 and 9 (for software developers: 7 plus or minus 2) than between 10 and 20 (for software developers: 15 plus or minus 5).

So, what can we learn from this?

My suggestion: when you need to structure a big project, don’t impose a “preferred” team size on people just because it is written in a book. Try to allow self-organization to do its job and let the people (within their real environment) figure out what their optimum is. Do they want to cut a team of seven into two teams of three and four? Sure, why not? Are they merging two teams into one big team of fifteen? Fine, let them see if that works. And be aware that they might want to reconsider things when the environment (or the set of personalities in the team) changes again.

One word of warning: you may want to question their decision when they come up with a team size of eight (plus or minus zero).