The Dead End of the Agile Transformation

Copy­ing Spo­ti­fy or sim­ply imple­ment­ing any oth­er blue­print of an agile orga­ni­za­tion is a fun­da­men­tal mis­take. Not because the mod­els them­selves were poor, but because imple­ment­ing a mod­el of an agile orga­ni­za­tion that has been cho­sen or devel­oped by a few man­agers, experts or con­sul­tants from top to bot­tom con­tra­dicts the essen­tial prin­ci­ple of self-orga­ni­za­tion. Agile orga­ni­za­tions are always emer­gent in the sense that they result from the coop­er­a­tion of self-orga­niz­ing teams towards a com­mon vision and are con­stant­ly evolv­ing. There­fore, it is cru­cial for a sus­tain­able agile trans­for­ma­tion to with­stand the pres­sure to deliv­er short-term suc­cess­es and to empa­thet­i­cal­ly and con­fi­dent­ly give peo­ple the space and time to learn and grow togeth­er. As tempt­ing as blue­prints and their large-scale imple­men­ta­tion may look, it is pre­cise­ly this that leads the agile trans­for­ma­tion into a dead end.

The essen­tial and most impor­tant com­po­nent in an agile orga­ni­za­tion is the self-orga­niz­ing team. This is what you find in the prin­ci­ples behind the agile man­i­festo. And this auton­o­my of the teams is also at the core of Spo­ti­fy. The Spo­ti­fy mod­el is based on exact­ly this fun­da­men­tal prin­ci­ple and is there­fore suc­cess­ful. Self-orga­ni­za­tion is the key, but also the chal­lenge. For the trans­for­ma­tion of a hier­ar­chi­cal orga­ni­za­tion into an agile orga­ni­za­tion of self-orga­nized teams any­way, but also and still for Spotify:

What is the best thing about work­ing at Spo­ti­fy? What is the most chal­leng­ing thing about work­ing at Spo­ti­fy? The answer for both ques­tions is the same: Autonomy.
Joakim Sundén

Self-orga­ni­za­tion with a sin­gle team or with only a few teams is not a chal­lenge. It only becomes dif­fi­cult when the num­ber of teams increas­es. This was also the case for Spo­ti­fy, where the engi­neer­ing team grew from 10 to 300 peo­ple between 2010 and 2013. And that’s exact­ly where this Spo­ti­fy mod­el emerged, which is now so often copied. But also some­thing else was devel­oped: “Agile à la Spo­ti­fy”, a descrip­tion of what this agile exact­ly means at Spo­ti­fy. And it starts with: 

Con­tin­u­ous improve­ment: At Spo­ti­fy, part of my work is to look for ways to con­tin­u­ous­ly improve, both per­son­al­ly, and in the wider organisation.
Agile à la Spotify

So the respon­si­bil­i­ty for the Spo­ti­fy mod­el clear­ly falls to those who have to work with it and in it. Every­one is con­tin­u­ous­ly work­ing to improve the orga­ni­za­tion at Spo­ti­fy. This is the log­i­cal and nec­es­sary con­se­quence of the prin­ci­ple of self-orga­niz­ing teams. Admit­ted­ly, any form of orga­niz­ing the coop­er­a­tion of numer­ous teams is a restric­tion of the free­dom of the indi­vid­ual team. How­ev­er, this is nec­es­sary to make the orga­ni­za­tion and its prod­uct a joint suc­cess. One person’s free­dom ends where anoth­er person’s free­dom begins (Immanuel Kant). The fine but deci­sive dif­fer­ence is that these restric­tions of the indi­vid­ual team’s free­dom result from the coop­er­a­tion of the teams and are decid­ed by the teams them­selves, and the teams are allowed to and trust­ed to do exact­ly that.

Trust: At Spo­ti­fy we trust our peo­ple and teams to make informed deci­sions about the way they work and what they work on.
Agile à la Spotify

The task of lead­er­ship in this agile trans­for­ma­tion is there­fore not to choose the best mod­el of an agile orga­ni­za­tion or to design a new and indi­vid­ual mod­el and then roll it out from top to bot­tom. This seri­ous­ly vio­lates the cen­tral prin­ci­ple of self-orga­ni­za­tion and keeps peo­ple and teams depen­dent exact­ly where they should act autonomous­ly. The actu­al task is rather to cre­ate a set­ting in which such an orga­ni­za­tion­al mod­el grad­u­al­ly emerges from the coop­er­a­tion of self-orga­niz­ing teams. This is a process of joint learn­ing that can­not be accel­er­at­ed with blue­prints. If you try it any­way, you just intro­duce a new orga­ni­za­tion­al mod­el and con­duct a trans­for­ma­tion, but agile will be nei­ther one. 

Ser­vant lead­er­ship: At Spo­ti­fy man­agers are focused on coach­ing, men­tor­ship, and solv­ing imped­i­ments rather than telling peo­ple what to do.
Agile à la Spotify

Share This Post


Vijay 13. February 2019 Reply

I gen­er­al­ly enjoy arti­cles on Agile on this web­site, but I tend to dis­agree that using any blue­print or frame­work will lead to a dead end. At the very least it seems, a blue print or enter­prise agile frame­work can be a start­ing point in Agile Trans­for­ma­tion. How else will teams use/adherence to EA, solu­tion archi­tec­ture, secu­ri­ty guide­lines, reg­u­la­to­ry com­pli­ance issues etc. A frame­work like SAFe or LaSS etc can also pro­vide logis­tics of coor­di­nat­ing work between Agile teams.

Marcus Raitner 15. February 2019 Reply

Maybe I was­n’t pre­cise enough. Not the mod­els them­selves are dead ends. In fact I con­sid­er them also as a good start­ing point (LeSS more than SAFe, but this is a dif­fer­ent sto­ry). The point I tried to make was, that imple­ment­ing those mod­els as a giv­en blue­print in a top-down fash­ion will not encour­age self-orga­ni­za­tion in the sense of this quote:

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

John Heintz 21. February 2019 Reply

Some shared and coor­di­na­tion stan­dards do need to be glob­al­ly set. Think “dri­ve on the right side of the road” types of con­straints. These how­ev­er are very sticky and every­one will live with them a long time. Think the yards vs meters. Be spar­ing when cre­at­ing a glob­al stan­dard and involve bot­tom up input and under­stand­ing when doing so.

Marcus Raitner 21. February 2019 Reply

Absolute­ly! I don’t object to glob­al stan­dards. What I object to is the way such stan­dards are imposed from top to bot­tom. This is best sum­ma­rized by this quote:

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

Leave a Reply