Innhald
- OM DENNE BOKEN
- HVORFOR DENNE BOKEN?
- TA-DAH! MØT CHEAT SHEET
-
HER ER ØVELSENE
- \#1: «ETT ORD RETROSPEKTIV»
- \#2: “SJEKK-INN: SINT, TRIST, GLAD, REDD”
- \#3: “KONSTELLASJONER”
- \#4: “SISTE RETRO OPPFØLGING”
- \#5: “SPRINT TIDSLINJE”
- \#6: “STOLT - TAKKNEMLIG - LÆRT”
- \#7: “SPRINT PERFEKSJON SPILLET”
- \#8: “FUNGERER BRA, MÅ FIKSES”
- \#9: “MER MINDRE BEHOLD STOPP START”
- \#10: “SPEEDBÅT”
- \#11: “DOT-VOTING / PRIKK STEMMING”
- \#12, 13: “FRA TOPPEN” ELLER “BRYTE UT”
- \#14: “PROBLEM-EKSPERIMENT-HVEM-HVA-NÅR”
- \#15: “PLUSS OG DELTA-PLUSS”
- \#16: “MORO VS. NYTTE”
- OK. HVA NÅ?
- NOEN KOMPLIKASJONER
- BRYT GAMLE VANER
- SNU ARKET
- BIBLIOGRAFI
- TILBAKEMELDING
- Notes
Skrevet med dyp takknemlighet til alle grupper og enkeltpersoner jeg har jobbet med, som tillot meg å gjøre eksperimenter og lære hvordan man ikke skal gjennomføre agile retrospektives.
Skrevet for alle grupper og enkeltpersoner som jobber utrettelig for forbedringer ved å endre seg selv og miljøet rundt seg.
Til fordel for oss alle.
OM DENNE BOKEN
Denne boken er skrevet med iterativ og inkrementell metode (du er herved advart!), det du sitter med i hendene (eller på skjermen) er et av trinnene i boken som allerede er lansert.
LAST NED SISTE VERSJON
Den gjeldende versjon av boken er 1.3
Endringer i siste versjon:
-Forbedret layout for mobile lesere
-Lagt til et nytt kapittel på MULTI-LOKASJON OG DISTRIBUERTE RETROSPEKTIV
-Rettet feil og lagt til kommentarer fra korrekturlesere
Leanpub lesere
Hvis du har kjøpt denne boken fra leanpub.com, sjekk om det finnes en nyere versjon tilgjengelig. Gå til: https://leanpub.com/agile-retrospective-kickstarter.
Du kan også lese denne boken via din favorittleser i PDF, MOBI eller EPUB formater. Så nyt boken i ditt favorittformat.
Oversettelser
Boken er overstått til flere språk og arbeidet med dette fortsetter. Pr. desember 2016 er den oversatt til norsk, russisk, polsk og fransk. Flere språk er underveis.
Alle oversatte versjoner er samlet her: http://retrospective-cheat-sheet.com.
Er du interessert i å hjelpe til med oversettelse av boken, ta kontakt med info@retrospective-cheat-sheet.com
FÅ KOMMENDE UTGAVER AV BOKEN
Jeg jobber kontinuerlig med å forbedre boken. De neste utgivelsene inkluderer:
- Illustrasjoner for hver øvelse - allerede i gang!
- Forbedringer basert på din tilbakemelding
HVORFOR DENNE BOKEN?
YARB!
Enda en ny bok om retrospektiv? Hvorfor? Det finnes mange allerede1…
Ja! Og akkurat det er grunnen. Jeg holder workshops om retrospektiv (og mange andre emner) for Scrum Mastere, grupper og agile coaches. Min observasjon er at til tross for den store mengde informasjon som finnes om dette emnet, synes det fortsatt å være et stort gap mellom visdom i bøkene og hva folk faktisk bedriver i møterommene under skiltet: «Ikke gå inn. Retrospektiv i prosess».
Jeg håper å minske denne avstanden med en veldig pragmatisk og praktisk kickstarter for…
ER DENNE BOKEN NOE FOR MEG?
… folk som planlegger sin første retrospektive. Er det deg?
Boken er også for de som har prøvd å finne snarveier ved å kjøre de mest forenklede retrospektiv ved bare å spørre hva som fungerte og hva som ikke fungerte - og som bare får tomme blikk tilbake [^ f32]. Kanskje det er deg?
Jeg vet også om folk som har gjort mange retrospektiv og fortsatt finner Retrospective Cheat Sheet så nyttig at de holder den tett til brystet. Kanskje vil det være deg?
OM FORFATTEREN
Jeg er en Lean-Agile coach. Mitt første Scrum-eksperiment var i 2003. Siden da har jeg kurset grupper og og hjulpet organisasjoner til å bli smidigere. Jeg er stolt over å ha bakgrunn som ingeniør og av å kunne kalle meg programvareutvikler.
I 2008 jeg startet jeg AgileUkraine.org og har siden da co-arrangert dusinvis av Agile begivenheter, inkludert: Agile Eastern Europe conferences 2009-2015. Jeg er ofte gjest på andre konferanser der jeg snakker, hovedsakelig om agile coaching og organisatorisk design. Jeg er også sertifisert Scrum trener (CST), og underviser i Scrum over hele verden.
Jeg har vært så å utvikle det som har blitt en av de mest populære simuleringene av Scrum - lego4scrum som nå har blitt oversatt til mer enn 20 språk2.
Jeg blogger av og til på http://www.agiletrainings.eu/blog/. Besøk meg gjerne der.
TA-DAH! MØT CHEAT SHEET
Så det eneste jeg faktisk gjør i denne boken er å samle et sett av verdifulle øvelser som har fungert bra for meg og mine team i en lett-å-ta-med-seg-pocket-bok for ScrumMastere.
Cheat sheet består av 16 øvelser. Disse kan bli til over 250 retrospektive agendaer3 hvis de kombineres og stokkes om. Egentlig færre. Men fortsatt nok for å sette deg igang.
Så la oss dykke inn i det som kan være den mest pragmatiske mini boken på retrospectives noensinne skrevet (og forhåpentligvis også lest!).
AGILE RETROSPEKTIVE CHEAT SHEET
Denne plakaten kan lastes ned på http: www.retrospective-cheat-sheet.com.
Som du kan se så er øvelsene gruppert i fem forskjellige områder, hver merket med en grønn post-it lapp. Dette er et velkjent fem-trinns retrospektiv rammeverk, laget og beskrevet av Esther Derby og Diana Larsen i deres bok4.
Hver av oppgavene er beskrevet som et kapittel av denne boken. Vi kommer dit veldig snart. Men først: noen ting jeg tror du trenger å vite om struktur og bruk (og misbruk) av Cheat Sheet.
HVORFOR FEM-TRINNVIS RAMMEVERKET?
Siden jeg skriver denne boken for folk som kanskje ikke har lest Esther og Dianas bok ennå (meget anbefalt lesning), vil jeg kort dele min forståelse for bruk av rammeverket. Hvis du allerede kjenner til dette må du gjerne hoppe over denne delen.
Dette rammeverket er ikke det eneste som finnes 5 men det er uten tvil mest brukt, sitert og referert til. Det har også vist seg å fungere. Gjennom årene har jeg blitt vant til å lage min egen agenda ved bruk av rammeverket. Jeg begynner med et tomt A4 dokument, lister de fem trinnene til venstre og begynner med aktiviteter som passer…
The Retrospective Cheat Sheet, som denne boken er basert på, bruker akkurat dette formatet. Det er faktisk slik den ble laget.
Som Sam Kaner forklarer i sin bok om deltakende beslutningsprosesser 6: møtedynamikk har tre faser. Begynnelsen divergerende tenkning (når vi vil utvide horisonten), avsluttende konvergent tenkning (når vi snevrer inn og velger alternativer) og den mindre-behagelig “stønne sonen” i midten.
Tilordning av de fem stadiene i et retrospektiv til modellen med møtedynamikk, har gitt meg en bedre forståelse av hvorfor alle stadier er nødvendige å kjenne til for å gjennomføre en høykvalitets, forbi-status quo og engasjerende retrospektiv.
Mens sett scenen og avslutte retrospektivet stadiene tjener som en ramme (for å avklare målet med møtet, sette forventningene, tiltrekke seg folks oppmerksomhet, så avslutte og gjøre seg klar for handling), så utgjør de de tre sentrale stadiene målet med møtefasene: utvide, utdype og deretter innsnevre.
HVOR KOMMER ØVELSENE FRA?
Jeg har ikke laget dem. Vel, kanskje én eller to. Sannsynligvis ikke. Husker ikke. Uansett, mine team spurte meg aldri om det. De bryr seg ikke. Hva de bryr seg om er at retrospektivet er morsomt, nyttig og en god investering av deres tid og energi.
Jeg oppdaget at å bygge agendaer fra disse utprøvde aktivitetene nesten alltid fører til bedre retrospektiv enn hvis jeg startet med en tom side.
Det er også raskere (når du leser og forstår dem).
HVA ER VERDIEN?
Ved bruk av Cheat Sheet så settes det fart på prosessen med å lage agenda (det er derfor det kalles en Cheat Sheet… selv om gjenbruk ikke er juks!), men jeg må advare deg:
Retrospektive som er laget med disse øvelsene vil trolig ikke bli enklere å kjøre.
Og jeg tror faktisk ikke retrospektiv må være enkle, gode eller noen av delene.
Min definisjon av “gode retrospektiv” er at du først gir dine team nok tid til å definere de temaene som er viktige for dem, og deretter la dem engasjere seg i meningsfylte diskusjoner om hvordan de kan forbedre sin framtid.
Min definisjon av “gode retrospektiv” er at til tross for god struktur, meningsfulle diskusjoner, høyt engasjement og en konstruktiv atmosfære, så bruker teamet nok tid og energi på sine retrospektive og den avtalte planen ved at de gjør endrer seg selv, hvordan de jobber og miljøet rundt seg.
Så ha disse definisjonene med deg når du lager din agenda. Poenget er ikke å skape flotte agendaer, men å hjelpe folk til kontinuerlig forbedringer. Det er verdien du burde strebe etter.
HVOR MYE TID VIL JEG TRENGE?
For å gjennomføre et restrospektiv:
En god tid for retrospektiv som lages ved hjelp av dette Cheat Sheet er 90-120 minutter. Hvis du har mindre tid, som for eksempel en time (som aldri var nok for de teamene som jeg jobbet med), så kan du kombinere noen av aktivitetene eller hoppe over noen av de…Men pass på!
Vær forsiktig med å hoppe over trinn. Før du gjør dette, anbefaler jeg at du gjennomfører minst fem retrospektiv eller til du føler deg komfortabel med progresjonen. Deretter vil du kunne forstå hvilken rolle hvert trinn spiller. Bare da vil det være forsvarlig å ta snarveier.
“Make it work, then make it fast, pretty and yours”. Den som sa det har et poeng.
Tiden det tar å forberede et retrospektiv:
Min personlige erfaring er at det tar minst like mye tid å forberede en retrospektiv som dets planlagte varighet. Med erfaring kan du forkorte forberedelsene noe etterhvert.
ER DET ANDRE TING Å VÆRE OPPMERKSOM PÅ?
Ja, noen minimale katastrofer:
Jeg håper plakaten er selvforklarende7. Og ja - det er mange måter å mislykkes på, selv med Cheat Sheet i bakhånd.
Så noen råd som hjalp meg videre og å unngå noen av disse alvorlige feil på retrospektiv:
- Bruk nok tid til å forklare hvorfor retrospektives er nyttig. Det er helt greit å dedikere halvparten av tiden i en retrospektiv til denne diskusjonen. Spesielt når Scrum er nytt for gruppen, du er ny i gruppen, eller begge deler. Å ikke forklare “hvorfor” men gå rett til å forklare “hvordan” er en effektiv måte å ødelegge refleksjon på 8.
- Ikke tillate folk å klage, se etter unnskyldninger eller legge skylden på andre. Det er trolig viktigere å se opp for denne destruktive atferd enn å ha en god og flott agenda. ScrumMaster har autoritet til å stoppe dette ved å lære opp og veilede gruppen. Se om innføring i Responsibility Process og My Soup metaforer kan forbedre situasjonen 9.
- Hold resultatene fra retrospektiv synlig og tilgjengelig. Noe jeg har stor suksess med er å legge ut bilder fra Action Items flip-charts og f.eks laste dem opp til Retrospektive siden for teamets wiki. Det er goså en god ide å henge opp plakater i team-rommet og i nærheten av Scrum tavlen. Gjør gjerne begge deler.
- Føl flyten. Ikke overdriv dine agendaer. Hold de overkommelige men kraftige. Ikke få folk til gjøre det de hater. Hver øvelse bør tillate deltakerne å lykkes. Hver diskusjon bør drives av at gruppen er enige om å starte den. Hvis du føler at gruppen ikke er åpne for den strukturerte retrospektiv som du hadde planlagt, sjekk om en Beer’o’spective eller en Åpen Retrospektiv 10 er veien å gå.
HER ER ØVELSENE
#1: «ETT ORD RETROSPEKTIV»
Mål: hjelpe folk å forberede seg til emnet for møtet; skape en avslappet atmosfære, etablere et trygt miljø som inviterer folk til å snakke og dele.
Nedenfor er en av øvelsene jeg pleier å starte en retrospektiv med. Hvorfor? Fordi den er enkel men samtidig virkningsfull. Du har dine deltagere på møtet, så de er fysisk tilstede. Men hvor bevisste er de? Det tar vanligvis en stund å “komme” mentalt til et møte etter man har satt seg ned.
Med denne aktiviteten vi deltakerne få hjelp til å kunne resonnere i forhold til hvordan de opplevde siste sprint. Det er det viktigste målet med denne aktiviteten. Den kalles “ett ord” fordi du ber om en rask assosiasjon - ideelt bare ett ord. Mitt favorittspørsmål er å spørre om været: hvordan vil du beskriv siste sprint hvis du skulle beskrive den som været?
Et sekundært og mindre opplagt mål med denne aktiviteten er å gi alle en sjanse til å snakke. Jo tidligere du gjør dette på et møte (alle slags typer møter, ikke bare en retrospektiv), jo mer engasjement kan du forvente fra deltakerne. Å be alle om å si et ord i begynnelsen av møtet sender ut et kraftfullt budskap til alle - du er invitert hit for å dele og snakke om det du er opptatt av, din mening har betydning, aktiv deltagelse er hva vi er ute etter her.
Det er en enkel ide: la alle etter tur dele sin erfaring med siste sprint med ett ord.
Hvis noen ønsker å stå over er det ok, (det gjelder alle retrospektive aktiviteter som vi inviterer deltagerne til å være med på. De har alltid en mulighet for å stå over - dette er med på å skape trygghet.
Samle de ulike svarene og se om du kan bruke noen av disse metaforene og beskrivelsene for å lage flere historier om sprinten.
Jeg husker at vi gjorde denne øvelsen i et team og en person som vanligvis ikke snakket mye tok ordet og fortalte at hans siste sprint var “partially cloudy with a high chance of meatballs falling from the sky”.
Dette satte definitiv tonen for denne retroen!
Variasjoner:
Ja! Eksperimentere med hva som kan fungere bedre for gruppen din - ikke bli stående fast i dårlig vær. Prøv biler, sport, land, reiser, landskap, operativsystemer, årstider, navn på filmer, musikere…
Noen ganger har jeg bilder som deltagere kan velge fra. Nedenfor finner du åtte landskapsbilder jeg har brukt som har fungert bra:
- last ned 11
- skriv ut (i farger, bare noen kopier)
- og inviter deltakere til å velge det som beskriver siste sprint best
Jeg har også sett deltakerne kombinere ulike bilder på ganske rare måter. Hva de enn gjør - så er det greit. Forvent å bli overrasket, ikke vær dømmende, men nysgjerrig.
Du kan for eksempel spørre:
- Forklar for meg hvordan bildet du valgte beskriver din siste sprint?
- Hvilke aspekter av sprinten føltes slik?
For distribuerte retrospektive så pleide jeg å sette alle bildene i et collage og lot de velge fra dette. Dette virket også ok, men fysiske artefakter er bedre. Se hva som fungerer best for din gruppe. Hvis du ikke er sikker - spør dem!
#2: “SJEKK-INN: SINT, TRIST, GLAD, REDD”
Mål: hjelper for å beskrive tilstander og bli klar for møtet.
Dette er en sjekk-inn øvelse fra Core Protocols12.
Sint, trist, glad eller redd er vesentlige, fundamentale følelser vi alle deler. Våre følelser kan bli sett på som en blanding av disse fire enkle ingrediensene. Det å lære team hvordan de skal dele sine følelser ved bruk av disse fire tilstandene er en opplæring i selv-bevissthet og mindfulness.
Hvordan utfører jeg denne øvelsen? Skriv disse fire følelsene på en flippover eller en whiteboard og be alle dele sine tanker ved å bruke en kombinasjonene av de fire ingrediensene. Team medlemmene deler sine tanker en etter en. Ingen diskusjoner eller kommentarer er tillatt på dette tidspunktet.
Noen kommer bare til å si noen få ord…mens andre…vel er du heldig så vil de åpne opp og dele noe som er usagt men absolutt tilstede.
Jeg anbefaler å ikke benytte denne aktiviteten for ofte. Men i noen tilfeller, når vi alle vet at det har hendt noe alvorlig, men ingen snakker om det, så kan denne aktiviteten være en redning. Den lar også mennesker lette seg for ting de tenker på og snakke om sine følelser.
Som i situasjoner når det finnes stor stinkende elefant som har sluppet en i rommet, når noe som har skjedd som alle tenker på men ingen snakker om, som: skikkelig dårlig tilbakemelding fra en kunde, en medarbeider har nettopp annonsert at hun forlater firmaet, selskapet ble kjøpt opp av Microsoft (ikke f**n!), eller sprinten var spesiell på en ikke god måte…
Jeg gjør denne øvelsen hver gang jeg føler at gruppen blir distrahert fra å fokusere på produktet og samarbeidet ikke fungerer. Vanligvis på grunn av noe eksternt og utenfor gruppens kontrollert.
Denne øvelsen, hvis gjennomført skikkelig, har en dyp virkning på atmosfæren og skaper plass i retrospektive for gjennomtenkte samtaler.
De originale instruksjonene i denne protokollen sier at alle skal si «du er velkommen» etter at hver deltager har delt sine tanker. Dette skaper en enkel seremoni, og ønsker alle velkommen, uavhengig av hva de føler eller tror. Hvis dette høres rart ut for gruppen, utelat det eller tilpass øvelsen til gruppen.
#3: “KONSTELLASJONER”
Mål: bygge en felles forståelse av kompliserte saker, inkludert emosjonelle og rasjonelle vektorer; oppvarming på samme måte som med fysiske aktiviteter.
Det som er artig med denne aktiviteten er at det innebærer at ingen snakker. Jeg tror vi trenger å fortsette å komme opp med flere stille øvelser siden de ofte viser seg å være enkle, men effektive.
Hvordan fungerer dette? Du stiller gruppen noen spørsmål om deres holdninger til sitt arbeid. De svarer ved å plassere seg på hver sitt punkt i rommet.
For eksempel: sett en markør på gulvet og si at jo nærmere de er til merket, jo mer positivt er svaret deres, lenger borte- mer negativt.
Eksempler:
- Hvordan vil du gradere suksessen i den siste sprinten?
- Hvor godt var vårt samarbeid?
- Hvor fornøyd er du med at produktkvalitet ble utelatt?
Noen varianter av denne aktiviteten er beskrevet i andre bøker referert i bibliografien.
Når folk har plassert seg, spør gjerne om noen er villig til å dele noen tanker: «noen som ønsker å kommentere dette?» Vanligvis er det noen som deler.
#4: “SISTE RETRO OPPFØLGING”
Mål: holde teamet ansvarlig for planene de lager; se fremdriften og verdsette det.
Vi vet alle at retrospektive burde avslutte med en handlingsplan. Så mellom siste og gjeldende retrospektiv bør gruppen ha jobbet med å implementere de planlagte endringene ved avtalte eksperimenter. Hvis dette ikke skjer er din retrospektive i alvorlig fare.
Hvorfor? Fordi en dag kommer noen med følgende kommentar: “Hvorfor skal vi bruke to timer igjen denne uken på en retrospektiv? Vi har allerede en liste over problemene på vår wiki… La oss kode i stedet.” Har han et poeng? Ja. Vil du tillate at det skjer? Nei.
Først: unngå lange lister over problemer som er samlet og dokumentert. Begrens utfallet av en retro til 1, 2 eller maksimalt 3 veldig viktig og løsbare utfordringer.
Dernest: Påminn teamet om deres ansvar. Noen ganger må man si det ganske klart til teamet: “folkens, dette er deres problemer som dere flagget på deres retrospektive; Hvis dere ikke kommer til å arbeide med dem, så vil ingen andre heller».
Så i løpet av retroen, gå gjennom handlingsplanen fra tidligere retrospektive. Sjekk oppgaver som er utført, marker de som ikke er utført. Visualiser det. Men ikke klandre noen om ikke alle aktiviteter er utført. Ikke gjør at noen føler seg dårlig. Forsøk å øke deres bevissthet til at uansett hva de blir enige om så vil dette bli kontrollert neste gang. Dette er vanligvis nok til å få ting i gang.
#5: “SPRINT TIDSLINJE”
Mål: hjelpe enkeltpersoner til å oppfriske minner og samle historier fra sprinten.
De fleste av oss er ganske dårlige til å huske hva vi gjorde i går. For å ikke snakke om å huske hva andre gjorde. Denne øvelsen vil være et god redskap for å revitalisere gruppehistorien fra den siste sprinten.
Bruk en maskeringstape for å visualisere en tidslinje. Et par meter holder fint for en to-ukers sprint.
Be deretter i stillhet alle om å skrive ned på post-it lapper: tenk på alle hendelsene som skjedde i sprinten. Alt teller med: fester, sykefravær, releaser, møter, konflikter, overraskelser. Én hendelse pr. post-it.
Når de er ferdig med å skrive post-its, be hver enkelt komme frem og fortelle sin historie nå de å henger sine post-it´ene i kronologisk rekkefølge langs tidslinjen. Du bør begrense tiden per person. 1-2 minutter er bra.
Som en variasjon kan du også be deltagerne tegne smilefjes på post-it´ene for å vise hva de føler om hendelsen.
Denne øvelsen fungerer også utmerket for andre tidslinjer, for eksempel kvartalsvise aktiviteter. Faktisk, jo lengre perioden retrospektivet dekker, jo bedre fungerer dette verktøyet. Denne øvelsen er også godt beskrevet i boken av Esther & Diana 13.
#6: “STOLT - TAKKNEMLIG - LÆRT”
Mål: hjelpe enkeltpersoner forsterke positive følelser og erfaringer, sjekke tilstanden i gruppen og lære å uttrykke takknemlighet.
Denne øvelsen har jeg ikke sett i noen bøker så send meg gjerne lenker hvis du har sett denne øvelsen i en bok. Jeg er ikke sikker på hvor den kommer fra 14, men det er uansett en av mine favorittaktiviteter for retrospektiv.
Del veggen eller en whiteboard i tre deler. Merk dem så “Stolt”, “Takknemlig” og “Lært”.
Forklar så områdene:
- STOLT: Hva har du oppnådd i denne sprinten som gjorde deg stolt? Dette kan være personlig eller teamprestasjon. Oppfordre til å skrive noe de personlig er stolt av.
- TAKKNEMLIG: hvem ønsker du å takke som gjorde noe spesielt for deg eller gruppen i denne sprinten? Oppmuntre alle til å skrive minst ett kort med ett navn på.
- LÆRT: Hva har du lært i denne sprinten? Forklar at en sprint er en fiasko kun hvis det ikke førte til noe læring.
La teamet få noen minutter i stillhet til å skrive post-its. Be de så en etter en dele med de andre ved å gå opp til tavlen og henge opp sine kort15. Som en variasjon kan takknemlig-kortene kan eventuelt deles ut direkte til den eller de som er navngitt.
#7: “SPRINT PERFEKSJON SPILLET”
Mål: hjelpe gruppen med å uttrykke deres egen evaluering av arbeidet, uttrykke frykt og bekymringer, i tillegg til stolthet og takknemlighet.
Dette er en variant av Perfection Game fra Core Protocols16. Isteden for å være en dialog mellom to personer som gir og får tilbakemeldinger, så er dette en gruppeaktivitet.
Tegn en vannrett akse (eller bruk maskeringstape). Lag en skala, f.eks 1 til 10.
Be alle om å velge en post-it og skrive et tall som representerer en personlig følelse av sprintens suksess (eller noe annet du ønsker å måle). Samle sammen post-it´ene (som er anonyme), og lag et stolpediagram ved å plassere post-it med samme nummer oppå hverandre.
Spør gruppen hva som de kunne gjort annerledes for å kunne en score 1 poeng høyere? Hva skulle de gjort annerledes for å gi den høyeste poengsummen? Alternativt la de snakke i mindre grupper.
En forlengelse av denne aktiviteten er å lage flere skalaer for ulike dimensjoner du er interessert i å få målt: produktkvalitet, samarbeidsnivå, teknisk kvalitet. Du kan også lage idédugnad på emnene med teamet. Bruk dot-voting og velg de høyest prioriterte emnene17.
#8: “FUNGERER BRA, MÅ FIKSES”
Mål: hjelpe gruppen med dele av deres egen evaluering og holdninger til prosessen.
Trolig den mest kjente øvelsen. Godt kjent før noen bøker om retrospektiv i det hele tatt var blitt skrevet. Jeg synes øvelsen fremdeles er svært nyttig, særlig i forhold til små grupper, og med begrenset tid og korte sprints.
Del en flip-over i to halvdeler og be deltagerne dele sine tanker. Foreslå at de skriver ned i stillhet før de begynner sin deling.
Post-it´ene fra «Trenger å fikses» skal senere grupperes og prioriteres.
Eksperimenter med å navngi kolonnene:
- hva er bra nok - hva trenger oppmerksomhet
- hva som driver oss fremover - hva er som holder oss igjen
- på den lyse siden - på den mørke siden
Hvis du føler at denne todelingen og dualismen skaper mange konflikter og bortkastede diskusjoner, bruk flere muligheter alternativer, f.eks som beskrevet i den neste øvelsen: “Mer mindre behold stopp start”.
#9: “MER MINDRE BEHOLD STOPP START”
Mål: hjelpe gruppen analysere sine arbeidsprosesser ved å evaluere ulike aspekter: uttrykke holdninger til regler og praksiser som følges eller blir ignorert.
Del en flippover (eller en del av veggen) i følgende deler: - gjøre mer - gjøre mindre - fortsette å gjøre
Alternativt legge til tre: - slutte å gjøre - starte gjøre - prøve gjøre
Start med noen minutter stille skriving.
Be alle foreslå endringer ved klistre opp sine post-it´s. Alle kan skrive så mange post-it´s de ønsker innenfor de forskjellige kategoriene. Dette er en god øvelse for å fange opp mange ideer.
Når man har samlet alle post-it´ene på tavlen, så er det en god ide å gruppere og la teamene prioritere de ulike ide-gruppene (f.eks med dot-voting).
Flere varianter av denne øvelsen er beskrevet i andre retrospektiv bøker, se Bibilografien.
#10: “SPEEDBÅT”
Mål: å vurdere prosessen fra et høyere perspektiv og lage et inntrykk.
Dette er en øvelse fra Innovation Games18. Også kjent som “Seilbåt” i andre retrospektive bøker. Dette er en metaforisk variant av “Fungerer godt, må fikses”. Det innebærer også tegning, som gjør møtet litt mer gøy.
Tegne en båt med - seil - symboliserer hva som fungerer - anker - symboliserer hva som ikke fungerer
Du kan også legge til (men ikke overdriv) - horisonten - visjoner, håp og planer - skjær og hai - risikoer - andre skip og sjørøvere - konkurrenter
Be deltagerne skrive og feste sine post-it´s til der det hører til på bildet. Flere seil og ankere gir god mulighet for grupperinger.
Jeg anbefaler ikke å gjøre denne øvelsen på hver retrospektiv. I min erfaring fungerer det fint for grupper som er nye til retrospektiv, fordi det skaper gode bilder som er lette å huske. La gjerne gruppen tegne båtene selv.
Hvis du jobber med flere grupper- la hver gruppe tegne hver sin båt og jobbe selvstendig. I et senere trinn kan du samle problemer fra hver gruppe/båt og kombinere diskusjonene, eller følge opp med et felles retrospektiv19.
#11: “DOT-VOTING / PRIKK STEMMING”
Mål: få en liste over emner i prioritert rekkefølge ved å oppnå gruppens konsensus om rekkefølgen.
Brukes når du skal prioritere/ordne en samling av ideer. God trening rett etter “Mer mindre beholde slutt start”, “Fungerer bra, må fikse” og “Speedbåt”.
Forklar til gruppen at det er ikke mulig å løse alle problemene innenfor den korte tiden en sprint varer. Prioritering og fokus er nøkkelen.
Gi alle noen virtuelle prikker som de bruke for å stemme. Altså, be alle om ta en markørpenn 20 og være klar for stemmegivning.
Tell antall prikker på hver post-it og sorter dem i synkende rekkefølge. Det er en god ide å delegere telling og sortering til gruppen. Involvering av deltakerne er en nøkkelkompetanse for en fasilitator, så gjør det så ofte du kan. Lat som du er lat, gjør bevisst feil, be om hjelp.
Ved å lære bort denne enkle prioriteringsteknikken kan du ta ferie uten å bekymre deg for at gruppen vil ende opp i endeløse diskusjoner om hva som er viktigst.
#12, 13: “FRA TOPPEN” ELLER “BRYTE UT”
Mål: diskutere en prioritert liste over emner, sekvensielt eller i parallell.
Når du har laget en liste over tema som skal diskuteres har du to alternativer:
- diskutere fra toppen av listen en etter en sekvensielt
- dele opp i mindre grupper og diskutere emnene http://less.works/less/framework/overall-retrospective.html
Dette er essensen av et retrospektiv. Selv om du kanskje har nok tid, ikke diskutere alle temaene. Fokuser! La gruppen diskutere de topprangerte emnene. En god ide er å sette av tid til hele hele aktiviteten og også til hver enkelt diskusjon.
Sekvensiell eller parallell - når du skal bryte ut? Her er noen «tommelfingeregler» i forhold til når bryte ut:
-
Mange personer.
Jo fler personer det er - jo verre er det å gjennomføre sentralisert styring. Så bryt ut i mindre grupper hvis du kan danne flere grupper på 3-5 personer. - Forskjellige klynger av temaer. Hvis du oppdager veldig forskjellige emner som ulike grupper mennesker ønsker å diskutere separat (f.eks kodestandard og en diskusjon om wireframes) - foreslå å bryte ut, eller vær klar til å gå med på hva gruppen bestemmer seg for. Avgjørelsen er deres.
- Distribuert eller multi-lokasjon retrospektiv. Hvis en retrospektiv gjennomføres på flere lokasjoner, bryt ut for å la hvert sted ha nyttige diskusjoner, se kapittel Multi-lokasjon og Distribuerte Retrospektiv for flere ideer. Ved f.eks outsourcing, vil hver gruppe kunne diskutere ting mer åpent og på sitt morsmål før du deler oppsummeringen med alle.
Hvis du skal bruke bryte ut alternativet, husk å følge med på tiden og be hver gruppe om å dele sine hovedpunkter og forslag til endringer med hele gruppen.
#14: “PROBLEM-EKSPERIMENT-HVEM-HVA-NÅR”
Mål: ha en strukturert diskusjon ved å analysere problemet før fremlegging av mulige løsninger og handlingsplan.
Uansett hva du velger - sentralisert eller distribuert - er det en god idé å foreslå et format for en strukturert diskusjon.
Ett format jeg bruker ganske ofte er dette. Del en flip-over ark i tre områder:
- Problem
- Eksperimenter
- Hvem hva når (eller HHN)
Analyser problemet
For hvert diskusjonsemne hjelp gruppen å oppdage det underliggende problemet før de diskuterer mulige løsninger. Vi vet alle at ingeniører har en tendens til å hoppe rett til løsningen.
Forbli i problemsfasen; - Be om eksempler. Hvis ingen eksempler kan gis - foreslå å forkaste problemet som for abstrakt til å kunne løses. - Sjekk om problemet er innenfor teamets kontroll eller innflytelse21. - Gjøre “5 Hvorfor” øvelsen eller bruk en annen teknikk for å finne rotårsakene til symptomene. - Sørg for at resultatene av diskusjonen dokumenteres, f.eks på en flip-over.
Lag en idedugnad rundt eksperimentene
Når gruppen er klar over hva som er problemet start med mulige løsninger. Hjelp alle med å forstå at vi samler ideer til eksperimentet gruppen kan gjennomføre. Avhengig av gruppestørrelse og gruppedynamikk, så kan bryte-ut aktivitet være nyttig her. Be for eksempel deltakerne om å arbeide i par og brainstorme mulige eksperimetner for det analyserte problemet. La så gruppene pitche sine forslag. Sjekk for raske løsninger, konsensus, sterk vilje til å gjennomføre et av eksperiementene, alternativt kan man bruke dot-voting for å finne eksperimentet som skal gjøres neste sprint.
Spesifiser Hvem-Hva-Når
Når et eksperiment eller et sett av eksperimenter er identifisert må teamet bli enige om hvem som skal gjøre gjør det og når. Denne diskusjonen må være spesifikk. Hvis gruppen bestemmer seg for å arbeide i par eller mini-grupper, så er det kjempefint - skriv navnene på alle som er ansvarlige.
Ikke press. Hvis det ikke finnes noen frivillige, minn gruppen på at dette er deres problem som de stemte frem. Ikke skriv navnet ditt hvis ingen andre er frivillige. Ha i bakhodet feilen med at ScrumMaster Takes It All (se kapitlene som omhandler feil og anti-patterns).
Som Scrum Master tar jeg kun på meg ansvaret dersom det er riktig for mine kvalifikasjoner og tilgjengelighet. Og også selvfølgelig om gruppen ønsker at jeg skal komme inn og hjelpe til.
Hvis du desperat ønsker å ta en oppgave eller to - samarbeid med noen i teamet.
#15: “PLUSS OG DELTA-PLUSS”
Mål: hjelpe å samle ideer om hva deltakerne likte med retroen (positive), samt hva som krever forbedring(delta-pluss).
- Del en flip-over i to deler eller bruk to flip-over ark. Kall den til venstre “+” og den andre “Δ+”.
- Forklar at minus poeng (ikke konstruktiv tilbakemelding) kan konverteres til et delta punkt (en forespørsel om endring). Gi et eksempel: “vi ikke har nok tid - det er et minus; la oss bruke mer tid på viktig emner på neste retro - en delta”.
- Be deltakerne påpeke hva de synes var bra og hva som trenger forbedring. Noter mens de snakker. Det er OK å skrive et sammendrag, f.eks “mer tid” for “la oss bruke mer tid i neste retro på viktig emner”.
- Be om flere pluss før dere tar går til delta-pluss.
- Når negative poeng (“minuser”) deles, hjelp deltagerne med å konvertere de til delta-pluss før du skriver dem ned. Alle minus kan konverteres til en delta.
- Fortsett delingen ved å stille åpne og oppmuntrende spørsmål som: “Hva ellers likte du? Noe annet vi bør vurdere å forbedre?”
Alternativt, i stedet for at en fasilitator (du) skriver ned ideer en etter en (tar tid og kan resultere i universell gruppetanke), be alle om å skrive på hver sine post-it´s og feste de på flip-over´en. Du kan eventuelt be folk dot-vote på delta-pluss for å prioritere forbedringer.
Denne øvelsen har jeg lært Sergey Dmitriev og flere andre i forskjellige varianter.
#16: “MORO VS. NYTTE”
Mål: måle hvor morsomt og hvor nyttig retrospektiv var.
- Lag en loddrett akse med maskeringstape på døren/veggen.
- Marker toppen av aksen med :-), en midtre del med :-|, og bunnen med :-(.
- Legge til en vannrett akse “bruk” og dele den i tre deler: “lite eller ingen nytte”, “OK” og “Super”.
- Be deltakerne idet de forlater møtet, sette en post-it hver på hvor mye de følte at tiden de investerte var verdt. Betydning: hvor nytting tiden de brukte på møtet var.
Alternativer:
- I stedet for smileys, bruke en rangering: f.eks 1 til 5 eller 1 til 10.
- Du kan også i etterkant av møtet ha en diskusjon rundt forbedringer i stedet for at de bruker en post-it.
- Istedet for å be om tomme post-it (det er jo sløsing), kan de skrive ned sine forslag til forbedringer - du vil da få både et diagram og ideer samtidig.
- Når alle post-its er oppe, bruk en dot-voting for å prioritere ideene.
OK. HVA NÅ?
Nå som du er kjent med de forskjellige øvelsene kan du starte med å lage din egen agenda ved å bruke øvelser fra Cheat Sheet.
TRE FORHÅNDSDEFINERTE AGENDAER
Her er noen eksempler på forhåndsdefinerte agendaer du kan ta i bruk umiddelbart:
AGENDA A
FASE | AKTIVITET |
---|---|
1 Sett scenen | Konstellasjoner |
2 Samle Data | Oppfølging fra siste Retrospektiv, Sprint perfeksjon |
3 Generere innsikt | Mer Mindre Behold Stopp Start, Dot-voting |
4 Bestem aksjoner | Fra Toppen, Problem - Eksperimenter - Hvem-Hva-Når |
5 Avslutt | Tid vs. Nytte |
AGENDA B
FASE | AKTIVITET |
---|---|
1 Sette Scenen | Innsjekking: Sint Trist Glad Redd |
2 Samle Data | Oppfølging fra siste Retrospektiv, Sprint tidslinje |
3 Generere Innsikt | Speedbåt, Dot-voting |
4 Bestem aksjoner | Fra Toppen, Problem - Eksperimenter - Hvem-Hva-Når |
5 Avslutt | Tid vs. Nytte |
AGENDA C
FASE | AKTIVITET |
---|---|
1 Sette scenen | Ett ord retrospektiv |
2 Samle Data | Oppfølging fra siste retrospektiv, Stolt-Takknemlig-Lært |
3 Generere innsikt | Fungerer bra, Må Fikses, Dot-voting |
4 Bestem aksjoner | Bryte ut, Problem - Eksperiment - Hvem-Hva-Når |
5 Avslutt | Pluss & Delta-pluss |
Mens agenda «A» og «B» er like bra for alle samlokaliserte grupper, så kan agenda «C» fint brukes for en distribuert multi-lokasjon retrospektive. Se kapittelet om «“Multi-lokasjon distribuerte retrospektiv”.
RETROSPEKTIV SJEKKLISTE FORBEREDELSER
Her er en sjekkliste som kan hjelpe deg i forberedelsene:
- Hva var handlingsplan fra forrige retrospektive?
- Har du tatt på deg ansvar for en oppgave som enda ikke er løst?
- Hva slags tilbakemeldinger kom gruppen med i forhold til å forbedre retrospektiv? Meldte noen seg til å hjelpe til med å gjennomføre neste retro?
- Hvor mye tid har du satt av til møtet?
- er det en rask, vanlig eller utvidet retrospektiv?
- Hvilke hendelser, uhell eller aktiviteter har skjedd, som du vil at gruppen skal fokusere på?
- Hvilken form for visualisering kan du dra nytte av?
- Finnes det et overordnet tema eller emne for denne retrospektive som du vil foreslå for teamet?
- Har teamet samarbeidet med noen eksterne som de muligens ønsker å invitere til møtet?
- Har du all rekvisita du trenger til retrospektivet tilgjengelig?
- Er det noen flip-charts du bør lage på forhånd?
NOEN KOMPLIKASJONER
MULTI-LOKASJON OG DISTRIBUERTE RETROSPEKTIV
Alle øvelsene jeg har samlet i Cheat Sheet fungerer veldig bra når teamet er samlokalisert, det vil si tilstede i det samme rommet.
Det er det ideelle. Ikke bare for retrospektiv, men generelt for samarbeid og smidig, siden vi verdsetter rik kommunikasjon ansikt til ansikt.
Men hva om teamet er spredt og deltagerne jobber på forskjellige steder? Er du dømt til å mislykkes? Eller hvis teamet er lokalisert utenlands med en Produkteier som jobber fra hovedkontoret? Hvordan kan man gjennomføre retrospektiv i en slik kontekst?
Hvis du har lest Agenda C fra kapitlet “Tre forhåndsdefinerte agendaer”, så vil noen øvelser fremdeles kunne fungere, selv om teamet er distribuert. Men finnes det flere tips?
Javisst, her er noen tips om hvordan man kan gjennomføre distribuerte retrospektiv:
Tips #1: Finn et verktøy som kan tillater samtidig skriving
… som Google Docs eller lignende. Opprett ett dokument og del det med alle på de ulike lokasjoner. Etter møtet kan det samme dokumentet fungere som en oppsummering av retrospektivet. Det gjør det også lettere å dokumentere. Men unngå å bruke slike verktøy hvis du er samlokalisert!
Vær oppmerksom på at de mest brukte wiki-samarbeidsverktøy vanligvis ikke tillater samtidig redigering. Videre viser de vanligvis ikke at noen på andre siden av verden kanskje skriver på det samme dokumentet samtidig. Så sørg for å velge det rette verktøyet. Og gjerne de som er gratis- da kan de enkelt byttes ut.
Tips #2: Prøv i det lengste å unngå lange monologer
….det vil gjøre folk uengasjerte.
For å klare dette, må vi bestemme hvordan vi kan tilpasse øvelsene for et distribuert scenario. Her er tre hovedtyper av øvelser:
Type A: Round-Robins. Øvelser som ikke krever mye snakking kan enkelt utføres sekvensielt der man snakker en og en (round-robin), selv om man er på flere steder
Type B: Bryte-ut. Aktiviteter som krever mer snakking: disse kan utføres i mindre grupper på alle lokasjoner samtidig.
Type C: Work-outs. Alle aktiviteter som krever skriving, tegning, manipulering med post-its…dette er øvelser som kan utføres samtidig i verktøyet. Det kan oppnås ved at man skriver fra samme sted til samme tid - enten i grupper eller individuelt.
Her er klassifiseringen av aktivitetene fra Cheat Sheet basert på de tre typene (A, B og C over):
A: Round-Robins
Kjør disse aktivitetene sekvensielt med alle involverte:
- Ett ord retrospektiv
- Sjekk-inn: Sint, Trist, Glad, Redd
- Stolt-Takknemlig-Lært
- Sprint Perfeksjon spill
Du bør minne alle på å dele bare noen få ord.
B: Bryt ut i grupper
Kjør disse aktivitetene i mindre (samlokaliserte) grupper:
- Oppfølging fra siste retrospektiv
- Problem-Eksperimentet-HHN
- Fra toppen/Bryte ut
Disse aktivitetene utføres i mindre grupper, par eller triader. Når gruppene har utarbeidet noe, så samler de seg og deler det de har kommet frem til.
Jeg foretrekker samlokaliserte grupper slik at folk kan arbeide ansikt til ansikt. Det er den mest effektive måten å formidle informasjon på.
Men hva hvis du har noen deltagere som jobber hjemmefra eller er på en øde øy? Da vil en eller flere team være ansvarlig for å inkludere disse og kommunisere via internett, mens de andre er sammen fysisk i en gruppe.
C: Work-Outs
Kjøre samtidig i mindre grupper med et skrive/tegne verktøy:
- Sprint tidslinje
- Fungerer Bra, Må Fikses
- Mer Mindre Beholde Stopp Start
- Speedbåt
- Dot-voting
- Pluss og Delta pluss
- Tid vs. Nytte
Disse aktivitetene kan gjøres individuelt eller i mindre grupper ved hjelp av et enkelt samhandlingsverktøy.
Logikken bak å danne grupper er den samme som som for Bryt-Ut aktiviteter: samlokalisering er nøkkelen og å foretrekke.
Etter at hver gruppe har nedtegnet sine ideer, samles gruppen for en felles diskusjon av resultatene.
Som du kan se fra klassifiseringen så er de fleste av aktivitetene egnet for distribuert multi-lokasjon retrospektiv (det eneste unntaket er konstellasjoner).
Noen aktiviteter kan gjøres uansett, for eksempel Stolt-Takknemlig-Lært kan gjøres i alle grupper etter en kort stille-skrivings aktivitet eller innenfor bryt-ut grupper. Jeg ville velge det andre alternativet, og når det er en mulighet til å gjøre minst en del av en aktivitet i mindre samlokaliserte grupper - så vil det være mitt valg. Hvorfor? Fordi det er der kraften i selv-organisering skapes.
Det er vanskelig å forvente samme effekt når du arbeider med et stort team hvor mennesker er spredt og kommuniserer gjennom en mikrofon. Slike møter vil kreve mer koordinasjon, mer styring, mer ledelse, mer kaffe. Det er bortkastet.
Tips #3: Balanser engasjement mellom ulike lokasjoner
Når du kjører en A-type øvelse, sørg for at du balanserer engasjementet mellom alle lokasjoner, en god måte å oppnå dette på er å spørre en person som snakker å si navnet på en tilfeldig person i teamet som skal være den neste som snakker. Dette tilføyer også litt skrik og skrål mellom lokasjonene. Dette vil du ha mer av.
B-type aktiviteter som krever lange samtaler kan også gjøres i mindre grupper og med video/telefon. For eksempel, det kan være et tema rundt prosjektet som flere utviklere fra forskjellige lokasjoner ønsker å bidra til. De kan starte en annen video/telefon konferanse seg imellom under bryt-ut-tiden. Når det er gjort, vil de rapportere sin konvergerte tenkning til den samlede gruppen.
Tips #4: Lær bort ideer om samarbeid til teamet
For å være istand til å velge mellom en rekke alternativer så må du være oppmerksom på dem. Pass derfor på at du bruker litt tid på lære bort disse ideene til teamet. “Sett scenen” fasen synes å være best egnet for dette.
Så, fire tips, 1000 timer med praksis - og du er der. Faktisk vil bare delvis anvendelse av disse ideene gjøre dine eksterne møter vesentlig mer produktive enn dagens telefonkonferanser.
BRYT GAMLE VANER
Du har laget en god agenda, du har gjort alle forberedelsene, menneskene deltok, alt gikk OK….men du føler fortsatt at retrospektivet var litt så der, deltagerne sloss ikke for å ta på seg oppgavene. Til tross for alle diskusjonene - dere ble ikke enige om noen reelle forbedringer eller en handlingsplan.
Hvorfor var det slik? Poenget er at: retrospektiv krever noe vi ikke er programmert til å gjøre som standard, med mindre vi trener oss opp mentalt til å ta ansvar for vår fremtid.
Vi, mennesker, har lagt til oss vaner der vi ser etter utvendige årsaker til problemer. Slik type tenkning reduserer konstruktive måter å se verden på og fikse utfordringer. Faktisk, hvis du finner noen eller noe der ute du kan legge skylden på eller rettferdiggjøre problemet, trenger du ikke lenger kaste bort energi på å løse problemet. Problemet er borte. Energien er ivaretatt. Alle er glade. Vel, på en måte. Men i virkeligheten - var det noe som endret seg?
Her er et par verktøy som hjelper meg å snakke med team om ansvar.
MY SOUP
Jeg har hørt denne om modellen fra forskjellige personer, ikke sikker hvor den opprinnelig kommer fra. Dette er scenarioet:
Du sitter ved et bord. Foran deg er din tallerken med suppe (eller bedre ukrainsk borsch) - du kan spise den, dele den, salte den, helle den ut om du vil. Det er helt under din kontroll.
Rundt deg har du andre mennesker med sine tallerkener, retter og bestikk. Du har ikke så mye av kontroll lenger, men du kan fortsatt be andre om å flytte sine tallerkener rundt, å skynde seg, å lage mindre støy mens de spiser… Du kan sikkert ha innflytelse på ting der, men ikke direkte kontroll. (Det unge nygifte paret som spiser fra hverandres tallerkener er ikke med i vår ligning her).
Og rundt ditt bord i restauranten er det andre bord med fremmede som hvisker hemmeligheter til hverandre, diskuterer siste nytt og lovene i kvantefysikk - typiske emner, ja du vet. Du kan knapt påvirke dem, for å ikke snakke om noen form for kontroll. De er utenfor din rekkevidde.
Det er metaforen. Du vil at dine team fokuserer på problemer de kan kontrollere, eller i det minste påvirke. Og den gode nyheten er at ethvert problem kan sees ut i fra min-suppe-og mitt-bord perspektiv.
Som team coaches er vi ansvarlig for å lære våre team å endre sine vaner (eller få nye vaner) og begynne å tenke på “jeg” og “vi” perspektiver: Hva kan VI gjøre med problemet vi har foran oss?
Her er noen eksempler:
En klage: «Styret forandrer stadig organisasjonsstrukturen.» Coach spør: “Hva kan vi gjøre for å påvirke deres beslutninger i fremtiden?”
En annen klage: “Men andre grupper bryter alltid de APIene vi er avhengig av. Coach spør: “Hvordan kan vi gjøre dem oppmerksomme på at det er et stort problem for oss?”
Enda en klage: “Produkteieren har ikke tid til å gjøre nok elementer i Produktkøen klare til sprinten.” Coach spør: “Hva kan vi gjøre for å sørge for å ha nok Produktkøelementer tilgjengelig til hver sprint?”
ANSVARSPROSESSEN
Ikke en fan av supper?
Tenk deg, du er sent ute til en Daglig Scrum som du har brukt mye tid på overbevise team-medlemmer at de skal ha regelmessig.
I stedet for å ta bussen, så bestemmer du deg for å ta bilen - som sparer deg rundt 17 minutter, så du har gode sjanser på å rekke frem i tide tross alt!
16 minutter senere parkerer du bilen foran kontorbygningen…og i farten kommer du til å skrape opp en annen bil fordi du prøver å parkere bilen på en trang plass. SCHCRRRR… - sier bilen din. Fankern også- sier du tilbake.
Hva skal jeg gjøre nå?
Vel, jeg har bodd over 30 år i Ukraina. Så jeg er ikke sikker på deg, men min første tanke er å se meg rundt og hvis ingen har sett det - parkere bilen på et annet sted.
Jepp. Og problemet er borte. Bilen er skrapet opp over alt uansett, så det gjør ingen forskjell.
Men hva hvis noen har sett deg? Og ja, disse gatekameraene… Hvem vet…
Men hvor dumme er disse menneskene som parkerer sine biler på en så dårlig måte og gir meg så liten plass? Det er så mye mer plass her og der… dårlige sjåfører!
Og jeg? Jeg prøvde å gjøre mitt beste! Jeg måtte jo komme i tide til mitt viktige møte. Jeg kommer helt sikkert for sent. Men hva kan jeg gjøre? Folk vil forstå dette. Slike ting skjer ikke hver dag…
Likevel forrige måned hadde jeg en ulykke med min kones bil. Gosh. Jeg er slik en elendig sjåfør. Jeg burde ha tatt bussen og brukt bilen bare når det var virkelig nødvendig. Jeg gruer meg virkelig til å fortelle mine team kamerater denne historien.
Så hva gjør jeg nå? La meg se hva skaden på den andre bilen er…Hmmmm, ikke bra. Jeg må betale ham, siden min forsikring ikke vil dekke dette. Jeg ønsker virkelig ikke å kaste bort flere tusen kroner. Men jeg antar jeg må. Så er her mitt visittkort. Jeg håper det blir tatt av vinden når sjåføren av denne andre bilen kommer for å hente sin bil og aldri ringer meg tilbake…
Vi er ikke ansvarlige eller uansvarlige mennesker. Dette er en prosess som skjer hos alle mennesker.
Så vi lærer våre team-kamerater dette så de blir klar over dette indre spillet vi alle spiller. Etterhvert kan man selv oppdage at man skylder på andre, rettferdiggjøre eller skylde på forpliktelse. Dette er ikke ansvarlig atferd. Det er sonen for null læring. Et kjipt sted å være………tenk på det et øyeblikk.
Bli så kjent med Responsibility Process model22 en av de beste modellene for å forklarer hvorfor og hvordan alle mennesker (inkludert oss) er hard-wired for å unngå å ta ansvar.
Last ned plakaten, lær det, heng den i møterommet, vær et eksempel.
SNU ARKET
Retrospektiv Cheat Sheet er to-sidig. Nå bør du ha en ganske god forståelse av forsiden: 16 øvelser gruppert i 5 kategorier.
Men det er en annen side. Se på baksiden av Cheat Sheet - når du føler at ingen øvelse kan få opp gruppens humør, ingen aktivitet kan få dem til å gå videre utover den overfladiske diskusjonen, ingen agenda åpner opp for utdyping av gruppens kompetanse og selvinnsikt…..
Den andre siden av Cheat Sheet er tom.
I STEDET… KJØR EN BEER’O’SPECTIVE!
Jeg har lært dette uttrykket fra David Hussman23. Ifølge David pleier vi å fokusere for mye på hvordan, i stedet for hvorfor24. Retrospektiv Cheat Sheet er definitivt et opphold i hvordan-ting-er. I tillegg er det dessverre ikke så vanskelig å gå seg vill i detaljene og glemme det overordnede målet.
Så isteden for å opprette et kunstig miljø for mennesker til å åpne seg og dele sine tanker, hvorfor ikke få tak i noen bokser øl levert til kontoret og kjøre en beer’o’spective i stedet? Oppriktig talt så trenger du ikke kjøre et møte i det hele tatt , du trenger bare å la det kjøre.
Jeg sier ikke at du ikke skal gjennomføre retros. Neida. Jeg sier, og min erfaring bekrefter, at til tider er en åpen, naturlig, ikke planlagt og ikke-administrert diskusjon i fri flyt akkurat hva et team virkelig trenger. Ikke sikker? Spør teamet - hva foretrekker de denne gangen?
ALTERNATIVT… KJØR EN ÅPEN RETROSPEKTIV
En litt mer organisert måte å kjøre en fri retrospektiv på er å kjøre det i en form av Open Space.
Det er et dusinvis av guider om hvordan du gjennomfører en Open Space ikke-konferanse. Her er trolig den korteste og minste presise:
Steg 1: Forberedelse
- Bestill nok øl.
- Book et rom for 3 timer (eller så) og invitere team medlemmene
- Forberede en tom agenda med 3 tretti minutters intervaller og 3 parallelle sesjoner. Det kan se omtrent slik ut:
Først en felles samling:
14:30-15:00 | Markedsplass |
---|---|
Parallelle sesjoner - de åpne postene på agendaen (de ni øktene) fylles ut av deltakerne under markedsplass aktiviteten.
SOFA “A” | SOFA “B” | SOFA “C” | |
---|---|---|---|
15:00-15:30 | økt #1 | #2 | #3 |
15:30-16:00 | #4 | #5 | #6 |
15:30-16:00 | #4 | #5 | #6 |
Avsluttende felles samling:
16:30-17:30 | Dele innsikt |
---|---|
Steg 2: Fasilitering
- Forklar reglene for open space og hvor den kalde ølen er.
- Åpne opp markedet - la folk pitche sine emner ved å skrive dem på hver sin post-it(som du hadde forberedt på forhånd) og fest dem på agenda plakaten (bestem tid og sted for diskusjoner).
- Sett av noen minutter for å stokke om på agendane for å fikse store konflikter (dot-voting kan være nyttig her).
- Ringe en bjelle og sett igang første økt
5…. Når alle planlagte økter er ferdig, inviter alle til en felles runde for å dele innsikter; mer øl kan være nyttig på dette tidspunktet ;)
Steg 3: Nytte!
BIBLIOGRAFI
Jeg kan bare håpe at arbeidet mitt er en liten dråpe i havet av visdom. Fordi mye har allerede vært sagt og skrevet om dette emnet. Jeg er takknemlig tilhenger av:
SAM KANER’S ARBEID
Denne boken hjalp meg å gjøre et betydelig framskritt i å forstå møtedynamikk.
Mange ideer, rammeverk, modeller og øvelser har gjort meg mye sterkere i utformingen av seminarer, møter, kurs og gruppediskusjoner.
ESTHER DERBY & DIANA LARSENS ARBEID
Denne boken trenger ingen introduksjon, det er den mest kjente boken om temaet agile retrospektiv.
Det fem-trinnvis rammeverket som jeg bruker i Cheat Sheet for grupperingsøvelsene er beskrevet i detalj i boken. Det er definitivt det mest kjente rammeverket for retrospektiv.
Boken beskriver også dusinvis av øvelser.
THE LEANPUB SPACE
På leanpub finnes nå en samling bøker på engelsk om retrospektives (inkludert denne) - se https://leanpub.com/b/agileretrospectives.
Alle velformulerte og godt skrevet, noen av dem gir mer teoretisk bakgrunn på forberedelser, tilrettelegging og oppfølging av retrospektiv. Mens andre fokuserer utelukkende på å hjelpe deg utvide din verktøykasse med nye øvelser og aktiviteter.
Les dem alle.
THE MAGNIFICENT RETROMAT
Leser du ikke noe særlig? Skriv inn følgende webadresse i din nettleser og få en (tilfeldig) retrospektiv agenda:http://plans-for-retrospectives.com/
For en genial ide!
TILBAKEMELDING
Jeg ønsker din tilbakemelding, så skriv til meg:
Web: http://retrospective-cheat-sheet.com
E-post: info@retrospective-cheat-sheet.com
Min andre kontakter: http://www.agiletrainings.eu/trainer/
Notes
1Se Bibliografi på slutten av denne mini-boken.↩
2Se http://www.lego4scrum.com↩
3Matematisk sett er det 288 kombinasjoner. Faktisk mindre- etter som noen øvelser vanligvis er gjort i sekvenser. Men hvem teller? For dere nerder: Hvis du har kommet frem til at antallet ikke er 288 - send meg svaret på en e-post og de første med rett svar vil motta en overraskelse fra den ydmyke forfatteren. Et løfte fra en agile coach.↩
4Se Bibliografi. ↩
5Se for eksempel 7-trinns rammeverket fra ThoughtWorks: https: www.thoughtworks.com/insights/blog/7-step-agenda-effective-retrospective.↩
6Se Bibliografi.↩
7Sjekk gjerne ut mitt blogginnlegg på “Why Your Retrospectives (May) Suck” for mer detaljer: http://www.agiletrainings.eu/2015/11/26/why-your-retrospectives-may-suck/.↩
8Se referansen til Dude’s Law i et senere kapittel av Beer’o’spectives.↩
9Se disse kapitlene senere i boken.↩
10Se disse kapitlene senere i boken.↩
11Du finner nedlastbare bilder i mitt blogginlegg:http: www.agiletrainings.eu/2016/11/05/retrospective-kickstarter-one-word-retrospective/↩
12Sjekk ut http: liveingreatness.com/core-protocols/check-in/ for å se de magiske Core Protocols av McCarthy’s. ↩
13Se bibliografi.↩
14Jeg mener å ha hørt noen variasjoner rundt dette fra min venn Vasco Duarte på hans workshop basert på http: www.scrum-master-toolbox.com/.↩
15Se “Kudo cards”av M3.0 for mer bakgrunnsinformasjon om hvorfor det er viktig å lære å uttrykke takknemlighet: https://management30.com/product/kudo-cards/.↩
16Se http://liveingreatness.com/core-protocols/perfection-game/.↩
17Se Spotify Squad Health Check Mode for en utvidet versjon av denne aktiviteten: https://labs.spotify.com/2014/09/16/squad-health-check-model/.↩
18For mer informasjon om øvelsen: >http://www.innovationgames.com/speed-boat/>. Det er også et intervju med Tobias Mayer som forklarer denne øvelsen.↩
19Se Large Scale Scrum (LeSS) rammeverket for mer om å skalere Scrum. LeSS anbefaler blant annet et felles retrospektiv for alle teamene - the Overall Retrospective: http://less.works/less/framework/overall-retrospective.html.↩
20Det finnes også fancy klistremerke-prikker å få kjøpt i butikken, men jeg bruker ikke disse da jeg ikke vil være avhengig av et verktøy. Dette gjør at folk føler de ikke kan bruke denne teknikken hvis de slipper opp for prikker. Jeg er sikker på at det er derfor slike verktøy er produsert. Det er ikke pent gjort!↩
21Se kapittelet “My Soup”.↩
22David er også kjent i agile community som “Agile Dude”. Han er en Pask Award winning agile coach, produsent og musiker. https://twitter.com/davidhussman. ↩
23David er også kjent i agile community som “Agile Dude”. Han er en Pask Award winning agile coach, produsent og musiker. https://twitter.com/davidhussman. ↩
24Dette er kjent som Dude’s Lov: Verdi = Hvorfor / Hvordan, se: http://devjam.com/2010/08/05/dudeslawgordonpaskshoveler/↩