Ketterät menetelmät olivat pieni askel oikeaan suuntaan

Eniten kritiikkiä alalla kohdistuu siihen, että ketterät menetelmät ovat käytännössä vähentäneet ohjelmistokehityksen menetelmällisyyttä. Menetelmiä ei siis noudateta käytännössä, eli ohjelmistotiimit jatkuvasti mukauttavat menetelmiä omien mieltymyksiensä mukaan, ja yleensä tämä tarkoittaa asioiden vähentämistä tai oikaisemista.

Esimerkiksi yksi hyvin yleinen ohitettava asia on niin sanottu valmiin määritelmä, jolla asetetaan laatustandardit eri toimintojen valmistumiselle ja teknis-toiminnalliselle laadulle. Hyvin moni ohjelmistotiimi ohittaa tämän asian käytännössä kokonaan, vaikka se on aivan keskeinen asia ketterässä toiminnassa. Ketteryydestä siis poimitaan lähinnä iteratiivinen etenemismalli ja tuotteen kehitysjono, mutta varsinaiset laadulliset (ja työläämmät) käytänteet ohitetaan.

Toinen varsin yleinen kritiikki kohdistuu tuloksiin. Moni ketterä kehityshanke tuntuu jatkuvan ikuisesti, eikä valmista tunnu syntyvän edes useiden vuosien koodaamisella. Tiimit eivät yleensä ole myöskään hyviä ennustamaan sitä, milloin tulee valmista, vaikka ennustettavuuden piti olla yksi ketteryyden merkittävistä edistysaskeleista. Tämä tietysti liittyy ensimmäiseen kohtaan, koska jos menetelmiä ei noudateta, ei prosessi tuota parempaa ennustettavuutta, kun tekemistä ei jatkuvasti arvioida kriittisesti suhteessa tavoitteisiin.

Kaikki tämä on tietysti hieman erikoista, koska Suomessakin on nähty viimeisen kymmenen vuoden aikana aivan käsittämättömän laaja sertifioitumishuuma, kun tuhannet asiantuntijat ovat sertifioineet itseään kilpaa erilaisiin ketteriin menetelmiin. Tästä massiivisesti sertifioitumisbuumista vaikuttavat kuitenkin lähinnä hyötyneet näitä sertifikaattikoulutuksia järjestäneet tahot, koska käytännön tekemiseen tällä sertifioitumisella ei tunnu olevan ollut kovin merkittävää vaikutusta.

Tai ehkä todellisuus olisi ollut vielä karmeampi, ilman sertifioitumista, kuka tietää.

Esimerkiksi ketterien menetelmien yksi kehittäjä Tom Gilb on todennut eri yhteyksissä, että ohjelmistoalalla ei ole vieläkään löydetty toimivia menetelmiä (esimerkiksi tässä YouTube-haastattelussa). Jos edelleen vain hyvin pieni osa ohjelmistohankkeista onnistuu, ja noin puolet hankkeista katsotaan selvästi epäonnistuneiksi, ei alan yleistilannetta voi mitenkään pitää hyvänä.

Tätä samaa asiaa on selvitetty Suomessakin eri yhteyksissä. Esimerkiksi tässä gradussa (Korpelainen 2021) haastateltiin kokeneita ohjelmistoarkkitehtejä eri ohjelmistoyrityksistä, ja todettiin, että vain muutama haastatelluista käytti joitain formaaleja mallinnusmenetelmiä työssään. Suurin osa kommentoi ohjelmistokehityksen tapahtuvan enemmän tai vähemmän ilman mitään formaalia mallinnusta ja prosessia, lähinnä kollegoiden kanssa keskustellen ja keskittyen kulloinkin työn alla olevaan tehtävään tai sprinttiin.

Lainaus gradusta ja siinä tehdyistä haastatteluista:

Tiimityöskentelyyn liittyvinä haasteina esitettiin, että suunnittelua tai kokonaisuuden hallintaa ei pidetä tärkeänä, vaan painopiste on toteutuksessa. Haastattelujen perusteella tiimeissä ajatellaan, että ilmankin etukäteissuunnittelua lopulta päädytään hyvään lopputulokseen.

