Agil projektledelse – Metoden er ikke et spørgsmål om enten/eller

Hvis I vil anvende agile produktudviklingsmetoder, er det store spørgsmål ikke, om I skal være agile eller ej, men derimod, hvor agil I kan og tør være. Det handler om at afveje den rette grad af agilitet op imod behovet og ønsket om styring og overblik. Blandt de mange forhold der kan vurderes på, er der disse fire:

1. Kompleksiteten af produktet

Kender I kun det resultat, produktet skal skabe, men ikke selve specifikationen af produktet, kan de undersøgende agile produktudviklingsmetoder være en stor fordel. Når der ikke er klarhed over den fremadrettede årsag-virkning, produktet har, gælder det nemlig om at kunne prototype og teste i små interaktioner.

Hvis I derimod kender specifikationen af produktet og dets årsag-virkning fra starten, er der nok begrænsede fordele ved at bruge de agile metoder og teknikker. I den situation kan I som alternativ anvende eksempelvis Kanban til at optimere flow og visualisere fremdrift. 
 

2. Graden af brugerinvolvering

Projekter skaber produkter til de brugere, der skal anvende dem, så virksomheden får en gevinst i sidste ende. Hvis I skal skabe produkter, som ikke kan specificere klart i starten af projektet, eller til et miljø der er under konstant forandring, så er det afgørende at involvere brugeren gennem hele projektet. Her vil de agile roller og tilgange fremme brobygningen mellem dem, der udvikler produktet, og dem, der skal anvende det, når det går i drift.

Her er det selvfølgelig en forudsætning, at de agile roller og tilgange anvendes korrekt. Hvis I på forhånd ved, at der vil være begrænset brugerinvolvering, kan et alternativ være at prøve sig frem med værktøjer fra den plandrevne verden som eksempelvis streng ændringsstyring og detaljerede produktbeskrivelser.
 

3. Organisationskultur

Hvis I gerne vil arbejde med agile produktudviklingsmetoder, kræver det høj grad af selv-organisering, tillid, transparens og åben kommunikation. Dette forveksles ofte med selv-styrende teams, men selv-styring kan være meget risikabelt, da det forhindrer kendskab til, hvor målpinden placeres.

Hvis projektarbejdet skal udføres i en kultur, der er præget af lav grad af tillid og et højt behov for kontrol, så kan den agile adfærd være væsentligt udfordret. Og eftersom vi ved, at det kan tage flere år at ændre en organisationskultur, kan det i det tilfælde være bedre at køre projektet med en højere grad styring og lavere grad af agilitet.
 

4. Fleksibilitet i scope

Når man arbejder med agile metoder og teknikker, vil man gerne ”låse” tid, omkostninger og kvalitet, men i en verden præget af usikkerhed og forandring er det svært at estimere tid og omkostninger. Hvis tid og omkostninger er ved at blive overskredet på grund af forkerte estimater, er den agile anbefaling derfor, at man de-scoper projektet.

At de-scope projektet kræver dog, at kunden og brugeren er involveret i prioriteringen. Hvis produkterne i projektet ikke kan prioriteres, og alt er "must have", vil det nemlig kompromittere den agile tilgang.  
 

Et spørgsmål om tilpasning

Agil projektledelse er altså ikke et spørgsmål og om enten/eller, men et spørgsmål om at tilpasse anvendelsen af de agile og de plandrevne metoder. Det handler om at opnå en passende fleksibilitet kombineret med den nødvendige styring i en verden, der er karakteriseret ved usikkerhed, midlertidig organisering og forandringer.

De virksomheder som forstår denne tilpasning vil hurtigst nå i mål med at udvikle det rigtige produkt – og udvikle produktet rigtigt.