PROJEKTINHALLINTA SCRUMIN AVULLA

Transkriptio

1 PROJEKTINHALLINTA SCRUMIN AVULLA Anttoni Lahtinen Mika Suikkanen Saana Vaateri Helmikuu 2016 Tietojenkäsittely Proakatemia

2 2 SISÄLLYS 1 JOHDANTO Ketterä kehitys Melu SCRUMIN ROOLIT Tuoteomistaja Scrummaster Kehitystiimi Scrumtiimi SCRUMIN PROSESSI Tuotteen kehitysjono Sprintin kehitysjono Valmiin määritelmä POHDINTA Scrummmasteri business leaderinä Päiväpalaverin hyödyntäminen akatemialla Valmiin määritelmä Case-esimerkki: Scrumin hyödyntäminen Kiivi-innossa LÄHTEET... 17

3 3 1 JOHDANTO Ohjelmistokehityksessä on lukuisia eri projektinhallintamalleja, joilla ohjelmistokehitysprosessia voidaan viedään eteenpäin. Prosessi kuvaa joukkoa vaiheita, jotka suoritetaan tietyssä järjestyksessä. Projektinhallintamalli pyrkii nimensä mukaisesti helpottamaan projektinhallintaa ohjelmistokehityksen aikana. Perinteisiä malleja ovat esimerkiksi Vesiputousmalli, iteratiivinen malli, spiraalimalli, sekä agilemallit.(selecting a development approach, viitattu 14.2.) KUVA 1. Vesiputousmalli Vesiputousmallia pidetään Scrumin vastakohtana. Se on mm. tietokonekomponenttien ja muun teollisuuden tuotantoprosesseissa käytetyistä menetelmistä syntynyt malli. Ohjelmistokehityksen alkuvaiheessa ei ollut tarjolla kuin kyseisiä teollisuuden käyttämiä menetelmiä ja vesiputousmalli kopioitiin sieltä käyttöön vähin muutoksin. Sille tyypillistä on alun tarkka suunnittelu, jonka aikana projekti jaetaan kronologisessa järjestyksessä eteneviin palasiin. Tämän jälkeen palaset toteutetaan yksi kerrallaan. Mallin parhaita puolia on alun suunnittelu, joka hyvin toteutettuna vähentää tuotantoon asti päätyviä bugeja. Kritiikkiä malli saa sen joustamattomuudesta ohjelmistotuotannossa. Teollisuuden puolella kesken projektia muuttuneiden prioriteettien tai muun syyn takia muutosten tekeminen on liian kallista ja aikaa vievää. Ohjelmistotuotannossa tämä ei pidä paikkaansa ja samalla voidaan todeta, että alan teknologia kehittyy huomattavasti nopeammin kuin useimmilla teollisuuden aloilla. Projektin toteutuksen aikana saattaa syntyä uutta teknologiaa, joka kannattaa ottaa mukaan projektiin. 1.1 Ketterä kehitys

