Aut­hors: Frit­jof Schmidt, Colo­gne; Lukas Römer, Berlin



As most peop­le working in the busi­ness con­text nowa­days know, Agi­le metho­do­lo­gy has its roots in soft­ware deve­lo­p­ment. The under­ly­ing mind­set is most pro­mi­n­ent­ly repre­sen­ted by the Agi­le Mani­festo (Scrum­Al­li­an­ce, n.d.), which was crea­ted in 2001 by thought lea­ders in soft­ware deve­lo­p­ment, who were aiming to enact a new way of deve­lo­ping app­li­ca­ti­ons for the busi­ness use.

The main pro­blem they were try­ing to sol­ve was the delay bet­ween busi­ness users indi­ca­ting a need and the deli­very of soft­ware pro­mi­sing to cater for that need. Deve­lo­p­ment just took too long and was not fle­xi­ble enough to ulti­mate­ly meet the expec­ta­ti­ons of end users.

The solu­ti­on of Agi­le metho­do­lo­gy and its frame­works (such as SCRUM, LeSS, SAFe) is try­ing to enact a sys­tem of peop­le, pro­ces­ses and struc­tures, which allows for a maxi­mum of user centri­ci­ty and gre­at ways of adap­ting to new infor­ma­ti­on and needs. It only makes sen­se that after we have seen espe­cial­ly tech­no­lo­gy com­pa­nies having gre­at suc­cess with this metho­do­lo­gy during the last years, other indus­tries and depart­ments are try­ing to adopt this way of working to reap its bene­fits as well.

But does it always make sen­se to work Agi­le? Keep in mind that the metho­do­lo­gy was brought tog­e­ther for soft­ware deve­lo­p­ment, which is a crea­ti­ve pro­cess (in the sen­se that some­thing new is being crea­ted). In this arti­cle, we will try to out­line what envi­ron­ments best bene­fit from working in an Agi­le way and in which sce­n­a­ri­os it pro­ves to be more effi­ci­ent to stick to more tra­di­tio­nal pro­ject manage­ment methods, e.g. a line­ar PMLC model (Flynn, 2007).

Uncertainty and complexity — the what and how

First, let us look at what uncer­tain­ty and com­ple­xi­ty mean in the con­text of pro­ject manage­ment. This is based on the VUCA stra­te­gic lea­ders­hip theo­ries (VUCA-World, n.d.) and the Cyne­fin frame­work (Snow­den & Boo­ne, 2007).

Uncer­tain­ty can be descri­bed best by the amount of know­ledge you have about what the final out­co­me of the pro­ject will look like. This is influ­en­ced by a mul­ti­tu­de of fac­tors, such as the degree of inno­va­ti­on, the amount of fea­tures of the final pro­duct, the envi­ron­ment in which the pro­duct will be used, as well as the align­ment on the needs the users of the out­co­me and the skills you and your team will bring into the pro­ject (more on the­se two down below).

Com­ple­xi­ty is an inna­te cha­rac­te­ris­tic of an out­co­me and descri­bes the amount of know­ledge you have on the inter­de­pen­den­ci­es bet­ween sin­gle ele­ments of your out­co­me. Com­ple­xi­ty rises with more (non-line­ar) inter­de­pen­den­ci­es bet­ween sin­gle ele­ments. High com­ple­xi­ty makes it hard for us to under­stand how a sys­tem (i.e. out­co­me) will react if we chan­ge something.

The­re­fo­re, both uncer­tain­ty and com­ple­xi­ty play a lar­ge role when thin­king about adop­ting an Agi­le way of working. The more uncer­tain­ty the­re is, the more important it will be for you to chan­ge the initi­al plan of the final out­co­me as you will face more sur­pri­ses (e.g. sta­ke­hol­ders chan­ging their minds, new infor­ma­ti­on about com­pe­ti­tors on the mar­ket). The more com­ple­xi­ty the­re is, the more need for you to test and obser­ve the system’s reaction.

Agi­le frame­works are desi­gned for com­plex and uncer­tain environments.

