Retrospective revisited

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

 

Playing Lean

Playing Lean

Ei nyt sentään kohellusta

Järjestimme halukkaille mahdollisuuden imeä Lean Startup-oppeja rennossa ”Koodausta ja kohellusta” iltatilaisuudessamme. Tällä kertaa ei oltu lavean viitekehyksemme koodauspäässä, mutta ei sentään pelkkää kohellustakaan ollut tarjolla.
Playing Lean peli toimii parhaiten alle 10 hengen ryhmällä ja saimme kasaan pienen mutta sitäkin monipuolisemman porukan. Rentoa iltaa tuli viettämään Hubblelaisten lisäksi pari toimitusjohtajaa, projektitutkija ja senioritason koodari. Allekirjoittanut sai toimia tilaisuuden sertifioituna Game Masterina.

Pelaamista ja vähän oppimista

Illan pääpaino laitettiin ajan puutteessa pelaamiselle ja tiettyjä pelin esiin tuomia oppeja Lean Startup ”metodologiasta” käytiin aika pikaisesti läpi ennen pelin aloitusta ja pelin aikana. Tarkoitus oli herättää mielenkiinto ja mahdollistaa pelin myötä oppiminen. Pöydällä olleet voittopokaalit tietysti haittasivat hieman keskittymistä, mutta pelin moninaiset säännöt saatiin kuitenkin käytyä hyvin läpi.

Peli sai näin työpäivän jälkeenkin kaikkien tarkkaavaisuuden vireille. Olikohan kyseisen päivän aikana kukaan keskittynyt yhtä tarkkaan pohtimaan mitä kannattaa kehittää, koska myydä ja kuinka paljon tehdä kokeiluja todellisten asiakastarpeiden selvittämiseksi.

Retro

Pelin jälkeisessä retrossa esiin tuli odotettu asia. Vielä enemmän oppimista olisi saatavissa, jos aikaa olisi enemmän ja esimerkiksi pelin aikana tehdyistä kokeiluista voitaisiin keskustella tarkemmin. Tämän tyyppinen tilaisuus toimisi esimerkiksi reilun aamupäivän mittaisena hienosti.
Peliä analysoitaessa voittavaksi tekijäksi muodostui strategia, joka ei painottanut erityisen vahvaa teknologista kehitystä, vaan asiakastarpeiden systemaattista selvittämistä ja tarpeeseen tehtyä tuotekehitystä. No, koska pelistä on kysymys, tuurillakin oli ehkä joku osuus.

Jälkipuheita, totta kai

Kovat panokset synnyttävävät aina kovat jälkipuheet. Pelin päätyttyä himoitut pokaalit saivat aikaan syytöksiä Game Masteria kohtaan. Pelissä oli kuulemma vuorot seonnut jossain kohtaa. Kuvitteellisen videotarkistuksen jälkeen tulokset pysyivät ennallaan.

Oli kiva ilta! Onnittelut voittajille ja kiitos osallistujille!

P.S. Lue Jukan tuuletuksista Linkedinissä

Koodausta ja kohellusta – node.js

Koodausta ja kohellusta – node.js

Hubble järjesti toista kertaa ”koodausta ja kohellusta”-tapahtuman, 24.4. klo 18-22 Tällä kertaa aiheena oli node.js . Edellisestä kerrasta ja sen palautteesta voit lukea täältä .

Kuten luova johtajammekin sanoo radiohaastattelussa että, Hubble haluaa olla rohkeasti edistämässä kokeilukulttuuria, ja me ymmärrämme että sen tärkeä – ehkä jopa tärkein – osa on nopea palaute. Viime kerran tapahtuman palautteesta opeimme ainakin että

  • arki-ilta on hyvä ajankohta
  • osallistamista voisi olla enemmän, edellinen tapahtuma oli koulutus-tyyppinen
  • syötävää oli hyvä olla tarjolla

Build

Tapahtuman sisältö ja ajankohta päätettiin kuukautta ennen itse tapahtumaa. Päätöksen jälkeen laitettiin ennakko-tieto sähköpostilistalla oleville henkilöille. Muutaman päivän päästä tämän ennakkotiedon jälkeen alkoikin lähteä tapahtumatiedoitteita henkilökohtaisiin eri kanaviin

Sisältö nivoutui hyvin pitkälti kokemuksiemme jakamiseen node.js tiimoilta.

Tapahtumaan osallistujia ilmoittautui melko hitaasti, mikä alkoi hieman mietityttämään, oliko tiedottaminen onnistunut. Tapahtuma herätti innostunutta kannustusta mm. Tampere Hacking Great meetuppien järjestäjien taholta. Lue lisää vierailusta täältä

