Download skabelon til retrospektiv
Print den til væggen, eller redigér den i det værktøj, du allerede bruger. Gratis, uden e-mail og uden tilmelding. Filerne er på engelsk.
Et agilt retrospective er et kort, tilbagevendende møde, hvor et team ser tilbage på en afsluttet arbejdsperiode, som regel et sprint, og bliver enige om, hvad der skal ændres ved måden, de arbejder på. Et planlægningsmøde handler om, hvad teamet skal bygge; et retrospective handler om måden, det bygges på. Resultatet er ikke en klageliste, men en eller to konkrete forbedringer, som teamet vil afprøve inden næste retrospective.
Retrospectives stammer direkte fra Det Agile Manifest fra 2001, hvis afsluttende princip opfordrer teams til med jævne mellemrum at reflektere over, hvordan de kan blive mere effektive, og derefter tilpasse deres adfærd. I Scrum er Sprint Retrospective begivenheden, der runder hvert enkelt sprint af.
Denne guide gennemgår de fem faser i et velfungerende retrospective, hvordan de mest udbredte formater adskiller sig, og et gennemarbejdet eksempel, der tager et team fra post-it-noter til én forpligtende forandring med en navngiven ejer.
Den korte version
Et retrospective har opfyldt sit formål, når teamet forlader mødet med én specifik forbedring, én ejer og en metode til at måle, om det virkede. Alt andet på mødet tjener blot til at finde frem til netop den forbedring.
Grundreglen
De fleste retrospectives indledes med at genopfriske Retrospective Prime Directive, formuleret af Norm Kerth i Project Retrospectives (2001). Kort fortalt: Uanset hvad vi opdager, antager vi, at alle gjorde det bedste, de kunne, ud fra hvad de vidste, deres færdigheder, de tilgængelige ressourcer og situationen på det givne tidspunkt.
Dette er ikke blot en høflighedsfrase. Et team, der frygter bebrejdelser, vil levere ufarlig, generisk feedback og skjule de reelle problemer. Ved at fjerne skyld fra bordet giver man folk modet til at sige "Jeg vidste ikke, at specifikationen var ændret" højt – og netop den sætning er som regel dér, hvor den værdifulde del af mødet starter.
De fem faser i et retrospective
Bogen Agile Retrospectives af Esther Derby og Diana Larsen beskriver fem faser, som stort set alle gode retrospectives følger, uanset hvilket format der anvendes:
| Fase | Formål | Typisk tidsforbrug i et 45-minutters retro |
|---|---|---|
| 1. Sæt scenen | Genopfrisk målet og grundreglen; få alle til at tage ordet tidligt | 5 minutter |
| 2. Indsaml data | Saml fakta, begivenheder og deltagernes oplevelser | 10 minutter |
| 3. Skab indsigt | Gruppér data, udpeg det største tema og find grundårsagen | 15 minutter |
| 4. Beslut hvad der skal gøres | Vælg en eller to ændringer, hver med en navngiven ejer | 10 minutter |
| 5. Afslutning | Bekræft aftalerne og evaluér mødets forløb | 5 minutter |
Fasen, som teams oftest springer over, er den tredje. At gå direkte fra "her er vores post-its" til "her er vores handlingspunkter" resulterer i lappeløsninger, der blot behandler symptomer.
Almindelige retrospective-formater
Formatet er det sæt af spørgsmål, I benytter i fase 2. Ved at variere formaterne undgår I, at faste retrospectives bliver forudsigelige og uengagerede.
| Format | Spørgsmål | Bedst til |
|---|---|---|
| Start, Stop, Continue | Hvad skal vi begynde på, stoppe med og fortsætte med? | Nye teams; hurtige retros |
| Starfish | Fortsæt med, mere af, mindre af, stop med, start med | Teams der ønsker mere nuance end blot "godt" og "skidt" |
| Mad, Sad, Glad | Hvad frustrerede, skuffede eller glædede dig? | Sprints der har været følelsesmæssigt hårde |
| 4Ls | Liked, learned, lacked, longed for | Afslutning på et projekt eller et kvartal |
| Sailboat | Vind (hvad hjalp os), ankre (hvad bremsede os), klipper (risici forude) | Teams der går ind i en risikabel periode |
| Tidslinje | Plot sprintets vigtigste begivenheder og markér op- og nedture | Evaluering efter hændelser eller store releases |
Starfish, typisk tilskrevet Patrick Kua, er det format, vores gratis skabelon til retrospektiv anvender. Dens fem kategorier giver plads til "dette fungerer, men vi overdriver det", hvilket en simpel opdeling i godt og skidt overser.
Et gennemarbejdet retrospective-eksempel
Her er et 45-minutters retrospective for et fiktivt produktteam på syv personer. Deres to-ugers sprint endte med, at en eksportfunktion til kunder blev leveret tre dage for sent.
Fase 1: Sæt scenen (5 minutter)
Facilitatoren genopfrisker grundreglen og definerer formålet: "Vi leverede eksportfunktionen tre dage for sent. Lad os finde ud af hvorfor og aftale én forbedring til næste sprint." Alle opsummerer sprintet med et enkelt ord. To deltagere siger "forhastet".
Fase 2: Indsaml data (10 minutter)
Teamet opstiller en hurtig tidslinje over sprintet og skriver derefter Starfish-noter i stilhed i fem minutter, så de mest dominerende stemmer ikke sætter dagsordenen.
| Fortsæt med | Mere af | Mindre af | Stop med | Start med |
|---|---|---|---|---|
| Daily standups under 15 minutter | Parprogrammering på svære opgaver | Ad-hoc designreviews i chatten | At ændre acceptkriterier midt i sprintet | At vise designs til kunden før sprintet |
| Skrive tests før merge | Demos for kunden | Statusmøder der kunne klares på besked | At starte opgaver uden færdig mockup |
Fase 3: Skab indsigt (15 minutter)
Teamet grupperer noterne og stemmer. Den suverænt største klynge handler om krav, der ændrede sig efter sprintets start. Teamet anvender 5 Whys på problemet:
- Hvorfor blev eksporten forsinket? Test viste, at den ikke matchede kundens forventninger.
- Hvorfor? Acceptkriterierne ændrede sig på dag seks i sprintet.
- Hvorfor? Kundens driftsleder så først designet på dag fem.
- Hvorfor? Designs gennemgås internt, men vises ikke til kunden, før en opgave tages ind i sprintet.
- Hvorfor? Ingen ejer kundens godkendelse. Produkt antog, at account management tog sig af det, og account management troede, produkt gjorde det.
Grundårsagen er ikke "dårlig kommunikation". Det er et procestrin uden en navngiven ejer.
Fase 4: Beslut hvad der skal gøres (10 minutter)
Nogen foreslår "bedre kommunikation med kunden". Facilitatoren griber ind: Det er et ønske, ikke en procesændring. Teamet aftaler i stedet et konkret eksperiment:
- Ændring: I de næste to sprints skal enhver opgave med kundeændringer have en kundegodkendt mockup, før den tages med i sprintet.
- Ejer: Produktchefen (Product Manager).
- Måling: Vi tæller antallet af opgaver, hvor acceptkriterierne ændres undervejs. I sidste sprint var det tre.
De øvrige noter gemmes til en senere gennemgang. Teamet forpligter sig til én ændring, ikke syv.
Fase 5: Afslutning (5 minutter)
Facilitatoren opsummerer eksperimentet og ejeren, og hver deltager vurderer mødet fra ét til fem. Næste retrospective vil åbne med at kontrollere status på målingen.
Hvad der får et retrospective til at fejle
- Ingen handlinger eller for mange. En liste med ti forbedringer er en liste, som ingen ejer. Vælg en eller to.
- Handlinger der blot er ønsker. "Bedre kommunikation" kan ikke eksekveres mandag morgen. "Kunden godkender mockups før sprintet" kan.
- Manglende opfølgning på sidste mødes aftale. Hvis næste retrospective ikke åbner med at gennemgå den seneste aftale, lærer teamet, at forpligtelser er valgfrie.
- Skyld og bebrejdelser. Så snart en enkelt person udpeges, begynder alle andre at censurere deres udtalelser.
- Det samme format hver evig eneste gang. Skift mellem formater, så teamet ikke svarer på autopilot.
At springe retrospectives over har sin egen pris, som vi behandler i prisen for procesgæld.
Retrospective vs. sprint review vs. post-mortem
Disse tre begreber forveksles ofte, fordi de alle ser tilbage:
- Sprint review: Teamet viser hvad det har bygget til interessenter og modtager feedback på selve produktet.
- Retrospective: Teamet kigger på hvordan det arbejdede og justerer sin proces. Interessenter deltager normalt ikke.
- Post-mortem: En enkeltstående analyse af en specifik hændelse eller fejl. Den følger ofte samme faser med en tidslinje som omdrejningspunkt.
Gratis skabelon til retrospektiv
Vores gratis skabelon til retrospektiv findes som PDF, Word-dokument, Excel-ark og PowerPoint-præsentation. Den er baseret på Starfish-formatet med hjælpetekster til hver af de fem kategorier og en handlingsplan med ejere og datoer.
Lær mere om retrospectives
- Sådan afholder du et projekt-retrospective: Facilitatorens tankesæt og håndtering af et anspændt mødelokale.
- Sådan afholder du et sprint retrospective i Microsoft Teams: En 45-minutters køreplan til fjernmøder.
- Prisen for procesgæld: Hvorfor det sænker teamets hastighed at springe retrospectives over.
Ofte stillede spørgsmål
Hvor ofte bør et team afholde et retrospective?
Ved afslutningen af hvert sprint eller hver anden til fjerde uge for teams, der ikke arbejder i faste sprints. Det er også god praksis at afholde et efter en større release eller driftsforstyrrelse.
Hvor lang tid bør et retrospective tage?
Cirka 45 minutter for et to-ugers sprint. Scrum Guiden sætter en øvre grænse på tre timer for et en-måneds sprint og bemærker, at det typisk er kortere for kortere sprints.
Hvem bør deltage i et retrospective?
De mennesker, der udførte arbejdet: Selve leveranceteamet, inklusive Product Owner og Scrum Master i Scrum. Chefer og eksterne interessenter deltager normalt ikke, så teamet kan tale frit.
Hvem bør facilitere et retrospective?
Typisk Scrum Masteren eller et teammedlem på skift. Rotation fungerer godt, og ved anspændte situationer kan en ekstern facilitator hjælpe med at holde fokus på processen frem for personerne.
Hvad er det konkrete output fra et retrospective?
En eller to specifikke procesforbedringer, hver med en navngiven ejer og en metode til at afgøre på næste møde, om forbedringen har virket.
Klar til at bruge det i praksis? Kør det med dit team med vores gratis skabelon til retrospektiv.
