Ratkaise 7 yleisintä Kanban-virhettä, jotka haittaavat kehitystyötäsi

Tämä sopii erinomaisesti tiimille, jonka työssä nopea reagointi on tärkeää, kuten asiakastuen tai ylläpitopyyntöjen käsittelyssä.

Kanban voi tuntua Scrum-menetelmää helpommalta, koska sinun ei tarvitse noudattaa Scrum-seremonioiden tiukkaa, ohjaavaa kurinalaisuutta. Tämä vapaus tekee Kanbanin toteuttamisesta hyvin myös vaikeampaa. Jos ajattelet, että Kanban vaatii vähemmän kurinalaisuutta, olet väärässä – se vaatii enemmän kurinalaisuutta.

Jotta voit toteuttaa Kanbania oikein etkä anna vapauden johtaa tehottomuuteen, jaan nyt muutamia tärkeitä neuvoja, jotka säästävät resursseja ja mielenrauhaa.

Hyvän Kanbanin periaatteet

Kun noudatatte ensin näitä yleisiä periaatteita, ette voi juuri mennä pieleen Kanbanin kanssa.

1. Aseta ja noudata työn alla olevan työn (WIP) rajoja prosessin eri vaiheille

2. Älä siirrä työtä seuraavaan vaiheeseen, jos siellä ei ole riittävästi kapasiteettia (eli jos seuraavien prosessivaiheiden WIP-rajat ovat täynnä)

3. Määritä, mitä vaaditaan työn siirtämiseksi prosessisarakkeesta seuraavaan

4. Muista sisällyttää toimintatapoihinne myös refinement, korkean tason suunnittelu ja oppiminen

Yleisimmät ongelmat ja niiden välttäminen

Olemme kollegoideni kanssa neuvoneet yrityksiä Agile-työskentelyssä jo vuosien ajan, ja olemme nähneet kaikenlaista. Haluamme jakaa kanssasi seitsemän yleisintä Kanban-ongelmaa ja keinot niiden ratkaisemiseen. Lue eteenpäin ja vältä sudenkuopat.

1. Hamstraat tikettejä

Kanban on työnkulun visualisointiin tarkoitettu menetelmä. Se toimii rajoittamalla työn alla olevan työn määrää. Kanban juontaa juurensa Toyota Production Systemistä ja autotehtaista. Autotehtaassa et voi ottaa autoja pois tuotantolinjalta ja varastoida niitä työpisteesi viereen. Et saisi mitään aikaan, jos työpisteesi näyttäisi supermarketin parkkipaikalta.

Miksi ohjelmistotiimit sitten ajattelevat voivansa toimia toisin? Miksi on niin yleistä nähdä Kanban-taulu täynnä tikettejä?

Prosessin WIP-raja onkin yksi useimmin rikotuista Kanban-säännöistä. Useimmilla Kanban-tiimeillä ei ole lainkaan WIP-rajaa, ja ne, joilla sellainen on, noudattavat sitä harvoin tarkasti.

Toimi näin sen sijaan

• Tiukan WIP-rajan noudattaminen on vaikeaa. Vaikka tuntuisikin, ettet pysty noudattamaan rajaa, tiimin tulisi vähintään tunnistaa, että vähemmän työn alla olevaa työtä on parempi.

• Varmista, että tiimin jäsenet työskentelevät yhden asian parissa kerrallaan, ja tarkista ennen uuden työn aloittamista, miltä seuraavat prosessivaiheet näyttävät. Onko siellä ruuhkaa? Sen sijaan, että lisäät ruuhkaa, selvitä, miten voit auttaa.

Tiukan WIP-rajan noudattaminen on vaikeaa. Vaikka tuntuisikin, ettet pysty noudattamaan rajaa, tiimin tulisi vähintään tunnistaa, että vähemmän työn alla olevaa työtä on parempi.

Varmista, että tiimin jäsenet työskentelevät yhden asian parissa kerrallaan, ja tarkista ennen uuden työn aloittamista, miltä seuraavat prosessivaiheet näyttävät. Onko siellä ruuhkaa? Sen sijaan, että lisäät ruuhkaa, selvitä, miten voit auttaa.

2. Refinement puuttuu

