Tässä kirjoitelmassa kerron Scrumin käytöstä Lemonsoftilla. Tarkoitukseni ei ole tehdä syväluotaavaa pohdintaa joka tarraa syvälle scrumin teorioihin, vaan kertoa enemmän käytännönläheisesti eri vaiheistamme Scrumin käyttöönotossa. Scrumissa on harvoja hyvin tarkasti kirjoitettuja sääntöjä ja parhaista Scrumin käyttötavoista käydäänkin jatkuvasti kiivasta keskustelua. Scrum muokkautuu yleensä jonkin verran sitä käyttävän organisaation mukaiseksi, mutta liikaa se ei saa karata perusteoriasta tai silloin ei voida ainakaan puhtaalla omallatunnolla sanoa Scrumin olevan käytössä organisaatiossa. Jos haluat tarkentaa nopealla ja kevyellä tavalla omaa Scrum tietämystäsi suosittelen lukemaan Ken Schwaberin ja Jeff Sutherlandin kirjoittaman oppaan The Scrum Guide. The Scrum Guide löytyy helposti internetin hakupalveluja käyttämällä. Teoksesta löytyy myös tarkasti Scrum-ammattilaisten kanssa suomennettu versio.
Itse sain scrumiin ensikontaktini hyvin suppeasti ammattikorkeakoulussa yleisiä ohjelmistokehitystekniikoita läpi käytäessä. Sittemmin tutustuin aiheeseen silloisen esimieheni lyhyen esittelyn perusteella ja lähdin hänen kannustamanaan tutustumaan aiheeseen tarkemmin ScrumMaster -sertifikaatin muodossa. Jo tätä ennen olimme valmiiksi kuitenkin tutustuneet aiheeseen ja päättäneet kokeilla scrumin käyttöä.
Itse scrumin teoria on melko selkeää ja helposti ymmärrettävää, mutta sen käyttöönotto ja käytäntöön sovittaminen ei mennytkään ihan niin helposti. Otimme teoriasta aina pieniä osia kerrallaan käyttöön, kuten koko scrumin teoriassakin kehotetaan toimimaan. Paransimme tekemistä jokaisen kehityssyklin aikana, aina palanen kerrallaan, jokaisessa sprintissä kohti parempaa laatua ja mielekkäämpää tekemistä. Alussa meilläkin esiintyi pientä muutosvastarintaa, joka sitten ajan myötä karsiutui pois. Nyt kukaan meistä ei enää haluaisi palata menneeseen.
Ensimmäinen konkreettien asia Scrumin käyttöönoton kanssa oli tarkempi lyhyen tähtäimen ennakoiva suunnittelu. Scrumissa työt toteutetaan saman mittaisina toistuvien sprinttien sisällä. Sprintit ovat suojeltuja ulkopuoliselta häirinnältä työn etenemisen ja sen laadukkuuden varmistamiseksi. Lemonsoftilla työt eivät koskaan lopu, aina on tarjolla uusia ajatuksia ja aina löytyy jotain parannettavaa. Tällöin työlistan suunnittelu on suurelta osin asioiden priorisointia. Sprintin suunnittelu sen ensimmäisenä päivänä realisoi kuitenkin sen tarpeen, että koko tiimille tulee olla valmiiksi suunniteltua työtä.
Käytämme töiden seurantaan Microsoftin Team Foundation Serveriä, jossa on mahdollista käyttää myös Scrum projektinhallinnan viitekehykseen liittyviä prosessimalleja. Näin saamme suunnitellut työt ja niille arvioidut toteutusajat näkyviin helposti tiimin tai niin haluttaessa myös henkilön tai vaikka koko tuotekehityksenkin tasolta. Scrum keskittyy kuitenkin tiimiajatteluun.
Kuva: Tiimien kuormitustilanne
Töiden etenemistä sprintin kestoon nähden seurataan ns. Burndown -kaaviolla, jonka ajatus on seurata mahdollisimman realistisesti aina parhaan sen hetkisen arvion mukaista sprintillä jäljellä olevan työn määrää.
Kuva: Burndown-chart
Töiden etenemistä seurataan päivittäisellä tasolla ns. daily scrum -palavereissa. Palavereiden ideana on synkronoida tiimin tekeminen sekä varmistaa, että kaikki pääsevät töissään eteenpäin. Palaveri kestää maksimissaan 15 minuuttia. Mikäli daily scrumin aikana selviää, että jollain tiimin jäsenellä on ongelmia tai este töiden etenemisen suhteen, sovitaan asian ratkaisemiseksi daily scrum palaverin ulkopuolinen hetki vain asian ratkaisemiseen tarvittavien henkilöiden kanssa. Daily scrumin tarkoituksena on myös vähentää päällekkäisten toisiinsa vaikuttavien töiden yhtäaikaista tekemistä, ilman että kehittäjät olisivat edes tietoisia asiasta.
Lemonsoftilla daily scrumeissa seurataan henkilötasolla noin työpäivän mittaisiksi pilkottuja, sprintissä kehitettävien ominaisuuksien valmistumiseen liittyviä töitä. Näitä tavallisimmin ovat ”konepellin alla olevat” kenties arkkitehtuurisetkin muutokset ja niiden suunnittelu, itse ominaisuuksien koodaus ja näyttöjen suunnittelu, testaus ja tulevan testauksen suunnittelu sekä sisäinen ja ulkoinen dokumentointi. Sprintin sisäisillä pienemmiksi kokonaisuuksiksi pilkotuilla töillä eli taskeilla on vain kolme tilaa ”To do”,”In progress” ja ”Done”. Eli näkökulmana kiinnostaa ainoastaan onko taski vielä aloittamatta, parhaillaan käynnissä vai jo valmis. Taskin tilanmuutos tai jäljellä olevan arvioidun työmäärän muutos vaikuttaa suoraan aikaisemmin esiteltyyn Burndown -kaavioon. Taskit tulisi myös suunnitella niin pieniksi, että niiden tilan vaihtumisia pitäisi tapahtua daily scrumien välillä, jolloin myös paikoilleen jumiutuminen havaitaan helpommin.
Kuva: Sprint board
Töiden seurattavuus on parantunut Lemonsoftilla scrumin käyttöönoton myötä, sillä nyt näemme nopeasti mitä tietyille töille kuuluu tai mikä on tiimin sen hetkinen kuormitusaste.
Teoriassa tiimi on itse sitoutunut sprintin töihin, jotka se aikoo saada valmiiksi sprintin aikana. Töihin tulee sitoutua, mutta käytännössä joskus käsitys työn sisällöstä muuttuu aloitetun työn myötä sen verran paljon, ettei työtä saadakaan suunnitellussa ajassa valmiiksi. Myös sairastapaukset ja muut vastaavat yllätykset vaikuttavat tiimin työtehoon. Scrumin tarjoamien seurantatyökalujen ansioista asioihin pystytään reagoimaan nopeasti. Tarkoitus ei ole yrittää lakaista ongelmia maton alle, vaan koko Scrumin idea on nostaa erilaiset, välillä kivuliaatkin ongelmat esiin. Scrum ei kerro mitä niille tehdään, mutta se pakottaa tekemään asioille jotain.
Asioihin ja ongelmakohtiin voidaan reagoida usein jo sprintin aikana. Jos ongelmaan ei voida kesken sprintin vaikuttaa, se siirtyy seuraavalle. Retrospektiivipalaverissa, joka pidetään sprintin lopussa, käydään läpi hyvin menneet sekä kehitystä kaipaavat asiat ja laaditaan suunnitelma kehitysten jalkauttamiselle.
Sprintin aikana tehdyt toteutukset tai muutokset käydään läpi sprinttikatselmuksessa. Sprinttikatselmukseen on kutsuttu asiaankuuluvat sidosryhmät tai heidän edustajansa. Sprinttikatselmuksessa tarjotaan myös paikka kehitystiimin ulkopuoliselle palautteelle, jonka perusteella esimerkiksi sprintissä valmistunutta ominaisuutta voidaan kehittää edelleen. Asiakkaamme antavat normaalisti palautteensa helpdesk-järjestelmämme kautta kehitysideoiden muodossa.
Asiakkaamme kirjaavat satoja kehitysideoita. Viime vuonna niitä kirjattiin 1524 kappaletta. Tämä tarkoittaa keskiarvollisesti 29 kehitysideaa joka viikko. Lemonsoftin tuoteomistajat käsittelevät kehitysideat normaalisti viikoittain ja koostavat tehtyjen kehitysideoiden pohjalta töitä tuotekehityksen työlistalle.
Hyväksytyt kehitysideat, pakolliset työt sekä ennen kaikkea tuotteen visio on product backlogissa, joka sisältää ideaalitilanteessa tarvittavan tarkalle tasolle määriteltyjä töitä noin kahdelle seuraavalle sprintille. Liian suuri product backlog johtaa hallittavuudelta raskaaseen kokonaisuuteen. Product backlogin tulee kuitenkin sisältää aina sen verran työtä, ettei työlista pääse loppumaan kesken, myöskään siinä tapauksessa jos sprintin tavoitteet täyttyvätkin ennalta arvioitua nopeammin.
Koostetaan lyhyesti Scrum -prosessin pääpiirteet vielä kasaan. Kaikki tekeminen pyörii sprinttien aikataulutuksen mukaan. Sprintit toistuvat samankokoisina paloina luoden rytmiä sekä kiinnekohtia muuten usein hyvin erilaisiin ja välillä hajanaisenkin tuntuisiin ohjelmistokehitystehtäviin.
Kaikki alkaa sprintin suunnittelussa, jossa kehittäjille esitetään tuotepäälliköiden priorisoima lista ohjelmaan halutuista ominaisuuksista. Tiimit hyväksyvät itse oikean määrän työtä sprinttiin, tarkoittaen sitä minkä määrän työtä he arvioivat kykenevänsä saamaan valmiiksi sprintin aikana yhdessä sovitun määritelmän mukaisesti. Sprintin työt kerätään siis product backlogista, niille asetetun prioriteetin mukaisesti, sekä sen mukaan mitä tiimi kokee järkeväksi toteuttaa seuraavaksi ja mitä se arvioi saavansa valmiiksi sprintin aikana. Kehittäjä antaa työlle viimeisen työmääräarvion. Sprintin ajaksi työlista suljetaan ja uusia töitä ei oteta vastaan. Työn edistymistä tarkkaillaan päivittäin, jotta mahdolliset esteet työn etenemiselle saataisiin raivattua nopeasti pois tieltä. Sprintin lopussa syntyy potentiaalisesti julkaisukelpoinen ohjelmaversio. Versioon tulleet muutokset käydään sitten läpi yrityksen sisäisessä sprinttikatselmuksessa, jossa kerätään vielä sidosryhmiltä palautetta uusista ominaisuuksista ja tämän perusteella mahdollisesti päivitetään tuotteen kehitysjonoa eli product backlogia. Sprintin retrospektiivissa kerätään palautetta, miten sprintin tai koko Scrum-prosessin kulku on sujunut. Jokaisella kierroksella pyritään tekemään aina pieni parannus, miten seuraavasta sprintistä saataisiin taas hieman edellistä mielekkäämpi ja tuottavampi, parempi sprintti.
Kuva: Scrum-prosessi yksinkertaistettuna
Mainitsin Scrumin parantaneen töiden seurattavuutta käynnissä olevan sprintin suhteen. Tämän lisäksi Scrum yhdistettynä Team Foundation Serveriin (TFS) luo meille taas uusia mahdollisuuksia. TFS:sään kirjataan alkuperäinen työn tarve, jolloin myöhemmin voidaan ominaisuutta muokattaessa palata helpommin siihen, mikä itseasiassa oli aikaisemmin toteutetun ominaisuuden alkuperäinen tarve. Töihin voidaan liittää siis määrittely, ohjeet, testit ja suora viittaus työn johdosta tehtyihin koodimuutoksiin. Näin muutosten tai mahdollisesti tehtyjen virheiden alkuperä on helpompi selvittää ja suunnitella tulevia muutoksia.
Siitä lähtien kun TFS on ollut käytössämme töiden seurantaan, olemme pystyneet jäljittämään helpommin myös yksittäisten kehitysideoiden kulun. Tulevaisuuden haaveet vievät meillä yhä täsmällisempään ja parempaan suuntaan myös asiakkaidemme informoimisen suhteen. Kaikki kehitys kuitenkin vaatii aikansa.
Tänä vuonna kirjatuista hyväksytyistä kehitysideoista jokaisen voi paikantaa esimerkiksi suoraan tuotekehityksen työlistalta kehitysidean numeron perusteella.
Scrum on luonut meille mallin, jonka perusteella näemme selkeästi missä kohtaa tuotekehitysprosesseja meillä on suurimmat haasteet. Näihin haasteisiin olemme vastanneet yksi kerrallaan. Suurimmat jo tehdyt muutokset liittyvät organisaation rakenteeseen. Seuraavat haasteet liittyvät julkaisujärjestelmään, versionhallintaan sekä uuteen selainpohjaiseen tuotteeseemme LemonOnlineen.
Ehkä nämä tulevat muutostarpeet olisi tiedostettu ilman Scrumiakin, mutta sen ansiosta meillä on selkeämpi malli ja tapa selvittää tiemme maaliin muutosten läpi. Scrum keskittyy enemmän ketterään tekemiseen ja lyhyen tähtäimen suunnitteluun, mutta myös pitkäntähtäimen suunnitelmat tulee olla tehtynä, varsinkin Lemonsoftin kaltaisessa elinkaarettomassa tuotteessa. Suurien asioiden tekeminen vaatii useita sprinttejä ja lopullinen visio tulee olla kaikille kehittäjille selvillä.
Informaatioteknologian, materiaalinhallinnan ja taloushallinnon maailmaan liittyy paljon lyhenteitä ja hienoja sanoja, joten lopuksi nippelitietona, mistä termi Scrum itseasiassa tulee. Scrum viittaa rugbyn aloitusryhmitykseen, josta joukkueen jäsenet reagoivat tilanteeseen hyvin nopeasti ja itseohjautuvasti. Suomalaiselle rugby on lajina melko tuntematon, mutta jos jaksoit lukea kirjoituksen loppuun, etsi käsiisi video tuosta aloituskuviosta, niin ymmärrät vertauksen paremmin.
