Agile-ohjelman rakentaminen kesken kasvun

Nykyaikaisiin hankkeisiin on tarjolla lähes rajattomasti malleja ja kehyksiä onnistumisen tueksi, mutta yksikään niistä ei tee päätöksiä puolestasi silloin, kun peli menee odottamattomaksi. Onnistuminen syntyy ihmisten yhteistyöstä ja siitä, miten hyvin rakenteet tukevat ihmisten osaamista ja johtamista.

Jatkuvat epäselvyydet haastavat hankkeita monesta suunnasta. Sisäisesti epäselviä kriittisiä kohtia voivat olla vastuut, priorisointi tai se, kuka päättää mistä. Ulkoisesti epäselvyyttä tuovat toimittajat, sidosryhmien odotukset ja ympäristön muutokset, joihin ei voi itse vaikuttaa. Yksittäinen epäselvyys on harvoin ongelma, mutta ne kertautuvat.

Epäselvyys lisääntyy myös positiivisten ongelmien kautta. Yksi tällainen myönteinen tekijä, joka kasvattaa epäselvyyttä, on hankkeen kasvu. Kun toimiva projekti laajenee useaksi projektiksi ja lopulta ohjelmaksi, vanhat toimintatavat eivät enää riitä ja uusi kokonaisuus tarvitsee uuden tavan toimia. Juuri tällaisessa tilanteessa monimutkaisuus kasvaa nopeammin kuin rakenteet ja ilman tietoisesti rakennettua johtamista tilanne muuttuu nopeasti hallitsemattomaksi.

Miten sitten toimivat uudet rakenteet tehdään? Esitellään hyvää lähestymistapaa keksityn case-kuvauksen kautta. Tämä ei ole kuvaus yksittäisestä asiakkuudesta.

Lähtötilanne: kolme syytä uudistaa

Otetaan esimerkiksi yritys, keskisuuri vähittäiskauppaketju, joka päättää uudistaa verkkokaupan ja varastonhallinnan taustajärjestelmänsä. Uudistuksen taustalla on kova halu tuoda tekoälyn käyttö vahvasti mukaan omaan liiketoimintaan ja pyrkiä hankkimaan sillä aitoa kilpailuetua. Vanha ERP on rakennettu yhden ulkoisen tuotteen ja sen toimittajan varaan ja tästä kokonaisuudesta muodostuu kolme ongelmaa.

Ensimmäinen on riippuvuus. Jokainen muutos kulkee tuotetoimittajan kautta, eikä vaihtoehtoja ole. Kyseessä on legendaarinen vendor lock, tilanne, joka ei tuo etua asiakkaalle ja kasvattaa yrityksen hallitsemattomia riskejä.

Toinen on hitaus: muutostarpeet jonottavat ja aikataulut venyvät kuukausiin. Pahimmillaan tuotetoimittaja tekee releasen vain kaksi kertaa vuodessa. Ja usein kaivatut muutokset eivät edes tule valituksi releaseen ja näin päädytään odottamaan vielä lisää.

Kolmas on joustamattomuus. Käytössä oleva järjestelmä ei taivu siihen, miten nopeasti tekoälyavusteiset työkalut muuttavat sekä asiakaskokemusta että sisäisiä prosesseja. Tämä ei ole linjassa yrityksen tarpeiden kanssa ja vaarantaa oman strategian.

On aika tehdä muutos.

Ensimmäinen projekti perustetaan selvittämään lähtökohtia ja luomaan pohja. Se toteutetaan konkreettisella ja rajatulla projektilla, jolla uusitaan ERP:n toimintaan liittyvä tietty osa-alue eli palanen. Kun pohja on pystyssä, hanke laajenee noin kahdeksassa kuukaudessa viiteen rinnakkaiseen projektiin. Mukaan astuu eri toimittajien tiimejä, eri painotuksia, ja tavoitteena on silti yksi yhteinen suunta.

Kun projektit alkoivat elää omaa elämäänsä

Luonnollinen kasvu näkyy ensin hajanaisuutena. Jokainen projekti etenee omalla logiikallaan, ikään kuin viisi erillistä hanketta olisi sattunut jakamaan saman budjettirivin.

Tekoälyä hyödynnetään kukin omalla tavallaan. Yksi tiimi automatisoi testausta, toinen kokeilee tekoälyavusteista koodikatselmointia, kolmas ei ole ehtinyt miettiä asiaa lainkaan. Kun yksi projekti ratkaisee hankalan teknisen ongelman, tieto ei liiku eteenpäin, ja sama pulma saatetaan ratkoa uudelleen kuukautta myöhemmin toisessa tiimissä. Samaan aikaan palaverien määrä kasvaa, varsinkin avainhenkilöillä, kun jokainen hanke haluaa vastauksia yksittäisiin kysymyksiinsä.

Riippuvuuksia ei hallitse kukaan kokonaisuutena. Riskejä arvioidaan vain oman projektin näkökulmasta, joten ohjelmatason riski nousee esiin vasta, kun se on jo ongelma usealle tiimille yhtä aikaa.

Yhteinen rytmi ei synny itsestään

Ratkaisu ei ole yksi iso prosessi vaan muutama kevyt, toistuva käytäntö, jotka yhdessä luovat ohjelmalle selkärangan.

Yksi ensimmäisistä uusista toimintatavoista on inkrementtisuunnittelu. Kuukausittainen suunnittelu kokoaa kaikki projektit saman pöydän ääreen sopimaan jakson yhteisestä suunnasta ja tavoitteista mieluummin kuin pienistä yksityiskohdista. Tavoitteena on rakentaa yhtenäisyyttä eri projektien välillä ja osoittaa, kuinka jokainen palanen muodostaa merkityksellisen osan kuukauden tavoitteesta. Tämän jälkeen on helppo jakaantua katsomaan tarkemmin oman projektin suunnittelua.

