Kokeileminen on ketterää

Ketterä toimintatapa rantautui Suomeen 2000luvun alussa, kun ensimmäiset ohjelmistoja kehittäneet tiimit kokeilivat Scrum-mallia. Toimintamalli kuulosti varsin houkuttelevalta, kun ketterän filosofian painotukset käännettiin toisilleen vastakkaiseksi. Yksilöiden, kommunikaation, asiakasyhteistyön, muutokseen reagoimisen ja toimivan ohjelmiston korostaminen yli prosessien, työkalujen, kattavan dokumentaation, sopimusneuvottelujen tai suunnitelmien noudattamisen ei kuitenkaan ole tarkoitettu toisiaan poissulkeviksi.

Kun ketterään malliin lähdetään, tapahtuu lähes poikkeuksetta niin, että unohdetaan nuo ”tylsemmät” asiat ja lähdetään vain tekemään jotain hienoa palvelua asiakkaan kanssa. Tällä tavalla ei missään nimessä rakenneta mitään kestävää. Dokumentaatio ja sopimukset ovat ohjelmistojen elinkaarta ajatellen todella tärkeitä ja prosessit auttavat joissakin kohdissa toistamaan asiat samalla tavalla, jolloin vaikutus on laadun tasoittumisessa. Näkisin kuitenkin, että prosesseja ja suunnitelmia tärkeämpi on lopputulos. Tärkein päämäärä on, että julkaistaan palvelu, joka on asiakkaan tarpeiden mukainen, teknisesti kestävästi toteutettu ja liiketoiminnallisesti arvokas.

Tämä tylsempien asioiden unohtaminen on mielestäni myös merkki siitä, että koko ketterän kehittämisen mallin ideologia on mennyt ensimmäisillä oppitunneilla ohi. Toteuttajan näkökulmasta malli voidaan kääntää siihen, että ei suunnitella eikä dokumentoida vaan lähdetään vaan tekemään suoraan valmista palvelua. Liiketoiminta puolestaan on kuullut ketterän mallin tehokkuudesta ja näkee kustannussäästöjä, joilla liiketoiminta on kannattavampaa.

Molemmilla osapuolilla on siis väärät odotukset ketterästä toimintamallista. Ilman suunnittelua ja dokumentaatiota ohjelmistojen arkkitehtuuri, ylläpidettävyys ja jatkokehittäminen muuttuvat yhä monimutkaisemmiksi.

Kustannussäästöjä ohjelmiston kehittämisessä saa joko vähentämällä työtä tai tekemällä työn halvemmalla. Jos taas ajatellaan ohjelmiston koko elinkaarta, niin kehittämisvaiheen investoinneilla voidaan pudottaa loppulaskua. Viisas johto siis maksaa kehittämisvaiheessa vähän enemmän saadakseen kokonaiskustannuksen putoamaan.

Ketterän toimintamallin filosofia ei siis ole tylsien asioiden sivuuttaminen eikä kustannusten säästäminen, vaan se, että lopulta valmistunut ohjelmisto on markkinatilanteeseen sopiva. Ohjelmistot monimutkaistuvat koko ajan, kun asiakkaiden vaatimukset kasvavat. Palveluiden taso on usein jo todella korkealla, ja asiakkaat vertaavat palvelua aina muihin käyttämiinsä palveluihin – esimerkiksi pankkipalvelun hyvyyttä verrataan mm. Spotifyn tai Netflixin käyttäjäkokemukseen.

Ketterän filosofiassa ytimessä on kokeileminen ja asiakkailla testaaminen. Luodaan konsepti ja mietitään, että mitä ominaisuuksia kokonaisuudesta julkaistaan ensimmäisenä. Yleensä käytetään testiasiakkaita jo ennen julkaisua. Ensimmäinen hyvin rajoitetulla toiminnallisuudella julkaistu palvelu on ensimmäinen kokeilu. Tähän asti kaikki suunnittelu on ollut hypoteettista ja nyt nähdään, että onko osuttu oikeaan. Julkaisun yhteydessä kootaan myös järjestelmällisesti palautetta, jotta suuntaa voidaan tarvittaessa korjata ja saada jopa lisää ideoita markkinoilta.

Kun tätä kokeilevaa kehittämistä, mitä myös ketteräksi kehittämiseksi kutsutaan, jatketaan syklisesti ja lisätään prosessia helpottavia teknologioita (DevOps), päädytään lopulta tilanteeseen, jossa on markkinoilla liiketoiminnallisesti menestyvä tuote, minkä kehitysresurssina on koko asiakaskunta. Kehityksen sykli nousee niin nopeaksi, että kilpailijoiden on erittäin vaikea saavuttaa samaa tasoa, jos ei synny jotain täysin odottamatonta innovaatiota.

Voitko soveltaa em. periaatteita ja malleja muussakin toiminnassasi ja sen kehittämisessä?

Jukka Parkkinen

Johtaja OP Ryhmä, Kehittäminen ja Teknologiat/Kehittämisen Kyvykkyydet