Praksis i agile projekter 15 år efter

Den agile projektledelse blev for alvor introduceret med det agile manifest i år 2000 og har nu haft opmærksomhed i mere end 15 år. Så det er interessant nu at se på, hvordan de agile metoder egentlig håndteres i praksis.

Agile projekter

Artiklen her går i dybden med to vinkler – den ene vinkel ser på, hvordan virksomhederne håndterer agil udvikling, og den anden vinkel ser på, hvordan kontrakter med leverandører om agil udvikling opstilles i praksis.

Agil udvikling skal ikke "oveni"

Håndteringen af agil udvikling i virksomhederne kan vi se på i form af sprogbrugen blandt ledelseseksperter [1] Her er agil vel det nærmeste, vi kan komme buzzword.

Èn af fædrene til det agile manifest, Jeff Sutherland, gør sammen med to andre forfattere status på anvendelsen af den agile tilgang i Harvard Business Review [2] Det er interessant. De kan nemlig se, at den agile tilgang bliver "lagt oveni" traditionel linjeledelse og kontraprincipperne i agil ledelse. Deres observationer fra virksomheder peger på, at ledere sætter gang i talløse initiativer i stedet for at give prioritet til de vigtigste to eller tre projekter. Og så føres de gamle vaner ind i agil projektledelse:

"Linjelederne spreder sig selv og deres bedste folk over alt for mange projekter. Lederne indkalder til mange møder og tvinger deltagerne til at droppe arbejdsopgaver eller sende substitutter. Mange af lederne bliver overdrevent involveret i enkelte gruppers arbejde. De taler mere end de lytter. De fremmer marginale ideer, som teams allerede har sat til side. De omstøder rutinemæssigt agile gruppers beslutninger og lægger nye kontrollag ind for at sikre, at fejl ikke gentages. Med de bedste intentioner undergraver linjeledelser de fordele, som agil udvikling kan bidrage med."

Betingelserne for agil projektledelse

Jeff Sutherland og hans to medforfattere råder til, at ledere docerer agil projektledelse, der hvor det kan give størst værdi.

For det første skal der være de rette vilkår tilstede for agile projekter. Markedet skal have en dynamik og mulighed for at involvere kunder, for at det agile giver mening. Og kun projekter, hvor der virkelig skal arbejdes på tværs af flere funktioner med komplekse problemer, skal den agile metode sættes ind. Agil projektledelse kan anvendes netop hvor vilkårene er tilstede, men, som de gør opmærksom på, er der områder, hvor den agile tilgang ikke passer, som fx salgsbesøg, vedligeholdelsesopgaver, indkøb og bogføring. 

Figur 1. Vilkår for agile projekter, Kilde: Harvard Business Review Maj 2016

Vilkår for agile projekter

Der skal derfor være rette vilkår i organisationen, for at vi kan opnå fordelene ved at arbejde agilt. Jeff Sutherland og hans to medforfattere har med 15 års erfaring nogle væsentlige bud på disse vilkår, og vi kan undgå, at den agile tilgang bare bliver et buzzword i stedet for et bidrag til bedre projekter.

Kontrakter om agil udvikling

Den anden vinkel på det agile i praksis, hvor forskningen begynder at vise interessante nuancer, handler om kontrakter i agil udvikling.

Herhjemme fik vi i 2012 Digitaliseringsstyrelsens kontaktoplæg for agile softwareprojekter K03 som en mulighed for at skabe juridisk grundlag for agil udvikling [3].

Kontaktoplægget betyder, at:

  • kunden får mulighed for at afbryde samarbejdet undervejs, hvis leverancerne ikke lever op til forventningerne
  • kontakten opstiller absolutte krav og øvrige krav (det vi ville kalde „nice-to-have“ og „need-to have“)
  • vederlagsmodellen ikke bliver generel, men kan tilpasses. Kunden skal typisk medvirke dagligt og skal kunne træffe beslutninger hurtigt.

Anvendelsen af K03-kontrakten har ifølge Version2 givet udfordringer [4]. Version2 kan fortælle om et projekt "Datafordeleren", hvor K03 medførte, at der i et projekt med en ramme for anskaffelsesfasen på 7,2 millioner blev anvendt 5,6 yderligere til ekstra juridisk konsulentbistand. Så vi er ikke helt i mål med problemstillingerne omkring underleverandører i agil udvikling.

