Kanbanin juuret

Kanbanin juuret ovat Lean-ajattelussa (Liker, 2010; Petersen, 2010; Hiranabe 2008;

Poppendieck & Poppendieck, 2003). Seuraavaksi kerrotaan Leanin taustasta, sen suhteesta ketteriin menetelmiin ja vaikutuksista Kanbanin syntyyn.

Lean-ajattelu on lähtöisin japanilaisesta tuotantotaloudesta, jossa sen alku-perä voidaan johtaa Toyotan tuotantotapaan (Toyota Production System, TPS;

Ikonen, 2011). Toyotan tuotantotavan keskiössä on nimenomaan arvon säilyttä-minen ja tuottasäilyttä-minen vähemmällä työllä (Liker, 2010). TPS:n historialliset juuret palautuvat aina 1940–1950-lukujen vaihteeseen asti (Ohno, 1988), mutta kä-site ”Lean” otettiin käyttöön vasta paljon myöhemmin vuonna 1990 Womackin, Jonesin ja Roosin (1990) toimesta. Lean-tuottamisen voi ajatella olevan variaatio työnkulun optimoinnin avulla saatavasta tehokkuuden parantumisesta. Ladas (2008) tarkentaa, että Toyotan tuotantotapa (TPS) on kyllä Lean-ajattelua, mutta kaikki Lean-ajattelu ei ole Toyotan tuotantotapaa. Leanissa ei ole kyse tehdas-maisesta tavasta tuottaa, vaan arvoista ja arvoketjuista.

Lean-johtamisfilosofia tai -ajattelu keskittyy asiakkaalle luodun arvon mak-simointiin. Keskeinen asiakkaan arvon maksimoinnin keino on hukan poistami-nen tuotanto- ja kehitysprosesseista. Eräs tärkeimmistä Lean-johtamisfilosofian

ajatuksista on nimenomaan ajatus seitsemästä resurssien hukkaajasta (Ohno, 1988), joiden minimoinnilla pystytään optimoimaan tuotannon arvon suhde työn määrään. Toinen keskeinen ajatus on veto-ajattelu (pull): kun yksikön resurssi vapautuu, se hakee itselleen uuden, korkeimman prioriteetin työn. (Liker, 2010.)

Vaikka Lean-ajattelun juuret ovatkin tuotantotaloudessa ja massatuotan-nossa, siitä saadut edut ja koetut hyödyt ovat levittäneet sitä ajan kuluessa perin-teistä ydinaluettaan laajemmalle (Ikonen, 2011). Nykyään Lean-johtamisfiloso-fiaa noudattavat Lean-tuotannon lisäksi mm. Lean-tuotekehitys (product develop-ment; Petersen, 2010), Lean-yritys (enterprise; Ikonen, 2011), Lean-kulutus (con-sumption; Womack & Jones, 2005) ja uusimpana Lean-ohjelmistokehitys (software development; Poppendieck & Poppendieck, 2007; Petersen, 2010; Ikonen, 2011).

Rinnan Lean-ajattelun leviämisen kanssa on ohjelmistokehityksessä otettu käyttöön yhä enemmän ketteriä menetelmiä, kuten XP (Beck, 1999a; Beck, 1999b) ja Scrum (Schwaber & Sutherland, 2011). Ketterän kehittämisen voi katsoa jo tuo-neen aineksia Leanin peruslähestymistavasta ohjelmistokehitykseen painotta-malla asiakastyytyväisyyttä ja jatkuvaa kehittämisprosessin parantamista. Li-säksi ketterä lähestymistapa pyrkii tuottamaan toimivaa ohjelmistoa mahdolli-simman jatkuvasti (iteratiivisesti ja inkrementaalisesti), mikä mahdollistaa asiak-kaan tarpeiden täyttymisen seurannan (Beck ym., 2001).

Vaikka perusainekset Lean-ajattelun mukaiseen kehittämiseen onkin lau-suttu osana ketterän kehittämisen taustalla olevia periaatteita (Middleton &

Joyce, 2012; Beck ym., 2001), ne lähestyvät asiaa käytännön kokemusten kautta ja pelkistyvät siten usein hyvien käytäntöjen kuvauksiksi. Pahimmillaan nämä me-netelmät ovat itsessään melko raskaita ja alttiita luomaan hukkaa prosessiin.

Lean-kehittäminen menee siten ketterää kehittämistä pidemmälle. Arvovirtauk-seen pohjautuvan asiakasnäkökulman lisäksi se keskittyy luomaan ohjelmisto-tuotantoon jatkuvan ja tasaisen virtauksen, joka minimoi syntyneen hukan ja maksimoi prosessin joustavuuden. (Ikonen, 2011.) Samalla Lean-lähestymistapa tunnustaa kehitysympäristöiden ja projektien yksilöllisyyden ja pidättäytyy määrittelemästä käytäntöjä, joilla periaatteita tulisi toteuttaa.

