Uuden toimintatavan oppiminen ja erityisesti ottaminen käytäntöön voi aluksi tuntua haastavalta. Näin ei kuitenkaan tarvitse olla Scrumin osalta. Toimintatavan käyttöönoton pilkkominen osiin auttaa pääsemään alkuun, sekä keskittymään oikeisiin asioihin. Alla olen listannut mielestäni tärkeitä Scrumin implementoinnin vaiheita, joiden kautta pääset fiilistelemään miltä Scrum-lähestyminen tuntuu. Voit ensin harjoitella pienellä tiimillä ja yksinkertaisella tuotteella/projektilla. Itse olen esimerkiksi ajatellut hyödyntää Scrumin toimintatapoja taloyhtiön hallituksen työskentelyssä.
Tutustu Scrumin perusteisiin
Ensimmäinen askel Scrumin implementoinnissa on ilman muuta sen peruskäsitteiden ymmärrys. Sinun ei tarvitse sertifioitua Scrum Masteriksi tai tuoteomistajaksi (PO:ksi), mutta sellaisten käsitteiden hallinta kuten esimerkiksi sprintti, backlog, käyttäjätarina, scrum taulu, retrospektiivi ja demo auttavat hahmottamaan miten Scrum toimii. Tähän riittää mainiosti esimerkiksi tämä peruskurssi. Hyvä perusteos aiheeseen on myös Jeff Sutherlandin “Scrum – The art of doing twice the work in half the time”.
Muodosta tiimi ja roolit
Toinen askel on määritellä tiimi, joka tulee työskentelemään Scrum-projektin parissa. Tiimin pitäisi sisältää tuoteomistajan, Scrum Masterin, ja kehittäjät/työn suorittajat (3-9 henkilöä). Jokainen rooli on tärkeä, joten vastuut kannattaa määritellä selkeästi. Pienemmissä projekteissa tuoteomistaja voi ottaa myös Scrum Masterin roolin. Tässä on kuitenkin oltava tarkkana, sillä kyseisen henkilön käytössä oleva aika ei välttämättä riitä molempien roolien samanaikaiseen hoitamiseen. PO:n tehtävänä on myös maksimoida tiimin tuottama arvo, samalla kun Scrum Masterin pitää suojella tiimiä liiallisilta odotuksilta.
Backlogin luominen
Kuten mainitsin aikaisemmin, ensimmäiseksi Scrum-harjoitteluprojektiksi kannattaa valita mahdollisimman selkeä kehityskokonaisuus, jota voisi toteuttaa suhteellisen lyhyessä ajassa (max muutama kuukausi).
Tuoteomistaja luo backlogin, joka sisältää kaikki sen luontihetkellä tiedossa olevat tulevan tuotteen ominaisuudet. Jokaisen tuoteominaisuuden pitäisi tuoda lisäarvoa loppukäyttäjälle. Mikäli näin ei ole (tai lisäarvo on vain pieni), niin kyseinen tuotteen ominaisuus kannattaa jättää toteuttamatta.
Kun kaikki tuotteeseen tulevat ominaisuudet ovat dokumentoitu backlogille, tuoteomistaja priorisoi niiden toteutusjärjestyksen. Näin tärkeämmät ominaisuudet tulevat työn alle ensin ja loput vasta myöhemmin. Tästä muodostuu työjono, josta tehtävät otetaan järjestyksessä sprinteille.
Sprinttien suunnittelu ja toteutus
Tiimi sopii alussa sprinttien kestosta. Nämä voivat vaihdella yhdestä neljään viikkoon. Sprintin keston valinnassa kannattaa vastata seuraaviin kysymyksiin:
- Kuinka usein halutaan saada palautteen tuotteen loppukäyttäjiltä?
- Kuinka usein työn prioriteetit kannattaa arvioida uudestaan?
- Kuinka usein halutaan arvioida tiimin työskentelyn tehokkuuden?
Mielestäni kaksi viikkoa on sopiva kesto sprintille kehitystyön alussa. Tarpeen mukaan kadenssia voi muuttaa lyhyemmäksi tai pidemmäksi.
Kehittäjät (työn suorittajat) ottavat priorisoidusta backlogista tehtävät sprintille ja pilkkovat ne tarvittaessa pienempiin osiin.. Sprintille otetaan ainoastaan sen verran tehtäviä mitä aiotaan sen aikana saada valmiiksi.
Sprintin aikana kannattaa pitää lyhyet (max 15 min) päivittäiset palaverit (dailyt), joiden avulla tiimi pysyy synkassa ja jakaa keskenään omat edistymiset ja haasteet.
Sprinttien arviointi ja retrospektiivi
Sprintin lopussa tiimi katselmoi saavutettiinko sprintin tavoitteet ja miten paljon yksittäisiä tehtäviä jäi vielä auki. Jokaisella sprintin tehtävällä pitää olla hyväksymiskriteeri, jonka täytyttyä tehtävät merkitään valmiiksi.
On myös hyvä käytäntö pitää demotilaisuus jokaisen sprintin lopussa. Sen aikana sprintin saavutuksia ”demotaan” loppukäyttäjille ja muille mahdollisille sidosryhmille. Tämän tavoitteena on saada palautetta rakennettavasta tuotteesta mahdollisimman varhaisessa vaiheessa. Palautetta hyödynnetään seuraavien sprinttien suunnittelussa.
Järjestä myös retrospektiivisessio, jossa tiimi arvioi omaa työskentelyprosessia ja ehdottaa siihen parannuksia seuraavia sprinttejä varten. Scrum on jatkuvaa kehitystä ja oppimista, joten tiimin pitää olla aina valmis tekemään nopeita kokeiluja ja muutoksia työskentelytapoihin.
Scrum-prosessin toteuttaminen vaatii sitoutumista, avoimuutta ja jatkuvaa viestintää tiimin jäsenten välillä. Scrum on joustava kehys, joka voi vaatia sovittamista tiimin ja projektin tarpeisiin. Näin olleen, ole valmis sopeutumaan ja kehittämään prosessia tarpeiden mukaan.
Toivottavasti näistä vinkeistä oli sinulle apua. Mikäli sinulle heräsi joitakin kysymyksiä Scrumin implementointiin liittyen, niin voit olla aina yhteydessä Taskmillin asiantuntijoihin. Pyrimme auttamaan parhaamme mukaan.