Mikä ihmeen Kanban?
Japaninkielinen sana kanban tarkoittaa suomeksi näkyvää taulua. Nimi kuvaa työvaiheiden ja työn tekemistä näkyväksi, jotta työtä voidaan ymmärtää, ohjata ja kehittää.
Kanban on kevyt strategia, joka sisältää vain kolme sääntöä minkä tahansa prosessin visualisointiin, kehittämiseen ja ennustettavuuden parantamiseen. Kanban sai alkunsa Toyotalla Taiichi Ōnon työn myötä, ja sitä on sittemmin sovellettu laajasti ohjelmisto- ja tuotekehitykseen sekä muilla aloilla.
Kanbanin kolme perussääntöä
Kanban perustuu kolmeen yksinkertaiseen sääntöön, jotka on helppo muistaa ja soveltaa eri konteksteissa:
1. Näkyvöitä työnkulku
Pilko työ sopivan kokoisiin tehtäviin, kukin omalle lapulleen. Piirrä fyysiselle tai digitaaliselle valkotaululle sarakkeet (yleensä 3-6 kpl), joiden otsikot kuvaavat työn tyypillisiä vaiheita, esim. asiakkaan tilauksesta toimitukseen. Näin näette nopeasti missä tehtävälaput etenevät ja missä ne jumittavat.
2. Määritä WIP jokaiselle sarakkeelle
WIP (Work in Progress) tarkoittaa suurinta sallittua määrää keskeneräisiä tehtäviä kussakin työvaiheessa. Sen tarkoitus on parantaa työn virtausta rajoittamalla keskeneräisyyttä, jolloin tukokset vähenevät, laatu paranee ja työ saadaan yhteistyöllä nopeammin valmiiksi.
WIP-luvut yleensä laskevat tiimin kehittyessä paremmaksi. Hyvä lähtökohta on aloittaa WIP-luvuista, jotka vastaavat nykyistä todellisuutta, esimerkiksi tyypillistä määrää samanaikaisesti kesken olevia tehtäviä. Tämän jälkeen WIP-lukuja lasketaan tarkoituksella niin alas, että virtaus heikkenee ja pullonkaulat sekä riippuvuudet paljastuvat. Kun esteet on poistettu, virtaus paranee uudella, alemmalla WIP-tasolla.
Hyvä nyrkkisääntö monessa tiimissä on WIP ≤ tiimin henkilömäärä, mutta todellinen tavoite on aina edellistä pienempi toimiva WIP. Liian pieni WIP löytyy, kun virtaus ei palaudu parannuksista huolimatta.
3. Kirjaa ja paranna tehtävien läpimenoaikaa
Läpimenoaika (Lead Time) tarkoittaa keskimääräistä aikaa asiakkaan tekemästä tilauksesta sen toimitukseen asiakkaalle. Kiertoaika (Cycle Time) taas mittaa keskimääräistä aikaa tehtävän aloituksesta sen valmistumiseen. Asiakas näkee aina Lead Timen. Jos siis tärkeä tilaus muhii pitkään sähköpostissa, Kanban-taululla tai Product Backlogissa, tai lopputulosta ei viedä ripeästi tuotantoon (ts. asiakas ei saa sitä käyttöön), Lead Time kärsii tiimistä riippumattomista syistä.
Tiimin sisällä mitataan yleensä kiertoaikaa (Cycle Time), mutta liiketoiminnan tulisi olla kiinnostunut läpimenoajasta (Lead Time). Sen minimointi vaatii yhteistyötä organisaation sisällä, kuten tuotteen koko arvoketjun visualisointia ja nopeutusta. Mittaamalla systemaattisesti läpimeno- ja kiertoaikaa voi pikkuhiljaa optimoida työvaiheita, prosessia ja kokeilla erilaisia WIP-arvoja kiertoajan lyhentämiseksi ja ennustettavuuden parantamiseksi.
Jurgen Appelon mainio kuvaus Lead Timesta ja Cycle Timesta.
Kanban strategiana virtauksen parantamiseen
Kanban on ennen kaikkea strategia työn virtauksen parantamiseen, ei vain valmistavan teollisuuden tai ohjelmistokehityksen menetelmä. Sama perusajatus toimii monissa eri ympäristöissä, vaikka työn konteksti vaihtuu.
Tukipalveluissa Kanban näkyy työjonona, jossa tavoitteena on lyhentää vasteaikaa. Pizzeriassa Kanban näkyy pizzajonona: uusia tilauksia otetaan paistoon vain sen verran kuin keittiö ehtii käsitellä ilman ruuhkaa. Tuotekehityksessä Kanban näkyy visuaalisena kehitysjonona, esimerkiksi sprintin backlogina, jossa tiimin työ etenee vaiheittain kohti valmista. Kanbanin pull-mekanismi onkin sisäänrakennettu Scrumin Sprint Backlogiin.
Lean- ja kanban-ajattelu korostaa virtaustehokkuutta ennen resurssitehokkuutta. Tämä tuntuu usein epäintuitiiviselta. Kun kaikki ovat jatkuvasti 100 % varattuja, työ jonoutuu ja läpimenoaika kasvaa. Kun keskeneräistä työtä rajoitetaan ja ihmisille jätetään tilaa, työ valmistuu nopeammin ja ennustettavammin, vaikka kaikki eivät ole koko ajan kiireisiä.
Tähän perustuu sekä Kanbanin että Scrumin pull-ajattelu: uutta työtä ei aloiteta ennen kuin edellinen on saatu valmiiksi.
Missä Kanban toimii yksin – ja miten Scrum täydentää sitä
Kanban on kevyt tapa tehdä työ näkyväksi ja parantaa ennustettavuutta. Se ei kuitenkaan ole kehitysmalli eikä yksin riitä monimutkaisen tuotekehityksen ohjaamiseen. Tämä helposti unohtuu, kun Kanbania tarjotaan yleisratkaisuksi kaikkeen tekemiseen.
Osa sekaannuksesta syntyy siitä, että klassinen Kanban (kolme perussääntöä) ja David Andersonin The Kanban Method sekoittuvat usein toisiinsa. Alkuperäinen kanban on tarkoituksella rooliton ja kevyt. Andersonin Kanban Method taas lisäsi ympärilleen käytäntöjä, mittareita ja johtamisen malleja, joita moni alkoi pitää “itse Kanbanina”. Tällöin Kanban vaikuttaa sisältävän valmiin toimintamallin, vaikka kyse on eri asioista.
Kanban ei määrittele vastuualueita, tavoitteita, kokouksia tai työn kontekstia. Siksi se toimii erinomaisesti reaktiivisessa työssä, kuten bugikorjauksissa, tukipalveluissa tai muussa jonotyössä. Sen sijaan ihmisten välinen, luovuutta ja yhteistä ajattelua vaativa tuotekehitys tarvitsee enemmän kuin näkyvän taulun.
Tässä kohtaa Scrum täydentää Kanbania. Scrum rakentuu osin Kanbanin pull-periaatteen varaan (Sprint Backlog on Kanban-taulun sovellus), mutta laajentaa sitä monimutkaiseen työhön sopivaksi. Scrum lisää yksinkertaiset vastuualueet, yhteiset tavoitteet, toistuvat kokoukset, selkeät tuotokset ja pelisäännöt, jotka tukevat päätöksentekoa, yhteistyötä ja oppimista.
Pelkkä lappu seinällä voi riittää yksinkertaisen tehtävän hoitamiseen. Monimutkaisen tuotteen uuden toiminnon fiksu toteutus vaatii yleensä yhteisen tavoitteen, riittävää kommunikointia ja aikarajan, jotka ohjaavat tiimiä yhteistyöhön. Siksi tuotekehityksessä Kanban toimii parhaiten meta-prosessina Scrumin kaltaisen viitekehyksen tukena, ei sen korvaajana.
Yleisiä väärinkäsityksiä Scrumista ja Kanbanista
“Scrumissa julkaistaan vain sprintin lopussa.” Väärin. Scrum edellyttää, että tuote on julkaistavissa viimeistään sprintin lopussa – ei että välijulkaisut (vaikka tasatunnein) olisi kielletty sprintin aikana. Julkaisu on liiketoimintapäätös, ei Scrumin rajoite.
“Scrumissa ei voi reagoida tuotannon bugeihin kesken sprintin.” Väärin. Tuotantoa haittaavat virheet saa ja pitää korjata heti. Sprintin sisältöä voi tarvittaessa mukauttaa, tai äärimmillään sprintti voidaan jopa keskeyttää.
“Sprinttiin sovittua työtä ei saa muuttaa.” Väärin. Sprintin tavoitetta ei pidä rikkoa kevyesti, mutta sovittujen töiden design, tekninen ratkaisu ja tarkentuminen elävät koko sprintin ajan oppimisen myötä.
“Scrum on hidas, koska se odottaa sprintin loppua.” Väärin. Scrum perustuu pull-ajatteluun ja jatkuvaan työn valmistumiseen. Sprintti tuo rytmin, fokuksen, yhteisen vastuun ja ennustettavuuden, ei hidastetta.
“Scrum ei sovi reaktiiviseen työhön.” Osittain väärin. Scrum ei ole malli maksimaaliseen reaktiivisuuteen, mutta maksimaalinen reaktiivisuus tarkoittaa harvoin maksimaalista tuottavuutta. Scrum toimii hyvin tilanteissa, joissa reaktiivisuutta halutaan tietoisesti vähentää parantamalla arvontuottoa, laatua, ennakointia ja yhteistyötä.
“Kanban on kevyempi ja siksi aina parempi.” Väärin. Kanban on kevyempi siksi, että se jättää monet asiat määrittelemättä. Monimutkaisessa tuotekehityksessä tämä tarkoittaa usein, että tarpeelliset rakenteet joudutaan keksimään uudelleen, tai ne puuttuvat kokonaan.
“Kanban on valmis prosessi.” Väärin. Kanban ei määrittele rooleja, kokouksia, tavoitteita tai vastuita. Se on strategia työn virtauksen parantamiseen, ei kokonainen toimintamalli.
“Kanban tarkoittaa vain taulua ja lappuja.” Väärin. Taulu on vain väline. Kanbanin ydin on virtauksen ohjaaminen, WIP-rajoitukset ja läpimenoaikojen parantaminen – ilman näitä taulu on pelkkä seinäkoriste.
“Kanban riittää kaikkeen työhön sellaisenaan.” Väärin. Kanban toimii erinomaisesti reaktiivisessa ja jonopohjaisessa työssä, mutta monimutkainen tuotekehitys tarvitsee usein tuekseen selkeät tavoitteet, vastuualueet ja päätöksenteon rakenteet.
“Kanbanissa ei tarvita tavoitteita.” Väärin. Kanban ei määrittele tavoitteita, mutta ilman yhteistä suuntaa työ hajautuu ja kokonaisuus hämärtyy.
“Kanban tarkoittaa jatkuvaa työn syöttämistä.” Väärin. Kanban perustuu pull-ajatteluun. Uusi tehtävä aloitetaan vasta, kun kapasiteettia vapautuu, eikä silloin, kun joku keksii uuden kiireen.
“Kanban tekee työstä automaattisesti nopeampaa.” Väärin. Kanban tekee työn näkyväksi. Nopeus paranee vasta, kun näkyviin tuleviin pullonkauloihin ja riippuvuuksiin myös puututaan.
“Kanban on kevyempi, koska se vaatii vähemmän kurinalaisuutta.” Päinvastoin. Kanban vaatii usein enemmän kurinalaisuutta, koska se ei tarjoa valmiita rakenteita tai rytmiä – tiimin on itse rakennettava ne.
“Tekninen työkalu hoitaa pull-mekanismin puolestamme.” Väärin. Työkalut voivat tukea näkyvyyttä ja WIP-rajoja, mutta ne eivät tee päätöksiä eivätkä takaa yhteistyötä. Pull-ajattelu syntyy ihmisten valinnoista, kuten milloin uutta työtä aloitetaan, mitä jätetään aloittamatta, milloin tehdään yhteistyötä ja miten esteisiin reagoidaan.
Yhteenveto
Scrum ja Kanban ymmärretään usein väärin. Scrumista nähdään säännöt ilman tarkoitusta, Kanbanista väline ilman kontekstia. Todellisuudessa molemmat pohjautuvat samaan pull-ajatteluun ja jatkuvaan parantamiseen, mutta palvelevat eri tarpeita. Kysymys ei ole Scrum vai Kanban, vaan minkä tyyppisiä ongelmia halutaan ratkaista ja millä rakenteilla.