Scrum-tiimissä säännölliset seremoniat ovat perusasia. Säännölliset, viikoittaiset refinement-sessiot eivät ole poikkeus. Kanbanissa seremonioita ei enää määritellä valmiiksi. Rutiini katoaa.

Koska Kanban perustuu tikettien virtaukseen, on liian helppoa aloittaa työskentely tiketin parissa, jota ei ole refineattu.

Tästä seuraa:

• Työn aloittaminen liian suurilla tiketeillä

• Hukka – työ siirretään ”käynnissä”-sarakkeeseen, ja tiimi luottaa siihen, että yksi kehittäjä tarkentaa tikettiä samalla, kun hän alkaa toteuttaa sitä.

Liian suurten tikettien toteuttamisen aloittaminen

Hukka – työ siirretään ”käynnissä”-sarakkeeseen, ja tiimi luottaa siihen, että yksi kehittäjä tarkentaa tikettiä samalla, kun hän alkaa toteuttaa sitä.

Toimi näin sen sijaan

• Järjestä säännöllisiä backlogin tarkennussessioita myös Kanban-tiimeille

• Varmista, että ”Definition of Ready” -käytäntöä noudatetaan johdonmukaisesti

• Käytä tarkennukseen omaa Kanban-taulua tai lisää työtauluun tarkennussarake, jotta näet, milloin tikettejä tarkennetaan

• Edellytä kokoluokan arviointia ja aseta kokorajat uusien tikettien aloittamiselle

Järjestä säännöllisiä backlogin tarkennussessioita myös Kanban-tiimeille

Varmista, että ”Definition of Ready” -käytäntöä noudatetaan johdonmukaisesti

Käytä tarkennukseen omaa Kanban-taulua tai lisää työtauluun tarkennussarake, jotta näet, milloin tikettejä tarkennetaan

Edellytä kokoluokan arviointia ja aseta kokorajat uusien tikettien aloittamiselle

3. Keskityt liikaa kehitystyöhön

Kanban-tiimit keskittyvät tyypillisesti liikaa kehitys- ja testausvaiheisiin. Ne unohtavat usein järjestää demoja tai pyytää palautetta käyttäjiltä ja muilta sidosryhmiltä.

Scrumissa sprint review pakottaa tiimin tarkastelemaan tuloksia ja sitä, miten työn valmistuminen vaikuttaa backlogiin ja tuleviin suunnitelmiin. Katselmuksen demo-osuus myös kannustaa aktiivisesti palautteen antamiseen. Tämä käytäntö puuttuu Kanbanista, joten se on tuotava takaisin tiimin kalenteriin.

Toimi näin sen sijaan

• Järjestä säännöllisiä demosessioita myös Kanban-tiimeille

• Harkitse ”palaute tarvitaan” -sarakkeen lisäämistä Kanban-tauluusi

• Huomaa, jos tiimi alkaa keskittyä liikaa toteutukseen ja liian vähän palautteeseen

Järjestä säännöllisiä demosessioita myös Kanban-tiimeille

Harkitse ”palaute tarvitaan” -sarakkeen lisäämistä Kanban-tauluusi

Huomaa, jos tiimi alkaa keskittyä liikaa toteutukseen ja liian vähän palautteeseen

4. Käytät Jiran oletustyönkulkua

Jiran oletustyönkulku ”To do” - ”In progress” - ”Done” pitäisi kieltää. Siinä on useita vakavia ongelmia, kuten:

• Et näe, mitkä tiketistä ovat uusia ja mitkä Product Owner on hyväksynyt backlogiin. Product Ownerilla on oltava hallinta backlogin hyväksynnästä. Hänen on tehtävä kyllä/ei-päätös ja asetettava kohteet oikeaan prioriteettijärjestykseen.

• Et voi merkitä, tarvitseeko työ refinementia vai onko se jo refined ja valmis toteutettavaksi (eli läpäissyt Definition of Ready -kriteerit). Kun koko backlogissa käytetään vain Todo-tilaa, refinementia ei voi hallita. Siksi työt aloitetaan usein ilman riittävää refinementia.

• Jos työ siirretään Done-tilaan, sen oletetaan olevan valmis. Et kuitenkaan näe, onko työ demonstroitu, odotetaanko asiakkaan palautetta tai mitkä työt on julkaistu tai odottavat julkaisua. Entä code review't ja design review't?

