Hva styrer valg av metodikk for design og utvikling av digitale systemer?
Waterfall vs agile; your call

‘Smidig’ eller ’agil’ har vært et buzzword de siste årene når samtalene dreier seg om metodikk for design og utvikling av digitale systemer. Litt spissformulert handler smidige metoder hele tiden om å kunne justere kurs og prioriteringer ut fra hva som gir mest umiddelbar verdi. Metodikken settes ofte opp mot konvensjonell ’fossefalls’-metodikk; en fasetilnærming med vekt på grundig planlegging i forkant av utvikling. Din frykt som oppdragsgiver er selvsagt at du føler du betaler det samme, men får mindre.

Vår påstand er likevel at større prosjekter faktisk er avhengig av smidig utvikling for å lykkes. Både økonomisk og kvalitetsmessig. Som regel vil det du trodde da dere engasjerte en innkjøpskonsulent for å vurdere hva dere trengte, garantert være endret når prosjektet leveres. Knowits perspektiv på større prosjekter er ofte at en mer kontinuerlig prosess hvor designet utvikles i vekslinger mellom designerens løsningsforslag og kundens krav og kriterier, gir bedre og mer relevante løsninger. Målet med smidige prosjekter er å minske tap.

Fordelene er at man raskere kan lansere i markedet, lære og justere underveis basert på erkjennelsen av at det som ble tenkt i fjor ikke nødvendigvis er like smart i år. Dette blir mer og mer aktuelt når vi ser hvor raskt digitaliseringen endrer samfunnet. Virksomheten endrer seg, men aller viktigst; kundepreferanser endrer seg hele tiden og målestokken er som regel global.

Hvordan skal dere kunne velge rett anbyder uten fossefallsmetodikk?
Man bruker mye tid på å estimere for å kunne gi et nøyaktig kostnadsbilde, og prosjekter velges mye basert på hvilken pris en tilbyder har. Rett og slett fordi dere selvsagt ønsker kontroll på fremtidige kostnader. Normen i dag er alt for ofte at enorme ressurser blir brukt på utforming, estimering og utvikling av krav som til slutt blir endret eller forkastet etter test. Vi tror ikke man alltid kan forvente at det er en suksessfaktor å binde seg eller den andre parten til et fast estimat på et svært prosjekt. Vår påstand er at det ikke alltid gir kontroll, men kun en illusjon av kontroll.

Fossefall-metoden har sin opprinnelse fra klassiske ingeniør-prosjekter. Digitaliseringsprosjekter har en annen natur enn konvensjonelle IT-prosjekter, og krever andre tilnærminger enn konvensjonell IT-tenkning. Du kan få mer ut av utviklings-budsjettet ditt ved å omfordele ressursene, for å kapitalisere på den uunngåelige endringen som kommer til å skje i løpet av prosjektet.

Hvorfor skal du ut av fossen?
Som bestiller er du nødt til å være involvert, ellers så kommer du ikke ut av fossen. I konvensjonelle it-prosjekter er endring vanskelig. Tydelige tegninger på alt som skal lages og alt er planlagt ned til minste detalj før første spadetak. Slutten er definert før start. For å lykkes med gode digitaliserings-prosjekter, kreves smidig tilnærming fra begge sider av bordet når prosjektene kommer opp i en viss størrelse.

Krav endrer seg med tid og erfaring
Kravene en organisasjon har i starten er ikke nødvendigvis det man ønsker til slutt. Disse er som regel satt basert på erfaringen man hadde på det tidspunktet. Nye systemer, portaler, brukergrensesnitt eller andre digitale flater gir nye erfaringer som igjen gir nye idéer. Et prosjekt er ferdig når ingen bruker det lenger. Ikke før, men likevel definerer man seg som regel ferdig når man har levert produktet. Vi tenker at et utviklingsprosjekt må jobbes med til det ikke skal brukes lenger. Med andre ord, det finnes alltid mer å gjøre.

Mange bekker små, blir en stor Å
Smidig arbeidsmetodikk starter med en visjon om et større mål, før man setter sammen små “pakker” med utvikling som man har større sjanse for å lykkes med. Færre ting kan gå galt og man har kontroll når det skjer. Man gjør ferdig mindre bolker, tester dem og går videre til neste bolk. Trenger dere en nettbutikk, eller er dere egentlig ute etter å øke omsetningen? Selv om visjonen er styringsverktøyet, vet vi av erfaring at den kan endre seg mens man er i prosjektet. Skal et prosjekt være vellykket må det dekke det faktiske behovet, bekkene må få lov å finne veien dit det er naturlig, ikke der vi bestemte at den skulle gå da vi begynte å planlegge.

Rent praktisk vil det si at i et tverrfaglig team vil deler av teamet jobbe hele, eller deler av tiden, med strategisk arbeid for å legge føringer for hva som skal gjøres i de neste sprintene. Skal et team kunne jobbe effektivt med å utføre og hele tiden vise til resultater, er det veldig viktig at arbeidet som skal utføres er tilrettelagt på best mulig måte, og at så mye som mulig av avklaringene er gjort på forhånd. Derfor er det kritisk at dyktige strategiske og tekniske rådgivere jobber tett mot prosjekteiere og med kontinuerlig feedback fra sluttbrukere.

6 takeaways
1. Fossen krever at vi faktisk kan spå fremtiden; det kan vi ikke alltid.
2. Et prosjekt er aldri ferdig før man skrur av nettstedet
3. Estimering gir en illusjon av kontroll, fordi det er vanskelig å spå fremtiden nøyaktig
4. Hele organisasjonen må være smidig. Fra bestiller til dem som utfører og tester
5. Uten kontinuerlig leveranser kan man ikke være smidig
6. En smidig leveranse er avhengig av åpenhet og gjensidig tillit