Blogi • 18.03.2020

Mikä on Kanban?

Mikä on Kanban?

Kanban on työkalu minkä tahansa työn tehokkuuden optimointiin ja sujuvoittamiseen. Kokemusperäisen työkalun lähtökohta on perusmalli, jota kukin voi kehittää itselleen sopivaksi ajan ja saadun opin myötä. Kanban ei anna kaikkia vastauksia, mutta tarjoaa lähtökohdan omalle prosessikehityksellesi.

Kaksi tunnetuinta ketterien menetelmien työkalua ovat Scrum ja Kanban. Scrumin olen esitellyt aikaisemmin, joten nyt tutustumme Kanbaniin.

Mallit eivät ole mitään varsinaisia projektinhallintamalleja vaan työkaluja työn tehokkuuden optimointiin. Molemmat työkalut ovat kokemusperäisiä eli sinun oletetaan aloittavan perusmallilla ja kehittävän sitä itselle sopivammaksi ajan myötä. Kumpikaan työkalu ei anna kaikkia vastauksia vaan tarjoavat vain lähtökohdan omalle prosessikehityksellesi. Tälle jatkuvan kehityksen ajattelulle on myös monta nimeä (Kaizen, Empirical Process Control, The Scientific Method jne.), jotka kaikki käytännössä seuraavat Demingin laatuympyrää.


Kuva: Demingin laatuympyrä

 

Imuohjaus

Kanban-taulu on peruja Toyotan tehdassaleista, missä Just-in-time eli JIT-periaate kehitettiin. Tavoitteena on ohut, tasainen ja oikea-aikainen virta, jota ohjaa tarve. Tarpeeseen perustuvaa toiminnanohjausta kutsutaan imuohjaukseksi. Seuraavan prosessivaiheen tarve imee tehtävän edelliseltä vaiheelta. Työntöohjauksessa, kuten Scrumissa, ennalta tehty suunnitelma työntää tehtävät prosessin läpi. (toim. huom. Scrumin Sprintti on imuohjausta verrattaessa vuosia pitkään vesiputousprojektiin, eli imu ja työntö ovat suhteellisia termejä.)

Lean-ajattelu

Varastointi aiheuttaa kustannuksia ja piilottaa prosessin ongelmat. Minimoimalla varastot vähennät kustannuksia ja ongelmia. Jos sinulla on rinnakkain kaksi tehtävää kesken, niin toinen tehtävä on varastossa, sillä aikaa, kun työstät toista tehtävää. Kun edistät kahta tehtävää ”rinnakkain”, niin molemmat valmistuvat keskimäärin puolet hitaammin ja tehtävien välillä kontekstin vaihtamiseen kuluva aika on hukkaa. Tässä oman toiminnan ”leanaamista” on pilkkoa tehtävät järkevän kokoisiin osiin ja tehdä osa kerrallaan valmiiksi asti.

Kanban-taulu

Kanbanin keskeinen periaate on visualisoida työn kulku Kanban-taululla. Taulu kuvaa työn kulun vaiheet selkeästi nimetyillä sarakkeilla.

Kuva: Yksinkertainen Kanban-taulu

Kanbanin kolme sääntöä

#1 Visualisoi työn kulku

Jaa tekemätön työ paloihin. Kirjoita joka palalle oma korttinsa ja laita kortti taululle ”TEKEMÄTTÄ”-sarakkeeseen. Huolehdi, että taulun sarakkeiden nimeäminen on selkeää ja kuvaa, missä vaiheessa kukin kortti on.

Kuva: Tehtävät Kanban-taululla

#2 Mittaa läpimenoaikaa

Kanban-prosessin tehokkuutta mitataan kortin keskimääräisellä läpimenoajalla eli ajalla mikä korteilta keskimäärin kuluu siirtyä ”TEKEMÄTTÄ”-sarakkeesta ”VALMIS”-sarakkeeseen.

Kuva: Läpimenoajan mittaaminen (ja visualisointi)

#3 Rajoita työn alla olevien tehtävien määrää

