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 - Java-kehittäjä
- Laura - Systems Specialist, ajoneuvot
- IsoSkills Oy - Open application: Data Engineer, Finland
- Nordea - Sr IT Analyst - Adobe/SAS Marketing Automation
- Nordea - Senior IT / Business Analyst with technical background - Finland, Nordea Payments
- Nordea - Senior IT Analyst, Finnish language required
- Laura - DevOps Engineer
Premium-asiakkaiden viimeisimmät referenssit
- Advania Finland Oy - Turun kaupunki valjastaa digitaaliset ratkaisut palvelemaan strategiaansa
- Sulava Oy - Fondia vahvistaa tekoälyn hyödyntämistä Microsoft Copilotilla
- Druid Oy - International House Turku: Ajanvarauspalvelu
- Symbio - Taxi Point Oy
- Valve - Helsingin yliopiston ylioppilaskunnan verkkopalvelun siirto WordPressiin
- Valve - Eezy Valmennuskeskuksen verkkokauppa-uudistus
- Valve - Danonen Nutricia ja Aptaclub -brändien sivustot
Tapahtumat & webinaarit
- 06.11.2024 - Webinaari: Future-Proof Your Data Infrastructure with Azure
- 13.11.2024 - Rakettiwebinaari: ohjelmistotestaus ja sen tulevaisuus
- 13.11.2024 - Miten palvelumuotoilu poistaa epävarmuutta digi-investoinneista?
- 14.11.2024 - RoimaDay 2024
- 14.11.2024 - Verkkolaskufoorumin syysseminaari 2024
- 19.11.2024 - The Future of Software - Embracing Collaboration in an AI-Powered World
- 19.11.2024 - Tehokkuutta ja säästöjä low-code-ratkaisuilla
Premium-asiakkaiden viimeisimmät bloggaukset
- Innofactor Oyj - Tunnista ja digitalisoi hiomattomat prosessit Power Platformin avulla
- SD Worx - Oletko etuoikeutettu työskentelemään jonkin asian parissa, jolla on todellinen tarkoitus ja merkitys?
- SD Worx - HR ja tekoäly – usein kysytyt kysymykset
- Timeless Technology - Verkon luotettavuuden varmistaminen: Ota käyttöön Perle Systemsin teollisuustason 4G ja 5G reitittimet!
- Efima Oyj - Hyvästi turhat klikkailut: Näin moderni järjestelmä tehostaa myyntityötä erikoistavarakaupassa
- SC Software Oy - SC Softwaren uratarinat: Joel Ollikainen, konsultti
- Softlandia Oy - Sovelletun tekoälyn insinöörien esiinmarssi ja tekoälyosaamisen muutos
Digitalisaatio & innovaatiot blogimediaBlogimediamme käsittelee tulevaisuuden liiketoimintaa, digitaalisia innovaatioita ja internet-ajan ilmiöitä |