Läpimenoaika kahteen viikkoon ja 300 julkaisukanditaattia päivässä
Aikoinaan siirryin ulkopuolelta erääseen tuotekehitysyksikköön yhdeksi esihenkilöksi. Ja koska yksi intohimoni oli tuolloin tehdä asioita paremmin, halusin tehdä meistä nopeampia.
Rakensimme jatkuvan integraation ja testiautomaation omalle tuotteellemme. Esimerkiksi testiautomaation tapaukset kirjoitettiin JavaScriptillä, ja kirjoitin niitä yhdessä kehittäjien kanssa, en vieressä katsoen vaan tehden samaa työtä. Se oli myös ainoa tapa ansaita se luottamus, jota myöhemmin tarvittiin.
Se toimi. Sain luottamuksen, joka liitti minut osaksi työyhteisöä. Samalla saimme nopeutettua tuotekehitystä automatisoimalla ison osan testauksesta.
Sitten yhtiö osti kilpailijan, ja minut valittiin auditoimaan heidän kehityskäytäntönsä.
Palasin ja kerroin, että heidän tapansa oli kattavampi kuin meidän. Esitin, että jatketaan heidän tavallaan ja työkaluilla tehdä uutta tuotetta. Niin tehtiin. Oma tuote hylättiin ja siirryimme uusiin toimintatapoihin. Toimintatavoissa ei ollut juurikaan eroa, mutta työkaluketju oli paremmin automatisoitavissa ja skaalattavissa.
Siitä alkoi toimintatapojen virittäminen huippuunsa.
Uudet työkalut mahdollistivat automaattisen jäljitettävyyden vaatimuksista aina koodiriviin ja testitapauksiin. Rakensin portfolion WIP-rajoineen ja käytäntöineen, kehitimme tiimien osaamista sekä toimintatapoja aina ”high performing” tasolle hyödyntäen ison talon omia asiantuntijoita.
Kun tiimit luottivat esihenkilöihin ja tunsivat että asioita voi parantaa, heiltä alkoi tulla parannusehdotuksia, joita toteutettiin yhdessä.
Kahden vuoden kuluttua tuloksena oli: läpimenoaika lyheni puolesta vuodesta viikkoihin ja kahden viikon julkaisusyklistä pääsimme jopa kolmeensataan julkaisukandidaattiin päivässä.
Olen edelleen ylpeä siitä, mitä saimme aikaiseksi.
Sitten tuli AI
Viime kuukausina olen lukenut, mitä ohjelmistokehityksestä kirjoitetaan nyt.
Kuva on suunnilleen tämä. AI-agentti kerää asiakastarpeet. Toinen muuttaa ne vaatimuksiksi. Kolmas kirjoittaa koodin. Neljäs katselmoi. Viides testaa. Kuudes päivittää dokumentit ja tiketit. Putki päästä päähän, ilman odottamista, ilman sitä kitkaa, jonka poistamiseen meiltä meni pari vuotta.
Ja minä istun tässä ja mietin: jos tällaisen muutoksen saa nyt tilauksena kuukausihintaan, mitä minä oikeastaan tein yhdessä muiden kanssa?
Se ei ollut retorinen kysymys. Se on vaivannut minua viikkoja, jopa kuukausia.
Olin kertonut tarinani väärin
Vastaus löytyi, kun mietin, mikä parannuksista tuotti eniten arvoa.
Se ei ollut automaatio.
Se ei ollut portfolionäkymä.
Se ei ollut itse auditointi, mutta sen tulos vakuutti siitä, että asioita voi tehdä paremmin jatkuvasti oppien.
Samalla, kun opimme nopeammin, ymmärsimme myös yhteisen tekemisen tärkeyden. Näin siilot romahtivat ympäriltämme.
Olin kertonut tarinani väärin. Olin kertonut sen nopeustarinana. Nopeus oli seuraus. Se, mitä teimme, oli oppia tekemään asioita yhdessä, yli tiimi- ja organisaatiorajojen sekä samalla oppia parantamaan toimintatapojamme jatkuvasti sallien myös epäonnistumiset.
Nopeus ei ole sama asia kuin oppiminen
Alalla kiertää lausahdus, jota olen itsekin viljellyt: nopeampi väärän tekeminen ei ole edistystä.
Olen alkanut ajatella, että se on puoliksi väärin.
Nopea tekeminen nimittäin auttaa myös väärän asian tekevää, koska se lyhentää oppimisaikaa. Organisaatio, joka rakentaa väärän asian kahdessa päivässä ja oppii siitä viikossa, on paremmassa asemassa kuin organisaatio, joka rakentaa väärän asian yhdeksässä kuukaudessa ja oppii vasta julkaisun yhteydessä.
Muuttuja ei siis ole nopeus.
Muuttuja on oppimisnopeus, ei tekemisnopeus.
Nopeus, johon liittyy oppiminen, on etu. Nopeus ilman oppimista on tehokkaampaa hukkaa ja kalliimpaa kuin hidas hukka, koska sitä syntyy enemmän.
AI-keskustelussa mitataan väärää asiaa
Tässä kohtaa AI-keskustelu menee mielestäni pieleen.
Melkein kaikki, mitä luen, mittaa nopeutta. Kuinka paljon koodia syntyi. Kuinka monta tikettiä liikkui. Kuinka paljon nopeammin päästiin ideasta pull requestiin. Nämä on helppo kerätä ja ne näyttävät aina hyvältä.
Yksikään niistä ei mittaa, oppiko organisaatio mitään tai tuotettiinko arvoa asiakkaille tai yritykselle.
Mitä tapahtuu, kun toteuttamisesta tulee halpaa?
Kysymys, jota en näe kysyttävän ääneen, on tämä: kun tuotoksen tuottaminen halpenee kertaluokan, mikä osuus lopputuloksen kokonaiskustannuksesta on enää toteutusta ja mikä osuus on sitä, että tehtiin väärää asiaa?
Jos tuotekehitys halpenee viisinkertaisesti, väärän valinnan hinta ei välttämättä laske lainkaan. Se vain kasvaa suhteessa kaikkeen muuhun, kunnes siitä voi tulla ainoa kustannus, jolla on merkitystä.
Mitä halvemmaksi tuotekehitys tulee, sitä arvokkaammaksi tulee osata päättää mitä kehitetään.
En ole sitä mieltä, että agenttiputket ovat huono juttu. Uskon, että ne tekevät mitä lupaavat, ja nopeammin kuin useimmat odottavat.
Olen sitä mieltä, että yhdessä tekeminen ja oppiminen luo paremman ja kestävämmän pohjan koko organisaatiolle kehittyä nopeammin.
Yksi kysymys sinulle
Minua kiinnostaa oikeasti tietää ja siksi kysynkin:
Kuinka kauan teidän organisaatiossanne kestää siitä, kun joku sanoo ”tämä pitäisi tehdä”, siihen kun joku oikeasti aloittaa sen?
Verratkaa sitä siihen, kuinka kauan sen tekeminen kestää.
Jos jälkimmäinen on lyhyempi kuin edellinen, teillä ei ole kehitysnopeusongelmaa. Teillä on jotain muuta, ja se on paljon kalliimpi.