The Three Pillars of Agility: Empiricism, Empowerment and Ownership

There are many agile meth­ods and frame­works, but what is the essence of agili­ty? And how can one describe it with­out resort­ing to the ter­mi­nol­o­gy of Scrum & Co? At first glance, the Man­i­festo for Agile Soft­ware Devel­op­ment seems like a good start­ing point for answer­ing these ques­tions. How­ev­er, propo­si­tions like “Respond­ing to change over fol­low­ing a plan” are not very action­able dec­la­ra­tions of intent. The prin­ci­ples behind the man­i­festo are much more con­crete when they, for instance, demand to “deliv­er work­ing soft­ware fre­quent­ly, from a cou­ple of weeks to a cou­ple of months, with a pref­er­ence to the short­er timescale.” How­ev­er, in their vari­ety of cov­ered aspects, these prin­ci­ples do not pro­vide a coher­ent pic­ture of what agili­ty is about at its core.

Now, what can be con­sid­ered essen­tial for agili­ty? First, and most con­spic­u­ous­ly, because it is the antithe­sis of the pre­vail­ing plan-dri­ven ana­lyt­i­cal approach, it is undoubt­ed­ly empiri­cism: Agile means empir­i­cal explo­ration of solu­tions and mar­kets in a com­plex envi­ron­ment. Sec­ond­ly, agili­ty con­sis­tent­ly relies on empow­er­ing the teams, who con­stant­ly ques­tion and improve their work­ing meth­ods and work process­es in the best tra­di­tion of lean man­age­ment. And third, agili­ty means own­er­ship and team­work. Agili­ty aban­dons small-scale exper­tise, which entails many han­dovers for any non-triv­ial devel­op­ment, favor­ing small, pow­er­ful, cross-func­tion­al teams that take joint respon­si­bil­i­ty for their prod­uct and devel­op it fur­ther with deliv­er­ies at short intervals.

Empiricism

Empiri­cism comes from the Greek εμπειρία (empeiría), which means expe­ri­en­tial knowl­edge. Empiri­cism is the attempt to under­stand causal rela­tion­ships through the sys­tem­at­ic col­lec­tion of expe­ri­ence. Empiri­cism, there­fore, works with the­o­ret­i­cal assump­tions about the world for­mu­lat­ed as hypothe­ses and test­ed or dis­proved by appro­pri­ate exper­i­ments. In con­trast to ana­lyt­ics (from the Greek ἀναλύειν ana­lyein ‘to resolve’), the sys­tem under inves­ti­ga­tion is not bro­ken down into its con­stituent parts, but rather the inter­re­la­tion­ships are con­sid­ered on a large scale. The human brain, for exam­ple, can be stud­ied ana­lyt­i­cal­ly and thus under­stood as a com­pli­cat­ed and dynam­ic net­work of neu­rons. Still, our mind’s pat­terns of thought and bias­es can only be demon­strat­ed empir­i­cal­ly through appro­pri­ate psy­cho­log­i­cal experiments.

Agili­ty starts with hon­est­ly admit­ting the uncer­tain­ty and com­plex­i­ty of the project and its envi­ron­ment. The log­i­cal response to this com­plex­i­ty is then to work more empir­i­cal­ly and less ana­lyt­i­cal­ly and plan-dri­ven. Every pri­or­i­ti­za­tion, every sprint goal, and every sprint plan­ning is thus actu­al­ly a hypoth­e­sis about an expect­ed cus­tomer ben­e­fit. Rea­son­able hypothe­ses will prove them­selves; bad ones will be refut­ed by real­i­ty. That is why agili­ty means more than just deliv­er­ing new incre­ments of the prod­uct. It is essen­tial to sys­tem­at­i­cal­ly col­lect data on the impact of the deliv­ery to con­firm or dis­prove the asso­ci­at­ed hypothesis.

An empir­i­cal-sci­en­tif­ic sys­tem must be able to fail from experience.

Karl Pop­per, Logik der Forschung 17

Empowerment

Agili­ty is based on lean man­age­ment and can be under­stood as apply­ing the five lean prin­ci­ples to soft­ware devel­op­ment. Its focus is on the rapid deliv­ery of cus­tomer val­ue through work­ing soft­ware. And the opti­mal flow for this is cre­at­ed in the inter­dis­ci­pli­nary self-orga­nized team, which cov­ers the com­plete val­ue stream from idea to oper­a­tion of the software. 

In lean man­age­ment, all employ­ees are encour­aged and empow­ered to ques­tion process­es and improve them con­tin­u­ous­ly. This empow­er­ment of “ordi­nary” work­ers, and thus the focus on the human fac­tor, rep­re­sents a sig­nif­i­cant depar­ture from the pre­vi­ous­ly dom­i­nant Tay­lorist mind­set: Those who work in the process, rather than their man­agers, know the process­es best and are con­se­quent­ly the ones who can best opti­mize them. Tai­ichi Ohno, the inven­tor of the Toy­ota Pro­duc­tion Sys­tem, puts it this way:

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

Tai­ichi Ohno

This empow­er­ment is at the heart of agile. It is not the inge­nious man­ag­er but self-orga­niz­ing teams that cre­ate the best archi­tec­tures, require­ments, and designs, as is unequiv­o­cal­ly stat­ed in the prin­ci­ples behind the man­i­festo for agile soft­ware devel­op­ment. And in the best tra­di­tion of lean man­age­ment, these teams are also respon­si­ble for con­tin­u­ous­ly improv­ing their process­es: “At reg­u­lar inter­vals, the team reflects on how to become more effec­tive, then tunes and adjusts its behav­ior accordingly.”

Ownership

Far too often, agile meth­ods and Scrum, in par­tic­u­lar, are reduced to opti­miz­ing work­flows. This mis­un­der­stand­ing is based on the assump­tion that one can orga­nize the exist­ing work dif­fer­ent­ly and bet­ter under oth­er­wise unchanged con­di­tions to become faster or more adapt­able. How­ev­er, this mech­a­nis­tic view com­plete­ly ignores that agili­ty is actu­al­ly about team­work and own­er­ship. Meth­ods such as Scrum only give the team the frame­work and struc­ture to focus on its prod­uct instead of a bunch of inco­her­ent tasks.

A team is not a group of peo­ple that work togeth­er. A team is a group of peo­ple that trust each other.

Simon Sinek

Agili­ty means learn­ing col­lec­tive­ly through exper­i­men­ta­tion and con­tin­u­ous­ly improv­ing both the col­lab­o­ra­tion and the prod­uct as a result. How­ev­er, this learn­ing only works if the peo­ple involved can act as a team and not just work togeth­er coin­ci­den­tal­ly this week because spe­cif­ic exper­tise is in demand in this par­tic­u­lar phase of the project. In a cer­tain sense, belong­ing to a team and shared respon­si­bil­i­ty for a prod­uct is more crit­i­cal to agili­ty than exper­tise, which flour­ish­es in most func­tion­al­ly fine-tuned orga­ni­za­tions. Of course, agili­ty still appre­ci­ates and requires expert knowl­edge, but rather where the val­ue is cre­at­ed and not in the expert silo.

Pho­to by Mitchell Luo on Unsplash.