Näin vältät Kanban-taulusi tukkeutumisen liian suuresta keskeneräisten töiden määrästä

Kanbanissa tätä kutsutaan keskeneräisen työn (Work In Progress, WIP) rajoiksi, ja ne ovat todella olennaisia toimivan Kanbanin kannalta.

Tiimillä voi esimerkiksi olla samanaikaisesti vain 5 tehtävää kehityksessä tai 3 tehtävää testauksessa. Jos WIP-raja saavutetaan, tiimi ei saa siirtää työtä seuraavaan vaiheeseen, ennen kuin työn kulkua rajoittava vaihe on saatu purettua.

Kaaos ilman WIP-rajoja

Ilman WIP-rajoja tiimillenne voi helposti kertyä liikaa keskeneräistä työtä. Kun taululla on liikaa työtä:

• Työn kulkua on vaikea ennakoida tai hallita

• Tehtävästä toiseen vaihtaminen lisääntyy, samoin stressi.

• Tiimi joutuu kehittämään keinoja kiireellisten töiden viemiseksi muuten tukkeutuneen prosessin läpi. Tämä voi johtaa ”äänekkäin voittaa” -priorisointiin, eikä muun organisaation haluta oppivan toimimaan näin.

Useimmat Kanban-tiimit eivät kuitenkaan aseta tiukkoja WIP-rajoja. Ja ne tiimit, jotka asettavat niitä, päätyvät usein olemaan noudattamatta niitä.

Kuvittele ohjelmistokehitysprosessin sijaan tehdas

Kuvittele toisenlainen, perinteisempi työympäristö. Tarkastellaan pientä tehdaspajaa, jossa valmistetaan fyysisiä tuotteita. Tuotteet valmistuisivat useilla työpisteillä. Vaiheita voisivat olla:

• Koneistus

• Maalaus

• Kokoonpano

• Lopullinen laaduntarkastus

Kuvittele tilanne, jossa ongelma ilmenee loppukokoonpanovaiheessa. Tuotantolinja on jostain syystä pysäytettävä. Syynä voivat olla aiemmista vaiheista tulevissa komponenteissa havaitut viat tai tuotantolinjan työkalujen rikkoutuminen. Mitä tehdashallissa tapahtuisi?

Olen melko varma, että jos ongelma jatkuisi muutamaa minuuttia pidempään, maalaus- ja koneistustyöpisteiden työntekijät saisivat siitä tiedon. Jatkaisivatko he työskentelyä työpisteillään normaalisti ja täyttäisivät tehdashallin puolivalmiilla komponenteilla?

Se olisi täysin järjetöntä. Edellisten vaiheiden työn jatkamisesta tulisi täysin typerää, kun työ ei etene seuraavissa vaiheissa. Se kävisi lopulta myös fyysisesti mahdottomaksi: tehdashallissa ei olisi tilaa keskeneräisten komponenttien varastoimiseen.

Jos mahdollista, työntekijät yrittäisivät varmasti selvittää vian ja korjata tuotantolinjan mahdollisimman pian.

Miksi sama maalaisjärki ei toimi ohjelmistokehityksen Kanbanissa?

Ohjelmistokehityksessä työtehtävät eivät ole fyysisiä. Jos työn myöhemmissä vaiheissa ilmenee ongelma, toimistotila ei vähene. Kehittäjät voivat silti siirtää työtä seuraavaan vaiheeseen.

Juuri siksi Kanbanissa on WIP-rajoja. Ne ovat virtuaalisia rajoitteita, joiden tarkoitus on tuoda esiin prosessin pullonkaulat. Jos jätät ne täysin huomiotta – tai WIP-rajoja ei ole lainkaan – toimit kuin tiedostamattomat tehdastyöntekijät, jotka jatkavat sokeasti tehdashallin täyttämistä keskeneräisellä työllä.

Miksi WIP-rajojen sivuuttaminen on IT-työssä helpompaa? Syitä voivat olla esimerkiksi:

• Työtehtävät ovat abstraktimpia kuin fyysiset esineet

• Emme aidosti ymmärrä tai arvosta seuraavien vaiheiden työtä

• Emme työskentele tiiminä, vaan keskitymme vain omaan prosessivaiheeseemme

