To Add Or Not To Add
Why staffing in software projects can delay schedules, and what should we consider instead
Why staffing in software projects can delay schedules, and what should we consider instead
Key Takeaways
When adding a workforce to a project, the additional contribution won’t necessarily be as effective as before.
In software projects, adding a workforce will only make them later (Brooks’s law).
To better estimate and lead software projects, we should separate effort from progress and identify sequential constraints.
The law of diminishing returns
Imagine you want to paint your house. You buy some paint and brushes, and from experience, you know this work will take you 5 hours. If you wanted to finish the job sooner, what would you do?
The typical answer is adding a workforce. If one person can do the job in 5 hours, two could do it in 2.5 hours. And five people would do it in an hour.
That’s where the law of diminishing returns comes into effect. The above is valid as long as -
Each person is working on independent sub-tasks
There are enough tools.
Communication is minimal
At some point, staffing won’t result in the same productivity increase as before. It will still help, but not as much as the first workers brought into the job.
On the contrary, if one woman takes nine months to carry a baby to labor, will two women require 4.5 months?
Brooks’s law
“adding manpower to a late software project makes it later.”
Fred Brooks, “the mythical man-month.”
Brooks emphasizes the myth around “man-month” in his book, saying, “Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them.”
Let’s consider we are working in a software company on a substantial project and are behind deadlines. What will we do? Usually, we will add a workforce to the project. While we understand the law of diminishing returns, why does Brooks claims it will only make the project later?
The focus is on communication. The topic reminds me of a text by Martin Buber, a philosopher, about human dialogue, explaining how a two-person conversation contains six characters.
I believe Brooks’s law can apply to other industries and projects, and I explain it with these three reasons.
1 — Recruiting and training
The team needs to invest effort in recruiting the right person and training him on the different subjects. In time, they lose focus on the original software project.
2 — Communication overhead
When a four-person team becomes five, it has four to six more communication lines (with each team member, with the manager). Adding manpower to a project creates a communication overhead.
3 — The group dynamic
In a software project, the focus is on bringing ideas to life. The group has its dynamic of raising ideas, accepting solutions, and working in a rhythm that allows each member to contribute. When adding a new member, the first months will require forming a new dynamic and paying extra attention to the team’s routines.
So what should we do?
First, when we estimate a project, we need to separate effort from progress. The progress depends on the team structure, the independence of the task, and the amount of communication involved. We can agree on the effort required, but we can’t fall to estimate man-months.
Second, identify the sequential constraints of the project, and consider -
How many teams are involved
How many independent sub-tasks
Who needs to be involved in the decision-making process
Lastly, if and when the schedule slips, remember Brooks’s law before deciding to bring in another teammate. Sometimes we need to accept the delay, cut on the quality, or find ways to reduce constraints.