Miksi kanban toimii – ja mistä tiedät, onko tiimisi valmis siihen

Useimmat tiimit ottavat kanbanin käyttöön, koska joku luki blogikirjoituksen. Viisaampi kysymys on, ovatko kanbanin ratkaisemat ongelmat oikeasti niitä, joita tiimissäsi on.

Useimmat tiimit tunnistavat tilanteen, joka tulee yleensä vastaan, kun tiimissä on yli kahdeksan tai yhdeksän ihmistä. Työ etenee – sähköposteja lähtee, ominaisuuksia julkaistaan, asiakkaita hoidetaan – mutta kukaan ei tiedä selvästi, mitä muut tekevät. Projektit kasautuvat. Asioita luvataan ja unohdetaan hiljaa. Käytät kaksikymmentä minuuttia ennen jokaista palaveria selvittääksesi, missä jokin työ oikeasti on. Vastaus on yleensä ”jossain”.

Juuri tämän ongelman ratkaisemiseksi kanban on kehitetty. Ei strategian määrittelyn, oikeiden ihmisten rekrytoinnin tai kulttuurin rakentamisen, vaan hyvin konkreettisen, puuduttavan operatiivisen ongelman: sen, että tiedetään, mitä tiimi tekee ja mikä on tiellä.

Se on yllättävän vaatimaton työkalu saamaansa huomioon nähden. Kanban ei väitä korjaavansa organisaatiotasi. Se vain tekee työstä näkyvää. Ja näkyvyys, kun sitä sovelletaan johdonmukaisesti, muuttaa hämmästyttävän monia asioita työn myöhemmissä vaiheissa.

Mistä kanban oikeastaan tulee

Sana on japania ja tarkoittaa ”kylttiä” tai ”mainostaulua”. Toyota kehitti järjestelmän 1940-luvun lopulla varastojen hallintaan tehtaissaan. Ajatus oli yksinkertainen: osia ei valmistettu kiinteän aikataulun mukaan, vaan vasta kun seuraava työvaihe ilmoitti tarvitsevansa niitä. Fyysinen kortti – kanban – kulki linjaa takaisin ylävirtaan tilauksena. Mitään ei tehty varmuuden vuoksi. Mitään ei kasaantunut turhaan.

Toyotan oivallus, jonka ohjelmistotiimit myöhemmin omaksuivat, on se, että suurin osa järjestelmän tehottomuudesta ei johdu siitä, että ihmiset työskentelevät liian hitaasti, vaan siitä, että tehdään väärää työtä väärään aikaan. Liian monta asiaa aloitetaan yhtä aikaa. Pullonkauloja ei huomata ennen kuin on liian myöhäistä. Valmis työ jää odottamaan yhteen paikkaan, kun seuraava vaihe hukkuu töihin muualla.

Ohjelmistokehittäjät alkoivat soveltaa näitä ajatuksia tietotyöhön erityisesti 2000-luvun alussa esimerkiksi Microsoftin kaltaisissa yrityksissä. Kortit muuttuivat tehtäviksi. Tehtaan työpisteet muuttuivat työnkulun vaiheiksi. Ja kyltistä tuli taulu – ensin fyysinen, sitten digitaalinen – jolta kuka tahansa tiimissä näki yhdellä silmäyksellä, mikä on työn alla, mikä odottaa ja mikä on valmista.

Mitä kanban-taulu oikeasti näyttää

Perustaulussa on kolme saraketta: Tehtävät, Työn alla ja Valmis. Se riittää monelle pienelle tiimille ja on hyvä aloituspiste. Todellinen hyöty syntyy kuitenkin vasta, kun alat muokata vaiheita vastaamaan sitä, miten työ oikeasti kulkee – ei sitä, miten toivoisit sen kulkevan.

Sisältötiimi voisi käyttää vaiheita: Idea, Briiffi, Luonnos, Tarkistus, Ajastettu, Julkaistu. Ohjelmistotiimi voi jakaa vaiheen ”Työn alla” erillisiin sarakkeisiin kehitykselle, koodikatselmoinnille ja laadunvarmistukselle. Konsulttitiimi voi seurata vaiheita Kartoitus, Tarjous, Käynnissä, Odottaa asiakasta ja Suljettu. Vaiheiden pitäisi heijastaa todellisia vastuunsiirtoja ja todellisia odotusaikoja – kohtia, joissa työ vaihtaa omistajaa tai odottaa jonkin muun tapahtumista.

Huomaa keskimmäisen sarakkeen kortti – varastotarkastuksen raportti, kahdeksan päivää työn alla, merkitty estyneeksi. Ilman taulua tämä tehtävä voisi törröttää paikallaan vielä kaksi viikkoa, ennen kuin kukaan huomaa, ettei se etene. Joku odottaa kolmatta osapuolta. Tai päätös puuttuu esihenkilöltä, joka ei tiedä olevansa pullonkaula. Taulu tekee tukoksen näkyväksi. Se on suurin osa työstä.

