Folk, der kender mig, vil vide, at jeg elsker retrospectives.
Og især når man arbejder agilt. Sidste år var jeg med til at oplære nye agile coaches i Siemens i Erlangen, og jeg fik lært dem, at hvis jeg vækkede dem om natten og spurgte ”Hvad er det vigtigste i agile?”, ville de svare ”Inspect and adapt”.
Ok indrømmet: jeg har aldrig prøvet at vække dem om natten, men jeg fik dem da opdraget til at svare det i kor, når jeg spurgte dem.
Jeg har skrevet en anden blogpost, hvor jeg har fortalt lidt om hvorfor man overhovedet kører retrospectives, hvor jeg lovede at skrive denne – det er efterhånden halvanden måned siden og jeg har flere gange tænkt ”nu skriver den post”, men så skal jeg liiige…
Hvilket leder godt hen til første punkt: sørg for at få retrospectives i kalenderen, for ellers sker det ikke. Vi har masser af gode intentioner om at stoppe op i hverdagen og tænke over forbedringer. Desværre viser al erfaring, at det bare ikke sker.
Der er mange andre ting, som kan hjælpe til at lave et godt retrospective og mange forskellige aspekter; i denne her blogpost vil jeg have fokus på proces og struktur.
Der er nogle minimumsting, der skal være i orden for, at et retrospective er effektivt:
- Der skal være fokus på processen
- Der skal være en struktur på mødet
- Der skal aftales actionpunkter, som der følges op på gangen efter
Processen
Det er vigtigt, at man i et retrospective fokuserer på processen. Formålet er at forbedre vores proces og lære af det, der er sket; både gode og dårlige ting.
Det er nemt at glemme det og begynde at gå efter manden i stedet for bolden. Aftal inden, at det er processen, der er det vigtige.
Jeg bruger Prime Directive til at sætte stemningen fra starten. Det har efterhånden en del år på bagen og giver stadigt stor værdi.
”Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
— Norm Kerth, Project Retrospectives: A Handbook for Team Reviews
Processen er også vigtig, når I kigger på hvad der skal ske bagefter.
Struktur og actionpunkter:
Jeg bruger næsten altid en struktur, som stammer fra bogen om Agile Retrospectives af Diana Larsen og Esther Derby.
Det er en god struktur til at holde fokus på formålet af mødet:
- Set the stage
- Gather data
- Generate insigth
- Decide what to do
- Close the retrospective
Eller sagt på en anden måde:
- Gøre klar. Det vigtigste er at sikre os, at alle ved,
- hvad vi taler om i dag,
- hvilken tidsperiode det handler om,
- eventuelt hvilket fokus der er i dag,
- hvem, der deltager i mødet
- hvordan det er gået med vores actionpunkter fra sidst.
- Indsamle data; hvad er der sket i perioden siden sidst; det er vigtigt, at det er så objektivt som muligt. Her er det godt at bruge de artefakter, som man har (i scrum kan det f.eks. være burndown chart, i kanban et billede af tavlen osv.)
- Få indsigt. Her handler det om at finde betydningen af de data, som vi har fundet. Kan vi se nogle mønstre? Er der nogle ting, der hænger sammen? Hvilke ting kan vi gøre noget ved og hvilke er udenfor vores indflydelse?
- Her vælger man hvad man skal gøre indtil næste gang. Hvilke eksperimenter kan vi lave for at løse et problem, sikre at noget godt bliver til, eller bare for at prøve noget andet. Vælg 2 eller maksimum 3 ting, som actionpunkter til næste gang. Det er vigtigt, at actionpunkterne er meget konkrete og sæt meget gerne en person som tovholder på hvert punkt.
- Sidste punkt handler om at lukke mødet af. Vurder mødet; virkede det? Skal vi gøre noget anderledes næste gang?
Nedenstående billede viser netop denne struktur. Lav de fem skridt, indarbejd de nye eksperimenter og når perioden/sprintet/iterationen er slut, har man et nyt retrospective.
Hvad så nu?
Andre ting, som giver yderligere værdi:
- Hav en ekstern facilitator – det kan f.eks. være en udefra eller en scrummaster fra er andet projekt.
- Sørg for at alle får tid til at tænke og plads til at sige noget.
- Lav et møde, hvor alle føler sig tryg nok til at sige sandheden.
Hvis I følger strukturen, har fokus på processen og laver actionpunkter hver gang, så er I godt på vej.
Der er masser af værktøjer og øvelser, der kan bruges i hvert trin, og mange af disse findes på nettet, så det er bare at søge. Og ellers har jeg god erfaring med at spørge om hjælp; mange erfarne facilitatorer, inklusiv mig selv, svarer gerne på spørgsmål på twitter og mail.
Hvorfor er det at en ekstern facilitator giver ekstra værdi? Jeg kan forestille mig at det er for at undgå bias i forhold til hvad der bliver taget op af emner, men en intern facilitator kender jo teamet bedre – på godt og ondt. Jeg har prøvet begge dele og må indrømme at jeg fik mest ud af det med en intern facilitator (ikke at der var en kæmpe forskel).
Hvad er dine erfaringer?
Det kan også fungere rigtig fint med en intern facilitator netop fordi de kender teamet. F.eks. ved de hvem de skal stoppe når de begynder på en endeløs snak om noget alle har hørt før. Og de ved at netop dette team har talt om netop dette symptom længe og måske skal de dybere ned for at finde årsagen. Det kan også være at folk føler sig mere trygge med en de kender.
Men der er også en anden side. Når man faciliterer, og faktisk også når man deltager i retrospectives, skal man passe meget på sine fordomme og antagelser. De kan stå i vejen for at se, hvad der virkelig er sket og hvad årsagen er. De kan forhindre en i at tænke åbent, fordi man jo har set den her situation før og ved hvad man skal gøre. Og en intern facilitator kan faktisk af nogle opfattes som værende katalysator for et mindre trygt miljø. Fordi de, selvom man som facilitator har tavshedspligt, ser en som en del af virksomheden.
Nu er det jo heller ikke sådan at Gitte siger at man absolut skal have en ekstern facilitator, men hvis man er stødt på grund, eller har uinspirerende retrospectives, eller er kørt træt i facilitatoren, så kan det have værdi at få en udefra med ny energi, nye aktiviteter og mindre forudindtagethed omkring teamet.
Hvem ved, måske er det “dumme Hans” der kommer med den forløsende indsigt, hvis facilitatoren ikke har et kropssprog der signalerer at han/hun ikke forventer det?
Godt spørgsmål 🙂
Måske skulle jeg have uddybet det lidt.
For det første har Aino ret (som altid 🙂
For det andet, så mente jeg egentligt ekstern i form af en uden for teamet. Hvis det er scrummasteren eller en af de andre fra teamet, der faciliterer, så er der to ting, der kan være en ulempe:
1. Faciltatoren kan ikke selv være aktiv deltager i mødet (min erfaring er at man enten faciliterer eller deltager – selv meget øvede facilitatorer har svært ved det)
2. For det andet så har man netop en masse viden, som man man kan bruge, så man (måske ubevidst) kommer til at styre mødet i stedet for at facilitere.
Super – tak for svaret.
Tænkte nok at det var for at undgå bias og ubevidst styring – og god pointe om at den interne facilitator jo også selv kunne have noget at bidrage med. Ainos pointe om at man kan komme ud af vanerne/antagelserne ved at få nyt blod ind er også god.
Personligt synes jeg at ulempen ved at bruge en intern facilitator (f.eks. Scrum Masteren) er at de ofte ikke får afsat tid nok til at forberede mødet “ordentligt”.
Det resulterer i at der ofte vælges same metode som de forgående gange og outputtet bliver tit det samme som ved de forgående møder.
En anden ulempe ved en intern facilitator er bias, som nævnt før. Specielt på emner som er gentages fra møde til møde. En intern facilitator kan måske få stoppet diskussionen for tidligt og dermed ikke finde frem til “root cause” – eller i det mindste en handling som kan håndteres internt i teamet således at man kan få ændret på problemet.
[…] first wrote this blog post for QED in 2014 in Danish and then in English for Skills Matter in […]