Scrum and the scaling frameworks

Don’t do it! If you can avoid it, do not use a scal­ing frame­work!”

Imag­ine how puz­zled I felt once the train­er kicked off the Scaled Pro­fes­sion­al Scrum course with this sen­tence! My enthu­si­asm dropped imme­di­ate­ly but the curios­i­ty grew even stronger: Why does he mean it like this? He got me!

The 2 days-course was great and very insight­ful but my main take-away was the per­cep­tion change on using a “sil­ver bul­let” solu­tion to scale Scrum. It was like a par­a­digm shift with lots of  “Aha” expe­ri­ences, which actu­al­ly showed how bound I was to my ini­tial per­cep­tion about scal­ing Scrum.

So what is “scaled” Scrum about?

It is still Scrum but with more than 3 Devel­op­ment teams work­ing from a com­mon Prod­uct Back­log against a com­mon prod­uct. At the end of every sprint, a poten­tial­ly ship­pable prod­uct incre­ment should be avail­able. Hav­ing mul­ti­ple Scrum teams work­ing on dis­tinct prod­ucts is not “scal­ing” Scrum, it is mere­ly mul­ti­ple sep­a­rate instances of Scrum.

This arti­cle is not about com­par­ing the exist­ing scal­ing frame­works. I think of any “frame­work” as a set of prac­tices, prin­ci­ples, roles that…should be applied wise­ly. Some of them come with a lot of mate­r­i­al, oth­er with very lit­tle. I don’t know which is bet­ter but I know that dif­fer­ent peo­ple and organ­i­sa­tions have dif­fer­ent needs, depend­ing on what they already know, their cul­ture, their soft­ware, their busi­ness mod­el etc.

What do we think it will help us? How much should we prescribe?

Some will need very lit­tle guid­ance, some need all the sup­port they can get. Some are hap­py to exper­i­ment what will work best for them (embrac­ing inspect and adapt) and some are reluc­tant to fig­ure this out and block ini­tia­tives of this kind.

I can under­stand why peo­ple feel com­fort­able with high­ly pre­scrip­tive meth­ods: they keep us safe from uncer­tain­ty. They also ensure that teams are work­ing in the same way by using an iden­ti­cal approach. Too much pre­scrip­tion though, about roles, struc­tures, process­es and tech­niques, can be dif­fi­cult to com­pre­hend, inhib­it learn­ing and are not adapt­able to dif­fer­ent con­texts. It kills cre­ativ­i­ty and the desire to chal­lenge the sta­tus quo. Every­body is fol­low­ing the rules with­out ques­tion­ing them.

On the oth­er side, with too lit­tle pre­scrip­tion, teams and orga­ni­za­tions often do not know where to start. The lack of con­crete­ness will make peo­ple avoid the change. You might have dealt so far with sit­u­a­tions where you had to do some­thing with­out know­ing exact­ly what that some­thing is.

Ulti­mate­ly, the more com­plex the rules, the less peo­ple use their brains. The more pre­scrip­tive the process, the less teams take own­er­ship of it. Large-scale prod­uct devel­op­ment is extreme­ly com­plex and the only way to suc­ceed in it is to have those with the most infor­ma­tion mak­ing most of the deci­sions around how to work.

Before choos­ing to imple­ment a scal­ing frame­work, the lead­ers in the organ­i­sa­tions should start think­ing about answer­ing these ques­tions:

  • Why scale? What are we try­ing to achieve? Do we expect that by adding more teams we will get greater results? What’s the goal? Is it increased pro­duc­tiv­i­ty or maybe more val­ue?
  • How can we do more with the cur­rent set­up (automa­tion, train­ing, remov­ing organ­i­sa­tion­al imped­i­ments, increase the focus on val­ue)? Every­thing that hurts in sin­gle team Scrum, is going to be painful at scale.
  • How often is the work going to be released?
  • What tech­niques will be used to inte­grate the work to that fre­quen­cy?
  • What will be done to mea­sure and man­age the work and its inte­gra­tion?
  • What over­head is being absorbed to achieve this inte­gra­tion and deliv­ery?
  • Are the cost and ben­e­fits of deliv­ery fre­quen­cy bal­anced by val­ue returned?
  • How is the cost going to be sys­tem­at­i­cal­ly reduced?

Scal­ing is hard. Real­ly hard, but not impos­si­ble. We should not com­pro­mise auton­o­my, desire for con­tin­u­ous improve­ment, and pro­fes­sion­al­ism just because we are work­ing at scale.

 

Ref­er­ences:

Scal­ing Scrum  https://www.scrum.org/resources/blog/scaling-scrum

Leave a Reply