The Benefits of Feature Teams

Agile meth­ods and espe­cial­ly Scrum look very sim­ple in a small prod­uct with a sin­gle team. As soon as sev­er­al teams work on one prod­uct, the work has to be split up some­how. The obvi­ous, because well-known, approach is to break down the prod­uct more or less log­i­cal­ly and mean­ing­ful­ly into com­po­nents and to assign com­po­nent teams to them. From the cus­tomer’s point of view, how­ev­er, these com­po­nents are com­plete­ly irrel­e­vant. At best, the cus­tomer does­n’t real­ize them. In most cas­es, how­ev­er, he does, because there usu­al­ly sev­er­al com­po­nent bound­aries have to be crossed to real­ize cus­tomer’s ben­e­fits and the pro­duc­t’s nec­es­sary func­tions. This results in han­dovers and coor­di­na­tion between teams that inter­rupt the flow. From the cus­tomer’s point of view, it would be much more desir­able if the new fea­ture was imple­ment­ed by a sin­gle so-called fea­ture team, no mat­ter which com­po­nents are affected.

Every­one who has built or ren­o­vat­ed a house is famil­iar with this. You real­ly “only” want to have sun pro­tec­tion attached to the win­dows. Unfor­tu­nate­ly, this often does not come from a sin­gle source, but requires not only the crafts­man who actu­al­ly installs the sun pro­tec­tion, but also an elec­tri­cian who lays the pow­er cables, a brick­lay­er who plas­ter every­thing and a painter who paints every­thing again. The val­ue stream from the idea to the ben­e­fit is inter­rupt­ed sev­er­al times by han­dovers and must be more or less exten­sive­ly planned and coor­di­nat­ed (by the client). How much eas­i­er and quick­er it would be to order the sun pro­tec­tion with every­thing you need from a sin­gle crafts­man! This is exact­ly the dif­fer­ence from the cus­tomer’s point of view between com­po­nent teams (the spe­cial­ized crafts­men with their respec­tive sub­con­tracts) and fea­ture teams (a team that com­plete­ly process­es the order, no mat­ter what skills are required).

Since cus­tomer ori­en­ta­tion is an essen­tial prin­ci­ple of agili­ty, com­po­nent teams may be the sim­pler, but only the sec­ond best solu­tion to split work on a large prod­uct. No mat­ter how the com­po­nents are cut, there are still han­dovers and coor­di­na­tion between the com­po­nents to offer the cus­tomer their ben­e­fit. Some cuts are cer­tain­ly bet­ter than oth­ers. The fre­quent­ly used slic­ing in hor­i­zon­tal lay­ers like fron­tend, back­end and data­base in soft­ware prod­ucts may be quite con­ve­nient for the respec­tive experts. But from the cus­tomer’s point of view this design is extreme­ly unsat­is­fac­to­ry, because any non-triv­ial fea­ture will pass through all lay­ers, result­ing in slow and error-prone han­dovers. Bet­ter are ver­ti­cal slices that break the prod­uct down into log­i­cal­ly self-con­tained sub-prod­ucts. For exam­ple, an enter­prise resource plan­ning sys­tem will con­sist of at least the com­po­nents pur­chas­ing, ware­hous­ing and sales. Nev­er­the­less, there will still be fea­tures that span more than one com­po­nent and thus require coordination.

Orga­ni­za­tions which design sys­tems […] are con­strained to pro­duce designs which are copies of the com­mu­ni­ca­tion struc­tures of these organizations.
Melvin E. Conway

Regard­less of the com­po­nent design, com­po­nent teams lead to silos, because each team will feel respon­si­ble only for its part of the prod­uct. This effect is rein­forced by the Con­way’s Law accord­ing to which “the soft­ware inter­face struc­ture of a sys­tem will reflect the social bound­aries of the organization(s) that pro­duced it, across which com­mu­ni­ca­tion is more dif­fi­cult” (Wikipedia). Orga­ni­za­tions tend to design soft­ware sys­tems in a way that resem­bles the orga­ni­za­tion­al and com­mu­ni­ca­tions struc­ture. If the ver­ti­cal com­po­nent slic­ing fol­lows this orga­ni­za­tion­al struc­ture and is staffed by teams of the respec­tive orga­ni­za­tion­al units, this only cements the walls of the already exist­ing silos.

Fea­ture teams, i.e. teams that can imple­ment a cus­tomer’s require­ment from the idea to the actu­al use, no mat­ter in which com­po­nent of the prod­uct, are cer­tain­ly the bet­ter choice. From the cus­tomer’s point of view any­way, but also from the orga­ni­za­tion’s point of view. Since com­po­nent teams can only work in their com­po­nents, it always requires a great deal of plan­ning to ensure that these teams are always opti­mal­ly uti­lized because not every require­ment will have the same amount of work per com­po­nent. How­ev­er, fea­ture teams require a high degree of matu­ri­ty of the orga­ni­za­tion, because the prod­uct is joint­ly designed and owned by every­one. Orga­ni­za­tions that were used to break work down into small steps and force peo­ple into rigid roles in defined process­es will have great dif­fi­cul­ties in the first place. Fol­low­ing the prin­ci­ple of Shu-Ha-Ri, it is rec­om­mend­ed to start with small prod­ucts with a sin­gle team and to inter­nal­ize the stance and prin­ci­ples of agili­ty. Then you can take on larg­er prod­ucts with ver­ti­cal com­po­nent teams and let them grad­u­al­ly devel­op into fea­ture teams.