Fortsätt till huvudinnehåll

Både Scrum Master och teammedlem?

En vanlig fråga som jag brukar få har att göra med vad som händer när en person bemannar två roller i Scrum. Frågan lyder: kan man vara både Scrum Master och medlem i utvecklingsteamet?

Först lite bakgrund till svaret. Mitt standardsvar på alla frågor som börjar med orden "kan man" eller "får man" är ett rungande ja. Självklart kan man göra som man vill, och självklart får man själv (eller snarare tillsammans med sina kollegor) bestämma hur man ska göra. Man behöver inte tillstånd från en expert eller en arbetsmetod. Det kan tyckas som en detalj, men språket styr tanken. Därför tycker jag det är mer hjälpsamt att börja frågan på ett annat sätt. Så här: Vad kan konsekvenserna av att vara både Scrum Master och teammedlem bli?

För mig är det lättast att hitta till ett begripligt svar om jag börjar med att fråga mig själv vad syftet är med att dela på Scrum Master och teammedlemsrollen.

En anledning till uppdelningen är att redan i förväg bygga en beredskap för framtida utmaningar. När ett projekt får upp farten kavlar folk upp ärmarna och kör så det ryker. Finns en deadline runt hörnet ökar trycket ännu mer.

Utvecklingsteamet i Scrum har som uppgift att arbeta tillsammans för att bygga produkten. De kommer att vara under tryck från både sig själva och omgivningen att få mycket gjort på kort tid.  Produktägarens ansvar är att göra produkten till en framgång. Framgången hänger på att rätt funktionalitet kommer ut i rätt tid, till rätt kostnad. Både teamet och produktägaren kommer med andra ord att känna det fulla trycket av ett utmanande projekt.

Scrum Mastern är också med i matchen, men från ett lite annat perspektiv. På ett sätt kan man säga att Scrum Masterns jobb är att behålla ett nyttigt lugn när alla andra blir galna. Scrum Masterns roll är att hjälpa alla andra att uppnå sina mål med hjälp av Scrum. I den mån andra beter sig kontraproduktivt är det Scrum Masterns jobb att belysa detta på ett sätt som gör att en beteendeförändring kommer till stånd.
Genom att redan från början identifiera Scrum Master-rollen som separat från utvecklingsteamet och produktägaren kan vi i någon mån redan från början vara överens om att det är någons explicita ansvar att backa ett par steg när börjar gå undan, och betrakta situationen från en viss distans.

Så: kan man vara både Scrum Master och teammedlem på samma gång? Självklart, men här är några av konsekvenserna:
  • När organisationen som mest behöver någon som lugnt och rationellt kan observera en kaotisk situation, och styra mot en anpassning - en Scrum Master - är den personen med stor sannolikhet precis som alla andra upptagen med att släcka bränder.
  • Även om tempot i projektet för tillfället är lugnt och produktivt finns det alltid långsiktiga utmaningar att jobba med. Min erfarenhet är att det är lätt att försaka en av de roller man tagit på sig, av gammal ohejdad vana. En utvecklare som också är Scrum Master är förmodligen mer benägen att göra ett testskott på en ny intressant teknik, än att gå till företagets lokalchef och diskutera möjligheten att förbättra kontorslayouten.
  • Att växla mellan två uppgifter betyder inte att man kan lägga femtio procent av tiden på respektive uppgift. En del tid, ofta mer än man tror, går åt till att växla mellan och koordinera de olika uppgifterna.
Är det då alltid en dålig idé att vara både teammedlem och Scrum Master? Nej, jag vill inte vara så kategorisk. I några situationer har jag sett det fungera alldeles utmärkt. Det har varit i organisationer där ledningen gett sitt fulla stöd åt användningen av Scrum, och därför aktivt hjälpt teamet på alla sätt och vis. I den situationen är trycket mindre på Scrum Mastern att jobba med lång- och kortsiktig hindereliminering, och därför har en person kunnat bära både Scrum Masterns och teammedlemmens hattar.

Kommentarer

