‹ Blogit

19.9.2017 12.00

Lean agile -transformaatio – laihdutusta ilman elämäntapamuutoksia?

  • Lean agile

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.

Mitä ketteryys tarkoittaa suuryritykselle?

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.

Ennen kuin alat jalkauttaa viimeisintä ketterää menetelmää, mieti seuraavia asioita:

  • Täytyykö hankintasopimukset tehdä aina kiinteällä hinnalla ja toimitettavilla nimikkeillä? Fixed scope ei ole ketterää, koska muutoksiin reagointi vaatii muutoksenhallintaprosessin.
  • Kuinka monelle digikehittäjälle työn syötteenä on yhden tyyppinen dokumentti ja tuloksena toisen tyyppinen dokumentti? Vaikka järjestelmien dokumentointi on tärkeää, dokumentit eivät itsessään tuota arvoa.
  • Kuinka monta kertaa dokumentti tai esitys vaihtaa omistajaa ennen kuin tekninen implementaatio alkaa? Tietoa hukkuu hand overeissa.
  • Voiko asiantuntija puhua suoraan toiselle asiantuntijalle, vai pitääkö hänen mennä managerien kautta? Monitaitoisten tiimien vastakohta on kompetensseihin jakautuneet tiimit, joiden managerit suojaavat työntekijöitään kuin tiikeriemot.
  • Kauanko idealla kestää päätyä implementaatioprojektin backlogille? Kyky toimittaa uusia toiminnallisuuksia joka toinen viikko on vain osa kokonaisuutta. Merkittävin hitausmomentti löytyy yleensä työtä ja aikaa hukkaavista työskentelytavoista, muutosvastarintaisesta kulttuurista sekä rakenteista, jotka eivät tue yhdessä työskentelyä organisaatiorajojen yli.

Eroon arvoa tuottamattomasta työstä

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.

Suosi pieniä monitaitoisia tiimejä

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.

Fixed scope ei ole ketterää 

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ä.

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

Asko Relas profile portrait circle

Kirjoittaja työskentelee Talent Base Oy:n johtavana konsulttina keskittyen moderneihin tiedonhallintateknologioihin, analytiikkaan sen eri muodoissa, verkkopalveluiden suunnitteluun, sekä liiketoimintalähtöiseen ratkaisusuunnitteluun yleisesti.

Katso profiilini

Pidätkö lukemastasi? Tilaa blogitekstimme meiliisi.