Esimerkiksi Shalloway ym. (2010) toteavat, että Lean laajentaa ketterää ke-hittämistä tarjoamalla ohjausta ketterien menetelmien sijoittamisesta uusiin ti-lanteisiin ja konteksteihin. Heidän näkemyksensä mukaan Lean painottaa erityi-sesti keskittymistä kehitysaikaan käytettyjen resurssien sijaan ja muistuttaa opti-moimaan kokonaisuutta yksittäisten työn osien tehokkuuden maksimoinnin si-jaan. Vastaavasti Petersen (2010, s. 53–70) vertailee ketterää kehitystä ja Leania toisiinsa niiden periaatteiden osalta. Hän tunnistaa 26 periaatetta ja ryhmittelee ne seitsemään kategoriaan: vaatimusmäärittely, suunnittelu ja implementointi, laadunvarmistus, ohjelmistojulkaisu, projektisuunnittelu, ryhmänjohtaminen ja päästä-päähän-virtaus (end-to-end stream). Petersen (2010) havaitsee eroja seitse-mällä osa-alueella: ihmisten johtaminen ja johtajuus, tuotteen laatu, tuotteen jul-kaisu, joustavuus, asiakkaan tarpeiden ja arvojen prioriteetit, oppiminen ja päästä-päähän -virtaus. Petersenin (2010) mukaan juuri nämä erot

Lean-lähesty-mistavassa tekevät siitä ketterää kehittämistä yleisemmällä tasolla olevan. Erityi-sen tärkeäksi erottavaksi tekijäksi nousee nimenomaan arvon tarkastelu päästä-päähän -perspektiivistä.

Lean-ajattelun tuominen osaksi ohjelmistokehitystä ei kuitenkaan ole on-gelmatonta. Leanin keskiössä olevan arvon määrittely sekä alun perin tuotan-toon ja toimitusketjujen hallintaan suunniteltujen metodien muuntaminen on oh-jelmistokehityksen näkökulmasta vaikeaa ja monimutkaista (Ikonen, 2011). Esi-merkiksi Ladas (2008) luettelee useita Lean-periaatekokoelmia, joita voisi käyttää Lean-ajatteluun pohjautuvassa ohjelmistokehityksessä. Tällaisia ovat muiden muassa: ”2 pillars of the Toyota Production System”, ”14 principles of the Toyota Way”, ”5 principles of Lean Thinking” ja “7 principles of Lean Software Development”.

Keskeisten Kanban-vaikuttajien näkemyksiin sopivista periaatekokoelmista sy-vennytään seuraavassa alaluvussa.

Shalloway ym. (2010) ovat ratkaisseet arvon määrittelyn ongelman ehdot-tamalla, että Lean-ohjelmistokehityksen keskeisen tavoitteen tulisi olla kokonai-suuden optimointi kestävyyden (sustainability) ja nopeuden (speed) ehdoilla. Iko-nen (2011) tulkitsee tätä siten, että käytännössä arvon tuottamiIko-nen tarkoittaa ta-paa saavuttaa asetettu tavoite eli kokonaisuuden optimointi. Ikonen (2011) tar-joaa lisäksi kaksi hyvää syytä, miksi Lean-ajattelu tulisi tuoda ohjelmistokehityk-seen. Ensinnäkin suunnitelmakeskeiseen (plan-driven) ohjelmistokehitykseen liit-tyy monia mahdollisia ongelmia (vaatimuksien muutokset yms.), jotka Lean-lä-hestymistavalla voidaan huomioida. Toiseksi ohjelmistomarkkinat ovat nykyään erittäin dynaamiset, mikä pakottaa ohjelmistotuottajat mukautumaan muutok-siin nopeasti. Lean-lähestymistavan käytöstä ohjelmistokehityksessä löytyy rat-kaisuja myös tähän. (Ikonen, 2011.)

