It seems like ever since the dawn of software development, humans have struggled with the question of team size. What team size is most productive? Most economical? When does adding more people to a project cease to make sense? So it comes as no surprise that one of the most popular articles on our website is a study Doug Putnam did in 1997 on team size, Team Size Can Be the Key to a Successful Project. The article leveraged data from 491 completed projects in the QSM Database to determine what is the optimal team size - "optimal" being most likely to achieve the highest productivity, the shortest schedule, and the cheapest cost with the least amount of variation in the final outcome. The study determined that for medium-sized (35,000 to 95,000 new or modified source lines of code) systems, smaller teams of 3-7 people were optimal. This article continues to be referenced today, especially by the agile community.
The topic of team size reappeared again in Don's Beckett study of Best in Class and Worst in Class projects for the 2006 QSM Software Almanac. To identify top and bottom performers, he ran regression fits for effort and schedule vs. project size through a sample of nearly 600 medium and high confidence IT projects completed between 2001 and 2004. On average, Best in Class projects delivered 5 times faster and used 15 times less effort than Worst in Class projects. What made the Best in Class projects perform so much better? Best in Class projects used smaller teams (over 4 times smaller, on average) than the worst performers.
In 2012, Kate Armel did a follow-up series of blog posts to see if Doug Putnam's original research still held true. She used data from nearly 1060 medium and high confidence IT projects completed between 2005 and 2011. She divided the projects into two bins: one with 4 or fewer FTE staff (median 2.1 FTEs) and the other with 5 or more FTE staff (median 8.5 FTEs). After comparing effort, schedule, and quality in each of these bins, the results were clear: though the larger teams might achieve meager schedule compression, it came at the (large) cost of quality and effort. On small projects, the large teams were 3 times more costly than the small teams, and delivered 2 times as many defects. On large projects, large teams were a whopping 4 times more expensive than the small ones and delivered 3 times as many defects.
So do these results still hold true today? This past December, Doug Putnam revisited his original research on team size using a fresh set of data, this time with the question: how much does development methodology matter? He looked at 390 applications of the same size featuring both 10,000 and 20,000 lines of newly developed code, with a significant portion using agile methods and tools. One sample used an average of less than 4 people and the other had 9 people or more. While the additional staff reduced the schedule by approximately 30%, the project cost actually increased by 350%. The additional staff also created 500% more defects that had to be fixed during testing. The study concluded that staffing decisions have more of an impact on project success than any development methodology.
QSM will continue to revisit team size studies each time our database is refreshed with new data, but as of right now, our research shows that smaller teams tend to be more productive, cost effective, and generate less defects. While larger teams sometimes achieve a modest amount of schedule compression, it's often at a great price. If you'd like to learn more about staffing smarter, check out the following resources linked below: