Agility Between Freedom and Order

Work in large indus­tri­al cor­po­ra­tions is defined by process­es, roles and stan­dards — cen­tral­ly planned, elab­o­rat­ed, doc­u­ment­ed, rolled out, trained and reg­u­lar­ly checked for com­pli­ance. In return, there are ISO and DIN stamps and every­one is hap­py. On the paper, any­way. You can and indeed some­times have to ask your­self whether the actu­al work hap­pens because of or rather despite the many process­es. How­ev­er, this should only be men­tioned in pass­ing. The ques­tion rather is whether agile orga­ni­za­tions require process­es and stan­dards. And if so, how these actu­al­ly emerge and develop.

A basic prin­ci­ple of agile orga­ni­za­tions is decen­tral­iza­tion. Small and effec­tive units act inde­pen­dent­ly towards their cus­tomers. Buurt­zorg does this for exam­ple with the nurs­ing teams, FAVI with the mini fac­to­ries and Spo­ti­fy with its squads or Ama­zon with the two-piz­za teams. Cen­tral­ly defined stan­dards and process­es restrict the free­dom of these teams to make deci­sions and act inde­pen­dent­ly and thus restrict the agili­ty and the val­ue cre­at­ed for the customer.

But where would we get to if every team worked dif­fer­ent­ly? Isn’t this going to be pret­ty con­fus­ing? How are we sup­posed to work togeth­er like this? A few process­es and stan­dards are need­ed despite all the agili­ty. For exam­ple, no sen­si­ble soft­ware com­pa­ny will allow teams work­ing on a com­mon prod­uct to man­age their source code in dif­fer­ent repos­i­to­ries with dif­fer­ent branch­ing strate­gies. It would be too tedious to con­tin­u­ous­ly inte­grate all this into an ship­pable prod­uct. Google even goes so far as to store its entire source code of more than 16 years, con­sist­ing of bil­lions of lines, in a sin­gle repos­i­to­ry.

Also one wants to rely on promis­es of inter­faces despite all agili­ty and not to be sur­prised by a com­plete­ly dif­fer­ent behav­ior every day. For this rea­son, it has become com­mon prac­tice in many agile soft­ware com­pa­nies to ver­sion and doc­u­ment inter­faces and to con­stant­ly ver­i­fy the promised behav­ior with auto­mat­ed tests. Once pub­lished, you have to be able to rely blind­ly on an inter­face and there has to be a set of auto­mat­ed test cas­es to check the inter­face. Quite a lot of rules and quite rigid process­es for the agile teams.

One per­son­’s free­dom ends where anoth­er per­son­’s free­dom begins.
Immanuel Kant

This guide­line also facil­i­tates the dif­fer­en­ti­a­tion here. Whether one team prefers to use Scrum and the oth­er Kan­ban, or whether they use an elec­tron­ic taskboard while the oth­ers swear on their phys­i­cal board, how they dec­o­rate their team room or which tools they use most pro­duc­tive­ly, this and much more does not affect the free­dom of the oth­er teams or only lit­tle. Not stor­ing the source code cen­tral­ly or vio­lat­ing the sta­bil­i­ty of pub­lished inter­faces affects the free­dom of oth­ers, because it inevitably leads to prob­lems in the process of con­tin­u­ous inte­gra­tion and deploy­ment of the com­mon prod­uct. And that will slow every­one down.

First and fore­most, agile soft­ware teams want one thing: to deliv­er and try out their new fea­ture as quick­ly as pos­si­ble. To this end, they have their high­ly indi­vid­ual work­ing meth­ods with­in the team and that’s a good thing. But they also rely on rules of col­lab­o­ra­tion that have proved help­ful for every­one. Agili­ty and process­es and stan­dards are there­fore by no means mutu­al­ly exclu­sive. On the con­trary, rather rigid rules are required to ensure that each team can act out its agili­ty in the best pos­si­ble way in coop­er­a­tion with the others.

So every­thing remains the same? Not quite. The process­es, stan­dards and rules of the col­lec­tive work are no longer elab­o­rat­ed and described in one cen­tral place and then rolled out to all, but rather arise from this col­lec­tive work and are fur­ther devel­oped by the teams togeth­er. The main dif­fer­ence is there­fore not new process­es, stan­dards and rules for the col­lab­o­ra­tion of agile teams, but rather the fact that these arise from the col­lab­o­ra­tion and that every­one bears joint respon­si­bil­i­ty for it instead of being forced upon them as a cen­tral guide­line. A sub­tle but essen­tial difference.