WHAT AND WHY?

Scrum on amerikkalaisen Jeff Sutherlandin kehittämä projektinhallintajärjestelmä. Yritän hieman avata tässä sen perusperiaatteita ja arvoja, sekä antaa lopussa termiselitysten jälkeen pikaoppaan sen käyttöön. Avartavia prokkiksia!

 

Tähän alkuun muutama Scrumin perusperiaate itse kehittäjän sanoin:

• Team is greater than an individual.
• It’s all about the process. Not the person.
• Plan, Do, Check, Act.
• Hesitation is death. Know where you are and act
• How do we do what we do, better.

 

Ja ehkä kaksi tärkeintä: ”Map is not the train” ja ”Change or die”. Nämä kaikki lausahdukset ja ideologia saivat minut ostamaan ajatuksen aika nopeastikin.

 

 

Kirjassa kerrotaan vanhentuneesta vesiputous- mallista, jota Scrum alun perin lähti syrjäyttämään. Vanhassa projektinhallintamallissa suunnitteluun käytetään todella paljon aikaa. Pieniä yksityiskohtia ja Gant- taulukkoa hiotaan suuressa tiimissä ja suunnitelmaa kierrätetään johtajalta toiselle hyväksyttäväksi. Pelkästään suunnitteluvaiheeseen käytetään hurjasti resursseja ja aikaa ja kun teon hetki koittaa, suunnitelmat (ja varsinkin Gant) räjähtävät käsiin. Todellisuutta ei voi koskaan täysin ennakoida, eikä kukaan todellisuudessa lue satojen sivujen mittaisia suunnitelmia. Kun sitten ilmenee suunnittelematon ongelma, sen syrjäyttämiseksi pyydetään lupaa ja neuvotellaan. Tämä tarkoittaa lopputuloksen venymistä ja mahdollisesti epäedullisia kompromisseja. Haluaisin kuitenkin ajatella, että näin kärjistetysti asiat toimivat vain Amerikassa mutta siinä piilee kuitenkin paljon totuuksia.

 

Scrumin perustana toimii tiimi ja tiimin vapaus. Tiimejä on tutkittu paljon ja lueskelin muutamia siihen liittyviä artikkeleita esimerkiksi Forbes:sta ja erilaisilta johtamis- ja itsensäkehittämissivustoilta (esimerkiksi refresh leadership, essential characteristics of a succesful team). Lähes kaikissa mainitaan yhteiset tavoitteet ja hyvä johtaminen sekä usein myös erilaisuus. Jeff Sutherland korostaa myös erityisesti tiimin vapautta. Jos tiimillä ei ole vapautta tehdä päätöksiä tilanteissa, se hidastaa projektien kehittymistä oleellisesti. Tämä pätee myös tiimin sisällä oleviin pienempiin tiimeihin. Jos esimerkiksi on jakauduttu markkinoinnin ja tuotekehityksen tiimeihin, on tuotekehityksellä oltava valta päättää tietyistä asioista kuten materiaaleista. Tietenkin yhteisesti määritettyjen raamien sisällä. Tiimissä on siis oltava myös luottamusta toisten kykyihin.

 

Sutherlandin mukaan yksilöllä ei juurikaan ole väliä, jos prosessi on kunnossa. Oletko koskaan miettinyt mikä olisi ollut sinun roolisi natsi-Saksassa, jos olisit ollut paikalla? 1961 vuonna tehdyn tutkimuksen mukaan 65% meistä olisi osallistunut kauhutekoihin. Ympäristön vaikutus on siis todistetusti hurja. (Reason.com, Would you have been nazi?)

 

Scrumissa pyritään luomaan kaikille turvallinen ympäristö mm. selkeän yhteisen päämäärän avulla, johon kaikki ovat sitoutuneita ja Sprintissä palautteen ja kehitysehdotusten muodossa. Järjestelmän yksi perusajatuksista on pyrkiä kehittymään jatkuvasti. Pyrkiä tekemään töitä tehokkaammin poistamalla esteitä ja ”jätettä”, joka tarkoittaa usein turhaa työtä. Tämän ajatuksen tulisi iskostua koko tiimiin, joka aiheuttaa kunnianhimoisen kehittymisen kierteen

 

Palautteella ei ole koskaan tarkoitus syytellä, vaan pyrkiä aina korjaamaan. Tämän pitäisi päteä mielestäni kaikkeen palautteenantoon, kaikissa tilanteissa. Kaiken ytimessä on ihmisten sitoutuneisuus yhteiseen tekemiseen ja kaiken tämän tekemisen ehdottomaan läpinäkyvyyteen. Yhteinen päämäärä kumoaa tiimin välistä kilpailua ja antaa mahdollisuuden vilpittömään onnellisuuteen toisten onnistumisista.

 

 

 

HOW?

 

Aikaisemmin mainitsemani Sprint tarkoittaa projektin alussa määriteltyä ”tarkastelujaksoa”. Tarkastelujakso määritellään heti projektin alussa tietyn pituiseksi, esimerkiksi kaksi viikkoa. Tarkoittaen sitä, että tiimi kokoontuu aina kahden viikon välein tekemään tilannekatsausta ja kysymään Scrum- rungon mukaiset kysymykset:

• Mikä meni hyvin, mitä jatketaan seuraavassa sprintissä?
• Miten voimme seuraavassa Sprintissä olla nopeampia, mitä esteitä kohdattiin?
• Onko jotain, jonka voimme jättää kokonaan tekemättä, mikä on jätettä tai järkevää ulkoistaa?

 

Ensimmäisessä sprintissä (tarkoitan tässä nyt sprintillä tapaamista) on tarkoitus keskustella tiimin eri rooleista ja nimetä Scrum- master sekä tuotepäällikkö. Ensimmäinen Scrum- tapaaminen eroaa lähes täysin siitä, mitä ainakin itselläni on kokemusta/ajatusta projektin aloittamisesta. Tapaamisessa ei siis määritetä dead-lineja tai yksityiskohtaisia suunnitelmia. Ajatus perustuu siihen, ettei uusi tiimi voi tietää uudessa projektissa toimintanopeuttaan ennen kuin on aloittanut tekemisen ja määritellyt sen. Alussa on siis hyvä myös määritellä jokin mittari toiminnan nopeuden kartoittamiseksi.

 

Ihminen on ilmeisen huono arvioimaan mitään mututuntumalta noin yleisesti. Siksi Sutherland kehottaakin ennemminkin vertailemaan eri vaatimustasoisia projektin paloja toisiinsa. Ihmiset ovat hyviä manipuloimaan ja manipuloitumaan, joten yksi tapa voi olla äänestää, vaikka pelikorteilla kuvapuoli alaspäin ja laskea keskiarvo kullekin tehtävälle. Jos tiimiläisten arviot eroavat kovasti, on tietysti hyvä pyytää perustelut. Tässä syy omaan ihastumiseeni tiimityöhön: joku osaa aina ajatella jotain minkä itse on täysin sivuuttanut.

 

Takaisin asiaan…

Joka Sprintissä määritellään, mitä pitää tehdä seuraavan jakson aikana. Tehtävät laitetaan ylös ja laitetaan ne tärkeysjärjestykseen. Tähän löytyy nykyään jo useitakin sovelluksia apuun, mutta yksinkertaisimmillaan Scrum-board voi olla paperi seinällä jossa on tarralappuja. Tehtävät voidaan esimerkiksi värikoodata tärkeysasteen mukaisesti tai laittaa vaikka numeerisesti tai mitä tiimi pitääkään parhaana. Sen jälkeen voidaan vaikka määrittää mikä tehtävä vie minkin pistemäärän aikaa. Scrum- seinä jakautuu lisäksi kolmeen eri osaan. Do, Doing, Done eli tehtävälistalla, tekemisen alla, tehty. Tämä lauta (oli se sitten sovelluksena tai seinällä) on koko projektin ajan koko tiimin, sekä sidosryhmien nähtävillä. Kaikki tietävät reaaliaikaisesti koko ajan mitä on tekeillä ja mitä tehty. Projektialusta on siis yksi tärkeimmän Scrumin arvon ylläpitäjä. Läpinäkyvyyden.

 

Tehtävien tärkeysjärjestystä kannattaa lähteä hakemaan kysymällä: ”Mikä tuo minulle eniten arvoa pienimmällä vaivalla?”. Tarkoituksena on, että fyysisiä tuloksia lähdetään tuottamaan heti alusta alkaen. Sillä tavalla Scrumissa tuotetaan arvoa ja annetaan varmuutta toimeksiantajalle suunnitelmien sijaan. Jos esimerkiksi kehitetään uutta tuotetta, luodaan mahdollisimman nopeasti demoja. Demojen avulla on ainoa luotettava tapa esimerkiksi tietää mitä asiakas oikeasti haluaa. Ei ole harvinaista, että asiakas luulee tietävänsä mitä haluaa muttei tiedä, mieli muuttuu matkalla tai tulee väärinymmärryksiä. Näytteillä ja jatkuvalla yhteydenpidolla asiakkaaseen vahvistetaan siis se, että tuote on todellakin lopulta se mitä halutaan saavuttaa, tai että sille on kysyntää.

 

Minulle tuotti jotenkin vaikeuksia ajatella, miten tämä yhteys asiakkaaseen käytännössä toimii, joten esimerkki lienee paikallaan:

