Retrospective revisited

by Santeri Vesalainen | 08.10.2018 | Kokeilukulttuuri

Meillä oli viime viikolla ”retrospective” erään asiakkuuden puitteissa. Taas opittiin jotain ja mikä tärkeintä saimme aikaan hyvää keskustelua ja jotain parannettavaa.

Todennäköisesti olet ohjelmisto-alalla jos luet tätä, mutta ei hätää jos teet muuta kuin väännät koodia työksesi. Kerron hieman ensin tuosta ”retrospektiivistä”.

Retrospective mikä se on?

Se termissä on kivaa että voit löytää siitä tietoa internetistä eli esim. duckduckgo.com-palvelulla hakusanalla ”Retrospective” toisin kuin vaikka vähemmän tunnetulla ”naulausmetodi”-haulla, eli päädyt melko todennäköisesti wikipedia-artikkeliin.

Oma kokemukseni on että retrospective

• on toistuva tapahtuma ja tila
• jossa luodaan tiimille mahdollisuus katsoa taaksepäin (ja ehkä vähän eteenpäinkin)
• se liittyy usein projektinhallinnan viitekehykseen (Scrum) pyrähdyksen eli sprintin loppuun nimellä Sprint Retrospective

Omia huonoja kokemuksiani on että retrospective saattaa myös muodostua joksikin näistä, varsinkin jos toistuva tarkoittaa kerran tai harvemmin vuodessa

• ”Vomit-sessio”
• ”Dumppaus”
• ”Kiukkupussien kokous”

Omat havainnot yli 10 vuoden ajalta scrum:n Sprint Retrospectiveissä on ollut ainoastaan tiimiläisiä, ehkä muutaman kerran myös product owner (toki vain ”kanan”-roolissa, ei ”sian”-roolissa kuten tiimiläinen)

Hubble ja Retrospective – Build

Pidämme Hubblella työkalu-ajattelusta, kuten esim. n. viikko sitten pidetyssä II TiedeAreenan Tekoäly-paneelikeskustelussa, jossa kerrottiin tekoälyn palvelevan vielä pitkälti työkalun asteella. Siksi meillä onkin Aivan Tavallinen Tekoäly(tm)-palvelu. Samoin suhtaudumme Scrum-viitekehykseen, eli emme siis dogmaattisesti vaan olemme poimineet Retrospective-käytänteen työkaluksi sieltä – joka asiakkuuteen sekä myös omaan sisäiseen käyttöön.

Poikkeuksellista tällä kertaa oli tuon kokoonpanon rikkominen. Tiimin lisäksi paikalle oli kutsuttu kyseisen asiakkuuden avain-henkilöt ja aikaa varattu 1,5 h (reilusti yli oman keskivertotarpeemme), koska halusimme

• kokeilla erilaista retrospectiveä
• lisätä työn läpinäkyvyyttä

Koska käytänne eli Retrospective ei ollut asiakkaan avain-henkilöille tuttu niin kävimme työskentelytapamme taustaa ja aiempaa Retrospectiveä sekä sen aiempia tuloksia, niin lyhyesti kuin kykenin – vain n. 20 min 🙂  – läpi. Tilaisuus aloitettiin kertomalla ’säännöt’:

• Aikaisemman retrospectiven actionpointtien todennus (2 min)
• 10 min yhteensä – hiljaista – aikaa molemmille ”Mikä meni kivasti”- ja ”Mikä voisi mennä paremmin”-kysymyksille kirjoittaen yhdelle lapulle yksi havainto
• Jokainen lukisi lappunsa ääneen vuorollaan (kahdella kierroksella) samalle ne kirjattiin ylös talteen myöhempää seurantaa varten
• Lopuksi muodostetaan tehtävä actionpoint tai kaksi (sillä on parempi tehdä vaikka yksi kuin jättää monta tekemättä)
• Havaintoja koskevaa aikaa ei rajattu esim. viime Retrospectiveen joka oli ollut juuri ennen kesälomia

Näistä ’säännöistä’ on mainittava että tämä on vain yksi variaatio mitä olemme käyttäneet itse, kuitenkin päätimme käyttää tätä pohjaa koska olimme käyttäneet sitä aiemminkin. Suosittelen tutusmaan ja kokeilemaan eri templateja esim. hakusanalla ”Retrospective templates” löytyy lisää hyviä kokeiluideoita. Ja niin jos vielä ei tullut selväksi niin asiakaskin osallitui tähän kirjaamalla omasta näkökulmastaan havaintoja kuten tiimiläiset.

Measure & Learn

Kun 1. kysymyksen (”Mikä meni kivasti”) kohdalla kello alkoi tikittämään ja asiakas oli samassa tilassa, oli itselle selvää että retrospectivestä tulisi erilainen. Jokainen hubblelainen oli tottunut käyttämään melko teknistäkin kieltä lapuissa ja nyt se ei tuntunut täysin sopivalta. Kun aloimme käymään läpi vuorollamme lappuja läpi niin huomasimme seuraavaa:

• Aikaa oli hyvä varata tarpeeksi vapaalle keskustelulle
• Saatiin nopeaa palautetta Retrospectiven aikana keskustelussa esille tulleisiin havaintoihin ja näkökulmiin
• Opittiin asiakkaan ajattelutavasta huomattavasti lisää
• Opittiin miten oltaisiin voitu toimia jossain tapauksissa eri tavalla
• Opittiin erityisesti miten tärkeää on nopea palaute-sykli ja tässä eri kommunikointi-työkalujen hyödyntäminen, mukaanlukien paikanpäällä käynti

Tavoitteiden osalta:

• Totisesti onnistuimme saamaan erilaisen Retrospectiven ja huomasimme että tarvitsemme edelleen ’täysin omaa’ Retrospectiveä
  • Nyt 14 erilaista parannettavaa havaintoja kirjattiin joista 1 oli täysin tekninen havainto. Viimeksi 10 erilaista paranetttavaa havaintoja kirjattiin joista ei yhtään teknistä havaintoa
    • Eli aiheen teknisyys ei merkittävästi tuonut erilaisuutta
  • Sen sijaan merkittävä ero havainnoissa liittyi uudenlaisiin näkökulmiin, asiakkaan näkökulmiin osittain samoista asioista, joita oltiin aiemminkin havaittu tarpeellisiksi kehittää
  • Eli saavutettu erilaisuus tarkoitti havaintojen monipuolisuutta Retrospectiveen
• Asiakas sanoi tilaisuuden lopussa läpinäkyyvyden lisääntyneen ja sitä toivottiin lopulta vielä lisää
• Läpinäkyvyyden lisäys kommunikointiin valikoituikin ratkaistavaksi kehityskohteeksi, erityisesti hyödyntämällä lisää monipuolisia kanavia eli työkaluja.

Ja lopuksi:

• Se että Retrospectiveen osallistuneet toimivat introspektiivisesti, mitä tapahtui tässäkin tapahtumassa eli asiakas ja tiimiläinen jakaa jostain arkisesta riemukkaan onnistumisen tai toistuvasta epäonnistumisen kokemuksestaan, lisää Retrospectiven arvoa aivan toiselle tasolle
• Vinkkinä, Ei tarvitse lähteä asiakkaan kanssa Leville ’bondaamaan’ jotta saadaan rakennettua luottamusta ja tulevaa, riittää kun kaikilla on vähän epämukavaa ja turvallista