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, osa 2

BloggausAikaisemmassa 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!

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
scrum
tuotekehitys

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