There is a productivity valley between small teams (up to 5-8 people) and large teams (20+). In that valley you get less done than on either side, so it makes no sense to be there.
What this means is that organizations need to make a choice between maximizing what can be done with at most 5-8 people, or else making teams of 20+ people work together smoothly. And the sets of features that are good for either of those goals are frequently bad for the other goal.
> There is a productivity valley between small teams (up to 5-8 people) and large teams (20+).
Sorry, but I don't agree with that at all. As soon as you have more than one person working on the same part of your code, you incur some degree of overhead. I don't see why the numbers 8 or 20 are special. Are you really claiming that a competent development team of 18 people cannot do more than a competent development team of 8 people?
To co-ordinate teams of many developers, we divide projects into manageable chunks, each with a relatively small number of developers working on them. This requires good abstraction tools, so that developers can see how their contribution fits into the larger picture, can work with the code written by others without having to know it in intimate detail, and can combine all the components into a complete product. Again, I don't see how this picture differs whether you have 8 people or 20 people, unless you're following some sort of surgical team model where you really are trying to get all of the smaller team working on the same code but most of them aren't actually writing that code at all.
See page 229 in Software Estimation for references to research that a medium size project will be produced in the same number of calendar months by a team of 5-8 people or a team of 20-25 people. And it will take LONGER if your team is between those two sizes. Beyond that larger threshold, development also speeded up.
In this case a medium sized project was 10-100 thousand lines of code, and for all the team sizes looked at across all of the projects examined averaged 50-60 thousand lines. I would expect that the small team likely had less code duplication within their project, which would indicate that when measured by functionality, the small team had an even bigger advantage.
Note that this is calendar months to finish the project. If you measure in terms of dollars spent to finish, the most productive team size is 1.
And yes, this is with the larger teams using standard practices such as being divided into smaller, more focused groups. The reason is that the process of doing that requires completely changing how you work, and that results in a significant productivity impact. Once you take that hit you can scale, but you have to take that hit first.
I'm all for evidence-based debate, but as I don't have that particular book, could you please provide specific citations?
I am willing to accept that I am wrong if the evidence really says I am, but I remain deeply suspicious of these conclusions on the basis of the data you have provided so far. A typical 50-60 KLOC project is the sort of thing I would expect one or two decent developers to put together in less than a year. I don't know why even a team of 8 people would be working on a project that small under most circumstances, never mind a team of 20-25 people. Of course if you go into the low end of the tail then the communications overheads will dominate development time with that sort of team size, but that's hardly typical of a realistic project with a competent development team.
(I keep using qualifiers like "competent", because I don't think this level of performance requires exceptional developers and managers, but I am ruling out clueless management or developers who aren't good enough to function effectively in a team at all. Of course with such people your supervision and communication overheads go through the roof.)
Edit: Never mind. I found the relevant excerpt of the book you mentioned. You are making a completely unfounded generalisation, extrapolating from data taken in a very specific context, with no logical basis whatsoever. I stand by my previous posts.
There is a productivity valley between small teams (up to 5-8 people) and large teams (20+). In that valley you get less done than on either side, so it makes no sense to be there.
What this means is that organizations need to make a choice between maximizing what can be done with at most 5-8 people, or else making teams of 20+ people work together smoothly. And the sets of features that are good for either of those goals are frequently bad for the other goal.