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

Pragmatisk eller dogmatisk? Progmatisk!

Scrum är ett enkelt ramverk. Några få regler bildar tillsammans ett system av aktiviteter som kan användas för att styra komplext arbete. Att ta bort en väsentlig del ur ett fungerande system påverkar alltid systemet som helhet. Tar man till exempel bort återblickarna ur Scrum minskar sannolikheten för framgång omedelbart. Man får lika stora problem, om inte större, om man försöker applicera Scrum dogmatiskt. Den som aldrig kan tänka sig att kompromissa kommer inte att ha någon framgång när det gäller att driva förändring. Har du själv jobbat med någon som aldrig kan kompromissa förstår du varför. Så hur ska man göra? Följa Scrum dogmatiskt för att inte förstöra arbetsmetodens effektivitet, eller vara pragmatisk för att inte alienera sig från andra människor? Jag föreslår en kompromiss. Låt oss kalla den en progmatisk hållning . Den progmatiska hållningen fungerar så här. Vi är å ena sidan aldrig rädda för att tänka själva och göra förändringar i Scrum, men å andra sidan gör vi

Hur lång ska en sprint vara?

Jag fick en fråga på mailen som löd: "Fick frågan av min chef varför vi har 3 veckors sprintlängd. Vet inte riktigt vad jag ska svara, det bara blev så. Vad säger du?" En sprint i scrum är en synonym för iteration. Det som utmärker scrums sprintar är att vi vill att de ska vara väldigt fokuserade och att de ska sluta i klar, potentiellt levererbar, produkt. Potentiellt levererbar betyder att om vi ville  så kunde vi skeppa ut produkten med ganska lite efterarbete. Tydlig och regelbunden feedback krävs för att styra utvecklingsarbete. Längre sprintar betyder att det blir längre tid mellan större avstämningar av nuläget, vilket ökar risken att vi drar iväg i fel riktning, eller att omvärlden ändrar sig så mycket under sprinten att det vi bygger hinner bli irrelevant. Ibland kan det kännas som om man lägger för mycket tid på planerings- och uppföljningsworkshops, vilket leder till idén att göra sprintarna längre. Jag vill hellre börja med att undersöka om arbetsmötena k

Introduktion till story points

Estimering med storlekspoäng är en sån där sak som somliga älskar och andra tycker är totalt förvirrande. Jag gillar det lugna sköna tempot i den här korta snutten om story points från Rally Software.