Er du ny i rollen som Scrum Master kan der være mange spørgsmål der popper op omkring arbejdsopgaverne i funktionen. Min erfaring er at der findes ligeså mange implementeringer af rollen, som der findes Scrum Masters. I det følgende vil jeg forsøge at komme med en generalisering af hvilke aspekter jeg typisk ser som “klassiske” Scrum Master aktiviteter.
I teorien
På den officielle hjemmeside for Scrum ses følgende tekst i forbindelse med definition af Scrum Masterens ansvar:
“Scrum Master er ansvarlig for at sikre at Scrum er forstået og efterleves.”
Yderligere er der nævnt at denne er “servant leader” for teamet, samt at der skal ydes services til Product Owner, Development Team samt den omkringliggende organisation. Men hvad indebærer det?
Det mekaniske (important)
En af de første opgaver en Scrum Master påtager sig er at sikre at de mekaniske elementer i Scrum sættes i gang så hjulene kan begynde at dreje i maskineriet. Der indkaldes således til:
- Daily Standup
- Sprint Planning
- Sprint Review
- Sprint Retrospective
Typisk er Scrum Master også facilitator på disse møder – eller som minimum ansvarlig for at finde en facilitator på møderne – samt sikre at deltagerne møder tilstrækkelig forberedte op.
De bløde værdier (more important)
Det er essentielt at Scrum Masteren forstår at rollen ikke er hævet over andre medlemmer i teamet og at teamet ikke bør se det som en leder. En mere passende beskrivelse kunne være en “coach”. Scrum Masterens vigtigste rolle er nemlig at sikre at teamet har det godt og at de kan komme i flow på opgaverne så aftalt funktionalitet kan leveres ved udgangen af sprintet.
Hvad vil det sige at være i flow?
Begrebet stammer fra Mihaly Csikszentmihalyi, der i 1989 kom med følgende opsummering:
“Flow kan defineres som en tilstand af selvforglemmende opslugthed af en aktivitet, der fuldstændig lægger beslag på individets opmærksomhed og giver en fornemmelse af uanstrengt og spontant at kunne styre.”
At være i flow på sine opgaver er én af de bedste følelser man kan have og er en stor bidragende faktor i forhold til at etablere et “high performing team”, som defineret af Tavistock Institute i 1950’erne. For at bistå dette sikrer Scrum Master at fjerne enhver hæmsko (impediment) som teamet måtte opleve i løbet af et sprint i forhold til løsning af de aftalte opgaver. Eksempler på dette kan være lange svartider ved Product Owner, dårligt IT-udstyr, fejlende udviklingsmiljø, m.m. Det er ikke Scrum Masters opgave at løse disse problemer, men at sikre at de bliver løst så teamet kan komme tilbage i flow.
Udover at fjerne hæmsko, så er det også essentielt at sikre at Product Owner møder velforberedt op til Sprint Planning og Sprint Review møderne. Scrum Masteren har interesse i dette for at sikre teamets flow i det kommende Sprint. I samarbejde med Product Owner sikrer Scrum Master at elementerne på Product Backlog bliver defineret i en tilstand så de er “ready to sprint” for teamet – alle afklaringer som Product Owner kan varetage er udført og beskrevet på fornuftig måde. Yderligere er det vigtigt at Scrum Master sikrer at Sprint Review foregår på en ordentlig måde; at Product Owner bliver afkrævet et binært svar – ja eller nej – på spørgsmålet om de aftalte opgaver er løst som forventet/beskrevet i “done kriterier”. Er svaret ja, lukkes opgaven, men hvis svaret er nej, så placeres en ny opgave på Product Backlog til fremtidig prioritering. Det er vigtigt at Scrum Master sikrer at opgaver ikke “overlever” fra et Sprint til det næste, da det ikke afspejler teamets fremdrift og kan være med til at svække følelsen af flow.
I tillæg arbejder Scrum Master på kontinuert forbedring af teamets processer og samarbejdsformer via Sprint Retrospective. Læs mere om Sprint Retrospective i et af mine tidligere indlæg her på qed.
Se de øvrige indlæg i hands-on serien: