Aina välillä on hyvä pohtia, mitkä trendit nousevat ohjelmistotuotekehitystä tekevissä organisaatioissa. Meidän visiomme on, että lähes kaikista yrityksistä tulee enemmän tai vähemmän ohjelmistotuotekehitystä tekeviä yrityksiä, joten ennustuksemme koskeekin isoa osaa kaikista yrityksistä.

Seuraavien vuosien tulevat trendit:

• Organisaation ketterän ohjauksen mallien mittavat käyttöönotot
• Ohjelmisto-osaamisen vahvistaminen yritysten omilla henkilöillä
• Tuotekehityksen jäljitettävyyden uudelleen arvostaminen
• Ketterien tiimien vahvistaminen (todellisen ketteryyden uusi aalto)

Käymme tässä postauksessa näitä trendejä vain pääpiirteittäin läpi. Jokainen näistä ansaitisisi oman postauksen tai webinaarin, jotta aihetta voitaisiin käsitellä laajemmin.

Organisaation ketterän ohjauksen mallien mittavat käyttöönotot

Monissa yrityksissä on herätty viimeisten vuosien aikana siihen, että ketterät tiimit vaativat toimiakseen toimivamman ohjausmekanismin. Muutamien vuosien ajan SAFe (Scaled Agile Framework) on noussut trendiaatteeksi ja malliksi organisaation ohjaukseen. Vastikään muitakin valmiita malleja on tuotteistettu paremmin, kuten esimerkiksi LeSS, NEXUS ja DaD. Näiden kaikkien mallien on tarkoitus tehdä käyttöönotto helpommaksi.

Näemme että tämä trendi tulee jatkumaan erityisen vahvana seuraavien vuosien ajan. Olemme jo nyt nähneet, että monet vanhakantaisetkin organisaatiot miettivät skaalautumisen mallien käyttöönottoa ja tekevät ensimmäisiä kokeilujaan prosessien käyttönotoissa. Organisatoriselle ketterälle ohjaukselle on selkeästi tarvetta, mutta tunnettuja malleja on vielä vähän ja monia tunnetuistakin otetaan käyttöön heikoin perustein.

Puhe ketteryyden skaalautumisesta tulee jatkumaan vahvana seuraavat vuodet. Uusia mallejakin saataneen vielä lähivuosien aikana. Toivomme että organisaatiot kuitenkin keskittyisivät miettimään millä perusteilla ja mihin tarkoitukseen skaalautuvuuden malleja halutaan soveltaa. Todellisten hyötyjen saaminen mallien avulla on työn ja tuskan takana, mutta onnistuessaan ketterällä organisaation ohjauksella pystytään parantamaan yritysten arvon tuottoa huomattavasti.

Ohjelmisto-osaamisen vahvistaminen yritysten omilla henkilöillä

Lähes kaikista yrityksistä tulee ajan myötä ohjelmistotuotekehitystä tekeviä yrityksiä. Ohjelmistot tulee olemaan osa kaikkia toimialoja ja niin jo pitkälti onkin. Kaikkien ei toki tarvitse tehdä koodaustaan itse, mutta ohjelmistot tulevat näyttelemään oleellista osaa uuden liiketoiminnan luomisessa ja markkina-aseman vahvistamisessa.

Vuosikymmenen vaihteen IT ja ohjelmistokehityksen ulkoistus trendien vastapainoksi uskommekin, että yritykset alkavat kehittämään yhä enemmän sisäistä osaamista ohjelmistokehityksestä. Ohjelmistojen tärkeys näkyy ja niiden kehittämistä ja hallinnointia ei haluta enää laittaa kumppaneiden käsiin. Jokapäiväinen ohjelmistojen ylläpito ja pienimuotoinen jatkokehittäminen onnistuu kumppaneiden avulla hyvin, mutta pitkäjänteinen strategisesti tärkeä ohjelmistoilla tehtävä liiketoiminta vaatii sisäistä osaamista ohjelmistokehityksestä.

Tämä ei tarkoita loppua ohjelmistoalihankinnalle. Sillekin on paikkansa pienkehityksessä ja ylläpidossa. Nykyaikainen kokonaisten tiimien vuokrausbusiness tulee varmasti vähenemään. Yritykset haluavat ohjata ja hallita ohjelmisto assettejaan yhä paremmin itse. Tätä kautta uskomme, että jonkinlaiset hybridimallit, jossa tärkeimpien asioiden kehitys ja esimerkiksi johtavat kehittäjät ovat sisäisiä ja ulkoa ostetaan sitten pelivaraa skaalata kehitystä eri suuntiin.

