Team Size

Team Size

Getting Staffing Right is the Key to Software Development Nirvana

This post was originally published on Linkedin. Join the QSM Linkedin Group and Company Page to stay up-to-date with more content like this.

Enterprise IT teams have been searching for years for the Holy Grail of software development: the greatest possible efficiency, at the least possible cost, without sacrificing quality.

This endless search has taken many forms over the years. Twenty years ago, development teams turned to waterfall methodologies as a saving grace. Soon after, waterfall begat object-oriented incremental or spiral, Rational Unified Development (RUP) practices.

Today, it’s agile development’s turn in the spotlight. C-suite executives are investing huge sums of money to develop their organizations’ agile methodologies. They’re also committing significant resources to train employees to work within agile frameworks.

Yet many projects are still failing, clients remain unsatisfied, and IT departments are often unable to meet scheduling deadlines. Why?

It’s the staff, not the method.

Whenever a project falls behind schedule, the natural inclination is to add more staff. There’s a belief that doing so will accelerate development and, ultimately, help the team hit their deadlines.

The "Typical Software Project" Over Time

What does a typical software project in the QSM historical database look like, and how has “what’s typical” changed over time? To find out, we segmented our IT sample by decade and looked at the average schedule, effort, team size, new and modified code delivered, productivity, language, and target industry for each 10 year time period.

The QSM benchmark database represents:

  • 8,000+ Business projects completed and put into production since 1980.
  • Over 600 million total source lines of code (SLOC).
  • 2.6 million total function points.
  • Over 100 million person hours of effort.
  • 600+ programming languages.

During the 1980s, the typical software project in our database delivered 154% more new and modified code, took 52% longer, and used 58% more effort than today’s projects.   The table below captures these changes:

Blog Post Categories 
Team Size Languages QSM Database Effort

The Laws of Software Staffing

Frederick Brooks famously said that adding staff to a late project only makes it later.  The reasons are readily apparent.  The project is already experiencing difficulties, most of which were not caused by understaffing.  The usual culprit is an unreasonable schedule constraint; but starting work before the requirements were well defined, poor change control, or weak configuration management could also be the villains (or at least play a contributing role).  None of these root causes is staff related and adding staff does not fix them: it merely adds more bodies to the confusion.

But, how do we determine the most appropriate staffing profile for a software project?  Parametric estimation models suggest a way: these models have determined that there is a relationship between the functionality that a project delivers (called size in the software estimation vernacular) and staff.  Fitting a regression line through hundreds or thousands of software projects determines an average and deviation from that average. The regression is a reflection of how software projects have performed.  This is what has worked.  This capability is built into estimation software like SLIM-Estimate.  A wise approach is to take the average as a starting point, then adjust the modeling parameters that would increase or lower the staff.  A word of caution here: if you find that your adjustments cause staff, effort, or duration to be more than 1 standard deviation above or below average, you are probably being either too optimistic or pessimistic.  Don’t do it! 

Blog Post Categories 
Team Size

Smaller Project Teams Are More Productive

It's no secret we're advocates of smaller teams, but it's always nice when others agree. Baseline's Tony Kontzer leveraged some of our most recent data for an informative slideshow about team size.

At one time or another, almost all information technology professionals have heard cries for more resources. They may even have been the one asking for help. "If only there were more people available for this project," they've said, "then maybe it would get done on time." Well, it turns out that more staffing is not the equivalent of optimal staffing. In fact, smaller project teams are more productive and can complete projects cheaper and faster than larger ones, according to a recent study from software life cycle consultancy Quantitative Software Management. That should be good news for IT departments that have seen their ranks depleted in recent years.

To see more results from QSM's recent study, read Don Beckett's post on the correlation between staffing and schedule.

Blog Post Categories 
Team Size QSM News

Staff That Project!

I should be the last one to complain about overstaffed projects; I may owe my career to one.  My first job in information technology (IT) was with a mortgage company that was a textbook example of bad practices.  Annual personnel turnover was 90% and after six months on the job, I was the person on the IT staff with the most seniority.  After a year, I knew it was time to go.  I applied for a job with a large systems integrator that was hiring furiously.  I was drug free, did not have a criminal record, and knew COBOL, so I was a perfect match.  The project to which I was assigned had planned to ramp up to a peak staff of 25 and last about 8 months.  I was team member number 60 of the 80 it eventually grew into by the time it completed (in 18 months).  I stayed with that company for a number of years and have no complaints about the wide range of experiences that I had and skills I gained. 

What is the best way to determine how much staff a software project should have?  QSM has conducted a productivity study on projects sized in Function Points that suggests a way.  A large sample of projects (over 2,000) was split into size bins.  Within each bin the projects were divided into quartiles based on their staffing. The average and median productivity (Function Points per Person Month) were determined for each quartile.  The following table compares productivity and staffing levels for the smallest and largest staffing quartiles.

Productivity Rates

Blog Post Categories 
Team Size

Part III: Finding the Optimal Team Size for Your Project

