Tuli toive edellisen postauksen jälkeen, että olisi kiva kuulla lisää tuosta Scrumista. Toive lämmitti sydäntä, että päätin heti kirjoittaa aiheesta. Satuin tekemään tästä lopputyöni ylemmässä AMK:ssa kun tein MBA-tutkintoa englanniksi. Lopputyö on nimeltään SharePoint and Scrum ja löytyy Theseuksesta.
Olen tehnyt Scrumin kanssa töitä vuodesta 2010 asti. Scrumin on kehittänyt Jeff Sutherland vaikka kasa ihmisiä idästä onkin antanut siihen jo enemmän viitteitä. Netistä löytyy pilvin pimein viittauksia erilaisiin Scrum ja Agile (=ketterä) kirjallisuuksiin. Mielestäni suomenkielinen wikipedia antaa hyvän selostuksen mitä on Scrum, ja en nyt halua lähteä kirjoittamaan tuota artikkelia uudestaan. Kirjoitan asian omasta näkökulmasta.
Jos tämän blogauksen jälkeen asia kiinnostaa enemmän, suosittelen lukemaan lopputyöstäni erilaisista projektimenetelmistä. Tämä avaa ymmärrystä mitä tarkoittaa ketterä projektimenetelmä, mistä sen tarve on lähtenyt ja minkälaisia menetelmiä on muitakin. Tuon jälkeen voi lukea wikipedian määritelmän. En kuitenkaan suosi suomenkielisiä termejä vaan me käytämme rooleista ja palavereista englanninkielisiä aivan selvyyden vuoksi. Kuten usein IT-alalla käytetään termeistäkin virhekommunikaation estämiseksi. Varsinkin kun nykypäivänä offshore-mallien ja kansainvälistymisen myötä työskentely ja palaverikieli on yhä enemmän englanti.
Minulle scrum oli pimeässä loistava majakka. Se oli kaikkea mitä kaipasin. Siinä oli tarpeeksi yksinkertainen malli ja teoria, johon pystyi syventymään niin paljon kuin halusi, mutta pystyi todella pienellä tiedolla sen kanssa työskentelemään. Se on myös malli, minkä voi opettaa muulle projektiryhmälle lennosta. Toki aluksi tulee vähän sama fiilis kuin korttipelissä, jota opetetaan samalla kun pelataan. Opettajalta tulee koko ajan uusia sääntöjä, mutta parin sprintin jälkeen kaikki alkavat olla kärryillä ja parantamana itse prosessia.
Jos nyt nopeasi kuvailisin sitä, niin kyseessä on projektimalli, jossa ei ole projektipäällikköä. Ohjelmisto tai tuote toteutetaan pienissä sykleissä, sprinteissä. Jokaisen sprintin jälkeen pitää olla valmis potentially shippable product – it-maailmassa se tarkoittaa ihan toimivaa systeemiä. Jos kyseessä olisi kotisivut, niin varmaan ensimmäisenä olisi sivuston pystytys ja yleistyyli. Tämän jälkeen jokainen sprintti täydentää projektia. Voitaisiin aloittaa vaikka sivuston eri osiosta ja seuraavan sprintin jälkeen löytyy etusivu ja kenties uutisosio. Aina kun luodaan uusia palasia, niin tulee lisää moduuleita sivustoon. Nettisivut ovat huono esimerkki, koska ammattilainen tekee viikossa valmiilla julkaisujärjestelmällä sivut. Koitin vain kuvailla, mitä tarkoittaa palasissa toteuttaminen.
Ideana tässä on, että tilaajalla on koko ajan käsitys mitä ollaan tekemässä. Tilaaja näkee koko ajan mitä saa ja voi heti vaikuttaa mitä tehdään seuraavassa sprintissä. Jos uutisosio näyttää ikävältä ja pitäisi seuraavaksi rakentaa portfolio-osio, voi tulla fiilis, että hei me halutaankin tämä ja tämä ensin. Tällöin valitaan ne seuraavaan sprintiin. Erona perinteiseen vesiputousmalliin on se, että ensin tilataan jotain ja määritellään se. Sitten koodarit toteuttavat ja saadaan jotain. Kun mennään ketterällä tyylillä, lopputulos luultavasti on aivan eri mitä aluksi oltiin määrittelemässä. Tuo lopputulos on kuitenkin juuri se, mitä tilaaja oikeasti tarvitsee. Projektin myötä tilaajan tietämys toteutettavasta tuotteesta kasvaa ja hän on täysin kärryillä jokaisesta ominaisuudesta, mistä hän on maksanut.
Scrum tiimissä on erilaisia osaajia, tehtävät ovat kuitenkin yhteisiä. Kehitystiimin lisäksi siellä on product owner ja scrum master. Scrum master katsoo, että scrum pyörii sääntöjen mukaan. Hän varaa palaverien tilat ja ohjailee prosessia, mutta ei vaikuta itse sisältöön. Product owner on asiakkaan edustaja, joka hallitsee kokonaisuutta mitä ollaan tekemässä. Tämä kokonaisuus on lista, jota kutsutaan product backlogiksi. Product owner on yleensä tilaajan edustaja, joka vastaa tiimin kysymyksiin ja käy tiimin kanssa läpi jokaisen sprintin alussa (sprint planning), mitä ominaisuuksia backlogilta otetaan seuraavaan sprintiin. Tämän jälkeen kehitystiimi purkaa keskenään nuo ominaisuudet teknisiksi tehtäviksi.
Kaikki tehtävät ovat priorisoidussa järjestyksessä. Työtehtävä otetaan aina listan kärjestä. Kun tiimin jäsen aloittaa työn, hän ottaa tehtävän listan kärjestä ja merkitsee sen itselleen. Näin muut tietävät, että tuo tehtävä on jo hoidossa. Seuraava ottaa seuraavan listalta. Kun tiimin jäsen saa tehtävänsä valmiiksi, hän katsoo listaa ja ottaa sieltä seuraavan vapaan tehtävän. Kun sprintti on ohi, heillä on kaikki tai suurin osa valituista ominaisuuksista valmiina. Tässä tilaisuudessa (sprint review) voi olla muitakin katsomassa tuota sprintin lopputuotosta. Tämän jälkeen sovitaan taas seuraavan sprintin toteutettavat ominaisuudet.
Tässä oli todella karkea esitys Scrumista. Jos asiaa kiinnostaa, niin suosittelen lukemaan lisää. Pääsääntöisesti se vaatii, että ihmiset ovat samassa tilassa. Tai ainakin pitävät päivän aikana paljon yhteyttä. Tämä malli ei välttämättä toimi esimerkiksi nuorkauppakamaritoimintaan, jossa ei olla samassa tilassa eikä työskennellä samaan aikaan. Scrumi ei myöskään toimi, jos siitä ottaa vain itselle sopivat osat. Siinä on esimerkiksi palaveri sprintin jälkeen, jossa analysoidaan kulunutta sprinttiä prosessina ja valitaan seuraavan sprintin kehityskohteet. Hyvä scrum tiimi luo jatkuvasti itselleen uusia sääntöjä ja kehittävät omaa toimintaansa.
Tässä yksi todella hyvä video product ownerin tehtävästä – tämäkin opetusvideo siis vain yhden roolintehtävästä. Melkein tärkeämpi tehtävä on Scrum masterilla, joka vahtii, että koko sirkus pyörii kuten pitää.
Että semmoista… se on tosi hauska juttu. Tykkään ehkä siksi niin paljon, kun on niin simppeli ja selkeä. Ja kaikki on huomioitu. Roolit, vastuut, palaverit ja menetelmät. Kuitenkin jokainen saa kehittää omaa prosessiaan, kehittää lisää sääntöjä. Työkalut voivat olla post-it lappuja seinällä, excel (huono vaihtoehto) tai tätä varten räätälöity it-järjestelmä.
Hyvää loppiaista itse kullekin!
