Me olemme kyllä käyttäneet kanbania Scrum-kehityksessä jo kauan ennen Leania. Mutta se on myös Lean-projektissamme täysin looginen jatkumo: Ensin korjataan edellytykset sille, että työn virtaamista voidaan mitata. Sen jälkeen kanbanin avulla pidetään huolta, että virta pysyy tasaisena.

Kanban tekee asioita näkyväksi

Kanban on taulu, jossa tehtävät virtaavat vasemmalta oikealle, tehtävälistasta valmistuneisiin, erilaisten työvaiheiden kautta. Kanbanin myötä nähdään visuaalisesti ja yhdellä silmäyksellä, mitä kunkin tiimin jäsenellä on työn alla, mikä on työtilanne ja miten tehtävät virtaavat prosessin läpi. Tämä on itsessään jo hyödyllistä, mutta sen lisäksi kanban paljastaa kaksi erittäin tärkeää asiaa: mihin työ pysähtyy ja miksi työtä tehdään uudelleen.

Keskeneräinen työ tulee esiin. Se pötköttää joko backlogilla eli tehtävälistalla, eikä pääse liikkeelle tai sitten tehtävä juuttuu keskelle prosessia ja jää sinne tukkimaan virtausta. Kun tunnistetaan, mihin tehtävät tökkäävät, voidaan ratkoa työn virtauksen esteitä. Mitä joudumme odottamaan ja miksi? Mikä prosessissa on pielessä?

Toinen tärkeä asia on päästä tunnistamaan ja mittaamaan, miksi ja milloin teemme työtä uusiksi. Missä kohdissa prosessia teemme virheitä ja miten voimme niitä estää? Sitähän se prosessin kehittäminen on, jatkuvaa viilaamista, että pystytään tekemään entistä parempaa laatua ja arvoa asiakkaalle.

Olennaista on tietää, mikä on valmis

Jokaiseen steppiin kuuluu olennaisesti validointi, eli tarkastus, onko tehtävä valmis siirrettäväksi eteenpäin. Erityisen merkittävä on viimeinen vaihe, jossa tehtävä katsotaan kokonaan valmistuneeksi. Jokaisessa projektissa on tärkeä määritellä, mikä on valmis eli mikä on Definition of Done (DoD).

Meillä DoDit määritellään projekti- ja tiimikohtaisesti, mutta niissä on samoja periaatteita aina taustalla. Valmiin määritelmä voi olla joskus hyvin yksinkertainenkin ja silti toimiva. Teimme esimerkiksi yhden kokoluokkaa valtavan, eli noin 10 000 työtuntia vaatineen projektin, jonka DoDiksi määriteltiin yksinkertaisesti: ei hävetä. Tehtävän saa merkitä valmiiksi, kun se ei hävetä. Projekti onnistui loistavasti.

Tietysti validointiin kuuluu olennaisesti myös koodikatselmoinnit, testaukset tai esimerkiksi saavutettavuuden ja esteettömyyden vaatimusten täyttäminen. Riippuu paljon tehtävätyypistä, millaisia asioita tehtävän tulee täyttää ennen kuin se on valmis uimaan kanban-taululla seuraavaan vaiheeseen.

Yleisesti suositellaan, että kanban-taulun tulisi olla fyysinen. Meillä taulu on rakennettu JIRAan ja tuotu näkyväksi työtilojen näytöille. Se tuntuu toimivan sähköisestikin oikein hyvin. Jos kanban siis kiinnostaa, niin voit kokeilla sitä näppärästi itsekin joko seinän ja post-it-lappujen avulla tai vaikkapa Trellossa.

Aiemmat blogitekstimme Leanista:

Hyvin määritelty ei ole vielä puoliksikaan tehty

Lean ruokkii uteliasta, kehittämishaluista luonnetta

Lean IT ei pidä odottamisesta eikä arvosta resurssitehokkuutta

Leanin ydinviesti kolmessa minuutissa


Kolahtiko? Kerro ajatuksesi, olemme sinuun yhteydessä.

Avainsanat:
kanban, lean, projektityö
ambientia

Blogi