Sääntö, joka saa kanbanin toimimaan: WIP-rajat

Jos on yksi käsite, joka erottaa kanbanin oikein käyttävät tiimit niistä, joilla on vain nätimpi tehtävälista, se on keskeneräisen työn rajoitus eli WIP-raja (work in progress). Ajatus on, että jokaisessa sarakkeessa saa olla yhtä aikaa enintään tietty määrä kohteita. Kun sarake on täynnä, uutta työtä ei voi lisätä ennen kuin jokin siirtyy eteenpäin.

Tämä tuntuu oudolta. Eikö se, että useampi tehtävä voi olla työn alla, tarkoita, että saadaan enemmän aikaan? Ei tarkoita. Kun ihmiset työstävät liian montaa asiaa yhtä aikaa, kaikki kestää pidempään. Kontekstinvaihto on kallista. Puolivalmis työ synnyttää koordinointityötä. Ja kun kymmenen asiaa on ”työn alla”, on erittäin vaikea sanoa, mitkä niistä oikeasti etenevät ja mitkä ovat vain jumissa ilman merkintää.

Kolmen kohteen WIP-raja Työn alla -sarakkeessa tarkoittaa, että kun neljäs asia ilmestyy jonkun pöydälle, tiimin on päätettävä: mikä olemassa olevista tehtävistä saatetaan ensin loppuun? Se pakottaa priorisoimaan. Se pakottaa keskustelemaan. Ja yksittäiset kohteet valmistuvat yleensä nopeammin, vaikka uusien aloitusvauhti hidastuisi.

Kanban vai Scrum: kysymys, jota tiimit kysyvät aina

Jos olet viettänyt aikaa ohjelmistotiimien tai nykyaikaisen operaatioajattelun parissa, olet todennäköisesti törmännyt Scrumiin – viitekehykseen, joka jäsentää työn kiinteisiin kahden viikon sprintteihin, suunnittelupalavereihin, retrospektiiveihin ja määriteltyihin rooleihin kuten Scrum Master ja Product Owner. Monet tiimit pitävät Scrumia ja kanbania kilpailevina menetelminä ja kokevat, että niiden on valittava. Ero on itse asiassa yksinkertaisempi.

Monet tiimit – erityisesti ne, jotka eivät ole puhtaita ohjelmistokehitystiimejä – kokevat Scrumin seremoniat raskaiksi ja kiinteät sprintit hankaliksi soveltaa jatkuvaan operatiiviseen työhön. Markkinointitiimien, asiakasmenestystiimien, operaatiotiimien ja kaikkea yhtä aikaa hoitavien perustajien työ harvoin mahtuu siististi kahden viikon sykleihin. Kanbanin jatkuvan virtauksen malli sopii heille yleensä paremmin.

Siitä huolimatta monet tiimit yhdistävät molemmat. Ne käyttävät sprinttimuotoisia suunnittelujaksoja tuotekehityksessä ja pyörittävät kanban-taulua operatiiviselle ja tukityölle, jota tulee riippumatta siitä, missä sprintissä ollaan. Se on täysin järkevä hybridimalli.

Kolme kysymystä, joihin taulun pitäisi vastata kolmessakymmenessä sekunnissa

Kanban-taulu on hyödyllisimmillään, kun sitä katsomalla pystyy ilman kenenkään kanssa puhumista vastaamaan nopeasti näihin kolmeen kysymykseen: Mitä tiimi tekee juuri nyt? Missä työ jumittaa? Onko jotain, mikä pitäisi tehdä mutta mitä ei ole aloitettu?

Jos et pysty vastaamaan kaikkiin kolmeen kolmessakymmenessä sekunnissa taulua katsomalla, sitä ei todennäköisesti ylläpidetä kunnolla. Yleisin ongelma on taulu, jolle luodaan tehtäviä, mutta joita ei koskaan siirretä – siitä tulee hyvien aikomusten hautausmaa todellisen työn elävän kartan sijaan. Taulu, joka ei ole ajan tasalla, on huonompi kuin ei taulua lainkaan, koska se luo väärän näkyvyyden tunteen.

Taulun ylläpito vaatii todellista kuria. Tehtävien on liikuttava, kun työ liikkuu. Estyneet kohteet on merkittävä heti, kun ne pysähtyvät, ei kahden viikon päästä. Korteilla on oltava selkeät omistajat, ja omistajien on päivitettävä korttinsa. Mikään tästä ei vie paljon aikaa – hyvin hoidettu kanban-käytäntö voi viedä viidestä kymmeneen minuuttia henkilöä kohti päivässä – mutta se vaatii johdonmukaisuutta. Eniten kanbanista hyötyvät tiimit, jotka pitävät taulua totuuden lähteenä eikä lisäkirjanpitona.

Mitä kanban ei tee

