Miksi Kanban toimii — ja kuinka tietää, ovatko tiimisi valmiita siihen

Useimmat tiimit ottavat Kanbanin käyttöön, koska joku luki blogikirjoituksen. Älykkäämpi kysymys on, ovatko ongelmat, joita Kanban ratkaisee, todella tiimisi ongelmat.

On hetkellä, jonka useimmat tiimit tunnistavat, yleensä siihen mennessä, kun heillä on enemmän kuin kahdeksan tai yhdeksän henkilöä. Työtä tehdään — sähköpostit lähetetään, ominaisuudet julkaistaan, asiakkaita hallinnoidaan — mutta kenelläkään ei ole selkeää käsitystä siitä, mitä kaikki muut tekevät. Projektit kasautuvat. Asioita luvataan ja sitten hiljaa unohdetaan. Viidät kaksikymmentä minuuttia ennen jokaista kokousta yrittämällä selvittää, missä työn kappale oikeasti on. Vastaus on yleensä "jostakin".

Tämä on ongelma, jonka Kanban suunniteltiin ratkaisemaan. Ei strategian asettamisen ongelma, tai oikeiden ihmisten palkitseminen, tai kulttuurin rakentaminen — vaan erityinen, rasittava, operatiivinen ongelma tietää, mitä tiimisi tekee ja mikä sen estää.

Se on yllättävän vaatimaton työkalu jollekin, joka on houkutellut niin paljon huomiota. Kanban ei väitä korjaavansa organisaatiotasi. Se vain tekee työn näkyväksi. Ja käy ilmi, että näkyvyys, jota sovelletaan johdonmukaisesti, muuttaa huomattavan määrän asioita.

Mistä Kanban todella tuli

Sana on japanilainen — se tarkoittaa "kyltti" tai "mainos" — ja järjestelmä kehitettiin Toyotan toimesta 1940-luvun lopulla tapaksi hallita varastoa tehtaissaan. Idea oli yksinkertainen: sen sijaan, että tuottaisivat osia kiinteässä aikataulussa, tehdas tuottaisi ne vain, kun alavirtaasema ilmoitti tarvitsevansa niitä. Fyysinen kortti — kanban — kulkisi takaisin linjan yli pyyntönä. Mitään ei tuotettu spekulatiivisesti. Mitään ei kertynyt tarpeettomasti.

Oivallus, jonka Toyota sai ja jota myöhemmin ohjelmistotyöntekijät lainasivat, on että suurin osa järjestelmän tehottomuudesta johtuu ei siitä, että ihmiset työskentelevät liian hitaasti, vaan väärästä työstä väärällä hetkellä. Liian monet asiat alkavat samanaikaisesti. Pullonkaulat, joita kukaan ei huomaa ennen kuin on liian myöhäistä. Työ, joka valmistuu yhdessä paikassa, kun seuraava vaihe on ylikuormitettu muualla.

Ohjelmistokehittäjät, erityisesti Microsoftin kaltaisissa yrityksissä 2000-luvun alussa, alkoivat soveltaa näitä ideoita tietämystyöhön. Kortit tulivat tehtäviksi. Tehtaan asemat tulivat työnkulun vaiheiksi. Ja ilmoitustaulu tuli levyksi — aluksi fyysiseksi, sitten digitaaliseksi — missä kuka tahansa tiimissä voisi nähdä yhdellä silmäyksellä, mikä oli käynnissä, mikä odotti ja mikä oli valmis.

Mitä Kanban-taulu todella näyttää

Perus-Kanban-taululla on kolme saraketta: Tehtävät, Käynnissä, ja Valmis. Tämä riittää monille pienille tiimeille ja hyvä paikka aloittaa. Mutta todellinen arvo ilmenee, kun alat räätälöidä näitä vaiheita vastaamaan sitä, kuinka työsi todella virtaa — ei kuinka haluaisit sen virtaavan.

Sisältötiimi voisi käyttää: Idea, Yhteenveto, Luonnoksessa, Tarkistettavana, Ajoitettu, Julkaistu. Ohjelmistotiimi voisi jakaa "Käynnissä" erillisiksi sarakkeiksi kehitykselle, koodin tarkastelulle ja laadunvarmistukselle. Konsulttitiimi voisi seurata Discovery, Ehdotusta, Aktiivinen, Odottaa asiakasta, ja Suljettu. Vaiheiden tulisi heijastella todellisia siirtoja ja todellisia odotusaikoja — paikkoja, joissa työ vaihtaa käsiä tai joissa se istuu, kunnes jotain muuta tapahtuu.

Huomaa kortti keskisarakkeessa — varaston tarkastusraportti, kahdeksan päivää, merkitty estetyksi. Järjestelmässä ilman taulua tuo tehtävä saattaisi istua vielä kaksi viikkoa, ennen kuin kukaan huomaa, että se ei liiku. Joku odottaa kolmatta osapuolta. Tai päätös tarvitaan johtajalta, joka ei tiedä olevansa esto. Taulu tekee esteen näkyväksi. Se on suurin osa työstä.

