Over a million developers have joined DZone.

What Is the Optimal Team Size?

DZone's Guide to

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.

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

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, = 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.

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

agile ,team size ,agile teams ,work culture

Published at DZone with permission of John Cook, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}