Läpimenoaikaa säädetään rajoittamalla sarakkeisiin otettavien korttien määrää. Optimoi vaiheita ja rajoittimia, niin että läpimenoaika on mahdollisimman pieni ja ennustettava.

Kuva: Työn-alla-olevien-tehtävien-määrä -rajoittimen käyttö

Kanban virittäminen työn-alla -rajaa muuttamalla

Perusmuotoinen Kanban asettaa vähän sääntöjä. Taulun sarakkeet ja työn-alla-olevien-tehtävien-rajoittimet ovat kuitenkin jo tehokas apuväline.

Klassinen esimerkki. Työn alla saa olla vain 1 tehtävä kerralla.

Kuva: Työn-alla-olevien-tehtävien-määrä -rajoitin on 1. Tätä tehtävää mahtuu ratkaisemaan 2 kehittäjää ja muut 3 tiimiläistä ovat joutilaina.

Seuraavaksi nostetaan työn-alla-rajoitin reilusti isommaksi.

Kuva: Työn-alla-olevien-tehtävien-määrä -rajoitin on 6. Nyt tiimiläiset aloittavat tehtäviä innokkaasti, mutta koska a) tehtävän valmiiksi saattaminen on aina vähän vaivalloista ja b) koska aloittaminen on kivaa, niin ajaudutaan aloittamaan maksimimäärä tehtäviä. Tämä heikentää läpimenoaikaa.

Kanban ”tiimi”

Kanban on prosessioptimointia. Kanban-taulu ei ota kantaa, kuinka monta tiimiä osallistuu taulun tehtävien edistämiseen. Siinä missä Scrum puhuu ”tiimistä”, Kanban-taulua voi edistää useampi tiimi tai tietyt taulun vaiheet on voitu osoittaa tietyille tiimeille.

Kuva: Jokaiselle työvaiheelle voi olla oma nimetty tiiminsä

Jos tiimit ovat lähekkäin ja monipuolisia, niin tällöin luonnollisesti tehokkainta on, että tiimit auttavat toisiaan tarpeen mukaan ja myös yli rooli- tai prosessivaiherajojen. Jos esimerkiksi DevOps- tai testausvaiheessa tulee ruuhkaa, niin sitten kehitystiimit menevät auttamaan sinne, jotta virtaus saadaan taas käyntiin.

Kuva: Tiimit voivat auttaa toisiaan yli työvaiherajojen

Kanbanin työjono

Kanban ei määrittele työjonoa. Yleisesti vasemmanpuoleinen sarake toimii työjonona. Tähän liittyvät käytännöt pitää suunnitella erikseen. Sekä se, että kuka ja miten työjonoa hallinnoi, että missä järjestyksessä tiimi työjonosta tehtäviä ottaa. Tiimi voi ottaa työjonosta esimerkiksi päällimmäisen, vanhimman tai kiireelliseksi merkityn ensin.

Kuva: Vasemmanpuoleinen sarake voi toimia työjonona

Mittaroi ja visualisoi

Kanban ei määritä mitään mittaroinnista, toisin kuin Scrumin burn-down graafi. Kanbanissa kokeilemisen arvoinen graafi on kuitenkin kumulatiivinen virtausgraafi ”CFD”. Paksut linjat graafissa osoittavat tehtäväsumia ja ohuet linjat tyhjän panttina odottavaa tiimiä.

Kuva: Cumulative Flow Diagram -on hyvä vaihtoehto Kanban-taulun virtaustehokkuuden tarkasteluun

Kanban, Scrum

Scrum määrittelee roolit ja prosessin paljon pidemmälle kuin Kanban. Määrämuotoinen Kanban määrittää vain yllä esitellyt 3 sääntöä. Scrum määrittelee roolit, tiimin koon, tehtävien koon, ajan jaksotuksen, sprinttiprosessin välivaiheet ja burndown graafien käytön.

Kuva: Kanban vs Scrum taulukointi

Työn alla olevien tehtävien määrän rajoittaminen

