… og hvad vil det sige at være Scrum Master for et team? De overvejelser har jeg gjort mig en del af i den sidste tid, da jeg har fået et Scrum Master lignende ansvar for et nyt team.
Den klassiske Scrum Master
Ifølge Scrum Guide er en Scrum Masters overordnede formål formuleret således:
“The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.”
Så en klassisk Scrum Master er ansvarlig for ceremonier og at holde teamet på den rette Scrum-vej – Scrum Guiden forholder sig ikke til andet. Hvad det så i praksis vil sige, at en Scrum Master laver, er helt op til den enkelte. Læser man Thereses indlæg om Scrum Master-arketyper, kan man se hvor generel denne definition er.
SAFe Scrum Master
SAFe udvider definitionen en smule:
“The SAFe Scrum Master is a servant leader who:
- helps assure that the team follows the rules of Scrum and SAFe
- helps the team meet their daily and iteration objectives
- works to remove impediments in the organization
- helps manage the teams relationships with outside stakeholders
- facilitates team continuous improvement
- coordinates solution implementation and delivery with other Scrum Masters on the Release Train.”
Som jeg læser beskrivelserne, mener jeg, at man kan frygte, at en SAFe Scrum Master bliver presset til at have andet, end teamets bedste på sinde, som der ellers lægges op til i den klassiske Scrum Master-definition ovenfor. Ron Jeffries har skrevet lidt om, hvordan SAFe kan forbedres, heriblandt Scrum Master-rollen. Som jeg ser det, er rollen snævret mere ind og dermed er det lidt mere klart, hvad en Scrum Master skal i et SAFe setup.
Den løse definition
Hvad nu hvis et team har tilpasset processen så meget, at det begynder at løbe uden for, hvad der står i Scrum Guide? Kan man så stadig med god samvittighed kalde rollen for “Scrum Master”? Joakim Sunden har skrevet lidt om hvordan “Scrum Master”-titlen blev til “Agile Coach” hos Spotify. Her startede de også med at sige, at de kørte Scrum for alle teams men lærte efterhånden to ting:
- At Scrum ikke passer til alle teams.
- At der stadig er værdi i at have en person tilknyttet med teamets samarbejde for øje.
Min erfaring siger mig. at når de fleste (på nær folk i SAFe-verdenen 🙂 ) snakker om en Scrum Master, mener de ikke en Scrum Master i den traditionelle forstand men mere i den lidt løsere Agile Coach-forstand.
Agilt niveau
Jeg mener at når både team og organisation har nået et vist agilt niveau, er det ikke længere en vogter af Scrum ceremonier teamet har brug for, men en agile coach i videre forstand. En der kan tage et bevidst valg om næste skridt på den agile rejse; en rejse som både organisation, team og coach er ude på.
Men har jeg ret?
Jeg er rigtig meget på samme vogn som dig. Jeg havde ikke mødte begreberne fra indlægget du linker til (Scrum Mum passer ret godt med at jeg her på stedet beder folk om at sladre til mor når de bliver afbrudt i deres arbejde), men de klinger rigtigt for mig.
Jeg har læst lidt her og der om SAFe, og jeg har sådan en snigende følelse af at det er lige lovligt styrende. Non-agile i forklædning om man vil. Det er jo svært med overordnede, fortolkningsåbne definitioner at vide hvad der menes, men generelt er jeg på vagt overfor konstruktioner der lugter af kontrol og måltal og glad for konstruktioner som hjælper med fremdrift og engagement.
Positivt for det SAFe du har citeret er ordene “servant leader”. Det er for mig det helt centrale i en scrum master / agile coach. Det kunne med fordel udbredes til andre dele af ledelsen også, i bytte for megen af den styring og administration man i daglig tale påstår er ledelse.
Om facilitatorens rolle synes jeg der gælder de samme trin som for al læring (agile, kampkunst, håndværk, instrumenter, etc):
1) Byg fundamentet (Shu / protect)
2) Bliv flydende (Ha / detach)
3) Transcender (Ri / leave)
Efterhånden som holdet bliver flydende og bevæger sig mod transcendens af systemet, vil facilitatoren have mere plads til at løfte den omkringliggende organisation og til at hjælpe holdet med at lægge mere ambitiøse mål for deres udvikling. Her synes jeg faktisk noget af det sværeste er at engagere folk til at tænke på hvordan tingene kunne være. Det kan være svært at drømme, hvis den omkringliggende organisation opleves som urokkelig. Men det er bestemt samarbejdsmesterens medsansvar at hjælpe holdet til at opsøge nye arbejdsgange.
Synes jeg.
Jeg har slet ikke bevæget mig ind på ScrumMaster / Agile Coach som facilitator. Men det er helt sikkert også en stor del af det samlede ansvar (hvordan afhænger selvfølgelig af konteksten).
SAFe har jeg ikke konkret erfaring med. Det skal dog ikke stoppe mig for at have en holdning 😉 Jeg er ikke som sådan bekymret, men dog lidt påpasselig af samme årsager som dig.
Meget enig i Shu-Ha-Ri betragtningen omkring læring; som facilitator, som ScrumMaster og ikke mindst som team! Har man fået mere blod på tanden omkring “agil modenhed” i teams og organisation er der masser af litteratur der ude. Lige for tiden er jeg fascineret af Agile Fluency ( http://agilefluency.com/ ). Det har givet anledning til reflektion omkring de organisationer og teams jeg har været i kontakt med – og min egen rolle derved.
Jeg har lidt erfaring med SAFe (5 måneder), og min konklusion er at det er hvad man gør det til. SAFe kan bruges som skohorn til at få styring og non-agilitet ind i en agil organisation og det kan bruges til at få agilitet og åbenhed ind i en non-agil organisation. Thoughtworks anbefaler “hold” på SAFe i deres seneste teknologiradar – fordi det er nemt at gøre forkert (http://www.thoughtworks.com/radar/techniques).
Når man sidder som Scrum Master i en SAFe-verden oplever jeg at man får lidt mere at lave med hensyn til koordinering mellem teams og evaluering af fælles (pr. release train) udfordringer, men samtidig har man en større løftestang til at kæmpe med impediments, så på den del af rollen får man mere action pr. tid brugt (med mindre selvfølgelig at man havde opgivet at løbe med impediments i forvejen). SAFe er absolut kun til store organisationer.
Mine teams hverdag har ikke ændret sig meget siden indførslen af SAFe – de kører stadig Scrum på teamniveau og det er mest PO’ens og SM’ens rolle der har udviklet sig en del. Til gengæld føler jeg at vi har fået bedre styr på hvad vi gør på afdelingsniveau og hvorfor vi prioriterer som vi gør – omend vi stadig har lang vej at gå.
Jeg er den samme type Scrum Master for mine teams i SAFe-settingen som jeg er i en ren Scrum-setting. Jeg har bare fået lidt mere med resten af organisationen at gøre og lidt flere møder i kalenderen (suk).
Det er sjovt du nævner det med at give op overfor impediements. Jeg ville gerne betale nogle møder for at få mere indflydelse udad i organisationen, netop fordi det er et punkt der gør ondt.
Jeg oplever at en af de største forhindringer som scrum master i en stor organisation er at man ligger for langt nede i hierarkiet til at kunne gennemtvinge forbedringer. Der er uforholdsmæssigt meget arbejde i at påvirke chefer, chefers chefer, andre afdelingers projektledere m.m.
Jeg er ikke fan af dybe hierarkier.
Jeg er bestemt heller ikke fan af dybe hierakier og sidder i et rigtigt dybt et. SAFe har gjort at vi har udpeget folk i flere lag som har ansvaret for at løbe med impediments og det gør det nemmere – du har nemlig helt ret i at man som Scrum Master i teamet sidder alt for langt nede i hierakiet til at kunne løbe effektivt med impediments.
Jeg sukker udelukkende over at flere møder i min kalender nu betyder at jeg er dobbeltbooket en del af tiden… Jep, det er mange møder… som jeg gerne tager fordi vi rent faktisk ændrer tingenes tilstand.
Det vil være interessant at høre mere om din erfaring, og håber at jeg får mulighed for det – gerne ansigt til ansigt 🙂
At ThoughtWorks har sat SAFe på “hold” er nyt for mig, men grundene underbygger meget min egen bekymring.
Som Rene siger, så skal man virkelig ikke undervurdere muligheden for indflydelse på organisationen. Det er simpelthen guld værd, og en af grundene til at jeg i sin tid valgte at gå med, da min gamle afdeling i KMD blev centraliseret – på trods af øget mødeaktivitet.
Jeg er vældig glad på dine vegne over at du har en god oplevelse med SAFe i din organisation 🙂
Om min oplevelse med SAFe er god eller dårlig sådan samlet set, har jeg vist ikke vurderet endnu. Der er et par skader som SAFe-indførelsen har medført og som vi arbejder på at rette op på. Der er så også de førnævnte fordele.
Om skaderne kommer direkte af SAFe-metoden eller vores måde at indføre SAFe på er også stadig en ting jeg debatterer med mine kolleger og mig selv jævnligt :).
Et eksempel på noget der har haft en negativ effekt er f.eks. point normalisering på tværs af teams i estimering. SAFe siger at man laver en engangs-normalisering hvor 1 point er 1 dag og det er utroligt svært at komme væk fra den tankegang, når man først er i den. Det har rodet noget så frygteligt med vores estimeringsevner – og forskningen siger jo også at man er bedre til at estimere relativt, så at binde point til tid er en dårlig ide. Effekten har været en opstået modvilje mod at estimere overhovedet.
Jeg tager gerne snakken ansigt-til-ansigt en dag Daniel – sig til når du er i DK :).
Jeg tænkte ikke yderligere over betydningen af facilitator som andet end et fællestræk ved scrum master og agile coach, altså at arbejdet involverer at skabe et minimum af buy-in hos udøverne, og hjælpe dem til at hjælpe sig selv. “Facilitator” kan erstattes med “scrum master” eller “agile coach” i ovenstående, som jeg opfatter det.
Jeg har vist ikke set Agile Fluency før, men jeg kan se den lander hos Martin Fowler, så det lover godt. 🙂
Begrebet facilitator (og coach og scrum master og…) er fluffy og ikke ens opfattet – deraf de tanker jeg har gjort mig i indlægget 🙂
Jeg forstår facilitator som det du beskriver, men også som noget mere. Fx som SAFe Scrum Master har man en opgave i at teamet skal overholde de omkringliggende SAFe regler. Det vil jeg mene gøres bedst ved øge teamets buy-in på faste rammer sat uden for teamets kontrol; det ser jeg som en faciliteringsopgave, uanset om det er til teamets bedste.
Godt du kunne bruge linket 🙂 Jeg vil mægtigt gerne høre dine kommentarer til AF!
Jeg har kigget på Agile Fluency et par gange siden. I overordnede linier synes jeg det er en meningsfuld inddeling, men det er klart at et hold sjældent vil være præcis på et niveau i alle facetter.
Det har givet mig to ting at tænke over:
1) Erkendelsen af hvor højt et ambitionsniveau jeg kan sætte for de hold jeg arbejder med nu. Grundet mange faktorer (både inden og udenfor afdelingen) er der en naturlig øvre grænse, som nok er lavere end jeg ønsker. Det giver mig noget at geare efter og noget acceptere.
2) Erkendelsen af hvor ambitionsniveauet rimeligvis bør ligge for bestemte hold og organisationer – altså, hvornår er det “godt nok”. Uden at man selvfølgelig stopper med at stræbe efter mere, men det er vigtigt at sætte en ambition der passer til rammerne.