4 4 Keskitymme tässä esseessä esittelemään ketterän ohjelmistokehityksen (agile software development) Scrum-menetelmää. Ketterä ohjelmistokehitys perustuu Ketterän ohjelmistokehityksen julistukselle (Agile Manifesto), joka sisältää 12 periaatetta ja neljä arvoa. Me etsimme parempia keinoja ohjelmistojen kehittämiseen tekemällä sitä itse ja auttamalla siinä muita. Tässä työssämme olemme päätyneet arvostamaan Yksilöitä ja vuorovaikutusta enemmän kuin prosesseja ja työkaluja Toimivaa sovellusta enemmän kuin kokonaisvaltaista dokumentaatiota Asiakasyhteistyötä enemmän kuin sopimusneuvotteluita Muutokseen reagoimista enemmän kuin suunnitelman noudattamista. Vaikka oikeallakin puolella on arvoa, me arvostamme vasemmalla olevia asioita enemmän. (Ketterän ohjelmistokehityksen julistus, viitattu 21.2.) Julistus kehitettiin vuonna 2001 Utahissa 17 eri ketterän menetelmän edustajan voimin. Ketterät toimintamallit nostavat asiakkaan ohjelmiston yläpuolelle. Ensimmäinen periaatteista kuuluukin: Tärkein tavoitteemme on tyydyttää asiakas toimittamalla tämän tarpeet täyttäviä versioita ohjelmistosta aikaisessa vaiheessa ja säännöllisesti.. Tämän takia juuri Toimiva ohjelmisto on edistymisen ensisijainen mittari., ei esimerkiksi laajat suunnitelmat tai hyvä dokumentointi. Asiakas voi ottaa parhaiten kantaa toimivaan ohjelmistoon. Tämän takia Scrum on jaettu sprintteihin, joiden aikana tiimi rakentaa ohjelmistoon asiakkaan toivomia ominaisuuksia. Sprintti mahdollistaa tiimille ajan toimia rauhassa, kahdesta viikosta kuukauteen. Sprintin jälkeen tiimi esittelee tuotoksensa asiakkaalle ja tämä voi ottaa kantaa tuotteeseen. Olivatko ominaisuudet toivottuja? Onko markkinatilanne tai prioriteetit ohjelmiston suhteen muuttuneen? Voidaanko jatkaa alkuperäisellä suunnitelmalla? Tiimi sopii mitä seuraavassa sprintissä tehdään ja tätä seuraa uusi sprintti uudella julkaisulla. Scrumin taustalla on myös ajatus projektihallintamallin minimoinnista. Projektihallinnassa säilytetään vain välttämättömimmät komponentit ja muu heitetään pois. Projektihallintaan tottumattomalle Scrumin työkalut voivat tuntua paljolta lisätyöltä, mutta verrattuna muihin projektinhallintatyökaluihin on asiakirjoja verrattavan vähän. 1.2 Melu

5 5 Ken Schwaber kuvaa elämän moniulotteisuutta ja muuttujia termillä melu (noise). Elämässä on paljon epätarkkuutta ja epätäydellisyyttä. Yhtenä esimerkkinä Schwaber mainitsee erilaiset pituuden mittayksiköt. Keittiön kaapin pituus ilmoitetaan sentteinä, mutta todellisuudessa 1 sentti voi olla 1,00356 senttiä. Yleensä tämä ei ole ongelma, ellei näitä sentin palasia ladota peräkkäin :ta, jolloin melusta voi tulla ongelma. Ihmiset ovat suurin melunaiheuttaja ja sen takia ihmisiä sisältävässä projektissa on aina odotettavissa melua. Esimerkiksi viestintä, vaikkapa projektin tavoitteiden avaaminen kaikille täysin selväksi, voi olla mahdotonta. Osmo A. Wiion sanoin: "Viestintä epäonnistuu aina paitsi sattumalta. Scrum pyrkii vastaamaan melun olemassaoloon pyrkimällä vähentämään sitä: Esimerkiksi tapaamiset kasvokkain ja tiimin työskentelyrauha sprintin aikana. Tämän lisäksi Scrum on omiaan muuttuvaan maailmaa, jossa yllättävän melun ilmaannuttua suunnitelmia tulee muuttaa. Scrum voidaan yhdistää myös muihin ketterän kehityksen menetelmiin, kuten esimerkiksi Extreme Programming-metodologiaan (XP). XP:ssä ohjelmoijat työskentelevät pareissa, testaavat koodia jatkuvasti sekä pyrkivät pitämään sen yksinkertaisena (Keep it simple, Stupid!-periaate). Kannaltamme mielenkiintoisempaa kuitenkin on miten hyvin Scrumia voi soveltaa ohjelmistokehityksen ulkopuolella? Proakatemian projektit poikkeavat usein teollisesta tuotannosta ja ovat lähempänä ohjelmistoprojekteja. Asiakas saattaa muuttaa toiveitaan kesken projektin tai tilanne markkinoilla saattaa muuttua. Toisaalta myös monet Scrumin periaatteista sopivat yritykseen kuin yritykseen, esimerkkinä asiakaslähtöisyys ja hyvä vuorovaikutus. Esittelemämme projektinhallintatyökalut ovat loistavia myös siksi, ettei niitä kaikkia tarvitse ottaa saadakseen huomattavaa etua tiimin toimintaan. Esimerkiksi tiimin työskentely voisi parantua huomattavasti implementoimalla pelkkä päiväpalaveri: Päivä aloitetaan mahdollisimman lyhyellä palaverilla, jossa jokainen noin minuutissa käy läpi: 1. Mitä teki eilen? 2. Mitä aikoo tehdä tänään? 3. Mitä esteitä työn teolla on? Scrumin käyttöön Proakatemialla perehdymme esseen lopulla. Sitä ennen esittelemme sen eri osa-alueet ja jäsenet.

6 6 2 SCRUMIN ROOLIT 2.1 Tuoteomistaja Tuoteomistaja (TO) on käytännössä projektin kasvot ja kuten nimikkeestäkin jo selviää, tyypillisesti lopputuotteen omistaja. Hänen vastuullaan on selkeä visio lopputuloksesta ja sen vision jakaminen kehitystiimille. Tuoteomistajalla on myös hyvä olla näkemystä kehitettävän tuotteen markkinoista, käyttäjistä ja kilpailijoista, jotta lopputulos olisi mahdollisimman hyödyllinen ja arvokas. Hänen ei kuitenkaan tule puuttua projektin tekniseen puoleen vaan vastata enemmänkin projektin bisnespuolesta. TOn tärkein tehtävä on järjestää tuotteen kehitysjono yhdessä kehitystiimin kanssa ja toimia kommunikointiväylänä kehitystiiimin ja sidosryhmän kanssa. Sidosryhmälle hän viestii projektin tilasta ja neuvottelee projektin laajuudesta sekä rahoituksesta. Projektilla tulee kuitenkin olla vain yksi TO, jotta tiimin ei saa ristiriitaista tietoa useammalta TOlta. 2.2 Scrummaster Scrummaster on kehitystiimin suojelija tai valmentaja. Hänen tehtävänään on poistaa kehitystiimin häiriötekijät ja auttaa tiimiä tekemään niin laadukasta jälkeä kuin mahdollista. Käytännössä se tarkoittaa työskentelyä tuotteen omistajan kanssa, jotta tuotteen kehitysjono mahdollisimman hyvä. Hän myös pitää silmällä kehitystiimin tilaa ja puuttuu epäkohtiin, jos sellaisia ilmenee. Scrummasterilla ei kuitenkaan ole muuta valtaa, kuin se minkä tiimi hänelle antaa, joten hän ei voi suoraan käskeä tiimin jäseniä, esimerkiksi tekemään tiettyä työtehtävää. Ainoastaan kun näyttää siltä että tiimi toimii scrumin ulkopuolella, on scrummasterin tehtävä ohjata heidät takaisin. Tämä erottaa scrummasterin perinteisestä projektipäälliköstä. 2.3 Kehitystiimi Kehitystiimi vastaa projektin varsinaisesta kehityksestä. Tiiimi on itseohjautuva, joten he voivat itse päättää kuinka kehitysjonon sisältö muutetaan toimivaksi lopputuotteeksi. Tiimin jäsenillä on omat erikoisosaamisensa, mutta vastuu projektin kehityksestä kuuluu

7 7 koko tiimille. Jäsenet auttavat ja opettavat toisiaan, jotta projekti pysyy aikataulussa. Tyypillinen koko kehitystiimille on 3-9 henkilöä, tällöin tiimi pysyy mahdollisimman tehokkaana ja joustavana. 2.4 Scrumtiimi Scrumtiimiin kuuluvat kaikki aikaisemmin mainitut, eli tuoteomistaja, scrum-mestari ja kehitystiimi. Scrumtiimi on itseohjautuva ja sillä on valta päättää omista työmenetelmistä.

8 8 3 SCRUMIN PROSESSI Scrum projekti alkaa projektissa kehitettävän tuotteen visiolla. Tuote voi olla aluksi suurpiirteinen, mutta se muotoutuu selkeämmäksi projektin edistyessä. Tuoteomistaja luo projektille suunnitelman, joka pitää sisällään tuotteen kehitysjonon. Tuotteen kehitysjonon perusteella kehitystiimi lähtee suunnittelemaan seuraavaa sprinttiään. (Schwaber 2004, 7-8.) Scrumin prosessi perustuu iterointiin, joka toteutetaan sprinttien avulla. Iteroinnissa työtehtäviä toistetaan niin kauan, kunnes ne saadaan valmiiksi tai halutaan lopettaa. Sprintit ovat pituudeltaan yleensä enintään 30 kalenteripäivää ja niiden pituus pysyy samana koko projektin ajan. Jokaista sprinttiä voi ajatella pienempänä projektina, jolla on tietty tavoite. Kun tuotetta kehitetään sprinttien avulla pienissä osissa, sen riskit vähenevät, sillä sprinteissä tehtävän työn edistymistä ja valmistumista on helpompi hallita ja tarvittaessa muokata. (Schwaber 2004, 8.) KUVA 2. Scrumin prosessi Sprinteissä tavoitteena on saada kehitystiimin ja tuoteomistajan yhdessä läpikäydyt tehtävät valmiiksi. Laatutaso ja tehtävät pysyvät samana koko sprintin ajan eikä niitä muuteta. Kehitystiimi voi kuitenkin tarkentaa sisältöä sprintin aikana neuvottelemalla tuoteomistajan kanssa. Mikäli sprintin tavoite muuttuu tarpeettomaksi sen aikana, voi tuoteomistaja keskeyttää sprintin. Sprinttien lyhyyden takia niitä keskeytetään kuitenkin harvoin. (Schwaber 2004, 8.)

9 9 Jokainen sprintti aloitetaan sprintin suunnittelupalaverilla, joka ei saa olla kestoltaan 8 tuntia pidempi. Sprintin suunnittelupalaverissa kehitystiimi valitsee ja arvioi yhdessä tuoteomistajan kanssa sprintissä toteutettavat tehtävät tuotteen kehitysjonosta, jotka listataan ylös sprintin kehitysjonoon. Tämän jälkeen scrumtiimi määrittelee yhdessä koko sprintin tavoitteen, jonka pohjalta kehitystiimi luo suunnitelman miten sprintin kehitysjonon tehtävät saadaan valmiiksi. Suunnitteluun ei käytetä liikaa aikaa, sillä tärkeintä on päästä tekemään. (Schwaber 2004, 8.) Sprintin aikana kehitystiimi kokoontuu päivittäin 15 minuutin mittaiseen päiväpalaveriin. Päiväpalaverissa jokainen tiimiläinen vastaa kolmeen kysymykseen: 1. Mitä tein eilen? 2. Mitä aion tehdä tänään? 3. Mitä esteitä työn teolle on tullut? Scrummaster varmistaa, että kehitystiimi järjestää päiväpalaverin päivittäin ja että tiimi pystyy pitämään sen 15 minuutin pituisena. Päiväpalaverien tarkoitus on saada koko tiimin työskentely synkronoitua päivittäin sekä parantaa tiimin kommunikaatiota, vähentää muita palavereja sekä edistää nopeaa päätöksentekoa. Tämän lisäksi edellä mainittujen kysymysten perusteella voidaan tarkastella edistyykö työ kohti sprintin tavoitetta. Päiväpalaveriin osallistuu vain kehitystiimi ja siellä ei ole tarkoitus raportoida mitään. (Schwaber & Sutherland 2014) Sprintin lopussa pidetään noin neljän tunnin kestoinen sprintin katselmointi, jonka aikana scrumtiimi esittelee tuoteomistajalle sekä mahdollisille muille sidosryhmille sprintin aikana valmiiksi saadut työt. Katselmoinnin tarkoituksena on luoda kaikille yhteinen kuva siitä mitä on tehty, mitä tiimin kannattaisi tehdä seuraavaksi ja kuinka kaukana tavoitteesta ollaan. (Schwaber 2004, 9) Sprintin katselmoinnin tuloksena on tarkistettu tuotteen kehitysjono, joka sisältää todennäköiset tuotteen kehitysjonon kohdat seuraavalle sprintille. Tuotteen kehitysjonoa voidaan myös yleisesti muokata sisältämään uusia kehitysmahdollisuuksia. (Schwaber & Sutherland 2014) Ennen seuraavaa sprintin suunnittelupalaveria scrummaster pitää sprintin retrospektiivipalaverin, jossa tiimillä on mahdollisuus tarkastella ja kehittää omaa tekemistään, jotta seuraava sprintti sujuisi entistä paremmin ja mukavammin. (Schwaber 2004, 9)

