Japaninkielinen sana kanban tarkoittaa suomeksi näkyvää taulua.
Kanban-menetelmä sisältää vain kolme sääntöä, jotka voi ajatella Scrumin tarkennuksena samaan tapaan kuin Test-Driven Development (TDD) tai DevOps. Kanbania voi myös hyödyntää sellaisenaan minkä tahansa prosessin visualisointiin ja kehittämiseen.
Kanbanin kolme perussääntöä:
1. Näkyvöitä työnkulku
Pilko työt sopivankokoisiin tehtäviin
Kirjaa kukin tehtävä paperilapulle ja kiinnitä laput kanban (tai scrum) -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 toimitukseen alkaen siitä, kun tehtävä on tilattu. Cycle Time taas mittaa keskimääräistä aikaa tehtävän aloituksesta sen valmistumiseen. Asiakas näkee aina Lead Timen. Jos siis tärkeä tilaus muhii pitkään sähköpostissa, Product Backlogissa tai Kanban-taulun Backlogissa, tai lopputulosta ei viedä tuotantoon (ts. asiakas ei saa sitä käyttöön), Lead Time kärsii tiimistä riippumattomista syistä.
Tiimin sisällä mitataan yleensä Cycle Timea, mutta liiketoiminnan tulisi olla kiinnostunut Lead Timesta. Sen minimointi vaatii yhteistyötä organisaation sisällä. Kun oppii mittaamaan (jompaa kumpaa) läpimenoaikaa, voi optimoida pikkuhiljaa työvaiheita, prosessia ja kokeilla erilaisia WIP-arvoja läpimenoajan lyhentämiseksi ja ennustettavuuden parantamiseksi.
Jurgen Appelon mainio kuvaus Lead Timesta ja Cycle Timesta.
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 (Minimum Viable Product, MVP) valmistuu. Näin Kanban-taulu ei koskaan tyhjene vaan pysähtyy viikonlopuksi kuin liukuhihna.
Kanban sopii luontevimmin tilanteisiin, joissa työn tavoitteet muuttuvat päivittäin. Esimerkiksi puhtaassa ohjelmiston ylläpidossa voidaan Kanbania käyttää reagoimaan lähes välittömästi käyttäjien bugiraportteihin. Scrumissakin sprintiin sovittujen töiden designia muokataan tarvittaessa koko kehitysjakson ajan. Yleensä kuitenkin vain tuotantoa haittaaviin virheisiin reagoidaan Scrumissa välittömästi: On viisaampaa rakentaa proaktiivisesti vaahtosammutin kuin juosta reaktiivisesti pienten tulipalojen perässä. Scrumin sprinteissä saa siis aina korjata tuotantovirheen, jolloin kehitysjaksoon sovittu työ vain keskeytyy ja viivästyy.
Ylläolevasta esimerkistä herää kysymys, kannattaisiko laatuun kiinnittää huomiota jo kehitysvaiheessa, vaikkapa tarkistamalla valmiin määritelmää ja kehittämällä testausprosessia. Parhaimmillaan reaktiivista korjaustiimiä ei koskaan tarvita, vaan sama tiimi voi hoitaa jatkokehityksen ja tarvittaessa korjaukset.
Ennen Kanbanin toteuttamista kannattaa arvioida, tarvitseeko muutoksiin todella reagoida päivittäin, tai tehdä useampia projekteja samaan aikaan (varsinkaan ilman projektitöitä tiimille priorisoivaa tuoteomistajaa), ja mitä vaikutuksia näillä on. Jos luovutaan Scrumin tasapitkistä kehitysjaksoista, katoaa 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, jos toistuvaa kokousaikaa ei ole kalentereissa, ja julkaisuaikoja voi olla hankalampaa ennustaa suuremmalle julkaisulle. Tuoteomistajan tulee lisäksi sopeutua töiden jatkuvaan “syöttämiseen”, ellei Selected-sarakkeeseen (kts. kuva) aseteta niin korkeaa WIP-arvoa, että tuoteomistaja ehtii tehdä muutakin. Artikkelin kuva on kirjasta Kanban and Scrum.
Haasteista huolimatta Kanbanille löytyy käyttökohteita varsinkin ohjelmistojen ylläpitotiimeistä sekä tilanteista, jolloin työnkuva on vahvasti reaktiivinen (esim. Puhdas ohjelmistovirheiden korjaaminen, assistentit, mainostoimistot, jne.) tai sama tiimi joutuu tekemään useampia projekteja samaan aikaan ilman tuoteomistajaa, joka priorisoi työtä projektien välillä. Hopealuoti Kanban ei kuitenkaan ole ja ennen sen toteutusta kannattaa ketteryyttä mahdollisuuksien mukaan harjoitella vaikkapa Scrumilla.
Scrumia ja Kanbania yhdistelevä kehitysmalli, jossa ei ole sprintejä, tunnetaan nimellä Scrumban. Siinä Kanbanin keveyttä voidaan tukea valitsemalla Scrumista sopivaksi katsottuja elementtejä, kuten rooleja, kokouskäytäntöjä tai kehitysjonoja.
Kanban-taulu – joka kuuluu myös Scrumiin – auttaa tiimiä näkyvöittämään työnsä, rajoittamaan työn määrää WIP-arvoilla (estää mahdollisia tukoksia) ja havaitsemaan ongelmia, kuten kuvassa. Kuva on Henrik Knibergin kirjasta Kanban and Scrum.
Jos haluat oppia lisää Kanbanista, Scrumista ja muista ketteristä menetelmistä, olet tervetullut Ketterille Kahveille. Tunnin maksuton videokokous perustuu Lean Coffee -formaattiin ja pureutuu osallistujien ehdottamiin aiheisiin. Tavoitteena on jakaa oppeja ja osaamista ketteristä menetelmistä.
Tutustu myös käytännölliseen Kanban & Scrum Express -koulutukseen.
