Ketterät menetelmät eivät toimi ilman ketteriä periaatteita. Jos oikeasti haluaa onnistua ketterässä projektissa, vaatii se ehdottomasti työkulttuurin muutoksen.
Suurin osa nykypäivän IT-projekteista mainostaa itseään ketterillä menetelmillä tehdyksi projektiksi. Menetelmissä – kuten Scrum tai Kanban – itsessään ei ole mitään vikaa, mutta ongelma on enemmän siinä, että niitä suoritetaan menetelmän kautta, ei periaatteiden. Hyvin helposti joku saattaa pyörittää Scrumia vesiputousmallisesti, tai tehdään pieniä vesiputousmallisia sprinttejä. Sitten kun asiat eivät toimikaan, niin syytetään menetelmää. Ja ehkä se suurin ongelma on, että projektitiimin ulkopuolella toimitaan edelleen “niin kuin ennen”.
Jos oikeasti haluaa onnistua ketterässä projektissa, vaatii se ehdottomasti työkulttuurin muutoksen. Tämä ei koske pelkästään projektitiimiä, vaan kaikkia siihen liittyviä sidosryhmiä. Jos projekti haluaa onnistua, vaatii tämä osaavan ketterät menetelmät ja periaatteet tuntevan projektipäällikön sekä Scrum Masterin. Liiketoiminnalliset vaatimukset ymmärtävän tuoteomistajan pitää lähtökohtaisesti tulla tilaajalta ja erityisesti hänen pitää ymmärtää ketterien menetelmien periaatteet. Nostan tässä blogissa esiin muutamia tärkeimpiä ketterän projektin periaatteita. Voit käydä kaikki 12 tiivistettyä periaatetta läpi Agile manifeston sivulta.
Asiakasarvo ennen kaikkea
Ketterien periaatteiden ydin on asiakasarvon tuottaminen. Jokainen päätös, jokainen kehityssykli ja jokainen sprintti on suunnattu asiakkaan tarpeiden täyttämiseen ja arvon maksimoimiseen. Scrumissa tämä näkyy tuotebacklogin priorisoinnissa, kun taas Kanbanissa se ilmenee jatkuvana työn virtauksena, joka vastaa asiakkaan muuttuviin vaatimuksiin.
Nämä asiat eivät kuitenkaan tarkoita sitä, että työtä voi aina vain lisätä muuttuvien vaatimusten takia. On osattava sanoa EI vähän arvoa tuottaville asioille, jotta voi sanoa KYLLÄ eniten siinä hetkessä arvoa tuottaville asioille. Ketterä projekti on siis jatkuvaa tekemättömän työn maksimointia.
Asiakasarvossa on myös ymmärrettävä mitä asiakkaalla tarkoitetaan: onko se järjestelmän tilannut asiakas, vai järjestelmän lopullisena käyttäjänä toimiva asiakas. IT-hankkeissa keskitytään liiaksi tilaavan organisaation haluun tehdä asioita, eikä selvitetä kunnolla mitä järjestelmän lopulliset käyttäjät järjestelmältä haluavat. Tehdään paljon tuotoksia ilman tulosta (outcome, ne toiminnot jotka tuottavat loppukäyttäjille eniten hyötyä). Tästä seuraa yleensä vain sanomista, jos järjestelmää ei suunnitella ja toteuteta loppukäyttäjiä varten.
Ihmiset ja vuorovaikutus prosessien yli
Ketterät periaatteet korostavat ihmisten välistä vuorovaikutusta ja tiimityötä. Vaikka Scrumissa on määritelty roolit ja Kanbanissa keskitytään työn visualisointiin, molemmat menetelmät nojaavat avoimeen kommunikaatioon ja tiimin jäsenten väliseen luottamukseen. Tässä pitää myös muistaa se, että tiimillä on hyvä ja läpinäkyvä yhteys kaikkiin tarvittaviin sidosryhmiin. Ketterässä maailmassa prosessit ovat tärkeitä, mutta ihmiset tekevät lopulta työn ja ovat tärkeämpiä.
Scrumissa myös tiimit saattavat ymmärtää Scrumin tapahtumat väärin ja niistä tulee helposti raportointipalavereita. Näissä erottuvat myös helposti tiimit ja ryhmät toisistaan. Tiimissä kaikilla on yhteinen tavoite, ryhmä taas keskittyy jokainen vain omaan asiaansa.
Jokainen scrumin tapahtuma on paikka, jossa ihmiset voivat edistää yhteisen tavoitteen saavuttamista, oppia jotain ja parantaa asioita. Hyvä Scrum master osaa huolehtia, että näin käy.
Reagointikyky muutokseen
Muutos on ainoa vakio, ja ketterät periaatteet tunnustavat tämän. Me emme tunne sitä, mitä emme tunne (unknown unknowns). Menetelmät, kuten Scrum ja Kanban, ovat joustavia ja sallivat muutokset suunnitelmissa, jotta voidaan vastata nopeasti ulkoisiin muutoksiin. Tämä reagointikyky on elintärkeää nykypäivän nopeatempoisessa liiketoimintaympäristössä.
Muun muassa käyttäjien tarpeiden ja lainsäädännön muutokset, tai tietoturvahyökkäykset ovat asioita, joita ei voida tietää etukäteen. Lisäksi järjestelmät sisältävät niin monta yksityiskohtaa, jotka riippuvat toisistaan, että kukaan ei pysty määrittelemään kaikkea etukäteen. Toki erilaisilla käyttäjätutkimuksilla ja protoilla voidaan varsinkin käyttäjien tarpeita testata ennen toteutusta ja tämä onkin järkevää, mutta ongelma piilee yleensä etukäteen tuntemattomissa yksityiskohdissa.
Näihin voidaan kyllä varautua, mutta ei tiedetä etukäteen milloin, missä ja miten jokin tapahtuu.
IT-projekteissa tällainen muutos on jatkuvaa, eikä siltä oikein voi välttyäkään. Tämän takia jokainen muutos ja sen vaikutus kokonaisuuteen pitää tarkasti harkita. Niissä päätäntävalta ja vastuu on lähes aina tuoteomistajalla. Nämä muutokset ovat myös monen IT-projektin turma ja oman bloginsa arvoinen asia, joten siitä myöhemmin lisää. Vaikka asiakkaan tuoteomistaja vastaa sisällöstä ja muutoksien aiheuttamista haasteista, on osaavalla projektipäälliköllä ja Scrum Masterilla tässä myös suuri merkitys.
Yksinkertaisuus
Ketterät periaatteet kannustavat yksinkertaisuuteen – tekemään vähemmän, mutta paremmin ja arvoa tuottavasti. Netumin arvojen mukaisesti viisaasti.
Tämä on myös yksi haastava tekijä kompleksisessa ympäristössä. Monesti asiakas tuo tiimille ratkaisuehdotuksen, joka ei ole kaikista yksinkertaisin ongelman ratkaisemiseksi. Tämäkin on enemmän työnjohdollinen haaste, kuin se, että kehitystiimi ei saa tarpeeksi nopeasti asioita valmiiksi. Antamalla tiimin päättää miten ongelma ratkaistaan päästään lähtökohtaisesti parhaaseen ratkaisuun, niin teknisesti, kuin kustannusmielessä. Yksinkertaisin ratkaisu on aina halvin, nopein ja sisältää vähemmän virheitä.
Jatkuva parannus
Ketterät periaatteet eivät ole staattisia; ne edellyttävät jatkuvaa parannusta ja oppimista. Scrumissa retrospektiivit ovat keskeinen osa tätä prosessia, kun taas Kanbanissa jatkuva parannus on osa kulttuuria ja työn virtausta.
Kompleksiseen ympäristöön liittyy vahvasti se, että edes huippuasiantuntija tai tiimi ei välttämättä tiedä miten jokin asia tulisi ratkaista. Tämän takia kompleksisessa ympäristössä on paljon asioita, joita joudutaan kokeilemaan ja sitten ymmärretään miten jokin asia ratkaistaan parhaalla mahdollisella tavalla. Kokeiluihin liittyy läheisesti reflektointi ja siitä seuraa jatkuva parannus. Hyvä esimerkki tästä on kaikkien huulilla oleva tekoälyn hyödyntäminen. Emme me tule hyväksi tekoälyn hyödyntäjäksi ilman, että aktiivisesti kokeilemme asioita. Yrityksen ja erehdyksen kautta opimme paremmiksi. Samalla meidän pitää myös muistaa oppia vanhasta pois (unlearning). Jos emme opi pois vanhasta, emme voi käyttää täydellä teholla uusia oppejamme.
Kompleksista projektia johtavan on pakko hyväksyä jatkuva epävarmuus ja muutos. Sen takia projektin tulee tarkastella toimintaansa jatkuvasti ja reagoitava sen mukaan. Tämä vaatii projektipäällikön tukea sekä osaavan Scrum Masterin tiimeineen.
Lopuksi
Nämä periaatteet ovat ketterien menetelmien sydämessä. Ne ohjaavat meitä luomaan parempia tuotteita, palvelemaan asiakkaitamme paremmin ja työskentelemään tehokkaammin tiiminä. Kun ymmärrämme ja omaksumme nämä periaatteet, voimme hyödyntää Scrumia, Kanbania ja muita ketteriä menetelmiä niiden täydessä potentiaalissa.
Toisin sanoen: tunnista projektisi toimintaympäristö, perehdy erilaisiin menetelmiin ja niiden takana oleviin periaatteisiin ja vasta sitten valitse sopivin työkalu projektiisi. Jos haluat jutella aiheesta lisää, ole yhteydessä.
