First the Problem, Then the Solution!

Much to my wife’s cha­grin, I’m not much of a do-it-your­selfer. Nev­er­the­less, tools fas­ci­nate me. Beau­ti­ful­ly lined up in incred­i­ble vari­ety, they tout their unde­ni­able use­ful­ness in the hard­ware store. And occa­sion­al­ly, they tempt me to buy them just in case I might need them some­day. This case nev­er hap­pens, or when it does, I have long for­got­ten about the tool (my wife also claims that I can avoid this by keep­ing the tool store­room tidy, but that’s anoth­er story).

The sit­u­a­tion is sim­i­lar with var­i­ous agile frame­works such as the Scaled Agile Frame­work (SAFe), LeSS, Nexus, or the Spo­ti­fy mod­el. You won’t find these at the hard­ware store, but every con­sult­ing firm has them on offer. And here, too, cus­tomers are enticed to buy a mod­el with its tools and prac­tices. How­ev­er, this is often more of a pre­ven­tive and the­o­ret­i­cal­ly moti­vat­ed pur­chase, just as I do at the hard­ware store. One has not under­stood all the prob­lems these mod­els pro­vide solu­tions for, but they look con­ve­nient and valuable.

All these frame­works con­tain help­ful solu­tions, but they have to fit the orga­ni­za­tion’s prob­lems. These prob­lems, how­ev­er, must first and fore­most be under­stood and present in prac­ti­cal every­day life. That’s why I always advo­cate think­ing the agile trans­for­ma­tion big, start­ing small, and learn­ing quick­ly. If you start small, for exam­ple, with one or two Scrum teams, and then grad­u­al­ly expand the activ­i­ties, you will inevitably come across these prob­lems and under­stand the solu­tions that the var­i­ous frame­works pro­vide for them.

First on this jour­ney typ­i­cal­ly comes the prob­lem of coor­di­nat­ing the work of mul­ti­ple teams on the same prod­uct. The some­what tra­di­tion­al solu­tion is to break down the prod­uct hier­ar­chi­cal­ly into com­po­nents, on each of which a ded­i­cat­ed team works. Coor­di­na­tion in this set­ting is often up to the prod­uct own­er, who must ensure a con­sis­tent result for each sprint. As a result, the prod­uct own­er quick­ly becomes a bot­tle­neck miss­ing out on his actu­al work on the future of the prod­uct and with the stakeholders.

A sim­i­lar­ly severe prob­lem is that, glob­al­ly, these teams do not always work on the things that are most impor­tant to the prod­uct for work­load rea­sons. Work is not always even­ly dis­trib­uted across all com­po­nents of the prod­uct. So the team for the user man­age­ment com­po­nent, for exam­ple, will be work­ing on things that are not a pri­or­i­ty because, at the moment, the focus should be on rework­ing the store com­po­nent. Unfor­tu­nate­ly, the user man­age­ment team can’t help because it’s a dif­fer­ent component.

So-called fea­ture teams address pre­cise­ly this prob­lem. Their scope is not lim­it­ed to one prod­uct com­po­nent, but they can imple­ment a fea­ture across all com­po­nents end-to-end. These teams also have to coor­di­nate, but joint sprint plan­ning and a reg­u­lar scrum of scrums dur­ing the sprint are usu­al­ly suf­fi­cient. How­ev­er, this mod­el requires a high­er matu­ri­ty of the teams, which of course, need to know more about the entire prod­uct to make adjust­ments. This high­er degree of own­er­ship, con­cern­ing the prod­uct as the whole and not just to one com­po­nent, leads to a high­er degree of self-orga­ni­za­tion and relieves the prod­uct own­er of coor­di­na­tive tasks.

Even with this ele­men­tary form of scal­ing, i.e., mul­ti­ple teams work­ing on a sin­gle prod­uct, it is cru­cial how we divide the work. Sup­pose you choose the tra­di­tion­al break­down into com­po­nents and encounter a “Pro­gram Incre­ment Plan­ning” (PI Plan­ning) in the SAFe tool­box. In that case, you solve the prob­lem of man­ag­ing depen­den­cies on the sur­face, but you don’t get to the root of the problem.

