Sileä siirtymä Scrumista Kanbaniin, osa 2

Sprinttien puuttuessa puuttuu myös luonteva tilaisuus järjestää demoja. Oma kokemukseni on, että Kanbaniin siirryttyä demojen järjestämisfrekvenssi harvenee. Jos Scrumissa demot tuli aina pidettyä kahden viikon välein, saattaa Kanbaniin siirryttyä tuo väli pidentyä, vaikka neljään tai kuuteen viikkoon. Demot ovat yksi ketteryyden feedback looppeja, eli niissä saadaan suora kontakti stakeholdereihin, ja tiimi saa palautetta tekemisestä. Olisikin syytä muistaa, että Kanbaniin siirtymisen jälkeen on tärkeää aikatauluttaa demoja sopivalla frekvenssillä.

Tiedättekö kuinka nopeasti ajoitte?

Velocityn mittaus on myös yksi haastava asia. Kanbanissa sen voi tehdä yksinkertaisimmin niin, että katsoo aikayksikössä (tyypillisimmin viikossa) suljetuksi menneiden arvioitujen tarinoiden effort estimaatit ja laskee sitten niistä rullaavan keskiarvon. Tätä arvoa voi käyttää sitten sen arvioimiseen, miten kauan joku tietty osa backlogista kestää saada valmiiksi. Katselin, tukeeko JIRA tätä – ja eipä taida tukea eli manuaaliseksi laskutoimitukseksi menee! Mutta sitten törmäsin ”Great Gadgets” JIRA-pluginiin, josta Kanban velocityn saa suoraan raporttiin. Eli jos teillä on JIRA käytössä, niin tutustukaapa tuohon, niin ei tarvitse käsin velocityä laskea!

Ei taida olla meidän ongelma

Viimeiseksi voisi ottaa riskin tiimin siiloutumisesta. Kun tiimi lopettaa Scrumin yhteisen ”mitä saisimme aikaan parissa viikossa” -ajattelutavan, ja alkaa tehdä töitä enemmän ”liukuhihnalla” (sitähän Kanban on!), niin saattaapi olla, että päähän alkaa hiipiä vähän sellainen ”liukuhihna-asenne”. Eli minä teen vaan tätä omaa juttuani, ja muut tekevät muita juttuja. Vaikka tämä voi kuulostaa hieman hassulta, niin tämä on ihan oikea vaaran paikka! Suosittelenkin, että Scrum Master terävöittää Daily meetingiä ja yhteisiä sessioita niin, että ihmiset olisivat niissä hereillä, ja kiinnostuneita siitä, mitä muut ovat tekemässä. Product Ownerin ja Product Managerin pitäisi myös pitää ihmisillä Big Picture hyvin tiedossa, ja tuotteen ja releasen senhetkinen visio myös. Näin saadaan Kanbanissakin toimiva tiimi tiedostamaan, mitä muut ovat tekemässä ja olemaan kiinnostunut ja avulias muille.

Koulutusta tai valmennusta? Harkitse!

Kanban on hieno toimintatapa, erityisesti kokeneille tiimeille. Tiimeille, joille tulee yllätyksiä usein, se on yleensä paljon miellyttävämpi tapa ohjata toimintaa kuin Scrum. Mutta kuten viisas lukija onkin nyt näistä parista blogista havainnut, Kanbanissakin on omat vaaransa. Toivottavasti osaatte nyt pitää niitä silmällä ja välttää sudenkuopat! Ja pitäkää mielessä, aina kun toimintatapoja muutetaan, valmentaja auttaa viemään muutoksen nopeammin läpi. Jos siis haluatte muuttua vähemmällä tuskalla, ottakaa coachi apuun!