Ketterät tiimit valitsevat usein toiminnanohjausmetodikseen joko Scrumin tai Kanbanin. Näistä Scrum on yleisempi, etenkin puhuttaessa tuotekehitystiimeistä. Jos tiimi tekee tukitoimintoja tai se ei ole varsinainen tuotekehitystiimi, on myös Kanbanin käyttö yleistä.

Sprintit on pilalla, ihan paskaa tilalla 

Tiimeille, joissa tekeminen ei ole kovin ennustettavaa, Kanban sopii todella hyvin.

Monet tiimit törmäävät Scrumia kokeiltuaan ongelmiin: sprinttien suunnittelu tuntuu tyhmältä, kun tekemiseen vaikuttaa niin paljon muista tiimeistä tulevat pyynnöt, tukipyynnöt, asiakasbugit ynnä muut ei-ennustettavat mutta kiireelliset asiat. Kun sprintit tuntuvat tyhmiltä eikä niihin valittuja asioita saada tehtyä, tulee helposti mieleen, että ehkä tiimi voisikin siirtyä Scrumista Kanbaniin. Juuri tällaisille tiimeille, joissa tekeminen ei ole kovin ennustettavaa, Kanban sopiikin todella hyvin.

Kanban auttaa, jos tekeminen on arvaamatonta

Muutaman tiimin Scrumista Kanbaniin itse coachanneena voin kuitenkin sanoa, että tässä siirtymässä on muutamia asioita, joihin pitää erityisesti kiinnittää huomiota. Jos nämä asiat otetaan huomioon tiimin kanssa kunnolla, Kanban on todennäköisesti paljon motivoivampi ja mukavampi toimintatapa. Ja toimistolle meno tuntuu taas mukavalta!

Aikaisemmassa Henrin blogikirjoituksessa käsiteltiinkin jo jotain Kanbanin haasteita. Erityisesti tuossa blogissa keskityttiin WIP limiittiin, eri Kanban prosessivaiheiden väliseen ”mini-DoDiin” ja jatkuvaan parantamiseen, eli retrospektiivien tärkeyteen. Käykääpä lukemassa tuo blogi, ja palatkaa sitten tänne, niin katsotaan lisää muita Kanbaniin siirtymisen haasteita!

Aina valmiina kuten partiopojat!

Jokainen tarina testataan aina välittömästi release-tasoisesti, ja bugit korjataan ennen kuin tarina merkataan suoritetuksi.

Määritelmällisesti puhdasta Scrumia käytettäessä kehitettävä ratkaisu tai tuote on ”potentiaalisesti releasoitavissa” sprintin lopussa. Mutta miten käy, jos tiimi vaihtaa Scrumista Kanbaniin, ja sprinttejä ei ole ollenkaan? Milloin tiimillä sitten on potentiaalisesti releasoitava tuote? Tämä on tärkeä asia, josta tiimin tulisi keskustella. Parasta kuitenkin olisi, jos vastauksena olisi aina ja jatkuvasti.

Vaikka tiimi tekeekin kehitystyötä yksittäisissä tarinoissa, niin kehitys tehdään niin, että myös main-haaran koodi on periaatteessa aina tuotantolaatuista. Eli jokainen tarina testataan aina välittömästi release-tasoisesti, ja bugit korjataan ennen kuin tarina merkataan suoritetuksi. Bugit tulee aina kirjata, ja vaikka hetkittäin saattaa olla jokunen salestopperi auki, on tiimin sisäisen priorisoinnin pidettävä huolta siitä, että ne korjataan heti seuraavaksi. Kun sprintit häviävät, häviää myös releasen kypsyttely sprinttien lopussa. Se siirtyy jokaisen tarinan done-siirtymään.

Jokainen tarina testataan kuin se menisi asiakkaalle

Jatkuva lähes-releasointikyky vaatii välttämättä sitä, että testaus on joko automaattista ja kattavaa, tai sitten sitä, että tiimin testaushenkilöt pystyvät tekemään yksittäisten tarinoiden testausta kuten he tekisivät release-testausta. Lisäksi tiimin pitää pystyä olemaan hyvin kurinalainen yksittäisen tarinan definition of donen kanssa. Tavoitteena on, että release-testauksessa ei enää löydettäisi mitään uusia vakavia bugeja, vaan kaikki olisi löydetty jo yksittäisissä tarinatestauksissa.

Kanbanin vapaus vaatii itsekuria

Kanbanissa on siis riski, että aloitetaan liian isoja asioita.

Toinen iso ongelma Kanbanissa on, että kun ei ole sprinttejä, tiimiltä unohtuu harkinta siitä, onko aloitettava asia tarpeeksi pieni, että se mahtuisi sprinttiin? On siis riski, että aloitetaan liian isoja asioita. Liian isojen tarinoiden aloittaminen on vaarallista – luottakaa minun sanaan, on nimittäin omakohtaista kokemusta! Vaatii kuria, ettei Kanbaniin siirtymisen jälkeen aloiteta liian isoja tarinoita, koska ”sprinttiin mahduttamisen” pakko puuttuu.

Erityisesti ohjelmistokehityksessä asioiden kompleksisuus ei ole lineaarista, vaan se seuraa enemmän ”hockey stick” -käyrää. Eli pienehköt tarinat ovat simppeleitä, mutta jossain kohtaa tiimin työmääräarviointia saattaakin tulla kohta, jossa isommat tarinat eivät olekaan enää lineaarisesti isompia. Jos yksi tarina on arvioitu esimerkiksi 10 storypointin kokoiseksi ja toinen 20 storypointin, niin tämä saattaa olla vielä kohtuullisen tarkka arvio. Mutta jos vastaan tuleekin 30 tai 35 storypointin tarina, on riskinä se, että se onkin oikeasti paljon isompi, jopa kaksin tai kolminkertainen.

Määritelkää maksimityömäärä sille, millaiset tarinat sallitaan aloittaa – isommat pilkotaan

Isompien tarinoiden keskustelu ja speksaaminen ennen aloitusta on paljon haastavampaa: koska niissä on aina enemmän sisäisiä riippuvuuksia, on isompien kokonaisuuksien testaaminen ja kypsytys huomattavasti vaikeampaa kuin pienien kokonaisuuksien. Tiimin pitäisikin erityisesti Kanbania käytettäessä määritellä maksimityömäärä sille, minkä kokoinen tarina voidaan ottaa työn alle. Tätä isommat urakat tulisi aina pilkkoa osiin.

To be continued

Tässäpä olikin pari Kanbaniin siirtymisen sudenkuoppaa. Jos pystytte välttämään ne, siirtyminen sujuu paljon paremmin! Mutta ei tässä ollut vielä ihan kaikki vaaran paikat – tulkaapa tsekkaamaan takaisin ensi viikolla niin kerron muutaman lisää ja annan vinkkejä miten niitä voi välttää!

Kanban on hyvä toiminnanohjauskeino. Kanbanin, kuten muidenkin ketterien metodien käyttöönotossa ja optimoinnissa osaava coachi voi olla todella hyvä apu. Valmentajan avulla uuteen toimintatapaan siirtyminen nopeutuu takuulla ja säästät aivan selvää rahaa. Contribyteltä löydät maailmanluokan osaajat Kanbanin ja Scrumin valmennukseen.