I dette indlæg vil jeg gå i dybden med Scrum Frameworket med fokus på hvordan du kan bruge det når du arbejder med agil projektledelse.
Hvad er SCRUM?
Scrum er ikke en standardiseret proces, hvor du følger en række metodiske skridt, som garanterer at producere et produkt af høj kvalitet til tiden og efter budgettet, som gør kunderne glade.
Scrum er derimod et redskab til at organisere og håndtere arbejde. Et Scrum Framework er baseret på et sæt af værdier, principper og praksis, som skaber fundamentet, hvortil din organisation kan tilføje dets unikke implementation af relevante ingeniør praksis og din egen specifikke tilgange til at realisere de forskellige praksis.
Dermed vil Scrum Frameworket du bruger altså være unikt til din organisation.
Vidste du at:
- Scrum værdierne, principperne og de forskellige praksis er de basale strukturelle komponenter af din organisation.
- Du kan selv styre alle de forskellige ting der ligger bag denne basale struktur, så du ender med en Scrum proces der virker for din organisation.
Scrum er dermed en simpel og menneske-fokuseret metode, som er bygget på værdierne ærlighed, åbenhed, mod, respekt, fokus, tillid, ansvar og samarbejde. De forskellige Scrum praksis findes i specifikke roller, aktiviteter og regler.
Scrum Roller
Scrum projekter består af en eller flere projektgrupper, som hver er bygget op af tre forskellige Scrum roller; Product Owner, Scrum Master og en projektgruppe. Derudover kan der være andre roller, som er relevante når man bruger Scrum, men Scrum metoden kræver kun disse tre.
En Product Owner er ansvarlig for hvad der skal udvikles og i hvilken rækkefølge.
Scrum Masteren er ansvarlig for at guide projektgruppen i at skabe og følge dets egen proces, som er baseret på det bredere Scrum Framework.
Projektgruppen står for at finde frem til hvordan man kan levere det produkt, som dennes Product Owner har efterspurgt.
Hvis du selv er leder i en virksomhed, så skal du ikke være bange, fordi at titlen leder ikke fremgår her. Ledere har nemlig stadig en vigtig rolle, når en organisation følger Scrum.
Selve Scrum metoden fremhæver bare kun de roller, som er krævet for Scrum metoden og ikke alle de roller, som derudover kan eksistere i en organisation der bruger Scrum.
Product Owner
En Product Owner er det centrale punkt i forhold til produkt lederskab. Han eller hun står med hele ansvaret for at vælge hvilke features og funktionalitet der skal bygges, samt i hvilken i hvilken rækkefølge det skal bygges.
Den gældende Product Owner vedligeholder og kommunikerer til alle de andre medarbejdere en klar vision for hvad det er projektgruppen forsøger at opnå. Dermed er holdets Product Owner ansvarlig for den overordnede succes af løsningen der udvikles eller vedligeholdes.
Det er ligegyldigt om fokus er på et eksternt produkt eller en intern applikation. En Product Owner har stadig den obligation at sørge for, at det mest værdiskabende arbejde finder sted.
For at sikre, at projektgruppen hele tiden arbejder på en effektiv måde og skaber det, som deres Product Owner efterspørger, så samarbejder projektets Product Owner aktivt med Scrum Masteren og projektgruppen, og skal altid stå til rådighed til at svare på spørgsmål når de opstår.
Scrum Master
Scrum Masteren hjælper alle der er involveret med at forstå og benytte Scrum værdierne, principperne og praksis. Han eller hun fungerer som coach, og giver proces lederskab, samt hjælper projektgrupper og resten af organisationen med at udvikle deres egen effektive og organisationsspecifikke Scrum tilgang.
Samtidigt hjælper Scrum Masteren organisationen gennem udfordrende ledelsesprocesser, som kan opstå når man begynder på at bruge Scrum. Som facilitator hjælper Scrum Masteren projektgruppen med at løse problemer og lave forbedringer af hvordan projektgruppen bruger Scrum.
Derudover er personen ansvarlig for at beskytte projektgruppen fra forstyrrelser og tager lederskab i forhold til at fjerne ting, som kan begrænse produktivitet.
Scrum Masteren har ikke autoritet til at kontrollere projektgruppen, så rollen er dermed ikke den samme som ved en traditionel projektleder. Scrum Masteren fungerer mere som en træner/coach som skal motivere, og ikke så meget som en leder som skal bestemme.
Projektgruppen
Projektgruppen indeholder traditionelle jobtyper, som f.eks. arkitekter, programmører, testere, database administratorer, UI designers og så videre. Scrum definerer rollen af de forskellige projektgrupper, hvilket helt simpelt er en divers, cross-functional samling af disse typer personer, som er ansvarlige for ting som at designe, bygge og teste det ønskede produkt.
Projektgruppen styrer selv, hvilken måde der er den bedste for at opnå det, som gruppens Product Owner har efterspurgt. En projektgruppe er typisk fem til ni personer, som samlet set skal have alle de evner der er nødvendige for at producere høj kvalitet og et produkt der virker.
Naturligvis kan Scrum også bruges til udviklingsscenarier, som kræver meget større projektgrupper. Det er dog typisk mere optimalt at man i stedet for at have projektgrupper på f.eks. 35 personer, så har fire projektgrupper med med omkring 8-9 ansatte, eller færre.
Scrum aktiviteter og genstande
Projektets Product Owner har en klar vision for hvad han gerne vil skabe, men eftersom at det projektgruppens Product Owner gerne vil skabe kan være et stort projekt, så vil man gennem en proces kaldet grooming dele produktet ned til et sæt af features, som man samler i en prioriteret liste af opgaver. Det kaldes produkt backlog.
En sprint starter med sprint planlægning, derefter udviklingsarbejdet der er under en sprint (sprint udførsel) og slutter af med sprint review og sprint retrospective. Antallet af ting der skal laves i et produkt backlog er typisk mere end hvad en projektgruppe kan færdiggøre i en sprint.
Derfor skal man i starten af hver sprint beslutte en del af hele product backloggen, som projektgruppen mener man kan færdiggøre. Det er aktiviteten der kaldes for sprint planlægning.
For at blive sikker på, at projektgruppen har forpligtet sig til et rimeligt mål, så skal udviklerne lave en til backlog under sprint planlægningen, som kaldes for Sprint backlog.
Herefter kommer vi til punktet sprint udførsel, som er der hvor projektgruppen udfører opgaverne der er nødvendige for at opnå de ønskede features. På daglig basis under sprint udførsel vil udviklerne hjælpe med at håndtere arbejdet ved at udføre synkronisering, inspektioner og tilpassende planlægningsaktiviteter kendt som daily scrum.
I slutningen af sprint udførsel har projektgruppen produceret et potentielt markedsklar feature, som repræsenterer noget af, men ikke hele, af Product Owner’s vision.
Projektgruppen færdiggør sprinten ved at udføre to test-og-tilpas aktiviteter. I den første, som kaldes for sprint review vil stakeholders og projektgruppen teste på produktet der bygges. I aktivitet nummer to, kaldet sprint retrospective, vil projektgruppen gennemgå de Scrum processer der bruges til at skabe den feature. Resultatet af disse aktiviteter kan være tilpasninger som vil finde deres vej ind i produkt backloggen eller blive inkluderet som en del af projektgruppens udviklingsproces.
Efter alt dette, så er man kommet til det punkt hvor sprint cyklussen skal gentages. Det er altså en ny start, hvor projektgruppen beslutter hvilke dele af produkt backloggen gruppen kan færdiggøre.
Efter en passende antal sprints er færdiggjort, så bør projektgruppens Product Owners vision være realiseret og løsningen/produktet kan udgives.
I resten af dette indlæg vil jeg gå mere i dybden med hver af disse aktiviteter.
Produkt Backlog
Når scrum bruges, så er det altid det mest værdifulde arbejde der udføres først. Projektgruppens Product Owner, med input fra resten af projektgruppen og stakeholders, er i sidste ende ansvarlig for at beslutte og styre rækkefølgen af arbejdet og at kommunikere det i en prioriteret liste kendt som produkt backlog.
Ved udvikling af nye produkter er produkt backlog aktiviteter som udgangspunkt features der er nødvendige for at opnå projektgruppens Product Owners vision. Ved videregående produktudvikling kan en produkt backlog også indeholde nye features, ændringer til eksisterende features, defekter som skal fikses, tekniske forbedringer, og så videre.
En Product Owner samarbejder med interne og eksterne stakeholders for at indsamle og definere produkt backlog aktiviteter.
Herefter sørger han for, at disse aktiviteter er placeret i den korrekte rækkefølge ved hjælp af faktorer, som f.eks. værdi, udgifter, viden og risiko sådan at aktiviteter med høj værdi fremgår i toppen af et produkt backlog og at dem med mindre værdi fremgår ned mod bunden.
Det er vigtigt at huske på, at et projekts backlog er i konstant udvikling. Aktiviteter kan tilføjes, slettes eller ændres af en Product Owner i takt med at forretningsforhold ændrer sig eller at projektgruppens forståelse for produktet bliver bedre.
Overordnet set er denne aktivitet med at skabe eller forbedre produkt backlog aktiviteter, estimering af dem, og prioritering af dem, kendt som grooming.
Før man kan gå i gang med at færdiggøre prioritering, rækkefølger og på andre måder arrangering af produkt backlog, så skal man først vide størrelsen af hver aktivitet i ens produkt backlog.
Størrelse er lig med omkostninger, og Product Owners har behov for at vide en aktivitets omkostninger for at kunne beslutte dens prioritet. Scrum dikterer ikke hvilken måleenhed man vil bruge til produkt backlog aktiviteter.
I praksis, så bruger mange projektgrupper en relativ måleenhed, som f.eks. story points eller ideal days. En relativ måleenhed fortæller mere om den overordnede størrelse på en aktivitet på en måde hvor den absolutte værdi ikke er overvejet, men den relative størrelse på en aktivitet sammenlignet med andre aktiviteter er overvejet.
Sprints
I Scrum er arbejde udført i cyklusser af 2-6 uger kaldet for sprints. Arbejdet der er færdiggjort i slutningen af hver sprint bør skabe noget af håndgribelig værdi for kunden eller brugeren.
Sprints er timeboxed, hvilket vil sige, at de altid har en fastsat start- og slutdato, og generelt bør alle sammen være af den samme længde.
En ny sprint starter med det samme efter den tidligere sprint er færdiggjort. Som en regel bør man ikke lave store ændringer i omfang eller personale under en sprint. Nogle gange kan virksomheder dog blive nødt til at bryde denne regel.
Sprint Planlægning
Et produkt backlog kan repræsentere mange uger eller måneders arbejde, som er meget mere end hvad man kan håndtere i en kort sprint. For at beslutte hvad der er de vigtigste ting i et produkt backlog der skal bygges i den næste sprint vil den gældende Product Owner, projektgruppen og Scrum masteren udføre sprint planlægning.
Under sprint planlægning vil denne Product Owner og projektgruppen aftale et sprint mål, som definerer hvad man vil opnå med den næste sprint.
Ved hjælp af dette sprint mål kan projektgruppen gennemgå deres product backlog og beslutte sig for hvordan de forskellige aktiviteter skal prioriteres, som projektgruppen realistisk set kan opnå i den næste sprint mens der arbejdes i et bæredygtigt tempo – hvilket vil sige et tempo, som projektgruppen komfortabelt kan holde i en længere periode.
For at blive sikker på hvad man kan nå i perioden vil de forskellige projektgrupper bryde hver ønsket feature ned til et sæt af opgaver. Samlingen af disse opgaver, sammen med deres tilhørende produkt backlog aktiviteter, danner en yderligere backlog, som kaldes for sprint backlog.
Projektgruppen vil så give et estimat (typisk i timer) på hvad hver opgave kræver for at blive færdig. Det at nedbryde produkt backlog aktiviteter ned til mindre opgaver er en form for design og just-in-time planlægning for hvordan de forskellige features kan gøres klar.
De fleste projektgrupper der udfører sprints af to uger til en måned i længde forsøger at færdiggøre sprint planlægning i omkring fire til otte timer. En sprint der varer en uge bør ikke tage mere end et par timer at planlægge (og gerne mindre). Her kan man bruge flere forskellige tilgange.
Den tilgang jeg oftest bruger følger en simpel cyklus: Vælg en produkt backlog aktivitet (når det er muligt, den næstmest vigtigste aktivitet som defineret af gruppens Product Owner), nedbryd denne aktivitet til opgaver, og vælg om den valgte aktivitet på rimelig vis vil passe ind i den nuværende sprint (i kombination med de andre planlagte aktiviteter for den samme sprint).
Hvis den passer ind og der er mere kapacitet til at færdiggøre arbejde, så gentages cyklussen indtil projektgruppen ikke har mere kapacitet til rådighed.
En alternativ tilgang vil være, at den aktive Product Owner og projektgruppen vælger alle de ønsket backlog aktiviteter på en gang. Så vil det kun være udviklingsholdet alene der bryder disse opgaver ned til opgaver for at bekræfte, at de rent faktisk kan nå at levere alle disse valgte produkt backlog opgaver.
Sprint udførsel
Når projektgruppen er færdig med sprint planlægning og er enige om indholdet af den næste sprint, så vil projektgruppen med hjælp af scrum masterens vejledning udføre alt opgave-niveau arbejdet der er nødvendigt for at få alle features færdige, hvor “færdig” betyder, at der er en høj grad af tillid til at alt arbejdet der er nødvendigt for at producere høj kvalitets-features er færdiggjort.
Præcis hvilke opgaver projektgruppen udfører afhænger naturligvis af naturen af det arbejde der skal laves (for eksempel, er det software der bygges, hvilken type software, eller er det hardware, eller måske markedsføringsarbejde?).
Ingen bør fortælle projektgruppen i hvilken rækkefølge eller hvordan opgave-niveau arbejde i deres sprint backlog skal laves. I stedet, så skal udviklerne selv definere deres opgave-niveau arbejde og selv organisere hvordan de føler, at man på bedst vis kan opnå et sprint mål.
Daily Scrum
Hver dag af en sprint, ideelt set på samme tid, bør projektgruppens udviklere holde en timeboxed (15 minutter eller mindre) daily scrum. Denne inspicer-og-tilpas aktivitet er nogle gange refereret til som daily stand-up på grund af den typiske praksis, at alle står op under mødet for at sørge for at mødet bliver kort og effektivt.
En typisk tilgang til at udføre daily scrum er, at scrum masteren faciliterer og hver udvikler skiftes mellem at besvare tre spørgsmål til fordel for de andre udviklere:
- Hvad har jeg opnået siden den sidste daily scrum?
- Hvad har jeg planlagt at arbejde på til den næste daily scrum?
- Hvad er forhindringerne eller ulemper, som gør at jeg ikke kan skabe fremskridt?
Ved at besvare disse spørgsmål forstår alle det store billede af hvad der sker, hvordan de bevæger sig mod deres sprint mål, hvilke ændringer de skal lave til deres planer for næste dags arbejde og hvilke problemer der skal adresseres. Daily scrum er essentielt for at hjælpe projektgruppen med at håndtere det hurtige og fleksible arbejds-flow der er i en sprint.
Daily scrum er ikke en problemløsende aktivitet. Derimod er der mange projektgrupper, som vælger at tale om problemer efter den daily scrum og gør dette med små grupper af interesseret personer. Daily scrum er heller ikke et traditionelt statusmøde, specielt den type der historisk set er arrangeret af projektledere så de kan få en status på projektet.
En daily scrum kan derimod være brugbar til at kommunikere statussen af sprint backloggens aktiviteter mellem projektgruppens medlemmer. Hovedsageligt er den daily scrum en inspektion, synkronisering og tilpassende daglig planlægningsaktivitet som hjælper de selv-organiserende projektgrupper med at gøre deres job bedre.
Selvom det ikke er noget man bruger specielt meget mere, så har Scrum brugt termerne “pigs” og “chickens” for at skelne mellem hvem der bør deltage under den daily scrum og hvem der bare skal observere. Formålet med disse termer i scrum er naturligvis at skelne mellem dem der er involveret og dem som er forpligtet til at møde sprint målet. Til en daily scrum er det kun pigs der skal tale, chickens, hvis der er nogen, bør kun deltage som observatører.
Done
I scrum refererer vi til sprint resultaterne som et potentielt marketable product, hvilket betyder, hvad end projektgruppen har aftalt der skal gøres, er færdigt, alt efter deres aftalte definition af “done”.
Denne definition specificerer graden af tillid til at arbejdet der er færdiggjort er af høj kvalitet og potentielt set marketable. For eksempel, når der udvikles software, så skal en minimum definition af done give et komplet stykke af produkt funktionalitet, som er designet, bygget, integreret, testet og dokumenteret.
En fyldestgørende definition af done gør det muligt for virksomheden at beslutte ved hver sprint om den skal udgive hvad der er blevet bygget til interne eller eksterne kunder.
Det er vigtigt at huske på, at potentielt marketable ikke betyder, at man rent faktisk behøver at sende det ud på markedet. Det er en forretningsbeslutning, som typisk er påvirket af ting såsom “Har vi nok features eller nok af et kunde workflow til at kunne retfærdiggøre at sende det ud til vores kunder?” eller “Kan vores kunder håndtere endnu en ændring eftersom at vi lige gav dem en ændring for to uger siden?”
Potentielt marketable er bedre at tænke på som et stadie af sikkerhed på at hvad der er bygget under en sprint rent faktisk er færdigt, altså at der ikke er mere vigtigt ufærdigt arbejde (som f.eks. tests eller integrationer, osv) som skal færdiggøres før at resultaterne fra en sprint kan sendes ud på markedet, hvis det er forretningens ønske.
Rent praktisk set vil nogle projektgrupper måske over tid have forskellige definitioner af “done”. For eksempel, i tidlige stadier af spiludvikling kan det være, at det at have features der er potentielt marketable, ikke er økonomisk smart eller ønsket, på grund af den meget udforskende natur af tidlig spiludvikling.
I disse situationer er en passende definition af done måske et stykke af produkt funktionalitet, som er funktionelt nok og brugbart nok til at kunne genere feedback, som tillader projektgruppen, at beslutte hvilket arbejde der skal gøres i næste sprint, samt hvordan det skal gøres.
Sprint Review
I sutningen af hver sprint er der to yderligere test-og-tilpas aktiviteter. Den ene kaldes for sprint review.
Målet med denne aktivitet er at inspicere og tilpasse produktet der bygges. Kritisk til denne aktivitet er den samtale der finder sted mellem dets deltager, som inkluderer projektgruppen, stakeholders, sponsorer, kunder og interesseret medlemmer fra andre projektgrupper.
Samtalen er fokuseret på at gennemgå de features der lige er blevet færdige i konteksten af den overordnet udviklingsindsats. Alle der deltager får et klart overblik over hvad der foregår og har en mulighed for at hjælpe med at guide den fremadrettet udvikling for at sikre, at den bedste løsning for forretningen skabes.
Et succesfuldt sprint review resultere i et tovejs informationsflow. De personer, som ikke er medlem af projektgruppen kan synkroniseres op til udviklingsindsatsen og hjælpe med at guide dens retning.
På samme tid kan scrum medlemmerne få en dybere forståelse og påskønnelse for virksomheden og markedsføringsdelen af deres produkt ved at få feedback på fast basis på konvergensen af produktet mod glade kunder eller brugere. Et sprint review repræsenterer dermed en planlagt mulighed for at inspicere og tilpasse produktet.
Praktisk set, så vil folk uden for projektgruppen udføre intra-sprint feature reviews og give feedback for at hjælpe projektgruppen med at nå deres sprint mål.
Sprint Retrospective
Den anden test-og-tilpas aktivitet i slutningen af hver sprint er sprint retrospective. Denne aktivitet opstår efter et sprint review og før den næste sprint planlægning.
Hvor et sprint review er en planlagt tid til at inspicere og tilpasse produktet, så er sprint retrospective en mulighed for at inspicere og tilpasse processen. Under en sprint retrospective vil projektgruppen, scrum masteren og en Product Owner komme sammen for at diskutere hvad der virker og hvad der ikke virker med scrum og de tilhørende tekniske praksis.
Fokusset er på at kontinuerligt forbedre processen, hvilket er nødvendigt for at skabe en god projektgruppe. I slutningen af hver sprint retrospective bør projektgruppen have identificeret og forpligtet sig til et praktisk antal af proces forbedrende aktioner, som udføres af projektgruppen i den næste sprint.
Efter sprint retrospective er færdig, så starter hele cyklussen forfra igen – startende med den næste sprint planlægnings session, som afholdes for at beslutte hvad det nuværende vigtigste sæt af arbejde for projektgruppen er. Og dermed hvad projektgruppen bør fokusere på.
Konklusion
I dette indlæg er jeg gået i dybden med scrum praksis med fokus på en-til-en beskrivelser af Scrum Framework’s roller, aktiviteter og genstande. Der er andre praksis, som f.eks. højere-niveau planlægning og fremskridtssporende praksis, som mange projektgrupper bruger.
