Kanban on suosittu, mutta myös paljon väärinkäytetty tiimin toiminnanohjauksen työkalu. Kanban tarkoittaa joillekin tiimeille vain kasaa lappuja seinällä, toisille itseään parantavaa ja jatkuvaa tehokkuutta luovaa prosessityökalua. Kanban voi olla tehokkain tai tehottomin tapa parantaa tiimien toimintaa. Onneksi sen yksinkertaisuus tuo myös yksinkertaiset tavat tunnistaa millaista Kanbania missäkin tiimissä käytetään. Tämän tekstin lopussa olevilla neljällä kysymyksellä saat tietää vaatiko teidän tiiminne Kanban vielä kehittämistä.
Kanbanista puhuttaessa pitää ymmärtää sen historia. Kanbanin juuret ovat valmistavan teollisuuden puolella, mutta se on rantautunut moniin tuote- ja palvelukehitystiimeihin työkaluksi. Kanbanin perusajatuksena on tarvevetoisuus ja samanaikaisen tekemisen rajoittaminen. Eli asioita tehdään vasta kun edelliset on saatu valmiiksi ja tarve uudelle tekemiselle tulee. Kanban sisältää kolme pääsääntöä, joista pelkästään yhdellä ei selviä: työnkulun visualisointi (visualize workflow), samanaikaisen työn rajoittaminen (limiting WIP) ja läpimenoajan mittaaminen (measure flow).
Huonoimmassa tapauksessa Kanbanista on käytössä vain työnkulun visualisointi eikä mitään muuta. Tällöin menetetään esimerkiksi tiimimäisyyden hyödyt, kun tiimin jäsenet hallitsevat omia tehtäviään samalla taululla, mutta eivät kuitenkaan auta toisiaan. Pelkkä Kanban taulu ilman ohjausta tuo läpinäkyvyyttä ja ymmärrystä tekemiseen, mutta muuta arvoa sillä ei juurikaa ole. Pahimmillaan se jopa tuo valheellisen uskon oman toiminnan laadukkuuteen ja piilottaa todelliset ongelmat.
WIP (Work in Progress) rajojen käyttö nostaa Kanbanin arvoa jo hyvinkin paljon. Niiden avulla pyritään jo optimoimaan prosessia ja saavuttamaan tuloksia nopeammin. Toki WIP rajojen käyttö edellyttää uskallusta rajoittaa työtä niiden mukaisesti. Rajojen tulee olla mahdollisimman tiukkoja, jotta ne eivät mahdollista monien asioiden samanaikaista työstöä. WIP rajojen käyttö onkin jo iso edistysaskel tiimien toiminnassa. Tällaisessakin Kanbanissa on vielä parantamisen varaa. Varsinkin prosessin jatkuvan parantaminen osa-alueella on usein puutoksia.
Hyvän Kanbanin edellytykset
Monet pitävät Kanbanin läpimenoajan mittaamista ja optimointia tärkeimpänä osana prosessia. Tämä on tuote- ja palvelukehityksessä haastavampi aihe. Valmistavassa teollisuudessahan Kanbanin läpimenoaika on oleellisessa osassa, mutta siellä Lean prosessin tärkeimpiä ajatuksia onkin samanmittaisuus ja variaatioiden minimointi. Tuote- ja palvelukehityksessä variaatiot ovat sisäänrakennettuina työn luonteen vuoksi. Kehitysasioiden kokoa ei voi arvioida etukäteen ja siksi myös Kanbanin läpimenoaika vaihtelee. Toki pitkän aikavälin mittaus auttaa tällaisessakin Kanbanissa ymmärtämään tehokkuuden kehittymistä, mutta tulokset eivät ole yhtä yksiselitteisiä kuin valmistavassa teollisuudessa.
Monet pitävät Kanbanin läpimenoajan mittaamista ja optimointia tärkeimpänä osana prosessia. Tämä on tuote- ja palvelukehityksessä haastavampi aihe. Valmistavassa teollisuudessahan Kanbanin läpimenoaika on oleellisessa osassa, mutta siellä Lean prosessin tärkeimpiä ajatuksia onkin samanmittaisuus ja variaatioiden minimointi. Tuote- ja palvelukehityksessä variaatiot ovat sisäänrakennettuina työn luonteen vuoksi. Kehitysasioiden kokoa ei voi arvioida etukäteen ja siksi myös Kanbanin läpimenoaika vaihtelee. Toki pitkän aikavälin mittaus auttaa tällaisessakin Kanbanissa ymmärtämään tehokkuuden kehittymistä, mutta tulokset eivät ole yhtä yksiselitteisiä kuin valmistavassa teollisuudessa.
Tuote- ja palvelukehityksen Kanbanissa keskimääräistä läpimenoaikaa tärkeämpiä ovatkin eri vaiheiden välisten sääntöjen noudattaminen sekä jatkuva oppiminen ja kokeilu. Scrummista tuttu Definition of Done -ajattelu, jossa määritellään selkeä yhteinen näkemys mitä Done tarkoittaa on elintärkeää myös Kanbanissa. Kaikilla tiimien jäsenillä tulee olla sama ymmärrys siitä, mitä pitää olla tehtynä, kun tehtävä siirtyy seuraavaan kohtaan taulussa. Toinen Scrummista tuttu asia, eli retrospektiivit tulisi olla käytössä myös Kanbania käyttävillä tiimeillä. Retrospektiivin aikataulun voi sitoa joko kalenteriin tai tiettyyn määrään läpimenneitä itemeitä. Tärkeintä kuitenkin on, että tiimit arvioivat kriittisesti toimintaansa ja tekevät toimintaa tehostavia kokeiluja, esimerkiksi WIP-rajoja muuttamalla.
Kanbanin vaarana siiloutuminen
Yksi Kanbanin vaaroista tuote- ja palvelukehityksessä on siiloutuminen. Kanbanin vaiheista tehdään henkilökeskeisiä ja sitten itemeitä siirretään taulussa ihmiseltä toiselle. Jokaisessa tällaisessa tiedonsiirrossa (handover) katoaa iso määrä tietoa (joidenkin mukaan jopa 50%). Tiedonsiirtoja ja siiloutumista tuleekin välttää. Onnistumisen avaimena on WIP-rajojen tiukka noudattaminen tiimeissä siten, että rajat eivät mahdollista jokaiselle omaa tekemistä, vaan pakottavat tiimiläiset auttamaan toisiaan.
Yleisin esimerkki huonosta Kanbanista on testaus-vaihe, jossa kehittäjät luovuttavat oman tekeleensä testaukselle ja ottavat seuraavan työn alle. Pahimmillaan testauksen työjono vain kasvaa, mutta se ei silti blokkaa uuden työn aloittamista. Testausvaiheessa WIP rajan pitää olla niin tiukka, että se pakottaa koko tiimiä tekemään kaikkensa sen vaiheen nopeuttamiseksi. Tässä harva tiimi onnistuu ja harvat yritykset uskaltavat painostaa tähän. Tällainen vaatii todella hyvää ymmärrystä kokonaisuuden maksimoinnista, joka ei perustu ihmisten maksimaaliseen ajan allokaatioon, vaan itemeiden läpimenoajan maksimointiin.
Neljä kysymystä Kanbania käyttävälle tiimille
Kun halutaan arvioida Kanbania käyttävän tuote- tai palvelukehityksen tiimin toimintaa prosessin näkökulmasta, niin tiimiltä voi kysyä seuraavat kysymykset. Jos yhteenkin kysymykseen tiimi vastaa ”Ei”, niin tiimin Kanbanin käytössä on varmasti parannettavaa.
- Onko Kanban taulu kaikkien jäsenten ja tärkeimpien sidosryhmien nähtävillä ja jatkuvasti päivitettynä ?
- Onko Kanban taulun jokaisella kolumnilla WIP raja, jota noudatetaan tarkasti?
- Onko WIP rajoja muutettu viimeisen kolmen kuukauden aikana?
- Onko tiimin WIP rajojen summa pienempi tai yhtä suuri kuin tiimin henkilömäärä?
Jos tiimi vastaa mihin tahansa kysymykseen ”Ei”, niin tiimin kannattaa keskustella toiminnan kehittämisestä. Kanban vaatii jatkuvaa parantamista ja kehittämistä. Ehkäpä kaikki tiimit eivät pysty koskaan vastaamaan viimeiseen kysymykseen ”Kyllä”, mutta siihen pitäisi kuitenkin pyrkiä. Tiimin hyöty on juuri se, että se pystyy tuottamaan enemmän kuin sen yksilöt tuottavat erikseen. Se onnistuu vain kun tiimi toimii yhdessä edistäen itemeitä eteenpäin mahdollisimman tehokkaasti.
Kanban voi olla erittäin tehokas työkalu toimitusnopeuden optimointiin ja laadun parantumiseen. Pelkkä Kanban taulun käyttäminen ei kuitenkaan riitä. Kanban vaatii kurinalaisuutta ja ymmärrystä yhden itemin läpimenoajan maksimoinnin tärkeydestä. Kanban käyttäminen ei missään nimessä ole vaikeaa, mutta se vaatii jatkuvaa huomiota ja ymmärrystä sen periaatteista. Kanbanista kannattaa ottaa kaikki hyöty irti.
Opi lisää kuuntelemalla maksuton webinaari aiheesta jälkitallenteena Oppia.fi sivustolta. Äänessä kirjoittaja itse. Oppimisen verkkokaupan pitkäaikainen kouluttajakumppani Contribyte tarjoaa erilaista ketterien menetelmien asiantuntijuutta myös koulutuksillaan. Tutustu tästä!
Henri Hämäläinen
Kirjoittaja on tuotekehitysyritysten toiminnan parantamiseen keskittyvän Contribyten toimitusjohtaja ja johtava konsultti. Henrillä on yli 10 vuoden kokemus erilaisista ketteristä organisaatioista ja on hän ollut auttamassa kymmeniä tiimejä Kanbanin käytön tehostamisessa.
Tämä blogikirjoitus on julkaistu alunperin Contribyten omilla sivuilla 12/2016.
Lisää ketterien menetelmien eri koulutuksia Oppimisen verkkokaupasta!