Oppiminen ohjelmistoprojektissa on joukkuelaji

Yksi ketterän ohjelmistokehityksen tärkeimmistä, mutta usein myös laiminlyödyimmistä, periaatteista on jatkuva parantaminen. Sovelluskehityksen ja tuotteen hiomisen lisäksi myös toimintatavat täytyy pitää jatkuvasti kriittisen tarkastelun kohteena. Projektin alussa sovitut käytänteet eivät välttämättä palvele enää ollenkaan julkaisun lähestyessä. Voi tulla erittäin kalliiksi, jos tähän ei kiinnitetä huomiota ja herätä muuttamaan sitä, miten työtä tehdään projektin eri vaiheissa.

Toimintatavat ovat kuitenkin asioita, jotka eivät työn tekemisen kiireessä muuta itse itseään, eikä niitä oikein tule projektityön tuoksinassa kyseenalaistettuakaan - ainakaan riittävissä määrin. Ketterän kehityksen menetelmät tarjoavat tähän ongelmaan työkalun: retrospektiivit.

Retrospektiivi sanana tarkoittaa taaksepäin katsomista ja juuri siitä tässä on kyse. Katsotaan taaksepäin sekä pyritään oppimaan ja muokkaamaan toimintatapoja opitun perusteella.

Vincitillä retrospektiivejä on järjestetty säännöllisesti projekteissa yrityksen ensimmäisistä vuosista lähtien. Mutta se miten retroja pidetään on muuttunut ajan kuluessa paljonkin. Huomaa myös, että retrospektiivi ei ole pelkästään ohjelmistosuunnittelussa toimiva menetelmä. Vincitillä retroja on sovellettu projektien lisäksi myynnin-, ohjausryhmän- ja design-tiimin työtapojen kehittämiseen.

Retrojen historia Vincitillä

Ensimmäiset retrospektiivit järjestettiin Vincitillä projektien loputtua. Projektista yritettiin kaivaa esiin tietoja, jotka olisivat yleistettävissä koko yrityksen toimintaan, ettei toistettaisi samoja virheitä muissa projekteissa. Osallistujina olivat kaikki projektissa jollain tavalla mukana olleet vincitläiset. Tällä tavoin saatiin kyllä kaivettua ihan hyviäkin oppeja, mutta niiden vieminen projektien käytänteisiin jäi monesti puutteelliseksi. Suurimmat syyt tähän olivat konkreettisten toimenpiteiden sopimisen puuttuminen retrospektiivin lopusta ja se, että eri projektit ovat usein hyvin erilaisia ja opit eivät välttämättä suoraan päde muissa projekteissa.

Ensimmäinen oivallus retrospektiiveistä olikin, että miksi ihmeessä niitä pidetään ainoastaan projektin loputtua, jolloin saaduilla opeilla ei enää voi kyseiseen projektiin vaikuttaa. Niinpä aloimme pitämään retroja projekteissa säännöllisesti. Tämä auttoi, ja samalla monia muuten taustalla nakertavia ongelmia saatiin ratkottua projekteissa tarkastamalla ja muuttamalla käytänteitä projektin aikana.

Usein kuitenkin retroissa nousi esiin sana asiakas. "Meillä on ongelma, koska asiakas toimii tilanteessa X tavalla Y". Tällaisissa tilanteissa nakitettiin tyypillisesti projektin vetäjä keskustelemaan ongelmasta asiakkaan kanssa. Joskus tällä tavoin saatiin muutosta aikaan, joskus ei. Ongelma siirtyi asiakkaalle tällä tavoin niin monen välikäden kautta, että asiakas ei välttämättä ymmärtänyt ongelmaa tai pitänyt aihetta ongelmana ollenkaan. Tai ainakaan yhteisenä ongelmana.

Tästä seurasi toinen oivallus. Asiakas mukaan retroihin, tietenkin! Tällä tavalla tarjotaan projektitiimille ja asiakkaalle yhteinen tilaisuus oppia ja parantaa tekemistä siten, että kaikki ihmiset, jotka asioihin projektissa vaikuttavat, ovat paikalla. Tällä tavoin muutokset saadaan sovittua koko porukalla siten, että kaikki sitoutuvat niihin.

Vinkkejä retron pitämiseen

