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