Can I make my project move faster if I simply add more team members? This question has plagued project managers since the beginning of our profession. For many manufacturing-like projects, the answer to this fits into the project management pyramid. If I keep the scope constant and I want to reduce my timeline, I need to just put more resources on the project. Unfortunately, in knowledge work fields, like software development, this simplistic model falls short.

The Grade School Model

In grade school, most kids are given a word problem that looks like this, “If Jane can produce 5 widgets an hour and Bobby can produce 3 widgets an hour, how many widgets can they produce together in 2 hours.” Teachers look for the simple answer of 16, based on an addition of each child’s rate per hour.

Number of People vs. Team Productivity

Grade School Model

My younger know-it-all self thought that this was far too simple of an answer. The assumption was that adding new team members would increase productivity, or the total value delivered by the team, at a fixed rate. They assumed cooperation yielded predictable and simple growth. My younger self always found this assumption perplexing.

My Naive Model

I thought if two or more people work together, they’d be even more productive than they were on their own. Tasks could be optimized based on an individual’s strengths. Cooperation would cause the output to grow beyond a simple linear model.

Number of People vs. Team Productivity

My Naive Model

My childhood experience showed that delivering newspapers was a lot faster when my brother and I worked together. We would fold in a production line. He would bag papers while I loaded the wagon. Together, we would divide and conquer the neighborhood. In our paper route, cooperation yielded efficiency.

Theory Hits Reality

As a fresh new business analyst, I brought with me this optimistic productivity model. I assumed that as you added more software developers to a team, they would be geometrically more productive. They could share knowledge, optimize processes, unblock each other, and cut out waste. This kumbaya view of team productivity was quickly shattered as my theory hit the real world.

Number of People vs. Team Productivity

The Reality

I saw project managers attempting to throw more developers at projects in jeopardy. To my horror, deadlines were overrun and requirements not met. At first, I didn’t learn from these mistakes. I attempted the same strategy myself. And like my predecessors, I watched my early projects fail. Training time, communication overhead, and rework all took up more time as developers were added. Adding more individuals to a struggling project didn’t increase productivity. It actually decreased it!

Living Brook’s Law

Around this time, I first read the Mythical Man Month, by Fred Brooks. Brooks claimed that adding manpower to a late software project makes it later. Adding individuals to a team would reduce productivity, because it takes time for them to get up to speed. New team members add extra communication burden to everyone on the team. Finally, subdividing many tasks efficiently is impossible.

I learned more about Agile software development. The phrase “Nine women can’t make a baby in one month” kept coming up. This concept combined with Brooks’ Law resonated with the struggle that I faced. I started asking the developers on my team some simple questions. This helped to gauge the impact of team expansion.

• “Would adding another person to this task help or hinder you?”
• “How would your output drop if you had to onboard someone new to the project?”
• “What sort of architectural debt will we incur if we attempted to go faster with a few more people?”
• “What processes would we have to employ to facilitate adding more developers to the project?”

Number of People vs. Team Productivity

Good Practices vs. Bad Practices

I began to see that teams have an inflection point. At this point, adding new team members would negatively impact the productivity of the entire project. This dip in productivity may begin with adding the 3rd member to the team or the 8th member. It really depends on the team and the project. There is no magic number. Determining at which point this inflection will be tripped is more of an art than a science. There are many variables at play:

• The experience level of the team and new team members
• The complexity of the project
• The level of documentation written
• The maturity of the project architecture
• And much more

Brooks himself admitted that his “law” was an oversimplification. But, it was a strong cautionary tale. Adding more people to a project without evaluating the negative impact of expansion itself will only turn a bad situation worse. Fortunately, there are ways to push the inflection point forward. This attempt could allow for some initial gains to productivity. This requires:

• Thinking smarter, not harder
• Adhering to good Agile software development best-practices
• Modern standards of continuous integration and release
• Reducing scope to critically necessary requirements
• Eliminating switching costs by focusing development efforts, rather than fragmenting them

Focusing on good Agile practices can help in the short term. But, completely eliminating the eventual decline of productivity is impossible. The piper must be paid and a project will suffer from too many people.

The Silver Lining

The reality of software development is that there is no simple model to predict how adding new members to a team will impact a project. In general, throwing warm bodies at a difficult project is a recipe for disaster. This situation can get significantly worse if processes put in place to ensure quality are ignored or removed. Adhering to software development best practices can reduce the negative impact, but not eliminate it. Adding more people rarely produces the anticipated results of most inexperienced project managers. Too many cooks in the kitchen can ruin the meal.

Adding a small handful of competent team members to a well managed project can create some initial gains. However, the increase to complexity will become insurmountable if the team grows without purpose. But all is not lost! Adjusting the timeline or scope of a project can counter the inevitable drop in productivity. Another good strategy is to modularize your product into independent components or services. Small, focused teams can then take on a dedicated portion. This will keep the scope limited for each individual team, while allowing for staffing scalability.

Rededicating your team to producing quality features that are focused on your minimum viable product is key. Cut away the excess and focus on the heart of your project. Thinking with a “less is more” product frame of reference can help you not fall victim to the “warm bodies” pitfall.