Vice ver­sa, think about the pro­cess of buil­ding an out­co­me which is rather simp­le and strict­ly defi­ned, e.g. a legal requi­re­ment: You will con­stant­ly ask sta­ke­hol­ders about their needs. And you will not face many sur­pri­ses during the pro­duc­tion pro­cess. Thus, in sta­ble and simp­le envi­ron­ments the expe­ri­men­tal style of Agi­le methods might be a was­te of time.

Stakeholder involvement

Uncer­tain­ty is also a func­tion of sta­ke­hol­der invol­ve­ment: the more sta­ke­hol­ders the more uncer­tain­ty. This is becau­se sta­ke­hol­ders of a pro­ject will have to agree on a joint goal and with dif­fe­rent per­spec­ti­ves on what the goal is, more align­ment and cor­re­spon­ding rea­lign­ment will be necessa­ry. Howe­ver, having many sta­ke­hol­ders and the­re­fo­re many per­spec­ti­ves also has a very posi­ti­ve impact on the final out­put, as you will be able to take their needs and expec­ta­ti­ons towards your pro­ject into account.

The Agi­le mind­set is stron­gly cen­te­red around user and sta­ke­hol­der centri­ci­ty, mea­ning that frame­works, which make use of Agi­le metho­do­lo­gy incor­po­ra­te many pro­ces­ses to align com­plex requi­re­ments with a bunch of sta­ke­hol­ders. This also inclu­des making sure that you get regu­lar feed­back from your sta­ke­hol­ders on the cur­rent sta­tus of your out­co­me of the pro­ject. This makes agi­le frame­works a good choice for com­plex pro­jects with a lot of sta­ke­hol­der involvement.

On the other side this makes Agi­le metho­do­lo­gy not the first choice for pro­jects with rather low sta­ke­hol­der invol­ve­ment and simp­le requi­re­ments. Even if you poten­ti­al­ly have a lot of end users of your final out­co­me, you are not able to reach out to them and ask them for regu­lar feed­back. As a result, the usa­ge of Agi­le metho­do­lo­gy might not be opti­mal as the who­le pro­cess is desi­gned around get­ting this feedback.

Team setup

We know the chal­len­ge from the past deca­des of soft­ware deve­lo­p­ment to inte­gra­te “Busi­ness” and “Deve­lo­pers” des­pi­te acting in silos.

The Agi­le mani­festo is rather expli­cit about the fact that soft­ware deve­lo­pers and busi­ness users have to work tog­e­ther in one team to be suc­cess­ful. Many frame­works adhe­re to this princip­le by advi­sing to crea­te “cross-func­tio­n­al” teams – a term which has been wide­ly adop­ted in the realms of busi­ness. But what does it mean in the con­text of Agi­le pro­ject management?

Simi­lar to the idea that mul­ti­ple sta­ke­hol­ders will impro­ve the final result by brin­ging in their dif­fe­rent per­spec­ti­ves, a mix­tu­re of com­pe­ten­ci­es in a team is belie­ved to be more bene­fi­cial in situa­tions in which fun­da­men­tal chan­ges occur. In tru­ly Agi­le teams, peop­le with all the com­pe­ten­ci­es necessa­ry for the pro­ject work tog­e­ther on a dai­ly basis, allowing for plu­ra­lism of per­spec­ti­ves during plan­ning and speed in imple­men­ta­ti­on. Silos are not allo­wed in Agi­le pro­jects as they impo­se a major thre­at to the speed of pro­ject progress.

When it comes to pro­ject set­ups, diver­se teams work best in Agi­le envi­ron­ments. It allows them to maxi­mi­ze their dif­fe­rent com­pe­ten­ci­es. The­re­fo­re, with a high­ly diver­si­fied pro­ject team it makes more sen­se to set­up agi­le methods.

On the other hand, if you have a small set of com­pe­ten­ci­es nee­ded for suc­cess of the pro­ject you will not need the pro­ces­ses, mee­tings and tools sug­gested by Agi­le frame­works. Even if you have a lot of pro­ject mem­bers, if they are very simi­lar in their points of view and pro­fes­sio­nal expe­ri­ence, the work is more easi­ly orga­ni­zed in dif­fe­rent work streams and the­re is poten­ti­al for less dis­cus­sion points.

Project controlling and KPI

