Agility and Subsidiarity: Autonomous Decisions – Shared Responsibility

Agile orga­ni­za­tions rely on the prin­ci­ple of sub­sidiar­i­ty. Deci­sions are always made as decen­tral­ized as pos­si­ble. The next high­er or next larg­er unit only takes action if the small­er unit is not able to solve the task alone. But even then, the objec­tive is still to help peo­ple to help them­selves. How­ev­er, this only works if auton­o­my is giv­en a com­mon ori­en­ta­tion towards a high­er pur­pose. Con­stant work on and with this pur­pose as a guide­line is thus one of the most impor­tant lead­er­ship tasks in an agile orga­ni­za­tion. And active­ly assum­ing respon­si­bil­i­ty in the sense of a com­mon mis­sion is the most impor­tant task of the decen­tral­ized units, by which their auton­o­my is legitimized.

Agile Teams Don’t Have Roles

Agile teams avoid shar­ing respon­si­bil­i­ty between roles. In Scrum, for exam­ple, there are no explic­it roles in the devel­op­ment team. Rather the team assumes joint respon­si­bil­i­ty for the user sto­ries it com­mits per sprint. Obvi­ous­ly, deliv­er­ing those sto­ries requires a wide range of skills in the team, from user inter­face design and back­end pro­gram­ming to user doc­u­men­ta­tion. Ded­i­cat­ed roles are not required for this and would be detri­men­tal to the respon­si­bil­i­ty for the com­mon goal (and detri­men­tal to the team’s flexibility).

Break down bar­ri­ers between depart­ments. Peo­ple in research, design, sales, and pro­duc­tion must work as a team.

W. Edwards Deming

Feature Teams Take Joint Responsibility for Their Product

Leav­ing the lev­el of the indi­vid­ual team as the small­est unit of an agile orga­ni­za­tion, one comes to the ques­tion of scal­ing, i.e. how sev­er­al teams work togeth­er on a sin­gle prod­uct. LeSS and SAFe, the two best-known scal­ing frame­works, agree that so-called fea­ture teams are best suit­ed for this.

What already applies on the small scale of a team is repeat­ed on a large scale here: In con­trast to com­po­nent teams, fea­ture teams are not respon­si­ble for a spe­cif­ic part of the prod­uct (e.g. for a mod­ule or a com­po­nent), but imple­ment require­ments (fea­tures) all across the prod­uct. Fea­ture teams thus inher­ent­ly assume more respon­si­bil­i­ty than com­po­nent teams. There­fore they are the bet­ter choice (besides the high­er flex­i­bil­i­ty they offer).

Objectives & Key Results Provide a Common Direction for the Agile Organization

Yet anoth­er lev­el high­er the ques­tion aris­es how to align a prod­uct port­fo­lio (if one hap­pens to have more than one prod­uct) as an agile orga­ni­za­tion. Here, the shared under­stand­ing of pur­pose and mis­sion is the deci­sive frame­work for agili­ty. As a link between this long-term guide­line and the dai­ly work, Objec­tives & Key-Results (OKR) can be used as a method for set­ting goals in an agile way and thus pro­vide a com­mon direc­tion for the products.

At first OKR – like so many oth­er things – are decep­tive­ly sim­ple: Ambi­tious goals are equipped with a few key results with which the attain­ment of these goals is mea­sured. All this is new­ly agreed in short cycles (e.g. quar­ter­ly) (see also this tuto­r­i­al at Google re:Work). What is deci­sive here is that a sig­nif­i­cant part of these objec­tives are devel­oped from the bot­tom up, i.e. sub­sidiar­i­ty clear­ly applies here as well. Equal­ly impor­tant is that all OKRs on all lev­els are com­plete­ly open and present at all times. Ide­al­ly, the key results are cho­sen in such a way that they are not only mea­sured once at the end of the quar­ter, but are con­stant­ly updat­ed. In this way, the indi­vid­ual teams can imme­di­ate­ly rec­og­nize the impact of their work on their com­mon goals.

Dis­ci­pline is achieved through self-orga­ni­za­tion and per­son­al respon­si­bil­i­ty, by dis­ci­plin­ing one only gets obedience.

Ger­ald Hüther

Share This Post

Leave a Reply