Paras hyöty retroista saadaan, kun niitä pidetään säännöllisesti. Iteraation pituus on hyvä lähtökohta, mutta meillä on yleensä pyritty mahduttamaan pari iteraatiota retrojen väliin. Eli noin kerran kuukaudessa -rytmillä pärjätään jo oikein hyvin. Harvemminkin toimii, mutta on hyvä pitää mielessä se nyrkkisääntö, että mitä pidempää ajanjaksoa tarkastellaan, sitä enemmän aikaa myös retrospektiiviin täytyy käyttää. Jos käsiteltävä ajanjakso on venähtänyt useamman kuukauden mittaiseksi, ei koko päivän kestävä retrospektiivi ole mitenkään ylimitoitettu.

Kun retrospektiivi on saatu mahdutettua kalentereihin, niin mitä siellä sitten kannattaisi tehdä? Tyypillisesti retrospektiivi jakautuu seuraaviin vaiheisiin:

  1. Alustus: Alustuksessa retron vetäjä käy lyhyesti läpi, mistä retrospektiiveissä on kyse, jos paikalla on ihmisiä, joille se on uusi asia. Lisäksi on hyvä teettää jokin lyhyt lämmittelytehtävä, jossa kaikki osallistujat pääsevät lyhyesti ääneen.
  2. Tiedon keräys: Tässä vaiheessa kerätään tietoa tapahtumista, faktoista ja tunnelmista retrospektiivin tarkastelun kohteena olevalta ajanjaksolta. Kerätyn tiedon määrä kannattaa suhteuttaa käytössä olevaan aikaan, jotta tiedon pohjalta ehditään myös tekemään päätöksiä.
  3. Oivallusten luominen: Tarkoitus on analysoida edellisessä vaiheessa kerättyä tietoa muokkaamalla ja ryhmittelemällä sitä eri muotoon. Myös alustava ideointi on hyvä käynnistää tässä vaiheessa.
  4. Päätösten tekeminen: Tärkeimpänä vaiheena retrospektiivissä tehdään päätöksiä, jotta edellisistä vaiheista kerätyt oivallukset ja tiedot eivät menisi hukkaan.
  5. Yhteenveto ja palaute: Retrospektiivin vetäjä kiteyttää retrospektiivissä päätetyt asiat ja kerää osallistujilta palautteen.

Hyviä retroja oppii pitämään helpoiten osallistumalla sellaisiin ja tietysti harjoittelemalla niiden pitämistä. Me olemme oppineet retroista seuraavia periaatteita:

  • Älä pidä retroa omalle projektillesi. Hanki joku toinen projektin ulkopuolelta fasilitoimaan.
    • Retrospektiivin fasilitointi sulkee yleensä pois siihen osallistumisen - tai ainakin tekee siitä vaikeaa. Joko tulee ohjailleeksi liikaa sitä, millaisia päätöksiä retrosta nousee, jolloin tiimin näkemys ei tule esille niin hyvin kuin se voisi tulla. Tai sitten keskittyy pelkkään fasilitointiin ja ei saa omaa näkemystään esiin ollenkaan.
  • Älä suunnittele retroa yksin. Sparraile ajatuksiasi projektitiimin tai ainakin jonkun tiimin jäsenen kanssa. Hanki etukäteen sopivasti tietoa projektin tilanteesta.
  • Huolehdi käytännön järjestelyistä käytettävän menetelmän mukaan.
    • Huolehdi, että huone on tarpeeksi iso, jotta ihmiset pääsevät liikkumaan.
    • Varmista, että huoneessa on riittävä suuri valkotaulu.
    • Varmista, että sinulla on tarpeeksi post-it-lappuja, kyniä ja muita tarvittavia välineitä.
  • Retrospektiivin tuloksena täytyy syntyä konkreettisia muutoksia. Vältä passiivia, vastuuta oikeat henkilöt, sovi määräaika ja ajankohta, jolloin asiaan palataan. SMART Goals tarjoaa hyvän esimerkin siitä, millaisia tuotoksia retrospektiivistä kannattaa kerätä.
  • Kehittyäksesi retrospektiivin vetäjänä kerää lopuksi palaute. Missä onnistuin? Mitä olisi hyvä muuttaa? Onko jotain muuta palautetta?
  • Varaa tarpeeksi aikaa ja huolehdi aikataulutuksesta.
    • Suunnittele retrospektiivin eri vaiheet aikatauluineen ja pidä niistä kiinni. Muuten käy helposti niin, että tärkein vaihe eli toimenpiteistä sopiminen, jää tekemättä.

Jos retrokärpänen puraisi, niin hyviä menetelmiä retrospektiivin pitämiseen tarjoaa esimerkiksi Agile Retrospectives -kirja.

Juha Riippi

Juha Riippi

Liity keskusteluun