Scrum - fortsatt relevant?

Ikke mange begrep vekker like mange assosiasjoner innen utvikling som “Scrum”. De fleste har erfaring med denne metodologien. Så hvorfor alle disse meningene? Flertallet av disse erfaringene er da også med negativt fortegn. Hva er greia?

Først litt historie. Som alle rammeverk, oppstod heller ikke Scrum i et vakuum. Også som mange andre liknende prosesser, har Scrum sine røtter Japansk produksjonsoptimalisering på starten av 1990-tallet. Hovedtrekkene i metoden som ble fremsatt var kryss-funksjonelle team. De gav den navnet Scrum, etter et begrep fra rugby, der ballen sendes frem og tilbake mellom lagmedlemmer på vei mot et mål. Dette ble plukket opp av Ken Schwaber og Jeff Sutherland som videreutviklet det til rammeverket vi kjenner idag. Siden den gang har Scrum blitt et kommersielt produkt med egen offisiell sertifisering.

Scrum var ikke alene om å være et lettvekts rammeverk tilpasset software-utvikling på denne tiden. Crystal Clear, Xtreme Programming og Unified Process er eksempler på andre medlemmer i denne familien. I 2001 samlet flere av folkene bak disse seg for undertegne det såkalte Manifesto for Agile Software Development. Dette dokumentet refereres ofte til som kilden for denne bevegelsen.

Agile er verdt et eget innlegg, men her er det Scrum vi diskuterer. Retningen Scrum har tatt siden sin spede begynnelse er interessant å se på. Jeg tror mye av frustrasjonen mange kjenner på kan forstås med å studere denne historien. La oss ta en kikk.

Da det agile manifestet ble underskrevet, ble det gjort av folk som selv jobbet med programvare. Bølgen med rammeverk som slo innover på starten av 1990-tallet, var en reaksjon på dominansen på tyngre prosesser som dominerte den gang. Dagens Scrum formidles i all hovedsak av personer hvis Scrum er et hovedprodukt, ikke et sideprodukt for å gjøre en jobb så effektivt som mulig. Dette har jeg opplevd som problematisk. Det går imot første punktet i det agile manifestet; “Individuals and interactions over processes and tools”.

Et utbredt feiltrekk ved implementasjon av scrum er at man ikke er åpen om hvorfor rammeverket innføres. En av de store styrkene til Scrum er at utviklerene kommer nærmere produktet og stakeholderene. Men i praksis så innføres det for å styre prosjektet. Da er veien veldig kort til det Ron Jeffries betegner som Dark Scrum. Utviklerene mister friheten som Scrum er ment å gi dem, og opplever Scrum som en hindring. Det kan man unngå dersom man er åpen med intensjonene med å innføre Scrum, noe jeg aldri har sett blitt gjort.

I Scrum planlegger man arbeidet i såalte sprinter. En sprint varer i typisk 2-6 uker. Før sprinten startet, velges oppgaver man tror man kan fullføre innen sprinten er omme. Denne tilnærmingen åpner for en rekke risikoer. Det er ofte vanskelig å planlegge utvikling så presist. Og dersom man ikke rekker å levere oppgavene man har valgt innen en gitt sprint på fast basis, mister man tiltroen til prosessen. En vanlig løsning på dette, er å forsøke å spesifisere oppgavene presist i et forsøk på presise estimat. Man bommer på abstraksjonsnivå, og gir ikke nok rom for designere og utviklere til å bruke ekspertisen sin og finne ut av disse detaljene selv.