Brooks's law in Agile projects

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.

• It might be that the team is too large to be ag­ile, in which case adding more peo­ple will harm the pro­ject.

• It might be that there are man­age­ment is­sues: com­mu­ni­ca­tion prob­lems, a team mem­ber which doesn't in­vest him­self in the pro­ject, what­ev­er. Adding more peo­ple will prob­a­bly harm the pro­ject as well.

• It might be that de­vel­op­ers are not ex­pe­ri­enced enough. Here, adding more peo­ple may help only if (1) new peo­ple are ex­pe­ri­enced, (2) old mem­bers un­der­stand and agree that new mem­bers are more ex­pe­ri­enced and (3) new peo­ple un­der­stand that they are join­ing a team of in­ex­pe­ri­enced de­vel­op­ers. Train­ing ex­is­tent mem­bers is an­oth­er so­lu­tion to con­sid­er, and will prob­a­bly be more ef­fec­tive.

• Fi­nal­ly, it might be that every­thing is per­fect­ly fine and that the pro­ject is done slow­er than ex­pect­ed be­cause there are no enough man­pow­er.

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

• Is the team small enough? If the team is al­ready too large to han­dle com­mu­ni­ca­tion prop­er­ly in Ag­ile en­vi­ron­ment, mak­ing it larg­er may have a neg­a­tive im­pact.

• Is it easy for a new­com­er to grasp the ar­chi­tec­ture of the pro­ject and to be able to de­liv­er a new fea­ture with­in days? If not, Brook's law ap­plies. Old mem­bers of the team will waste their time ex­plain­ing things to new­com­ers, which will be coun­ter­pro­duc­tive in short-term. In the same way, if there is no re­gres­sion test­ing and no Con­tin­u­ous In­te­gra­tion, for­get about adding per­sons.

• Would new mem­bers in­te­grate with­in the team with ease? If a team has strong team cul­ture which is hard to share to out­siders, new per­sons may feel ex­clud­ed. This ex­clu­sion will lead to poor com­mu­ni­ca­tion be­tween the team it­self and the per­sons who are here to help, but who are not part of the team. Be­ware of cul­tur­al gap as well: if the cur­rent team has de­vel­oped over time some opin­ions about sub­jec­tive mat­ter such as cod­ing style, new­com­ers may find them­selves fight­ing with the team.

• Are crit­i­cal fea­tures iso­lat­ed enough? New­com­ers help to for­ward the ship­ment date only if they can work on crit­i­cal fea­tures alone, with­out dis­turb­ing the old mem­bers of the team. If all crit­i­cal fea­tures are al­ready tak­en by the mem­bers of the team, new­com­ers will con­tribute to less crit­i­cal fea­tures only, which will have no ef­fect on ship­ment date.

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.