Scrum er et enkelt rammeverk for å optimalisere produktutvikling – i utgangspunktet programvarebaserte produkter. Dette rammeverket inneholder nesten ikke metodikk eller teknikker, man må selv finne ut hvilke håndtverksmessige verktøy og metoder som gir best effekt.
Rammeverket er basert på utvikling og leveranser i korte iterasjoner med en fast lengde (1 måned eller kortere) i tett, løpende samarbeid mellom kunde og leverandør. Man bestreber å komme raskt i gang med å levere den viktigste funksjonaliteten til kundene. Denne formen for prioritering fortsetter i hele produktets levetid – vi prioriterer de funksjonene som kunden/brukerne vedsetter høyest.
Vi unngår å forplikte oss til annet enn det vi planlegger på kort sikt og vi sørger for å vise fram resultatet av hver iterasjon til utvalgte interessenter slik at vi kan få verdifulle tilbakemeldinger. Vi utnytter all nyervervet kunnskap til å hele tiden forbedre produktet. Det er derfor viktig å ikke låse seg, men derimot bevare handlingsrommet. Derfor dokumenterer vi ikke mer enn høyst nødvendig. Selv om fleksibilitet og smidighet er sentrale verdier kan selve resultatmålet eller visjonen stå fast.
Scrum hviler på ideen om å løse problemene i selvstyrte, tverrfaglige team av passe størrelse (5-9 personer). Utviklingsteamet skal ha myndighet til å løse oppgavene slik de finner mest hensiktsmessig – innenfor visse rammer som er gitt av organisasjonen og/eller kunden. Teamet har ingen utnevnt leder, men det er helt greit at enkelte teammedlemmer tar mer ansvar enn andre. Et Scrum team jobber tett sammen, har korte møter hver eneste dag og bør i det hele tatt ha gode betingelser for kommunikasjon. Aller helst bør teamet sitte samlokalisert. I et velfungerende Scrum team har medlemmene et kollektivt, sterkt eierskap til innholdet av den iterasjonen de jobber med. Dette innebærer at de hjelper hverandre slik at ikke enkeltpersoner blir flaskehalser eller hindrer måloppnåelse. Når teamet starter en ny iterasjon skal de ha tro på at de vil lykkes med å nå målet. Derfor må de få arbeidsro, samt ha begrenset med avhengigheter av andre for å lykkes.
Høy kvalitet er helt sentralt i Scrum. Resultatet av et inkrement skal i størst mulig grad være funksjonalitet som direkte kan settes i produksjon. Derfor jobber alle gode Scrum organisasjoner og team med å bearbeide sin definisjon av begrepet ferdig. Vi kan ikke leve med at individuelle ulikheter bestemmer hvor godt en funksjon fungerer. Heldigvis får teamet dårlig kvalitet raskt i retur. Bug-fix og annen ikke planlagt omarbeiding er ganske ødeleggende for både motivasjon og framdrift og teamet forstår intuitivt at det vil lønne seg å hele tiden lage mer og mer robust definisjon av ferdig. De korte iterasjonene gjør det også veldig tydelig at utviklingsomgivelsene må være strømlinjeformede og automatiserte. Tidlig test og automatisering på flere nivåer tvinger seg fram og bevirker at produktiviteten kan nå helt nye høyder!
Scrum hviler tungt på ideen om perfeksjon gjennom empirisk ledelse og kontinuerlig læring (“inspect and adapt“). En god Scrum implementasjon er svært transparent og synliggjør problemer. Et synlig problem kan løses! Hver iterasjon skal utnyttes til å ta små skritt for å bli bedre. Man kan si at Scrum er en prosessforbedringsmodell. Det siste man gjør i en iterasjon er at man i fellesskap kikker tilbake og trekker erfaringer som utnyttes til forbedring. Her er det veldig viktig at organisasjonen er med, slik at teamet erfarer at de hindringene de identifiserer faktisk blir gjort noe med.
Vi trenger bare rollene Produkteier, Scrum team og Scrum Master. Produkteier eier visjonen og skal ha mandat til å bestemme hvilken funksjonalitet teamet skal jobbe med. Teamet må få tilstrekkelig tillit til å løse oppgaven slik de finner mest optimalt. Det er svært viktig at teamet har løpende kontakt med produkteier slik at vi utnytter all tilgjengelig kunnskap om både forretning og teknologi. Det ansees også som en styrke at selve teamet har sterk domenekunnskap og gjerne er bemannet med “ekte” brukere.
For å få denne helheten til å fungere bedre og bedre trenger vi rollen Scrum Master. Denne personen skal være ekspert på Scrum og jobbe utrettelig for å optimalisere produktutviklingen.
På bakgrunn av visjonen utarbeider Produkteier en Product Backlog som fortrinnsvis er en liste med funksjoner. Listen skal være både estimert og prioritert. Det er bare Scrum teamet som har lov til å estimere. Iterasjonene heter Sprint i Scrum. Når en ny Sprint skal starte velger Produkteier ut sin de høyest prioriterte funksjonene basert på kunnskap om teamets kapasitet eller hastighet. Dette kalles Selected Product Backlog og presenteres for teamet i Sprint Planning part 1, der teamet aksepterer denne evt. med visse endringer. Teamet utarbeider så (i Sprint Planning part 2) en oppgaveliste (Sprint Backlog) som er det som skal til for å realisere Selected Product Backlog. Sprint Backlog estimeres i timer og teamet finner til slutt det omfanget som de har tro på at de vil klare å realisere i neste Sprint.Underveis i Sprinten plukker teammedlemmene oppgave etter oppgave og fullfører funksjon for funksjon. Hver da møtes teamet til et daglig Scrum møte der de informerer hverandre om hva de har gjort, hva de tenker å gjøre og ikke minst hva de evt. har av problemer og hindringer. Hver dag skal alle påbegynte oppgaver re-estimeres slik at man kan lage et burn-down chart som brukes for å styre Sprinten. Den siste dagen i Sprinten har de Sprint review der teamet demonstrerer det realiserte produktinkrementet til utvalgte interessenter – som da gir tilbakemelding til teamet. Det aller siste de gjør i Sprinten er å gjennomføre et retrospective som innebærer å se seg tilbake og hente ut lærdom og å identifisere tiltak for å bli bedre.
Gå til Certified Scrum Master kurs
Gå til Certified Scrum Product Owner kurs
