Hae it-yrityksiä
osaamisalueittain:

Asiakkuudenhallinta CRM BI ja raportointi HR Tuotekehitys ja suunnittelu Toiminnanohjaus ERP Taloushallinto Markkinointi Webkehitys Mobiilikehitys Käyttöliittymäsuunnittelu Tietoturva Verkkokaupparatkaisut Ohjelmistokehitys Integraatiot Pilvipalvelut / SaaS Tekoäly (AI) ja koneoppiminen Lisätty todellisuus ja VR Paikkatieto GIS IoT Microsoft SAP IBM Salesforce Amazon Web Services Javascript React PHP WordPress Drupal
Contribyte » Bloggaus

Sileä siirtymä Scrumista Kanbaniin

BloggausKetterä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ää!

Pinterest
Contribyte logo

Lisätietoja

Yritysprofiili Contribyte kotisivut

Tagit

Jos tarjontatagi on sininen, pääset klikkaamalla sen kuvaukseen

Liiketoimintaprosessi

Tietohallinto

Erikoisosaaminen

Ketterät menetelmät
Ohjelmistokehitys

Toimialakokemus

IT

Tarjonnan tyyppi

Konsultointi
Koulutus

Omat tagit

Kanban

Siirry yrityksen profiiliin Contribyte kotisivut Yrityshaku Referenssihaku Julkaisuhaku

Contribyte - Asiantuntijat ja yhteyshenkilöt

Premium-profiilia ei ole aktivoitu. Aktivoi premium-profiili näyttääksesi tässä lisäämäsi 3 asiantuntijaa.

Contribyte - Muita referenssejä

Contribyte - Muita bloggauksia

Löydä sopivimmat it- ja ohjelmistoyritykset liiketoiminnan kehityskumppaneiksi

ite wikin yrityshaku »

It- ja ohjelmistoalan työpaikat

Kaikki it-alan työpaikat »

Premium-asiakkaiden viimeisimmät referenssit

ite wikin referenssihaku »

Tapahtumat & webinaarit

Kaikki it-alan tapahtumat »

Premium-asiakkaiden viimeisimmät bloggaukset

ite wikin julkaisuhaku »

Digitalisaatio & innovaatiot blogimedia

Blogimediamme käsittelee tulevaisuuden liiketoimintaa, digitaalisia innovaatioita ja internet-ajan ilmiöitä
Huhti 22
Suorahaku rekrytointikeinona it-alalla - top 5 vinkit, joiden avulla menestyt
LinkedIn Recruiterissa rekrytoijat etsivät profiileja profiilissa toistuvien avainsanojen ja taitojen perusteella.
Huhti 19
Mikä todella toimii ohjelmistoalan markkinoinnissa ja myynnissä? Top 10 liidien lähteet
Tutkimuksen mukaan verkkosivujen hakukoneoptimointi on kaikista tärkein liidien lähde ohjelmistoalalla
Huhti 10
Kannattaako tietojärjestelmää jatkokehittää, vai investoida uuteen ohjelmistoon? Sofokuksen Digikehityksen katsastus auttaa digipalvelun elinkaaren suunnittelussa
Katsastuksella autetaan varmistamaan, että teknologia palvelee asiakasta, eikä päinvastoin
Siirry blogiin

Etusivu Yrityshaku Pikahaku Referenssihaku Julkaisuhaku Blogimedia