God Scrum, dårlig Scrum
Forståelsen av hva Scrum egentlig er, varierer veldig for tiden. Det er gledelig å se at Scrum engasjerer og at dette diskuteres i mange ulike fora. Det er også bra at det kommer opp motforestillinger. Ikke alle ser fordelen av å bruke Scrum – spørsmålet er hva som er årsaken til dette? Påstand: I de fleste tilfellene bunner det i at man ikke har tatt Scrum helt på alvor!
Scrum er bare et enkelt rammeverk som krever at du jobber i selvstyrte team, i korte iterasjoner og at du utnytter disse iterasjonene til å forbedre deg. Rammeverket definerer noe få roller, prinsipper og møteplasser. Scrum er laget for å eksponere problemer. Åpenhet og synlighet er essensielle verdier. Når problemer kommer til overflaten har vi mulighet til å gjøre noe med det. Om teamet fungerer godt vil de som jobber der forøke og løse problemet. Vi løser problemer og fjerne hindringer i små trinn – og gradvis forbedrer vi oss.
God Scrum gir god kvalitet
I en god Scrum implementasjon gjør man en og en funksjon helt ferdig av gangen i den forstand at man integrerer og tester fortløpende gjennom Sprinten. Man oppdager raskt fordelen ved automatisering, både av bygging, enhetstester og system/akseptanse-tester. Dette er jo krevende, men et godt Scrum team jobber utrettelig for å gradvis automatisere testene. Alle gode Scrum team har en omforent, godt forstått definisjon av ordet Ferdig. Mange gode Scrum team bruker kodestandarder og gjør kodereview som en del av deres definisjon av Ferdig. Dette gjør de fordi de har erfart at dette gir bedre kvalitet og at de dermed får mindre feilretting i de påfølgende Sprintene. Et godt Scrum team har som (mer eller mindre langsiktig) mål å kunne release som en del av Sprinten. For å få til dette trenger man en god Scrum organisasjon som gir teamet anledning til å stadig forbedre seg.
Hva er dårlig Scrum?
Jeg diskuterer mye med andre som er Certified Scrum Trainer i Scrum Alliance. Og jeg har sett en rekke organisasjoner fra innsiden de siste årene. Det typiske utgangspunktet er noe slikt som at “vi har brukt Scrum i et år og vi trenger litt coaching for å komme videre”. Det de kaller Scrum er som oftest et begrenset utvalg av Scrum elementene.
En organisasjon jeg var inne hos for noen måneder siden var slik. De hadde ca 4 uker lange iterasjoner (ikke konsekvent), et team der få var allokert 100%, ingen klar definisjon av begrepet ferdig. De hadde en Scrum Master som på mange måter opererte som prosjektleder. Det mest alvorlige bruddet med Scrum var allikevel Produkteierrollen. Denne personen hadde ikke har fått opplæring og hadde ikke ryddet plass i kalenderen sin med tanke på Scrum oppgavene. Når det gjaldt den kontinuerlige forbedringen gjennomførte de ofte retrospective møtet som et pliktløp, uten at det er noe særlig temperatur å spore. Allikevel var de fornøyde! Dette har jeg sett flere ganger. Bare iterasjonene, tettere team og litt bedre fokus kan gi en (tilsynelatende) positiv effekt.
Det at folk er fornøyd er jo fint, men er vi trygge på at vi har fått en varig forbedring? Neppe. Men det er trist å se at såpass mange stopper her. Det er mye større gevinster å hente ut! Dessuten er det er fare for at dette forvitrer og faktisk utvikler seg i negativ retning. Scrum Alliance er krystallklare her. Dette er Bad Scrum. Den eneste “unnskyldningen” for være i en slik tilstand er at man er på vei mot et klart mål – Good Scrum.
Nå kan jeg forstå at noen vil hevde at dette tenderer mot en slags religiøs fanatisme. De bokstavtro har rett! Men når vi tar med i betraktning at Scrum er et veldig enkelt rammeverk beregnet på synliggjøring og forbedring – så er er det kanskje ikke så dumt å fokusere en del på de elementene som er ment å bidra nettopp til kontinuerlig forbedring?