In part one of our team size series, we looked at Best and Worst in Class software projects and found that using small teams is a best practice for top performing projects. Part two looked at differences in cost and quality between small and large team projects and found that small teams use dramatically less effort and create fewer defects.  But simply knowing that small teams perform better doesn’t tell us how small a team to use. Most software metrics scale with project size, and team size is no exception. Management priorities must also be taken into account. Small projects can realize some schedule compression by using slightly larger teams but for larger projects, using too many people drives up cost but does little to reduce time to market:

Larger teams create more defects, which in turn beget additional rework… These unplanned find/fix/retest cycles take additional time, drive up cost, and cancel out any schedule compression achieved by larger teams earlier in the lifecycle.

In a study conducted in the spring of 2011, QSM Consultant Don Beckett designed a study that takes both system size and management priorities into account. He divided 1920 IT projects into four size quartiles. Using median effort productivity (SLOC/PM) and schedule productivity (SLOC/Month) values for each size bin, he then isolated top performing projects for schedule, effort, and balanced performance (better than average for effort and schedule):

Effort vs. Schedule

Blog Post Categories 
Team Size

Part II: Small Teams Deliver Lower Cost, Higher Quality

This is the second post in a three part investigation of how team size affects project performance, cost, quality, and productivity. Part one looked at cost and schedule performance for Best in Class and Worst in Class IT projects. For this study, Best in Class projects were those that delivered more than one standard deviation faster, but used more than one standard deviation less effort than the industry average for projects of the same size. A key characteristic of these top performing projects was the use of small teams: median team size for best in class projects was 4 FTEs (full time equivalent) people versus 17 FTEs for the worst performers.

What is the relationship between team size and management metrics like cost and defects? To find out, I recently looked at 1060 medium and high confidence IT projects completed between 2005 and 2011. These projects were drawn from the QSM database of over 10,000 completed software projects. The projects were divided into two staffing bins:

  • Small team projects (4 or fewer FTE staff)
  • Large team projects (5 or more FTE staff)

Average Staff vs. System Size

These size bins bracket the median team size of 4.6 for the overall sample, producing roughly equal groups of projects that cover the same size range. Our best/worst in class study found a 4 to 1 team size ratio between the best and worst performers. 

Blog Post Categories 
Team Size

Top Performing Projects Use Small Teams

Last week, Carl Erickson of Atomic Spin referenced a study performed by Doug Putnam several years ago:

A study done by consultancy QSM in 2005 seems to indicate that smaller teams are more efficient than larger teams. Not just a little more efficient, but dramatically more efficient. QSM maintains a database of 4000+ projects. For this study they looked at 564 information systems projects done since 2002. (The author of the study claims their data for real-time embedded systems projects showed similar results.) They divided the data into “small” teams (less than 5 people) and “large” teams (greater than 20 people).

To complete projects of 100,000 equivalent source lines of code (a measure of the size of the project) they found the large teams took 8.92 months, and the small teams took 9.12 months. In other words, the large teams just barely (by a week or so) beat the small teams in finishing the project!

Since then, QSM has performed several studies investigating the relationship between team size and metrics like project scope, productivity, effort/cost, and reliability. The results have been surprisingly consistent regardless of application domain, technology, or year group.  I’ll be reviewing what we found in a series of posts.

Blog Post Categories 
Team Size

Technology Can Only Do So Much

It’s hard to believe it’s been 36 years since an IBM manager named Fred Brooks came out with his seminal insights about software development, the most famous of which ("adding more people to a late software project makes it later") came to be known as Brooks’ Law. These days, most software professionals accept and appreciate Brooks’ analysis, yet we continue to make the very mistakes that prompted him to write The Mythical Man Month!

Which leads to an interesting question: armed with such a clear and compelling argument against piling on staff at the last minute, why do we repeatedly employ a strategy that not only fails to achieve the hoped-for schedule reductions but often results in buggy, unreliable software?

The most likely answer combines schedule pressure with the human tendency to over-optimism. Basing plans on hope rather than experience is encouraged by a constant parade of new tools and methods. Faced with the pressure to win business, please customers and maintain market share, is it really surprising that new  technologies tempt us to discount the past and hope that – if we use this tool, this team, this methodology - this project will be different?

How can software developers counter the human tendency to fall for overly optimistic estimates and unachievable schedules?

What's needed is perspective: the kind of perspective that comes from honestly examining - and reminding ourselves - how things have worked in the past. In a paper called, “Technology Can Only Do So Much”, I look at the human and technological factors that trip up so many software projects.  Good historical data provides a sound empirical baseline, against which both conventional wisdom and future plans can be assessed.


Blog Post Categories 
Metrics Team Size Estimation

Part IV: Duration, Team Size, and Productivity

For many projects, duration is just as important a constraint as cost. In this installment we will tackle the question:  How do changes to team size affect project duration and the resulting productivity?  Once again we will use our database of business applications completed since January, 2000.

Continue reading...

Blog Post Categories 
Team Size Productivity