Agil eller fossefall – hvilken metode skal vi velge?

Fossefallmetoden og agil-metoden er begge mye brukt i prosjektplanlegging, men de representerer svært ulike måter å planlegge prosjekt på. Her forklarer vi når det passer å velge den ene fremfor den andre.

Metodene har sin opprinnelse i IT-verdenen, hvor de beskriver to ulike tilnærminger til programvareutvikling. Begge metodene har imidlertid spredd seg til andre sektorer, også prosjektledelse.

Den enkleste måten å vise forskjellen mellom de to metodene på er ved å beskrive fossefall som lineær og agil som syklisk, eller iterativ, som du ofte vil se brukt i litteraturen. Videre ligger mye av forskjellen i hvordan man planlegger prosjekter med de ulike modellene.

Slik planlegger du med fossefallmetoden

Hvis du følger en fossefall-modell, vil du planlegge hele prosjektet på forhånd, og du vil legge opp løpet i bolker, hvor hovedoppgaven innen hver bolk helst skal være ferdig og godkjent før du går videre til neste. Det er vanlig å dele opp i bolkene «krav», «design», «utvikling», «verifisering», «lansering» og «vedlikehold». Når du så går i gang med prosjektet, beveger du deg fra bolk til bolk, som i et fossefall – og det er ikke vanlig å bevege seg tilbake i rekken av bolker.

Rigid er et annet ord mange bruker om fossefall, fordi det er vanskeligere å gjøre endringer underveis. Hvis du er i utviklingsbolken, og kunden kommer med nye krav, kan det hende du plutselig må gjøre om på store deler av planene. I ekstreme tilfeller kan du måtte forkaste hele planen og arbeidet så langt, og bli nødt til å starte forfra. Fossefall passer best til prosjekter der kravene er godt kjent, og det er lite sannsynlig at det vil komme nye ønsker fra kunden.

Innen fossefall blir altså planene gjerne omfattende, rigide, svært detaljerte og ikke minst langsiktige. Her skal alt foregå langs én tidslinje, og hele planen for prosjektet skal ligge klar før man går i gang med noe som helst design eller utvikling.

Slik planlegger du med agil-metoden

Hvis du derimot følger en agil modell, legger du ikke detaljerte planer for hele prosjektet, men deler det opp i flere miniprosjekter – kalt iterasjoner eller sprinter. Her er målet å ha et ferdig produkt eller en ferdig del av produktet etter hver sprint. Dere skal kun bruke en kort periode i starten til å legge overordnede planer og sørge for at hele teamet har den samme visjonen, før dere går i gang med de sykliske fasene.

En av de største fordelene med agile metoder ligger i navnet, nemlig at de er smidige og tilpasningsdyktige. Hvis kunden kommer med nye krav eller ønsker etter hvert, enten basert på det dere allerede har levert, eller fordi forutsetningene er endret, trenger dere ikke gjøre om på omfattende, langsiktige planer. Når dere jobber agilt, kan dere tilpasse sprintene til de nye forutsetningene. En agil metode vil passe best når målet er raskt å ha et produkt som kan lanseres for sluttbrukerne.

En annen viktig komponent i agil prosjektstyring er de korte daglige statusmøtene. Her kan dere presentere hva dere har gjort, diskutere utfordringer, og vurdere om det fremdeles er mulig å gjøre alle oppgavene i løpet av inneværende sprint. Kanskje har dere fått nye krav fra kunden og ser at dere må gjøre nye prioriteringer av oppgavene i sprinten.

Slik bruker du timeboxer og sprinter

Innen agil prosjektstyring er det altså vanlig å dele prosjekter inn i sprinter. En sprint er en såkalt timebox, en forhåndsbestemt tidsperiode der teamet jobber mot et mål. Poenget med timeboxer er at teamet jobber til tiden er ute, og så stopper de arbeidet og ser på hva de fikk gjort – til forskjell fra at teamet jobber til de har nådd målet, og så ser på hvor lang tid de brukte.