10 Tuotteen kehitysjono Tuotteen kehitysjono on lista asioista, joita projektin aikana tullaan tuotteelle tekemään. Se pitää sisällään tuotteelle toteutettavat ominaisuudet, toiminnot, vaatimukset, parannukset ja korjaukset. Tuotteen kehitysjonon sisällöstä, järjestämisestä ja saatavuudesta vastaa tuoteomistaja. (Schwaber & Sutherland 2014) Tuotteen kehitysjonon ensimmäinen versio sisältää vain tuoteomistajan ensimmäiset arviot tuotteen vaatimuksista. Se kehittyy koko projektin ajan, kun tuote sekä sen ympärillä oleva ympäristö kehittyy. Tätä voi tapahtua esimerkiksi markkinoilta saadun palautteen avulla. Tuotteen kehitysjonoa muutetaan jatkuvasti, jotta pystytään tarkemmin tunnistamaan mitä tuote tarvitsee ollakseen tarkoituksenmukainen, kilpailukykyinen ja käytännöllinen. (Schwaber & Sutherland 2014) Tuotteen kehitysjono (TAULUKKO 1.) sisältää vähintään työtehtävän kuvauksen, missä sprintissä tehtävä toteutetaan ja kuinka kauan siihen menee työaikaa. Tuotteen kehitysjonossa järjestyksessä korkeimmalla olevat tehtävät ovat selkeämpiä ja yksityiskohtaisempia toteutuksen ja työmäärän osalta. Kehitysjonossa matalammalla olevat tehtävät ovat yleensä suurpiirteisempiä, eikä niitä ole ehditty työstää kehitystiimin kanssa loppuun. (Schwaber & Sutherland 2014) Työtehtävä Sprintti Arvioitu työaika tunteina Pelimoottorin ohjelmointi osa Tasosuunnittelu osa Hahmografiikkojen toteutus 2 12 Tasojen grafiikkojen toteutus 2 10 Nettisivujen sisällön suunnittelu 3 4 Pelimoottorin ohjelmointi osa Pelin äänet 3 15 Nettisivujen ohjelmointi 5 8 TAULUKKO 1. Tuotteen kehitysjono Tuotteen kehitysjonon sisältöä työstetään toistuvasti yhdessä tuoteomistajan ja kehitystiimiin kanssa. Kehitystiimi käyttää yleensä kehitysjonon työstöön enintään 10% kapasiteetistaan ja sen käytännön toteutuksesta päätetään tiimin sisällä. Työstön aikana kehitysjonoa siistitään yksityiskohtien, työmääräarvioiden ja kehitysjonon järjestyksen osalta.

11 11 Tuotteen kehitysjonon jokainen uuteen sprinttiin valittava tehtävä tulisi työstää niin yksityiskohtaiseksi, että se voidaan saada valmiiksi sprintin loppuun mennessä. (Schwaber & Sutherland 2014) Tehtäville asetetuista työmääräarvoista vastaa kehitystiimi. Tuoteomistaja voi yrittää vaikuttaa työmääräarvioihin auttamalla kehitystiimiä ymmärtämään tehtävän vaatimuksia ja tekemällä kompromisseja. Lopullinen sana on kuitenkin kehitystiimillä. (Schwaber & Sutherland 2014) Tuotteen kehitysjonossa oleva kokonaistyömäärä on laskettavissa yhteen milloin tahansa ja tuoteomistaja tarkistaa jäljellä olevan ajan jokaisessa sprintin katselmoinnissa. Lukua verrataan edellisen sprintin katselmointeihin, jolloin pystytään arvioimaan onko työ edistynyt yhtä nopeasti, kuin edellisessä sprintissä ja ollaanko tuotetta saamassa valmiiksi toivotussa aikarajassa. (Schwaber 2004, 11.) Tämä voidaan toteuttaa esimerkiksi kuvassa 3 löytyvän tuotteen edistymiskäyrän avulla, jossa pystyakselilta löytyvät työtunnit ja vaaka-akselilta jäljellä olevat työpäivät. KUVA 3. Tuotteen edistymiskäyrä 3.2 Sprintin kehitysjono Sprintin kehitysjonoon listataan tuotteen kehitysjonon tehtävät, jotka kehitystiimi on sitoutunut toteuttamaan sprintin aikana. Tuotteet on valittu yhdessä tuoteomistaja kanssa ja kehitystiimi on kirjannut ylös sprintin kehitysjonoon tuntimääräisen arvion siitä, kuinka nopeasti se saa työn tehtyä. Kehitystiimi on koko sprintin ajan vastuussa omasta ajankäytöstään. (Schwaber & Sutherland 2014)

