Monissa yrityksissä valmentaessani olen törmännyt asiaan, joka häiritsee minua suuresti. Yritykset sanovat tekevänsä Agile-kehitystä ja käyttävät Scrum-menetelmää. Käytännössä tämä on kuitenkin tarkoittanut sitä, että heillä on 1–3 viikon iteraatiot (sprintti) ja mahdollisesti Daily standupit käytössä. Puhutaan User Storeista, mutta niiden määritelmä on hieman sekava ja monesti niitä ei edes ehditä tekemään tämän iteraation aikana valmiiksi. Myöskään muita seremonioita, kuten retrospektiiveja tai sprinttien katselmointeja, ei oikeasti hyödynnetä.  

Tässä blogissa kerron oman näkemykseni siitä, mitä Sprint Review:n tulisi sisältää.

Sprint Review on paljon muutakin kuin Demo

Sprint Review:n pitäisi olla paljon muutakin kuin Demo.

Sprinttien katselmointi on ehkä yksi aliarvostetuimmista tapahtumista Scrum-käytännöissä, tai sitten se on vain väärin ymmärretty. Monesti tapahtumassa käydään läpi, mitä on saatu aikaiseksi, ja se demotaan – ja kenties retrotaan – mutta eipä sitten paljon muuta olekaan. Usein tämä pidetään myös ainoastaan tiimin sisäisenä tapahtumana.

Katselmoinnissa olisi tarkoitus käydä läpi mitä tiimi on saanut aikaiseksi, eli ”Done-asiat”, mutta myös ”NOT Done -asiat”, eli mitä ei saatu tehtyä. Tämän lisäksi pitäisi vähän tarkastella backlogista esimerkiksi nykyisen ja kenties tulevienkin releasejen sisältöä. Ollaanko budjetissa, aikataulussa, tai onko kenties tarvetta kasvattaa kapasiteettia? Onko olemassa jotain riskejä, joiden vuoksi joudutaan vaikka laittamaan koko kehitys jäihin? Entä ollaanko tässä juuri loppuneessa Sprintissä löydetty tai huomattu jotain, mikä kuuluisi lisätä backlogille? Onko joidenkin asioiden prioriteetti muuttunut? Entäpä riskitasot?

Avaan kohta näitä asioita hieman tarkemmin, jotta niiden tarpeellisuus tulisi esille.

Lähdetään kuitenkin ensin liikkeelle siitä, kenen pitäisi osallistua sprinttien katselmointiin.

Keiden pitäisi osallistua?

Tiimi itse, koska se on vastuussa tuotoksestaan. Tiimillä tosiaan tarkoitan koko tiimiä: tuoteomistaja/Product Owner, Scrum master ja kehitystiimi. Tämän lisäksi olisi hyvä että myös muut sidosryhmät, jotka ovat kiinnostuneita tiimin tuotoksista, tulisivat ainakin silloin tällöin kuulemaan miten työ edistyy. Esimerkiksi pilottiasiakkaat (silloin kun mahdollista), liiketoiminnan edustajat, mahdolliset muut tiimit tai käyttäjät voisivat tässä vaiheessa olla hyödyllisiä. Asiakas (sisäinen tai ulkoinen) on erittäin tärkeässä roolissa, koska hänelle ollaan toimittamassa tilattua työtä. Tämä on se paikka keskustella jatkosta, mihin halutaan mennä.

Budjetti, aikataulu ja sisältö

Sprintti-katselmoinnissa on tarkoitus tarkastella koko sprinttiä, jotta nähdään missä mennään. Erityisen tärkeää olisi keskittyä muun muassa budjettiin, aikatauluihin, riskeihin ja sisältöön.

Budjetti

Ollaanko edelleen budjetissa? Tämä on erityisen tärkeätä silloin kun asiakasprojektit tehdään agile-periaatteilla. Tekeminen ja budjetti pitää olla läpinäkyviä kaikille, koska silloin voidaan nopeasti vaikuttaa asioihin ja tehdä tarpeelliset päätökset. Näin vältytään suuremmilta yllätyksiltä myöhemmin. Uskallan väittää, että asiakas ja toteuttajat ovat tästä yhtä mieltä. Periaatteessa jokaisen sprintin jälkeen on mahdollista tehdä päätös, että lopetetaan kehitys. Jäljellä oleva raha voi myös vaikuttaa prioriteetteihin!

