Sileä siirtymä Scrumista Kanbaniin, osa 2

Bloggaus Aikaisemmassa blogissani aloinkin jo miettiä sitä, mitkä ovat useimmin vastaan tulevia ongelmia tiimin siirtyessä Scrumista Kanbaniin. Jos et vielä lukenut kyseistä blogia, niin lue se ensin, ja palaa sitten tänne! Myös varhaisempi Kanbanin perushyödyt -blogipostauksemme voi tarjota kiinnostavaa taustalukemistoa.
Viimeksi puhuttiinkin siitä, että Kanbanissa on Scrumia helpompi sallia liian ison tarinan aloittaminen. Kun Scrumin sprintit puuttuu, puuttuu tiimiltä myös se ”pakko” mahduttaa tekeminen siihen kahden tai kolmen viikon ajanjaksoon. Sprinttien puuttumisella on myös toinen vaara: sprinttien puuttuessa ei tarvita myöskään sprintin suunnittelua, eli Sprint Planningia.

Kaikki selvää?

Sprint Planning on Scrumissa viimeinen tsekki, jossa sprinttiin ladattavat tarinat voidaan katsoa läpi. Riski onkin, että kun tiimi siirtyy Scrumista Kanbaniin, tiimi ja Product Owner eivät enää riittävästi suunnittele tulevaa, eivätkä juuri keskustele ja tarkenna ymmärrystään backlog itemeista. Kanbanissa olisikin aivan ensiarvoisen tärkeää pitää säännöllistä sessioita joka viikko, kutsutaan sitä sitten suunnitteluksi tai Backlog Groomingiksi. Tässä kokouksessa olisi syytä katsoa prioriteetteja, sekä keskustella läpi tärkeimmät backlog itemit.

Unohtuiko demot?

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!