Det er vanlig at sprinter varer mellom én og tre uker, men dere står selvsagt fritt til å finne en sprintlengde som passer for hvert enkelt prosjekt. Etter som teamet jobber mer sammen og dynamikken kommer på plass, vil dere i stadig større grad kunne estimere hvor mye dere kommer til å få gjort i de neste sprintene. Sprintene skal nemlig helst vare like lenge hver gang – og dere skal lære dere å tilpasse arbeidsmengden til sprinten.

I starten av hver sprint lager dere en liste over alt som skal gjøres. Denne er basert på kundens behov og målsettinger, og oppgavene er prioritert basert på hva som har størst verdi for kunden. Hvert av teammedlemmene velger seg så en oppgave fra listen og jobber med denne til den er ferdig, eller til sprinten er over. På slutten av sprinten skal dere helst ha et ferdig produkt som kan testes av kunden, og så ideelt sett lanseres.

Mens fossefall-metoden kan isolere fagområder og ansvarsområder, ved at overordnede sitter sammen og planlegger, designere sitter sammen og designer, og kodere sitter sammen og koder, oppfordrer agil prosjektstyring til samarbeid på tvers av fagområder og funksjoner. Hvert team må gjerne bestå av medlemmer fra de ulike delene av prosessen.

Test underveis med frequent releases

Frequent releases, eller hyppige leveranser som vi sier på norsk, går ut på at dere ofte sender produktet til sluttbrukere for testing – og det er viktig at dette er representative sluttbrukere. Det er ikke nok at et kvalitetssikringsteam eller den som styrer prosjektet, går gjennom produktet, det må innom de som faktisk skal bruke det. Bare da får dere den mest verdifulle tilbakemeldingen. Det er ikke alle bransjer hvor det passer å sende produktet til sluttbrukerne etter hver sprint, men dere må gjerne ta sikte på å ha leveranser etter hver fjerde til hver sjette sprint.

Fordelene med hyppige leveranser er mange. Tilbakemeldingene kan redusere usikkerheten i prosjektet – du ser tidlig om dere er på riktig vei eller ikke. Og hvis dere ikke er det, kan dere raskt endre retning. Disse hyppige leveransene kan også hjelpe kunden til å forstå eller sette ord på hva de ønsker. Det er ikke alltid enkelt å se for seg hva man faktisk kommer til å trenge fra et produkt, men det blir mye enklere så snart det begynner å ta form og man kan ta deler av det i bruk.

Leveransene er også tydelige tegn på at prosjektet beveger seg fremover, noe som er av interesse for alle fra kundene til sluttbrukerne til de som jobber med prosjektet, og denne fremdriften skaper engasjement rundt produktet.

Når bør man velge hvilken metode?

Det kan være en fordel å bruke en agil metode når det viktigste er å ha et fungerende produkt med de essensielle egenskapene til en spesifikk tid. Innen agil prosjektledelse vil man alltid prioritere det som har størst verdi for kunden, og søke å få det ferdig først.

Hvis man derimot har et godt bilde av hva man ønsker, og det viktigste er å få et fullstendig og helhetlig produkt med alt av egenskaper, kan fossefall-metoden være den riktige.

Både PRINCE2® og PRINCE2 Agile® er eksempler på hvordan fossefall og agile kan kombineres. PRINCE2® og PRINCE2 Agile® har bestemte faser og prosesser som skal gjennomgås samtidig som at hvert beslutningspunkt muliggjør små og store endringer i prosjektet. Denne sammenflettingen av smidighet og struktur gjør det mulig å hente ut det beste fra fossefall og agile. Men husk, til syvende og sist bør valg av metode tilpasses prosjektet.

Ønsker du å lære mer om PRINCE2® og PRINCE2 Agile® ? Bli med på gratis webinar!

Hva er PRINCE2®?

Hva er PRINCE2 Agile®?

Vi tilbyr både klasseromskurs og e-læringskurs for deg som ønsker en PRINCE2®- eller en PRINCE2 Agile®-sertifisering.