Hva er forskjellen på fossefall og smidig?
La oss ta for oss et typisk fossefallprosjekt: prosjektet gjennomfører en forstudie for deretter å spesifisere kravene til løsningen. Videre spesifiseres design før teamet realiserer løsningen. Helt til slutt blir løsningen testet før man gjør en produksjonssetting hvor løsningen blir tatt i bruk. Når vi jobber med fossefall som metode er det vanskelig å bevege seg tilbake til forrige iterasjon med arbeid, for eksempel å endre kravene når teamet er i gang med å utvikle løsningen. En endring vil da i verste fall kunne gjøre at teamet må planlegge prosjektet på nytt og vil kunne kreve omfattende arbeid i form av oppdatering av løsningsdokumentasjon ettersom denne er definert i detalj før man starter utviklingen. Dette kan høres ryddig ut, men det er en grunn til at fossefall prosjekter ofte blir kalt rigide, og det er ikke alltid denne måten å jobbe på matcher problemstillingen eller løsningen teamet jobber mot.
Smidige prosjekter utfolder seg ikke nødvendigvis mye annerledes dersom man kun ser på iterasjonene prosjektet består av. Hovedforskjellen er at prosessen “beskrive, designe, utvikle” repeteres flere ganger etter hverandre i stedet for at man gjør de isolert hver for seg. Dette bidrar til at teamet ikke nødvendigvis vet helt konkret hva det ferdige produktet er lenger frem i tid, ettersom løsningsbeskrivelsen blir til underveis. Det bidrar også til at det kan være vanskelig å forutse når prosjektet er ferdig, men samtidig har man også mye mer fleksibilitet.
Det kan oppleves som en unødvendig risiko å ikke ha 100% kontroll på produktet fra start til slutt, men her kommer vi til et viktig poeng når du jobber med IT-prosjekter: de er uforutsigbare av natur.
Last ned guide: Vismas 7 steg til en vellykket prosjektoppstart
I løpet av prosjektperioden kan jeg garantere at det vil komme til nye sikkerhetstiltak teamet bør implementere i løsningen eller gjøre en vurdering rundt. Teamet vil også bli nødt til å forholde seg til eksempelvis nye praksiser, metoder, språk, rammeverk og oppdateringer. Det er ikke alt av prosjektrelaterte hendelser eller tilbakemeldinger som kan forutses, og det er heller ikke alt prosjektet skal trenge å bruke tid på å forutse. Teamet er derfor nødt til å tilpasse seg miljøet de jobber i underveis i prosjektperioden.
Når det er sagt, så er smidige prosjekter ikke uten svakheter, det finnes flere feller å gå i. Selv om metoden skal sikre en større grad av forutsigbarhet i et uforutsigbart miljø kan det raskt bli kaos dersom teamet ikke passer på og aktivt bruker de verktøyene og rammene som finnes. Jeg tror de aller fleste som har vært med i et smidig prosjekt har opplevd hendelser som ikke har gått så bra, og ofte er det nok også vanlig å feile første gangen man tar i bruk denne måten å jobbe på.
Nedenfor gjennomgår jeg seks typiske fallgruver og måter å håndtere disse på:
1. Forutsigbarhet
Det kan være vanskelig å forutse det endelige produktet når prosjektperioden er over og derfor også vanskelig å forutse kostnader, tid og ressursbruk. Når du jobber med smidig prosjektstyring er du derfor avhengig av erfaringer fra deltakerne i prosjektet, samt en dyktig prosjektleder, scrum master, tech lead eller koordinator som er med på å sørge for at teamet har riktig fokus og forventninger til produktet underveis.
Metodene innenfor smidig prosjektstyring tilbyr flere hjelpemidler som skal bidra til større forutsigbarhet i prosjektet. Scrum, til eksempel, har sprinter, planning, retro, demo og daglig standup som typisk passer mer omfattende prosjekter. Kanban har en kort og enkel prosess for mindre omfattende prosjekter. Begge metodene nevnt inkluderer aktiv bruk av tavle, swimlanes og kontinuerlig estimering / prioritering i prosjektperioden.
2. Dokumentasjon
Dokumentasjon oppstår underveis i et smidig prosjekt – dersom det er behov for det. Det vil si at dokumentasjon ofte er noe teamet må ta igjen på slutten, dersom det er en påkrevd del av leveransen. Når man jobber smidig vil produktet endre seg underveis – og det er derfor ikke alltid nødvendig å dokumentere hver enkelt utgave av løsningen i detalj. Ofte vil du kunne finne historien til en sak eller endring gjennom versjonkontrollverktøy slik som Github eller Gitlab, eller for eksempel gjennom kommentarer og logging i prosjektstyringsverktøyet Jira. Her handler det om å finne en fin balanse mellom behov og nytteverdi for prosjektet, også etter at prosjektet er ferdigstilt i en første versjon. Noen ganger er det viktig at hele eller deler av løsningen er godt dokumentert, andre ganger gir timene en større verdi dersom de er brukt på kvalitetssikring eller videreutvikling av funksjonalitet. Det er opp til prosjektet å vurdere dette fortløpende i prosjektperioden.
Les mer om hvordan Visma kan bidra til prosjektledelse for dine IT-prosjekter her.
3. Fragmentert produkt
I et prosjekt med smidig prosjektstyring vil du typisk komme deg raskere til målet enn ved fossefall. Det gjør at teamet raskt kan teste om en idé eller konsept fungerer, men det gjør også at produktet kan ende opp mer fragmentert og mindre helhetlig. Dette er ting teamet må tenke på underveis i utviklingen, og krever at teamet kommuniserer godt sammen og har de riktige forventningene til hva de lager. Det krever også at prosjektleder må følge opp løsningen å ikke være redd for å snakke med teamet om potensiell teknisk gjeld som kan oppstå og vurdere denne løpende.
Sett opp kortsiktige mål som skal nås og prioritere disse – hva er viktigst å få ferdig først? Finnes det ting fremover vi bør hensynta allerede nå? Det er en hårfin balansegang med å gjøre nok men ikke altfor mye. Dersom komponenten, metoden eller klassen likevel må skrives om eller byttes ut senere, er det ikke sikkert du trenger å bruke altfor mye tid på å perfeksjonere og refaktorere den i en første versjon. Da kan det være man heller bør vente til komponenten, til eksempel, er moden nok for det.
Hvorfor bruke en konsulent som prosjektleder til digitaliseringen? Les mer her.
4. Måle fremgang underveis
For å måle fremgang i et smidig prosjekt må vi se på inkrementet eller produktet teamet jobber med over tid. Dette betyr at vi i starten av et prosjekt ikke nødvendigvis har så mange KPIer å jobbe med da prosjektet mangler referansetall. Dersom dette er viktig kan det lønne seg å sette seg ned tidlig for å sette opp noen klare mål som brukes aktivt i prosjektperioden, og forventningsstyre når disse målene faktisk vil kunne indikere hvordan teamet ligger an. I Scrum tar det ofte 5-10 sprinter før teamet har gode referansetall å bruke til estimering av oppgaver og til å forutse når fremtidig funksjonalitet er på plass. Har teamet jobbet sammen før kan det gå kortere tid. Stol på prosessen!
5. Ingen slutt?
Det er lett å bli distrahert i smidige prosjekter – “La oss bare gjøre dette, fikse dette eller inkludere dette også”. Det fine med å jobbe smidig er at det har prosjektet alltid mulighet til, hvis det er slik at dette er nødvendig for å maksimere verdien av endelig produkt. Det betyr ikke at prosjektet skal undervurdere konsekvensen av å innføre ny funksjonalitet, eller å endre eksisterende underveis. Her må teamet hele tiden ha et aktivt forhold til hva de egentlig jobber med å løse. Periodiske og overordnede mål er et godt verktøy for å sørge for dette og at teamet ikke mister drivet mot ferdig funksjonalitet, slik at prosjektet ikke sitter igjen med en hel haug med halvferdige funksjonaliteter. Ha i bakhodet at timer brukt på en oppgave typisk ikke har noen verdi før oppgaven faktisk er levert og implementert – så jobb hele tiden mot en ferdig minsteløsning.
6. Tør å feile
Alle prosjekter er forskjellige og det viktigste er at teamet underveis har et aktivt forhold til målet med prosjektet og kontroll på hvilke metoder og verktøy de bruker for å komme dit. Det kan fort bli dyrt dersom teamet mister oversikt og jobber med unødvendig eller umoden funksjonalitet, så det er viktig å prioritere og vurdere kost versus nytte underveis. Det finnes retningslinjer og rammeverk, men det vil uansett være prosjektteamet i sin helhet som bestemmer hvordan disse følges opp og fungerer i praksis. Snakk med andre som har kjørt lignende prosjekter, hva slags erfaringer gjorde de? Hva slags erfaringer har menneskene i teamet du jobber med? Smidig prosjektstyring vil i større eller mindre grad innebære at prosjektet må gjøre tilpasninger underveis, og enhver erfaring (bra eller dårlig) gjør oss flinkere. Ikke få panikk om du ikke føler mestringsfølelsen allerede i første sprint eller iterasjon, du har alle muligheter til å gjøre det bedre i neste.