Mitä ketteryys on AI‑aikana?

Viime aikoina ketterään kehitykseen liittyvä keskustelu on pyörinyt vahvasti saman teeman ympärillä: mitä ketteryys on AI‑aikana. Kirjoitusten näkökulmat ovat olleet monipuolisia, enkä tässä ota kantaa yksittäisiin teksteihin. Sen sijaan pysähdyn pohtimaan, mitä ketteryys pohjimmiltaan on ja miten tämä ydin on muuttunut tai on ehkä muuttumassa.

Aloitin urani 2000‑luvun taitteessa, ja vesiputousmallin haasteista puhuttiin jo tuolloin. Digitalisaatio oli osittain jo pidemmällä, mutta monin paikoin yritettiin silti toistaa manuaalisia prosesseja sellaisenaan, ottamatta huomioon digitaalisten palveluiden ominaispiirteitä.

Vesiputousmalli on tästä hyvä esimerkki. Kerrostaloa rakennettaessa perustuksia ei enää muuteta kesken työn, eikä rakenteita ja LVI‑asennuksia juurikaan vaihdella, jos projekti halutaan viedä kunnialla maaliin. Suunnitelmat on tehtävä perusteellisesti, ja muutoksia voidaan myöhemmässä vaiheessa tehdä vain rajatusti ilman merkittäviä vaikutuksia projektin kestoon ja budjettiin. Mitä täsmällisemmin suunnittelu on tehty, sitä parempi lopputulos. (Vertaus ei tietenkään ole täydellinen, mutta se auttaa hahmottamaan ajattelutapaa.)

Vesiputousmalli yritti toistaa tätä ajattelua ohjelmistoprojekteihin. Isoja hankkeita suunniteltiin kuukausia tai jopa vuosia ennen varsinaista tekemistä. Usein lopputulos ei kuitenkaan vastannut suunnitelmia tai asiakkaan todellisia tarpeita: asiakas ei aina osannut ilmaista tarpeitaan insinöörikielellä, vaatimukset eivät lopulta palvelleetkaan käyttäjiä, toteutusta tehtiin omien tulkintojen pohjalta ja testaus tuli mukaan vasta siinä vaiheessa, kun parannuksia ei enää voitu tai ehditty tehdä. Ohjelmistohankkeet etenivät hitaasti, eivätkä lopputulokset usein vastanneet asiakkaan tarpeita.

Prosessikehityksen saralla hoksattiin, että ohjelmistokehitystä voi perinteisiin projekteihin verrattuna suunnitella, toteuttaa ja esitellä asiakkaille pienemmissä palasissa. Koulutin 2000‑luvulla testausprosesseja, ja tuolloin puhuttiin inkrementaalisesta kehitysmallista, jossa tehdään pienempiä osatoteutuksia.

Tärkeätä tässä osatoteutusten prosessissa oli se, että testausta tehtiin jatkuvasti alemmalla tasolla, ja osatuotoksen esittelyä varten kokonaisuus integroitiin ajoissa ja testattiin eri palikoiden yhteensopivuus demoa varten. Asiakkailta saatiin palautetta siitä, ollaanko menossa oikeaan suuntaan, ja suuntaa korjattiin seuraavassa osatoteutuksessa. Kokonaisuudesta oli olemassa ylätason kuvaus, mutta tarkempi määrittely tehtiin vaiheittain, osissa.

Näihin aikoihin puhuttiin jo ketterästä kehityksestä ja siitä, miten esimerkiksi Extreme Programming ja vastaavat mallit mullistivat prosesseja täydellisesti. Monenlaista kokeilua oli liikkeellä, mutta isompien kehityskohteiden osalta suurin osa yrityksistä eteni silti hieman maltillisemmin.

Oman kokemukseni mukaan ketterä kehitys näyttäytyi monessa paikassa tavallaan hiotumpana inkrementaalisena kehityksenä. Asioita tehtiin tekemisen luonteesta ja tiimeistä riippuen erilaisilla sykleillä, mutta kaikille oli yhteistä se, että tehdään, testataan ja toimitetaan nopeasti eteenpäin. Kaiken tämän keskiössä oli saada asiakkailta tai asiakasta edustavilta tahoilta näkemys siitä, onko ketju: tarpeet → vaatimukset → speksit tuottanut oikeita asioita. Palautteen pohjalta tehtiin tarvittaessa muutoksia.

Pikkuhiljaa mukaan tulivat Agile Manifesto, kirjat, prosessikuvaukset, ohjeet ja Lean/Agile‑gurut. Ketteryys oli joissain paikoissa tehnyt valtavia mullistuksia, ja näitä käytäntöjä haluttiin monistaa mahdollisimman laajasti. Tässä kohtaa jotain perustavanlaatuista saattoi kuitenkin unohtua.

Keskityttiin periaatteisiin ja toteutuksen organisointiin niin kuin kirjoissa kerrottiin tai kuten jossain muualla oli onnistuneesti tehty. Monessa organisaatiossa, joissa olen työskennellyt tai joita olen seurannut läheltä, pienet yritykset ottivat ketteryyden usein käyttöön varsin mallikkaasti, mutta isoilla organisaatioilla oli suuria haasteita. Ohjelmistokehityksellä oli kasvukipuja. Skaalautuvat menetelmät tulivat kyllä hyvissä ajoin mukaan, mutta siinä missä Scrum oli suhteellisen suoraviivainen ottaa tiimitasolla käyttöön, skaalautuvien menetelmien käyttöönotto ei useinkaan edennyt toivotulla tavalla.

On suoraviivaista kertoa, miten jossain muualla onnistuttiin, mutta jotta käytännöt saisi toimimaan omassa organisaatiossa, pitäisi pysähtyä huolella peilaamaan erilaisia malleja ja pohtia, mikä toteutustapa oikeasti sopii juuri meille. Millä sykleillä juuri meidän tuoteasiantuntijat ja tuotekehitys toimii parhaiten, keiden on tärkeää suunnitella yhdessä, onko aitoja riippuvuuksia ja miten usein niiden takia on tarpeen kokoontua? Mikä työkalu tuo aidosti lisäarvoa? Tässä kohtaa ketteryyden ydin – jatkuva oppiminen, kokeilu ja palautteen hyödyntäminen – on tärkeämpää kuin yksittäinen viitekehys tai valmis malli: Mitä asioita on tärkeää tehdä ensin ja miten niitä testataan? Kelle näitä näytetään ja miten palaute saadaan vietyä osaksi suunnittelua?

AI‑aikana tämä korostuu entisestään. Valmiita vastauksia ja työkaluja on tarjolla enemmän kuin koskaan, mutta mikään niistä ei yksin ratkaise sitä, miten juuri meidän tiimimme tekee arjessa parempia päätöksiä, oppii nopeammin ja toimittaa oikeita asioita asiakkaille.

Monissa kirjoituksissa on pohdittu sitä, onko AI ketterän kehityksen loppu, kun ei ehkä enää tarvita seremonioita ja muita asioita, jotka mielletään osaksi ketteryyttä. Esimerkiksi spec driven ‑kehityksen ajatellaan vievän takaisin vesiputousmalliin – tosin nopeampaan sellaiseen. Rohkenen väittää, ettei siitä ole kysymys -> emme halua tehdä ohjelmistokehitystä kuten isoja rakennushankkeita.

Palaamme ehkä pikemminkin kohti ketteryyden juuria: yksinkertaisesti siihen, miten saadaan nopeasti palautetta tehdyistä asioista, miten demotaan nopeasti ja tehokkaasti ja miten nämä havainnot otetaan osaksi seuraavan askeleen suunnittelua ja koko toteutuksen yleiskuvaa. Seremoniat, sprintit ja työkalut ovat palvelleet tiimejä ja tekijöitä antamalla mahdollisuuden suunnitella yhdessä, antaa palautetta, jakaa osaamista ja kuulla palautetta jo tehdystä työstä. Nämä keinot saattavat muuttua – ja niistä puhun seuraavassa blogissani.

Ketteryys ei ole pelkkä prosessi tai toimintatapa, vaan ennen kaikkea nöyränä pysymistä sen edessä, ettei näitä asioita tehdä yksin. Aina on jossain asiakas, jonka mielipidettä haluamme kuunnella, jotta voimme tarjota hänelle aidosti parhaan mahdollisen tuotteen. AI‑aika tuo tähän lukemattomia mielenkiintoisia mahdollisuuksia.