Japaninkielinen sana kanban tarkoittaa suomeksi näkyvää taulua.
Kanban-menetelmä sisältää vain kolme sääntöä, jotka voi osin mieltää Scrumin laajennukseksi samaan tapaan, kuin eXtreme Programming (XP) ja Test-Driven Development (TDD) -käytäntöjä voidaan hyödyntää Scrum-viitekehyksen sisällä.
Kanbanin kolme sääntöä:
1. Näkyvöitä työnkulku
- Pilko työt sopivankokoisiin tehtäviin
- Kirjaa kukin tehtävä paperilapulle ja kiinnitä laput kanban-tauluun
- Kuvaa taulun sarakkeilla missä työvaiheessa kukin tehtävä on
2. Määritä WIP taulun jokaiselle sarakkeelle
WIP (Work in Progress) tarkoittaa suurinta määrää tehtäviä, joita kyseisessä sarakkeessa saa kerrallaan olla, jottei sarakkeeseen kasaantuva työ hidasta muita työvaiheita.
3. Kirjaa ylös tehtävien läpimenoajat
Läpimenoaika (Lead Time) tarkoittaa keskimääräistä aikaa yhden tehtävän valmistumiseen. Kun olet mitannut läpimenoajan, optimoi pikkuhiljaa prosessia ja kokeile erilaisia WIP-arvoja läpimenoajan lyhentämiseksi ja ennustettavuuden parantamiseksi.
Scrumin ja Kanbanin ero on siinä, ettei Kanban sisällä kehitysjaksoja (sprintejä), vaan määrittely- ja suunnittelupalavereita pidetään aina tarvittaessa ja ohjelmistosta julkaistaan uusi versio heti, kun pienin markkinoitava ominaisuusjoukko valmistuu. Näin Kanban-taulu ei koskaan tyhjene vaan pysähtyy viikonlopuksi kuin liukuhihna.
Kanban sopii luontevimmin tilanteisiin, joissa työn sisältöä on mahdotonta lukita edes yhdeksi viikoksi. Esimerkiksi ohjelmiston ylläpidossa voidaan Kanbania käyttää reagoimaan lähes välittömästi käyttäjien bugiraportteihin. Esimerkistä tosin herää kysymys kannattaisiko laatuun kiinnittää huomiota jo kehitysvaiheessa määrittelemällä vaatimuksille Definition of Done, joka sisältää automatisoidut ja läpäissyt yksikkö- ja/tai hyväksymistestit.
Ennen Kanbanin toteuttamista kannattaa arvioida, tarvitseeko muutoksiin todella reagoida päivittäin ja mitä vaikutuksia tällä on. Jos samalla luovutaan Scrumin tasapitkistä kehitysjaksoista, saatetaan kadottaa osa työn tavoitteellisuudesta, kun sprintille määriteltävä tavoite ja ajan loppumisen tunne jäävät pois. Suunnittelu- ja katselmointikokouksiin on myös vaikeampaa osallistua, kun kokousaikaa ei etukäteen voida sopia, ja julkaisuaikoja voi olla hankalaa ennustaa suuremmalle projektille. Tuoteomistajan tulee lisäksi olla ketterä kuin gaselli sopeutuakseen töiden jatkuvaan “syöttämiseen”, ellei Selected-sarakkeeseen (kts. kuva alla) aseteta niin korkeaa WIP-arvoa, että tuoteomistaja ehtii välillä tehdä muutakin.
Haasteista huolimatta Kanbanille löytynee käyttökohteita varsinkin ohjelmistojen ylläpitotiimeistä. Hopealuoti Kanban ei kuitenkaan ole ja ennen sen toteutusta kannattaa ketteryyttä harjoitella vaikkapa Scrumilla. Scrumia ja Kanbania yhdistelevä kehitysmalli, jossa ei ole sprintejä, tunnetaan nimellä Scrum-ban.
Kuva on Henrik Knibergin kirjasta Kanban vs Scrum.
Lue lisää Scrumista ja Kanbanista tai tutustu Kanban Express -koulutukseen.
