Lean-ohjelmistotuotanto

hyväksymispäivä arvosana arvostelija Lean-ohjelmistotuotanto Satu Kärkkäinen Helsinki 13.12.2017 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

HELSINGIN YLIOPISTO - HELSINGFORS UNIVERSITET - UNIVERSITY OF HELSINKI Tiedekunta Fakultet Faculty Matemaattis-luonnontieteellinen tiedekunta Laitos Institution Department Tietojenkäsittelytieteen laitos Tekijä Författare Author Satu Kärkkäinen Työn nimi Arbetets titel Title Lean-ohjelmistotuotanto Oppiaine Läroämne Subject Tietojenkäsittelytiede Työn laji Arbetets art Level Kandidaatintutkielma Tiivistelmä Referat Abstract Aika Datum Month and year 13.12.2017 Sivumäärä Sidoantal Number of pages 22 sivua Toyota alkoi 1940-luvun lopussa valmistaa pieniä eriä edullisia autoja menetelmällä, jonka avulla tuotantoa saatiin tehostettua. Toyotan tuotantomenetelmästä syntyi kaikille aloille sopiva Lean-ajattelu, jonka avulla pyritään tekemään vähemmällä enemmän. Mary ja Tom Poppendieck sovittivat Lean-ajattelun ohjelmistotuotantoon sopivaksi. He ovat kehittäneet seitsemän ohjelmistotuotannon periaatetta ja käytäntöjä, joiden avulla periaatteet saadaan käyttöön. Lean-ajattelu kattaa koko liiketoimintaympäristön. Ensisijaisena tavoitteena on poistaa arvoa tuottamaton toiminta. Lean-ohjelmistotuotanto pyrkii parantamaan ohjelmiston laatua, kasvattamaan asiakastyytyväisyyttä, pienentämään kustannuksia ja lyhentämään tuotannon läpimenoaikoja. Menetelmien käyttöönottoon liittyy paljon haasteita, koska varsinaisia sääntöjä ei ole. Käytännöistä voi valita sopivimmat tai niitä voi yhdistellä muiden menetelmien kanssa. ACM Computing Classification System (CCS): Software and its engineering Software creation and management Software development process management Software development methods Avainsanat Nyckelord Keywords Lean, tuotanto, ohjelmistotuotanto, Lean-startup, Lean-ajattelu, ketterä ohjelmistokehitys Säilytyspaikka Förvaringsställe Where deposited Muita tietoja Övriga uppgifter Additional information

Sisältö 1 Johdanto... 1 2 Lean-ajattelu... 3 3 Lean-ohjelmistotuotannon periaatteet... 5 3.1 Poista hukka... 5 3.2 Rakenna laatua... 8 3.3 Opi jatkuvasti... 9 3.4 Päätä mahdollisimman myöhään... 9 3.5 Toimita nopeasti... 10 3.6 Arvosta ihmisiä... 10 3.7 Optimoi kokonaisuus... 11 4 Lean-periaatteet käytännössä... 11 5 Lean startup-menetelmä... 14 6 Ketterä ohjelmistokehitys... 15 7 Haasteet ja menestystekijät Lean-ohjelmistotuotannossa... 16 7 Yhteenveto... 19 Lähteet... 21

1 Johdanto Autovalmistaja Toyota Motor Corporation (TMC), lyhyemmin Toyota, perustettiin vuonna 1937. Tyynenmeren sodan aikaan yritys valmisti kuorma-autoja armeijan käyttöön ja sodan jälkeen tuotantokiellon rauettua se aloitti kaupallisen henkilöautotuotannon (Section 6. Postwar Arrangements and Labor Disputes 2006) Talousvaikeuksista kärsivässä Japanissa automarkkinat eivät olleet riittävän suuret, jotta massatuotanto olisi ollut kannattavaa, joten tarvittiin menetelmä, jolla voitaisiin valmistaa pieniä määriä hinnaltaan edullisia ajoneuvoja (Poppendieck & Poppendieck 2003: 1). Toyota alkoi 1940-luvun lopussa valmistaa autoja menetelmällä, jonka avulla työtunteja kului vähemmän ja varaston kiertonopeus oli nopeampi kuin kilpailijoilla (M. Poppendieck & M. A. Cusumano 2012: 26). Menetelmän taustalla oli Taiichi Ōno, yksi Toyotan tuotantojärjestelmän (TPS, Toyota Production System) kehittäjistä. Toyotan tuotantojärjestelmä jätettiin muualla suurelta osin huomiotta vuoden 1973 öljykriisiin asti, jolloin monien yritysten kannattavuus laski (Poppendieck & Poppendieck 2008: 7). Toyota kuitenkin toipui kriisistä nopeasti ja muut yritykset kiinnostuivat, mitä Toyotan nousun takana oli. Tuotannon keskeisiä tavoitteita oli valmistaa juuri oikea määrä tuotteita juuri oikeaan aikaan (JIT, Just-In-Time ), sekä minimoida sellaisten prosessien määrä, jotka eivät tuota lisäarvoa asiakkaalle tai lisää tietoa siitä, miten tämä arvo saavutetaan (M. Poppendieck & M. A. Cusumano 2012: 8). Tällaista lisäarvoa tuottamatonta prosessia kutsutaan hukaksi (Waste). Termi lean otettiin käyttöön kirjassa The Machine That Changed the World (Womack, Jones & Roos 1990) kuvaamaan muun muassa Toyotan käyttämää menetelmää, joka minimoi hukan määrän. Samalla JIT laajennettiin sopimaan autoteollisuudesta mihin tahansa ympäristöön. Suomen kielessä lean voidaan korvata termillä sutjakka. Käsite Lean-ajattelu on peräisin Womackin ja Jonesin vuonna 1996 julkaistusta kirjasta Lean Thinking, jossa he esitelevät viisi periaatetta, joilla organisaatiota voidaan kehittää sutjakkaammaksi. Lean-ajattelun avulla asiakkaan toiveet pyritään toteuttamaan käyttäen vähemmän esimerkiksi ihmisen suorittamaa työtä, aikaa, laitteita tai tilaa. Lean-ajattelu esitellään tarkemmin luvussa 2. Vaikka Lean-tuotannon alkuperä on autoteollisuudessa, sen periaatteet soveltuvat myös muiden alojen käyttöön. Muun muassa ohjelmistokehityksessä on alettu hyödyntää Toyotan tuotantojärjestelmän ajattelumallia hyvin tuloksin (P. Middleton & D. Joyce 2012). Ohjelmiston 1

kehittäminen vaatii innovointia, validointia ja muutosten tekemistä ennen kuin tuote on valmis, kun taas teollisuuden tuotantoprosessi pyrkii saavuttamaan toiminnallisen huippuosaamisen (Sharma & Gandhi 2016: 6-7). Mary ja Tom Poppendieck (2003) ideoivat seitsemän ohjelmistotuotantoon soveltuvaa, Lean-tuotantoon pohjautuvaa toimintaperiaatetta ja joukon käytäntöjä, joiden avulla voidaan työskennellä periaatteiden mukaisesti. Heidän periaatteensa esitellään luvussa 3 ja käytännöt luvussa 4. Luvussa 5 esitellään Lean Startup-menetelmä, joka soveltuu startup-yritysten käyttöön ja uusien tuotteiden innovointiin (Eric Ries 2011). Innovointimalli pyrkii lyhentämään tuotteen kehitysjaksoja sekä vähentämään työmäärää, aikaa ja kuluja. Asiakkailta saadun palautteen perusteella pyritään luomaan tuote, jota asiakas pitää arvokkaana ja josta hän on valmis maksamaan. TPS ja Lean-ohjelmistotuotannon kehittymiseen vaikuttaneet merkittävät julkaisut ovat aikajärjestyksessä kuvassa 1. n. 1950- TPS 1990 The Machine That Changed the World 1996 Lean Thinking 2001 Agile Manifesto 2003 Lean Software Development: An Agile Toolkit 2011 The Lean Startup Kuva 1: Lean-ohjelmistotuotannon merkittävät julkaisut Aluksi Lean-menetelmiä on käytetty pääasiassa yksityisen sektorin yrityksissä. Sittemmin myös julkinen sektori on osoittanut kiinnostusta menetelmiä kohtaan tarjotakseen parempia palveluita kansalaisille, jotka odottavat nopeita muutoksia ja parannuksia (Sharma & Gandhi 2016: 5). Muun muassa sähköisen asioinnin avulla palvelut on tehty tavoitettaviksi syrjäisillä alueilla. Palveluja pystytään tarjoamaan sähköisesti ilman ajan ja tilan tarvetta (Tang, Miao & Xi 2010: 150-151). Sähköinen hallinto mahdollistaa myös paremman vuorovaikutuksen ja yhteistyön eri yksiköiden välillä. Ketterää ja Lean-kehitysmenetelmää pidetään usein hyvin samanlaisina (Hibbs, Jewett & Sullivan 2009: 16). Ketterällä (Agile Software Development) ja Lean-ohjelmistokehityksellä on tavoitteena parantaa tuottavuutta ja samalla lisätä ohjelmiston laatua. Menetelmien erona on perspektiivi ja ajattelutapa, joita käsitellään luvussa 6. Lean-ohjelmistokehityksen toteutuksessa onkin melko tavallista yhdistää ketteriä ja Lean-menetelmiä. 2

2 Lean-ajattelu Womackin ja Jonesin (2003: 10) Lean-ajattelu tiivistyy viiteen periaatteeseen (kuva 2): arvon (Value) määritteleminen, arvovirran (The Value Stream) tunnistaminen, arvon tuottaminen jatkuvana virtauksena (Flow), imuohjattu (Pull) tuotanto ja täydellisyyteen pyrkiminen (Perfection). Ajattelutavan on katettava kaikki vaiheet alun ideasta sen elinkaaren loppuun saakka. 5 Täydellisyyteen pyrkiminen 1 Arvon määritteleminen 4 Imuohjaus 2 Arvovirran tunnistaminen 3 Tuottaminen virtauksena Kuva 2: Lean-ajattelun viisi periaatetta Lean-ajattelun lähtökohtana on arvo ja sen tuottaminen (Womack & Jones 2003: 16-19). Asiakas määrittää tuotteen lopullisen arvon, joten yrityksen on ymmärrettävä, minkä arvon asiakas asettaa tuotteelle ja paljonko hän on valmis maksamaan siitä. Pyrkimyksenä on poistaa arvoa tuottamaton hukka prosesseista ja valmistaa tuote mahdollisimman pienin kustannuksin. Arvovirta sisältää joukon toimia, joita vaaditaan tuotteen valmistamiseksi. Se kattaa kaikki tuotteen suunnitteluun, valmistamiseen ja toimittamiseen sisältyvät toimenpiteet. Ymmärtämällä arvovirran, voidaan havaita tuotteen valmistusprosessiin liittyvät arvoa tuottavat sekä tuottamattomat tapahtumat (Womack & Jones 2003: 19-21). Ohjelmiston aineettomuus vaikeuttaa arvovirran kartoittamista (Sharma & Gandhi 2016: 4). Arvovirtakuvauksen (Value Stream Map, VSM) tekeminen on hyvä keino arvioida ja parantaa ohjelmistotuotantoprosessia (Poppendieck & Poppendieck 2009: 9-10). Arvovirtakuvaus on visuaalinen kokonaiskuvaus prosessin vaiheista. Kuvauksen alareunassa on aikajana, jolle asetetaan arvoa lisäävät ja lisäämättömät toiminnat. Kuvassa 3 on merkinnät, joita käytetään arvovirtakuvausta piirrettäessä (Mujtaba, Feldt & Petersen 2010: 140). 3

Työvaihe Työvaihe Käsittely Odottaminen Käsittely Arvoa lisäävä toiminta Arvoa lisäämätön toiminta Arvoa lisäävä toiminta Aikajana Kuva 3: Arvovirtakuvauksessa käytettävät merkinnät Kun arvo on täsmennetty, arvovirta kartoitettu ja turhat vaiheet poistettu, on aika suorittaa arvokkaiksi koetut tehtävät. Tavoitteena on luoda tehtävistä alati virtaava tuotantoprosessi, joka ei pysähdy. Keskeytyksetön tuotanto minimoi hukan määrän, vähentää työhön kuluvaa aikaa ja nostaa tuotteen arvoa (Womack & Jones 2003: 21-24). Virtaus sisältää virtausyksiköitä (Flow unit), jotka ovat yleensä materiaaleja, tietoa tai ihmisiä (Lehtonen ym. 2016: 74). Läpimenoaika (Lead time) on aika, joka yksiköltä kuluu virrata prosessin alusta loppuun. Ohjelmistotuotannossa virtausyksikkö on muun muassa ohjelmistoon toteutettu uusi ominaisuus, virheenkorjaus tai refaktorointi. Läpimenoaikaa voidaan parantaa nopeuttamalla käyttöönottoa (ibid. 77). Tiheällä julkaisutahdilla hukan poistaminen tapahtuu useasti ja palautteensaanti nopeutuu. Lean-ajattelun on todettu lyhentävän läpimenoaikoja (P. Middleton & D. Joyce 2012: 30). Perinteisessä tuotannossa tuotteet niin sanotusti työnnetään (Push) eteenpäin noudattaen etukäteen tehtyjä ennusteita ja aikatauluja. Kun kyetään tekemään täsmälleen oikeaan aikaan mitä asiakas haluaa, tuotteita ei tarvitse tehdä varastoon odottamaan, vaan ne tehdään pyyntöjen perusteella. Toisin sanoen asiakas imee (Pull) tuotteen itselleen. Pull-lähestymistapa varmistaa, ettei valmisteta sellaista, jota asiakas ei halua (Womack & Jones 2003: 24-25). Lean-ajattelua toteuttava yritys asettaa tavoitteensa täydellisyyteen (Womack & Jones 2003: 25-26). Ideaalitilanteessa hukka poistetaan niin täydellisesti, että kaikki arvovirran toiminnot luovat arvoa. 4