12 12 Sprintin kehitysjonon lista on mahdollisimman yksityiskohtainen. Tämä helpottaa kehitystiimin työtä, sillä aikaa ei tarvitse käyttää työn suunnittelemiseen, vaan voidaan keskittyä itse tekemiseen. Sprintin kehitysjonon tehtävän kuvausta päivitetään, kun siitä opitaan sprintin aikana lisää. (Schwaber & Sutherland 2014) Sprintti 2 Työtehtävä Vastuuhenkilö Työn tila 1. päivä 2. päivä 3. päivä 4. päivä Tasojen esteiden väritys Hessu Aloittamaton 5 h 5 h 5 h 5 h Hahmojen väritys Saana Keskeneräinen 5 h 5 h 5 h 3 h Hahmojen animointi Anttoni Keskeneräinen 7 h 7 h 5 h 4 h Tasojen taustan toteutus Mika Valmis 5 h 4 h 2 h 0 h TAULUKKO 2. Sprintin kehitysjono Sprintinkehitysjonossa löytyy tehtävän yksityiskohtainen kuvaus, työmäärä tunteina, työn tila (valmis, keskeneräinen, aloittamaton) ja kuka kehitystiimin jäsenistä on vastuussa tehtävästä. Työmäärä vähähenee joka päivä työtä tehtäessä ja jäljellä olevaa työmäärää päivitetään jokaisessa päiväpalaverissa. Samalla arvioidaan ollaanko pääsemässä sprintin tavoitteeseen. (Schwaber & Sutherland 2014) 3.3 Valmiin määritelmä Jotta työn läpinäkyvyys turvataan, on koko scrumtiimillä oltava yhteinen ymmärrys siitä, mitä valmis työ tarkoittaa. Se voi olla esimerkiksi lista työtehtävistä, jotka tekemällä tuotteen osa saadaan julkaisukelpoiseksi. Valmiin määritelmän listan työtehtävät tulee pitää niin yksinkertaisina, että ne voi määrittää joko tehdyiksi tai keskeneräiseksi. Määritelmän avulla kehitystiimi pystyy helpommin arvioimaan, montako tehtävää se pystyy saamaan valmiiksi sprintin aikana. (Lekman 2015) Valmiin määritelmä pätee ensisijaisesti tuotteen kehitysjonon tehtäviin ja se vaihtelee eri scrumtiimien välillä. Scrumtiimin kehittyessä myös valmiin määritelmä kehittyy ja se saa ympärilleen tiukemmat kriteerit, jotka takaavat tuotteelle korkean laadun sekä tietyn standarditason tuotteeseen tehtävälle työlle. (Lekman 2015)

13 13 4 POHDINTA 4.1 Scrummmasteri business leaderinä Scrummasterin rooli scrumtiimissä on hyvin samantapainen kuin Kiivision business leaderin (BL). Kummallakaan ei ole suoraa ja perinteistä määräysvaltaa, joten molemmat pyrkivät vaikuttamaan eri tavalla. Scrummasteri voi vaikuttaa scrum-prosessiin, jonka kautta hän pystyy vaikuttamaan kehitystiimiin. Scrummasteri myös pyrkii poistamaan kehitystiimiä haittaavaat esteet ja valmentamaan tiimiä itseohjautuvuuteen. Kiivision BLn tehtävinä on yleensä ollut tiimin juoksevien asioiden hoitaminen ja kaikkia koskevista asioista tiedottaminen, sekä tiimin ohjaaminen kohti yhteisiä tavoitteita. Roolit ovat siis jo valmiiksi hyvin samankaltaiset, mutta jos muokkaamme BLn roolia entistä lähemmäksi scrummasteria, voi siitä olla hyötyä Kiivisiolle ja BLlle. Scrumissa on selkeät säännöt ja raamit, jonka sisällä scrumtiimi toimii ja jos tiimi on liikkumassa sen ulkopuolelle, on scrummasteri tehtävä ohjata tiimi takaisin. Kiivision kohdalla tämän voisi toteuttaa luomalla selkeät yhteiset pelisäännöt, josta kävisi ilmi miten tiimi työskentelee ja mitä tiimin jäseniltä odotetaan. Tällöin tilanteessa, jossa tiimi ei enää noudata näitä sääntöjä tai yksittäiset jäsenet eivät täytä heille asetettuja odotuksia, BLllä olisi valta puuttua tilanteeseen ja tehdä ratkaisuja. Tietenkin tiimi pyrkisi välttämään tälläisia tilanteita ja BLn avustuksella purkamaan ne ennenkuin ne ehtivät kehittyä pahemmiksi. 4.2 Päiväpalaverin hyödyntäminen akatemialla Kiivisiossa, ja yleisesti Akatemiallakin kuulee, että ihmiset haluaisivat tietää enemmän toistensa tekemisistä. Ei tiedetä miten toisilla menee ja mitä he tekevät. Tämä on ongelmallista myös tiimin tai projektiryhmän johdon kannalta. Lisäksi erikseen työskentelevät tiimin jäsenet eivät välttämättä hyödynnä tiimin ongelmanratkaisukykyä kohdatessaan ongelmia. Scrumin päiväpalaveri tuo ratkaisun näihin ongelmiin. Se parantaa tiimin kommunikaatiota ja edistää nopeaa päätöksentekoa.

