Agile: Asking the Right Questions

How can we become (more) agile? Many of my con­ver­sa­tions begin with this ques­tion. So some­one wants to work dif­fer­ent­ly, wants to become agile or more agile. The expec­ta­tion is most­ly to be taught new and bet­ter meth­ods to do their job in a bet­ter way. But this ques­tion of how to do agile almost always does­n’t go deep enough. That’s why I usu­al­ly answer it with a few clar­i­fy­ing ques­tions. Which prob­lem should the desired agile meth­ods actu­al­ly solve? What do you want to achieve? Why do you want to work agile? And final­ly, what is the sub­ject, the prod­uct, on which you want to work agile? But one after the oth­er.

Why: The Motivation

He who has a why to live for can bear almost any how.

Friedrich Niet­zsche (abbre­vi­at­ed by Vik­tor Fran­kl)

Unfor­tu­nate­ly, it is often not clear which goals should be achieved with those shiny agile meth­ods. At least not to those who come to me with their ques­tions. They have received the assign­ment from a high­er author­i­ty and are now try­ing their best. This can­not be blamed on them, but on their prin­ci­pals. There is a good rea­son why Netflix’s Cul­ture State­ment states: Con­text over Con­trol. But that is actu­al­ly anoth­er top­ic

The leader’s job at every lev­el is to set clear con­text so that oth­ers have the right infor­ma­tion to make gen­er­al­ly great deci­sions.

Net­flix Cul­ture State­ment

Some­times it turns out dur­ing the clar­i­fi­ca­tion of the moti­va­tion that there is only this one: “Oth­ers are doing it as well”. Of course, you can do that, but you should­n’t. Soon­er or lat­er the dis­cus­sion will lead to the insight that some­how peo­ple should work faster and more effi­cient­ly. The agile meth­ods are seen as a kind of con­cen­trat­ed feed for the employ­ees in order to increase per­for­mance. At this point I usu­al­ly explain this great pic­ture of Hen­rik Kniberg:

Source: Hen­rik Kniberg

This illus­tra­tion shows that the essence of agili­ty is short feed­back cycles. At short inter­vals, usable prod­uct incre­ments are deliv­ered and the find­ings from the actu­al use of these inter­me­di­ate prod­ucts then influ­ence the next steps (this is why the pic­ture in the low­er sequence shows a con­vert­ible and not a lim­ou­sine, because on the way it was learned that the cus­tomer loves fresh air). Agili­ty real­ly accel­er­ates … learn­ing!

These short learn­ing cycles are use­ful and nec­es­sary when­ev­er the goal is unclear and the path to it uncer­tain. The right moti­va­tion for agile work there­fore always has some­thing to do with uncer­tain­ty and com­plex­i­ty and thus the desire for more flex­i­bil­i­ty and adapt­abil­i­ty. If a known and planned result is to be reached only more effi­cient­ly, agile meth­ods are the wrong tool no mat­ter how many oth­ers are doing it. The most effi­cient way to design a con­vert­ible is cer­tain­ly not to use a skate­board, a scoot­er, a bicy­cle and a motor­cy­cle as inter­me­di­ate solu­tions.

That’s where the dis­cus­sion might end. Most of the time, how­ev­er, I con­tin­ue it because cer­tain­ty is decep­tive. Per­haps it is clear here and now that and how a con­vert­ible should be built. How­ev­er, it is by no means fore­see­able what will hap­pen on the way and cer­tain­ly not whether in the end (and this is usu­al­ly years in the future) the cus­tomer still wants a con­vert­ible and if so, if he real­ly wants the planned one. And maybe the motor­cy­cle or the bicy­cle would have been suf­fi­cient. This uncer­tain­ty, which is most­ly denied in a plan-dri­ven approach, usu­al­ly gives nev­er­the­less a great moti­va­tion to become more agile.

What: The Product

Now that the why is suf­fi­cient­ly clear, the ques­tion aris­es on what we should work in an agile way. In the worst case this is the work of a com­mit­tee or some­thing sim­i­lar. Don’t get me wrong. I wel­come the fact that deci­sion-mak­ers are expos­ing them­selves to agile meth­ods and want to try them out for them­selves, but a com­mit­tee is not a team work­ing on a joint prod­uct. It’s a group that makes deci­sions togeth­er. The mem­bers do some­thing togeth­er 5% of their time, name­ly mak­ing deci­sions, and 95% of their time they do their actu­al work in their respec­tive silos.

So let’s skip the agiliza­tion of the com­mit­tees (in the course of a larg­er trans­for­ma­tion, the goal would be to elim­i­nate them any­way and make deci­sions again where the infor­ma­tion is, name­ly with the teams) and turn to the case that a group of peo­ple joint­ly pro­duces some­thing mean­ing­ful for the orga­ni­za­tion (even bet­ter, of course, for the cus­tomer!). This could be soft­ware, but it could also be brand com­mu­ni­ca­tion or audit reports.

In our func­tion­al­ly divid­ed orga­ni­za­tions, how­ev­er, it is usu­al­ly the case that the desire for more agili­ty aris­es only in a small sec­tion of the entire val­ue chain. There might be, for instance, the team that devel­ops soft­ware for elec­tron­ic con­trol units that wants to become more agile and wor­ries about scal­ing and coor­di­na­tion. So far, so good.

If one then looks at the path from the require­ment to ver­i­fy­ing the soft­ware on the elec­tron­ic con­trol unit in the vehi­cle, it becomes evi­dent that this team is only a small part of a much longer chain of han­dovers (and this func­tion­al divi­sion into spe­cial­ist func­tions is well jus­ti­fied in some ways … at least it had some jus­ti­fi­ca­tion an ben­e­fits in the past). The idea first becomes a con­cept, which then goes to an archi­tect and then is ver­i­fied by a data mod­el­ing expert. Then, the soft­ware is cre­at­ed by this devel­op­ment team from the pre­vi­ous­ly approved con­cept. How­ev­er, it’s far from being fin­ished. First the soft­ware has to be deployed onto the con­trol unit and then this unit has to be built into a vehi­cle and only then the feed­back loop is closed and learn­ing hap­pens. Klaus Leopold uses this beau­ti­ful and unfor­tu­nate­ly not so unre­al­is­tic pic­ture to illus­trate this prob­lem:

Source: Klaus Leopold

So the much more inter­est­ing ques­tion at this point is how this feed­back cycle can be short­ened end-to-end and thus learn­ing can be accel­er­at­ed, because that is all that mat­ters in terms of agili­ty. The already halfway agile devel­op­ment team is def­i­nite­ly not the bot­tle­neck. Instead, agile and inter­dis­ci­pli­nary team­work is required across the bound­aries of silos along the entire val­ue chain. How­ev­er, this is not intend­ed and is not always wel­comed by the respec­tive lords of the indi­vid­ual silos. There­fore, with the why and what it usu­al­ly starts to get real­ly inter­est­ing, the how is always just the sec­ond step.

A pru­dent ques­tion is one-half of wis­dom.

Fran­cis Bacon

Stay Current!

You nev­er want to miss an arti­cle on my blog again? With our Newslet­ter you will receive the lat­est arti­cles in your inbox once a week.

Leave a Reply