Synes du det er som om I kører rundt i de samme emner til alle jeres retrospectives? Har du måske et sammentømret team som har svært ved at se hvor de kan forbedre sig? Vil du gerne undersøge om der er nogle generelle problemer som går på tværs af Scrum Teams i jeres organisation?
Hvis du kan svare ja til et af disse spørgsmål, så har Henrik Kniberg (forfatter til bl.a. Scrum and XP from the Trenches) lavet et værktøj du måske kan bruge.
Vi er så heldige i vores organisation at Henrik Kniberg hjælper os med vores agile setup og modenhed. Han er her ikke 100 %, men dukker i stedet op med jævne mellemrum og stiller hårde spørgsmål og hjælper os på vej. Et af de hårde spørgsmål må have været “kender I som ledelse de udfordringer som jeres Scrum Teams sidder med?” og svaret må have været “Ikke i tilstrækkelig grad” for Scrum Masterne i vores organisation fik en forspørgsel på om vi havde lyst til at lave et health check på alle Scrum Teams i vores del af organisationen.
Health checket vi bruger er udviklet af Henrik Kniberg og Kristian Lindwall i deres arbejde med Spotify – der findes mange andre health checks som man kan tage fat i. Den måde vi har valgt at bruge dette health check på, er som et internt værktøj til teamet og samtidig et værktøj som Scrum Masterne kan bruge til at finde mønstre, som gælder på tværs af teams. Vi bruger det altså først til at dirigere vores retrospectives og først derefter til en samtale mellem Scrum Masterne for at finde de fælles udfordringer.
Fremgangsmåden er enkel. I health check-kittet er der en liste over emner f.eks. “Health of Codebase”, “Teamwork”, “Easy to release”, “Delivering Value” eller “Fun”. Man vælger et af emnerne, læser stemme-vejledningen der står på kortet og stemmer.
Der er også tomme kort, så man kan lave sine egne.
Lad os sige vi snakker om emnet “Easy to release”.
Stemmevejledningen siger at en grøn stemme er:
At release er simpelt, sikkert, smertefrit og for det meste automatiseret.
En rød stemme er til gengæld:
At release er risikofyldt, smertefuldt, meget manuelt arbejde og tager for evigt.
Dermed ikke sagt at en release ikke kan være sikker, automatiseret og alligevel tage for evigt og derfor er det også muligt at stemme gult. Min erfaring med det er dog at det er meget nemt at vælge den gule stemme for ikke at skulle tage en længere diskussion – det ligger nok især i danskernes konsensus-søgende natur. Derfor valgte jeg at indføre 2 slags “gul” – en orange og en lysegul, hvor den lysegule var tættere på grøn og den orange var tættere på en rød. På den måde var der ikke en nem midtervej, men grader af grøn/rød. Et lille hack som kan gøre en forskel, hvis man sidder med et konsensussøgende team.
Når der er stemt skal man argumentere for sin stemme (ligesom i planning poker) – hvilket kan blive en længere diskussion. Især røde stemmer er vigtige at få hørt, men man skal også være opmærksom på de emner, hvor der er stor spredning i stemmerne. Hvorfor er vi uenige om, hvor godt det går? Er det fordi at vi sidder i forskellige dele af kodebasen, i forskellige roller eller med forskellige referencepunkter/prioriteter/tidshorisonter osv.? Også i tilfælde af enighed om rød/orange, så kan det være brugbart at bruge tiden på at nå frem til problemets kerne ved hjælp af f.eks. 5 whys. Prøv at se om I kan nå frem til enighed indenfor teamet om hvad teamets stemme ville være. Kan de gule overbevises om (ikke trynes til) at blive røde eller omvendt? Se om I kan lave et afstemningsresultat for teamet generelt på alle punkter evt. med en trend-angivelse som set i oversigten for alle teams.
Hvis man er i en større organisation og gerne vil se om der er generelle smertepunkter, kan Scrum Masterne sætte sig ned og lede efter generelle trends, når alle teams har været igennem øvelsen. Stemmerne er ikke nok uden at man kender diskussionerne bag, så dem skal hver enkelt Scrum Master også huske at få med til diskussionsbordet. Er det samarbejdet med en anden afdeling som påvirker “Fun” eller er det f.eks. arbejdets natur? Er det en specifik del af kodebasen som får røde stemmer i “health of codebase” eller er det en generel trend? Er det teamwork i dette sprint der evalueres eller er det teamwork set over lang tid? Husk at afstemningerne er samtale-startere og ikke noget man bare skal lave et gennemsnit over før man konkluderer.
Emnerne er alle meget brede og diskussionerne bagefter er altafgørende. Det kan være en stor mundfuld at forsøge at nå alle emner igennem på en gang, hvis ikke man styrer diskussionerne bagefter med hård hånd. Det er en god ide at sætte en timebox på og så fortsætte en anden dag, hvis man går over tid. De enkelte emner hjælper især godt hvis der er tabuer i teamet – emner som man ikke selv vil tage initiativ til at tale om. Her kræver øvelsen at man tager emnet op og legimiterer dermed at nogen bryder tabuet. Hvis øvelsen virker godt for teamet, kan man gentage den efter nogle måneder og sammenholde svarene. Har vi forbedret os eller går det i den forkerte retning?
I sidste ende er det vigtigste processen og de tilhørende aha-oplevelser, men resultaterne kan også pege Scrum Masteren i en retning i forhold til hvor der skal sættes ind. Jeg ville ønske jeg havde kendt til dette værktøj, da jeg først overtog mine nuværende teams, da det kunne hjælpe mig med at finde gode fokusområder til mit arbejde helt fra starten af. Resultaterne kan dog også være overvældende, hvis de peger i mange retninger – man skal passe på med at angribe flere vinkler ad gangen.
Kunne dit team trænge til et sundhedstjek?