Sääntö, joka tekee siitä toimivan: WIP-rajat

Jos on yksi käsite, joka erottaa tiimit, jotka käyttävät Kanbania oikein, tiimeistä, joilla on vain kauniimpi tehtävälista, se on työn kesken olevat rajat — WIP-rajat lyhyesti. Idea on, että jokaisella sarakkeella on enimmäismäärä kohteita, joiden sallitaan olla siellä samanaikaisesti. Kun sarake on täynnä, et voi lisätä enempää työtä, kunnes jotain siirtyy ulos.

Tämä tuntuu vastaintuitiiviselta. Varmasti kyky laittaa enemmän tehtäviä käynnissä tarkoittaa, että enemmän tehdään? Se ei. Mitä todella tapahtuu, kun ihmiset työskentelevät liian monilla asioilla samanaikaisesti, on se, että kaikki kestää pidempään. Kontekstinvaihto on kallista. Puoliksi valmis työ luo koordinaatiokuluja. Ja kun kymmenen asiaa on "käynnissä", on hyvin vaikeaa kertoa, mitkä todella liikkuvat ja mitkä ovat vain juuttuneet, mutta merkitsemättä.

WIP-raja kolme Käynnissä-sarakkeessasi tarkoittaa, että kun neljäs asia saapuu jonkun pöydälle, joku tiimissäsi joutuu tekemään päätöksen: mikä olemassa oleva tehtävä valmistuu ensimmäisenä? Se pakottaa priorisoinnin. Se pakottaa keskustelun. Ja se tulee tuottamaan nopeampaa yksittäisten kohteiden valmistumista, vaikka uusien kohteiden aloitusvauhti hidastuisi.

Kanban vs. Scrum: kysymys, jonka tiimit aina kysyvät

Jos olet viettänyt aikaa ohjelmistotiimien tai nykyaikaisen toiminnan ajattelun parissa, olet todennäköisesti kohdannut Scrumin — kehyksen, joka järjestää työtä kiinteiksi kahdeksi viikoksi kestäviksi sprinteiksi suunnitteluistuntojen, retrospektiivien ja määriteltyjen roolien, kuten Scrum Master ja Product Owner kanssa. Monet tiimit käsittelevät Scrumia ja Kanbania kilpailevina menetelmäolina ja tuntevat, että heidän on valittava. Ero on itse asiassa yksinkertaisempi kuin se.

Monet tiimit — erityisesti ne, jotka eivät ole puhdasta ohjelmiston insinöörityötiimit — löytävät Scrumin seremoniapainotteiseksi ja sen kiinteän sprintin rakenteen hankalaksi soveltaa jatkuvaa operatiivista työtä varten. Markkinointi-, asiakasonnistumis-, toiminta- ja kaiken hallinnasta vastaavat perustajat ovat harvoin työtä, joka sopii siististi kahden viikon sykleihin. Kanbanin jatkuvan virtausmallin mukaan ne sopivat heille paremmin.

Silti monet tiimit yhdistävät molemmat. He käyttävät sprint-tyylistä suunnittelua tuotekehitykseen samalla kun käyttävät Kanban-taulua operatiiviselle ja tukityölle, joka virtaa riippumatta siitä, millä sprintillä olet. Se on täysin järkevä hybridi.

Kolme kysymystä, joihin taulusi pitäisi vastata kolmekymmentä sekuntia

Kanban-taulu on hyödyllisin, kun voit katsoa sitä ja ilman puhumista kenellekään vastata näihin kolmeen kysymykseen nopeasti: Mitä tiimisi tekee juuri nyt? Missä työ juuttuu? Onko jotain, mitä pitäisi tehdä mutta ei ole aloitettu?

Jos et voi vastata kaikkiin kolmeen kolmekymmentä sekuntia taulun katsomisesta, sitä ei todennäköisesti ylläpidetä oikein. Yleisin vikaantumistilanne on taulu, jossa tehtävät luodaan mutta ei koskaan siirretä — se tulee hyveistä aikeista taulu eikä elävä kartta varsinaisesta työstä. Taulu, jota ei pidetä ajantasaisena, on huonompi kuin ei lainkaan, koska se luo väärän näkyvyyden tunteen.

Taulun ylläpitämiseen vaadittu kuri on todellista. Tehtävien tulee liikkua, kun työ liikkuu. Estetyt kohteet on merkittävä sillä hetkellä, kun ne pysähtyvät, ei kahta viikkoa myöhemmin. Korteilla pitää olla selkeät omistajat, ja omistajien on päivitettävä korttejaan. Mikään tästä ei vaadi paljon aikaa — hyvin hoidettu Kanban-käytäntö saattaa ottaa viisi kymmeneen minuuttia per henkilö päivässä — mutta se vaatii johdonmukaisuutta. Tiimit, jotka hyötyvät eniten Kanbanista, ovat ne, jotka pitävät taulua totuuden lähteenä, ei sivutoimisena kirjaamisena.