3 Lean-ohjelmistotuotannon periaatteet Mary ja Tom Poppendieck (2009: xxv-xxvii) esittelivät kirjassaan joukon ohjelmistotuotantoon soveltuvia, Lean-tuotantoon pohjautuvia toimintaperiaatteita, joista he korostivat seitsemää: poista hukka (Eliminate Waste), opi jatkuvasti (Amplify Learning), päätä mahdollisimman myöhään (Decide as Late as Possible), toimita mahdollisimman nopeasti (Deliver as Fast as Possible), sitouta henkilöt (Empower the Team), luo laatua (Build Integrity in) ja näe kokonaisuus (See the Whole). Myöhempien kokemusten perusteella periaatteet muutettiin seuraaviksi: poista hukka (Eliminate Waste), rakenna laatua (Build Quality in), opi jatkuvasti (Create Knowledge), päätä mahdollisimman myöhään (Defer Commitment), toimita nopeasti (Deliver Fast), arvosta ihmisiä (Respect People) ja optimoi kokonaisuus (Optimize the Whole) (Poppendieck & Poppendieck 2008). Seuraavissa alaluvuissa esitellään nämä periaatteet tarkemmin. 3.1 Poista hukka Työ voidaan jakaa arvon ja tärkeyden mukaan kolmeen luokkaan: arvoa lisäävä toiminta, lisäarvoa tuottamaton, mutta välttämätön toiminta ja arvoa lisäämätön toiminta. Työ, joka ei tuota lisäarvoa asiakkaalle on hukkaa. Ideaalitilanteessa selvitetään aluksi, mitä asiakas haluaa ja sen jälkeen tehdään tai kehitetään se välittömästi vaatimusten mukaan (Poppendieck & Poppendieck 2009: xxv). Tämä on kuitenkin käytännössä mahdotonta. Ensimmäisenä täytyy oppia huomaamaan, mikä on hukkaa (Poppendieck & Poppendieck 2008: 23-24). Tämän jälkeen pitää toistuvasti etsiä suurimmat hukan aiheuttajat ja poistaa ne. Poppendieckit (2008: 74) listaavat seitsemän ohjelmistotuotannossa yleisesti esiintyvää hukkaa: osittain tehty työ, lisäominaisuudet, uudelleenopettelu, siirrot, tehtävien vaihdot, viivästykset ja viat. Ohjelmistotuotannossa osittain tehtyä työtä on toiminto, jota ei ole testattu, toteutettu, integroitu, dokumentoitu tai otettu käyttöön. Osittain tehty työ vie resursseja tehtäviltä, jotka voitaisiin tehdä loppuun. Keskeneräiset toiminnot, jotka eivät tuota asiakkaalle tai käyttäjälle lisäarvoa ovat hukkaa ja niiden määrä tulisi pitää minimissä. Poppendieckien (2008: 75) mielestä lisäominaisuudet ovat suurin ohjelmistotuotannossa esiintyvä hukka. Toimintoja tai kokeiluja ei kannata tehdä siinä uskossa, että niitä saatetaan tarvita myöhemmin. Ominaisuus tulisi kehittää vain, jos sille on kyseisellä hetkellä selkeä ja taloudellinen tarve. Ylimääräistä koodia ei tulisi kirjoittaa järjestelmän monimutkaistumisen 5

