Agile Metoder: Navigering i IT-utviklingens evolusjon
Bjørn Erik Sandnes og Anders Torper
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.
Hva er agile metoder?
Agile metoder baserer seg på at kunde og leverandør i tett samarbeid utvikler en løsning sammen. I prinsippet trenger man i starten ikke mer enn en god idé, dedikerte ressurser, samt at budsjetter er på plass før man kan komme i gang. Man produksjonssetter løsninger i starten for å innhente erfaringer tidlig i prosessen. Prosjektteamet skal være autonomt (selvledede) og bærekraftig i den form at det skal leveres mer effekt og verdi enn kostnaden ved å ha et team.
Agile metoder er særlig godt egnet for produktutvikling. De kan brukes i prosjekter som har en klar oppstart og slutt, men også i vedvarende produktutvikling. Det kan være en god idé å etablere en ny løsning ved å gjennomføre et prosjekt frem til løsningen er satt i produksjon. Deretter kan prosjektteamet fortsette med videreutvikling av løsningen ved å bruke den samme agile metodikken som i prosjektet.
Grunnleggende prinsipper og verdier i Agile-manifestet
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.
Ulike agile metoder
Det finnes en rekke agile metoder. Her er en oversikt over de mest kjente:
- Scrum: Scrum er en mye brukt metode som legger vekt på iterativ utvikling og tverrfaglige team. Den benytter seg av korte tidsbokser, kjent som “sprint”, for å levere funksjonalitet i små, gjentakende sykluser.
- Kanban: Denne metoden er basert på visuell styring av arbeidsoppgaver. Den bruker tavler med kolonner for å spore oppgaver gjennom ulike stadier, fra “å gjøre” til “ferdig”.
- Extreme Programming (XP): XP fokuserer på teknisk dyktighet og samarbeid. Den inkluderer praksiser som parprogrammering, kontinuerlig integrasjon og testdrevet utvikling.
- Lean: Lean-metoden stammer fra produksjonsindustrien og handler om å eliminere sløsing. Metoden fokuserer på å levere verdi til kunden så effektivt som mulig.
- Dynamic Systems Development Method (DSDM): DSDM er spesielt egnet for IT-prosjekter. Den legger vekt på samarbeid, iterasjon og rask levering.
- Crystal: Crystal-metoden tilpasser seg prosjektets kompleksitet og størrelse. Den har forskjellige varianter, som for eksempel Crystal Clear og Crystal Orange.
- Feature-Driven Development (FDD): FDD fokuserer på å levere funksjoner i små, håndterbare biter. Den har en strukturert tilnærming til design og utvikling.
- Adaptive Software Development (ASD): ASD legger vekt på samarbeid, kommunikasjon og tilpasning til endrede krav. Dette er en fleksibel metode.
- Agile Unified Process (AUP): AUP kombinerer prinsipper fra Agile og Unified Process. Den gir retningslinjer for hvordan man kan tilpasse UP til smidige prosjekter.
Hva er Scrum?
Scrum er en av de mest kjente agile metodene for prosjektledelse og produktutvikling. Metoden er utviklet for å levere verdi til kunden på en rask og effektiv måte. Under følger noen nøkkelpunkter som forklarer nærmere hva scrum er (hentet fra scrum.org og Scrum Alliance):
Roller: Scrum-teamet består av tre hovedroller: Scrum Master, Product Owner og teammedlemmer. Scrum Master sikrer at teamet følger Scrum-prinsippene. Product Owner representerer kundens interesser, prioriterer og arbeidsoppgaver. Teammedlemmene utfører selve arbeidet.
Iterativ prosess: Scrum deler prosjektet inn i korte, iterative arbeidsperioder kalt "sprints", vanligvis 2-4 uker lange.
![](https://evidi.imgix.net/Miljobilder/Havnelageret/Evidi_BY_AlexandraGjerlaugsen_LR-43.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.7129&fp-y=0.3946&h=398&q=90&w=350&s=e8721ac67c07513e5024fe55796419f6 350w, https://evidi.imgix.net/Miljobilder/Havnelageret/Evidi_BY_AlexandraGjerlaugsen_LR-43.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.7129&fp-y=0.3946&h=682&q=90&w=600&s=561b3d1488e3f192ee3fc8dcec0dc0d5 600w, https://evidi.imgix.net/Miljobilder/Havnelageret/Evidi_BY_AlexandraGjerlaugsen_LR-43.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.7129&fp-y=0.3946&h=967&q=90&w=850&s=4d330bd9ae14656be367ec58103d8348 850w, https://evidi.imgix.net/Miljobilder/Havnelageret/Evidi_BY_AlexandraGjerlaugsen_LR-43.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.7129&fp-y=0.3946&h=1251&q=90&w=1100&s=306af922f2ab661e5bbf23b85b2943ef 1100w, https://evidi.imgix.net/Miljobilder/Havnelageret/Evidi_BY_AlexandraGjerlaugsen_LR-43.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.7129&fp-y=0.3946&h=1422&q=90&w=1250&s=ffd6c4086cfe23346dd652a73a529b6f 1250w)
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.
Les også:
Agile metoder vs. tradisjonell prosjektledelse
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.
![](https://evidi.imgix.net/Miljobilder/Sarpsborg/W1A3398.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.6531&fp-y=0.5512&h=817&q=90&w=750&s=9f10278c696e16a27e547539fda4ee2d 750w, https://evidi.imgix.net/Miljobilder/Sarpsborg/W1A3398.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.6531&fp-y=0.5512&h=1089&q=90&w=1000&s=61f6c08bbec986ef03e502655ed94cb1 1000w, https://evidi.imgix.net/Miljobilder/Sarpsborg/W1A3398.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.6531&fp-y=0.5512&h=1361&q=90&w=1250&s=d35541ccd3ee00fb831ca4065d1b19ea 1250w, https://evidi.imgix.net/Miljobilder/Sarpsborg/W1A3398.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.6531&fp-y=0.5512&h=1633&q=90&w=1500&s=6edc9c4f48599097036b930294e26c9e 1500w, https://evidi.imgix.net/Miljobilder/Sarpsborg/W1A3398.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.6531&fp-y=0.5512&h=1906&q=90&w=1750&s=433aa35c2d827a4509e593a708afbf93 1750w, https://evidi.imgix.net/Miljobilder/Sarpsborg/W1A3398.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.6531&fp-y=0.5512&h=2178&q=90&w=2000&s=27e4dcab6c93127ab13a9a0a6b991e39 2000w, https://evidi.imgix.net/Miljobilder/Sarpsborg/W1A3398.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.6531&fp-y=0.5512&h=2450&q=90&w=2250&s=558d9de058bce62a62af8e0a903bf6cd 2250w, https://evidi.imgix.net/Miljobilder/Sarpsborg/W1A3398.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.6531&fp-y=0.5512&h=2613&q=90&w=2400&s=7bbc8ea93849066a519a530126c3bea2 2400w)
![](https://evidi.imgix.net/Miljobilder/Halden/W1A4265.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.464&fp-y=0.6535&h=485&q=90&w=750&s=91feb70fa431181c1678f32b01c578b7 750w, https://evidi.imgix.net/Miljobilder/Halden/W1A4265.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.464&fp-y=0.6535&h=647&q=90&w=1000&s=8dddf41a5ecbe138b9ad58ffd679f56f 1000w, https://evidi.imgix.net/Miljobilder/Halden/W1A4265.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.464&fp-y=0.6535&h=808&q=90&w=1250&s=43ffc185742c42725f0d8ef3e37a91ae 1250w, https://evidi.imgix.net/Miljobilder/Halden/W1A4265.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.464&fp-y=0.6535&h=970&q=90&w=1500&s=8a32e47d388c4795c9109234fa3e5052 1500w, https://evidi.imgix.net/Miljobilder/Halden/W1A4265.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.464&fp-y=0.6535&h=1132&q=90&w=1750&s=0bb4728d637b6fec53eec7ad6d201eba 1750w, https://evidi.imgix.net/Miljobilder/Halden/W1A4265.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.464&fp-y=0.6535&h=1294&q=90&w=2000&s=e439101c624dda28c3f41156d58b35ce 2000w, https://evidi.imgix.net/Miljobilder/Halden/W1A4265.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.464&fp-y=0.6535&h=1455&q=90&w=2250&s=39956efd63582915e6277eb67166c710 2250w, https://evidi.imgix.net/Miljobilder/Halden/W1A4265.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.464&fp-y=0.6535&h=1552&q=90&w=2400&s=db308b0a43dbede8f336970db3ed48d9 2400w)
Agile metoders betydning i dagens prosjektlandskap
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.
Målet med agile prosjekter
I agile prosjekter er målet å sette løsningen i produksjon så tidlig som mulig, selv om den kanskje mangler noen funksjoner eller ikke fungerer optimalt. Det viktige er at den leverer verdi! Når brukerne har noe konkret å forholde seg til, kan de gi mer presise tilbakemeldinger til utviklingsteamet. Endringsønsker blir kartlagt, prioritert og utviklet iterativt, mens ytelsen overvåkes og forbedres. Til slutt kan prosjekteieren bestemme at løsningen er tilstrekkelig god, og at det er mer fordelaktig for virksomheten å investere det resterende budsjettet i andre prosjekter eller løsninger. Men hvordan sikrer vi at teamet ikke sløser med tid og penger hvis vi ikke kan planlegge og kontrollere basert på estimert tid? Svaret ligger i den agile metodens iterative natur og fokus på kontinuerlig forbedring, som sikrer at ressursene brukes effektivt til å skape verdi for kunden.
![](https://evidi.imgix.net/Miljobilder/Bergen/W1A6323.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.5&fp-y=0.5&h=398&q=90&w=350&s=9f747d5c34371e605a934230f56d7998 350w, https://evidi.imgix.net/Miljobilder/Bergen/W1A6323.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.5&fp-y=0.5&h=682&q=90&w=600&s=f18eee75bf00572c4a70fa638c8b4618 600w, https://evidi.imgix.net/Miljobilder/Bergen/W1A6323.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.5&fp-y=0.5&h=967&q=90&w=850&s=588fbe36b797051629140e4223d17cd1 850w, https://evidi.imgix.net/Miljobilder/Bergen/W1A6323.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.5&fp-y=0.5&h=1251&q=90&w=1100&s=581e4dd91f81f4cd035ef9888b551631 1100w, https://evidi.imgix.net/Miljobilder/Bergen/W1A6323.jpg?auto=compress%2Cformat&crop=focalpoint&cs=srgb&fit=crop&fp-x=0.5&fp-y=0.5&h=1422&q=90&w=1250&s=554a334f2edd1faaaffc8dc8a146ea00 1250w)
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.
Implementering av agile metoder
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.
Fremtiden for agile metoder
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!
Vil du vite mer om agile metoder og hvordan de kan implementeres i virksomheten?
Kontakt våre rådgivere for en uforpliktende prat!