Et näe, mitkä työt ovat uusia ja mitkä Product Owner on hyväksynyt backlogiin. Product Ownerilla on oltava hallinta backlogiin hyväksymisestä. Hänen on tehtävä kyllä/ei-päätös ja asetettava työt oikeaan prioriteettijärjestykseen. 

Et voi merkitä, tarvitseeko työ refinementia vai onko se jo refined ja valmis toteutettavaksi (eli läpäissyt Definition of Ready -kriteerit). Kun koko backlogissa käytetään vain Todo-tilaa, refinementia ei voi hallita. Siksi työt aloitetaan usein ilman riittävää refinementia.

Jos työ siirretään Done-tilaan, sen oletetaan olevan valmis. Et kuitenkaan näe, onko työ demonstroitu, odotetaanko asiakkaan palautetta tai mitkä työt on julkaistu tai odottavat julkaisua. Entä code review't ja design review't?

Tee näin sen sijaan

• Käytä Kanban-taulun sarakkeina esimerkiksi seuraavia prosessivaiheita: Uusi, Tarvitsee refinementia, Valmis toteutettavaksi, Tarkistus, Tarvitaan palautetta, Odottaa demoa.

• Varmista, että Kanban-taulusi vastaa todellista prosessiasi – siinä Kanbanin ydin on!

Käytä Kanban-taulun sarakkeina esimerkiksi seuraavia prosessivaiheita: Uusi, Tarvitsee refinementia, Valmis toteutettavaksi, Tarkistus, Tarvitaan palautetta, Odottaa demoa.

Varmista, että Kanban-taulusi vastaa todellista prosessiasi – siinä Kanbanin ydin on!

5. Sinulla ei ole sääntöjä töiden siirtämiseen prosessin seuraavaan vaiheeseen

Hyvillä Agile-tiimeillä on kaksi laatukriteeriä: työn aloittamiseen Definition of Ready (DoR) ja työn valmistumiseen Definition of Done (DoD). Lisäksi kehittyneemmät Kanban-tiimit keskustelevat ja sopivat säännöt töiden siirtämiselle Kanban-taulun sarakkeesta seuraavaan. 

Huomioi mini-DoD

Esimerkiksi viimeisimmässä Kanbania käyttäneessä tiimissäni kehittäjä varmisti seuraavat asiat siirtäessään työn Development-sarakkeesta Testing-sarakkeeseen:

• Toiminnallisuus toimii halutulla tavalla ja vastaa hyväksymiskriteerejä

• Kehittäjän omat testit menevät läpi, eikä tunnettuja bugeja ole

• Koodi kääntyy ilman varoituksia

• Yksikkötestit on tehty, ja ne menevät läpi

• Suunnitteludokumentaatio on päivitetty Confluenceen

• Testaajalle on toimitettu testausohjeet

• Kehittäjä ja testaaja käyvät luovutuskeskustelun

Toiminnallisuus toimii halutulla tavalla ja vastaa hyväksymiskriteerejä

Kehittäjän omat testit menevät läpi, eikä tunnettuja bugeja ole

Koodi kääntyy ilman varoituksia

Yksikkötestit on tehty, ja ne menevät läpi

Suunnitteludokumentaatio päivitetään Confluenceen

Testausohjeet toimitetaan testausinsinöörille

Kehittäjä ja testaaja käyvät luovutuskeskustelun

Tämän sopimuksen (mini-DoD) avulla vähensimme testaajan ja kehittäjän välistä edestakaista viestintää ja sujuvoitimme työnkulkua tiimin prosessissa.

Ajattele jälleen autotehdasta. Jokaisen seuraavan työpisteen on voitava luottaa siihen, että edellisillä työpisteillä työ tehdään aina samalla tavalla.

Toimi sen sijaan näin

• Määritä mini-DoD:t jokaiselle Kanban-sarakkeiden väliselle siirrolle

6. Kärsit tikettisokeudesta

Kanbanissa on helppo keskittyä liikaa yksittäisiin tiketteihin ja kadottaa kokonaiskuva. Esimerkiksi tiimin dailyissa jäsenet kertovat toisilleen, mitä tekevät. Myöhemmin, kun tulee tilanne, jossa tiimin jäsenten pitäisi ymmärtää, mitä muut työstävät, käy ilmi, etteivät he kuunnelleet.

