Retrospektiv. Et gammelt, såre enkelt og supereffektivt verktøy for å skape kontinuerlig forbedring i team. Jeg vil si at retrospektiver, gjort riktig, er et av de beste verktøyene et team har for å bli velfungerende. Men hvorfor gjør ikke alle det da?

Les videre for en enkel innføring i effektive retrospektiver, og noen tips om hvor det ofte går feil!

Vi har sluttet å ha retrospektiver, fordi vi ikke får nok tid til å kode.

… sa ingen team som var i ferd med knekke koden, noen sinne.



Den egenskapen, over noen annen, som går igjen i høytpresterende team jeg har sett, er en velfungerende prosess for retrospektiver. Forklaringen er enkel: i retrospektiven tar teamet tak i ett og ett problem, løser dem og blir litt bedre. Uke etter uke, måned etter måned. Team som gjør dette hyppig, vil over tid ha løst en drøss med problemer.

På den andre siden har du team som enten ikke har retrospektiver, eller som ikke får dem til å fungere. Prosesser gror fast, problemer som dukker opp blir ikke løst og teamet klarer ikke å tilpasse seg endringer i konteksten rundt seg. Teamet står i beste fall stille, men vil også ha en tendens til å bli gradvis verre.

Hva skal til for å lykkes med retrospektiver?

Hvis det er så enkelt som at retrospektiver gir høytpresterende team, så burde vel alle team være høytpresterende? For så vanskelig er det ikke å kalle inn til en retro innimellom. Dessverre er det korrelasjon og ikke kausalitet vi snakker om her: høytpresterende team vil veldig ofte ha en velfungerende prosess for retrospektiver. Det betyr ikke at alle team som har retrospektiver er høytpresterende. Så la oss fokusere på det vi kan gjøre noe med: velfungerende retrospektiver.

Velfungerende retrospektiver har noen enkle, og helt avgjørende, egenskaper:

De er regelmessige og hyppige. Helst annenhver uke. Hver tredje uke er ok, sjeldnere enn det sannsynligvis for sjelden.

Alle i teamet bidrar og kommer med innspill og forslag.

Oppfølgingspunktene er konkrete, har et realistisk omfang og en tydelig person som er ansvarlig for å følge dem opp.

Det er aksept i og rundt teamet for å bruke tid på prosessforbedring.

Medlemmene i teamet er åpne for endring, og er villige til å teste nye ting for å se om det virker.

En enkel retro som virker bra

Jeg holder dritkjedelige retroer.

Det finnes en haug bedre måter å gjøre det på, men i prinsippet holder det plenty med gode gamle mer, mindre, prøv. Og så har jeg funnet gleden i å legge til en fjerde «jeg lurer på» for å ha en plass å la folk spekulere litt uten å mene for mye.



Herfra gjør jeg det veldig enkelt:

Sett av en fast tid, for eksempel fem minutter, der alle skriver lapper for alle kategoriene.

En og en går gjennom lappene sine, presenterer dem og henger opp. Det er lov å stille spørsmål for å forstå, men det er ikke tid for å diskutere lappene enda.

Jeg liker å gruppere lappene underveis, sånn at det blir lettere å holde oversikt over temaer og å finne igjen enkeltlapper etterpå. Pass på å ikke lage for brede kategorier. Det bør være ting det går an å finne tiltak for!

Når alle har presentert lappene sine og de er gruppert, er det tid for å stemme. Tre til fem stemmer per person pleier å fungere bra, men det kommer an på størrelsen på teamet og antallet temaer. Jeg pleier be folk stemme på de grupperte temaene, ikke enkeltlapper.

Tell opp stemmene, og gå gjennom de 2-3 temaene som fikk flest stemmer.

Bli enige om konkrete oppfølgingstiltak for temaene som ble stemt fram. Diskutér og bli enige om forbedringstiltak. Tiltakene trenger ikke være det som står på lappene fra før. Terskelen for å teste noe bør være lav – det er uansett bare for de neste 2-3 ukene. Det er mye bedre å prøve noe, enn å ende opp med å ikke gjøre noen ting. Det har en egen verdi å trene endringsmuskelen!

Bli enige om hvem som følger opp hvert tiltak. Den som er ansvarlig for et tiltak legger det inn langt oppe i backloggen med en gang, sånn at det blir prioritert, synliggjort og ikke glemmes.

