Impact over Input

Success­ful agile orga­ni­za­tions are strong­ly ori­ent­ed towards a com­mon mis­sion despite the guid­ing prin­ci­ple of self-orga­ni­za­tion. Auton­o­my requires ori­en­ta­tion, oth­er­wise it leads to chaos. Of course, all oth­er orga­ni­za­tions also claim for them­selves an appro­pri­ate vision and mis­sion. Agile orga­ni­za­tions, how­ev­er, are more impact-dri­ven. They focus more on out­comes and mea­sure the impact that these out­comes make. Tra­di­tion­al orga­ni­za­tions are more input-dri­ven inas­much they try to plan exact­ly which input in terms of resources is needed

Traditional Organizations Analyze, Plan & Execute

Tra­di­tion­al orga­ni­za­tions are heav­i­ly plan-dri­ven. A project is bro­ken down, ana­lyzed and planned. This is a tedious process of coor­di­na­tion and agree­ment that kills a lot of inno­va­tion right from the start. In this process, the time and effort required for the project (which has become rather bloat­ed in the mean­time) is being planned and esti­mat­ed. This is then com­pared with an assumed busi­ness value.

The bet­ter the rela­tion­ship between effort and val­ue, the high­er the prob­a­bil­i­ty of approval, which often leads to under­es­ti­mat­ed effort and risk and to over­es­ti­mat­ed and embell­ished busi­ness val­ue. After all, the project in which so much time has already been invest­ed for inves­ti­ga­tion and eval­u­a­tion should also be imple­ment­ed (which, despite all ratio­nal­i­ty in the analy­sis, is not very ratio­nal; see Esca­la­tion of Com­mit­ment).

It is fun­da­men­tal­ly the con­fu­sion between effec­tive­ness and effi­cien­cy that stands between doing the right things and doing things right. There is sure­ly noth­ing quite so use­less as doing with great effi­cien­cy what should not be done at all.

Peter Druck­er (1963) Man­ag­ing for Busi­ness Effec­tive­ness. p. 53 – 60.

After all, the val­ue, i.e. the expect­ed impact, did mat­ter at the time of approval. Lat­er, it quick­ly fades into the back­ground. This is nei­ther an acci­dent nor an inabil­i­ty of the staff car­ry­ing out the work, but rather there is a method in it. And this method has its ori­gin in Tay­lorism: First, one ana­lyzes and plans and this analy­sis con­sti­tutes the basis for a deci­sion (by the management).

Once this deci­sion has been made, the plan is ready for imple­men­ta­tion. From this point on, the unques­tioned assump­tion is that a time­ly imple­men­ta­tion of the agreed deliv­ery results also brings the expect­ed val­ue and shows the expect­ed impact. There­fore, the focus is on exe­cu­tion and deliv­ery and the resources required for this. The val­ue is reviewed at the end of imple­men­ta­tion if at all.

Agile Organizations Try, Inspect & Adapt

Work­ing soft­ware is the pri­ma­ry mea­sure of progress.

Prin­ci­ples behind the Agile Manifesto

Agili­ty is essen­tial­ly based on short feed­back loops. For this rea­son, in Scrum, for instance, there is a poten­tial­ly ship­pable prod­uct incre­ment at the end of each sprint. This allows the assumed impact to be checked after each sprint. In agile com­pa­nies like Spo­ti­fy and Ama­zon, the teams also do this by per­form­ing A/B tests live with their users again and again, i.e. they show some of the cus­tomers the new or mod­i­fied fea­ture and some the pre­vi­ous one and then eval­u­ate the impact.

How­ev­er, this requires that every­one is clear about what impact is desired at the moment. Objec­tives & Key-Results, for exam­ple, are use­ful for this ori­en­ta­tion, describ­ing in a well-struc­tured way on sev­er­al lev­els which goals are cur­rent­ly being pur­sued (Objec­tives) and how one can mea­sure whether one is approach­ing them (Key-Results). With this knowl­edge, each team can align itself to the objec­tives and eval­u­ate the impact of its work.

After Objec­tives & Key-Results, Spo­ti­fy has switched 2016 to its own frame­work DIBB, which stands for the chain of deduc­tion “Data > Insight > Belief > Bet”. In the pic­ture above, the feed­back loop is cru­cial again. Accord­ing­ly, every bet has a “suc­cess met­rics” sec­tion in its two-page descrip­tion, as Hen­rik Kniberg describes in his blog post and the slides linked in it. In order to sup­port this Spo­ti­fy (like many data-dri­ven agile com­pa­nies) con­stant­ly col­lects data on user behav­ior in order to gen­er­ate new insights and to deduce or check beliefs and bets in short cycles (at com­pa­ny lev­el every quar­ter and below cor­re­spond­ing­ly faster).