14 14 Päiväpalaverin voisi ottaa käyttöön joko tiimin kanssa jolloin kaikki pysyisivät kartalla siitä mitä kukin tekee. Tällöin käytössä olisi myös laajempi verkosto ongelmien ratkaisemiseen. Päivittäin, esimerkiksi kello tapahtuva tiivis tsekki parantaisi myös tiimin jäsenten ajanhallintaa, kun päivän tavoite olisi asetettu selkeästi heti aamulla. Tiimiläiset näkisivät toisiaan enemmän ja näkemisen puitteissa olisi mahdollista vaihtaa muitakin kuulumisia. Tällaisessa muodossa täytyisi kuitenkin ottaa kantaa siihen, miten ilmeneviä ongelmia käsitellään. Tavallisesti Scrummaster tarttuisi ilmeneviin työnteon esteisiin palaverin jälkeen, mutta Proakatemia perinteisessä tiimimallissa tällaista henkilöä ei suoraa ole nimetty. Yksi mahdollisuus olisi BL:n toimiminen esteiden purkajana. On tietenkin todettava, ettei läheskään kaikkiin työn esteisiin edes voi puuttua ulkopuolisen avuin. Esimerkiksi asiakkaan materiaalin toimituksen venyminen on este, jonka ratkaisuna on asianomaisen yhteydenotto asiakkaaseen. Tällaisessa tapauksessa päiväpalaveri auttaa tiedostamaan ongelman ja luonnollinen ratkaisu olisi olla asiakkaaseen yhteydessä palaverin jälkeen. Sen sijaan esimerkiksi jonkin projektiryhmän erimielisyydet saattaisivat selvitä paremmin ulkopuolisen sovittelijan avulla. Toinen vaihtoehto on käyttää päiväpalaveria projektihallinnan työkaluna. Päiväpalaveri voisi olla esimerkiksi kaksi kertaa viikossa projektiryhmän sovittuina työpäivinä. Tällöin päiväpalaveri vastaisi lähemmin scrumin päiväpalaveria, kun kaikki palaveriin osallistuja työskentelevät saman projektin kimpussa. Palavereissa projektipäällikkö voisi toimia scrummasterina. 4.3 Valmiin määritelmä Valmiin määritelmä (Definiton of Done) on mielestämme parhain yksittäinen scrumista nostettava ajatus. Yksilöajattelussa valmiin määritelmää voi verrata esimerkiksi Juha T. Hakalan turmarajamääritelmään: Turmaraja on se laatutaso, jonka alle ei saa missään tapauksessa mennä. (Uralehti: Downshifting työntekijän oma strategia selviytyä. Lainattu

15 ). Turmaraja on hyvä huomioida valmiin määritelmää tehtäessä, rima voidaan kuitenkin asettaa myös korkeammalle. 15 Kun valmiin määritelmä on muodostettu, kykenee yksilö kommunikoimaan tiimin kanssa työtehtävien edistymisestä. Hän myös ymmärtää eri työvaiheiden tärkeyden ja tietää panostaa niihin aikaa ja resursseja. Valmiin määritelmä tuo tiimille selkeän tavoitteen. Tiimi myös tietää missä vaiheessa tavoitteen saavuttamista ollaan. Valmiin määritelmä on asiakkaan näkökulmasta hyvää tuotteistamista. Sen viestiminen asiakkaalle helpottaa tietämään, mitä tuotteelta tai palvelulta odottaa. 4.4 Case-esimerkki: Scrumin hyödyntäminen Kiivi-innossa Kiivi-Inno on Kiivision 16 tunnin mittainen kaksipäiväinen innovointi, jossa ideoimme ratkaisuja asiakkaan antamaan haasteeseen. Innovoinnin tuotteena tarjoamme perustellun ratkaisun, jonka asiakas pääsee arvioimaan presentaation ja raportin pohjalta. Kiivi-innon hinta perustuu asiakkaan antamaan arvosanaan asteikolla 1-5. Scrumista saa hyödynnettyä useita osia, joilla Kiivi-innon toteutus saadaan ketterämmäksi ja tehokkaammaksi. Kiivi-innon projektipäällikkö toimii projektissa tuoteomistajana ja hän on vastuussa tuotteen kehitysjonon toteuttamisesta ennen Kiivi-innon ensimmäisen päivän alkua. Projektipäällikkö rakentaa tuotteen kehitysjonon asiakkaan toimeksiannon vision sekä oman visionsa perusteella. Loput 16 Kiivisiolaista on jo jaettu neljään neljän hengen scrumtiimiin. Jokainen scrumtiimi on valinnut keskuudestaan yhden scrummasterin, jonka tehtäviin kuuluu oman tiiminsä motivointi sekä sprintin tavoitteessa pysymisestä huolehtiminen. Scrummaster pitää myös huolen tiimin hyvinvoinnista, tauoista ja toimii kommunikaattorina projektipäällikön ja kehitystiimin välillä. Ensimmäinen innovointipäivä alkaa kello 8 projektipäällikön pitämällä esityksellä, jossa hän esittelee tuotejonon tärkeimmät tehtävät. Esitys on kestoltaan maksimissaan yhden tunnin mittainen ja sen aikana scrumtiimit voivat esittää kysymyksiä ja tarkentaa tuotteen