Kanban ei ole strategiatyökalu. Se ei auta päättämään, mitä pitäisi tehdä – vain hallitsemaan sitä, minkä olet jo päättänyt tehdä. Jos organisaatiossasi on priorisoinnin ongelma, epäselvä mandaatti tai ”aloitamme liian monta projektia ennen kuin vanhat on saatu valmiiksi” -ongelma, joka juontuu johtamiskäyttäytymisestä eikä prosessista, kanban-taulu paljastaa nämä ongelmat mutta ei ratkaise niitä.

Se ei myöskään korvaa hyvää johtamista. Taulu ei korvaa kahdenkeskisiä keskusteluja, harkittua delegointia tai selkeää viestintää siitä, miksi tietty työ on tärkeää. Tiimit joskus ottavat prosessityökaluja käyttöön toivoen, että prosessi hoitaisi ihmissuhde- ja organisaatiotyön, joka on todellisuudessa esihenkilön tehtävä. Se ei hoida.

Mitä se sen sijaan tekee, on taustalla vaikuttavan epävarmuuden vähentäminen, joka hidastaa useimpia tiimejä. Kysymykset ”kuka tekee mitä”, ”onko tämä valmis” ja ”mihin tarttuisin seuraavaksi” synnyttävät valtavasti vähäarvoista viestintää organisaatioissa, joissa ei ole yhteistä, näkyvää järjestelmää. Kanban poistaa suurimman osan tuosta kohinasta. Ja tiimeille, joille kohina on vallitseva ongelma, ero on merkittävä.

Miten aloittaa – ilman kolmen päivän työpajaa

Parhaat näkemäni kanban-käyttöönotot alkoivat pienesti ja kehittyivät matkan varrella. Huonoimpiin kuului konsultti, kaksipäiväinen kehittämispäivä ja kauniisti suunniteltu taulu, jota kukaan ei käyttänyt enää kolmantena viikkona.

Aloita tiimistäsi sellaisena kuin se on ja työstä, joka teillä todella on. Luo kolme saraketta: Backlog, Työn alla, Valmis. Käytä puoli tuntia siihen, että laitatte tiimin kanssa jokaisen nykyisen työtehtävän omalle kortilleen. Sopikaa yhdestä säännöstä: kun aloitat jotain, se menee taululle. Kun se etenee, siirrät korttia. Älkää tehkö mitään muuta kahteen viikkoon.

Kahden viikon jälkeen katsokaa taulua yhdessä. Mihin asiat kasaantuivat? Mikä jäi Backlogiin, vaikka kaikki sanoivat sen olevan prioriteetti? Mikä eteni odotettua nopeammin? Mikä jäi jumiin ja miksi? Käytä havaintojasi sarakkeiden tarkentamiseen. Ehkä ”Työn alla” pitää jakaa vaiheisiin ”Työn alla” ja ”Odottaa ulkopuolista”. Ehkä tarvitset sarakkeen ”Tarkistuksessa”, koska se vaihe jää jatkuvasti huomaamatta. Anna taulun kehittyä sen mukaan, mitä todellinen työnne paljastaa, ei sen mukaan, miltä metodologiakirja sanoo sen näyttävän.

Pidemmän aikavälin peli: virtausmittarit

Kun kanban-järjestelmä on käynnissä, se tuottaa dataa, jota useimmat tiimit eivät koskaan hyödynnä. Läpimenoaika – kokonaisaika tehtävän luomisesta sen valmistumiseen – on tärkein. Jos tyypillisen tehtävän keskimääräinen läpimenoaika on kaksitoista päivää ja haluat sen olevan viisi, sinulla on nyt luku, jota kohti pyrkiä, ja taulu, joka näyttää, minne nuo ylimääräiset seitsemän päivää menevät.

Sykliaika mittaa vain aktiivista työskentelyaikaa ja jättää pois ajan, jonka tehtävä on odottanut backlogissa. Läpivirtaus mittaa, montako kohdetta tiimisi saa valmiiksi viikossa. Mikään näistä mittareista ei vaadi erityisohjelmistoa, jos kirjaat kurinalaisesti ylös, milloin kortit luodaan ja milloin ne suljetaan. Yhdessä ne antavat paljon rehellisemmän kuvan tiimisi kapasiteetista kuin mikään arvioihin perustuva suunnitteluprosessi.

Useimmat pienet ja keskisuuret tiimit eivät koskaan pääse tähän asti. Ne käyttävät kanbania näkyvyystyökaluna – mikä on arvokasta sinänsä – eivätkä mene pidemmälle. Se on ihan hyvä. Mutta jos huomaat haluavasi antaa sidosryhmille sitoumuksia siitä, milloin jokin valmistuu, tai haluavasi ymmärtää, miksi jokin työ kestää kolme kertaa odotettua pidempään, mittarit ovat valmiina, kun tarvitset niitä.