Jag skriver på en bok med arbetsnamnet “Nyckeln till Scrum”. Min erfarenhet säger mig att de som lyckas bäst med Scrum är de som inte bara kan metodens praktiska steg, utan som också förstår varför den är utformad som den är. Beväpnad med den förståelsen öppnar sig också vägen framåt, möjligheten att gå bortom Scrum. Det här är ett avsnitt som handlar om roller, som kanske kommer med i boken.
Enligt ordboken på min Mac härstammar ordet ”roll” från det inte längre använda franska ordet ’roule’, som syftade på den rulle med papper som skådespelarens roll stod skriven på.
Till skillnad från andra modeller beskriver Scrum bara några få roller. Tre stycken, närmare bestämt: produktägaren, scrum mastern och utvecklingsteamet. Vi har inga speciella roller för de som deltar i utvecklingsteamet, utan nöjer oss så.
Varför behöver vi roller överhuvudtaget?
Det handlar om förenkling. Över tiden kan vi lära oss att närmast intuitivt agera inom ramen för en viss roll, eller bete oss på ett visst sätt i vårt samarbete med en person som verkar i en viss roll. Vi behöver inte hänvisa till en lång lista som beskriver ansvar och befogenheter. Vi vet vad som gäller, helt enkelt.
Roller som verktyg är ett dubbeleggat svärd. De förenklar, men kan också förenkla för mycket. När du hör att jag arbetat som projektledare associerar du vissa beteenden och mandat med det. Du kanske kan tänka dig ungefär vad jag jobbade med, vilka typer av utmaningar jag brottades med och vilken sorts beslut jag fick ta. Tyvärr har du förmodligen fel. Inga två projektledarjobb är lika varandra.
En fara med namngivna roller är att vi tror att vi vet vad som gäller när vi egentligen inte vet. Eftersom vi tror att vi vet ställer vi inte frågor om rollerna. Vi beter oss som om vi vore överens och blir förvånade när problem uppstår, eftersom vi var så säkra på att vi förstått varandra.
Samma utmaning finns när det gäller rollerna i Scrum. På pappret ser de tydligt definierade ut, men i praktiken är det inte är fullt så enkelt.
När jag undervisar i Scrum brukar jag dela ut varsin specialgjord kortlek till grupperna på kursen. På varje kort står ett ansvarsområde eller en fråga. Jag ber grupperna dela upp korten i tre högar, en för varje roll i Scrum, så att rätt kort ligger på rätt roll. Jag förklarar att de är klara när de är helt överens om sorteringen. Det blir de aldrig.
På ett av korten står ”Kan du förklara den övergripande arkitekturen?”. Gruppen vrider och vänder på argumenten för att lista ut vem som egentligen borde besvara denna fråga. Det brukar bli jämnt skägg mellan produktägaren och utvecklingsteamet. Några hävdar bestämt att det är utvecklingsteamet som borde ta denna fråga. Andra är lika säkra på att det är produktägaren. Det brukar sluta med att man får lägga kortet åt sidan.
När vi efteråt går igenom övningen frågar jag deltagarna om de kan definiera ordet arkitektur. Utan undantag visar det sig att de som tycker att produktägaren borde fått frågan anser att arkitektur handlar om produkterbjudandets olika delar, som produktägaren självklart måste behärska för att kunna förklara produkten. De som röstar på utvecklingsteamet tycker istället att arkitektur handlar om den rent tekniska lösningen, som teamet ansvarar för. Olika definitioner leder till olika syn på ansvarsområdena.
Flera frågekort är svåra att placera eftersom de beror på vilken kompetens som finns var. En fråga lyder: ”Exakt hur är det tänkt att den här dialogrutan är tänkt att fungera?” Somliga svarar snabbt utvecklingsteamet. Produktägaren ska ju inte vara inne och pilla i detaljer, och naturligtvis har vi antingen en separat gränssnittsexpert med i teamet, eller minst en utvecklare som behärskar området bra. Andra protesterar. Deras utvecklingsteam består av programmerare som inte behärskar gränssnittsutveckling, och ser det därför som självklart att produktägaren är den man går till för denna typ av frågor. Ytterligare andra menar att frågan handlar om situationen när teamet inte kan komma överens, och arbetet blir lidande för att ett beslut inte tas. De menar att det är produktägarens jobb att kliva in och ta beslutet. Vid ett tillfälle påpekade någon att det kanske handlar om utveckling av ett gränssnitt för en operatörspanel i ett kärnkraftsverk, och att produktägaren därför är med och bestämmer även om de minsta detaljerna, eftersom de är en sådan avgörande framgångsfaktor för produkten.
Det är sällsynt att någon helt missförstått någon av Scrums roller – ändå blir tolkningarna helt annorlunda. Sammanhanget avgör tolkningen. Vi är inte ute efter den enda sanna tolkningen, vi är ute efter den tolkning som passar bäst, utan att göra våld på rollens grundläggande skrivelse.
En fördel med att inte skriva rollbeskrivningar med extrem detaljskärpa är att de blir brett användbara. Nackdelen, om man får säga så, är att vi måste tänka efter mer själva. Vi måste sätta in rollen i sitt sammanhang, och se vad som händer då. Vi måste applicera metoden i vår kontext, lite på samma sätt som skådespelaren måste tolka sin roll utifrån den scen han står på och den pjäs han spelar. Det finns inte en sann Hamlet, lika lite som det finns en färdig definition av vad det innebär att vara produktägare, scrum master eller medlem i ett utvecklingsteam. Allt vi får är papperet med rollen på, sen är det upp till oss att på darriga ben stappla ut på scenen och agera.
Vilka är dina erfarenheter av namngivna roller på jobbet?
