Martin Koksrud Bekkelund

Scrum er en fantastisk prosjektmetodikk. Forutsatt at du kommer fra en verden hvor vannfall er metodikken du kjenner. Men har du først fått taket på Scrum, er tiden inne for å komme seg videre. Scrum er intet blivende sted. Sånn sett er Scrum en avrusningsmetodikk for dem som kommer fra vannfall.

Man må lære å krabbe…

Når man kommer fra vannfall, representerer ofte smidige prosjektmetodikker noe fundamentalt annerledes enn hva man er vant med. Ikke bare er det en annerledes måte å jobbe på, det virker til og med uansvarlig ved første øyekast: ingen kravspekker, ingen dokumentasjon, ingen planlegging, ingen deadlines, ingen prosjektledere, ingen milepelplaner. Hvordan i all verden skal man få levert noe med så lite?

Og det er her Scrum kommer inn. Scrum innfører mye av tankegodset til smidig på en måte som gjør det spiselig for dem som trenger avrusning fra vannfall. Man har en Scrum Master som prosjektleder, man har sprinter som deadlines, man har Planning Meetings for planlegging og diverse andre artefakter som fungerer som pusteøvelser når savnet etter vannfall blir for stort.

Problemene med Scrum

Problemet er at flere av artefaktene fra Scrum blir en flaskehals straks man behersker Scrum. Når man innfører Scrum er det derfor viktig at man før innføringen klart og tydelig setter seg som mål at når Scrum beherskes, så må man komme seg videre. Kontinuerlig forbedring er sentralt i smidig.

Ta dette med sprinter. En sprint er en avgrenset tidsperiode som man driver utvikling i. En sprint varer for eksempel tre uker. Man starter en sprint med et planleggingsmøte. Deretter jobber man med å lage det man har definert i planleggingsmøtet. Og det er her problemene oppstår. Plutselig støter man på problemer og oppgaver må tas ut av sprinten for å rekke deadline. Ja, deadline. En kunstig, selvpåført deadline som kun fører til stress. Eller verden endrer seg underveis i sprinten, slik at forutsetningene du arbeider etter også har endret seg.

Løsningen? Fjern sprintene. Hvorfor ha selvpåførte deadlines hvis det ikke er noen reell grunn til å ha dem? Kast sprintene ut døra sammen med planleggingsmøtene.

Og Scrum Master? Hvorfor ha en person til å fotfølge utviklerne for å måle fremdriften deres til stadighet? Du klarer deg med en som leder utviklingsteamet og som selv utvikler og er produktiv.

Når passer Scrum?

Vi i Posten har gjennom flere år levert flere IT-prosjekter til offentlig sektor. Prosjektene ble levert på tid og pris. Det siste prosjektet ble gjennomført mer eller mindre etter Scrum-boka.

Scrum har etter mitt syn sin naturlige plass enten hvis man kommer fra vannfall og skal videre til noe mer smidig, eller hvis man har leveranser med faktiske deadlines.

… før man lærer å gå

For mange er Scrum et mål i seg selv. Jeg har tidligere skrevet at metoden ikke er målet. Sentralt i smidig står tanken om kontinuerlig prosessforbedring. Finn flaskehalser i utviklingen og fjern dem, en etter en.

I stedet for sprinter plukker utviklingsteamet oppgaver fra en prioritert backlog, utvikler, tester, aksepterer og produksjonssetter når de er ferdige med oppgaven. Alle utviklere bør kunne gjøre alle oppgaver: utvikle, teste, akseptere og produksjonssette alle deler av all kode. Gi utviklerne root.

DevOps og Extreme Programming (XP) har mye bra ved seg som du kan hente inspirasjon fra. Det samme har Kanban. I kombinasjon får du både elementene du trenger til å sette sammen en god prosess, i tillegg til å visualisere fremdrift og legge begrensninger på flaskehalsene.

Kommer du fra vannfall hjelper Scrum deg opp i knestående. Herfra må du selv komme deg videre, for eksempel med XP og Kanban som krykker. Hva som skal til videre herfra er helt opp til deg selv. Finn flaskehalsene og stressfaktorene, fjern dem og gjenta.

Teknologiledelse