Om man bortser från ett av standardsvaren på den frågan som lyder: "Ja, många agila team ser rollen som just en roll och låter den vara ambulerande (d.v.s. man turas om att ha rollen)". Så har jag själv deltagit i projekt där en scrum master blir en lite för lätt börda för en heltid. Då har jag gärna jobbat med lite mer långsiktiga förbättringsbitar (byggsystemet, rapportgenerering, teststrategier). Jag har kunnat lägga ca. 30-50% på sådana aktiviteter vilket har varit bra för min utvecklarsjäl. Jag skriver dock helt under på att man som scrum master bör minimera sitt utvecklaråtagande under en iteration. Fin artikel!
Tobias Fors sa…
Välkommen hit Måns, och tack för feedbacken!
Tobias Fors sa…
Oh, och en grej till. För mig är Scrum Master-rollen en sann ledarskapsroll som växer i takt med att man lär sig vad en skicklig ledare kan åstadkomma. Många kanske drar en lite för snabb liknelse mellan chef och ledare, men det är ledare jag tänker på här, inte chef. Vi är alla ledare ibland, och kan därför alla ha nytta av att förstå grunderna för ledarskap. För mig har Jerry Weinbergs läror varit otroligt viktiga för detta. I höstas var jag på AYE-konferensen i Phoenix, och i mars i år var jag med på hans PSL-workshop, som han kört i 34 år och som fortfarande är going strong, eller kanske stronger than ever, eftersom han itererat fram förbättringar i över tre årtionden. Dessa upplevelser i kombination med hans böcker, särskilt Quality Software Management 1 till 4 och Becoming a Technical Leader är just nu min största källa till inspiration. Jag och Magnus Ljadas jobbar just nu för fulla muggar för att realisera en PSL-workshop här i Sverige. Att Jerry kommer till Sverige är sjukt unikt, men han har faktiskt varit här förut, för ganska länge sedan, då för att köra PSL inhouse för ett större svenskt bolag. Kolla in http://www.citerus.se/psl. Jerry kommer att köra workshopen tillsammans med Esther Derby och Johanna Rothman, som också är inspirerande så det heter duga. De fyller i med de där så kallade "mjuka" bitarna, du vet de där som är de riktigt hårdsvåra sakerna ...
Sonja sa…
Hmmmm roller hit och dit... Ofta kan det väl vara ännu trassligare? Kurt är Scrum Master, han utvecklar i teamet och han är också chef. Sonja är Product Owner, Kurt är hennes chef. Sonja ingår också i teamet, hon testar.
Tobias Fors sa…
Hej Sonja! Haha, ja det där lät lite småtrassligt.
Anders S sa…
Om Scrum Master är en sann ledarskapsroll (vilket jag håller med om) så anser jag att denne åtminstone måste finnas i teamets absoluta närhet. Att vara närvarande är viktigt. Kanske som en medlem i teamet, men i så fall med anpassade eller begränsade utvecklaruppgifter.
Tobias Fors sa…
Hej Anders! Jag håller med - närhet är helt avgörande. Scrum mastern behövet kunna se med egna ögon vad som händer från dag till dag.
Anders S sa…
En relaterad fråga: Vad får det för konsekvenser om Scrum Master och Produktägare är samma person? Det ända jag kan komma på är att det sannolikt blir en alltför stor arbetsbörda.
Tobias Fors sa…
Anders: en anledning att hålla de två rollerna isär är att det finns en dynamik mellan dem som är bra att bevara. Produktägaren är ansvarig för att ta produkten i rätt övergripande riktning, så att den blir en framgång på marknaden, hos användarna. Scrum masterns jobb är att hjälpa alla i organisationen att använda Scrum framgångsrikt. En del av Scrum masterns jobb är att hjälpa övriga hålla koll på det långsiktiga kvalitetstänket. Detta är ofta det första som ryker när det behöver gå fort. Att ha en Scrum master som kan hjälpa till att balansera upp produktägarens mer leverans- och hastighetsorienterade perspektiv kan hjälpa.

Populära inlägg i den här bloggen

Vad sprintplanering och glassinköp har gemensamt

En missuppfattning som lever kvar kring lättrörliga metoder är att de inte har tillräckligt med planering. Det är precis tvärtom, vi gör massor av planering. Dels gör vi så mycket planering som behövs när vi ska starta ett nytt projekt, dels gör vi granskning och revidering av planerna med en regelbunden rytm. Eftersom vi planerar så mycket behöver vi vara mycket effektiva planerare.

Varje sprint i Scrum börjar med en planeringsworkshop där produktägaren och teamet tillsammans väljer ut rätt mängd viktigt arbete för sprinten. Planeringsarbete kan lätt dra ut på tiden, särskilt när vi eftersträvar precision. Just därför är sprintplaneringen i Scrum begränsad till max en arbetsdag: sprintens första dag. Vissa team märker efter några sprintar att man inte ens behöver hela dagen för att göra en bra plan.

En effektiv sprintplanering kräver att samtliga inblandade kommer väl förberedda. Då kan planeringen genomföras inom tidsramen, och sluta med ett genuint åtagande från samtliga inblandade a…

Sprintbacklog på väggen, produktbacklog elektroniskt

En artikel på InfoQ om för- och nackdelar med att sätta upp sina planer och sin information på väggen fick mig precis att komma ihåg att jag har några tips att dela med mig av.

Sprintbackloggen är, som du redan vet, utvecklingsteamets eget verktyg för att hantera sitt åtagande i sprinten. Med hjälp av sprintbackloggen kan teamet granska och anpassa sitt arbeta på daglig basis. Detta är viktigt, eftersom utvecklingsteamet är själva motorn i Scrum. För att sprintbackloggen ska vara relevant och användbar måste den vara aktuell. Det kommer den att vara givet att två förutsättningar är uppfyllda.

Den första förutsättningen är att teamet verkligen tagit på sig ansvaret att planera och följa upp sitt eget arbete, eftersom man ser nyttan med att göra det och därför vill göra det.

Den andra förutsättningen är att det är extremt enkelt att hålla sprintbackloggen uppdaterad. Vanliga orsaker till att det inte är enkelt är att man lagrar sprintbackloggen i ett verktyg som alla inte behärskar till fu…