Flere forskere har forsøgt at afdække problemstillingen. Blandt andet har to finske forskere [5] gennem litteraturstudier og interviews forsøgt at afdække vanskeligheder med agil udvikling. De er kommet frem til, at enten må man sætte megen tid af under indgåelse af kontrakten for at forberede den agile udvikling, eller også må man give kunden mulighed for at afbryde udviklingen midt i projektet. Det passer jo meget godt med de nævnte erfaringer fra K03 i Danmark.

To andre forskere Zijdemans og Stettina [6], fra Leiden University i Holland, er gået lidt dybere i spørgsmålet om kontrakter og har i et intensivt, eksplorativt studie afdækket yderligere nuancer fra praksis omkring agile kontrakter.

Deres resultater er interessante, fordi de i deres interviews får vist, at paletten af kontrakter er meget bred, og at der viser sig et mønster for, hvornår forskellige kontraktelementer bringes i spil.

Det fremgår af deres interviews, at der indgås aftaler fra rene fast-pris-aftaler, over betalinger pr. sprint til kontrakter baseret på omkostninger, "time and material".

Imødegåelse af risici finder sted i tre former:

  1. enten gennem exit-aftaler, hvor kunden kan afbryde efter hvert sprint eller iteration
  2. med indlæggelse af et risikotillæg eller
  3. med en opdeling af udviklingen i to faser.

De kan også se, at nogle større agile kontrakter bliver formuleret som Joint-Ventures, hvor udviklingen foregår i fælles selskaber med aftaler om fordeling af overskud mv.

Det interessante ved deres resultater er, at de peger på, hvornår de forskellige kontraktelementer bringes i spil, og hvor fordelene ligger hos enten kunden, leverandøren eller begge.

Og fra interviewene kan man også sige, hvilke kontraktelementer, der kan bringes i spil i de kritiske områder omkring agil udvikling. Her bliver anbefalet, at hvis der er usikkerhed om kundens involvering har netop Joint-Venture eller aftaler om økonomisk kompensation vist sig at have effekt. Hvis der er lav tillid mellem parterne, viser det sig, at en række elementer kan bringes i spil fx betaling pr sprint eller risikotillæg.

Her får du et skema med en opsamling af deres anbefalinger.

 Figur 2. Forståelse af aftalepraksis i agile projekter.

Aftalepraksis i agile projekter

Her godt 15 år efter

Godt 15 år efter det agile manifest er vi ved at få et indtryk af udfordringerne i praksis - både når vi skal drive projekterne internt, og når vi skal drive dem med underleverandører. Det fremgår jo nok, at der er en række nuancer omkring den agile projektledelse, som kræver stillingtagen både fra linjeledelse og projektledelse.

Kilder

  1. Se fx JP Finans 26. maj 2016
  2. Darell K. Rigby, Jeff Sutherland, Hiro Takeuchi “Embracing Agile” Harvard Business Review Maj 2016.
  3. K03 Standardkontrakt for agile it-projekter, Digitaliseringsstyrelsen 2012.
  4. Version2: 27.november 2014 Jesper Stein Sandahl Agil udbudsproces gør datafordeleren 5,6 millioner dyrere end planlagt .
  5. J. Kujala, S. Nystén-Haarala, J. Nuottila Flexible contracting in project business International Journal of Managing Projects in Business, Vol. 8 Iss 1 pp. 92–106.
  6. Shi Hao Zijdemanns, Christoph Johann Stettina: Contracting I Agile Software Projects – State of Art and how to understand it Giovanni Cantone Michele Marchesi (ed) Agile processes in Software Engineering and extreme programming, !5 International Conference XP May 2016.

Om Peter G. Harboe

Peter G. Harboe er underviser og forsker på VIA University College, Innovation og Karriere. Peter er cand.merc. og underviser på Diplom i Projektledelse en række moduler herunder metodefag, strategi og porteføljeledelse.

Peter har mere end 25 års erfaring fra projekter i dansk erhvervsliv og er ekspert i projektledelse, branding og markedsføring. Han er blogger, debattør og forfatter.

Mere inspiration

Sådan indarbejder du bæredygtige elementer i dine projekter
Artikel Gå til siden
Du skal lede dit projekt bæredygtigt – men hvad betyder det?
Artikel Gå til siden
Den hybride fremtid: Hvordan fastholder vi engagementet?
Podcast Gå til siden
Forholder du dig til bæredygtighed i dine projekter?
Artikel Gå til siden
Når I kalder det for et projekt, hvad mener I så egentlig?
Artikel Gå til siden