Agile Metoder: Navigering i IT-utviklingens evolusjon

Agil prosjektmetodikk har vært i vinden i over 20 år. Store og små virksomheter som driver med innovasjon og IT har for lengst adoptert metodologien, og sakte, men sikkert kommer andre etter. IT-utvikling og agil har nå nærmest blitt synonymer, og flere og flere uttrykker et ønske om å jobbe i en eller annen form for agile. Oppdag hvordan agile metoder skiller seg fra tradisjonelle tilnærminger.

Det finnes et Agilt Manifest som får frem riktig «mindset» og gir en pekepinn på de verdier og prioriteringer som ligger til grunn. Under finner du et utdrag fra Manifestet for smidig programvareutvikling (hentet fra agilemanifesto.org).

Vi finner bedre måter å utvikle programvare på ved å gjøre det selv og ved å hjelpe andre med det. Gjennom dette arbeidet har vi lært oss å verdsette følgende:

• Personer og samspill fremfor prosesser og verktøy
• Programvare som virker fremfor omfattende dokumentasjon
• Samarbeid med kunden fremfor kontraktsforhandlinger
• Å reagere på endringer fremfor å følge en plan

Dette vil si: Selv om punktene som står til høyre har verdi, så verdsetter vi punktene til venstre enda høyere.

Inkrementell utvikling: Målet med hver sprint er å produsere et funksjonelt, testbart "inkrement" av produktet, som kan leveres til kunden.

Backlog: En liste over oppgaver, kjent som "product backlog", prioriteres av Product Owner. Teamet velger oppgaver fra backloggen for hver sprint og overfører dem til "sprint backlog".

Daily Stand-up: Korte, daglige møter der teamet diskuterer hva de gjorde forrige dag, hva de skal gjøre i dag, og eventuelle hindringer de møter.

Sprint Review og Retrospektiv: Ved slutten av hver sprint, evaluerer teamet det utførte arbeidet i en sprint review, og reflekterer over hva som kan forbedres i en retrospektiv.

Selvorganisering og kontinuerlig forbedring: Scrum-teamet er selvorganiserende og tar ansvar for å planlegge og gjennomføre arbeidet. Det fokuserer også på kontinuerlig forbedring av både prosessen og produktet.

For de som ikke er så kjent med agile metoder kan det virke som om agile prosjekter fraskriver seg kontroll. Dessverre ser vi mange prosjekter som hevder de 'jobber agilt' uten å ha klare mål, styring eller kontroll. La oss avkrefte denne myten umiddelbart. Tre av pilarene i Scrum er 'transparens', 'inspeksjon' og 'tilpasning'. Dette betyr ikke bare at prosjektets tilstand, status, prestasjoner og leveranser skal være fullstendig åpne, men at vi også aktivt skal kontrollere og justere disse for å optimalisere ytelsen. Den største forskjellen fra fossefallsmetodikken ligger i kontrollmetoden. Scrum er fleksibelt og kan tilpasses ulike prosjekter og team. Det legger vekt på kundeinvolvering, transparens og tilpasningsevne for å håndtere endring.

Agile metoder er mye brukt som prosjektmetode i IT-bransjen. Etter å ha benyttet diverse fossefallsmetoder i tidligere tiår var det for flere en befrielse å ta i bruk agile metoder. Tradisjonelle fossefallsmodeller krever at du har tilnærmet 100% kontroll på hva som leveres igjennom hele prosjektperioden før start. Årsaken er at du skal lage alle spesifikasjoner, tidsplaner og estimater eller fastpris (worst case scenario) for hele prosjektet før du kommer i gang med å bygge det som skal bygges. Denne modellen låser deg til å levere det som er spesifisert og åpner i liten grad for justeringer underveis. Dette samsvarer i liten grad med dagens krav om hyppige forandringer og ikke minst å kunne høste umiddelbart av de erfaringer som blir gjort underveis i prosjektet.

Selv om denne artikkelen argumenterer for bruk av agile metoder, er det ikke alltid agil metodikk passer inn i prosjektet. Det kan være lurt å kjøre et forprosjekt først, for å få på plass noen viktige elementer, som mål, high level design, etc. Hvis kunden ikke er moden for en slik modell vil man muligens få såpass mye motstand at det blir vanskelig å få flyt. Tenk spesielt på om kunden krever totalestimat knyttet opp mot det som leveres, skarpe tidsfrister med mer.

Dersom man med stor sikkerhet kan identifisere behov og løsninger, og har erfaring fra lignende arbeid tidligere, kan fossefallsmetoden være et alternativ. For å oppnå suksess med metodene må man kjenne til alle forutsetningene på forhånd. Noen eksempler her er når det skal byttes ut ‘bokser’, som PC’er, skrivere etc. eller ved installasjon av en 100% ferdig komponent som man god erfaring med fra tidligere. Her vil det ikke være behov for mye tilpasning eller utvikling i prosjektperioden.

Ved høyere usikkerhetsgrad er derimot agile metoder å foretrekke. For virksomheter som ønsker å utforske innovasjon og produktutvikling i nye markeder, anbefales en hypotesedrevet metodikk, som for eksempel lean startup eller design thinking.

Å ta i bruk agile metoder vil i all hovedsak være den beste tilnærmingen. I et agilt prosjekt blir det et tett samarbeid mellom kunden og leverandøren. Det er et tillittsbasert samarbeid, noe som passer utmerket i Norge, hvor vi generelt har høy tillitt til hverandre (og myndigheter). Kunden opparbeider seg kunnskap om de ulike tekniske mulighetene og begrensningene. Leverandøren opparbeider seg kunnskap om kundens prosesser, mål og ønsker. I symbiosen som oppstår mellom kunde og leverandør oppstår en kreativ base for å bygge den beste løsningen som gir mest mulig effekt. I de beste agile (smidige) prosjektene jobber man så tett og målrettet at skillet mellom leverandør og kunde viskes bort og alle blir dedikert til å lage den beste løsningen.   

Det foreligger mye erfaring og analyser som stadfester at agil metodikk har en høyere suksessrate enn tradisjonell prosjektmetodikk. Noe av årsaken til at agile metoder er populært i Norge, og derfor har gode forutsetninger for å lykkes, er den norske arbeids- og organisasjonskulturen. Fundamentet agile bygges på er nemlig tillit, samarbeid og flat hierarkisk struktur.

Prosjekter er alltid forbundet med en viss usikkerhet og risiko, og på samme måte som vi mennesker unngår risiko så langt vi kan, ønsker vi å kontrollere all risiko i prosjekter. Den tradisjonelle måten å redusere risiko på i prosjekter har vært grundig og lang planlegging og deretter strenge kontrollregimer. Dette plan- og kontrollregimet skaper arbeidsforhold som er motstridende sammenlignet med hvordan vi ønsker å ha det og hvorfor vi gjennomfører prosjekter. Dette skjer fordi konsekvensen av plan- og kontrollregimet er at prosjektets mål blir å følge planen fremfor å skape verdi.

Alle som har stått i spissen for prosjektplanlegging og oppfølging er kjent med behovet for fleksibilitet. Ofte settes frister med kort varsel, men paradoksalt nok bruker vi lang tid på detaljerte planer som strekker seg år frem i tid, før selve utviklingsfasen starter. Utviklere nøler med å gi estimater på komplekse oppgaver, vel vitende om at disse 'gjetningene' kan komme tilbake for å hjemsøke dem. Dette er ikke overraskende, ettersom vi mennesker generelt er dårlige til å estimere tid - et fenomen kjent som «the planning fallacy» (planleggingsillusjonen), først beskrevet av psykologene Tversky og Kahneman på 70-tallet, og senere bekreftet gjennom forskning. Resultatet er ofte overoptimistiske estimater som er umulige å oppfylle, noe som kan føre til et anstrengt forhold mellom kunde og leverandør, hvor tillit og samarbeid blir erstattet av mistillit og forhandlinger.

Selv om det ikke alltid er tilfellet, vil gjentatt utførelse av samme oppgave ofte resultere i et høyere presisjonsnivå. IT-prosjekter byr på en betydelig grad av usikkerhet og kompleksitet, som ikke bare skyldes utviklingsprosessen, men også usikkerheten rundt de mest optimale forretningsprosessene. Utfordringen forsterkes av at informasjonsteknologiens 'beste praksis' stadig endres på grunn av IT-evolusjonens raske tempo.

Tradisjonelt har prosjektstyring fokusert på 'tid', 'kostnad' og 'omfang'. Regelen har vært at endringer i én av disse faktorene vil påvirke de andre. For eksempel kan man ikke be om mer funksjonalitet uten å øke budsjettet og tidsrammen. I agile prosjekter 'låses' tid og kostnad ved at man betaler for et bestemt antall ressurser over en gitt periode. Dette eliminerer forhandling om prosjektets detaljer (omfanget) som ble avtalt i planleggingsfasen. Kunden skal få det de ønsker, uten kompromisser.

Dette leder oss til det neste viktige spørsmålet: Hva ønsker kunden egentlig? Eller mer presist, hva vil faktisk skape verdi for dem? I IT-prosjekter er det vanligvis tre faktorer som fører til at kostnadene overstiger det nødvendige. Det første er de velkjente gigantprosjektene som aldri leverer fordi de enten oppdager hindringer for sent eller ignorerer dem. Det andre er 'overutvikling', hvor det er kjent at 80% av brukerne kun benytter 20% av funksjonaliteten. Dette resulterer i at man investerer i kostbar funksjonalitet som sjelden brukes og som kan forringe brukeropplevelsen. Det tredje er at virksomheter ikke utnytter muligheten til å realisere gevinster underveis i prosjektet. En fellesnevner for alle disse er at implementeringen av løsningen tar for lang tid.

I agile prosjekter blir det vi leverer og hvordan vi leverer nøye fulgt opp. Selv om målet er å minimere planlegging og detaljeringsfasen for å starte utviklingen så tidlig som mulig, er planlegging fortsatt en viktig del av prosessen. I motsetning til tradisjonelle metoder, foregår det meste av planleggingen underveis, med en kortere planleggingshorisont, og fokus på å løse ett problem av gangen. Kundens ønskede gevinster er alltid i fokus for å bestemme hva som skal løses og hvordan. Kunden er involvert i å inspisere både planer og løsninger, noe som gir dem kontinuerlig kontroll over prosjektets fremdrift. Erfaring og tilbakemeldinger brukes til å planlegge den neste utviklingsfasen.

En av prosjektlederens viktigste oppgaver i agile prosjekter er å skape et høypresterende team. Vi bruker teknikker for å måle prestasjonsevnen og, i tråd med lean-prinsipper, identifiserer og fjerner vi alt 'svinn', sårbarheter og hindringer som kan påvirke teamets ytelse. Ved å være transparente og invitere kunden til å delta, bygger vi også tillit til utviklingsteamet hos kunden.

Agile metoder krever at alle som er med har forståelse for hvilke regler og rutiner, prosesser som er gjeldende. Dette blir utfordrende om det bare er prosjektleder/Scrum Master som forstår hvordan ting skal gjøres.

Det kan være utfordrende å starte et agilt prosjekt hos ny kunde som ikke har kjennskap til agile prosjekter fra før. Dette vil være enklere hos eksisterende kundeforhold som har erfaring med agile prosjekter fra tidligere. Det trengs gjerne litt erfaring for å bli fortrolig med at prosjektet ikke har tydelige og detaljerte planer for leveranser inklusivt budsjett. Det kan fort virke litt ustrukturert at man har en svær backlog med oppgaver som utvikler kan plukke fra og at det ikke er noen fast struktur på når leveransene kommer.

Når forutsetningene er på plass, er vi av den oppfatning at agil metode er den mest effektive og beste måten å levere prosjekter på. Det kan derfor påstås at det er en fremtid for agile metoder. Når det er sagt kan metodene videreutvikles, da det er svakheter som helt klart kan forbedres. Man kan f.eks. se til metoden Half Double, som henter det beste fra agile og tradisjonelle prosjekter (f.eks. Prince2).

Agile metoder foretrekkes spesielt i situasjoner med høy usikkerhet, og anbefales for virksomheter som ønsker å utforske innovasjon og produktutvikling i nye markeder. Metodene støtter en hypotesedrevet tilnærming, som lean startup eller design thinking, og er generelt sett den beste tilnærmingen for å oppnå suksess i prosjekter med varierte forutsetninger. For å oppsummere, mener vi at agil metodikk er den beste metoden for å sikre at kundene får det de vil ha, det de trenger og som gir dem verdi, og samtidig redusere sjansen for økonomisk tap. Og ikke minst gjør det selve prosjektgjennomføringen mye mer fornøyelig!