Hae it-yrityksiä
osaamisalueittain:

Asiakkuudenhallinta CRM BI ja raportointi HR Tuotekehitys ja suunnittelu Toiminnanohjaus ERP Taloushallinto Markkinointi Webkehitys Mobiilikehitys Käyttöliittymäsuunnittelu Tietoturva Verkkokaupparatkaisut Ohjelmistokehitys Integraatiot Pilvipalvelut / SaaS Tekoäly (AI) ja koneoppiminen Lisätty todellisuus ja VR Paikkatieto GIS IoT Microsoft SAP IBM Salesforce Amazon Web Services Javascript React PHP WordPress Drupal
Contribyte » Bloggaus

Scrumin seremoniat: kuusi pointtia hyvään retrospektiiviin

Bloggaus

Onpas mahtavaa päästä taas suosikkiaiheeni ääreen! Yksi entinen kollega antoi minulle jo lisänimen “Retromies”. Retrospektiivien kehittäminen vaan sattuu olemaan minun yksi suosikkiaiheeni. On kivaa, kun pääsen auttamaan tiimejä ja organisaatioita parantamaan heidän retrokäytäntöjä, ja sitä kautta oppimista. Valmentajaurallani olen auttanut jo kymmeniä tiimejä parantamaan retroja. Paras fiilis tällaiselle kouluttaja-valmentajalle on se kun huomaa, että auttamani tiimi on päässyt itseoppimisen ja jatkuvan parantamisen kierteeseen. Aivan olennainen osa tätä kierrettä ovat hyvin toimivat retrospektiivit.


Ne, joille retrospektiivi ei ole tuttu termi, nopea selitys: kyse on Scrumin seremoniasta, jossa tiimi säännöllisesti kokoontuu miettimään, mikä viime ajanjaksolla meni hyvin, mikä meni huonosti ja mitä voitaisiin tehdä paremmin. Näin retron määrittelee oppikirjat, ja juuri tässä onkin suuri sudenkuoppa. Aivan liian moni tiimi pitää retrospektiivejä nimenomaan näin – keskustellen siitä mikä oli hyvää ja mikä huonoa, ilman mitään formaattia ja keinoa. Tämä alkaa maistua sahanpurulta aika nopeasti.


Onneks hätä ei ole tämän näköinen! Jos retrot maistuu puulta, ei muuta kuin haaste vastaan! Retrokäytäntöjen kehittäminen virkeämmiksi ja mukavammiksi on tosi helppoa. Netti on pullollaan ideoita, ja jos ei halua itse käyttää aikaa parhaiden retroideoiden oppimiseen, meiltä Contribyteltä saa apua tarvittaessa nopeasti ja helposti. Tässä blogissa haluan nostaa esiin kuusi pääpointtia perushyvään retrospektiveen. Muita blogejani samasta aiheesta kasasin tälle sivulle, samoin kuin muutaman muun kivan mielenkiintoisen linkin aiheesta.

Eli nyt asiaan: kuusi asiaa hyvään retrospektiiviin!


Pidä retroja! Epäsäännöllinen retro vie nopeasti teho-osastolle!


Duh, lukija ajattelee. Mutta se vaan on niin totta. Aika moni ketterä tiimi on lopettanut tai “unohtanut” retrot, koska koki niiden pitämisen turhaksi ja ajanhukaksi. Näissä tilanteissa kysyn usein: “miksi?”. Miksi ne olivat turhia? Usein vastaus tähän on, että “niissä aina keskusteltiin samoista ongelmista, eikä mikään koskaan muuttunut.”


On ymmärrettävää, että tiimi kokee retrospektiivin turhauttavaksi, jos ei pystytä muuttumaan. Mutta retrojen lopettaminen on väärä päätös – niitä pitää ehdottomasti jatkaa. Retrot ovat jatkuvan parantamisen sydämenlyönnit. Retrojen keskeyttäminen vie tiimin nopeasti teho-osastolle, eikä apuun tule George Clooney! (Saattaa tosin olla, että apuun tulee lähes yhtä komea Contribyten valmentaja!)


