Det er sådan lidt meta at være Scrum Master. Hvor udviklingsteamet har ansvaret for at lave arbejdet, Product Owneren (POen) har ansvaret for at teamet laver det rigtige arbejde (og dermed det rigtige produkt), så har Scrum Masteren ansvaret for at hjælpe teamet og POen med at få succes. Deres mulighed for succes er Scrum Masterens succes.
Inspireret af “42 tasks for a Scrum Master’s job” og Scrum Master checklist tænkte jeg, at jeg ville skrive om hvad en Scrum Master egentlig bruger sin tid på for at sikre denne succes. Det blev så langt at jeg har lavet det til en serie af blogindlæg.
Dette indlæg er specifikt om Scrum Masterens arbejde med at sikre Product Ownerens succes. Sådan et indlæg kan nemt blive et langt indlæg om formel Scrum, men underliggende skal man huske at man ikke hjælper en person med at få succes med en løftet pegefinger om at de gør alt forkert. Man sikrer deres succes ved at tilbyde hjælp – ved at bygge dem op, ikke ved at pille dem ned. Oprigtig ros og bemærkning af hvad der går godt er en stor del af en Scrum Masters arbejde (og forhåbentlig personlighed). Bemærk hvad der giver POen energi og se om du kan tilføje mere af det.
En Scrum Master er både coach, partner og heppekor for POen, såvel som den der bearbejder organisationen for at forbedre POens arbejdsvilkår.
For at finde ud af hvad der er værd at kigge nærmere på kan POen og Scrum Masteren kigge på disse spørgsmål i fællesskab (og hver for sig).
Om processen:
- Ved POen hvad der forventes af dem i Scrum?
- Er detaljeniveauet på backloggen fornuftigt (groft sagt: finkornet i toppen og grovkornet i bunden, hvilket er med til at gøre backloggen overskuelig)?
- Er der en definition of ready f.eks. INVEST?
- Overholder stories på backloggen definition of ready?
- Repræsenterer backloggen produktvisionen fuldt ud?
- Har POen et overblik over stakeholders?
- Bliver stakeholders hørt?
- Er der en Definition of Done?
- Accepterer POen kun arbejde som overholder Acceptance Criteria?
- Håndteres teknisk gæld?
- Har POen overblik over om vi holder planen?
- Har POen en sund tilgang til kravsændringer?
- Kender POen teamets velocity?
- Er releaseplanen holdt rimeligt up-to-date?
- Fungerer sprint review?
Om forholdet til teamet:
- Har teamet altid den information som de skal bruge fra POen?
- Har POen en god dynamik med teamet?
- Kan POen motivere teamet?
- Respekterer teamet POens beslutninger?
- Lytter POen til teamet?
- Respekterer POen teamets rolle i planning og er hun til rådighed under planning?
Om forholdet mellem POen og Scrum Masteren:
- Har POen en god dynamik med Scrum Masteren?
- Respekterer POen og Scrum Masteren hinandens rolle?
- Lytter POen og Scrum Masteren til hinanden?
- Bruger POen og Scrum Masteren tid på hinanden?
Om forholdet til organisationen:
- Har POen vilkår i virksomheden som gør at hun kan udføre sit arbejde (OVERVEJ: hvilke krav stilles til POen, har hun beslutnings-kompentence, er der et godt samarbejde med andre POer og lignende problemstillinger)?
Hvis svaret er nej til et af disse spørgsmål, kan man sætte det på dagsordenen.
Desuden: Har POen brug for hjælp til
- at skrive user stories?
- at finpudse visionen?
- at formidle visionen?
- at prioritere backloggen?
- release planning?
- at arbejde med innovation?
- at repræsentere teamet overfor stakeholders?
Hvis svaret er ja til en af disse, så kan man vælge at sætte kræfter ind her.
Derudover kan der kigges på POens personlige omstændigheder, såsom stressniveau, læring/inspirationskilder og erkendelse af hvor der er brug for hjælp med at udfylde den komplekse rolle som PO.
I rollen som Scrum Master kan man nemt forfalde til at være proces-rytter, men den virkelige udfordring i rollen er at føre andre frem til succes. Det er ikke noget man kan lære på et 2 dages certificerings-kursus, men snarere noget der kræver livslang læring, interesse for menneskehedens og organisationers finurligheder og en ærlig omsorg for sine kolleger.
Overstående liste er naturligvis ikke en udtømmende liste over hvor man kan kigge efter forbedringer, som kan øge chancen for succes for POen. Tilføj endelig dine egne bud i kommentarfeltet.
Glimrende og pragmatisk overblik 🙂
Min erfaring siger mig at så snart produktet når en hvis kompleksitet (overraskende lav, i hvert fald for mig) så er det ikke nok med en PO. Der skal selvfølgeligt være en og kun en med ansvaret, men vedkommende har brug for alt det hjæp der kan skaffes til ting som kunde & bruger involvering, specialist viden om området og til udformning af Backlog Items og tilhørende artefakter (MockUps, forretningsregler etc).
Så mit bud på en tilføjelse til din liste er, at man skal hjælpe sin PO med uddelegering af opgaver.
God tilføjelse Daniel. Jeg oplever at det kan være meget svært at indrømme at man som PO ikke kan løse alle opgaver som kommer med titlen, men rollen er kompleks. Den kræver: God domæneviden, evnen til effektiv kommunikation, evnen til at lytte og mediere konflikter, at man kan være informationsaggregator og innovativ visionær med disciplineret overblik. Styr på forretningen med forståelse for og tilgængelig deltagelse i udviklingsprocessen. I mange tilfælde forventes endda også teknisk forståelse. Ikke mærkeligt at det er en stor mundfuld – især for dem som ikke er fuldtidsPOer. Uddelegering er ofte nødvendigt.
Og i forhold til arkitekturen.
Med hver iteration sikrer vi så at vi et har et fornuftigt fundament for den endelige løsning?
Kan hele teamet stå inde for den nuværende arkitektur eller er der en arkitektonisk gæld man bærer fremad?
Jep. Arkitekturen skal man heller ikke glemme. To gode tilføjelser.