Tämä tulee vaikuttamaan myös organisaatioiden sisäisiin osaamistarpeisiin. Lähes kaikkien organisaatioissa tulee ymmärtää ohjelmistokehityksen lainalaisuudet ja esimerkiksi vaatimusten hallinnan perusteet. Jos katsotaan kaikkia viimeisen 10 vuoden aikana isosti kasvaneita yrityksiä, niin ohjelmistojen mahdollisuuksien ymmärtäminen ja niiden yhdistäminen markkinoiden tarpeisiin on luonut todella innovatiivisia läpimurtoja.

Tuotekehityksen jäljitettävyyden uudelleen arvostaminen

Tuotekehityksen jäljitettävyys ja esimerkiksi niin sanotut ALM (Application Lifecycle Management) ratkaisut kokivat inflaation ketteryyden ensimmäisessä aallossa. Ketterän kehityksen julistuksen teesi ” Toimivaa ohjelmistoa enemmän kuin kattavaa dokumentaatiota” otettiin niin sananmukaisesti, että dokumentaatio unohdettiin lähes kokonaan.

Viimeisten parin vuoden aikana on tuntunut, että kokeneet ohjelmistokehityksen ammattialaiset ovat vihdoin saaneet suunsa auki toteamaan, että dokumentaatio on arvokasta, kun tuotteiden elinikä on pitkä. Nykyään lähes kaikkien ohjelmistotuotteiden elinikä on pitkä ja niitä pitää huoltaa ja jatkokehittää vuosia jopa monia kymmeniä vuosia. Myös liiketoiminnan edustajisto on ymmärtänyt sen verran paljon ketteryydestä, että he ovat alkaneet uskaltaa vaatia kunnollista dokumentaatiota ja vaatimusten hallintaan.

Uskommekin, että monet vaatimusten hallinnan hyvät käytännöt kymmenien vuosien takaa näkevät uuden tulemisen. Niitä vaan yhdistetään paremmin lyhyisiin toimitussykleihin ja jatkuvaan laadun rakentamiseen. Esimerkiksi pysyvä tuotedokumentaatio on päässyt pahasti happanemaan elävien backlogien aikakaudella. Pahimmillaan ainoa dokumentaatio on koodi ja tuote, kun on käytetty ”laput seinällä” ajattelua ketterien tiimien toiminnassa.

Tämän kanssa monet yritykset tulevat olemaan pulassa. Kun kerran on päästetty tuotedokumentaatio huonoon kuntoon, sen kasaaminen on todella mittava projekti. Tähän tullaan heräämään ja tämä tullaan integroimaan yhä paremmin ketterien tiimien ja tuoteomistajien jokapäiväiseen työhön. Myös tuotekehityksen työkaluissa tultaneen näkemään uusia tuulia. Backlogeissa tehtävät muutokset pitää pystyä tulevaisuudessa viemään helpommin osaksi tuotedokumentaatioon niiden valmistuttua.

Ketterien tiimien vahvistaminen

Viimeisenä, mutta ei vähäisimpänä yrityksissä tultaneen laittamaan ketteriä tiimejä tilille tuottavuudestaan. Liian monet, arviomme mukaan 60 – 80 % tiimeistä, jotka sanovat olevansa ketteriä, eivät edes osaa sanoa mitä ketteryys heidän kontekstissaan tarkoittaa. Se että pidetään jatkuvaa sprinttisuunnittelua tai hoidetaan taskeja Kanban-taululla (lue myös Kanban-blogimme!), ei ole ketteryyttä, vaan prosessin noudattamista.

Ketteryys syntyy laadun rakentamisesta tekemisen aikana. Pitää tehdä pienissä osissa mahdollisimman valmista ja kokonaista. Esimerkiksi monilla tiimeillä Definition of Done:t ovat joko olemattomia tai niitä ei noudateta. Myös jälkijättöinen laadun rakentaminen testauksella on hyvin yleistä. Isoissa organisaatioissa myös komponenttikeskeisyys on jäänyt perinteiseksi tavaksi ajatella kehittämistä.

Näemmekin, että tiimien ketteryydessä tulee uusi vahvistamisen aalto. Kun ohjelmistohankkeet vaativat yhä enemmän yhteistyötä eri tiimeiltä, laatu ja aikataulussa pysyminen nousee yhä tärkeämmäksi. Sen voi saavuttaa vain kun tiimit ovat sisäistäneet ketteryyden periaatteet ja noudattavat niitä hyvin.

Yhteenveto

Lähitulevaisuudessa tulemme varmasti näkemään paljon muitakin asioita ohjelmistokehityksessä ja organisaatioissa yleisesti. Muutokset ovat kuitenkin hitaita ja vaativat paljon aikaa ja energiaa.

Uskomme kuitenkin, että yrityksien strategioihin nousee yhä useammin ohjelmistojen avulla tapahtuva liiketoiminnan kasvu. Tämä sitten johtaa siihen, että ohjelmisto-osaamista tulee organisaatioissa vahvistaa entisestään.