• Emme mittaa työnkulkua DevOps-mittareilla, kuten läpimenoajalla

• Haluamme vaistonvaraisesti olla ”tehokkaita” ja näyttää kiireisiltä töissä

Vastusta tarvetta näyttää ”tehokkaalta”

Tehokkuus on mittari tilanteisiin, joissa työskentelet silmät sidottuina. Kun et tiedä, miten työ etenee tiimin prosessin läpi, keskityt luonnollisesti tekemään oman tehtäväsi mahdollisimman nopeasti ja tehokkaasti.

Ehkä sinullakin on vaisto olla ”tehokas ja kiireinen”. Mitä teet, kun esihenkilö on paikalla? Kaikki näyttävät kiireisiltä! Johtuuko tällainen käytös siitä, että haluamme vaikuttaa tiimin arvokkailta jäseniltä?

Mitä voit tehdä tilanteen korjaamiseksi

Miten voimme auttaa tiimiä ymmärtämään työn virtauksen ja keskeneräisen työn rajoittamisen arvon? Mielestäni meidän pitäisi

• Mittaa työn virtausta ”Valmis”-tilaan asti ja kokeilla tiukkoja WIP-rajoja

• Tee toimia rajoitteiden ja pullonkaulojen vaikutusten vähentämiseksi

• Tutustu paremmin työn muihin vaiheisiin – vaihda rooleja

• Tiimin rakentaminen – tutustukaa toisiinne, niin autatte herkemmin muita tiimin jäseniä silloin, kun he tarvitsevat apua

Mittaa työn virtausta Valmis-tilaan asti

Scrum Master voisi mitata tiimin viikoittaisen nopeuden. Hän voisi esimerkiksi laskea joka perjantai, kuinka monta tikettiä päätyi kyseisellä viikolla Valmis-sarakkeeseen. Sen jälkeen hän voisi sopia tiimin kanssa kokeilusta: seuraavalla viikolla tiimi sitoutuu noudattamaan tarkasti sovittuja WIP-rajoja. Sitten perjantaina mitataan jälleen valmistuneen työn määrä.

Tiimin tulisi sitten keskustella siitä, miten WIP-rajoja muutetaan seuraavaa viikkoa varten. Takaan, että tämä nopeuttaa asioita. Se on väistämätöntä. Kun tämä yhdistetään työn pilkkomiseen pienempiin osiin, lähestymistavan pitäisi löytyä jokaisesta ”Kanban-mestarin” keittokirjasta.

Tunnista rajoitteet

Tiimillä on pullonkaula. Sellainen on jokaisessa maailman prosessissa, ja niin on tiimilläkin. Mikä se on? Testaus? Automaattinen testaus? Asiakkaan hyväksyntä? Tiimin Scrum Masterin on kysyttävä tätä, ja tiimin on tiedostettava pullonkaula.

Seuraava kysymys on, miten pullonkaulan läpi kulkevan työn määrää voidaan kasvattaa. Esimerkiksi:

• jos pullonkaula on automaattinen testaus, miten testien luomista ja suorittamista voidaan nopeuttaa?

• Jos pullonkaula on koodikatselmoinnit, millaisia sääntöjä tiimi voi ottaa käyttöön kokeillakseen muiden kehittäjien pull requestien katselmoinnin nopeuttamista?

Ymmärrä koko prosessi paremmin

Jos liian suuren WIPin ongelma johtuu siitä, ettei tiimi tunne tai kunnioita prosessin muita vaiheita, voi olla aika vaihtaa rooleja. Antakaa kehittäjien tehdä testauksia jonkin aikaa ja testaajien pariohjelmoida kehittäjän kanssa.

Uskon myös vahvasti, että perinteinen ”tiimin rakentaminen”, jossa tiimin jäsenet tutustuvat toisiinsa paremmin, auttaa kunnioittamaan muita. Oletteko ryhmä vai tiimi? Puhukaa muistakin asioista kuin työstä ja tutustukaa roolin takana olevaan ihmiseen.

Toivottavasti tämä blogi herätti sinut pohtimaan WIP-rajojen käyttöönottoa tiimissäsi. Onnea keskeneräisen työn rajoittamiseen!