16 16 kehitysjonon tehtäviä. Tunnin aikana valitaan myös ensimmäisessä sprintissä toteutettavat tehtävät kullekin scrumtiimille. Tiimien on tärkeä pystyä arvioimaan oma ajankäyttönsä ja kuinka paljon he pystyvät saamaan aikaan yhdessä sprintissä. Sprintit ovat Kiivi-innossa pituudeltaan 3 tuntia, jolloin niitä mahtuu 16 tunnin innovointiin 4. Päivän ensimmäisen ja toisen sprintin välillä pidetään 15 minuutin mittainen päiväpalaveri, jossa scrumtiimit kokoontuvat yhteen ja käyvät läpi mitä sprintissä saatiin valmiiksi, mitä seuraavassa sprintissä tehdään ja onko eteen tullut jotain esteitä. Samalla projektipäällikkö voi tiedottaa, mikäli toimeksiantajalta on tullut uutta tietoa, minkä perusteella tuotteen kehitysjonoa pitäisi muuttaa. Kello Tapahtuma Päivä 1 8:00-9:00 Projektipäällikön esitys, scrumtiimien kyselyt 9:00-12:00 Sprintti 1: Innovointi 12:00-13:00 Ruokailu 13:00-13:15 Päiväpalaveri 13:15-16:00 Sprintti 2: Tiedonhakua Päivä 2 8:00-9:00 Projektipäällikön esitys, scrumtiimien kyselyt 9:00-12:00 Sprintti 3: Toteutusta, käytäntöön viemistä, raportin aloitus 12:00-13:00 Ruokailu 13:00-13:15 Päiväpalaveri 13:15-16:00 Sprintti 4: Viimeistelyä, esityksen valmisteleminen TAULUKKO 3. Kiivi-innon esimerkki aikataulu ja sisältö scrumilla toteutettuna

17 17 LÄHTEET Bussa, M Scrum Outside of Software Development. Blogiteksti. Julkaistu Luettu Centers for Medicare & Medicaid Services Selecting a development approach. Luettu Ketterän ohjelmistokehityksen julistus Lekman, L Valmiin määritelmä kuntoon. Luettu Mountain Goat Software Scrum. Luettu Radigan, D Atlassian: A brief introduction to scrum. Luettu Schwaber, K Agile Project Management with Scrum. Redmond, Washington: Microsoft Press. Schwaber, K. & Sutherland, J Scrum Guide. Luettu Suomenkielinen scrum-sanasto Luettu The Less Company Product owner. Luettu

18 18 Uralehti Downshifting työntekijän oma strategia selviytyä. Julkaistu Luettu