Home Home

Brooks's law in Agile projects

Arseni Mourzenko
Founder and lead developer, specializing in developer productivity and code quality
December 11, 2014

I was recently asked whether Brook's law applies to Agile projects as well. By Agile projects, the person asking the question means actual, real Agile projects, the ones where canceling a project and resuming it several months later with a different team has no major negative implications.

Brook's law deals with projects which are already late. I'm not sure if we can tell that an Agile project is late, given its dynamic nature. I assume that we are in a context where there is still some estimate about features being delivered for specific deadlines, but even then, I'm not sure if it makes sense to declare the project late: for me, the only implication is that the estimate is wrong and should be corrected.

But for the sake of argument, let's pretend that the estimate is right and the team is slower than expected. Jumping to the conclusion that adding more people would make things faster would be premature. Before that, one needs to know why is the team performing lower than expected.

  • It might be that the team is too large to be agile, in which case adding more people will harm the project.

  • It might be that there are management issues: communication problems, a team member which doesn't invest himself in the project, whatever. Adding more people will probably harm the project as well.

  • It might be that developers are not experienced enough. Here, adding more people may help only if (1) new people are experienced, (2) old members understand and agree that new members are more experienced and (3) new people understand that they are joining a team of inexperienced developers. Training existent members is another solution to consider, and will probably be more effective.

  • Finally, it might be that everything is perfectly fine and that the project is done slower than expected because there are no enough manpower.

In the last case, one should be careful adding new persons:

  • Is the team small enough? If the team is already too large to handle communication properly in Agile environment, making it larger may have a negative impact.

  • Is it easy for a newcomer to grasp the architecture of the project and to be able to deliver a new feature within days? If not, Brook's law applies. Old members of the team will waste their time explaining things to newcomers, which will be counterproductive in short-term. In the same way, if there is no regression testing and no Continuous Integration, forget about adding persons.

  • Would new members integrate within the team with ease? If a team has strong team culture which is hard to share to outsiders, new persons may feel excluded. This exclusion will lead to poor communication between the team itself and the persons who are here to help, but who are not part of the team. Beware of cultural gap as well: if the current team has developed over time some opinions about subjective matter such as coding style, newcomers may find themselves fighting with the team.

  • Are critical features isolated enough? Newcomers help to forward the shipment date only if they can work on critical features alone, without disturbing the old members of the team. If all critical features are already taken by the members of the team, newcomers will contribute to less critical features only, which will have no effect on shipment date.

Outside those cases, I don't see how adding new people could harm the project. Keep in mind that this concerns well-managed Agile projects, which are extremely rare. Chances are, you're not concerned by this article. Thanks for reading.