• Nykyään varsinkin pelimaailmassa on yleistä, että uuden, esimerkiksi tietokonepelin, kehitysvaiheessa demoversio laitetaan heti esimyyntiin, kun mahdollista. Tämä mahdollistaa jatkuvan asiakaspalautteen jo heti pelin kehityksen alkuvaiheessa ja tuotanto kohtaa kysynnän. Pelaajat ja koodarit kehittävät pelin yhdessä lopulliseen päämäärään.

Jos ollaan kehittämässä jotakin aineettomampaa, Scrum- alusta antaa hyvän kuvan edistymisestä. Vaikka tapahtuman järjestämisessä. Tehtyjen asioiden lista kasvaa. Kuitenkin tapahtuman järjestämisessäkin on hyvä tehdä välillä ”demoja”, esimerkiksi luonnoksia teemasta. Ja tässä on hyvä muistuttaa, että tehty asia on ainoastaan loppuun asti suoritettu tehtävä. Puoliksi haravoitu piha ei ole valmis.

 

Vaikka ajatusmallin mukaan tiimi on yhdenvertainen, on silti hyvä asettaa vastuuhenkilöitä. Näitä alkuperäisen mallin mukaan kutsutaan Scrum-masteriksi ja tuotepäälliköksi. Suuressa projektissa on varmaankin kaikkien edun mukaista valita näihin rooleihin pienemmät tiimit.

Scrum-master:

Scrum-masterin tehtävänä on ylläpitää hyvää pöhinää. Sprint- tapaamisissa hän esittää tarvittaessa kysymykset eteen pääsemiseksi, muttei määrää suuntaa. Hän on tiimin valmentaja. Johtajan roolissa hän huolehtii Scrum-pöydän ylläpidosta (vaikka toki tämä on myös kaikkien tiiminjäsenten vastuulla). Usein tämä henkilö on myös vastuussa tiimin määrittelemien ongelmien poistamisesta ja toimii myös tuotekehittäjän ja tiimin välikätenä. Scrum-master ja tuotepäällikkö tekevät tiivistä yhteistyötä.

Tuotepäällikkö:

Tuotepäällikkö on henkilö, joka on yhteyksissä toimeksiantajaan. Hän pitää huolen siitä, että tiimi tietää mitä toivotaan ja pitää projektin oikeassa kurssissa. Tuotepäällikkö toimii ikään kuin puhemiehenä tiimin ja toimeksiantajan/asiakkaiden välillä. Demoja kehitellessä hän myös kerää asiakaspalautteen ja tarvittaessa muuta dataa markkinoiden selvittämiseksi.

 

Näillä tiedoilla toivon, että jokainen pystyisi kokeilemaan Scrumia!

1. Kerää tiimi.
2. Lataa sovellus (löytyy ainakin Google Playsta hyvin hakusanalla Scrum).
3. Valitkaa yhdessä Scrum-master ja tuotepäällikkö.
4. Päättäkää mitkä työn osaset tuovat projektille pikaisimmin arvoa ja aloittakaa niistä.
5. Valitkaa työkalut (esimerkiksi vertailemalla luotu pisteytys) työn tehokkuuden arviointiin
6. Mitatkaa, keskustelkaa, kehittäkää, nopeuttakaa. Älkää ikinä kuvitelko että toimitte juuri nyt parhaalla mahdollisella tavalla. Change or die.

 

Uskon, että varsinkin erittäin suurissa projekteissa ja tuotekehityksessä tämän menetelmän avulla päästään erittäin hyviin tuloksiin. Miksei kuitenkin myös ihan oman elämän hallinnassa. Tällä hetkellä Scrum on yleisimmin käytössä nimenomaan teknologia-aloilla. (Tivi, hipsterikehittäjät elävät Scrum- kuplassa)

Sain myös Timolta vinkkiä Leanin ja Scrumin yhdistämisestä. Siitä siis lisää seuraavassa jaksossa.

 

 

 

 

 

 

Lisää tietoa löydät:

 

Sutherland Jeff. Scrum – The art of doing twice the work in half the time. 2016. Random House, UK.

 

Reason.com, 06.01.2009: Would you have been a nazi? Katsottu 10.9.2017.

http://reason.com/archives/2009/01/06/would-you-have-been-a-nazi

 

Jared Brox, 04.08.2015: 4 essential characteristics of a succesful team. Katsottu 5.9.2017.

http://www.refreshleadership.com/index.php/2015/08/4-essential-characteristics-successful-team/

 

Aleksi Kolehmainen, 14.04.2016: Hipsterikehittäjät elävät Scrum kuplassa. Katsottu 10.9.2017.

http://www.tivi.fi/Kaikki_uutiset/hipsterikehittajat-elavat-scrum-kuplassa-6541251