Kanbanin rooliksi muodostuu siis Lean-ajattelun tuominen ohjelmistokehi-tyksen käytäntöön. Avaimen tähän tarjoaa Hiranabe (2008) osoittaessaan, että monet ketteristä menetelmistä jo tutuiksi tulleet työskentely- ja projektinhallin-tatavat mahdollistavat Lean-ajattelun joustavan käyttöönoton. Esimerkiksi val-kotaulujen (elektronisten tai fyysisten) käyttö on muodostunut ketterässä kehit-tämisessä yleiseksi tavaksi visualisoida ja viestiä projektin tilaa. Pelkästään val-kotaulu mahdollistaa monien Lean-näkökulmien käyttöönoton. Kuvitellaan ti-lanne, jossa valkotaulun sarakkeet kuvaavat työvaiheita, joita suorittavat eri työntekijät, ja taululla liikkuvat laput kuvaavat yksittäisiä työtehtäviä. Jos nämä työtehtävälaput luodaan siten, että ne ovat pieniä asiakkaalle arvoa tuottavia osia, muuttuu lapun virtaus valkotaulun läpi arvon virtaukseksi työnhallinnan tai tuotantoprosessin läpi. Edelleen mikäli lappujen määrää saraketta kohti rajoite-taan, määritellään veto-mekanismi (pull), jossa uusi työtehtävä vedetään tehtä-väksi vasta kun resurssi vapautuu. (Hiranabe, 2008.) Molemmat esimerkin käy-tännön kautta ilmennetyistä periaatteista ovat Lean-ajattelussa hyvin keskeisessä roolissa.

On tärkeää painottaa, ettei Hiranaben (2008) esittämää näkemystä ja esi-merkkejä tule ottaa ainoina oikeina tapoina tuoda periaatteet käytäntöön. Niiden keskeinen anti on nimenomaan käytäntöjen taustalla vaikuttavan ajattelutavan

muutoksen selventäminen, joka viimekädessä määrittelee käytetyn Lean-ohjel-mistokehityksen luonteen. Kanban muodostuu siten siis Lean-ajattelun periaat-teista, joita ilmennetään kontekstiin sopivien käytäntöjen avulla. Nämä käytän-nöt ovat usein ketterässä kehityksessä hyviksi havaittuja.

Ensimmäinen ohjelmointikehitykseen implementoitu Kanban oli David Andersonin vuonna 2004 Microsoftilla käyttöönottama Drum-Buffer-Rope (Schragenheim & Dettmer, 2000) -ratkaisu (Anderson, 2010). Drum-Buffer-Rope -menetelmä on Rajoitteiden teorian (Theory of Constraints; Goldratt, 1990) tuo-tantosovellus.

Wang ym. (2012) ovat tutkineet kokemusraportteja Lean-lähestymistapoja ketterään ohjelmistokehitykseen yhdistelleistä hankkeista. He tunnistivat tutki-muksessaan yhteensä kuusi erilaista tapaa implementoida Lean-ajattelun mukai-sia periaatteita ketterään ohjelmistokehitykseen. Wang ym. (2012) korostavat, ettei yhtä oikeaa tapaa Leanin implementoinniksi ole, vaan jokaisen organisaa-tion tulee tehdä ratkaisunsa kulloisenkin kontekstin ja tarpeiden perusteella.

Kanban-lähestymistapa voidaan kuitenkin nähdä ydinstrategiana siirryttäessä ketterästä kehityksestä Leaniin. Jopa kolmessa neljästä tämän aiheen raportissa käytettiin Kanbania muutosprosessissa. (Wang ym. 2012.) Ahmad, Markkula ja Oivo (2013) tukevat tätä näkemystä ja menevät vielä hieman pidemmälle. Heidän mukaansa aiemmat tutkimukset paljastavat, ettei Kanbania voi ottaa käyttöön sellaisenaan, vaan se vaatii jonkin implementointia tukevan käytännön, esimer-kiksi jonkin ketterän menetelmän, käyttöä. Tästä syystä Kanbanin käyttöön-otossa käytetään Ahmadin, Markkulan ja Oivon (2013) mukaan useimmin jotain yhdistelmämenetelmää, esimerkiksi Scrumbania (Ladas, 2008).

Yhteenvetona Kanbanin juurien voi siis yhtäältä todeta olevan syvällä Lean-ajattelun mukaisissa johtamis- ja tuotantomalleissa sekä toisaalta ensim-mäisen sukupolven (Ladas, 2008) ketterien menetelmien (Abrahamsson, Salo, Ronkainen & Warsta, 2002) hyviksi koetuissa käytännöissä. Tällä kahden lähes-tymistavan yhdistämisellä pyritään saavuttamaan liiketoiminnan arvovirtauk-sen kokonaisvaltaisempi hallinta, nopeampi ja tehokkaampi resurssien reaktiivi-suus sekä kestävät ja käytettävät työnteon toimintatavat työnvirtauksen edistä-miseksi. Lisäksi Kanbanin käyttöönoton lähtökohdan ollessa organisaation työn-hallinnan nykytilassa vältytään ensimmäisen sukupolven ketterien menetelmien käytön aloittamisesta aiemmin aiheutuneista kuormittavista prosessi- ja työtapa-muutoksista.