Ovatko ihmiset jotka vihaavat retroja vain kiukuttelevia kakaroita?
– Onko pakko osallistua lappuleikkiin?
– Oon tehny tällä viikolla lähinnä omaa osuuttani itsenäisesti, mun ei varmaan tartte osallistua retroon?
– Blääh, retro on tänään.
Kuulostaako tutulta? Monesta tiimistä löytyy jäseniä, joita retrot ahdistavat tai jopa pistävät vihaksi.
Ongelmana ihmiset?
Olisi helppo luokitella nämä ihmiset konservatiivisiksi jääriksi. Mitä jos sen sijaan myöntäisimme, että kyse on toistuvasta kuviosta, jolle on syytä tehdä jotain?
Miksi tiimit vihaavat retroja
Kyselin tätä Twitterissä. Seuraavassa kooste vastauksista:
- retrojen fasilitointi on kehnoa,
- sovittuja action pointteja ei toteuteta ja
- mikään ei muutu.
Tämä herättää kysymyksen: miksi näin on?
Retro on irrallinen käsite
Minusta me ketterät ihmiset olemme tähän syyllisiä. Keksimme tiimin jatkuvan kehityksen tukemiseen yhden ainokaisen tapahtuman, retrot. Me annoimme sille muodon, joka on geneerinen ja irrallaan muusta tekemisestä.
Viestimme, että ainoa tapa tulla paremmaksi retrojen fasilitoijaksi on ketterät koulutukset ja valmennukset. Onhan retro asia jota ei juuri tunneta ketteryyden ulkopuolella.
Samalla olemme antaneet tiimeille kuvan, että retro on jotain jota tehdään ketteryyden kehittämiseksi. Jos pidämme retroja, olemme ketteriä, ja se on tärkeää.
Kaikki tämä on johtanut siihen, etteivät retrot nivoudu useimpien tiimien päämääriin tai työhön. On vaikea ymmärtää, miksi niitä tehdään tai miten niistä saisi enemmän irti.
Mikä eteen?
Tiimit eivät tarvitse retroja.
Sen sijaan tiimit tarvitsevat toimintatapojensa jatkuvaa tarkastelua ja mukauttamista, jotta ne voisivat menestyä kompleksisessa ympäristössään.
Tämän tarpeen ymmärtäminen vaatii sitä, että ymmärtää
- että ohjelmistojen kehittäminen on kompleksista ja
- mitä kompleksisuus tosiasiassa on.
Jos tiimissä ei ole tälläistä ymmärrystä, on luonnollista että retrot turhauttavat. Mitä syytä on yrittää kehittyä jatkuvasti, jos oma uskomus on, että alan hyväksi koetuilla parhailla käytännöillä pärjää parhaiten?
Retrot siis toimivat, jos ne ovat osa tiimin yhteistä jatkuvan kehittymisen työtä. Mutta jos tiimissä ei ole sisäistetty tätä tarvetta, retrot voivat tuntua vain ketterän softakehityksen pakolliselta rastilta, josta ei ole ihmeemmin hyötyä.
Mitä jos tiimi ei ole valmis?
Tässä tapauksessa on hyvä jättää puheet retroista ja ketteryydestä taka-alalle ja keskittyä johonkin konkreettisempaan.
Voitte tiimissänne käyttää aikaa sen miettimiseen, mitkä ovat isoimmat haasteenne päämäärienne saavuttamisessa.
Jos haasteet liittyvät teknisiin ongelmiin, kokoontukaa säännöllisesti miettimään, mitä voisitte kokeilla ongelmanratkaisutaitojenne kehittämiseksi.
Jos haasteet liittyvät liiketoimintaan, ideoikaa säännöllisesti kokeiluja liiketoiminnan kehittymiseksi.
Ja niin eteenpäin. Sitokaa kehittämistoimenne päämääriinne ja tehkää niistä konkreettisempia kokeiluilla.
Jokaisella osa-alueella löytyy suuri määrä olemassa olevaa osaamista, jota voitte tässä työssä hyödyntää.
Ja samalla kokeilut saattavat paljastaa tiimille ohjelmistokehityksen kompleksisen luonteen sillä, että parhaat käytännöt eivät aina takaakaan toivottua tulosta.
Jos aihe kiinnostaa ja haluat kuulla siitä lisää, suosittelen katsomaan ystäväni Gitte Klitgaardin puhetta aiheesta Øredev 2014 -konferenssissa (43 min., englanniksi).
Antti Kirjavainen on kokenut valmentaja. Hän auttaa yrityksiä kehittymään liiketoimintalähtöisiksi, asiakkaita ymmärtäviksi ja jatkuvasti toimintaansa kehittäviksi.
Antin tehtävänä on auttaa uusia yrityksiä omaksumaan näitä uusia työn organisoimisen ajatusmalleja ja käytäntöjä ja näin viedä vaikutuksensa aivan uudelle tasolle.
- Kirjoittaja
- @anttiki
- Haastattelu