Ari Tanninen & Marko Taipale
Lyhyt johdanto Tässä artikkelissa käsitteellä johtaminen tarkoitetaan pääasiallisesti organisaation ymmärtämistä, suunnittelemista sekä muutosten toteuttamista ja seuraamista. Laajennamme siis johtamisen käsitettä perinteisestä asioiden johtamisesta (management) ja ihmisten johtamisesta (leadership) jatkuvaan organisaation systeemisen ymmärtämiseen, parantamiseen ja ylläpitämisen.
Oletamme lukijan tuntevan Scrum-menetelmän ja ketterän ohjelmistokehityksen perusteet. Tarvittaessa hyvään alkuun pääsee lataamalla ja lukemalla ilmaisen Scrum oppaan osoitteesta http://scrum.org/Scrum-Guides. Scrumin skaalaamisesta opas ei kerro mutta siitä pääsee kärryille vaikka lukaisemalla Henrik Knibergin ilmaisen Scrum and XP from the Trenches -kirjan, jonka voi ladata osoitteesta http://www.crisp.se/bocker-och-produkter/scrum-and-xp-from-the-trenches.
Tämän artikkelin viesti on: radikaalisti parannuksia organisaation toimintaan saadaan vasta kun ketteryyttä tuetaan systeemiajattelulla ja johtamisella.
Tarina: skaalatusta ketteryydestä tuotekehitysvirran johtamiseen
Tämä tarina liittyy kansainväliseen ohjelmistotuoteyritykseen, jonka liikevaihto on noin sata miljoonaa euroa ja jossa työskentelee satoja ihmisiä.
Kuva 1: Yrityksen organisaatio alkutilanteessa
Yrityksen johto määritti ongelman: “Meidän liiketoiminta ei skaalaudu, koska ohjelmistokehitys on niin hidasta”. Tässä vaiheessa yrityksen tuotekehitysosaston katsottiin oleva pullonkaula ja tuotekehitysosasto alkoi tehdä työtä käskettyä. Tuotekehitysosastolla työskenteli joukko kehittäjiä, joilla oli mielessä kaksiosainen ratkaisu: uudistetaan tuotteiden alla oleva vanha tekninen alustaratkaisu ja pilotoidaan samalla ketterää ohjelmistokehitystä Scrumilla. Mikäli tämä pilotti onnistuisi, niin kaikki ohjelmistokehitystiimit voisivat siirtyä vähitellen käyttämään Scrumia tai jotakin muuta ketterää menetelmää.
Kahden vuoden ja monen kommervenkin jälkeen tekninen alusta oli uudistettu ja ketterä pilotti osoittautui onnistuneeksi. Uusien toimintatapojen ja alustan vuoksi uuden tuotteen ohjelmiston kehittämiseen kuluva aika saatiin leikattua kuudesta kuukaudesta kahteen kuukauteen. Tuotekehitysosaston tuottavuus kolminkertaistui ja urakan tehneet kehittäjät olivat ylpeitä onnistuneesta lopputuloksesta.
Samalla Scrum oli laajentunut koko tuotekehityksen tavaksi kehittää ohjelmistoja. Scrum oli käytössä yli kymmenessä kehitystiimissä, jotka synkronoivat toimintaansa yrityksen laajuisiin kuuden viikon sprintteihin (tiimien omat sprintit olivat kahden tai kolmen viikon pituisia, joten niitä mahtui kaksi tai kolme kappaletta kuhunkin yrityksen laajuiseen sprinttiin). Yrityksen laajuinen sprinttien suunnittelu toimi loistavasti, vaikka niihin osallistuikin paikoitellen yli sata ihmistä. Yrityksen tuotekehitystä ohjattiin usean tasoisilla product backlogeilla ja koordinointia sekä tuotehallintaa tehtiin product owner groupeissa. Työn tekemistä kehitettiin ja koordinoitiin scrum of scrumeissa. Yrityksen laajuisen jatkuvan integraatiojärjestelmän avulla uusi julkaisu yrityksen kymmenistä järjestelmistä voitiin tehdä päivässä viikkojen sijaan. Kehitystiimit olivat itsenäisiä tuotetiimejä, jotka kehittivät kaikkia arkkitehtuurikerroksia oman tuotteensa osalta. Kehittäjien moraali oli korkealla tiimityön tuoman vapauden, fokuksen ja korkean laadun vuoksi.
Kuva 2: Yrityksen Scrum-tuotekehitysorganisaatio
Tuotekehitysosaston johtajalla oli erityinen syy tyytyväisyyten. Johtajan henkilökohtaiset kannustimet oli sidottu tuotekehitysosaston tuottavuuteen, eli hänelle maksettiin bonuksia siitä kuinka nopeasti hänen osastonsa tuotti tuotteita tuotekehitysaihioista. Moninkertainen tuottavuus tarkoitti merkittäviä bonuksia.
Juhlallisuuksien lomassa muutoksesta vastuulliset keskijohdon edustajat tapasivat liiketoimintayksikön johtajan, joka kertoi karun näkemyksensä edistymisestä: “En tiedä mitä olette saaneet aikaan, mutta liiketoiminnan näkökulmasta mikään ei ole muuttunut. Tuotteiden saaminen asiakkaalle kestää kaksi vuotta eikä tyytyväisyys ole noussut tippaakaan.” Tämä herätti suurta kummastelua. Keskijohto käynnisti selvityksen, jossa kahden keskijohdon edustajan tuli selvittää mistä tämä kommentti oikein kumpusi. Tuotekehitysosastolla vallitsi hämmennys: eikö kahden vuoden onnistuneen projektin jälkeinen juhlinta olekaan aiheellista?
Selvittäjät vaihtoivat perspektiiviä tuotekehitysosastosta koko organisaatioon. He kartoittivat yrityksen tuotekehitysvirran aina tuoteideasta konseptoinnin kautta kehitykseen ja asiakastoimitukseen. Virran kartoitus tehtiin kahdesti eri osallistujilla jotta tuloksia voitaisiin verrata toisiinsa. Kahden kuukauden selvityksen jälkeen heillä oli mykistävä tulos: tuotekehityksen tehostuminen oli hidastanut läpimenoaikoja suhteessa alavirtaan. Viivästykset johtuivat osastojen väleihin syntyneistä työjonoista joita esiintyi sekä ennen ohjelmistokehitysvaihetta että tämän jälkeen. Radikaaleimmat numerot saatiin kun laskettiin tuotekehityskaaren kokonaiskestoaika (läpimenoaika) sekä eriteltiin työvaiheet joissa tuotteeseen lisätään arvoa ja sellaiset työvaiheet, kuten jonossa odottelu, joissa arvoa ei lisätä. Tuotteen läpimenoajaksi saatiin kaksikymmentä kuukautta josta ainoastaan neljän kuukauden ajan tuotteeseen lisättiin arvoa eli sitä kehitettiin. Loput kuusitoista kuukautta työn alla oleva tuote odotti seuraavaa työvaihetta. Onnistuneen ketteryyden skaalaamisenkin jälkeen tuokehitysprosessin tehokkuus on vain 20%!
Kuva 3: Yrityksen tuotekehitysvirta lähtötilanteessa.
Kuva 4: Yrityksen tuotekehitysvirta 2 vuoden jälkeen. Yrityksenlaajuinen Scrum käytössä.
Tuotekehityksen ketteröittäminen ja uusi alustaratkaisu olivat leikanneet tuotekehityksen sisäistä läpimenoaikaa kuudesta kuukaudesta kahteen kuukauteen, mutta samalla tämä muutos lisäsi käyttöönoton jonoa yhä kiihtyvällä tahdilla. Käyttöönoton jonon syynä oli epävakaa tuotantoympäristö johon ei haluttu viedä muutoksia kuin kokemuksen synnyttämällä varovaisella prosessilla. Kun käyttöönoton jonoa tarkasteltiin niin sieltä löydettiin tuotteita, jotka olivat kaksi vuotta vanhoja ja joista oli jo uusi versio kehitteillä. Jonojen syntyyn löytyi lukuisia syitä, kuten esimerkiksi tuotekehitysvirran vaiheiden vastuuttaminen eri organisaatio-osille, joiden kannustimet johtivat virran kannalta paikalliseen optimiin (alioptimointiin) koko järjestelmän kärsiessä.
Tuotekehitysvirtaa lähdettiin korjaamaan merkittävin muutoksin:
- tuotekehitys- ja käyttöönotto-osastot järjesteltiin uudestaan
- kehitystiimit muodostettiin poikkifunktionaaliseksi siten, että ne pystyivät itsenäisesti kehittämään tuotteen konseptin, ohjelmiston ja viemään sen asiakaskäyttöön
- teknistä infrastruktuuria kehitettiin edelleen edellisen mahdollistamiseksi
- jonoihin tartuttiin hanakasti: joko ne poistettiin tai niiden kokoa rajoitettiin hylkäämällä vanhentuneita tuotoksia
- tuotekehitysvirran tarkastelu otettiin keskeiseksi johtamisen aiheeksi
Kuva 5: Yrityksen tuotekehitysvirta 2,5 vuoden jälkeen. Tuotekehitysvirtaa johdetaan aktiivisesti.
Edellämainituilla muutoksilla yritys leikkasi tuotekehityksen läpimenoaikaa (concept to cash) kahdestakymmenestä kuukaudesta kolmeen kuukauteen. Yrityksen kyky reagoida asiakastarpeeseen parantui huomattavasti ja asiakastyytyväisyys nousi merkittävästi.
Jälkitarkastelu: mitä tapahtui?
Jälkikäteen tarkasteltuna tarinassamme on useita mielenkiintoisia kohtia alkaen ongelman asettelusta päättyen kokonaiskuvan johtamiseen ja organisaation siiloihin.
Tarinan alkuvaiheessa liiketoiminnasta vastaavien henkilöiden asettama ongelma oli kohdallaan, mutta ratkaisuun hypättiin liian varhaisessa vaiheessa. Syitä tähän oli muutamia. Liiketoimintaosasto oli jo pidemmän aikaa ollut tyytymätön tuotekehitysosaston tuottamien ohjelmistojen määrään. Toisaalta tuotekehitysosaston sisällä graafisesta suunnittelusta vastaavat henkilöt olivat kummissaan koska näkivät oman kättensä jäljen vuosien viiveellä asiakaskäytössä. Lisäksi ikääntynyt tekninen alusta oli yleinen jupinan kohde ja toimi valmiina syntipukkina. Koska havaittuun ongelmaan (hidas kehitys) oli valmiina selkeä syy (vanha tekninen alusta) ja tähän ratkaisu (uusi tekninen alusta) ei kenellekään tullut mieleen ruveta selvittämään syvällisemmin mistä tuotekehitysputken tukkoisuus voisi johtua. Tällöin tuotekehitysosasto lähti korjaamaan eniten jupinaa aiheuttavaa oiretta ja taustalla vaikuttavat hiljaiset juurisyyt jäivät huomiotta.
Tuotekehitysosaston kahden vuoden projektin voitonjuhlien jälkeen aiheutunut kankkunen on helppo selittää. Osastolle oli asetettu haastava tavoite joka oli saavutettu, mutta valitettavasti tavoite oli asetettu väärin yrityksen liiketoiminnan näkökulmasta. Tuotekehityksen ensisijaiset pullonkaulat olivat valmiiden konseptien suuressa määrässä sekä käyttöönotossa. Konseptien määrän selitti suurelta osalta liiketoimintaosaston innokkuus. Osasto olisi halunnut myydä ja markkinoida kymmenkertaisen määrän ohjelmistoja kuin mitä alla oleva tuotekehitysorganisaatio olisi kyennyt valmistamaan. Valmiita konsepteja ja ohjelmistoja kasautui jonoihin kymmenittäin vanhentumista odottamaan. Mikä pahinta, kasvavat jonot tarkoittavat sitä, että uuden tuotteen kehitykseen kuluva aika kasvaa kasvamistaan ja tilanne pahenee ajan kuluessa.
Oman kortensa kekoon kantoivat osastojen siiloutumisen aiheuttama eripura. Liiketoimintaosaston näkökulmasta hidas tuotekehitysosasto on syyllinen hitaaseen kehitykseen. Tuotekehitysosaston näkökulmasta liiketoimintaosasto toivoo mahdottomia eikä ymmärrä käytännön tekemisen rajoituksia. Myöhemmässä vaiheessa tuotekehitysosaston näkökulmasta käyttöönotosta ja tuotannosta vastaava osasto oli syyllinen koska se ei kyennyt viemään uusia tuotteita tuotantoon tarpeeksi tehokkaasti. Kukin osasto kuitenkin täytti tehtävänsä parhaalla näkemällään tavalla. Liiketoiminta myi mahdollisimman paljon, tuotekehitys kehitti mahdollisimman paljon ja käyttöönotto yritti viedä tuotantoon mahdollisimman paljon sekä yritti pitää monimutkaistuvan tuotantojärjestelmän vakaana ja toimintakuntoisena. Osastot muodostivat siis omat siilonsa joilla oli omat tavoitteensa ja kannustimensa. Valitettavasti yrityksen liiketoiminnan näkökulmasta tavoitteet olivat ristiriitaisia. Kassavirta muodostuu asiakkaiden käyttämistä ohjelmistoista joten tavoitteena tulisi tuottaa asiakkaille mahdollisimman paljon ajantasaisia ohjelmistoja. Koska eri osastot eivät tätä yhteistä tavoitetta jakaneet eivätkä ymmärtäneet toimitusketjua kokonaisuudessaan perusteet osastojen väliselle yhteishengelle ja yhteistyölle olivat hatarat.
Tarinamme keskivaiheilla keskijohto tarkasteli organisaatiota kokonaisuutena asiakkaiden arvon tuottamisen näkökulmasta selvittämällä ja piirtämällä yrityksen tuotekehitysvirran valkotaululle. Virtaa tarkasteltaessa selvisi hyvin nopeasti, että lukuisat jonot estivät yritystä tuottamaan systeemiajattelusta tuttua value demandin mukaista arvoa. Tämän takia failure demandin tutkimiseen ei käytetty aikaa. Spekuloinnin ongelmien syistä ja syntipukeista korvasi karun todellisuuden ymmärtäminen ja liiketoiminnallisesti merkittävät mittarit (kassavirta ja läpimenoaika). Selvisi, että ongelma ei ole yhdessäkään osastossa vaan osastojen välisessä interaktiossa eli ongelma oli systeeminen eikä yhdenkään osaston vika. Ymmärrys mahdollisti sen, että syyttelyn sijaan voitiin keskittyä organisaation uudelleensuunnitteluun ja parantamiseen. Yrityksen tuotekehitysvirtaa johdettiin kokonaisuutena ensimmäistä kertaa.
Valitettavasti oppiakseen yrityksen piti ensin tehostaa tuotekehitysosaston tuottavuutta. Tämä todisti sen, ettei tuotekehitysosasto ollutkaan yrityksen pullonkaula. Tämä sai keskijohdon muuttamaan ajatteluaan ja tarkastelemaan tuotekehitystä systeemisenä kokonaisuutena asiakkaan näkökulmasta.
Ilmiöitä selittäviä teorioita
Tässä artikkelissa tarkasteltuja ilmiöitä selittävät muun muassa seuraavat mallit ja teoriat:
Responsibility model (Christopher Avery)
Lean thinking (Taiichi Ohno, Jeffrey Liker, Womack & Jones)
Theory of constraints (Eliyahu Goldratt)
Principles of flow (Donald G. Reinertsen, W. Edwards Deming)
Value demand, failure demand (John Seddon)
Systems thinking (Russell Ackoff, John Seddon, W. Edwards Deming)
Complex adaptive systems (esim. Dave Snowden)
Double-loop learning (Chris Argyris)
Systeemiajattelun perusteita sivutaan nasevasti seuraavassa videossa: If Russ Ackoff had given a TED Talk…
Mitä opimme
- Pysyvä muutos vaatii muutoksen johdon ajattelutavassa
- Liiketoiminnallisen hyödyn saaminen ketteryydestä edellyttää systeemin johtamista
- Järjestelmän tarkastelu on aloitettava sen tarkoituksesta, eli siitä näkökulmasta jolle järjestelmä tuottaa arvoa (yrityksissä asiakkaat)
- Organisaation rakenteet (siilot) saattavat olla este ketteryydelle ja tulosten aikaansaamiselle
- Ketteryyttä kannattaa soveltaa tunnistetun, mitatun tarpeen mukaan; ei itseisarvoisesti
Tämä artikkeli on lainattu kirjasta “376 vuotta ketteriä kokemuksia”. Alkuperäisen artikkelin ovat kirjoittaneet Ari Tanninen ja Marko Taipale. Kirjan muut kirjoittajat ovat: Antti Auer, Liisa Auer, Miikka Heinäsmäki, Jussi Hölttä, Eija Kalliala, Maarit Laanti, Kati Laine, Lere Lekman, Paula Miinalainen, Heikki Naski, Timo Piiparinen, Hannu Puhakka, Maaret Pyhäjärvi, T. Pääkkönen, Silja Räisänen, Henri Sora, Jukka Talvio, Tarmo Toikkanen, Towo Toivola, Kimmo Toro, Anne Valsta, Virve Väyrynen, Martin von Weissenberg Kirja on lisenssoitu seuraavalla lisenssillä:
Tämän teos teoksen käyttöoikeutta koskee Creative Commons Nimeä 3.0 Muokkaamaton -lisenssi.