Arkkitehtuuri weekly-meeting tuo jokaisen projektin pääkehittäjän ja ohjelman pääarkkitehdin viikoittain samaan keskusteluun. Riippuvuudet ja tekniset ristiriidat nousevat esiin ennen kuin ne ehtivät kasvaa esteiksi ja jokainen projekti pysyy ajan tasalla muiden tekemisestä. Tätä suunnittelua pyöritetään etupainotteisesti, jotta tulevat suunnitelmat etenevät niin, että esteet on jo raivattu ja kysymyksiin vastattu.

Kaikki dokumentaatio, weekly-meetingin muistiinpanot mukaan lukien, kootaan yhteiseen wikiin. Siihen liitetään tekoälyavusteinen tiedonhaku ja yhteenvedot, joten kukaan ei enää kaiva tietoa viidestä eri paikasta. Kaikki tieto on jatkuvasti kaikkien saatavilla ja ennen kaikkea helposti haettavissa ja tekoälyn käytettävissä. Samoin kuin kaikkien projektien suunnitelmat ja speksit.

Inkrementtien loppuun perustetaan uusi yhteinen demosessio. Tässä demossa kaikki projektit esittelevät oman työnsä samassa tilaisuudessa. Se tiivistää aikataulua ja se luo ohjelmalle yhtenäisyyttä. Tavoitteena on myös avoimuus: kenen tahansa on helppo nähdä, missä muut menevät. Tavoitteena on jatkuvasti tuoda esille konkreettisten esimerkkien kautta, mitä kukin projekti on saavuttanut omalla palasellaan.

Eniten arkea helpottaa pre-refinement. Pieni ydinjoukko kustakin projektista, eli pääkehittäjä, Product Owner ja testauksen edustaja, ratkoo esteet keskenään ennen suunnittelusessiota. Ilman tätä suunnittelupalaverit venyvät ja ovat tehottomia. Nyt isossa porukassa puhutaan enää siitä, mikä oikeasti vaatii yhteistä päätöstä.

Kuukausisuunnittelu antaa suunnan, pre-refinement raivaa esteet ja kaikki tiimit etenevät kahden viikon sprinteissä. Demo päättää jakson ja arkkitehtuuri weekly-meeting sekä wiki pitävät tiedon liikkeessä koko ajan.

Kompromissit, ei täydellisyyttä

Eri toimittajien tiimit tuovat mukanaan omat tapansa, mutta ohjelma tekee tietoisen valinnan: kaikki toimivat samassa muotissa. Alusta asti kaikki tiimit työskentelevät kahden viikon sprinteissä ja yhteinen rytmi rakennetaan niiden varaan.

Yhtenäinen sprinttirytmi tekee yhteisistä kiinnekohdista mahdollisia. Kuukausisuunnittelu, arkkitehtuuri weekly-meeting ja demo osuvat kaikille samoihin kohtiin, eikä kenenkään tarvitse sovittaa omaa aikatauluaan toisten mukaan. Vastineeksi tiimien oma liikkumavara kapenee: jokaisen on mukauduttava samaan tahtiin.

Ensimmäinen kuukausisuunnittelu paljastaa, että koko väen kutsuminen ei toimi: istunnosta tulee kuuntelutilaisuus, jossa suurin osa odottaa omaa vuoroaan. Osallistujat rajataan avainrooleihin ja yksityiskohdat siirtyvät pre-refinementiin. Yhteinen demo on aluksi liian pitkä, koska jokainen projekti esittelee kaiken. Sen jälkeen näytetään vain se, mikä on valmistunut ja mikä on muuttunut.

Rytmi ei ole valmis malli vaan jatkuvasti säädettävä kompromissi. Jokainen käytäntö saa mahdollisuuden osoittaa hyötynsä, ja se, joka ei vähennä kitkaa, lopetetaan.

Ohjelmataso antaa suunnan, kokoaa riippuvuudet ja tuo valmiin työn näkyviin. Projektit tekevät työn kahden viikon sprinteissä, ja wiki pitää tiedon kaikkien saatavilla.

Mitä tästä jää käteen

Rakenne syntyy muutamassa kuukaudessa. Aikaa ei ole paljon ja se pakottaa valitsemaan riittävän hyvän täydellisen sijaan: kevyt kuukausisuunnittelu ennen raskasta portfoliotyökalua, wiki ennen täydellistä tietojärjestelmää ja pre-refinement ennen muodollista prosessimallia.

Hyödyt näkyvät arjessa. Yhteinen suunta ohjaa kaikkia projekteja samaan tavoitteeseen, ja riippuvuudet ja riskit nousevat esiin ajoissa. Ratkaisut ja tieto kulkevat projektien välillä, joten samaa ongelmaa ei ratkota kahdesti. Asiantuntijoiden aika vapautuu itse tekemiseen, kun yhteiset palaverit keskittyvät vain siihen, mikä vaatii yhteistä päätöstä. Lisäksi ohjelman tila on kaikkien nähtävillä, ja yhteinen tietopohja antaa myös tekoälylle hyvän lähtökohdan auttaa.

Rakenteen tuominen ohjelmaan onnistuu pienin askelin ja hyödyt ovat suuret: tehokkuus ja mielekkyys kasvavat. Yhtä oikeaa tapaa tai prosessia ei ole, vaan jokaiselle löytyy varmasti oma tapansa erilaisista mahdollisuuksista. Jos haluat jutella aiheesta lisää ja keskustella omista kokemuksista tai tarpeista, minuun voi ottaa yhteyttä. Keskustelen mielelläni lisää.

Teemu Sevon