Tapahtuma haluttiin nyt myös osallistavan ihmisiä keskusteluun ja siksi tarjoilun puolesta päätimme kokeilla tavanomaisten taukotila-virvokkeiden lisäksi muutamaa olutta.

Satky halusi toimia sponsorina tapahtumaan tarjoamalla cola-juomat ja subway-tarjottimen, hyväksi todetun meatlovers-vaihtoehdon. Vastineeksi tapahtuman alussa kerroin lyhyesti Satakunnan Tietojenkäsittely yhdistyksestä ja mm. hacklabista.

Kaikki ilmoittautuneet pääsivät osallistumaan. Itse tapahtuma lähti käyntiin leppoisasti jutustellen. Seuraavaksi kerrottiin Hubblesta ja juuri käynnistyneestä Business Finland-hankkeesta ”Brand Based Programming”:sta.

Measure

Heti alkuun tuntui hyvältä idealta näyttää keskustelu-aiheet samalla kun esittäydyttiin, jotta voitiin varmistaa että ainakin erityisen kiinnostavista aiheista keskusteltaisiin. Tästä nopeasta palautteesta kävi oitis muutama asia osallistuneiden osalta selväksi

  • node.js tuotannossa ja erityisesti backend-puolella oli vieras
  • frontend eli käyttöliittymä-puolella sen sijaan node.js-työkalut olivat erittäinkin tuttuja
  • JWT eli jsonwebtoken on kiinnostava
  • osallistujat olivat opiskelevia tai työssäkäyviä koodaajia

Meidän hubblelaisten kokemusten ja tarinoiden kerronta eri aiheissa ja niiden välillä oli poukkoilevaa. Kuitenkin tästä saattoi huokua että hubblelaiset kertovat ihan todellisia kokemuksia, eikä koreografioitua näytelmää, josta eräs osallistuja mainitsi. Me tulkitsemmekin tämän erittäin hyvänä palautteena, porilaiseen tyyliin. Kysymyksiä tulikin ja niihin löytyi vastauksia, joskus useampikin. Keskustelua syntyi.

Learn (palaute)

Ennen tapahtumaa oli tullut selväksi että seuraavalla kerralla some-kanavissa mainostamista halutaan kokeilla tapahtuman tiedottamisen tueksi, koska hämmästyttävän moni tuttava ei ollut huomannut viestejä.

Heti tapahtuman jälkeen ehdittiin kuulla muutama suora palaute:

  • Hienoa että Porissa järjestetään tälläisia tilaisuuksia
  • tarjoiluun viitaten ”pizza and beer” voisi olla kiva

Sen lisäksi teimme lyhyen muutaman kysymyksen google forms kyselyn ja lähetimme sen osallistujille. Vastauksia tuli 4 kpl. Kysely lähti  6 osallistujalle, eli poislukien hubblelaiset. Tässä yhteenvetoa kyselyn tuloksista

  • vastaajista 100% haluaa jatkossakin lisää node.js tilaisuuksia
  • vastaajista 75 % sai tietoa tapahtumasta kaverilta eikä esim. somesta
  • vastaajista 100 % haluaa osallistua muihinkin kuin ”koodaus”-aiheisiin tapahtumiin
  • tapahtuman hyödyllisyys sai asteikolla (1=hyödytön,4=erittäin hyödyllinen) keskiarvoksi 3,75
  • vastaajat toivoivat tapahtumien ajankohdaksi joko arki-iltaa tai viikonloppupäivää (75%)
  • vapaamuotoisia vastauksia tilaisuudesta tuli seuraavia kuten
    • ”Hyvää ”real world” keskustelua, porukka oli hyvin meiningissä mukana”
    • ”Oluesta plussaa. Tekniikan lisäksi vois jutella koodamisen arvoista, tavoista, tiimityöstä yms. pehmeistä asioista.”
    • ”isompi / ”vapaampi” tila ois pop, tyyliin sohvia tms. Neukkaripöytä inan jähmeä =/”
    • ”Asiantunteva, rento ja erittäin positiivinen tunnelma, vaikka asiantunteva ja rento on usein vaikea yhdistää.”
    • ”Mukavaa jutustelua”
    • ”Siistii saada tällasta settii Porii, tulee ihan mieleen Helsingin new school -softatalojen meininki”
    • ”Kiitokset hubblen porukalle hyvästä tapahtumasta, jonka mahtavuutta ja tarpeellisuutta ei edes ymmärtänyt ennen kuin oli ollut tapahtumassa. Toivottavasti saadaan lisää vastaavia erilaisista alaan liittyvistä aiheista ja muitakin innostumaan järjestämään vastaavia.”

Kuvia tapahtumasta

Sequelize stacktrace

