Bli en Super Scrum Master 2 - arbeta som Scrum Master

Nu tänkte jag komma in på lite mer konkreta arbetsuppgifter för en ScM och hur de olika ceremonierna kan anordnas för att få ut så mycket som möjligt av dem.

En liten, men ack så viktig ceremoni är de korta daily standups som ingår i Scrum. Syftet med dessa träffar är att underlätta samarbetet mellan teammedlemmar och skapa en arbetsmiljö med högt i tak och där alla i teamet hela tiden har full insyn i vad de andra teammedlemmarna gör.

Jag skrev korta standups och med det menar jag att de ska hållas väldigt korta och inte vara föremål för långa diskussioner och samtal. Fokusera i stället på att var och en i teamet får besvara tre frågor:

• Vad gjorde jag igår?
• Vad ska jag göra idag?
• Finns det några hinder i vägen för mig?

Ytterligare en rekommendation är att hålla daily standups stående. Hörs lite på namnet… Anledningen till det är att detta också bidrar till att hålla tiden nere. Om alla sitter ner i sköna fåtöljer eller kontorsstolar i ett sammanträdesrum blir det betydligt svårare att timeboxa mötet. En effektiv daily standup i ett team på max tio personer ligger på max en kvart, helst ännu kortare.

Om du som ScM konstant överskrider den tiden kommer medlemmar efter hand att känna att detta tar alltför mycket tid i anspråk och börja ifrågasätta vad vi får ut av det och om det är värt det.

Om någon tar upp ett hinder så kan det vara frestande att försöka ge sig in och försöka lösa det på en gång – gör inte det! Detta är en sak som kan diskuteras utanför daily standup annars är det stor risk att det drar ut på tiden. Här har du som ScM en viktig uppgift i att avbryta dessa diskussioner på ett snyggt sätt så att ingen känner sig trampad på tårna eller sårad.

Sista saken jag vill ta upp är att se till att hålla daily standups vid samma tidpunkt och på samma plats varje dag. Detta skapar en naturlig rutin hos alla och underlättar deltagandet från alla medlemmar i teamet.

Sprintplaneringen är en kritisk aktivitet där både Scrum Master och Product Owner har centrala roller. Som ScM är det viktigt att förbereda sig ordentligt innan sprintplaneringen genom att läsa in sig på alla mål och syftet med kommande sprint. Anledningen till detta är att det blir lättare för dig som ScM att berätta för teamet om de kommande målen som ska uppfyllas och samtidigt skapa en bättre förståelse för vad vi behöver göra i nästa sprint.

Innan mötet är det bra om du som ScM sätter dig ner med teamet och förklarar aktiviteten och sätter ord på vad som ska göras och varför. Det är betydligt enklare för teamet att vara delaktiga och engagerade om de också vet vad som förväntas av dem. En annan sak som är viktig är att produktbackloggen är tydlig och prioriterad.

Det underlättar ganska rejält om alla vet vad som är viktigast genom att studera backloggen och det blir betydligt krångligare om ni ska inleda sprintplaneringen med att prioritera allting i backloggen.

Som vanligt är det också mycket upp till ScM att se till att inte teamet drunknar i oändliga diskussioner om olika saker. Tänk på att tekniker är tekniker och det är lätt hänt att de fastnar i detaljerade diskussioner om vilka krypteringsalgoritmer som är att föredra nu och i framtiden och hur kvantdatorerna kommer påverka alla algoritmer framöver mm mm.

Här är det viktigt att du som ScM känner ett ansvar för att det övergripande målet med sprintplaneringen uppfylls och att ni håller tidplanen.

Ett vanligt problem i samband med sprintplaneringen är att teamets medlemmar tenderar att bli lite för tillmötesgående och lova lite för mycket. Jag har full förståelse för att personer gör det, men samtidigt kan det slå tillbaka ganska ordentligt om teamet inte kan uppfylla alla löften.

Det jag har sett i de team jag har arbetat med är att det snarare är bättre att lova lite för lite och sedan fylla på med saker om det uppstår utrymme. En viktig del i planeringen handlar om att beräkna vilken kapacitet teamet har och i sin enklaste form kan du som ScM definiera att en storypoint motsvarar åtta timmars arbetstid, alltså en arbetsdag.

Om du då ska beräkna kapaciteten för ett team på tio personer i en sprint på tre veckor så blir det 10 personer x 3 veckor x 7 dagar = 210 story points (SP). Men ScM och Product Owner (PO) är inte medräknade så där blir vi av med 2x3x7=42 SP och alltså återstår 168 SP. Dessutom måste du som ScM räkna med en viss overhead och utrymme för saker som inte ingår i den vanliga planeringen. Om vi antar att 15% går till detta så försvinner ytterligare 0,15x168= ca 25 SP och kvar blir då 143 SP. Sen har vi kanske två personer som ska vara lediga, den ena i två veckor och den andra i en vecka. Det innebär att ytterligare 3x1x7=21 SP försvinner vilket ger oss slutsiffran 122 SP som också blir teamets kapacitet under sprinten.

När ni nu planerar in allt ni ska göra i sprinten är 122 det magiska talet. Givetvis är det svårt att planera alla aktiviteter så att exakt siffran 122 uppnås, men kan ni komma i närheten är det betydligt större chans att teamet också klarar av att leverera allting som ni har lovat och commitat er till.

Även om det är PO som ansvarar för backloggen kan du som ScM också bidra till att prioritera alla saker i den. Ju mer du underlättar detta arbetet desto tydligare kommer backloggen att vara och desto mer användbar blir den, både under sprintplaneringen och det löpande arbetet.

Det är alltid bra med olika infallsvinklar och ju tätare PO och ScM kan samarbeta desto bättre.

Ju mer insatt du som ScM är i POs arbete desto mer kommer ni också att få ut av samarbetet. Jag har i mina tidigare uppdrag/anställningar flera gånger fått höra att:

• Ja, men det där är väl egentligen ScMs ansvar och arbetsuppgift
• Det där ingår inte i mina arbetsuppgifter. Det är PO som ska hantera det

I de allra flesta av dessa fall kunde de inte haft mer fel. Tänk på att fokusera mer på vad teamet ska leverera och inte så mycket på vad som ingår i de olika rollerna. Det känns ju lite som att gå tillbaka till 80-90-talet när alla skulle ha ansvarsbeskrivningar med exakta specifikationer och så fort det kom in en arbetsuppgift som inte riktigt passade in fanns det inte heller någon som kunde ta hand om den. Därför är det varmt välkommet att ScM hjälper och stöttar PO i alla lägen.

Extra viktigt blir det när saker och ting gnisslar eller när det uppstår ett skav någonstans i processen. Detta kommer också bidra på sikt till att backloggen är välskött och att alla i teamet hela tiden vet vad som förväntas.

Om du, som ScM, lyckas med det jag skrivit om har du kommit en bra bit på väg mot att bli en SScM, men en annan viktig arbetsuppgift som vi bara har snuddat vid än så länge är hur du som ScM ska hantera hinder/risker och annat som dyker upp och gör vattnet i bägaren grumligt.

Mer om detta i nästa artikel.