Mitä Kanban ei tee

Kanban ei ole strategiatyökalu. Se ei auta sinua selvittämään, mitä pitäisi tehdä — se vain auttaa hallitsemaan sitä, mitä olet jo päättänyt tehdä. Jos organisaatiollasi on priorisoinnin ongelma, tai epäselvä mandaatti, tai "aloitamme liian monta projektia ennen kuin viimeistellään vanhat" -ongelma, joka juontuu johtajien käyttäytymisestä ennemmin kuin prosessista, Kanban-taulu paljastaa nämä ongelmat mutta ei ratkaise niitä.

Se ei myöskään ole korvike hyvän johtamisen vuoksi. Taulu ei korvaa yksiköitä, harkittua delegointia tai selkeää viestintää siitä, miksi tietty työ on tärkeää. Tiimit adoptoivat joskus prosessivälineitä toivoen prosessin tekevän suhteellisen ja organisatorisen työn, joka on itse asiassa johtajan työ. Se ei tule.

Se tekee alentaa ympäristön epävarmuuden, joka hidastaa useimpia tiimejä. Kysymykset "kuka tekee mitä", "onko tämä valmis" ja "mitä minun pitäisi poimia seuraavaksi" tuottavat valtavia määriä matalan arvon viestintää organisaatioissa, joilla ei ole jaettua näkyvää järjestelmää. Kanban eliminoi suurimman osan tästä melusta. Ja tiimeille, joissa tämä melu on hallitseva ongelma, ero on merkittävä.

Kuinka aloittaa — ilman kolmen päivän työpajaa

Parhaat Kanban-toteutukset, joita olen nähnyt, aloitettiin pienellä ja kehittyivät. Pahimmat edellyttivät konsultin, kahden päivän poissaoloa ja kauniisti suunniteltua taulua, jota kukaan ei käyttänyt kolmannella viikolla.

Aloita tiimillä sellaisena kuin se todella on, työn kanssa, joka sinulla todella on. Luo kolme saraketta: Taaksepäin, Käynnissä, Valmis. Viete kolmekymmentä minuuttia tiimisi kanssa laittamalla jokaisen nykyisen työn kohteen kortille. Sopilaa yhdestä säännöstä: kun aloitat jotain, se menee tauluun. Kun se siirtyy, siirrät kortin. Älä tee mitään muuta kahteen viikkoon.

Kahden viikon jälkeen katso taulua yhdessä. Missä asiat kasautuivat? Mikä jäi Taaksepäin-kohtaan, jonka kaikki sanoivat olevan prioriteetti? Mikä siirtyi odotettua nopeammin? Mikä juuttui ja miksi? Käytä mitä huomaat tarkentaaksesi sarakkeita ja lisätaksesi spesifisyyttä. Ehkä "Käynnissä" on jaettava erillisiksi "Käynnissä" ja "Odottaa ulkoisesti". Ehkä tarvitset sarakkeen nimeltä "Tarkistuksessa", koska se vaihe menetetään jatkuvasti. Anna taulun kehittyä siinä valossa, mitä todellinen työsi paljastaa, ei siinä valossa, mitä metodologiakirja sanoo sen pitävän näyttää.

Pidemmän pelin: virtausmittaukset

Kun Kanban-järjestelmä on käynnissä, se tuottaa tietoja, joita useimmat tiimit eivät koskaan käytä. Johtamisaika — kokonaisaika siitä, kun tehtävä luodaan, kunnes se valmistuu — on tärkein. Jos keskimääräinen johtamisaikasi tyypilliselle tehtävälle on kaksitoista päivää ja haluat sen olevan viisi, sinulla on nyt numero, jonka kanssa työskennellä, ja taulu, joka näyttää sinulle, missä nuo ylimääräiset seitsemän päivää menevät.

Sykliaika mittaa vain aktiivista työjakson, lukuun ottamatta aikaa, jonka tehtävä istuu taaksepäin. Läpi mittaa, kuinka monta kohtetta tiimisi suorittaa viikossa. Mikään näistä mittauksista ei vaadi erityistä ohjelmistoa, jos olet kuri merkitsemään, milloin kortit luodaan ja kun ne suljetaan. Ja yhdessä ne antavat sinulle paljon rehellisemmän kuvan tiimisi kapasiteetista kuin mikään estimaattipohjainen suunnitteluprosessi voi.

Useimmat pienet ja keskisuuret tiimit eivät koskaan saavuta tänne. He käyttävät Kanbania näkyvyystyökaluna — mikä on arvokasta sinänsä — eivätkä mene pidemmälle. Se on hyväksyttävää. Mutta jos huomaat tekevän sitoumuksia sidosryhmille siitä, milloin jokin valmistuu, tai haluat ymmärtää, miksi jokin työ kestää kolme kertaa niin kauan kuin odotit, mittaukset ovat siellä, kun tarvitset niitä.