SCRUMGUIDEN. Et hjelpemiddel for deg som ønsker å komme i gang med Scrum

Transkript

1 SCRUMGUIDEN Et hjelpemiddel for deg som ønsker å komme i gang med Scrum

2 Til brukere av Scrumguiden, Scrum er et rammeverk av regler og prinsipper som støtter smidig systemutvikling. Scrumguiden er basert på en forståelse av Scrum som er i henhold til Scrum Alliance, samt erfaringer vi har gjennom en rekke oppdrag i Norge og i utlandet. Guiden henvender seg til deg som er teammedlem, Scrum Master, produkteier, prosjektleder, eller sitter i en annen posisjon hvor du blir berørt av Scrum. Denne veilederen vil ikke alene kunne sette noen i stand til å begynne med Scrum. Vi anbefaler alle å starte med Certified Scrum Master eller Certified Scrum Product Owner kurs for å få en god innføring. Deretter kan denne guiden fungere fint som oppslagsverk. Vi har etterstrebet en konsistent begrepsbruk som er i henhold til den offisielle Scrum guiden på norsk ( Norwegian.pdf). Vi håper at du finner guiden nyttig lykke til! Geir Amsjø Certified Scrum Trainer Benjamin Sommer Certified Enterprise Coach Ris / ros? Eller lurer du på noe rundt Scrum? Send en e-post til post@leanventure.com