“…tällä alalla yleisesti edelleen mun mutu on semmonen, et kyllähän siellä on paljon sitä, että, et enempi niinku lähetään vaan tekemään -tyyppisesti ja ajatellaan, että se niin kun, homma siitä, siitä kyllä menee kuosiin…” (ratkaisujohtaja H3)

“…ei nähdä sitä kokonaisuuden hallintaa tärkeänä, vaan uskotaan, että kunhan vaan tehdään asioita, niin se jotenkin loksahtaa paikoilleen. (ratkaisuarkkitehti H9)

“..tää Scrum on se, että kun niitä ei mietitä laajemmin niitä asioita, niin se on ehkä, mistä mä en ite tykkää. Koska mä näin sen ajan, kun tehtiin vesiputousmallilla, et se mua vähän harmittanu, että niin kun mennään vähän laput silmillä. Ainakin nuoremmat kehittäjät, niin mä aina sanon, että kattokaa vähän kauempaa, että mitä te ootte tekemässä. — ne ei niinku ymmärrä, että mitä sillä niinku saavutetaan sillä jutulla laajemmin, mitä se asiakas saa.” (sovellusarkkitehti H12)

Ketterän kehityksen teoria ei tosiaan ole painottanut etukäteissuunnittelua koskaan, mutta on sillä aina jonkinlainen rooli ollut teoriassa. Alalla moni vain on tulkinnut tämän kohdan kenties itselleen parhaiten sopivalla tavalla, kuten gradun haastatteluissakin hyvin tulee ilmi.

Neljä arkkitehtiä mainitsi haasteena organisaatioiden halun saada koko ajan nopeammin ja nopeammin toimivaa ohjelmistoa ulos (keskitytään lyhyen tähtäimen hyötyihin). Vaatimukset koettiin välillä hyvin kohtuuttomina, kun tavoitteena kuitenkin oli laadukkaan ohjelmiston toimittaminen.

“Siihen se nykyisin menee, et ei piirretä enää niin tarkkoja kuvia, pitäs vaan saada sitä koodia ulos mahollisimman paljon. Se on ihan yleinen joka puolella, kaikki yritykset yrittää mahollisimman kevyesti, mahollisimman tota tehokkaasti ja poistaa kaikki overheadit. Ihan pahimmillaan menny siihen, että testaustakaan ei juuri enää ole. Mikä on tosi huono juttu. Ne nähään noista miten huonoja nuo ohjelmistot nykyisin on.” (ohjelmistoarkkitehti/-kehittäjä H1)

Kiirettä ja mallintamisen aliarvostamista ruokki haastateltavien mielestä ketterän kehityksen yleistyminen ja sen ymmärtäminen väärin.

“…on nähty, että kun tehdään ketterästi asioita, niin sillon ei tarvis mallintaa asioita, mikä ei ollu kyllä Scrumin ja agiilin, ketterän kehityksen mukaista alun perinkään, mutta sitä on käytetty sitten semmosena tekosyynä, minkä takia ei tarvii mallintaa ja dokumentoida asioita.” (ratkaisuarkkitehti H9)

Me hyvin harvoin kehitämme mitään räjäyttävän todella uutta. Useimmitenhan IT:ssä tehdään asioita, tehdään nyt vaikka ne ostolaskut, niitä on kuule tehty kymmeniä vuosia ennenkin. — ketteryys vetäs näistäkin kehitysjutuista, joissa se tiedonjakamisen takia riittävä mallintaminen on aina ollut tarpeen, niin vähän mentiin ehkä siinä yli. (projekti- ja palvelupäällikkö H4)

“Mää uskon ainoostaan niinku arkkitehtuurilähtöiseen ohjelmistokehitykseen. Se on ainoo, minkä mää oon huomannu, että on 25 vuodessa tuottanu ees jollain lailla järkevää, koherenttia softaa. — No, otetaan vaikka tää agile mikä on mun suosikki-inhokki nykyään on se, että mitään ei tartte dokumentoida ja mitään ei tartte niinku tehä muuta kuin vaan lätkitään koodia pinoon, niin. Mut eihän se niin mee.” (ohjelmistoarkkitehti H2)

Alan menetelmällinen kehitys onkin ollut enemmän vuoristorataa kuin systemaattista etenemistä kohti parempia malleja. Mutta onneksi hyviäkin asioita on tapahtunut.

Ketteryys on tuonut parempaa näkyvyyttä asiakkaille

Ketterät menetelmät ovat toki tuoneet ohjelmistokehityskulttuuriimme paljon hyviä asioita. Usein huonotkin prosessit ovat läpinäkyvämpiä kuin aiemmin. Asiakkaat pystyvät (yleensä) seuraamaan ohjelmistokehityksen prosessia jo varhaisesta vaiheesta lähtien. Hyvät tiimit myös esittelevät asiakkailleen välituloksia säännöllisesti, keräävät palautetta omistajilta ja tulevilta käyttäjiltä, ja muutenkin ymmärtävät dialogin merkityksen kehitysprosessin aikana.

Testausta tapahtuu jo toteutusvaiheen aikana

Myös jatkuva testaus on asia, joka on parantanut alalla tekemisen tasoa, vaikka tätä eivät edelleenkään kaikki ohjelmistokehitystiimit tee kovin systemaattisesti. Yleisesti ala on kuitenkin ottanut ison askeleen siihen suuntaan, että testaaminen on osa normaalia kehitystyötä, eivätkä kehittäjät siirry eteenpäin ennen kuin toiminnot on testattu ja hiottu kuntoon. Käytännössä tämä toki usein vaatii asiakkaalta jonkin tason testausosaamista ja runsaasti aikaa, mutta ohjelmistokehityksen onnistumisen näkökulmasta muutos on ollut hyvä.

Aiemmin testaaminen oli usein erillinen vaihe, ja mitä enemmän keskeneräisiä toimintoja oli, sitä pidempään niiden korjaaminen saattoi viedä, viivästyttäen hankkeiden loppuvaiheita joskus suhteettoman pitkälle.

Asiakkaat ottavat enemmän johtamisvastuuta hankkeista

Myös asiakkaiden vastuunotto hankkeiden onnistumisesta on lisääntynyt, vaikkakin ehkä osittain pakotettuna, kun ketterät tiimit eivät suostu ottamaan johtamisvastuuta itselleen. Tämä ei ole kuitenkaan huono asia isossa kuvassa. Moni vesiputousaikakauden ongelma oli lähtöisin siitä, että asiakkaat eivät halunneet ottaa mitään kantaa ohjelmistokehitykseen, vaan halusivat vain asettaa mahdottomia aikatauluja ja vaatimuksia. Tässä tasapainottelussa on toki heilahdettu aivan toiseen laitaan, kuten tässäkin blogissa on usein kirjoitettu. Nykyisin asiakkaiden täytyy usein vastata kaikesta johtamiseen liittyvästä, eivätkä tiimit suostu sitoutumaan mihinkään tulos- tai aikataulutavoitteisiin.

Ketterät hankkeet eivät onnistu juurikaan vesiputoushankkeita paremmin

Isoin ongelma on kuitenkin edelleen hankkeiden heikko onnistuminen. Usein viitataan esimerkiksi Standish Groupin selvityksiin, joissa ketteriä menetelmiä hyödyntävät hankkeet ovat onnistuneet vain muutamia prosentteja todennäköisemmin kuin aiemmat vesiputoustyyppiset hankkeet. Myös tässä blogissa on aiemmin viitattu vastaaviin tutkimustuloksiin, joissa onnistumisasteiden nousu on ollut 5-10 prosentin luokkaa.

Parannus ei ole toki merkityksetön, ketterät hankkeet siis onnistuvat todennäköisemmin kuin aiemmat vesiputoushankkeet. Tarpeeksi korkealta jos katsoo, niin tilannetta voi jopa pitää hyvänä, koska tutkitustikin parempaan suuntaan mennään.

Todellisuus ei ole kuitenkaan hyvä. Alalla on edelleen valtavia laatuongelmia, eikä alan toimistoja tunnu laadulliset asiat edes kiinnostavan. Isoina tekijöinä huonoon tilanteeseen mainitaan yleensä tuntilaskutuksen kulttuuri ja isojen puitesopimusten liian helppo kilpailuttaminen. Esimerkiksi tuoreessa Helsingin Sanomien jutussa argumentoidaan, että alaa ei kiinnosta enää lopputulosten laatu, koska kukaan ei myy lopputuloksia. Henkilöstövuokraus-tyyppinen projektitekeminen ei anna toimistoille eikä yksittäisille asiantuntijoillekaan insentiivejä onnistua hankkeissa, vaan ehkä jopa suuntaa asiantuntijoiden kiinnostuksen muihin asioihin, kuin asiakkaan ongelmien ratkaisemiseen.

“Heikniemi nostaa esiin tutkimuksen, jonka mukaan jopa 70 prosenttia ohjelmistohankkeiden kustannuksista syntyy sen jälkeen, kun tietojärjestelmä on jo rakennettu. Tietojärjestelmää siis korjaillaan ja paikkaillaan suuremmalla työmäärällä kuin sen rakentamiseen on kulunut. Vaikka rakennusala on saanut moitteita huonosta laadusta, it-alalla laatu vaikuttaa olevan usein vielä sitäkin huonompaa.

Sekä Puupposen että Heikniemen mielestä it-projektien ja konsultoinnin ostajien pitäisi olla nykyistä vaativampia.”

Ketteryys oli pieni askel eteenpäin, mutta vuori on vielä kiivettävänä

Ketterän kehittämisen menetelmät ovat siis ehkä tuoneet meidät ulos pimeästä laaksosta, sen ison vuoren juurelle. Nyt edessä on kuitenkin vielä se vuori, eikä meillä ole vieläkään kaikkia tarvittavia välineitä ja kokemusta sen ylittämiseen.

Erityisesti asiakkaiden tulisi edelleen panostaa enemmän hankkeiden valmisteluun ja kehityshankkeiden johtamiseen. Ketteryys ei ole mikään hopealuoti, joka ratkaisee onnistumisen, se on vain hieman parempi menetelmä kuin edelliset mallit. Isoissa ohjelmistohankkeissa epäonnistuminen on silti todennäköisempää kuin onnistuminen. Siksi tulisi kääntää kaikki kivet ja kannot, ja palkata parhaat mahdolliset tekijät, jos haluaa onnistua tietojärjestelmähankkeessaan. Erityisesti kannattaisi tutustua niihin projekteihin, jotka ovat onnistuneet, ja kerätä näiden kokemuksia ja parhaita käytänteitä, eikä vain opiskella jonkun ketterän menetelmän teoriaa.

Tähän kannustaa myös aiemmin viitattu Tom Gilb, joka sanoo, että me tiedämme kyllä, miten hankkeissa onnistutaan. Me vain emme jaksa selvittää niitä asioita riittävän perusteellisesti tutustumalla vastaaviin onnistuneisiin projekteihin.

Alan toimistoilta tulisi myös vaatia enemmän. Tiimeiltä tulisi odottaa koestettuja toimintamalleja, kestäviä ja perusteltuja teknologiavalintoja sekä sitoutumista aikataulu- ja budjettitavoitteisiin. Ei ole kestävä malli, että vain toisella osapuolella on riskejä hankkeessa. Jonkinlainen jaettu riski ja voitto täytyy olla olemassa, jos halutaan kaikkien aidosti sitoutuvan samoihin tavoitteisiin.

PS. Tilaa Vierityspalkin kerran kuukaudessa ilmestyvä uutiskirje, joka koostaa artikkelit, linkkivinkit, työpaikat ja julkaisut (uutiskirjeellä on jo yli 1000 tilaajaa).