Adding developers to an agile project disrupts Velocity: Brooks law re-interpreted

“Adding developers to a late project will only make it later” (A rewording of Brooks law).

The mythical man month is a classic in software development that is still relevant. And a highly recommended read for project managers. However, times change, while brooks law is relevant, we need to unpack a few concepts for its application on agile projects.

Understanding Brooks’s Law

I like that the seemingly simple statement of Brooks law, highlights the complex dynamics that are at place in software development.

For instance:

• Ramp-up Time: New team members require time to become productive. They need to understand the project’s architecture, codebase, and tools. This onboarding process requires existing team members to divert their attention from their tasks, temporarily diminishing their capacity to produce software.
• Communication Overhead: As team size increases, so does the number of communication channels between team members. The number of communication channels increases rapidly with the number of people, creating a combinatorial explosion. This increased communication overhead can lead to miscommunications and requires more meetings, reducing overall efficiency.
• Limited Task Divisibility: Not all software development tasks can be divided easily among many developers. Some tasks require a concentrated effort by a small group or a single developer. Adding more developers to such tasks might not speed things up and may even cause delays.
• Unpredictable Velocity: Fluctuations in capacity, will become visible in the teams’ velocity, which will fluctuate and decrease the predictability of the team.

Brooks’s Law as a Systemic Issue

If we look at the model we are drawn to ask questions like:

• How long does it take for new hires to work productively in the team?
• What effort do current team members have to invest in training new hires?
• Have we considered the increased cost of communication?

Reinterpreting Brooks’s Law in Agile: The Impact on Velocity

Brook stated the law at a time when fixed-scope projects were the norm. Agile projects are typically of fixed cost. So the statement “a project is late” has a different meaning (if any).

In agile projects, the impact of Brooks’s law is felt in the disruption to the team’s Velocity and as a result on the team’s capacity to consistently deliver software increments. 

When new developers are added to an agile team (some team formation models would suggest that the first impact is that you are creating a new team!), I can think of the following first-order effects to consider:

• Sprint Disruption: The existing team’s rhythm and sprint backlog are disrupted, requiring task re-evaluation and potential backlog reconfiguration.
• Onboarding within Sprints: The existing team members have to balance their sprint tasks with onboarding new colleagues, potentially leading to incomplete tasks by the end of the sprint. This impacts the overall capacity.
• Extended Sprint Ceremonies: Teams have to relearn how to keep the ceremonies timeboxed with the increase in members and communication channels. Again the visible effect is the reduced overall capacity.

Recommendations: Navigating the Challenges of Brooks’s Law

Brooks law is a cautionary tale that adding developers is not a quick fix. If you are to add developers you need to take a longer view of the project (and of the prospective return on investment). Eventually, the new developers will be assimilated into the team, and the team will settle into some other productive capacity. So, before adding new team members, think of the following first-order effects:

• Timing: Do you feel the need to increase Velocity? The immediate effect will likely be a reduction. Think ahead with your release plan when you need the next peak in team performance.
• Invest in training: Don’t expect your new team members to hit the ground running, identify the project-specific training needs and develop a training plan to facilitate the onboarding.
• Task Segmentation: How good are your user stories? Smaller tasks help distribute the work better to a larger team.

Conclusion

The lessons from Brooks’s Law isn’t aren’t about adding more people to achieve faster results. They are about understanding the complex interactions within a development team and making informed decisions. In Agile environments, instead of focusing on lateness, the real impact of this law can be seen in the fluctuation of the team’s velocity. 
Has your team performance improvement hit a bottle neck? Click this link to reach out, and let’s take the first step toward breaking through those barriers together.