3 INTRODUKSJON Ken Schwaber og Jeff Sutherland co-presenterte Scrum først på OOPSLA konferansen i Jeff Sutherland, Ken Schwaber og Mike Beedle representerte Scrum i det famøse møtet som fant sted i februar 2001 og som resulterte i agile manifesto (se Formålet med møtet var å bli enige om en helt ny og langt mer effektiv tilnærming til programvare-utvikling. De tradisjonelle, rådende metodene ansåes som dysfunksjonelle og ikke basert på en grunnleggende forståelse av programvare. MANIFEST FOR SMIDIG PROGRAMVAREUTVIKLING Personer og samspill fremfor prosesser og verktøy Programvare som virker fremfor omfattende dokumentasjon Samarbeid med kunden fremfor kontraktsforhandlinger Å reagere på endringer fremfor å følge en plan Scrum er basert på empirisk prosesskontroll-teori, hvilket innebærer at man baserer seg på en klar visjon for så å lære i korte iterasjoner underveis. Hver iterasjon skal resultere i et produktinkrement som det er fysisk mulig å sette i produksjon. Dette inkrementet analyseres i samarbeid med interessenter slik at man får verdifull lærdom til bruk i senere iterasjoner. Det er et mål å produksjonssette så hyppig som mulig. I Scrum gjøres arbeidet av forholdsvis små, tverrfaglige, selvorganiserte team (4-9 personer) med ansvar for å finne løsninger på problemene etter hvert som de kommer. Scrum er i dag det dominerende og raskest voksende smidige rammeverket.

4 SCRUMTEAMETS 3 ROLLER PRODUKTEIER (PRODUCT OWNER) Ansvarlig for utforming og kommunikasjon av visjonen, release plan og produktkøelementene. Eier produktkøen og sørger for at den til enhver tid er oppdatert. Produkteier definerer akseptansekriterier og vil i samarbeid med utviklingsteam og interessenter sikre at produktinkrementet kan leveres ved slutten av hver Sprint. SCRUM MASTER Ansvarlig for at arbeidsprosessene fungerer bedre og bedre, gjennom å sørge for at man evner å trekke erfaringer ut av hver Sprint og tar små forbedringsskritt. Scrum Master lærer opp alle involverte og vil i starten være den som fasiliterer møtene og aktivitetene. Scrum Master sørger for at man identifiserer hindringer og at disse fjernes så raskt som mulig. UTVIKLINGSTEAM Er sammensatt på en slik måte at de har nok tverrgående kompetanse til å utvikle og levere elementene i produktkøen. Teamet tar ansvar og planlegger Sprintene og utfører alt som er nødvendig for å ende opp med et leverbart produktinkrement av høy kvalitet.

5 SCRUM ARTEFAKTER PRODUKTKØ (PRODUCT BACKLOG) SPRINT SPRINTMÅL En ordnet liste over alle krav / behov der rekkefølgen til enhver reflekterer produkteiers prioriteringer Hvert element er grovestimert Alltid i bevegelse: nye elementer kommer inn, store elementer brytes opp i mindre biter og elementer tas ut om de ikke når opp i prioriteringen En tidsboks av fast lengde (1-4 uker) som gjentas så lenge produktet er under utvikling (også kalt iterasjoner) En Sprint har et fast omfang som utviklingsteamet har tro på at de vil klare å fullføre En Sprint ender opp med et produktinkrement som er i henhold til definisjonen av Ferdig Et klart uttrykt hovedmål med Sprinten SPRINTKØ (SPRINT BACKLOG) Inneholder det utvalg av produktkøen som teamet har forpliktet seg til å levere, dette utvalget skal ikke endres under Sprinten Selve Sprintkøen er utviklingsteamets detaljplan for hvordan de skal oppnå sprint målet PRODUKTINKREMENT Funksjonalitet laget i Sprinten som oppfyller Definisjon av Ferdig Inkrementet demonstreres i Sprint Review og Produkteier tar umiddelbart beslutningen om det faktisk skal settes i produksjon. DEFINISJON AV FERDIG Skal fjerne all tvil om hva man mener når noen sier at man er ferdig Defineres av Produkteier og Utviklingsteamet i fellesskap En klar definisjon øker gjennomsiktigheten

6 SCRUM TEORI OG VERDIER TEORI BÆREBJELKER VERDIER Scrum er basert på Empirisk prosesskontroll-teori som på mange måter er motsatsen til Definert prosesskontroll. Det er med andre ord det som gir empiri (det man lærer) i en Sprint som er drivkraften. Scrum og empirisk prosesskontroll bygger på tre pilarer; Gjennomsiktighet Inspeksjon Tilpasning Scrum hviler på 5 verdier: Fokus. Fordi vi kun fokuserer på noen få ting om gangen, jobber vi godt sammen og produserer utmerket arbeid. Vi leverer da funksjoner med høy verdi raskere Dristighet. Fordi vi ikke er alene, føler vi en trygghet og har mer ressurser til rådighet. Dette gir oss mot til å gi oss i kast med større utfordringer. Åpenhet. Siden vi arbeider sammen, må vi åpent uttrykke hvordan vi ligger an, og hvilke hindringer vi ser foran oss. Vi lærer at det er godt og nyttig å uttrykke bekymringer, slik at de kan diskuteres i teamet Engasjement. Fordi vi får god kontroll over arbeidet og verdiene vi skaper, føler vi en større forpliktelse og et samlet engasjement Respekt. Ettersom vi samarbeider tett - og deler suksesser og fiaskoer - vil vi respektere hverandre og hjelpe hverandre å bli respektert.

7 PRODUKTKØVEDLIKEHOLD At Produktkøen til enhver tid er oppdatert og at neste Sprintplanlegging kan gjennomføres på en effektiv måte DELTAGERE Produkteier er ansvarlig for at aktiviteten blir gjennomført Scrum Master deltar for å sikre at aktiviteten gjennomføres på en effektiv måte Hele utviklingsteamet er alltid med Spesielt relevante interessenter kan gjerne inviteres OMFANG Det er vanlig å bruke mellom 5 og 10 % av Utviklingsteamets kapasitet på dette. Det anbefales å gjøres dette jevnlig, samme tid, samme sted - en gang pr uke GJENNOMFØRING Produkteier går igjennom nytt element i produktkøen, og ber utviklingsteamet estimere Når Produkteier begynner å bli klar til å forplikte et stort produktkøelement, samarbeider alle om å splitte det opp i flere funksjonelle elementer. De nye elementene estimeres. Tips: Tips:. Bruk relative størrelser på elementene og ikke tid Bruk gjerne Planning Poker til estimering Om Teamet er svært usikre på hvordan et element skal løses, planlegg i stedet en Spike en liten, tidsbegrenset analyse

8 SPRINT PLANLEGGING Definere sprint mål, velge arbeid fra produktkøen, samt legge en realistisk plan for den kommende Sprinten DELTAGERE Hele Scrumteamet VARIGHET Tidsboks: 2 timer per uke Sprint FORBEREDELSE Produkteier har plukket ut det ønskede omfanget fra produktkøen Dette omfanget skal bestå av en realistisk mengde grovestimerte produktkøelementer som er brutt ned i små biter Teamet vet om den kapasiteten de har til rådighet i Sprinten GJENNOMFØRING Møtet gjennomføres som regel i to etapper; o o Del 1 med fokus på Sprint mål og omfang Del 2 med fokus på detaljplanlegging De to delene kan blandes, slik at ett og ett produktkøelement også detaljplanlegges

9 SPRINT PLANLEGGING (FORTS) SPRINT PLANLEGGING DEL 1 Produkteier presenterer Sprint målet og det diskuteres i hele teamet slik at alle får en felles forståelse og et eierskap til målet Produkteier går igjennom alle de valgte produktkøelementene Om teamet mener enkelte elementer er litt i største laget, splittes de opp i mindre enheter. Teamet enes om et realistisk omfang og et sprint mål etableres SPRINT PLANLEGGING DEL 2 RESULTAT Utviklingsteamet diskuterer hvordan det lønner seg å løse det valgte omfanget Normalt lager teamet en Sprintkø som består av alle de aktivitetene som er nødvendige for å lage alle produktkøelementene med gjeldende definisjon av Ferdig. Når dette er gjort skal teamet gjøre seg opp en mening om dette er noe de er rede til å forplikte seg til. Mange estimerer Sprintkøen i timer og sammenligner summen med sin kapasitet. Om utviklingsteamet gjennom Del 2 oppdager at omfanget er for stort må de sammen med produkteier finne produktkøelementer som kan tas ut. Bemerk: Det at utviklingsteamet forplikter seg betyr ikke at de lover å få ferdig alt. Programvareutvikling er komplekst og uforutsette hindringer kan komme i veien. Sprint mål og et valgt omfang En Sprintplan En grunnleggende tro på at det er realistisk å levere det valgte omfanget; en forpliktelse

10 DAGLIG SCRUM Koordinere teamet og bli enige om plan frem til neste Daily Scrum FORBEREDELSER Følgende deltagere er invitert Utviklingsteamet Scrum master Produkteier Andre interessenter Det er kun Utviklingsteamet som er forpliktet til å møte, og det er kun disse som har talerett Alle medlemmer av Utviklingsteamet har tenkt igjennom hva de gjorde siden sist møte, hva de har tenkt å gjøre fram til neste møtet og hva de eventuelt ser av problemer og hindringer. Dette møtet gjennomføres på samme sted og tid hver dag. VARIGHET Aktiviteten har en tidsboks på 15 minutter. GJENNOMFØRING Alle medlemmene av utviklingsteamet snakker på rundgang og redegjør for; Hva ble gjort siden forrige møte som hjelper teamet å nå Sprintmålet? Hva planlegger du å gjøre til neste møte for å hjelpe teamet å nå Sprintmålet? Ser du noen problemer eller hindringer som forhindrer teamet å nå Sprintmålet?? Problemer og hindringer loggføres

11 DAGLIG SCRUM (FORTS) RESULTAT Realismen i Sprinten vurderes Bemerk: det er sjelden tid til å løse problemer på dette møtet, så om en lengre diskusjon utvikler seg er det viktig å ha disiplin og stanse denne og loggføre problemet. Utviklingsteamet er koordinert Sprintkøen er oppdatert Hindinger er identifisert Realismen i Sprinten er vurdert; Om det for mye eller for lite gjenstående arbeid revurderes omfanget. Produkteier har det siste ordet om noe skal tas ut eller legges til. BRUK AV BURNDOWN CHART Mange Scrumteam vedlikeholder estimert gjenstående arbeid satt opp mot gjenstående kapasitet hver dag. På denne måten vil man på en enkel måte kunne vurdere realismen i inneværende Sprint og lettere identifisere behovet for å ta elementer inn eller ut av Sprinten I figuren går den rette linjen fra teamets totale kapasitet på dag 1 ned til 0 siste dag. Den buktende linjen er estimert gjenstående arbeid hver dag. Det er naturlig å oppdatere Burndown i forbindelse med Daglig Scrum.

12 SPRINT REVIEW Å gå igjennom - og demonstrere - alle produktkøelementer som er Ferdig. Få feedback fra interessentene. FORBEREDELSER VARIGHET Produkteier sørger for å invitere de meste interesserte interessentene Produkteier har en klar oversikt over det omfanget som var planlagt og det som faktisk ble ferdig iht. definisjonen av Ferdig. Utviklingsteamet er forberedt på å demonstrere all Ferdig funksjonalitet Tidsboks på 1 time per uke Sprint GJENNOMFØRING RESULTAT Produkteier går igjennom hva som ble Ferdig og hva som evt. ikke ble Ferdig Utviklingsteamet demonstrerer funksjonaliteten de har laget. La gjerne interessentene få prøve selv. Alle svarer på spørsmål. Produkteier noterer seg kommentarer og ideer fra interessentene Etter demonstrasjonen går produkteier igjennom produktkøen slik den står akkurat nå. Alle på møtet kommer med synspunkter på hva de kunne tenke seg å gjøre i neste omgang. Produkteier ser på plan, budsjett frem mot release dato Hele Scrumteamet og andre interessenter har en felles forståelse av resultatene fra sprinten og produktets totale status Scrumteamet har erfart noe i samspill med interessentene, noe som naturlig er input til neste møte: Sprint Retrospektiv.

13 SPRINT RETROSPEKTIV Lære av erfaring for å forbedre teamets og organisasjonens effektivitet FORBEREDELSER: Scrum Master er ansvarlig for møtet og kaller inn Følgende deltagere inviteres: Hele Scrumteamet (Valgfritt) Interessenter som har vært en spesielt viktig del av arbeidet Styrende prinsipp for retrospektiver: Uavhengig av hva vi oppdager, vi må ta inn over oss og virkelig tro at alle gjorde den beste jobben de kunne, gitt det som var kjent, deres kompetanse, tilgjengelige ressurser og situasjonen. VARIGHET Tidsboks på 1 time per uke Sprint GJENNOMFØRING Scrum Master starter møtet med å gå igjennom relevant fakta fra Sprinten. Eksempler: Feedback fra Sprint review, antall supportsaker, blokkerte saker, hendelser, saker der man undervurderte arbeidet, etc.. Alle bidrar Alle bidrar så med sine opplevelser av Sprinten; Hva fungerte fint, hva ville de gjerne forbedret. Varier gjerne med ulike idedugnadsteknikker for å engasjere alle i teamet. Reduser alle forslagene til noen få tiltak (maks 4) Bli enige om hvem som gjør hva, Scrum Master følger opp

14 SPRINT RETROSPEKTIV (FORTS) Tips: For å redusere mange ulike momenter (gjerne i form av post-it lapper) i en idédugnad til noe få aksjonspunkter, prøv dette: o o Alle hjelper til å gruppere lapper som er relaterte. Gi gruppene navn. Bruk dot-voting : hver deltager får et lite antall dots (prikker fra en tusj) som han/hun fordeler på de viktigste gruppene. Bruk teknikken 4 L s som sorterer erfaringene fra siste Sprint i 4 kategorier. Bruk gjerne ett flip-over ark for hver og få deltagerne til å klistre lapper på de fire arkene: o o o o Liked: Det fungerte flott og det vil jeg gjerne fortsette med Learned: A-ha opplevelser og annen ny lærdom fra Sprinten Lacked: Skulle ønske vi hadde dette! Konkrete ting. Longed for: Langsiktige ønsker, kanskje ikke helt realistiske ting. RESULTAT Et lite antall aksjonspunkter med ansvarlig person på REFERANSER Liste over identifiserte hindringer Lærdom alle teamdeltagerne forlater forhåpentligvis retro-møtet litt klokere Se

15 Kursopplegg med utstrakt bruk av øvelser og gruppearbeid Vil du vite mer? Her kommer noen gode tips: Lyntaler og foredrag fra Smidigkonferansen: Large Scaled Scrum (LeSS) Henrik Knibergs blog Video on Retrospectives: Norsk blog om smidig og Scrum: Drive video om motivasjon:

16 Trenger dere hjelp til å komme igang, eller ønsker dere å ta det neste steget? Vi kan hjelpe til videre med Smidig, Lean, Kanban og Scrum. Kontakt oss gjerne. Geir Amsjø Benjamin Sommer