Overblik over interessenter og stadier i en Scrum-proces

Som softwarehus arbejder vi agilt på baggrund af Scrum-metodikken. Kort fortalt er Scrum en iterativ udviklings- og projektledelsesmodel, som er med til at sikre god kommunikation og tæt samarbejde imellem kunde, udviklere og slutbrugere fra start til slut i et IT-projekt. Du kan læse mere om Scrum i en af vores tidligere artikler her.

I dette indlæg vil jeg gøre dig klogere på, hvordan en Scrum-proces fungerer i praksis. Dette er med beskrivelse af de forskellige interessenters roller og opgaver, samt hvordan deres relationer er i en agil arbejdsproces. 

Scrum-model
Til at forklare de forskellige stadier en Scrum-proces indeholder, herunder interessenters roller, vil jeg tage udgangspunkt i Headfitteds egen Scrum-model, som forklarer den proces et softwareprodukt udvikles igennem.

Headfitted’s Scrum-model er illustreret af Mikkel Thormod, CTO i Headfitted ApS

Headfitted’s Scrum-model er illustreret af Mikkel Thormod, CTO i Headfitted ApS

Idémanden
Lad os begynde øverst i modellens venstre hjørne med kunden. Kunden er ikke nødvendigvis en ekstern kunde – det kan også være en intern ’kunde’, dvs. en person i virksomheden som er idémanden til et nyt produkt. Men for udviklingsteamet ses vedkommende som en kunde, man skal udvikle noget for. 

Rent praktisk foregår det således, at kunden henvender sig til Product Owneren og fremlægger sin idé. Product Ownerens opgave er nu at sikre return on investment ved udvikling af produktet. Vedkommende vurderer således, hvor mange timer og penge man skal bruge på at udvikle produktet – og om det kan betale sig. 
Alt efter hvem kunden er, kan Product Owner være CEO, CTO – eller en medarbejder som har fået til opgave at finde ud af, hvordan produktet bedst giver business value. Derfor udarbejder Product Owneren i samarbejde med kunden en backlog hvor der står beskrevet, hvilke funktioner de gerne vil have udviklet i et softwareprodukt. Backloggen sendes til udviklingsteamet. 

 

 Forventningsafstemning
Udviklingsteamet estimerer tiden på de forskellige issues i backloggen. Det kan lyde simplet, men det er det som regel ikke. En backlog er opbygget således, at man beskriver de ting man allerhelst vil have lavet først. Det er dog bedst at beskrive så lidt som muligt i backloggen, så udviklingsteamet stiller spørgsmål til Product Owner. Somme tider er det nemmest at diskutere mundtligt, hvordan issues i backloggen skal forstås.

 

Daily Scrum
Som følge af kommunikationen mellem Product Owneren og udviklingsteamet, bliver parterne enige om hvilke opgaver der skal løses først. Det vil sige, at der oprettes et sprint med opgaver, som udviklingsteamet arbejder på mellem 14 dage og en måned, alt efter hvad estimeringen af opgaverne lyder på.

Udviklingsprocessen styres af en Scrum-Master som holder styr på, om de enkelte opgaver under sprintet følger tidslinjen. Scrum-Masteren fungerer derfor som projektleder der holder styr på, hvornår nye sprints er klar til at blive gennemført, og hvornår udviklingsteamet har et fysisk produkt, de kan sende til test. 
Et af de vigtigste elementer under udviklingsprocessen, er de daglige Scrum møder, også kaldet Daily Scrum. Her mødes udviklingsteamet og Scrum-Masteren, hvor de bl.a. diskutere, hvorvidt der er faktorer som gør, at udviklerne sidder fast i udviklingsprocessen. Hvis dette er tilfældet, er det Scrum-Masterens opgave at gøre således, at udviklerne kan fortsætte deres arbejde.

 

Brugertests
Ved afslutning af hvert sprint, har udviklingsteamet som oftest et Potentially Shippable Product. Det vil sige, at efter hvert sprint har man et produkt man kan ’røre’ ved, og som man kan bygge videre på i efterfølgende sprints. Fordelen ved at have et fysisk produkt er, at man faktisk kan trykke på ’go’-knappen hvis det er det man ønsker. Men i stedet vil man typisk sende produktet til test hos de faktiske brugere af det kommende produkt. 

Her vil brugerne komme med feedback til, hvordan de oplever produktet. Både med henblik på produktets visuelle stil, men også dets funktioner. Det store spørgsmål er nu, om produktet lever op til brugernes forventninger og behov. 
Product Owneren modtager brugernes feedback, og han vurderer igen, hvor mange timer og penge man vil udvikle for evt. nye tiltag. Hvis dette er tilfældet, begynder samme proces igen.

Testningen er primært for, at vi som udviklingshus undervejs bliver klogere på, hvordan et nyt softwareprodukt skal udformes. Det kan ske, at brugernes behov har ændret sig siden Product Owneren og kunden skrev den første backlog - eller at der i mellemtiden er kommet andre krav til produktet udefra, fx ny lovgivning.

 

Retrospektive
En vigtig ting når vi arbejder agilt, handler om at være retrospektiv. Det er den proces, der er skitseret i form af den nederste cirkel i Scrum-modellen.  

 I retrospektive-stadiet er det vigtigt at Product Owner, Scrum-Masteren og udviklingsteamet får diskuteret, hvad der rent procesmæssigt gik godt, og hvad der gik mindre godt.
Oftest besvares spørgsmål som: Hvad kan vi konkret gøre for at forbedre processen? Og hvordan kan vi sikre at det der gik godt, kommer til at gå godt igen?

Opsummering
Det samlede resultat af Scrum-proces er et softwareprodukt, der er tilpasset brugernes behov. Scrum-processen sikrer en løbende udvikling af produktet, både teknisk og visuelt, desto klogere vi som udviklingshus bliver på brugernes og kundens forventninger til softwareproduktets kunnen. Samtidig sikrer processen en tæt kommunikation mellem brugere, Product Owner og udviklingsteam, så der ingen misforståelse er omkring, hvordan softwareproduktet skal udvikles.