Sileä siirtymä Scrumista Kanbaniin
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
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!
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
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ää!
Lisätietoja
Tagit
Liiketoimintaprosessi
Tietohallinto |
Erikoisosaaminen
Ketterät menetelmät | |
Ohjelmistokehitys |
Toimialakokemus
IT |
Tarjonnan tyyppi
Konsultointi | |
Koulutus |
Omat tagit
Contribyte - Asiantuntijat ja yhteyshenkilöt
Contribyte - Muita referenssejä
Contribyte - Muita bloggauksia
It- ja ohjelmistoalan työpaikat
- Laura - Development Team Manager, Sports Games
- Taito United Oy - Senior Full Stack -kehittäjä
- Webscale Oy - Head of Sales, Cloud Services
- Laura - Hankinta-asiantuntija, tietohallinto
- Laura - Development Manager, Operations
- Laura - ICT-asiantuntija
- Laura - IT Manager
Premium-asiakkaiden viimeisimmät referenssit
- SD Worx - Kehitystyö SD Worxin kanssa takaa Clas Ohlsonille parhaat palkanmaksun prosessit kasvun tiellä
- Digiteam Oy - Case Esperi Care Oy: Ketterä kumppanuus vei Esperin verkkosivu-uudistuksen maaliin sujuvasti ja aikataulussa
- Kisko Labs Oy - Howspace Hub - Mukautuva oppimisen hallintajärjestelmä kasvaviin oppimisalustavaatimuksiin
- Kisko Labs Oy - Sanoma Pro: Multimediasisältöjen hallinnan uudistaminen
- Kisko Labs Oy - Svean helppokäyttöinen palvelu asiakkaan verkko-ostosten hallintaan
- Kisko Labs Oy - Yhtenäinen käyttöliittymä luovien alojen ammattilaisille
- Codemate - Digitaalisen murroksen nopeuttaminen Flutterin avulla
Tapahtumat & webinaarit
- 27.11.2024 - Green ICT -ekosysteemitapaaminen III: Ohjelmistojärjestelmien virrankulutuksen mittaaminen ja kasvihuonepäästöjen arviointi
- 27.11.2024 - Digitaalisen asiakaskokemuksen uusi aikakausi
- 28.11.2024 - Webinaari: Keskity myyntityön laatuun!
- 28.11.2024 - Copilot-webinaari – Mielekkäämpää tietotyötä turvallisesti
- 04.12.2024 - Kuinka oikea matka- ja kululaskujärjestelmä tehostaa prosesseja?
- 05.12.2024 - Green ICT VICTIS -hankkeen kick off -tilaisuus
- 15.01.2025 - Datavastuullisuuden valmennus: hanki valmiudet vastuulliseen datan ja tekoälyn hyödyntämiseen
Premium-asiakkaiden viimeisimmät bloggaukset
- Kisko Labs Oy - Heroku: Millaisiin projekteihin se sopii ja mitkä ovat sen todelliset hyödyt ja haitat?
- Zimple Oy - Pipedrive vai Hubspot? Kumpi kannattaa valita?
- SC Software Oy - Jatkuvat palvelut – asiakaslähtöistä kumppanuutta projekteista ylläpitoon
- Timeless Technology - Ohjelmoitavat logiikat (PLC): Ratkaisevat työkalut automaatioon ControlByWebiltä.
- Kisko Labs Oy - Heroku: Ohjelmistokehittäjän ykköstyökalu skaalautuvien sovellusten rakentamiseen
- SD Worx - Näin luot vakuuttavan Business Casen palkkahallinnon ulkoistukselle
- Timeless Technology - Kyberriskien tunnistaminen Profitap IOTA verkkoanalysaattorin avulla.
Digitalisaatio & innovaatiot blogimediaBlogimediamme käsittelee tulevaisuuden liiketoimintaa, digitaalisia innovaatioita ja internet-ajan ilmiöitä |