Retrospektiv i løpet av 1 time, er det mulig?
Forfatter: Pål Berg, Promis Qualify
Jeg skulle fasilitere et retrospektivmøte for en prosjektfase hos en kunde.
Retrospektivet skulle omhandle et tidsrom på 3 uker, og vi skulle være 7 deltagere.
Etter at jeg hadde sendt ut innkallingene oppdaget jeg at jeg hadde booket bare 1 time. Min første reaksjon var å forlenge møtet, men hvorfor ikke ta det som en utfordring? Tross alt så har vi vel alle vært med på retrospektivmøter som drar ut i det lange og breie uten at resultatet blir så mye bedre av den grunn.
Målet med retrospektiv er som kjent å gi innspill til kontinuerlig forbedring. Det var viktig å ikke miste det av syne i iveren etter å presse møtet inn på 1 time.
Jeg skjønte raskt at for at dette skulle lykkes måtte forberedelsene være gode.
Forberedelser:
I innkallingen hadde jeg lagt ved en veldig kort tekstlig versjon av tidslinjen for å få i gang tankeprosessene allerede før møtet.
Jeg googlet litt for å finne inspirasjon, men fant ingen som promoterte én-times retrospektiver. De fleste oppskriftene var relativt tidskrevende. Dog så fant jeg en oppskrift som Johannes Brodwall hadde prøvd ut på Smidig 2010. Og da spesielt noe han kalte “Tenke og svare”, “3×3 spørsmål”, “Snakke og lytte”. Jeg så jo fort at dette ville ta altfor lang tid, men hva om vi tok ut deler av disse og gjorde alt på en gang?
Ofte har jeg opplevd at man har gruppert i “Hva var bra?” og “Hva var ikke så bra?” og “Forberdinger”. Jeg ønsket et annet fokus enn dette, så der valgte jeg “Høydepunkter” og “Overraskelser”, som skulle gi observasjoner fra deltagerne uten at de trengte å sette pluss eller minus foran. Jeg ønsket også at deltagerne skulle se framover, og da ble “Erfaringer” en fin kategori.
Så da puttet jeg alt dette i gryta og gjorde det kokkene kaller for reduksjon, og det hele kokte ned til en tabell med overskriftene
Høydepunkter – Overraskelser – Erfaringer
Med disse temaene blir tankeprosessen litt annerledes og ikke nødvendigvis så polarisert.
For ytterligere å hjelpe tankeprosessene i gang forberedte jeg en ikke utfyllende stikkordliste som inneholdt temaer som:
- Ressurssituasjon
- Rapportering
- Kommunikasjon
- Avhengigheter
- Samarbeid
- Oppstart
- Avslutning
- Arbeidsbelastning
- Arbeidsfordeling
- Utstyr/verktøy
- Oppfølging
- Trivsel
I tillegg listet jeg opp noen stikkord som var spesifikke for dette retrospektivet.
Jeg plukket med meg skrivesaker og gule lapper og møtte opp på møterommet 10 minutter før start. (Jeg hadde passet på å booke rommet fra 15 minutter før selve møtet).
Whiteboard:
Jeg tegnet opp en tidslinje og skrev på start og stoppdatoer.
Jeg skrev opp de 3 kategoriene i et “skjema” der man kunne henge lappene.
Flipover:
Skrev opp stikkordeksemplene på et ark.
Gjennomføring
Da deltagerne var på plass ønsket jeg velkommen, og siden ikke alle hadde vært med på retrospektivmøter før, så forklarte jeg hensikten med møtet. Vi hadde en liten dialog rundt dette, slik at alle forstod og var enige om opplegget.
Så forklarte jeg konseptet med tidslinjen og fikk med alle på den. Tidslinjen er ei rett linje, som tegnes opp på tavla/flipoveren, for å illustrere den tidsperioden som retrospektivmøtet behandler. En kalender der viktige hendelser plottes inn. Hensikten er å få opp et visuelt bilde av forløpet, til hjelp i tankeprosessene med å hente fram innspill.
Når så tidslinjen var på plass og vi alle var enige om innholdet, forklarte jeg opplegget med å bruke lapper for å komme med innspill. Jeg forklarte så de tre kategoriene og gikk fort gjennom stikkordlista på flipover.
Så fikk alle 10 minutter til å komme med lapper. Når alle var ferdige med å skrive lapper etter en 7-8 minutter, så var det tid for få disse opp på tavla. Det ble gjort slik at man gikk opp etter tur, plasserte én og én lapp i en av de tre kategoriene, og framførte en kort forklaring og begrunnelse.
Det ble produsert 35 lapper fordelt på
- 17 høydepunkter
- 8 overraskelser
- 9 erfaringer.
Det ble så gjennomført en kort diskusjon som munnet ut i forslag til tiltak. Forslagene ble gruppert i 6 temaer. Det var viktig å komme fram til temaer alle var enige om.
Eksempel: Gruppering i temaer:
| Tema | Beskrivelse |
| Kravsporbarhet | Kravene ligger for det meste i Excel-filer. Har man kravene på plass i Jira kan man koble de sammen med testcaser og feilrapporter og med det få full spobarhet mellom disse, og en oversikt/indikasjon på hvordan testene dekker kravene. |
| Testdekning | Det er trolig noe redundans i testomfanget. Det vil trolig være nyttig å gå gjennom testene for å luke ut “duplikater”. |
| Organisering av testcaser, testsykluser og prosjekter i Jira/Zephyr | Prisendringer bør trolig være egne prosjekter, med egne testsykluser. Testcasene bør i utgangspunktet være prosjektløse (og også egentlig produktløse), men knyttes mot kravene de tester, og legges i testsykluser for eksekvering.
Det trengs en utredning av dette. |
| Involvering av kundestøtte | Kundestøtte syntes det var veldig nyttig å være med, de bidro med ekstra kompetanse på flere områder, og de var en viktig suksessfaktor for å komme i mål med testingen. Bør gjentas. |
| Testmiljøer | Vi opplevde lite problemer med testmiljøene, men det var på håret at fluxkondensatoren hadde blitt en show stopper. Man bør etterstrebe at utstyret på lab’en til en hver tid er i orden. Pr i dag er det betalingsterminalen på fluxkondensatoren som ikke fungerer for test. |
| Testdata | Billettene ble organisert vha “skruebokser”. Man bør ta en vurdering av hvilke billetter man ønsker å beholde for testing i andre sammenhenger. Man trenger isåfall en hylle eller plass i et skap for disse. |
Jeg avsluttet møtet ved å gi alle sjansen til å komme med en sluttkommentar for å kvalitetssikre at vi var kommet i mål.
Det hele klokket inn på 55 minutter.
Etterarbeid
Referatet ble gjort så enkelt som mulig med data om deltagere, tidspunkt og kort beskrivelse av gjennomføringen. Innholdet på lappene ble ført inn i “Høydepunkter/Overraskelser/Erfaringer”-tabellen.
Forbedringsforslagene (inkludert ting som var bra og som burde bevares) ble skrevet inn i en tabell med Tema og Beskrivelse.
Alt dette ble dokumentert i en wiki-side på intranettet. Alle deltagerne fikk så anledning til å kommentere på denne.
Så ble e-mail med link til wiki-siden sendt ut til alle interessentene.
Så, hva er det som er bra med dette?
Vi klarte å gjennomføre selve møtet på under én time, det er flere årsaker til det:
- Formen på møtet var klart definert på forhånd
- Forberedt og aktiv møteleder
- Gruppas sammensetning. Gruppa var jo ikke satt sammen for å fungere på retrospektivmøtet, men dette var en gruppe som jobbet effektivt gjennom hele prosjektperioden og uten de store fakter. Det ble lagt vekt på effektiv kommunikasjon og det preget også retrospektivmøtet.
- Prosjektet i seg selv var en suksess, noe som i seg selv bidro til å redusere omfanget på retrospektivet.
Punkt 3 og 4 er man ikke herre over, men jeg tror det først fremst er punkt 1 og 2 som danner grunnlaget for å lykkes med denne type retrospektiv.
Retrospektivmøtet resulterte i forslag til tiltak gruppert innenfor områder som man ble enige om i løpet av møtet. Disse dannet i neste omgang et bra grunnlag for å definere og tildele konkrete forbedringsoppgaver.
Så hva er det med formen som gjør dette effektivt?
Jeg tror at “Høydepunkter/Overraskelser/Erfaringer”-kategoriene løser opp og gir retrospektivet et mer positivt preg. Legg merke til at ingen av kategoriene er negativt ladet i utgangspunktet:
- Høydepunkter er den mest positive kategorien, her kom det innspill på ting som fungerte etter forventningene fordi noen hadde gjort en bra innsats.
- Overraskelser: Her kom det både negative og positive overraskelser. Det mest tydelige skillet på overraskelser og erfaringer er at overraskelsene er hendelser som vil kunne overraske også neste gang de skjer. Det vil si at man kanskje ikke helt skjønner hva som er årsaken.
- Erfaringer er hendelser som man har mer innsikt i. Både at ting fungerte fordi man gjorde det på en spesiell måte, eller at noe ikke fungerte fordi man hadde gjort slik og slik, eller fordi at man ikke hadde gjort noe for at det skulle fungere i det hele tatt.
Her snakker vi altså om nyanser, noe som dette eksempelet illustrerer:
| Høydepunkter | Overraskelser | Erfaringer |
| “Godt planlagt med ressurser og nødvendig utstyr.”
(Her synes en tester at det er gjort gode forberedelser.) |
“Lite problemer med testmiljøene.”
(Her er testleder overrasket over hvor lite trøbbel man hadde med miljøene.) |
“Sikre at testmiljøer er 100% oppe før testing.”
(Her ønsker en tester å videreføre og ytterligere forbedre forberedelsesaktivitetene.) |
Testmiljøer pekte seg ut som ett av temaene og munnet ut i følgende forslag til tiltak:
“Vi opplevde lite problemer med testmiljøene, men det var på håret at fluxkondesatoren hadde blitt en showstopper. Man bør etterstrebe at utstyret på lab’en til en hver tid er i orden. Pr i dag er det fluxkondesatoren som ikke fungerer for test.”
| Møteledelse: | Kontekst: |
| Sparte totaltid ved å ha møterommet og tavlene klare når møtedeltagerne møtte opp. | I en setting der prosjektgjennomføringen har mange utfordringer, eller en setting der det er flere motstridende interesser, vil det være mer utfordrende og heller ikke hensiktsmessig å gjennomføre et retrospektivmøte på tider ned mot en time. |
| Hadde klar og konsis sesjon med innledende informasjon. | Ved å forberede seg godt kan man i en velfungerende organisasjon kunne gjennomføre retrospektivmøtet i et litt høyere tempo, noe som vil kunne heve kvaliteten. Høyere tempo fører til mer engasjement, som igjen kan føre til ærligere tilbakemeldinger. |
| Satte av 10 minutter til å skrive lapper og overholdt tiden. | |
| Passet på at tempoet ikke dabbet av under plasseringen av lappene på tavla. | |
| Hadde ingen lappeflytting på tavla under diskusjonen og seansen med å komme opp med temaer for tiltak. | |
| Lot deltagerne få diskutere fritt, men hjalp til med å komme opp med navn på temaer som materialiserte seg, og var med på å formulere tiltak. | |
| Hadde ingen egen agenda som måtte landes i løpet av møtet, men brukte litt spissformuleringer for å provosere på en forsiktig måte. |
Epilog – gjennomføring av forslag til tiltak
For dette retrospektivarbeidet fikk jeg ikke mulighet til å følge opp forbedringsarbeidet, men den måten jeg liker å gjøre det på er å legge ut forbedringsforslagene som oppgaver i Jira. Oppgavene tildeles så personer som identifiseres som rett adressat for de forskjellige tiltakene. Referatet fra retrospektivmøtet legges i Confluence og lages slik at Jira-sakene synes i tabellen over tiltak. Status på sakene oppdateres da dynamisk etter hvert som det er progress i sakene.
Etter hvert som det gjennomføres flere retrospektivmøter, kan man samle alle sakene derfra på en Confluence-side koblet mot Jira.
Lista følges deretter opp i et dertil egnet forum som har ansvaret for kontinuerlig forbedring i teamet/prosjektet/organisasjonen.
Som alle vet så er det det å få gjennomført tiltakene som er den vanskelige delen. Derfor er det viktig at oppgavene delegeres og følges opp. Og at de som har vært med på å identifisere problemene og tiltakene både involveres og får informasjon om progresjonen i forbedringsarbeidet.
