Setting Standards in Agile Organizations

Agili­ty requires ori­en­ta­tion. It’s exact­ly this align­ment that enables effec­tive auton­o­my and decen­tral­ized deci­sions, which make agile orga­ni­za­tions so adapt­able. But agili­ty also requires com­mon stan­dards and con­ven­tions to ensure that effec­tive coop­er­a­tion of autonomous teams. So the ques­tion is not whether such stan­dards are required in agile orga­ni­za­tions, but rather how they are cre­at­ed and enforced.

The answer to this ques­tion is obvi­ous and well known in tra­di­tion­al­ly func­tion­al­ly divid­ed orga­ni­za­tions: A sep­a­rate unit of spe­cial­ists is formed with the task of elab­o­rat­ing, imple­ment­ing and then con­tin­u­ous­ly improv­ing guide­lines, stan­dards, process­es, etc. Thus a few spe­cial­ists design in an ivory tow­er the stan­dards for the rest. Think­ing and act­ing are there­fore just as strict­ly sep­a­rat­ed as they were at the time of Hen­ry Ford (where think­ing in this sense was still more with the man­ag­er than with a spe­cial­ized unit, but this does not change the principle).

Stan­dards should not be forced down from above but rather set by the pro­duc­tion work­ers themselves.

Tai­ichi Ōno

An essen­tial inno­va­tion of the Toy­ota Pro­duc­tion Sys­tem, which Tai­ichi Ōno sub­stan­tial­ly shaped, was to bring think­ing and act­ing togeth­er again at the Gem­ba, i.e., at the place where the val­ue is cre­at­ed. This enabled Toy­ota to sig­nif­i­cant­ly increase pro­duc­tiv­i­ty and not only to catch up with the Amer­i­can com­pe­ti­tion from Detroit from a des­per­ate posi­tion, but even to out­per­form it. 

The con­cepts and meth­ods spread from the man­u­fac­tur­ing indus­try as Lean Man­u­fac­tur­ing to many oth­er indus­tries in gen­er­al­iza­tion as Lean Man­age­ment – includ­ing IT, where the Agile Man­i­festo can be read his­tor­i­cal­ly and in terms of con­tent as an appli­ca­tion of the Lean Man­age­ment prin­ci­ples to the process of soft­ware devel­op­ment.

Some­thing is wrong if work­ers do not look around each day, find things that are tedious or bor­ing, and then rewrite the pro­ce­dures. Even last month’s man­u­al should be out of date.

Tai­ichi Ōno

Owning not renting

For Tai­ichi Ōno, stan­dards were the foun­da­tion of any con­tin­u­ous improve­ment (“With­out stan­dards, there can be no improve­ment.”). But he also knew that the only peo­ple who are allowed to devel­op and improve these stan­dards and process­es are those who prac­tice them on a dai­ly basis. The role of the man­ag­er in this game is a sup­port­ive one: it’s about empow­er­ing employ­ees to do that con­tin­u­ous improve­ment instead of just instruct­ing them.

Exact­ly these find­ings from Lean Man­age­ment pro­vide the deci­sive hint for answer­ing the ques­tion asked at the begin­ning, how stan­dards, guide­lines, process­es, etc. arise and should be fur­ther devel­oped in agile orga­ni­za­tions. All this clear­ly belongs in the hands and respon­si­bil­i­ty of those who have to work with them every day. The mot­to is: own­ing not renting.

Just like the task of the man­ag­er in Lean Man­age­ment, the task of the for­mer cen­tral offices for stan­dards, process­es, etc. changes accord­ing to this prin­ci­ple. Instead of pre­scrib­ing and mon­i­tor­ing, they have to empow­er peo­ple to do this con­tin­u­ous improve­ment work on com­mon stan­dards. Through train­ing and coach­ing on the one hand and through good com­mu­ni­ty man­age­ment on the other.