Agile ja ketterät menetelmät – pelkkää sanahelinääkö?

Mehän olemme jo ketteriä

Heikki oli vetänyt projektia aikataulussa ja budjetissa puolivälin krouviin asti. Määrittelyt oli saatu valmiiksi jopa aikataulusta edellä. Projektin ohjausryhmä nyökytteli joka toinen viikko tyytyväisenä Heikin raporteille etenemisestä. Hän oli tehnyt arkkitehdin kanssa huolelliset työmääräarviot ja riskikartoitukset, joten mikäs siinä oli ollessa? Projekti oli myös päätetty yksissä tuumin asiakkaan kanssa tehdä ketterästi. Etukäteen sovitun ja määritellyn sisällön toteutus ja toimitus olikin ositettu ja aikataulutettu pienempiin paloihin.

Pari kuukautta ennen sovittua julkaisuajankohtaa alkoivat ensimmäiset tummat pilvet hiipiä taivaalle.

Pyöriteltyään viimein kahta avainominaisuutta testiympäristössä asiakkaalle valkeni, etteivät ne olleet lainkaan sitä mitä he halusivat! Tiimin ja asiakkaan käsitys ominaisuuksien sisällöstä erosivat kuin yö ja päivä. “Paperilla tämä oli niin selvää”, Heikki harmitteli.

Lisäksi viimeisimmän toimituksen katselmoinnissa sekä Heikille, tiimille kuin asiakkaan projektipäällikölle Jounille selvisi, että he olivat kaikki ymmärtäneet yhden kriittisen käyttäjätarpeen väärin. Heikki ja Jouni onnistuivat pääsemään lopulta kivuliaaseen kompromissiin muuttuneen tilanteen kustannusvaikutuksista. Aikataulu sen sijaan oli enemmän kuin vaakalaudalla. Sovittua sisältöä oli jäljellä vielä riittämiin ja julkaisuhetki, joka oli suunniteltu markkinan tämän vuoden merkittävimpien messujen ajankohtaan, lähestyi vääjäämättä. Tämä tiesi tiimille pitkiä iltoja. Tarvitseeko tarinan mennä näin? Ei välttämättä.

Ketterä lähestymistapa projekteihin on paras riskienhallintastrategia tähän mennessä

Monimutkaisten tietojärjestelmien kehitystyö on kompleksi, epädeterministinen ongelma, jossa ei etukäteen tiedetä, mikä tulee olemaan paras lopullinen ratkaisu. Tehokkain vastaus tällaiseen haasteeseen on ns. empiirinen lähestymistapa. Siinä pikkutarkan ja etukäteen tehdyn suunnitelman – eli arvauksen – sijaan visioidaan tavoite (saavutettavissa oleva asiakasarvo) ja lähdetään rakentamaan ratkaisua pala kerrallaan (inkrementaalisesti) täsmentäen sitä käyttäjäpalautteen ja tehdessä opitun perusteella (iteratiivisesti).

Jokaisen iteraation tarkoitus on tuottaa arvoa jo itsessään, mutta yhtä tärkeänä se myös lisää tietoa itse ratkaistavasta ongelmasta: arvo = asiakasarvo + tietoarvo. Tällä tiedolla vähennetään riskejä sekä ohjataan tulevaa tekemistä. Päätökset perustuvat siis faktoihin, palautteeseen ja tehdessä opittuun, eivät pelkkiin suunnitelmiin, jotka usein on tehty vaiheessa, jossa koko ongelmasta tiedettiin vähiten.

Tällaisessa hankkeessa käytettävän toimintamallin tulee siis ennen kaikkea varmistaa systemaattinen oppiminen riittävän tiheiden palautekierrosten avulla ja lisääntyvän tiedon perusteella kyky tehdä muutoksia alkuperäiseen suunnitelmaan. Yksi tapa mieltää ketterä lähestymistapa on perinteisen projektikolmion kautta, joka ketterässä lähestymistavassa kääntyy päälaelleen:

Ketterä ja arvovetoinen lähestyminen vaatii uudenlaista ajattelua

Heikin kollega, Petri, oli kantapään kautta tullut perehtyneeksi miten hahmottaa projektin toimintaympäristöä ja lähestyä kompleksisia ongelmia. Petri oli saanut perusteltua omassa projektissaan asiakkaansa kuinka riskialtista on lukittua ratkaisuihin liian aikaisin pelkkien olettamusten varassa. Petrin johdolla oli pohdittu; mitä ongelmaa oikeasti oltiinkaan ratkaisemassa ja mistä ratkaisun vaikutus havaitaan?

Edelleen projektiryhmässä analysoitiin olettamuksia siitä, millä tuotoksilla tavoitteeseen voitaisiin päästä. Näistä ei kuitenkaan lukittu ostoslistaa, vaan alustava julkaisusuunnitelma. Projektiryhmä jalosti julkaisusuunnitelman edelleen niin sanotun tarinakartan muotoon, joka havainnollisti vaakasuuntaan suunnitelman leveyden (tuotosten ja ominaisuuksien määrä) ja pystysuuntaan suunnitelman syvyyden (ominaisuuksien monimuotoisuuden).

Projektin puolimatkassa yksi alussa tehty olettamus osoittautui täysin vääräksi loppukäyttäjien käyttäytymisen perusteella.

Tämän johdosta kyseistä ominaisuutta ei tehty alkua pidemmälle vaan tiputettiin kokonaan pois. Heikki arvioi yhdessä muun projektiryhmän kanssa tämän tiedon pohjalta vaikutukset julkaisusuunnitelmaan. Tuloksena suunnitelmaa päivitettiin ja opitun perusteella yksi kolmesta avainominaisuudesta muuttui melkoisesti ja kahden muun ominaisuuden keskinäinen järjestys vaihtui.

Seuraavien viikkojen ahkera työ avainominaisuuksien parissa heilautti projektin tavoitteeseensa valittujen mittareiden mukaan. Koska haluttu vaikutus oli saavutettu, projektin ohjausryhmä päätti jättää loput ominaisuudet tekemättä ja käyttää säästyneen budjetin seuraavaan hankkeeseen.

Kuinka hyvin sinä näet tulevaisuuteen?

Pelkästään pilkkomalla etukäteen määritelty sisältö pienempiin osiin ja julkaisemalla näitä säännöllisesti saadaan toki perinteistä vesiputousprojektia parempi näkyvyys etenemiseen. Tämä antaa myös ainakin teoriassa mahdollisuuden muuttaa suuntaa opitun pohjalta. Käytännössä tämä voi olla kuitenkin mahdotonta, tai ainakin vaikeaa, jos sisältö on sovittu ja kenties jopa hinnoiteltu etukäteen.

Oikeasti ketterä, empirismiin perustuva lähestymistapa on sen sijaan erittäin tehokas suoja riskejä vastaan.

Se ohjaa miettimään hanketta tavoite- ja vaikutuslähtöisesti ja jättää sinulle riittävästi pelimerkkejä pöydälle. Osaatko sinä ennakoida asiakkaidesi käyttäytymisen niin hyvin, että uskallat panostaa kaikki pelimerkit kerralla yhdelle ratkaisulle?

Mikäli kaipaat apua, ota rohkeasti yhteyttä! Varmistetaan yhdessä, että sinun projektisi sujuu kuten sen pitääkin.