Patterns er erfaringer skrevet ned så andre kan gøre brug af dem. Antipatterns er det samme, bare beskrivende hvad der kan gå galt og derfor synes jeg de er sjovere end patterns. Siden jeg begyndte at facilitere retrospectives har jeg set og hørt om mange retrospectives der er gået galt, både for mig og for andre. En eftermiddag i 2013 på GOTO konferencen i Aarhus, besluttede jeg at “lufte” 5 af mine retrospective antipatterns. Siden er det blevet til foredrag om flere antipatterns. Mit håb er at vi kan få udviklet et ordforråd om retrospectives som vi kan bruge, så når I f.eks. lander i et DIY retrospective næste gang kan I måske genkende det og løse situationen.
I øjeblikket er jeg ved at skrive en bog om dem, som forhåbentlig kan glæde andre eller i det mindste være en slags dagbog for mig selv.
Her kommer det første, som er det jeg plejer at få flest spørgsmål om, når jeg fortæller om det:
DIY retrospectives:
Anti-pattern løsning:
Ofte bliver Scrum Masteren udpeget til at være facilitator for retrospectives. Det kan der være mange grunde til; Han udnævner sig selv fordi han mener (måske med rette) at han ville være den bedste til det. Han bliver udnævnt til det af ledelsen, som mener at det er en SM opgave. Eller måske er der ikke andre i teamet der har mod på det. Under alle omstændigheder kan man finde mange artikler og blogs hvor beskrivelsen af facilitering af retrospectives lægger op til at det er SM der gør det.
Konsekvenser:
Der er to store konsekvenser ved den løsning og for begges vedkommende er problemet at man ikke kan have to hatte på til et retrospective. Man kan ikke både være facilitator og deltager. Begge roller kræver fuld opmærksomhed.
Hvis man som SM er facilitator vil man opleve at man kan blive så optaget af det der foregår til retrospectives, de diskussioner der er, at man glemmer at facilitere, f.eks. glemmer at holde tiden, glemmer at være opmærksom på hvor aktive/inaktive folk er.
Den anden ulempe er at man som facilitator er så opmærksom på at opfylde den rolle at man helt glemmer sig selv i afstemninger, brainstorms, etc.
Det gælder naturligvis også, hvis det er et andet teammedlem der faciliterer, men forskellen er at det ofte er SM der faciliterer og derfor sjældent får noget ud af det selv.
Symptomer:
Man kan opdage at man står i dette anti-pattern hvis man ser at facilitatoren ikke er opmærksom på tiden, eller at SM efter et retrospective oplever at hun eller han ikke fik noget ud af det.
Genovervejet løsning:
Løsningen kan være at skiftes til at facilitere retrospectives, så man for det meste får noget ud af retrospectives, selvom man er mere opmærksom på facilitatorrollen ind imellem. Man kan også få en fra et andet team eller en helt udenforstående; en professionel facilitator.
En anden fordel ved at skiftes eller få en ekstern er at man får lov til at prøve noget nyt, det kan gøre ens retrospectives mere spændende. Yderligere kan det være en god ide at lade de andre i teamet facilitere et retrospective ind imellem, så kan de selv få lov at prøve og se at det faktisk er en udfordring at gøre det godt.
Hej Aino.
Overraskende anti-pattern. Det er jo netop SM’s rolle at være faciliterende. Måske misforstår jeg dig – og beklager så på forhånd – men er handler det her om at SM også er Developer? Og hvis ja, er det anti-pattern vi leder efter så ikke i virkeligheden at SM også er udvikler?
Jeg er helt enig i Ainos betragtninger. En anden ulempe ved at det er den samme SM der faciliterer kan også være at man kører samme dagsorden og dermed ender op med identiske actions fra møde til møde.
Hvis man har mulighed for det kan det være en ide at lave en liste med personer i virksomheden som ønsker (og evner) at være facilitator og på den måde opbygge et korps der kan anvendes.
Hej Michael
Tak for dit spørgsmål. Det er en længere diskussion hvorvidt det er et antipattern at SM er udvikler. Nogle vil mene at SM skal være en udvikler for at udviklerne har den rette respekt for SM. Andre vil mene at SM skal koncentrere sig om at være faciliterende, som du skriver. Jeg har set begge dele, eller faktisk alle fire;
1. SM er udvikler og er ikke særlig interesseret i at være faciliterende overfor teamet og glemmer sine forpligtelser i den retning
2. SM er udvikler og er samtidig en supergod SM
3. SM er ikke udvikler og teamet føler ikke han er en del af teamet fordi han ikke “laver noget” i retning af at udvikle produktet.
4. SM er ikke udvikler og teamet respekterer ham for at være en nyttig del af deres fælles succes.
Jeg ville prioritere scenarierne i følgende rækkefølge; 2, 4, 1, 3
Men, som sagt, det er en anden diskussion, som jeg er sikker på at andre har langt stærkere meninger om end mig.
Angående ovenstående antipattern, så er den stærkeste ulempe at det altid er den samme person der faciliterer, altså at man ikke skiftes eller får inspiration udefra ind imellem, og det er min erfaring at den person oftest er SM. Og en del af at kunne respektere SMs arbejde kan være at træde i deres sko og se at der faktisk er ting at gøre som er svære og hårde, som f.eks. at facilitere et retrospective godt.
Ok fair nok. Og jeg var upræcis. Jeg er helt enig i det er en styrke at SM er udvikler og forstår hvad der er teamet laver. Det jeg forsøgte at sige var at det er svært at være SM og udvikler på samme Scrum Team.
Jeg køber helt at det faktum det er den samme der faciliterer kan være en ulempe. Omvendt er der altså mange udviklere der faktisk ikke synes det at facilitere er særlig interessant – og nogle som bare er virkelig dygtige og synes det er spændende.
Hvis vi skal følge både de bagvedliggende tanker og den aktuelle formulering af Scrum, så er det SM’s rolle at facilitere og derfor er jeg nok stadig tilbøjelig til at synes det er strække den lidt at kalde det et anti-pattern at SM gør sit arbejde. Og jeg er bestemt enig i at hvis man kan være udvikler på et team og SM på et andet – eller hvis der er flere på teamet der har lyst til at facilitere, så bliver det endnu bedre.