First the Problem, Then the Solution!

Agile frameworks are collections of generalized solutions to typical problems in agile organizations. Applying these solutions works best when the pain of the problem is felt instead of just understood theoretically. An agile transformation is not an introduction of a framework but a joint journey on which obstacles are discovered and solved with the help of the known frameworks.

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

Share This Post

Leave a Reply