Sequelize stacktracen ihmettelyä

Esittäytyminen

Esittäytyminen

Jutustelua

Jutustelua

Linkit

Ideat, kokeilu ja validoitu oppiminen

Ideat, kokeilu ja validoitu oppiminen

Senkus räpläätte

Valtakunnallisen kokeiluviikon innoittamana päätin kirjoittaa hiukan kokeiluista ja validoidusta oppimisesta. Kokeilukulttuuria syydetään lähes joka tuutista, enemmän tai vähemmän edellytyksenä menestykselle. No sitähän me Hubblessakin toitotetaan. Mielestäni usein kuitenkin unohdetaan validoitu oppiminen, ja sitä pitäisi korostaa enemmän kuin vain kokeiluja. Validoidun oppimisen pitäisi olla yksi tärkeä peruste kokeilujen tekemiselle. Kun puhutaan vain kokeilemisesta, tulee helposti mieleen hallitsematon räpläily minkä tahansa asian ympärillä. Toisaalta kokeiluihin mahdollistava johdon kommentti ”senkus räpläätte” voi olla se ainoa tarvittu palanen suurten innovaatioiden syntymiseen. Historia sen kertoo, että paljonhan niitä vahingossa on syntynytkin.

Pyrstö edellä puuhuun

Yksi kokeiluajatusten lähde ja itseänikin asian tiimoilta innoittanut kirja on Eric Riesin Lean startup. Ericin kuvaama malli on sangen yksinkertainen ja siksi pidän siitä. Sitä on helppo soveltaa lähes mihin tahansa toimialaan, kunhan ajattelee luovasti eikä asettele itse keinotekoisia rajoituksia. Build – Measure – Learn mallia käytetään paljon ja joskus haastan itseänikin ajattelemaan tuota mallia takaperoisesti. Eli pyritään ensin miettimään mitä halutaan oppia, miten se oppiminen saadaan validoitua ja sen jälkeen tehdään MVW (Minimum Viable Whatever).

Naama edellä

Normaali tapa on edetä toteuttamalla iteraatio rakentamalla ensin MVW, mittaamalla onnistumista ja keräämällä opit. Vaikka asiaa ajattelisi näin, haastan silti miettimään asiaa myös takaperoisesti. Kun päästään kiinni ajatukseen mitä halutaan oppia, on huomattavasti helpompi löytää sopivia ”määreitä” onnistumisen mittaamiseen.

Ja ensin se idea

Lean startup mallia voi käyttää, kun ensin on se idea. Digitaalisen tilannekuvan työpajoissa olen havainnut, että kyllä niitä ideoita löytyy, kunhan on hyviä tapoja saada niitä esiin. Erilaiset Game storming mallit ovat hyviä. Peleissä päästään eroon erilaisista ideointia haittaavista ongelmista, kuten esimerkiksi itsekritiikistä, desibeli ideoinnista (kovaäänisimmän idea on paras) tai HIPPO priorisoinnista (highest paid person’s opinion). Idean perusteella muodostetaan hypoteesi, jota lähdetään validoimaan kokeilumallilla.

Byrokratiaa peliin, not

Koska kokeiluissa halutaan olla nopeita ja ketteriä voi dokumentointi ja kokeilumalli jäädä pohtimatta. Kun palataan validoituun oppimiseen, on hyvä päästä asiaan uudestaan kiinni myöhemminkin. Ajatellen esimerkiksi tilannetta, jossa uusi työntekijä tulee taloon ja yrityksessä on hiljalleen saatu kokeilukulttuuria edistettyä. Kevyt dokumentaatio tehdyistä kokeiluista, validointitavoista ja oppimisesta on erittäin arvokasta tietoa uudelle kaverille. Pääsee heti kiinni ajatukseen, kuinka omia ideoita voisi kokeilla. Tai kun ajan saatossa jokin aikaisemmin kokeiltu hypoteesi nousee uudestaan pintaa, voidaan asiaa ensin lähestyä ajatuksella ”kuinka maailma hypoteesin ympärillä on muuttunut”. Kevyellä ja avoimella dokumentaatiolla on paikkansa. Ei hommaa tietenkään tule kuormittaa liian byrokraattisella rakenteella, mutta jokin kevyt toistuva tapa kokeilujen käsittelyyn tulisi olla. Tuo tapa tietysti kehittyy jatkuvasti. Liika byrokratia tunnetusti hoitaa koko homman niin, ettei validoitavia ideoita ja hypoteeseja ole eikä tule.

Fail fast, fail cheap

Kannustan teemaviikon mukaisesti kokeilemaan. Mielenkiintoa saa lisää, kun miettii miten asian saa kokeilemalla validoitua nopeasti ja halvalla.

Jani