Scrumissa tehtävien tulee valmistua Sprintin aikana. Isot tehtävät siis pyritään pilkkomaan sen kokoisiksi osakokonaisuuksiksi, että ne mahtuvat yhdelle Sprintille. Kanban ei tällaista ajatusta tunne, vaan rajoittaa vain työn-alla-olevien-tehtävien määrää.

Kuva: Kanban rajoittaa yhtä aikaa työn alla olevien tehtävien määrää. Scrum rajoittaa iteraation aikana tehtävien tehtävien määrää

Tehtävien koon arviointi

Kanban ei määritä työmääräarviointia kuten Scrum. Tehtävät voidaan pyrkiä jakamaan esimerkiksi samankokoisiksi tehtäviksi, jolloin on helppoa mitata, kuinka monta tehtävää tietyllä aikavälillä saatiin Kanban taulusta läpi. Tai tehtävät voidaan ryhmittää jonkin suuremman osakokonaisuuden perusteella. Esimerkiksi yhden käyttötapauksen toteutukseen liittyvät tehtävät. Jolloin voidaan mittaroida käyttötapauksen toteutuksen keskimääräistä kestoa.

ScrumBan

Kanban on yksinkertainen ottaa käyttöön. Sen ympärille lähtee usein kokeilujen myötä muodostumaan enemmän Scrumin kaltaisia rakenteita, jolloin mallia kutsutaan nimellä ScrumBan. Esimerkiksi tuoteomistajan rooli on ihan yhtä elintärkeä, vaikka toimittaisiin Kanbanilla. Ja kun tuoteomistajan rooli esitellään, niin herää kysymys, että koska, missä ja miten tuoteomistaja saa määritellä tehtävien sisältöä ja prioriteetteja, jolloin aletaan tekemään työjonon hallintaa. Sitten kun on pystytetty työjono, niin herää kysymys, että ”koska käyttötapaus X on valmis”, mistä päästään tehtävien työmäärien arviointiin ja jonkinlaiseen sprinttimoodiin, missä isosta työjonosta jyvitetään yksityiskohtaisempia sprintin työjonoja.

Kokeile

Prosessimallien toiminta riippuu täysin toimintaympäristöstä. Scrum ja Kanban ovat hyväksi havaittuja työkaluja, joilla on helppo lähteä liikkeelle. Tärkeintä on silti keskittyä jatkuvasti ja pitkäjänteisti kehittämään toimintaa. Esimerkiksi Kanban taulu voi toimia alhaalta ylöspäin, sarakkeissa voi olla alisarakkeita ja rivejä, ja työjono voi olla omalla erillisellä taulullaan.

Kuva: Vain kokeilemalla löytää parhaiten toimivan Kanban -taulun

Retrospektiivit

Retroja kannattaa pitää säännöllisesti ja eri kokoonpanoilla. Retroja voi pitää esimerkiksi pohdittaessa parannusehdotuksia esimerkiksi tiimiläisten, asiakkaan, prosessien tai ketterien periaatteiden näkökulmasta. Yleisestikin kannattaa kokeilla erilaisia retroideoita. Googlaamalla löytyy kokonaisia sivustoja täynnä erilaisia retro- ja brainstormaus -ideoita.

Jari Hietaniemi
Serice Architect

Lähteet:

Kniberg & Skarin. 2010. Kanban and Scrum: making most of both.

Anderson. 2010. Kanban: Succesful Evolutionary Change for Your Technology Business.

 

Jari Hietaniemi

Jari Hietaniemi

Jari on yksi Goforen monilahjakkaista palveluarkkitehdeista. Hänen ydinosaamistaan on monimutkaisten sekä laajojen tietojärjestelmähankkeiden suunnittelu ja vetäminen. Jarin filosofian mukaan projektipäällikkö on tarvittaessa myös myyntiedustaja, innovaattori, laatupäällikkö, tekninen suunnittelija ja henkilöstöesimies samassa paketissa. Hänen monipuolinen kokemuksensa ja valmentava tyylinsä vievät projektit laadukkaasti maaliin sekä tuovat myös uudenlaista ajattelua ja draivia kohdeorganisaatioon.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.