If sev­er­al prod­ucts in a port­fo­lio work agile, the ques­tion of coor­di­na­tion and joint align­ment aris­es again, but now at a high­er, strate­gic lev­el. Here objec­tives and key results, for instance, could give the prod­ucts a shared strate­gic direc­tion with­out restrict­ing their auton­o­my too much. SAFe pro­vides answers to this at the port­fo­lio lev­el, and to a cer­tain extent, the tribes in the Spo­ti­fy mod­el are also a solu­tion. Many roads lead to Rome. How­ev­er, it is cru­cial to look for the solu­tion start­ing from a prac­ti­cal­ly occur­ring prob­lem and not pre­cau­tion­ary or out of the­o­ret­i­cal fas­ci­na­tion for the method­ol­o­gy on col­or­ful slides.

Final­ly, when many teams are work­ing in an agile man­ner across sev­er­al prod­ucts, the ques­tion of com­mon stan­dards for the oper­a­tions of the prod­ucts, the archi­tec­ture, Con­tin­u­ous Inte­gra­tion / Con­tin­u­ous Deploy­ment, or secu­ri­ty, to name only the obvi­ous ones, is press­ing. The pri­ma­ry orga­ni­za­tion­al struc­ture is right­ful­ly the prod­uct hier­ar­chy: The employ­ees should feel that they belong pri­mar­i­ly to their prod­uct and the val­ue cre­ation for the cus­tomer (ide­al­ly in a fea­ture team because oth­er­wise, they think they belong pri­mar­i­ly to the com­po­nent). In this sense, spe­cial­ist silos in the orga­ni­za­tion for these cross-cut­ting aspects are not a good solu­tion. Here come into play com­mu­ni­ties of prac­tice or guilds, depend­ing on the pre­ferred frame­work. Their task is always the same: to build up, pro­fes­sion­al­ize and also stan­dard­ize joint exper­tise (IT oper­a­tions, secu­ri­ty, archi­tec­ture, etc.) across sev­er­al prod­uct teams.

I could con­tin­ue this list of typ­i­cal prob­lems and the solu­tions offered in agile frame­works. How­ev­er, my point is not to exhaust the top­ic or cre­ate a meta-mod­el of agile frame­works. All frame­works con­tain rea­son­able solu­tions. Like there are good tools in the hard­ware store. But to use them suc­cess­ful­ly, you have to have the right prob­lem and under­stand that prob­lem cor­rect­ly. In addi­tion, all solu­tions also have side effects and inter­ac­tions, and some­times these solu­tions also need spe­cif­ic pre­req­ui­sites for suc­cess­ful application.

It is no longer suf­fi­cient to have one per­son learn­ing for the orga­ni­za­tion, a Ford or a Sloan or a Wat­son or a Gates. […] The orga­ni­za­tions that will tru­ly excel in the future will be the orga­ni­za­tions that dis­cov­er how to tap people’s […] capac­i­ty to learn at all lev­els in an organization.

Peter Sen­ge, The Fifth Discipline

The obses­sion with sim­ply select­ing a proven mod­el and rolling it out will there­fore not be reward­ed with suc­cess but has the poten­tial to burn the cho­sen agile frame­work and the con­cept of agili­ty in gen­er­al. It seems more sen­si­ble to me to explore the prob­lem space of scaled agile step by step and then, after under­stand­ing the prob­lem thor­ough­ly, look for ade­quate solu­tions in the known frame­works and beyond. Cru­cial to this is a fear­less learn­ing cul­ture and the fun­da­men­tal agile prac­tice of con­tin­u­ous improve­ment that orig­i­nates from lean man­age­ment, such as ret­ro­spec­tives in Scrum. With such a sus­tain­able foun­da­tion, it is unnec­es­sary to find the best frame­work to start with; a good begin­ning is enough, as long as there is con­sis­tent shared learning.

Pho­to by Natal­i­no D’Am­a­to on Unsplash