What Is the Optimal Team Size?
What Is the Optimal Team Size?
John Cook explains why it is important for you to consider your team's ability to work both in parallel and in communication costs.
Join the DZone community and get the full member experience.Join For Free
You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang.
Kevlin Henney’s keynote at GOTO Copenhagen this year discussed how project time varies as a function of the number of people on the project. The most naive assumption is that the time is inversely proportional to the number of people. That is:
t = W/n.
...where t is the calendar time to completion, W is a measure of how much work is to be done, and n is the number of people. This assumes that everything on the project can be done in parallel. Nobody waits for anybody else.
The next refinement is to take into account the proportion of work that can be done in parallel. Call this p. Then we have:
t = W[1 – p(n-1)/n].
If everything can be done in parallel, p = 1 and t = W/t as before. But if nothing can be done in parallel, p = 0, and so t = W. In other words, the total time is the same whether one person is on the project or more. This is essentially Amdahl’s law.
With the equation above, adding people never slows things down. And if p > 0, every addition person helps at least a little bit.
Next, we add a term to account for communication cost. Assume that communication costs are proportional to the number of communication paths, n(n – 1)/2. Call the proportionality constant k. Now we have:
t = W[1 – p(n-1)/n + kn(n-1)/2].
If k is small but positive, then at first adding more people causes a project to complete sooner. But beyond some optimal team size, adding more people causes the project to take longer.
Of course, none of this is exact. Project time estimation doesn’t follow any simple formula. Think of these equations more as rough guides or metaphors. It’s certainly true that beyond a certain size, adding more people to a project can slow the project down. Kevlin gave examples of projects that were put back on track by reducing the number of people working on them.
My quibble with the equation above is that I don’t think the cost of more people is primarily communication. Communication paths in a real project are not the simple trees of org charts, but neither are they complete graphs. And if the problem were simply communication, then improved communication would mitigate the cost of adding people to a project, though I imagine it hardly does.
I wrote about a similar theme in the blog post, Maybe you only need it because you have it. Here’s the conclusion of that post:
Suppose a useless project adds staff. These staff need to be managed, so they hire a manager. Then they hire people for IT, accounting, marketing, etc. Eventually they have their own building. This building needs security, maintenance, and housekeeping. No one questions the need for the security guard, but the guard would not have been necessary without the original useless project.
When something seems absolutely necessary, maybe it’s only necessary because of something else that isn’t necessary.
I think that the cost of adding people to a project has more to do with Parkinson’s Law, which says that people make work for each other. The aphorism form of Parkinson’s Law says that work expands to the time allowed, but the eponymous book explains why work expands, and it is in part because people make extra work for each other.
Published at DZone with permission of John Cook , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.