Toimialasta riippumatta yritys kuin yritys haluaa tällä hetkellä viedä digikehitystään kevyempään ja ketterämpään suuntaan. Usein tämä pitäisi kuitenkin pystyä tekemään muuttamatta organisaatiorakenteita, henkilöitä, järjestelmiä tai hankintakäytäntöjä merkittävästi.
Uusissa järjestelmähankinnoissa aletaan ehkä kokeilla ketteriä menetelmiä, mutta mitä vanhempi järjestelmä on kyseessä, sitä todennäköisemmin asiat saavat jatkua kuten aina ennenkin.
Ikään kuin normaalien päivittäisten ruoka-annosten lisäksi söisi vielä yhden salaatin - ja odottaisi laihtuvansa.
Ketteryyden perikuvina usein olevat teknologiastartupit tekevät kovin erilaista työtä kuin suuryritys, joka kehittää itselleen omaa liiketoimintaansa tukevia järjestelmiä. Startup voi keskittyä enemmän asiakkaisiinsa ja oman tuotteensa kehittämiseen. Suuryrityksen täytyy taas huomioida myös mm. työntekijät ja organisaatiot, jotka tulevat käyttämään järjestelmää, olemassa olevat liiketoimintaprosessit ja järjestelmät sekä budjetointi eri organisaatioyksiköiden yli. Siksi ei välttämättä kannata ottaa viileintä teknologiastartuppia vertailukohdaksi.
Joitakin käytäntöjä startupeilta kuitenkin kannattaa kopioida, kuten esimerkiksi oman liiketoiminnan jatkuva iteratiivinen kehitys. Projektilla on aina alku ja loppu, mutta liiketoimintasi ei ole koskaan valmis. Miksi siis haluaisit kehittää sitä projektinomaisesti? Kuriositeettina esimerkiksi skaalatun ketterän ohjelmistokehityksen malli SAFe (Scaled Agile Framework) ei edes tunnista käsitettä ”projekti”. SAFe näkee digikehityksen jatkuvana työnä, jossa liiketoiminnan eri osa-alueille - SAFen mallissa eri arvovirroille - allokoidaan tietty budjetti. Arvovirralla on priorisoitu lista asioita, joita kehitetään budjetin puitteissa niin paljon kuin ehditään.
Organisaation ketteröittämisessä ei kuitenkaan ole kyse vain viimeisimmän ketterän ohjelmistokehitysmenetelmän käyttöönotosta. Pohjimmillaan kyse on kyvystä työskennellä organisaatiorajojen yli, uudenlaisista hankintakäytännöistä, budjetoinnista ja muiden kuin ohjelmistokehittäjien työtapojen muuttamisesta. Näihin asioihin pelkät ohjelmistokehitysmenetelmät eivät tarjoa ratkaisua, ja tällaisen muutoksen ajaminen IT-lähtöisesti on todennäköisesti kivinen tie.
Jos lean-filosofia pitäisi kiteyttää yhteen ajatukseen, se olisi varmasti arvoa tuottamattoman työn poistaminen. Katso ympärillesi. Kuinka monella digikehitystä tekevällä henkilöllä toimistossanne on pääsääntöisesti näytöllään auki PowerPoint tai Word? Tuotetaanko näillä työkaluilla arvoa?
PowerPointia ja Wordiä, sekä liian usein myös Exceliä käytetään paketoimaan oma tietämys jostakin asiasta kokonaisuudeksi, jonka voi luovuttaa toiselle henkilölle, tiimille, tai organisaatiolle. Käytännössä tämä rituaali minimoi yhdessä työskentelyn määrän ja hand overeissa menetetään tietoa.
Uusi palveluidea tai konsepti luovutetaan business analystille, joka kääntää sen liiketoimintavaatimuksiksi. Liiketoimintavaatimukset luovutetaan ratkaisusuunnittelijalle tai IT-arkkitehdille. Näistä tehdään ratkaisusuunnitelma, joka luovutetaan ohjelmistotoimittajalle, joka kääntää sen teknisiksi vaatimuksiksi, käyttäjätarinoiksi ja testitapauksiksi. Jokaisessa vaiheessa alkuperäinen idea muuttuu hieman, ja arvoa ei ole vielä tuotettu yhtään.
Pystytkö muuttamaan organisaatiosi toimintatapoja siihen suuntaan, että liiketoiminnan asiantuntijat, määrittelijät sekä ohjelmistokehittäjät ja -testaajat muodostavat yhden tiimin, mielellään saman katon alla?
Pienet monitaitoiset tiimit voittavat ekstensiiviset suunnitteluprosessit erityisesti kuluttajapalveluiden kehittämisessä. Kyky nopeaan kokeiluun on arvokkaampaa kuin isolla konklaavilla tehty ja sinetöity yksityiskohtainen määrittely, joka on kaikesta vaivannäöstä huolimatta kuitenkin puutteellinen, todennäköisesti sisältää ristiriitoja, ja on jo toteutuessaan vanhentunut.
Taipuuko ostoprosessisi siihen, että ohjelmistokehityssopimuksia ei tehdä kiinteällä budjetilla ja lukkoon lyödyillä toimitettavilla nimikkeillä, vaan hankitaan asiantuntijoita suoritusperusteisella laskutuksella osaksi tiimiä? Fixed scope -projektit ovat vesiputouksia, vaikka niiden eri vaiheet naamioidaan ”sprinteiksi”.
Toimittaja lisää työmääräarvioihin riskipuskurin. Vaatimusdokumentaation luovutukset hukkaavat tietoa, ja lopullinen tulos ei vastaa alkuperäistä tahtotilaa. Joitakin vaatimuksia on unohtunut alkuperäisestä vaatimusexcelistä, jonka takia hieman ennen lanseerausta huomaat, että verkkokaupallasi ei ole etusivua (tositarina). Tästä täytyy tietysti tehdä muutospyyntö, joka priorisoidaan ja hyväksytään muutoshallintakomiteassa - joka muuten kokoontuu seuraavan kerran kahden viikon päästä.
Ohjelmistotoimittajilta on helppo vaatia ketterää toimintamallia. Työn rytmittäminen sprintteihin on heille arkipäivää. Ketteryys edellyttää ennen kaikkea rohkeutta nostaa esille oman organisaation aikaa ja resursseja hukkaavia käytäntöjä sekä energiaa niihin puuttumiseen.
Venyttely on epämukavaa ja laihduttaminen tekee kiukkuiseksi - mutta jos haluaa saada tuloksia aikaan, on elämäntapoja pakko muuttaa.
Autamme asiakkaitamme löytämään digikehitykselleen parempia toimintamalleja aina portfolionhallinnasta yksittäisiin ohjelmistokehitysprojekeihin, sekä tunnistamaan heille parhaiten sopivan ketterän kehityksen operativiisen mallin.
Tarjoamme myös Lean agile -koulutusta, SAFe-kursseja sekä räätälöityjä työpajoja. Katso esimerkiksi:
SAFE® PRODUCT OWNER/PRODUCT MANAGER, HELSINKI, 7.-8.12.2017
ja lue lisää täältä.
Asko Relas (kirjoittaja työskenteli Loihde Advancella joulukuuhun 2018).