Tikettisokeus saa jokaisen tiimin jäsenen keskittymään vain omiin tehtäviinsä.

Ongelman ratkaiseminen yhdessä on tehokas tapa selvittää vaikeita haasteita. Kun ihmiset keskittyvät liikaa omiin tiketteihinsä, he voivat toisinaan jättää huomaamatta tilanteet, joissa ongelman ratkaiseminen yhdessä olisi tarpeen.

Tikettisokeus on erityisen vaarallista, kun tiimi työskentelee pääosin etänä.

Kanban voi luoda yhden henkilön siiloja

Scrumissa tiimin on ajateltava sprinttiä ja sitä, mitä koko tiimi voi sprintin aikana saavuttaa. Siksi sokeus muiden työlle on pienempi riski. Sprinttitavoitteet myös ohjaavat tiimiä työskentelemään yhdessä.

Toimi sen sijaan näin

• Tunnista ongelmat, joiden ratkaiseminen vaatii yhteistä työskentelyä

• Varmista, että Product Owner auttaa tiimiä ymmärtämään kokonaiskuvan ja tulevan työn (backlogin jalostaminen sekä ”scan and plan” -menetelmät auttavat tässä)

• Järjestä Kanban-tiimin kanssa säännöllisiä suunnittelutapaamisia, jotta kaikki pysyvät linjassa suuremman tavoitteen kanssa

• Varmista, että ihmiset kuuntelevat dailyissa eivätkä haaveile omiaan

• Harkitse kuukausitavoitteiden tai muiden välitavoitteiden asettamista, jotta tiimi löytää suuntansa

• Ole erityisen valppaana välttääksesi yhden henkilön siiloja täysin etätyöskentelevissä tiimeissä

Tunnista ongelmat, joiden ratkaiseminen vaatii yhteistä työskentelyä

Varmista, että Product Owner auttaa tiimiä ymmärtämään kokonaiskuvan ja tulevan työn (backlogin jalostaminen sekä ”scan and plan” -menetelmät auttavat tässä)

Järjestä Kanban-tiimin kanssa säännöllisiä suunnittelutapaamisia, jotta kaikki pysyvät linjassa suuremman tavoitteen kanssa

Varmista, että ihmiset kuuntelevat dailyissa eivätkä haaveile omiaan

Harkitse kuukausitavoitteiden tai muiden välitavoitteiden asettamista, jotta tiimi pysyy oikeassa suunnassa

Ole erityisen tarkkana, ettei täysin etätyötä tekeviin tiimeihin synny yhden henkilön varaan rakentuvia siiloja

7. Et pidä retrospektiivejä – et siis opi

Scrumissa retrospektiiveillä on yleensä tietty rytmi. Virallisessa Scrum-oppaassa retrospektiivi pidetään sprintin viimeisessä tapaamisessa – mutta mikään ei estä järjestämästä ylimääräisiä retrospektiivejä muulloinkin. Kokeile siis ja selvitä, mikä toimii tiimillesi.

Ilman tätä rytmiä Kanban-tiimit voivat helposti unohtaa pitää retrospektiivejä.

Tee sen sijaan näin

• Varaa säännölliset retrospektiivit kuusi kuukautta etukäteen

• Pidä niitä vähintään kerran kuukaudessa, mielellään useamminkin

• Arvosta retrospektiivejä ja pidä niistä kiinni – älä jätä niitä väliin

Varaa säännölliset retrospektiivit kuusi kuukautta etukäteen

Pidä niitä vähintään kerran kuukaudessa, mielellään useamminkin

Arvosta retrospektiivejä ja pidä niistä kiinni – älä jätä niitä väliin

Kanban, joka toimii käytännössä

Kanban voi olla hauskempi ja motivoivampi tapa työskennellä tiimille, joka toimii hyvin dynaamisessa ympäristössä. Vaikka Kanban voi vaikuttaa helpolta, älä pidä sitä itsestäänselvyytenä. Hyvä Kanban vaatii enemmän kurinalaisuutta kuin Scrum. Hyvä Scrum Master auttaa Kanban-tiimiä kehittymään jatkuvasti.

Toivomme, että tämä seitsemän vältettävän asian lista auttaa Kanban-tiimiäsi kehittymään.