sekä mahdollisen tarpeettomaksi tulemisen tai vanhenemisen vuoksi. Turhan koodin kirjoittaminen vaikuttaa projektiin useilla tavoilla, joista selvin on siihen kuluva aika. Sen lisäksi koodimäärän kasvaessa myös komponentteja tulee lisää, vikojen mahdollisuus lisääntyy, koodin omaksuminen vaikeutuu sekä kehittämis- ja ylläpitokustannukset kasvavat (Hibbs, Jewett & Sullivan 2009: 72). Ohjelmistotuotannossa on tärkeää osata hyödyntää työntekijöiden osaamista ja kokemusta. Opitut asiat saattavat toisinaan unohtua, jolloin työntekijä joutuu opettelemaan aiemmin opitun asian uudelleen. Asioita voidaan joutua tekemään turhaan uudelleen tilanteissa, joissa jätetään huomiotta tietämys, joka ihmisillä on. Olemassa oleva tieto tulisi jakaa niin, että se on aina jokaisen sitä tarvitsevan saatavilla. Kun työ siirretään tekijältä toiselle, suuri määrä hiljaista tietoa jää siirtymättä vaihdon mukana. Jokainen siirto työntekijältä toiselle kadottaa Poppendickien (2008: 77) arvion mukaan 50 prosenttia tiedon määrästä. Kahden siirron jälkeen tiedosta on jäljellä 25 prosenttia, kolmen siirron jälkeen 12 prosenttia ja niin edelleen. Siirroista johtuvaa hukkaa voidaan vähentää parantamalla kommunikointia ja pitämällä vaihtojen määrän minimissä. Ohjelmiston kehittäminen vaatii paljon ajatustyötä. Siirtyminen tehtävästä toiseen häiritsee keskittymistä, on aikaa vievää ja heikentää usein tuloksia. Usean tehtävän suorittaminen samaan aikaan hidastuttaa niiden valmistumista. Koska osittain tehty työ lasketaan hukaksi, tulisi tehtävät tehdä mieluummin yksi kerrallaan valmiiksi kuin pitää useampaa samaan aikaan keskeneräisenä. Viivästyksellä tarkoitetaan tilannetta, jossa tehtävää ei voi jatkaa tai suorittaa loppuun. Henkilö, jonka tietoa tai osaamista tarvitaan työn etenemiseen, saattaa olla kiinni toisessa tehtävässä, jolloin avun tarvitsija voi keskeyttää tehtävän ja yrittää hankkia tarvitsemansa tiedon, vaihtaa toiseen tehtävään tai yrittää jatkaa eteenpäin arvaamalla, miten tulisi edetä. Lyhyissä odotuksissa tauon pitäminen saattaa aiheuttaa vähemmän hukkaa kuin toiseen tehtävään vaihtaminen tai arvaaminen (Sedano, Ralph & P 'eraire 2017: 137). Vioista ja niiden korjaamisesta syntyy suuri määrä hukkaa lisääntyvien työtuntien ja kulujen muodossa (Poppendieck & Poppendieck 2009: 5-8). Kattavalla testauksella voidaan havaita uudet viat varhaisessa vaiheessa ja estää samojen vikojen syntyminen uudelleen. Testit kertovat myös yksityiskohtaisesti, kuinka koodin odotetaan toimivan ja mitkä testitapaukset on läpäistävä. Siten saadut testitulokset toimivat ajantasaisena dokumentaationa. 6

Aiemmin mainittujen lisäksi ohjelmistotuotannossa hukaksi on havaittu muun muassa tarpeettoman monimutkaiset ratkaisut, kognitiivinen kuormitus, henkiset rasitteet ja tehoton viestintä (Sedano, Ralph & P 'eraire 2017: 139). Monimutkaiset ratkaisut voivat johtua osaamisen puutteesta, tehtävän hankaluudesta, teknisestä haasteesta tai uudelleenkäytön puutteesta. Joissakin tapauksissa sama ongelma voidaan ratkaista yksinkertaisemmalla toteutuksella. Toinen tapa lisätä järjestelmän monimutkaisuutta on rakentaa uusi komponentti sen sijaan, että käytettäisiin olemassa olevaa. Uudelleenkäytön puute ilmenee tuplakoodina tai komponentteina, joilla on samanlaiset toiminnot. Suuren tietomäärän käsittely ja muistaminen aiheuttavat työntekijälle kognitiivista kuormitusta. Koska työntekijöiden henkinen kapasiteetti on rajallinen, liiallista kognitiivista kuormitusta pidetään hukkana. Sedano ym. (2017: 136-137) havaitsivat, että kognitiivisesti kuormittavia asioita ovat muun muassa monimutkaiset vaatimusten kuvaukset, huonot työvälineet, tekninen velka ja usean tehtävän tekeminen samaan aikaan. Henkisiä rasitteita, kuten määräajan jatkuvasta seuraamisesta aiheutuvaa stressiä pidetään hukkana samasta syystä kuin kognitiivista kuormitusta. Henkiset rasitteet kuluttavat työntekijän voimavaroja sekä aiheuttavat tuottavuuden heikkenemistä, poissaoloja ja terveysongelmia (ibid. [(Westman & Etzion 2001)]). Tehotonta viestintää on puutteellinen tai virheellinen kommunikointi. Sedano ym. (2017: 137) huomasivat, että suuri tiimikoko, asynkroninen viestintä, viestinnän epätasapaino ja turhat kokoukset heikensivät tuottavuutta. Sharman ja Gandhin (2016) mukaan kaksi suurinta hukkatyyppiä tietotekniikka-alalla ovat arvoa tuottamaton käsittely ja pitkät odotukset, jotka yhteensä vaikuttavat noin 65 prosenttiin tunnistetun hukan kokonaismäärästä (kaavio 1). Arvoa tuottamaton käsittely johtuu pääasiassa puutteellisesta viestinnästä. Odotus puolestaan johtuu sovelluksen hitaista vasteajoista ja manuaalisista menetelmistä. 7

120 100 80 92 70 65 79 88 94 97 99 100 60 40 20 37 35 24 13 8 5 3 0 kpl % Kaavio 1: Tutkimustulokset tietotekniikka-alan yrityksessä esiintyvästä hukasta kuukauden ajalta 3.2 Rakenna laatua Laadun rakentaminen tarkoittaa, että tuotetta tehdään alusta loppuun saakka laatua silmällä pitäen, eikä laadun varmistusta jätetä loppuvaiheeseen. Perinteisissä kehitysmalleissa integraatio suoritetaan projektin lopussa, jolloin saattaa syntyä paljon konflikteja. Leanperiaatteisiin sopiva käytäntö on jatkuva integraatio (Continuous Integration), jossa komponentit koostetaan jatkuvasti yhdeksi kokonaisuudeksi ja nähdään, rakentuuko ohjelmisto oikein (M. Poppendieck & M. A. Cusumano 2012: 28). Testaus ja tulosten raportointi aina muutosten yhteydessä tarjoavat välittömän palautteen kehittäjille (Hibbs, Jewett & Sullivan 2009: 55). Laatuun tähtäävä periaate ei salli jonoja, joihin kerätään vikoja odottamaan korjausta (Poppendieck & Poppendieck 2008: 27). Vian löydyttyä työvaihe tulisi keskeyttää ja korjaustoimenpiteisiin pitäisi ryhtyä heti. Koodi, jossa on täydelliset testit, auttaa vähentämään todennäköisyyttä, että havaitsemattomat virheet otetaan käyttöön ohjelmistossa (Hibbs, Jewett & Sullivan 2009). 8

3.3 Opi jatkuvasti Ohjelmiston kehittäminen on tiedon tuottamista ja sen sisällyttämistä tuotteeseen. Tiedon hankkimiseen on kaksi vastakkaista lähestymistapaa (M. Poppendieck & M. A. Cusumano 2012: 29). Tietoa voidaan hankkia tutkimalla ensin useita vaihtoehtoja ja viivästyttämällä päätöksiä viimeiseen hetkeen asti ("Learn first"), jolloin päätökset tehdään parhaan käytettävissä olevan tiedon perusteella. Toinen tapa on oppia jatkuvasti ( Learn constantly ). Tällöin vähimmäisvaatimukset tehdään toistuvasti valmiiksi, ne toimitetaan asiakkaalle ja käytetään asiakaskokemuksesta saatua palautetta päätösten tekemisen apuna. Jatkuva palautteen saaminen varmistaa, että kehitetään sellaisia ominaisuuksia, joita asiakkaat pitävät arvokkaina. Ohjelmiston monimutkaisessa ympäristössä on aina ongelmia, joiden syy tulisi löytää ja etsiä paras tapa ratkaista ne (Poppendieck & Poppendieck 2008: 31). Ideaalista on, ettei aiemmin tehtyjä virheitä toisteta tai aiemmin opittua opetella uudelleen (Hibbs, Jewett & Sullivan 2009: 20-21). Tieto tulisi dokumentoida niin, että se on muiden työntekijöiden saatavilla, jotta heidän ei myöskään tarvitse selvittää ratkaistuja asioita toistamiseen. 3.4 Päätä mahdollisimman myöhään Ohjelmistokehityksen aikana kriittiset ja peruuttamattomat päätökset tulisi tehdä viimeisellä mahdollisella hetkellä (Poppendieck & Poppendieck 2008: 32). Epävarmuuden ja ohjelmiston monimutkaisuuden vuoksi ongelmat pitäisi ratkaista tutkimalla ensin erilaisia ratkaisuvaihtoehtoja ja pitämällä kriittiset päätökset avoinna siihen asti, kun valinta on viimeistään tehtävä. Tämä ei tarkoita, että kaikkia päätöksiä olisi lykättävä, sillä vähemmän kriittisten päätösten tulisi olla peruttavissa, jotta suunnitelmia voidaan muuttaa helposti ja nopeasti. Päätösten viivästyttäminen antaa työntekijöille aikaa kerätä tarvittavat tiedot sopivan ratkaisun löytämiseksi ja lyhyet iteraatiot tarjoavat mahdollisuuden kerätä tarvittavat tiedot asiakaspalautteen muodossa (Hibbs, Jewett & Sullivan 2009). Kehittäjät voivat luoda prototyyppejä varhaisessa iteraatiossa, kerätä palautetta ja käyttää palautetta päättääkseen lopullisesta toteutuksesta myöhemmässä iteraatiossa. 9

3.5 Toimita nopeasti Sen lisäksi, että asiakkaat arvostavat nopeaa toimitusta, siitä on hyötyä myös yrityksille. Nopeasti toimittavat yritykset ovat onnistuneet poistamaan suuren määrän hukkaa prosesseistaan, säästämään kuluissa ja pienentämään vikojen määrää (Poppendieck & Poppendieck 2008: 34-35). Nopea toimitus vapauttaa osittain tehdyissä työvaiheissa olevia resursseja muille tehtäville ja pienentää riskiä, että asiakas ehtii muuttamaan vaatimuksia. Jotta toistuva ja luotettava nopea toimittaminen on mahdollista, työntekijöiltä vaaditaan kykyä reagoida asiakkaiden vaatimuksiin nopeasti. Asiakas saattaa päättää keskeyttää kehityksen tietyllä osa-alueella tai koko tuotteen osalta. Suunnittelu liian pitkälle tulevaisuuteen voi johtaa uudelleen toteuttamiseen, mikäli asiakkaan tarpeet muuttuvat. Nopeasti toimittamalla voidaan antaa asiakkaalle tuote arvioitavaksi säännöllisesti ja usein, jolloin asiakaspalautteella on keskeinen rooli meneillään olevassa kehitysprosessissa. (Hibbs, Jewett & Sullivan 2009). Sen perusteella voidaan tehdä muutoksia ja varmistaa, että lopputuote on se, mitä asiakas todella haluaa. 3.6 Arvosta ihmisiä Lean-periaatteiden mukaisen työskentelyn mahdollistaminen saattaa vaatia muutoksia organisaatiorakenteeseen. Erillisen kehitysosaston sijaan vastuu arvon etsimisestä ja luomisesta kuuluu jokaiselle, joka työskentelee tuotteen parissa (Poppendieck & Poppendieck 2008). Lean-ohjelmistotuotanto kannustaa tiimityöskentelyyn, jossa osallistuvilla ihmisillä on valtuudet tehdä päätöksiä. Ihmisten vastuun lisääminen, ryhmätyöskentelyyn kannustaminen ja päätöksenteon siirtäminen mahdollisimman alhaiselle tasolle ovat olennainen osa onnistunutta toteutusta. Lisäksi periaatteella tähdätään siihen, että työntekijöihin luotetaan ja heille annetaan mahdollisuus muuttaa työprosesseja itseorganisoidusti parhaaksi katsomallaan tavalla (Poppendieck & Poppendieck 2008: 37, Janes & Succi 2014: 131). Tämä vaikuttaa muun muassa työn johtamiseen ja valvontaan. Yhteisenä päämääränä on luoda tuote, joka tarjoaa asiakkaalle maksimaalisen arvon. Yritys huolehtii siitä, että teknistä asiantuntemusta on tarpeeksi ja tiimeillä on tarvittava osaaminen tavoitteiden saavuttamiseksi. 10

3.7 Optimoi kokonaisuus Tuotannon olisi perustuttava syvälliseen ymmärrykseen siitä, mitä asiakkaat haluavat ohjelmiston tekevän (M. Poppendieck & M. A. Cusumano 2012: 28). On hankalaa selvittää, mitä asiakkaat arvostavat, varsinkin kun ohjelmiston arvo selviää usein vasta siinä vaiheessa, kun se on otettu käyttöön tai liitetty osaksi suurempaa järjestelmää. Lisäksi ohjelmiston arvo ei ole peräisin pelkästään kehitysvaiheesta; suunnittelu ja ylläpito ovat myös olennaisia sen arvon kannalta. Yksi ohjelmistotuotannon haasteista on, kuinka työntekijät saadaan keskittymään kokonaisarvon tuottamiseen ja ohjelmistoon kokonaisuutena (Poppendieck & Poppendieck 2009: 84). Jotta monimutkaisesta järjestelmästä tulisi eheä, edellyttää se syvää osaamista ja yhteistyötä monilla eri alueilla. Osien on toimittava yhdessä parhaalla mahdollisella tavalla, sen sijaan, että yksi vaihe toimisi yksinään maksimaalisesti. 4 Lean-periaatteet käytännössä Aiheesta myöhemmin kirjoitetuissa teoksissa Poppendieckien periaatteita käytetään paljon pohjana. Muun muassa Curt Hibbs, Steve Jewett ja Mike Sullivan (2009) ovat kehittäneet toisenlaisen näkökulman Lean-ajattelun sovittamiseksi ohjelmistotuotantoon. Heidän käytäntönsä kohdistuvat pitkälti ohjelmointiin: versiohallinta ja komentosarjat (Source Code Management and Scripted Builds), testiautomaatio (Automated Testing), jatkuva integraatio (Continuous Integration), vähemmän koodia (Less Code), lyhyet iteraatiot (Short Iterations) ja asiakkaan osallistaminen (Customer Participation). Näistä monet ovat toimenpiteitä, joita myös Poppendieckit kehottavat käyttämään. Automaattinen testaus tukee kolmea Poppendieckien periaatetta: rakenna laatua, poista hukka ja opi jatkuvasti. Lyhyet iteraatiot tukevat kolmea periaatetta: poista hukka, päätä mahdollisimman myöhään ja toimita nopeasti. Poppendieckien (2008: 234) mukaan tehokkain tapa aloittaa Lean-kehitys on kouluttaa johtajia ja ohjaajia, korostaa työn kehittämistä dokumentoinnin sijaan ja mitata ainoastaan muutamia avainindikaattoreita. Usein organisaatioissa kiinnitetään liikaa huomiota dokumentointiin, eikä työntekijöitä kannusteta miettimään, miten työtä voitaisiin parantaa (Poppendieck & Poppendieck 2008: 234). Johtajille tulisi opettaa, kuinka tieto siirretään työntekijöille. Täsmällisten asiakirjojen kirjoittamisen sijaan työntekijöitä pitää kannustaa parantamaan prosesseja ja ideoimaan. Ehdotettu- 11

ja parannusehdotuksia ei pitäisi joutua siirtämään jollekin toiselle arviointia ja toteutusta varten, vaan yhdessä työskentelevien joukossa pitäisi olla ideoiden toteuttajat. Tehokkaiden mittausten löytäminen on haastavaa, koska tulokset eivät usein ole ilmeisiä ennen kehitystyön päättymistä. Tämä saattaa johtaa tarpeettomien mittausten suorittamiseen (Poppendieck & Poppendieck 2008: 237-241). Vaikka ohjelmisto toimitetaan ajoissa, sovitun budjetin rajoissa ja suunnitellulla laajuudella, saattaa asiakas silti olla tyytymätön. Mittausten jatkuvan lisäämisen sijaan olisi mitattava oikeita asioita. Lean-organisaatioissa sopivia mitattavia asioita ovat muun muassa kiertoaika, taloudelliset tulokset ja asiakastyytyväisyys. Kiertoaika (Cycle Time) kertoo, kuinka kauan keskimäärin kuluu aikaa vaiheen tai vaiheiden suorittamiseen operaation sisällä. Se paljastaa järjestelmän hukan, sillä osaamisen puuttuminen, heikko suorituskyky ja viallinen toteutus lisäävät kiertoaikaa. Asiakkaiden perusedellytykset on täytettävä ja tuotteen on oltava kilpailukykyinen. Tavoitteena on ymmärtää asiakkaiden tarpeet ja ratkaista heidän ongelmansa. Tuotteen tulisi olla niin hyvä, että asiakas on valmis suosittelemaan tuotetta muille. Asiakastyytyväisyyttä voidaan mitata esimerkiksi kyselyillä. Seuraavissa kappaleissa esitellään Poppendieckien (2008: 244-246) esimerkkejä, kuinka Lean-periaatteita voi toteuttaa käytännössä. Hukkaa voidaan vähentää varmistamalla, että kaikilla on selkeä ymmärrys siitä, mitä asiakkaat arvostavat ja mitä ollaan tekemässä. On oltava varmuus, että rakennetaan oikeita ominaisuuksia. Kaikkien prosessin vaiheiden on kohdistuttava arvoa luovaan toimintaan tai parantaa kykyä tuottaa arvoa. Järjestelmän ominaisuudet rajoitetaan niihin, jotka ovat välttämättömiä arvon lisäämiseksi. Laatua voidaan rakentaa vähentämällä osittain tehdyn työn määrää ja kirjoittamalla testit aluksi. Viat tulee korjata heti, kun ne havaitaan. Koodi pitää integroida mahdollisimman usein ja laajasti. Kaikki mahdolliset rutiininomaiset prosessit tulee automatisoida mahdollisimman pian. Koodipohja tulee pitää yksinkertaisena muun muassa refaktoroimalla koodia ja välttämällä duplikaatteja. Oppimista voidaan tehostaa antamalla jokaiselle tarvittava johtajuus sitoutumisen, läpinäkyvyyden parantamiseksi. Tiimin jäsenille tulee opettaa ongelmanratkaisumenetelmiä, joiden avulla voidaan laatia hypoteeseja, suorittaa nopeita kokeiluja, luoda tiivis dokumentaatio ja toteuttaa perustellut muutokset. 12

Työskentely pienissä iteraatioissa ja projektin koon pienentäminen auttavat toimittamaan valmista toiminnallisuutta nopeammin. Rajoittamalla työn määrä kapasiteettiin sopivaksi, voidaan rajoittaa käynnissä olevien töiden määrää. Aloitettu työ tulisi tehdä kokonaan loppuun ennen kuin aloitetaan uusi tehtävä. Tarkan etukäteen tehdyn määrittelyn sijaan päätökset tulisi tehdä projektin edetessä, jolloin ne voidaan tehdä viimeisimmän tiedon perusteella. Peruuttamattomille päätöksille pitää etsiä vaihtoehtoja ja tehdä päätös viimeisellä mahdollisella hetkellä. Muut päätökset tulee säilyttää niin yksinkertaisina, että niitä voidaan tarvittaessa muuttaa. Tiiminvetäjille pitää antaa koulutusta ja aikaa, jotta he voivat toteuttaa ja opettaa Leanajattelua. Vastuu ja päätöksenteko siirretään mahdollisimman alhaiselle tasolle. Työympäristöstä tulisi poistaa tekijät, jotka estävät työntekijöitä olemasta ylpeitä tehdystä työstä. Heitä tulisi kannustaa sitoutumaan ja odottaa heiltä laadukkaita tuloksia. Muista keinoista muun muassa arvovirtakuvaukset ovat helposti ymmärrettävissä ja auttavat visualisoimaan ongelmia ja mahdollisia parannuksia. Niiden avulla voidaan tunnistaa hukka ja lyhentää läpimenoaikoja. Mujtaba, Feldt ja Petersen (2010: 147) tunnistivat kuvauksen avulla Ericsson AB:n ohjelmiston kustomointiprosessista kolme selkeää hukkaa: odotus, ylimääräiset prosessit ja osastojen väliseen viestintään kuluva aika. Tutkimus osoitti myös, että 38% tuotantoajasta ei ollut lisännyt arvoa. Eniten odotusta kertyi suunnitteluvaiheessa, tarjouksen hyväksynnän odottamisesta ja integraatiotestauksessa havaittujen virheiden korjaamisesta. Kanban tuotannon ajoitusjärjestelmää käyttämällä Lean-periaatteita saadaan otettua organisaatiossa käyttöön. Kanban-järjestelmä sopii käynnissä olevien töiden seurantaan ja rajoittamiseen (Corey Ladas 2008). Arvovirta esitetään visuaalisesti taulun muodossa, jossa on omat sarakkeet eri tilassa oleville työvaiheille. Kanban-kortit, jotka kuvastavat työtehtäviä, sijoitetaan sarakkeeseen, joka edustaa työn sen hetkistä tilaa. Kun tehtävä on valmis, kortti siirtyy seuraavaan sarakkeeseen, kunnes se on virrannut taulun läpi. Samalla voidaan seurata läpimenoaikoja. Jokaisen sarakkeen työtehtävien määrä on rajoitettu, jolloin käynnissä olevien ja osittain tehtyjen töiden määrää pystytään seuraamaan. Kanban-järjestelmä tarjoaa hyvän työvälineen organisaatioille, jotka aloittavat Lean-periaatteiden käytön tuotannossaan (M. Poppendieck & M. A. Cusumano 2012). 13

5 Lean startup-menetelmä Lean startup-menetelmä on Eric Riesin (2011) kehittämä innovointimalli, jolla pyritään lyhentämään kehitysjaksoja sekä vähentämään uusien tuotteiden kehitykseen kuluvaa työmäärää, aikaa ja kuluja. Menetelmän avulla saadaan jatkuvaa palautetta asiakkailta ja palautteen perusteella pyritään rajoittamaan ominaisuuksia, joita he eivät halua. Kun vähimmäisvaatimusten mukainen tuote (Minimum Viable Product, MVP) on valmis, se annetaan asiakkaan hyväksyttäväksi tai hylättäväksi. Nopeasti saatu palaute mahdollistaa prosessin aikaisen korjaamisen ja epäonnistumisilta voidaan välttyä (Sharma & Gandhi 2016: 4). Riesin mukaan Lean Startup-menetelmää voidaan soveltaa startup-yritysten lisäksi myös muiden yritysten innovaatioprosesseihin (Euchner 2013: 12). Käynnistysvaiheessa vallitsee usein epävarmuus ja ei välttämättä tiedetä, kuka on tuleva asiakas. Perinteisessä Leanajattelussa katsotaan tuotantoa asiakkaan näkökulmasta. Kun asiakasta ei tunneta, tarvitaan tekniikoita, jotka sopivat uusien tuotteiden kehittämiseen ilman asiakasta. On tärkeää pystyä ratkaisemaan ja vähentämään suurimmat riskit ja hankkia todisteita siitä, että tuotetta pidetään arvokkaana. Oppimisprosessi on aloitettava mahdollisimman pian (Euchner 2013: 13). Jos tuote esitellään ensimmäisen kerran yleisölle vasta julkaisupäivänä, saatetaan huomata, että asiakkaat eivät kiinnostu siitä lainkaan. Jotta näin ei tapahtuisi, julkaistaan vähimmäisvaatimusten mukaisia tuotteita. Tuotteen on oltava mahdollisimman paljon myytävän tuotteen kaltainen, jotta voidaan varmistaa, ovatko asiakkaat valmiit maksamaan siitä. Kun asiakas löytyy, saadaan tärkeää tietoa, mihin suuntaan tuotetta kannattaa kehittää. 14

6 Ketterä ohjelmistokehitys Ketteriä menetelmiä on käytetty ohjelmistokehityksessä jo 1990-luvulta lähtien, mutta perustan sisältävä Ketterä manifesti (Agile Manifesto) on kirjoitettu vasta vuonna 2001 (Behroozi & Kamandi 2016: 102). Käytänteet, jotka muodostavat ketterän ohjelmistokehityksen (Agile Software Development) metodit, tukevat Lean-periaatteita (Hibbs, Jewett & Sullivan 2009: 16). Ohjelmistojen ketterällä ja Lean-kehitysmenetelmällä on molemmilla sama tavoite lisätä tuottavuutta ja parantaa ohjelmiston laatua. Molemmat menetelmät suhtautuvat positiivisesti projektin aikana tapahtuviin muutoksiin ja pyrkivät täyttämään asiakkaan todelliset tarpeet. Kehitysmenetelmillä on myös joitain samoja käytäntöjä, kuten välitön testaus, ohjelmiston kehittämisen laittaminen dokumentoinnin edelle, asiakkaiden palautteen huomioiminen, lyhyet iteraatiot, läpinäkyvyys, itseorganisoiva tiimi, lisätoimintojen välttäminen sekä tiimin vahvistaminen (Behroozi & Kamandi 2016). Niiden erona on perspektiivi ja ajattelutapa. Ketterän ohjelmistokehityksen painopiste on Lean-menetelmää kapeampi (Hibbs, Jewett & Sullivan 2009: 16, 22). Leanohjelmistotuotanto tarkastelee koko liiketoimintaympäristöä, jossa ohjelmistokehitys tehdään. Sen vuoksi Lean-periaatteita voidaan soveltaa mihin tahansa yrityksessä. Ketterät menetelmät puolestaan huolehtivat enimmäkseen ohjelmistokehityksen ja ympäröivän projektinhallinnan käytännöistä. Lean-tuotannossa on tavallista laajentaa sutjakkaat toimintatavat jopa yrityksen ulkopuolella olevien yhteistyökumppaneiden toimintaan. Ketterän ohjelmistokehityksen painopiste on tiiviissä yhteistyössä asiakkaiden kanssa ja toimivan ohjelmiston nopeassa toimittamisessa mahdollisimman varhaisessa vaiheessa. Leanohjelmistotuotanto suosii myös näitä toimia, mutta sen ensisijaisena tavoitteena on hukan poistaminen (Hibbs, Jewett & Sullivan 2009: 22). Ketterällä ohjelmistotuotannolla on melko paljon muodollisia sääntöjä, kun taas Leanmenetelmällä niitä ei ole (Hibbs, Jewett & Sullivan 2009: 22). Sääntöjen sijaan on suositeltavia käytäntöjä, joiden joukosta voi valita sopivimmat. Ketterät ohjelmistokehitysmenetelmät ovat Lean-ohjelmistotuotantoon sopivia, sitä tukevia käytäntöjä. Lean-ohjelmistokehityksen toteutuksessa on melko tavallista valita ketterä menetelmä lähtökohdaksi ja soveltaa Leankäytäntöjä siihen. 15

7 Haasteet ja menestystekijät Lean-ohjelmistotuotannossa Lean-periaatteiden noudattaminen saattaa vaatia muutoksia organisaation rakenteeseen, toimintaan ja käyttäytymiseen. Työntekijät tai johtajat voivat vastustaa muutoksia (Sharma & Gandhi 2016: 4, Bon & Kee 2015: 5). Vastustus voi johtua erikoistumisalan laajentumisesta tai kaventumisesta. Työntekijöiltä kaivataan monitaitoisuutta, joka voi vaatia henkilöä siirtymään toiminnosta toiseen. Projekteissa saatetaan joutua esimerkiksi vuokraamaan lisää työvoimaa, tarjoamaan koulutusta, hankkimaan uusia laitteita tai uusimaan palkitsemisjärjestelmiä, jolloin tarvitaan taloudellisia resursseja. (Bon & Kee 2015: 4). Johdon osaaminen ja sitoutumishalu määrittää paljon, kuinka Lean-periaatteet saadaan sovitettua organisaatioon (Bon & Kee 2015: 5). Johtajilla on korkeimmat valtuudet projekteissa ja heidän toimintansa määrittää täytäntöönpanon onnistumisen. Heillä on oltava lisäksi kurinalaisuutta, rehellisyyttä ja kannustavuutta johtaakseen muita. Johtoryhmän tulee myös pystyä viestimään työntekijöiden kanssa. Henkilöiden osallistuminen, halukkuus muutokseen ja yhteistyö kaikkien tasojen työntekijöiden kanssa mahdollistavat projektin onnistumisen (Bon & Kee 2015: 5). Ilman yhteistyötä kaikkien osapuolten kanssa muutos epäonnistuu. Uusien menetelmien toteuttaminen saattaa epäonnistua (Dikert, Paasivaara & Lassenius 2016: 96-97). Arvoja ja käsitteitä ei välttämättä ymmärretä ja käytännöt toteutetaan sisäistämättä niiden tarkoitusta. Uutta menetelmää on myös vaikea oppia kirjallisuudesta tai selkeää käsikirjaa ei ole. Menetelmiä räätälöimällä saatetaan muuttaa vääriä asioita, jolloin teot eivät saa aikaan todellista muutosta prosessissa ja ajattelussa. Näitä haasteiden esiintyvyyttä esitetään kuvassa 4. Ohjelmistokehitys on liitettävä muihin organisaation tehtäviin, mikä aiheuttaa haasteita, ellei toimintatapoja haluta ymmärtää tai voida muuttaa. Kaikki osastot joutuvat sopeutumaan lisääntyviin ja nopeutuviin toimituksiin, vaikka se ei työhön sovi. Täyttä hyötyä ei voida saavuttaa, ellei koko organisaatio toimi yhdessä parhaalla mahdollisella tavalla (Dikert, Paasivaara & Lassenius 2016: 99, Fagerholm 2015: 79). 16

Implementointi 20 Toimintojen integrointi 18 Vastustus 16 Vaatimusten suunnittelu 16 Hierarkia 14 Investointi 13 Koordinointi 13 Lähestymistapojen erot 9 Kuva 4: 48 organisaation kohtaamat haasteet toteutettaessa laajoja tuotantomenetelmien muutoksia (Dikert ym. 2016) Haasteet voivat johtaa siihen, että työntekijät palaavat vanhaan työskentelytapaan (Dikert, Paasivaara & Lassenius 2016: 97). Liian tiukka aikataulu ja muutosten käsittelyn aiheuttama stressi voivat saada palaamaan vanhaan tapaan. Uusien menetelmien oppimiseen tarvitaan koulutusta ja aikaa. Tuloksia ja muutoksia saatetaan odottaa toteutuvaksi heti. Mikäli hyödyt eivät ole välittömiä, saatetaan turhautua. Myös liika innokkuus saattaa vähentää tiimin jäsenten kiinnostusta. Uuden menetelmän käyttöönotto ei takaa menestystä, joten sitä ei tule noudattaa sokeasti. Positiiviset kokemukset ja havaittavat tulokset innostavat kokeilemaan uusia työskentelytapoja laajemmin (Dikert, Paasivaara & Lassenius 2016: 102). Lean-periaatteet saatetaan ottaa käyttöön suurin odotuksin, ilman että tiedetään tarkasti, mitä käytöltä odotetaan (Ebert, Abrahamsson & Oza 2012: 23-24). Muutokset voivat olla odotuksiin nähden vähäisiä ja epätyydyttäviä. Ohjelmistojen aineettomuus ja ohjelmistokehityksen vaikeus tekevät Leanperiaatteiden ja käytäntöjen soveltamisesta haasteellista. Onkin melko yleistä, että organisaatiot yhdistävät ketteriä menetelmiä Lean-menetelmiin. Erityisesti Scrum-, XP- ja Leanohjelmistokehitystä käytetään yhdessä. (Dikert, Paasivaara & Lassenius 2016: 92) Työskentelytavan muuttaminen edellyttää koordinointia ja johtajuutta. On tärkeää, että muutoksille löytyy edustaja (Dikert, Paasivaara & Lassenius 2016: 101). Edustaja voi olla yksi henkilö, joka ajaa organisaation muutosta tai sitä voi johtaa ryhmä, jossa on edustajia ryhmän kaikista osista. Muutoksiin voi ohjata myös organisaation ulkopuolinen henkilö tai ryhmä. 17

Kouluttaminen parantaa mahdollisuuksia menestyä muutoksessa (Dikert, Paasivaara & Lassenius 2016: 102). Se myös auttaa ihmisiä suhtautumaan positiivisemmin uuteen toimintatapaan. Lean-menetelmät välttävät täsmällisiä toimintatapoja ja korostavat tilanteeseen sopeutumista. Ohjaajat auttavat ymmärtämään periaatteita, sillä ilman ohjausta tekniikoita voidaan käyttää väärin. Periaatteita tulisi korostaa käytäntöjen avulla. Kun ihmiset ymmärtävät arvot, he ymmärtävät myös, miksi muutos on tehty ja ovat motivoituneita (Dikert, Paasivaara & Lassenius 2016: 103). Ulkopuoliset henkilöt osaavat antaa puolueettoman näkemyksen organisaatiosta, kun taas sisäiset ohjaajat ovat helpommin tavoitettavissa ja tuntevat organisaation erityispiirteet. Menestystekijät laajoille tuotantomenetelmien muutoksille esitetään kuvassa 5. Kustomointi 20 Ajattelutapa 17 Johdon tuki 16 Ohjaus 15 Pilotointi 14 Vaatimusten hallinta 10 Tiimien autonomia 10 Kuva 5: Maininnat kohdatuista menestystekijöistä toteuttaessa laajoja tuotantomenetelmien muutoksia 48 organisaation keskuudessa (Dikert ym. 2016) Intensiivisellä viestinnällä saavutetaan mahdollisimman paljon ihmisiä organisaatiossa ja uudet toimintatavat saadaan laajasti käyttöön. Tavoitteiden kertominen saa ihmiset ymmärtämään muutoksen tarkoituksen (Dikert, Paasivaara & Lassenius 2016: 102-103). Tarvittava läpinäkyvyys saavutetaan kertomalla avoimesti sekä menestyksestä että haasteista, näyttämällä projektin tilan julkisesti ja pitämällä julkisia kokouksia. 18

7 Yhteenveto Toyotalla alettiin käyttää tuotantojärjestelmää, jonka keskeisiä tavoitteita oli tuottaa juuri oikea määrä tuotteita juuri oikeaan aikaan sekä minimoida lisäarvoa tuottamattomien komponenttien ja työvaiheiden, eli hukan määrä. Sen pohjalta syntyi Lean-ajattelu ja Toyotan periaatteet on onnistuttu siirtämään teollisuudesta muun muassa ohjelmistotuotantoon. Lean-ajattelu on tiivistetty viiteen periaatteeseen: arvo, arvovirta, virtaus, imuohjaus ja täydellistyminen. Ajattelutavan on katettava kaikki vaiheet tuotteen elinkaaren aikana. Mary ja Tom Poppendieck kehittivät seitsemän ohjelmistotuotantoon soveltuvaa, Leanperiaatetta. Niiden päämääränä on poistaa arvoa tuottamaton toiminta eli hukka, rakentaa laatua alusta asti, oppia jatkuvasti, päättää mahdollisimman myöhään, toimittaa nopeasti, arvostaa ihmisiä ja optimoida kokonaisuus. Konkreettisia menetelmiä, joilla periaatteet voidaan ottaa käyttöön ovat muun muassa versiohallinta, testiautomaatio, jatkuva integraatio, koodin vähentäminen, lyhyet iteraatiot ja asiakkaan osallistaminen. Ohjelmistotuotannossa hukkaa on muun muassa osittain tehty työ, ylimääräiset prosessit, lisäominaisuudet, tehtävien vaihtaminen, odottaminen, tarpeeton liike ja viat. Tuotannon alusta alkaen pitää toistuvasti etsiä suurin hukka ja eliminoida se. Lean-ohjelmistotuotanto perustuu ymmärrykseen siitä, mitä asiakkaat haluavat ohjelmiston tekevän. Iteraatioiden ollessa lyhyitä, voidaan toimittaa nopeammin, oppia jatkuvasti, saada jatkuvaa palautetta sekä viivästyttää päätöksentekoa. Tämä estää sen, ettei tuoteta ominaisuuksia, joita asiakas ei halua. Peruuttamattomat päätökset tulisi tehdä viimeisellä mahdollisella hetkellä sen hetkisen parhaan tiedon pohjalta. Asiakkaat arvostavat nopeaa toimitusta ja se on myös ohjelmiston tuottajille hyödyksi. Nopea toimitus vapauttaa resursseja osittain tehdyissä, lisäarvoa tuottamattomissa työprosesseissa olevia resursseja ja vähentää riskiä, että asiakas muuttaa mielensä. Koska Lean-ajattelussa katsotaan tuotantoa asiakkaan näkökulmasta, sen rinnalle on kehitetty Lean-startup innovointimalli, joka sopii startup-yrityksille ja projekteihin, joissa tulevaa asiakasta ei tiedetä. Myös se pyrkii kehittämään asiakkaan mielestä arvokkaan tuotteen mahdollisimman pienillä kuluilla ja ponnisteluilla. Lean-periaatteiden tuominen työympäristöön saattaa vaatia muutoksia organisaation rakenteeseen, toimintaan ja käyttäytymiseen. Käyttöönottoon ja toteuttamiseen liittyy paljon haas- 19

teita. Johdolta ja muilta työntekijöiltä vaaditaan sitoutumista ja ymmärtämistä, jotta toivottuihin tavoitteisiin päästään. Tuomalla Lean-ajattelua ohjelmistotuotantoon, voidaan havaita tuotannon ongelmakohdat ja parantaa niitä. Huomioimalla haasteet ja korostamalla menestystekijöitä, voidaan saada tuloksia aikaan. Menetelmää voidaan soveltaa organisaatioon ja projektiin sopivalla tavalla valitsemalla sopivat periaatteet, joita korostaa. On myös yleistä yhdistää Lean-menetelmiä muihin ketteriin ohjelmistokehitysmenetelmiin. 20

Lähteet Behroozi, N. & Kamandi, A. 2016, Waste elimination of agile methodologies in web engineering, s. 102-107. Bon, A.T. & Kee, T.S. 2015, Implementation of Lean manufacturing for productivity improvement in Malaysia, s. 1-6. Dikert, K., Paasivaara, M. & Lassenius, C. 2016, Challenges and success factors for largescale agile transformations, JOURNAL OF SYSTEMS AND SOFTWARE; Volume 119, s. 108. DOI 10.1016/j.jss.2016.06.013. Ebert, C., Abrahamsson, P. & Oza, N. 2012, Lean Software Development, IEEE Software, 29(5), s. 22-25. DOI 10.1109/MS.2012.116. Euchner, J. 2013, What Large Companies Can Learn from Start-ups, Research Technology Management, 56(4), s. 12-16. Fagerholm, F. 2015, Software developer experience : case studies in lean-agile and open source environments, University of Helsinki. Hibbs, C., Jewett, S. & Sullivan, M. 2009, Art of Lean Software Development, 1. p., O'Reilly Media. Janes, A. & Succi, G. 2014, Lean software development in action, Springer, Heidelberg. Ladas, C. 2008, Scrumban: and other essays on kanban systems for lean software development, Modus Cooperandi Press, Seattle, WA. Lehtonen, T., Kilamo, T., Suonsyrjä, S. & Mikkonen, T. 2016, Continuous, Lean, and Wasteless: Minimizing Lead Time from Development Done to Production Use, s. 73-77. Middleton, P. & Joyce D. 2012, Lean Software Management: BBC Worldwide Case Study, IEEE Transactions on Engineering Management, 59(1), s. 20-32. DOI 10.1109/TEM.2010.2081675. Mujtaba, S., Feldt, R. & Petersen, K. 2010, Waste and Lead Time Reduction in a Software Product Customization Process with Value Stream Maps, s. 139-148. Poppendieck, M. & Cusumano, M.A. 2012, Lean Software Development: A Tutorial, IEEE Software, 29(5), s. 26-32. DOI 10.1109/MS.2012.107. Poppendieck, M. & Poppendieck, T. 2009, Lean software development: an agile toolkit, 14. p., Addison Wesley, Boston, MA. 21

Poppendieck, M. & Poppendieck, T.D. 2008, 6. p., Implementing lean software development: from concept to cash, Addison-Wesley, Upper Saddle River. Poppendieck, M. & Poppendieck, T. 2003, Lean software development: an agile toolkit, Addison Wesley, Boston, MA. Ries, E. 2011, The lean startup: how today's entrepreneurs use continuous innovation to create radically successful businesses, 1st ed. p., Crown Business, New York. Section 6. Postwar Arrangements and Labor Disputes, 5. U.S. Army Vehicle Repair Operations and Compact Car Development c. Saatavilla: http://www.toyotaglobal.com/company/history_of_toyota/75years/text/taking_on_the_automotive_business/ chapter2/section6/item5.html (Haettu 11.10.2017). Sedano, T., Ralph, P. & P 'eraire, C.'. 2017, Software Development Waste, Proceedings of the 39th International Conference on Software EngineeringIEEE Press, Piscataway, NJ, USA, s. 130-140. Sharma, S. & Gandhi, P.J. 2016, Scope of optimising I.C.T objectives applying lean principles: An exploratory review, s. 1-7. Tang, Y.h., Miao, X. & Xi, B. 2010, E-government based lean public management: A case study, s. 150-153. Westman, M. & Etzion, D. 2001, The impact of vacation and job stress on burnout and absenteeism, Psychology & Health, 16(5), s. 595-606. DOI 10.1080/08870440108405529. Womack, J.P. & Jones, D.T. 2003, Lean thinking: banish waste and create wealth in your corporation, Rev. and updated. p., Free Press; Simon & Schuster, New York: London. Womack, J.P., Jones, D.T. & Roos, D. 1990, The machine that changed the world, Rawson Associates, New York. 22