Merk at det aller viktigste kommer på slutten: konkretisering av tiltak. Hvis dere ofte går tom for tid uten å ha konkretisert tiltakene, må dere enten sette av mer tid eller begynne med bedre tidsstyring.





Hvor går det feil?

Hvordan vet dere om retrospektiven dere har i dag virker? Den enkle sjekken er: lykkes dere med å løpende implementere forbedringer?

Den vanligste feilen team gjør med retrospektiver er at de ikke klarer å sette konkrete oppfølgingstiltak og gjennomføre dem. Det kan være fordi de går tom for tid, fordi ingen tar på seg å konkretisere, eller fordi teamet ikke er lojale mot det de blir enige om.

Noen vanlige problemer å se etter

Retrospektiven blir lang, gjerne litt klagete, og munner ut i en haug lite konkrete oppfølgingstiltak som ikke blir gjort noe med

Ofte et symptom på at man har retrospektiver for sjelden. Det bygger seg opp for mye gruff som må tømmes ut samtidig. Bruk timeboxer, og sett et lavt maks antall lapper for hver enkelt deltaker, sånn at folk må prioritere det som er viktig.

Ha retrospektiver ofte, gjerne hver andre eller tredje uke, med høy terskel for å avlyse.

De fleste lappene som deles er overfladiske, og gjerne nøytralt positive: «god stemning i teamet!» 

Er det egentlig psykologisk trygghet i teamet? Tør dere være ærlige og snakke om ting dere er uenige om? Ikke mist motet! Start med å gjøre endringer på mindre kontroversielle deler av prosessen, og øv på å snakke om ting som gjør vondt.

Vanskelig å bli enige om oppfølgingspunkter. Folk klarer ikke komme opp med konkrete forslag, eller folk er uenige i hva som er riktig løsning

Handler ofte om dynamikk og psykologisk trygghet i teamet. Bli enige om at tiltakene er eksperimenter som dere tester ut til neste retro. Hvis det ikke virker er det bare å rulle det tilbake igjen! Ta dere tid til å snakke om hvorfor dere er uenige, og hva som gjør at dere ikke er villige til å teste ut en endring.

Ingen ønsker å ta på seg ansvaret for tiltak, eventuelt at samme personer blir sittende med ansvaret hver gang

Ofte et tegn på at teamet føler seg overveldet av mengden arbeid. Noen ganger har et team en ekte frist som gjør at det faktisk ikke er tid til å jobbe med prosess. Mer vanlig er det at teamet er fanget i et nedadgående spiral, med dårlig fungerende prosess og uklare mål, som gjør at teamet opplever at det konstant er veldig travelt. Det er nettopp i slike team at det virkelig er viktig å jobbe med prosess!

Tiltakene man blir enige om blir ikke gjennomført

Folk i teamet opplever ikke at det er akseptert å prioritere tid på prosessforbedringer. Dette handler oftere om følelsen man har selv, enn om hva som faktisk er greit å gjøre. Sørg for å få lagt inn oppfølgingsiltakene i backloggen, og gi dem høy prioritet!

Avslutningsvis

En god prosess for retrospektiver skal være enkelt, og jeg mener det er noe alle team bør klare selv uten ekstern fasilitering. Noen ganger kan det være vanskelig å få til, fordi det er større dysfunksjoner som ligger bak. Som manglende psykologisk trygghet, dårlig ledelse eller uklare rammer og kontekst rundt teamet. I disse tilfellene vil dårlige retrospektiver ofte være et symptom som kan være til hjelp med å forstå at det er et problem i teamet som trenger å løses. Og det i seg selv er verdt veldig mye!

Så oppfordringen min er: har dere ikke retrospektiver i dag? Sett i gang nå! Har dere retrospektiver som ikke virker? Da er det på tide å stille spørsmål om hvorfor – og be om hjelp hvis dere virkelig ikke får det til å sitte. Da er det sannsynligvis andre problemer som også bør løses!

For team som begynner å få sving på retrospektivene sine, så vil jeg på det sterkeste anbefale retrobanken til Sigrid, Emilie, Puru og Ragnhild. Jeg mistenker de holder vesentlig mindre kjedelige retrospektiver enn meg!

17-Dec

Today's posts

Retrospektiver: det enkleste og viktigste verktøyet et utviklingsteam har