Brooks's law in Agile projects

Arseni Mourzenko
Founder and lead developer
December 11, 2014
Tags: management 34 agile 10 short 50

I was re­cent­ly asked whether Brook's law ap­plies to Ag­ile pro­jects as well. By Ag­ile pro­jects, the per­son ask­ing the ques­tion means ac­tu­al, real Ag­ile pro­jects, the ones where can­cel­ing a pro­ject and re­sum­ing it sev­er­al months lat­er with a dif­fer­ent team has no ma­jor neg­a­tive im­pli­ca­tions.

Brook's law deals with pro­jects which are al­ready late. I'm not sure if we can tell that an Ag­ile pro­ject is late, giv­en its dy­nam­ic na­ture. I as­sume that we are in a con­text where there is still some es­ti­mate about fea­tures be­ing de­liv­ered for spe­cif­ic dead­lines, but even then, I'm not sure if it makes sense to de­clare the pro­ject late: for me, the only im­pli­ca­tion is that the es­ti­mate is wrong and should be cor­rect­ed.

But for the sake of ar­gu­ment, let's pre­tend that the es­ti­mate is right and the team is slow­er than ex­pect­ed. Jump­ing to the con­clu­sion that adding more peo­ple would make things faster would be pre­ma­ture. Be­fore that, one needs to know why is the team per­form­ing low­er than ex­pect­ed.

In the last case, one should be care­ful adding new per­sons:

Out­side those cas­es, I don't see how adding new peo­ple could harm the pro­ject. Keep in mind that this con­cerns well-man­aged Ag­ile pro­jects, which are ex­treme­ly rare. Chances are, you're not con­cerned by this ar­ti­cle. Thanks for read­ing.