Arseni Mourzenko
Founder and lead developer
July 16, 2015
Tags: thoughts 6 short 50 management 34 agile 10

Hu­man be­ings want to con­trol every­thing. Their lives, oth­er peo­ple, things around them, events which can af­fect them in any way. The il­lu­sion of con­trol gives them cer­tain­ty, the feel­ing of or­der, the im­pres­sion that the world around them will some­how fol­low the rules, their rules.

And so we cre­ate plans, sched­ules, dead­lines, poli­cies, guide­lines. We think that those mea­sures will give us more con­trol, or at least a bet­ter vis­i­bil­i­ty of the world around us. Pro­ject man­agers do that to. Would it be through Gantt charts or week­ly meet­ings, they think that they are ac­tu­al­ly able to pre­dict some­thing and, ul­ti­mate­ly, to con­trol pre­cise­ly the flow, the re­al­iza­tion of a pro­ject.

In prac­tice, we can­not even con­trol a thing as mun­dane as ar­riv­ing at work for a giv­en time. What if you tear your shoelace? What if there is a jam on the road? Or maybe the door of your garage is sim­ply blocked? Maybe your child is sick and there is no­body else to take care of her? Or maybe the bus dri­ver wasn't look­ing at the road at the mo­ment when you were cross­ing?

Imag­ine a pro­ject as an or­gan­ic struc­ture, its growth be­ing in­flu­enced by the en­vi­ron­ment. Sim­i­lar­ly to a tree, the pro­ject is nev­er the same and adapts to the en­vi­ron­ment, that is to thou­sands of dif­fer­ent fac­tors which can have from min­i­mal to se­vere im­pact on it. In oth­er words, the pro­ject is un­pre­dictable.

De­spite that, we, we who can eas­i­ly be dis­rupt­ed by a sim­ple shoelace, set the dead­lines, plan ahead, and, in essence, be­lieve that we can know how and when the pro­ject will end. While be­ing un­able to pre­dict our own death, we imag­ine that we can pre­dict the death of our pro­jects, de­spite the fact that, again and again, pro­jects die much soon­er than we thought, they die un­ex­pect­ed­ly, they die un­no­tice­ably, or they live for years while we thought that no­body will re­mem­ber them few months af­ter their birth.

This is not sim­ply a busi­ness sus­tain­abil­i­ty ver­sus the com­plex­i­ty the IT per­son­nel faces on dai­ly ba­sis, no; this is a core mis­take com­pa­nies ap­proach soft­ware de­vel­op­ment. Things Tai­ichi Ohno ex­plained near­ly thir­ty years ago in man­u­fac­tur­ing can ex­cel much more with­in the soft­ware in­dus­try, where room for flex­i­bil­i­ty is much high­er com­pared to man­u­fac­tur­ing, but this is only one of the as­pects which is mis­un­der­stood by many soft­ware com­pa­nies. A much more sub­stan­tial change re­sides in the ap­proach of the no­tion of con­trol.

Un­til con­trol is the top pri­or­i­ty, jus­ti­fied as a re­quire­ment for bet­ter vis­i­bil­i­ty, adapt­abil­i­ty is moved to the sec­ond plan, while it is specif­i­cal­ly the adapt­abil­i­ty which is cru­cial for every team. Like in war, plan­ning ahead is key. Like in war, from the first en­counter of the en­e­my, you must adapt the plan to the cir­cum­stances.

Busi­ness is war. Faster, more flex­i­ble teams have bet­ter chances to sur­vive. They built the prod­uct with changes in mind, and they are ready to take what­ev­er the real world will throw at them, and to use it at their ad­van­tage. In­stead, rigid teams where con­trol is every­thing can­not stand the con­stant­ly chang­ing cir­cum­stances, and will in­evitably lose the bat­tle.

Man­u­fac­tur­ing, and oth­er in­dus­tries in gen­er­al, usu­al­ly can't af­ford such flex­i­bil­i­ty. They have con­sid­er­able pri­or costs, which in­volves in­vest­ment, which, in turn, in­volves ROI, and so plans, sched­ules, dead­lines, poli­cies and guide­lines. In soft­ware in­dus­try, any pro­ject can start small, with usu­al­ly pri­or costs of sev­er­al hun­dreds of dol­lars in­stead of hun­dreds of thou­sands.

Start small. Fail fast. Move on.

You don't need to con­trol the pro­ject. You need to adapt it. Don't plan ahead, but do what is need­ed to do to en­sure that the pro­ject will be mal­leable enough to face the changes.

You don't need to avoid fail­ure. Em­brace it. Learn from it. And then, start over, move on.

Agili­ty is ex­act­ly about that. Ag­ile pro­ject start small: there is not much to de­liv­er at the first it­er­a­tion, af­ter a week of work. They fail fast: every block­ing is­sue is no­ticed in the worst case at the end of an it­er­a­tion. Fi­nal­ly, they move on, by it­er­at­ing, and mak­ing it­er­a­tions as short as pos­si­ble.

Con­trol, in those pro­jects, doesn't make sense. Changes are so fre­quent that any plan ahead fails with­in hours or days. As soon as the team knows what to do next and where the pro­ject is go­ing, they can bring the pro­ject shape, day af­ter day. Day af­ter day, they will de­liv­er ad­di­tion­al val­ue to the cus­tomers; and in soft­ware de­vel­op­ment busi­ness, this is the only met­ric which ac­tu­al­ly mat­ters.