Aikataulu

Ollaanko siinä aikataulussa kuin kuvitellaan? Aikataulu on monesti lukittu johonkin julkaisuun tai muuhun tärkeään päivämäärään, mutta sisältöön voidaan vaikuttaa. Tässä taas tullaan siihen tärkeään asiaan, että asiakaan pitää olla mukana mahdollisimman paljon alusta lähtien, ja että backlogin pitää olla ymmärrettävä ja priorisoitu. Jos aikataulua halutaan nopeuttaa, niin silloin pitää mahdollisesti miettiä, onko tarvetta ottaa lisää resursseja tiimiin. Resurssien lisäys pitää analysoida hyvin sen pohjalta, tuoko se sitä haluttua nopeutta kehitykseen vai ei. Varsinkin kehityksen loppuvaiheessa uudet henkilöt eivät tuota samaa lisäarvoa kuin muuta jäsenet. Tämä vaikuttaa myös budjettiin.

Jokainen sprintti on riskienhallintaa

Tiimille nousseita riskejä pyritään lieventämään tai poistamaan Sprintin aikana. Riskienhallintatoimenpiteitä ovat muun muassa tutkimus-storyt (”spike”), joiden avulla voidaan selvittää lisää vaatimuksen toteutusta tai sen tarpeellisuutta. Oli riskeihin liittyvät toimenpiteet mitkä tahansa, tulokset katsotaan katselmoinnissa yhdessä läpi, ja tehdään päätös sen suhteen, miten jatketaan. Tämä jää valitettavan usein tekemättä.

Sisältö elää – hyvä backlog muuttuu!

Backlog on elävä vaatimuslista, joka pitää olla tärkeysjärjestyksessä eli priorisoitu. Backlogille voi tulla koska vain uusia juttuja, mutta yhtä lailla sieltä voidaan koska vain ottaa asioita pois. Katselmoinnin aikana, varsinkin Demo-osiosta, voi asiakkaalle tulla ahaa-elämyksiä oikeasta toteutuksesta verrattuna siihen, mitä paperille (ppt mockup) oltiin kirjattu vaatimukseksi. Näin ollen katselmoinnit ovat ehkä tärkeimpiä palautesilmukoita niin asiakkaalle kuin tiimille. Palautteen perusteella pyritään vähentämään tarpeettoman teko ja keskittymään siihen oleelliseen, joka tuottaa arvoa.

Kuusi vinkkiä hyvään Sprint Review -tilaisuuteen!

Tuota parempaa arvoa tehokkaalla Sprint Review:llä.

Valmistaudu tähänkin tapahtumaan kunnolla. Kurinalaisuus on tärkeintä, mutta monesti myös se vaikein asia yrityksissä, jossa vanha kulttuuri tappaa uuden tekemisen mallia.

Tässä muutamia nostoja seuraavaan Sprintti-katselmukseen:

• Huolehdi, että backlog on päivitetty ja priorisoitu ennen tapahtumaa

• Tilaa kahvit ja ”perjantaipullat”

• Pitäkää tapahtuma mahdollisimman vapaana, mutta hyvin fasilitoituna (tämä on tärkeää!)

• Varsinkin jos haluat mukaan ydintiimin ulkopuolisia, muista lähettää kutsut tapahtumaan hyvissä ajoin! Pyri samaan asiakkaita ja käyttäjäkuntaa mukaan.

• Älä kontrolloi liikaa – ”Vapauta” tiimi keskustelemaan suoraan asiakkaan tai loppukäyttäjien kanssa. Näin kehittäjät saavat paremman käsityksen mahdollisesti toteutustavasta.

• Käytä aikaa siihen, että tiedätte mihin haluatte mennä!

Yhteenveto

Sprint Review:n tulisi olla muutakin kuin demo. Tämä on se arvokas hetki, jolloin voidaan katsoa mitä ollaan saatu aikaiseksi ja mihin halutaan seuraavaksi mennä. Onko tullut jotain uutta tietoa tarpeista, jotka vaikuttavat sisältöön tai koko kehitykseen. Tehdään päätökset yhdessä ja läpinäkyvästi. Jaetaan tietoa!

Haluatko kehittää sprint review’ta tai muita agile-seremonioita? Lataa ilmainen Agilen superseremoniat -oppaamme ja nosta seremoniasi seuraavalle tasolle!