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.
Lähteet:
Kniberg & Skarin. 2010. Kanban and Scrum: making most of both.
Anderson. 2010. Kanban: Succesful Evolutionary Change for Your Technology Business.