Muutos vaatii toimenpiteitä, ja toimenpiteistä pitää tehdä sellaisia, että ne myös tapahtuvat – tästä lisää listan kohdissa neljä ja viisi. Mutta retrojen säännöllisyys on ensiarvoisen tärkeää. Säännölliset retrot toimivat tiimin paineentasausventtiilinä ja kanavana kertoa hankalista asioista. Jos säännöllisyys puuttuu, asiat jäävät vaivaamaan ja haittaamaan tiimin ilmapiiriä.


Hyvä frekvenssi retrojen pitämiseen on 2–4 viikkoa. Väli retrojen välissä ei saisi mieluusti kasvaa yli kuukauteen. Retroja ei ole pakko pitää sprinttitahdissa, jos ette halua. Itse asiassa neuvomme usein, että retrot kannattaa irrottaa sprinttifrekvenssistä, koska se pakottaa pitämään retrot eriytettynä muista seremonioista. Meidän kokemuksemme mukaan retro osana sprintin lopetusreview-kokousta saa usein liian vähän aikaa, fokusta ja huomiota. Lisäksi sprintin viimeinen päivä on matalan energiatason päivä. Kaikki ovat väsyneitä; se ei ole hyvä aika luovaan ongelmanratkaisuun.

Hyvä retro on tunnin mittainen

Hyvä retrospektiivi ottaa aina tunnin. Minulla on aika paljon kokemusta retrojen fasilitoinnista ja olen nähnyt monen tiimin retroja.



Hyvä retro on tunnin mittainen.

Vähemmän ei vaan yksinkertaisesti riitä. Tuntikin pitää käyttää tehokkaasti, aikaa pitää käyttää alun aiheiden exploraatioon, sitten keskusteluun ja priorisointiin, sitten analyysiin ja root causen mietintään ja lopuksi sen suunnitteluun, mitä asialle voitaisiin tehdä.


Jos ajattelet asiaa, niin tunti kuukaudessa on hyvä investointi siitä, että tiimin suorituskyky on jatkuvalla nousukäyrällä. Ottakaa se tunti ja käyttäkää se tehokkaasti!


Retrotaidot kannattaa opetella

Retrospektiivi on periaatteessa kokous – siihen kannattaa suhtautua niin, että kokousta hallitaan ja sillä on joku fasilitaattori. Yleensä tämä on Scrum Master. Scrum Masterin kannattaa opetella retrospektiivien erikoispiirteet. Mitä erilaisia keinoja voi käyttää alun aiheiden exploraatioon? Mitä keinoja voi käyttää, jos joku henkilö tai aihe dominoi keskustelua? Miten hallita ajankäyttöä? Tätä voi opiskella itse tai Contribyten avustamana.


Niin hauska ajatus kuin retrojen hostaamisen kierrättäminen onkin, olisi kuitenkin suositeltavaa, että jokainen joka vuorollaan hostaa retroa, osaa retron järjestämisen perusasiat. Peruseepos retroista on Esther Derbyn “Making good teams great”, josta tekemämme arvostelun löytää täältä.


Sopivasti ja realistisia touhupisteitä


Aivan olennaista retroissa on, että lopputuloksena saadaan jotain toimenpiteitä, millä tilannetta parannetaan (tai jos on havaittu joku todella hyvä tapa tehdä töitä, mietitään miten sitä tapaa muistetaan tehdä useammin, tai miten sitä voidaan jalkauttaa muualle organisaatiossa). Tässä kannattaa muistaa muutama asia.


Ensimmäinen on ajankäyttö – retron viimeinen 15 minuuttia kannattaa varata toimenpiteiden suunnitteluun ja sen varmistamiseen, että joku paikallaolijoista ottaa homman vastuulleen. Eli lupaa tehdä asialle jotain. Eikä vain jotain: paras lupaus on konkreettinen, aikaan ja paikkaan sidottu lupaus “ensi viikon tiistaina aamulla kello 8–11 teen tämän asian. Epämääräisemmät lupaukset on helppo unohtaa ja lykätä.


Samanlainen impakti saadaan myös sillä, että retron parannustoimenpide ladataan automaattisesti aina seuraavan sprintin sisältöön, ja tuoteomistaja priorisoi sen korkealle. Se on nyt siis lupa tehdä.


Jos toimenpiteet jätetään epämääräisiksi, ilman omistajaa, ilman deadlinea, ilman lupausta tehdä asialle jotain, tai ne jätetään lataamatta seuraavaan sprinttiin, voi melkein jo antaa takuun sille, että niitä harvoin tehdään. Ja tämä on yksi perussyy, miksi retrot alkavat maistua tylsiltä. Touhupisteisiin kannattaa siis panostaa, sekä aikaa että lupausenergiaa.

Touhupisteiden pitää olla realistisia, eli tehtävissä olevia. Ne eivät voi olla sellaisia, joita tiimi ei voi tehdä. Jos tarvitaan apua ulkoa, niin touhupiste on sellainen, että taivutellaan muita auttamaan.


Touhupisteitä ei myöskään voi olla liian monta. Jos päätetään tehdä 5–8 action pointtia per retro, on suuri riski, että osaa niistä ei saada tehdyksi. On parempi valita vain 1–3 touhupistettä, ja sen sijaan pitää retroja tiheämmin ja ottaa aina tavaksi saada touhupisteet tehdyksi. Retrojen touhupisteitä EI saa kasata backlogille – ne pitää aina tehdä ennen seuraavaa retroa!


Touhupisteet pitää AINA tehdä


Tästä päästäänkin seuraavaan asiaan. Päätetyt touhupisteet pitää ottaa tavaksi tehdä – aina. Erittäin todennäköisesti tämä vaatii vähän coachausta. Taas päävastuu voi olla Scrum Masterilla. Ruoskimiselta vältytään, jos touhupisteet ovat edellä kuvatun kaltaisesti mahdollista tehdä, ja niihin on annettu lupa käyttää aikaa (Scrumissa lupa käyttää aikaa tarkoittaa, että ne on ladattu sprintin backlogiin).


Jos tiimi oppii, että retroissa sovittuja touhupisteitä ei tarvitsekaan tehdä, loppuu aika nopeasti motivaatio miettiä mitään touhupisteitä. Sitten seuraavaksi ollaankin siinä kierteessä mistä aikaisemmin puhuin: tuntuu että minkäänlaista muutosta ei saada aikaan.


Tämä vaatii retron hostaajalta (eli yleensä Scrum Masteriltä) jonkin verran kurinalaisuutta – retroista kannattaa tehdä memo ja touhupisteet kirjata ylös sovittuun paikkaan. Jos on, kuten suosittelemme, sovittu niin että ne ladataan automaattisesti seuraavaan sprinttiin, sitten Scrum Master voi ne syöttää sinne heti retrosession loputtua. Tämä on erittäin tärkeä pointti sen kannalta, miten arvokkaana tiimi näkee retrokokouksen. Pieni asia, mutta yllättävän usein tämä on pielessä muuten hyvissä kehitystiimeissä.


Retrojen keinovalikoiman laajennus


Kuudes ja viimeinen asia tässä retrojen perusasioiden listassa on retrokeinovalikoiman pitäminen tarpeeksi laajana. Tiimin pitää saapua retrosessioon hyvällä mielellä ja virkeänä. Yksi asia mikä voi madaltaa mielialaa on, jos retro vedetään läpi aina samalla metodilla, varsinkin jos se metodi on tunnin puhdas vapaa keskustelu “mikä meni hyvin” ja “mikä meni huonosti.”


Maailma on täynnä kivoja retrometodeja perushauskoista MAD, SAD, GLAD tai 4L -metodeista vähän erikoisempiin, kuten vaikka omaan suosikkiini “Many faces of Jack Sparrow”. Netistä löytyy googlaamalla vaikka kuinka paljon retrokeinoja, ja olemme kasanneet Contribyten suosikkikeinot retrotyökalupakkiin.


Formaattia vaihtamalla voi saavuttaa sen, että keino sopii kivasti kulloiseenkin ongelmatilanteeseen. Jotkut retrokeinot sopivat paremmin pidemmän aikavälin taaksepäin katsomiseen (vaikkapa Root cause tree) tai sitten tulevaisuuden ennustamiseen (Pre-mortem). Autan mielelläni teitä laajentamaan teidän retrovalikoimaanne! Joko tuolla retrojen tehostuspaketilla tai sitten voidaan keksiä jotain muutakin. Ota rohkeasti yhteyttä!


Näillä kuudella asialla saadaan aikaan jo paljon


Jos olette onnistuneet saamaan jo nämä yllä kuvaamani kuusi asiaa kuntoon, mahtavaa! Teidän retrospektiivit ovat jo erittäin hyvällä mallilla! Niitä voi sitten halutessaan vieläkin parantaa – lista pikkuasioista, mitä voi lähteä hiomaan on pitkä: positiiviset retrot, alun jäänsärkijäkikat, virkeyden hakeminen vierailijoilla, fokusalueet, paikan vaihtelu, tulosten julkisuus, muiden tiimien coachaus paremmaksi, monen tiimin yhteisretrot, etäretrot – lista on pitkä. Mutta kuudella perusasialla pääsee hienosti alkuun. Ja takaan, että jos saatte nuo kuusi asiaa kuntoon, niin olette parempia kuin yhdeksän kymmenestä scrum-tiimistä. Siitä tuleekin pian jo väistämättä tehokkuus- ja kilpailuetua!


Kiitos kun jaksoit lukea ja toivottavasti palaat takaisin taas ensi viikolla uuden Scrumin parhaat seremoniat blogin pariin! Hauskaa kevättä!

Pinterest
Contribyte logo

Lisätietoja

Yritysprofiili Contribyte kotisivut

Tagit

Jos tarjontatagi on sininen, pääset klikkaamalla sen kuvaukseen

Liiketoimintaprosessi

Tietohallinto

Erikoisosaaminen

Ketterät menetelmät
Ohjelmistokehitys

Toimialakokemus

IT

Tarjonnan tyyppi

Konsultointi
Koulutus

Omat tagit

retrospektiivi
scrum master
scrum-seremonia

Siirry yrityksen profiiliin Contribyte kotisivut Yrityshaku Referenssihaku Julkaisuhaku

Contribyte - Asiantuntijat ja yhteyshenkilöt

Premium-profiilia ei ole aktivoitu. Aktivoi premium-profiili näyttääksesi tässä lisäämäsi 3 asiantuntijaa.

Contribyte - Muita referenssejä

Contribyte - Muita bloggauksia

Löydä sopivimmat it- ja ohjelmistoyritykset liiketoiminnan kehityskumppaneiksi

ite wikin yrityshaku »

It- ja ohjelmistoalan työpaikat

Kaikki it-alan työpaikat »

Premium-asiakkaiden viimeisimmät referenssit

ite wikin referenssihaku »

Tapahtumat & webinaarit

Kaikki it-alan tapahtumat »

Premium-asiakkaiden viimeisimmät bloggaukset

ite wikin julkaisuhaku »

Digitalisaatio & innovaatiot blogimedia

Blogimediamme käsittelee tulevaisuuden liiketoimintaa, digitaalisia innovaatioita ja internet-ajan ilmiöitä
Loka 30
Suomalainen innovaatiotoimisto on kansainvälisesti palkittu ja kehittää digitaalisia palveluita maailman suurimmille firmoille - Näin Hellonin palvelumuotoiluprosessi eroaa it-toimittajien mallista
Hellon on kerännyt useita kansainvälisiä digitaalisen designin palkintoja
Loka 11
Digipalvelulain saavutettavuusvaatimuksia aletaan soveltaa uusiin verkkopalveluihin 28.6.2025 - Näin asetus vaikuttaa digitaalisten palveluiden kehityshankkeisiin
Digipalvelulaki sisältää kolme keskeistä vaatimusta saavutettavuudesta
Loka 10
Digitalisaatiokentän syksyn tapahtumia 2024
Ite wikin tapahtumasivu koostaa yhteen digitalisaatiokentän tapahtumat ja webinaarit
Siirry blogiin

Etusivu Yrityshaku Pikahaku Referenssihaku Julkaisuhaku Blogimedia