The Agi­le frame­works pro­vi­des signi­fi­cant auto­no­my to the team sin­ce the out­co­me is not exact­ly defi­ned right from the begin­ning by the busi­ness. What does this mean for the finan­cial respon­si­bi­li­ty of the deve­lo­p­ment pro­ject? How com­ple­te is the auto­no­my of the deve­lo­p­ment team?

In this case, it is worthwhile to take ano­t­her look at the ori­gi­nal con­di­ti­ons of the Agi­le metho­do­lo­gy: a high­ly com­pe­ti­ti­ve envi­ron­ment whe­re suc­cess and fail­u­re are clo­se­ly rela­ted. Both have an immedia­te impact on the play­ers – be it through growth and bankrupt­cy or respec­tively sim­ply through hire and fire. 

Today we are intro­du­cing Agi­le in many pla­ces in the cor­po­ra­te envi­ron­ment. The teams are rela­tively well protected.

Remem­ber the magic tri­ang­le of bud­get, qua­li­ty and scope. While the scope is set in a non-agi­le pro­ject, it is obvious­ly not pos­si­ble in an agi­le pro­ject. Thus, the bud­get for the sin­gle, incre­men­tal deli­ver­a­bles must be set even more clear­ly in order to not lea­ve the deve­lo­p­ment team out of respon­si­bi­li­ty. It is less a jus­ti­fi­ca­ti­on for tracking “Agi­le KPI” but a blank necessity.


The decisi­on whe­ther to con­duct a pro­ject in an Agi­le fashion main­ly revol­ves around the anti­ci­pa­ted uncer­tain­ty and com­ple­xi­ty of the pro­ject. In most cases, the sta­ke­hol­der invol­ve­ment and team set­up are a con­se­quence of that, but act as a good pro­xy to esti­ma­te the uncer­tain­ty or complexity.

Agi­le pro­ject manage­ment is some­ti­mes advo­ca­ted as the new and bet­ter solu­ti­on for con­duc­ting pro­jects. Even though it offers a lot of bene­fits and is well equip­ped to work wit­hin envi­ron­ments, which are pro­ne to a lot of chan­ge (like many envi­ron­ments nowa­days), working with Agi­le methods comes at a cost. Adhe­ring to the­se pro­ces­ses is resour­ce inten­si­ve and that effort will only be off­set if you can make use of the incre­a­sed focus on team and sta­ke­hol­der align­ment by impro­ving the qua­li­ty of your final outcome.

Also, we stron­gly advi­se to work tog­e­ther with peop­le who know both Agi­le methods as well as tra­di­tio­nal methods if you plan to work Agi­le to find the appro­pria­te cour­ses of actions in each situa­ti­on and not sim­ply fol­lowing Agi­le methods. We need to keep in mind, that it impo­ses a chan­ge to the way peop­le work tog­e­ther and how pro­jects are mana­ged, which makes Agi­le methods a chan­ge pro­ject on its own. An examp­le would be lar­ger com­pa­nies who spend several years on Agi­le trans­for­ma­ti­on pro­jects, ulti­mate­ly trans­forming a good part of how their busi­ness works on a very fun­da­men­tal level.


Scrum­Al­li­an­ce. (n.d.). The Agi­le Mani­festo. Retrie­ved August 13, 2020, from

Snow­den, D. J., & Boo­ne, M. E. (2007). A Leader’s Frame­work for Decisi­on Making. Har­vard Busi­ness Review.‑leaders-framework-for-decision-making

VUCA-World. (n.d.). LEADERSHIP SKILLS & STRATEGIES V U C A world. Retrie­ved August 13, 2020, from

Flynn, T. A. (2007). Inte­gra­ti­on of the pro­ject manage­ment life cycle (PMLC) and the sys­tems deve­lo­p­ment life cycle (SDLC) in acce­le­ra­ted pro­ject efforts: adap­ting pro­ject manage­ment best prac­ti­ces to unre­a­son­ab­le requests. Paper pre­sen­ted at PMI® Glo­bal Con­gress 2007—North Ame­ri­ca, Atlan­ta, GA. New­town Squa­re, PA: Pro­ject Manage­ment Institute.

%d Bloggern gefällt das: