Agile metoder: Navigering i it-udvikling

Agile projekt metoder har været i vælten i over 20 år. Store og små virksomheder, der beskæftiger sig med innovation og it, har for længst taget metoden til sig, og langsomt men sikkert følger andre trop. IT-udvikling og agile metoder er nu nærmest blevet synonyme, og flere og flere udtrykker et ønske om at arbejde i en eller anden form for agilitet. Opdag, hvordan agile metoder adskiller sig fra traditionelle tilgange.

Det er en Agil Ideologi, der bringer den rigtige tankegang frem og giver en indikation af de værdier og prioriteter, der ligger til grund for den. Nedenfor finder du et uddrag fra Ideologien for Agil Softwareudvikling (hentet fra agilemanifesto.org)

Vi finder bedre måder at udvikle software på ved at gøre det selv og ved at hjælpe andre med at gøre det. Gennem dette arbejde har vi lært at værdsætte følgende:

• Mennesker og interaktion frem for processer og værktøjer
• Software, der virker i stedet for omfattende dokumentation
• Samarbejde med kunden frem for kontraktforhandlinger
• At reagere på forandringer i stedet for at følge en plan

Det betyder: Selvom punkterne til højre har værdi, værdisætter vi punkterne til venstre endnu højere.

Inkrementel udvikling: Målet med hvert sprint er at producere et funktionelt, testbart "inkrement" af produktet, som kan leveres til kunden.

Efterslæb: En liste over opgaver, kendt som "produktefterslæb", prioriteres af produktejeren. Teamet udvælger opgaver fra backloggen for hvert sprint og overfører dem til "sprint-backloggen".

Daglig stand-up: Korte, daglige møder, hvor teamet diskuterer, hvad de lavede dagen før, hvad de skal lave i dag, og eventuelle forhindringer, de møder.

Sprintgennemgang og retrospektiv: Ved afslutningen af hvert sprint evaluerer teamet det arbejde, der er udført i en sprintgennemgang, og reflekterer over, hvad der kan forbedres retrospektivt.

Selvorganisering og løbende forbedringer: Scrum-teamet er selvorganiseret og tager ansvar for planlægning og udførelse af arbejdet. Det fokuserer også på løbende forbedring af både processen og produktet.

For dem, der ikke er så fortrolige med agile metoder, kan det virke som om agile projekter frasiger sig kontrollen. Desværre ser vi mange projekter, der hævder at 'arbejde agilt' uden at have klare mål, styring eller kontrol. Lad os aflive denne myte med det samme. Tre af grundpillerne i Scrum er 'gennemsigtighed', 'inspektion' og 'tilpasning'. Det betyder ikke kun, at projektets tilstand, status, ydeevne og leverancer skal være fuldt gennemsigtige, men at vi også aktivt skal kontrollere og justere disse for at optimere ydeevnen. Den største forskel fra vandfaldsmetoden ligger i kontrolmetoden. Scrum er fleksibelt og kan tilpasses forskellige projekter og teams. Det lægger vægt på kundeinvolvering, gennemsigtighed og tilpasningsevne til at håndtere forandringer.

Agile metoder er meget udbredt som projektmetode i IT-branchen. Efter at have brugt forskellige vandfaldsmetoder i de foregående årtier var det en lettelse for mange at bruge agile metoder. Traditionelle vandfaldsmodeller kræver, at du har næsten 100% kontrol over, hvad der leveres i hele projektperioden, inden du går i gang. Årsagen er, at du skal lave alle specifikationer, tidsplaner og estimater eller fast pris (worst case scenario) for hele projektet, før du begynder at bygge det, der skal bygges. Denne model låser dig fast i at levere det, der er specificeret, og giver lidt plads til justeringer undervejs. Det svarer ikke til nutidens krav om hyppige ændringer og ikke mindst for at kunne høste umiddelbart af de erfaringer, der er gjort i løbet af projektet.

Selvom denne artikel argumenterer for brugen af agile metoder, er det ikke altid agile metoder passer ind i projektet. Det kan være en god idé at køre et forprojekt først, for at få nogle vigtige elementer på plads, såsom mål, design på højt niveau osv. Hvis kunden ikke er klar til en sådan model, kan du få så meget modstand, at det vil være svært at få flow. Tænk især over, om kunden har brug for et samlet estimat knyttet til det, der leveres, skarpe deadlines og meget mere.

Hvis du kan identificere behov og løsninger med en høj grad af sikkerhed, og har erfaring fra lignende arbejde tidligere, kan vandfaldsmetoden være et alternativ. For at opnå succes med metoderne skal man kende alle forudsætningerne på forhånd. Nogle eksempler her er, når du udskifter 'kasser', såsom pc'er, printere osv. eller ved installation af en 100% færdig komponent, som du har gode erfaringer med fra før. Her vil der ikke være behov for meget tilpasning eller udvikling i projektperioden.

Men med en højere grad af usikkerhed er agile metoder at foretrække. For virksomheder, der ønsker at udforske innovation og produktudvikling på nye markeder, anbefales en hypotesedrevet metode, såsom lean startup eller design tænkning.

At vedtage agile metoder vil hovedsageligt være den bedste tilgang. I et agilt projekt er der et tæt samarbejde mellem kunde og leverandør. Det er et tillidsbaseret samarbejde, hvilket er fremragende i Norge, hvor vi generelt har en høj grad af tillid til hinanden (og myndighederne). Kunden får kendskab til de forskellige tekniske muligheder og begrænsninger. Leverandøren opbygger viden om kundens processer, mål og ønsker. I den symbiose, der opstår mellem kunde og leverandør, opstår der et kreativt grundlag for at bygge den bedste løsning, der giver mest effekt. I de bedste agil projekter arbejder du så tæt og målrettet, at skellet mellem leverandør og kunde udviskes, og alle er dedikerede til at skabe den bedste løsning.

Der er en masse erfaring og analyser, der bekræfter, at den agile metode har en højere succesrate end traditionelle projektmetoder. En del af grunden til, at agile metoder er populære i Norge, og derfor har gode betingelser for succes, er den norske arbejds- og organisationskultur. Fundamentet, som agile metoder bygges på, er tillid, samarbejde og en flad hierarkisk struktur.

Projekter er altid forbundet med en vis usikkerhed og risiko, og på samme måde som vi mennesker undgår risiko så vidt vi kan, ønsker vi at kontrollere al risiko i projekter. Den traditionelle måde at reducere risikoen i projekter på har været grundig og lang planlægning og derefter strenge kontrolordninger. Dette planlægnings- og kontrolregime skaber arbejdsforhold, der er modstridende i forhold til, hvordan vi ønsker det, og hvorfor vi gennemfører projekter. Det sker, fordi konsekvensen af planlægnings- og styringsregimet er, at projektets mål er at følge planen frem for at skabe værdi.

Alle, der har været på forkant med projektplanlægning og opfølgning, kender behovet for fleksibilitet. Deadlines bliver ofte sat med kort varsel, men paradoksalt nok bruger vi lang tid på detailplaner, der strækker sig år ud i fremtiden, før selve udviklingsfasen starter. Udviklere tøver med at give estimater på komplekse opgaver, vel vidende at disse "gæt" kan komme tilbage for at hjemsøge dem. Dette er ikke overraskende, da vi mennesker generelt er dårlige til at estimere tid - et fænomen kendt som "planlægningsfejlslutningen", først beskrevet af psykologerne Tversky og Kahneman i 70'erne, og senere bekræftet gennem forskning. Resultatet er ofte overoptimistiske estimater, der er umulige at opfylde, hvilket kan føre til et anstrengt forhold mellem kunde og leverandør, hvor tillid og samarbejde erstattes af mistillid og forhandling.

Selvom dette ikke altid er tilfældet, vil gentagen udførelse af den samme opgave ofte resultere i et højere præcisionsniveau. IT-projekter præsenterer en betydelig grad af usikkerhed og kompleksitet, hvilket ikke kun skyldes udviklingsprocessen, men også usikkerheden omkring de mest optimale forretningsprocesser. Udfordringen forværres af det faktum, at informationsteknologiens "bedste praksis" konstant ændrer sig på grund af den hurtige it-udvikling.

