Er du til Agile eller vandfald? – måske et af tidens dårligste spørgsmål!

Debat/januar 14, 2020/af Soeren Stuhr

Tidens store spørgsmål indenfor projektledelse er, om man er med på noderne og arbejder agilt, eller om man mere er til vandfalds-modellen? Men det er måske et af de dårligste spørgsmål, der kan stilles. Mit korte svar er ”ingen af delene”. Jeg er til projektledelse!

Ideologi er noget bras

Da daværende statsminister Poul Schlüter på Det Konservative Folkepartis repræsentantskabsmøde i december 1984 erklærede, at ideologi er noget bras, talte han ikke om projektledelse, men pointen er den samme. Når folk bliver dogmatiske omkring projektledelse, så forstummer samtalen ofte, og i stedet for at se efter gensidig befrugtning af hinandens perspektiver, bliver det til en ”enten eller diskussion”. De mest inkarnerede fortalere for agile modeller har en tendens til at betegne enhver ”ikke-agil”-tilgang som et udtryk for vandfaldsmodellen.

Vandfaldsmodellen

Vandfaldsmodellen er en model for softwareudvikling, hvor processen betragtes som konstant flydende nedad som i et vandfald, gennem faserne: kravspecifikation, design, udvikling, test, integration og vedligeholdelse. Som argument for modellen blev det bl.a. fremhævet, at den tidlige præcise specifikation af leverancerne, mindsker risikoen for scope creep. Modellen blev introduceret i 1970 af Winston W. Royce, der dog samtidig selv påpegede vandfaldmodellen som en model, der var ”risikabel og dømt til at fejle”. Royce var selv fortaler for en anden model, nemlig iterativ softwareudvikling eller integreret produktudvikling. I starten af 90’erne blev modellen for integreret produktudvikling konceptualiseret og brugt på mange danske universiteter fx ved Institut for Produktudvikling ved DTU.

Agile

Agile derimod er et sæt værdier og principper omkring softwareudvikling. Agile rummer mange fine elementer, men det er ikke en generel projektstyringsmetode. Det agile manifest blev lavet i 2001 og hedder oprindeligt ”manifest for agil software-udvikling”. Mange af de praksisser, som præsenteres som Agile elementer, er praksisser og teknikker, som er blevet anvendt i mange veldrevne ”ikke-agile” projekter, lang tid før manifestet blev skrevet. Faktisk er flere af elementerne grundpiller i integreret produktudvikling. Lad os give nogle eksempler:

· Brugen af enkle og regelmæssigt opdaterede visuals (Visuel planlægning)

· Brug af iterationer, mock-ups, prototyping m.m.

· Tidlig og hyppig slutbrugergennemgang af leverancer

· Daglig kommunkation omkring spørgsmål og aktuelle arbejdsopgaver

· Etablering af tværfunktionelle teams med beslutningstagere indlejret i teamet

· Ansigt til ansigt kommunikation (samlokation af projektgruppen)

Ovenstående elementer hjælper med at minimere misforståelser og omarbejder og fremskynder dermed leveringsprocessen. Samtidig øger det tilliden til at projektets leverancer opfylder brugernes reelle behov.

Tilsvarende gælder det, at nogle de agile ”værktøjer” (fx burn-down charts) er udviklet specifikt til at understøtte de agile tanker, mens andre metoder blot er ”lånt” fra projektledelseslitteraturen. Fx er ”Planning poker” – som ofte præsenteres som et agilt estimeringsværktøj, men er reelt blot en version af estimeringsmetoden kaldet Delphi (opkaldt efter oraklet i Delphi). Metoden blev udviklet i 1944 i den amerikanske hær!

Buzzwords kommer og går

Som det ofte er med ideologier (eller nye management buzz-words), så bliver de agile værdier og principper konceptualiseret og pakketeret på en måde, så de fremstår som noget, man ikke kan sige nej til. Hele projekttrekanten vendes på hovedet, og vi loves meget hurtigere, billigere og bedre projekter. Og som en ekstra bonus, kan du blive certificeret i den agile metode på næsten ingen tid. Men som de siger hos Forbrugerrådet ”hvis nogen prøver at give dig et tilbud, som lyder for godt til at være sandt, så er det som regel lige præcist det!”

Så virkeligheden er, at selvom agile rummer mange fine elementer, tanker og værdier, så er det ingen mirakelkur. Det egner sig glimrende til simpel softwareudvikling, hvor inkrementel sekventiel udvikling passer rigtig godt. Men Agile passer ikke til alle projekter. Så snart leverancerne begynder at involvere mere end blot software, eller når kompleksiteten er høj, så viser Agile sine begrænsninger. Når dette så kombineres med, at de mest radikale Agile fortalere har bandlyst projektledere fra projekterne (og indført agile coaches i stedet), så står problemerne i kø. Behovet for langsigtet planlægning, koordinering og håndtering af afhængigheder samt ledelse af projektets interessenter forsvinder ikke selv vi kalder os agile. Der er stadig brug for ledelse af projekterne.

Virkelighedstjekket

Det agile motto om ikke at arbejde med deadlines og slutprodukter, men kun at frigive produkter, når de er klar og godkendt, passer meget dårligt med virkeligheden i mange danske virksomheder. På samme måde gælder det, at i Agile er omfang (scope) den eneste reelle variable, hvilket simpelthen ikke passer i mange af de virksomheder, jeg kommer i. Der er masser af projekter, hvor sekventiel inkrementel levering aldrig vil være mulig eller anvendelig. Lad mig give et par eksempler fra nogle af de projekter vores kunder arbejder med for tiden:

· Et energiselskab har et projekt omkring etablering af havvindmøllepark i Taiwan

· En høreapparatsvirksomhed har et projekt omkring at skifte navn

· En non-profit organisation har et projekt omkring afholdelse af verdens tredje største musikfestival

Fælles for alle de 3 kunder er faktisk, at de alle lader sig inspirere af agile og bruger de elementer, som de mener skaber værdi for dem. Men agil sekventiel inkrementel levering bruger de altså ikke.

Ikke enten/eller

Så lad mig afslutningsvis lige opsummere min pointe:
Agile er glimrende. Det kan medføre nogle klare fordele i produktudviklingen i nogle projekter og giver nogle gode input til projekteksekvering, men det dækker ikke alt, hvad der er brug for i projektledelse, og det kan ikke bruges i alle tilfælde. Det er ikke et enten/eller valg, når man skal beslutte, hvordan man bedst leverer projekter. Vi har brug for mange forskellige projektledelsesmetoder og vi har brug for at metoderne arbejder sammen. Løsningen er ikke at ”afskaffe projekter”, som jeg har hørt nogle fundamentalister formulere det. Projekter er kommet for at blive, og der er forskel på projektstyring og produktudviklingsmetoder.