Traditionelt har projektledelse fokuseret på 'tid', 'omkostninger' og 'omfang'. Reglen har været, at ændringer i en af disse faktorer vil påvirke de andre. For eksempel kan man ikke bede om mere funktionalitet uden at øge budgettet og tidsrammen. I agile projekter er tid og omkostninger 'låst' ved at betale for et vist antal ressourcer over en given periode. Dette eliminerer forhandlingen af projektets detaljer (omfang), som blev aftalt i planlægningsfasen. Kunderne skal få, hvad de ønsker, uden at gå på kompromis.

Dette fører os til det næste vigtige spørgsmål: Hvad ønsker kunderne egentlig? Eller mere præcist, hvad vil egentlig skabe værdi for dem? I it-projekter er der normalt tre faktorer, der får omkostningerne til at overstige det nødvendige. Den første er de velkendte gigantiske projekter, der aldrig leverer, fordi de enten opdager forhindringer for sent eller ignorerer dem. Den anden er "overudvikling", hvor det er kendt, at 80 % af brugerne kun bruger 20 % af funktionaliteten. Dette resulterer i investering i dyr funktionalitet, der sjældent bruges, og som kan forringe brugeroplevelsen. Den tredje er, at virksomhederne ikke udnytter muligheden for at realisere fordele undervejs i projektet. Fælles for alle disse er, at implementeringen af løsningen tager for lang tid.

I agile projekter følges nøje op på, hvad vi leverer, og hvordan vi leverer. Selvom målet er at minimere planlægnings- og detaljeringsfasen for at starte udviklingen så tidligt som muligt, er planlægning stadig en vigtig del af processen. I modsætning til traditionelle metoder foregår det meste af planlægningen undervejs, med en kortere planlægningshorisont og fokus på at løse et problem ad gangen. Kundens ønskede gevinster er altid i fokus for at beslutte, hvad der skal løses og hvordan. Bygherren er involveret i at inspicere både planer og løsninger, hvilket giver dem løbende kontrol over projektets fremdrift. Erfaring og feedback bruges til at planlægge den næste fase af udviklingen.

En af projektlederens vigtigste opgaver i agile projekter er at skabe et højtydende team. Vi bruger teknikker til at måle præstationer og i overensstemmelse med lean-principperne identificere og fjerne alt 'spild', sårbarheder og forhindringer, der kan påvirke teamets præstationer. Ved at være gennemsigtige og invitere kunden til at deltage, opbygger vi også tillid til udviklingsteamet hos kunden.

Agile metoder kræver, at alle involverede har en forståelse for de regler, rutiner og processer, der gælder. Dette bliver udfordrende, hvis det kun er projektlederen/Scrum Masteren, der forstår, hvordan tingene skal gøres.

Det kan være udfordrende at starte et agilt projekt med en ny kunde, der ikke har kendskab til agile projekter før. Dette vil være lettere med eksisterende kunder, der har erfaring med agile projekter fra før. Det kræver ofte en vis erfaring at blive fortrolig med, at projektet ikke har klare og detaljerede planer for leverancer, herunder budget. Det kan hurtigt virke lidt ustruktureret, at man har et kæmpe efterslæb af opgaver, som udvikleren kan plukke imellem, og at der ikke er en fast struktur for, hvornår leverancerne kommer.

Når forudsætningerne er på plads, er vi af den opfattelse, at den agile metode er den mest effektive og bedste måde at levere projekter på. Der kan derfor argumenteres for, at der er en fremtid for agile metoder. Når det er sagt, kan metoderne videreudvikles, da der er svagheder, der klart kan forbedres. Du kan f.eks. se på Half Double-metoden, som trækker det bedste fra agile og traditionelle projekter (f.eks. Prince2).

Agile metoder foretrækkes især i situationer med høj usikkerhed, og anbefales til virksomheder, der ønsker at udforske innovation og produktudvikling på nye markeder. Metoderne understøtter en hypotesedrevet tilgang, såsom lean startup eller designtænkning, og er generelt den bedste tilgang til at opnå succes i projekter med varierede antagelser. For at opsummere mener vi, at den agile metode er den bedste metode til at sikre, at kunderne får det, de ønsker, hvad de har brug for, og som giver dem værdi, samtidig med at risikoen for økonomiske tab reduceres. Og ikke mindst gør det selve projektgennemførelsen meget sjovere!