Välillä tiimeille tulee vastaan harvinaisen hankala bugi, kuten ongelma, jota ei tiimin käytettävissä olevilla testiympäristöillä saada toistettua. Tällaisessa tilanteessa olisi tärkeää käyttää ylivoimaa bugin selvittämiseen, sillä ratkaisuun tarvitaan koko tiimin aivoja ja voimavaroja. Lisäksi porukalle olisi luotava positiivinen mielentila, jossa ihmiset ajattelevat, että juttu ratkeaa tavalla tai toisella. Ihmiset ratkovat ongelmia paljon paremmin ja tehokkaammin kun heidän ajatuksensa ja aivonsa eivät ole negatiivisilla ajatuksilla alustettuja.
Bugipato syö tehoja
Usein vastaan tuleva ongelma on se, että tiimillä on kertynyt ”verifiointivelka”, eli bugeja on fiksattu nopeammin kuin testaus pystyy niitä verifioimaan. Tässä onkin sellainen piilevä vaara, että jos tuo verifioitavana olevien bugien määrä kasvaa kovin isoksi, siitä tuleekin aikamoinen suo, kun sitä aletaan sitten myöhemmin kahlaamaan läpi. Tämä on todennäköisempää bugeille kuin tarinoille, koska agile-metodit pitävät huolen siitä, että aloitettavat tarinat ovat aika korkealla backlogilla. Lisäksi tarinat ovat usein hitaampia implementoida kuin bugifiksit.
Product Owner – tuotepäällikön torppari vai tuotteen omistaja?
Monissa organisaatioissa tuotepäällikön sekä Product Ownerin vastuualueet menevät iloisesti päällekkäin. Kun vastuut ovat samankaltaiset, riskinä on, että tehtävät muodostuvat niin epäselviksi, että jotain oleellista jää tekemättä.
Tehdäänkö teidän tiimissä näin? Kolme yleistä virhettä bugiraporteissa.
Eipä juuri enää tule vastaan tuotekehitystiimejä, joilla ei olisi käytössä jonkin sortin online-bugityökalu. JIRA on ehkä suosituin, mutta bugeja voidaan hallita myös muillakin työkaluilla. Oli tiimi sitten miten kokenut tai laatutyötä tekevä tahansa,...
Päätöksenteolla ainainen kiire? Hopulle loppu aktiivisella delegoinnilla.
Nykyään töissä tuntuu aina olevan kiire. Tuotekehitysprojektit eivät ole tästä mikään poikkeus. Ketterillä toimintatavoilla voidaan tiimiläisten kiireen tuntua vähentää, mutta toimintaa ohjaaville henkilöille, tuotteen omistajalle tai projektin vetäjälle kasautuu...
Värillä on väliä – Scrumin edut käyttöön myös Kanbanissa
Suosituimmat ketterät toiminnanohjauskeinot ovat Scrum ja Kanban. Näistä Scrum on tuotekehityksessä yleisemmin käytössä. Scrummin pääetu Kanbaniin verrattuna on se, että fiksatun mittaisissa iteraatioissa on helpompi mitata tiimin nopeutta, velocityä, ja sitä kautta ulottaa ennustettavuutta pitemmälle tulevaisuuteen. Scrummin iteraatiot myös pakottavat tiimin tekemään suunnitelmia ja retrospektiivejä. Jo käynnissä olevaan Scrum – sprinttiin ei kuitenkaan yleensä ole hyvä lisätä mitään, joten tyypillisesti Scrum-tiimi voi reagoida kiireellisiin asioihin vasta seuraavassa sprintissä.
Tiikeri vai tiimi? – Positiivisuus lisää tehoja.
Positiivisuudella on suuri merkitys myös töissä. Innovatiivisuuden ja tehokkuuden takia olisikin tärkeää, että työntekijät kokisivat jatkuvasti positiivisia tunteita. Onnellisena ajattelu on tehokkaampaa, ja positiiviset aivot löytävät uusia, innovatiivisia ratkaisuja helpommin ja nopeammin kuin negatiiviset.
Työporukan yhteinen kahvihetki on kuin keidas aavikolla
Ensimmäisessä työpaikassani vuosia sitten koko tuotekehitysporukka kerääntyi kaksi kertaa päivässä kahville. Yhteiset kahvihetket olivat loistavia yhteishengen kohottajia ja työnteon rytmittäjiä. Niiden aikana juteltiin enimmäkseen muista kuin työasioista, mutta joskus joku kyseli joltain toiselta tietoa ja apuakin joko kahvihetken aikana tai sen päätteeksi. En ole koko 20-vuotisen työurani aikana törmännyt yhtä hyvin suunniteltuun tuotekehitystoimistoon tai yhtä mukavaan kahvihetkikäytäntöön.
Asiakaskommunikaatio kuuluu kaikille – ethän pidä tiimiäsi pimennossa?
Säännöllinen asiakaskommunikaatio on tärkeää tuotekehitystiimeille. Yhteydenpito asiakkaiden kanssa edistää sekä itseohjautuvuutta että ketterää toimintaa, ja siihen kannattaa siksi panostaa.
Retrospektiivi on elintärkeä tuotekehitystiimeille – muille riittääkin viinanhöyryinen kehityspäivä kerran vuodessa?
Ketterät tuotekehitystiimit pitävät tyypillisesti pari kertaa kuussa retrospektiivin, jossa mietitään keinoja parantaa toimintatapoja. Tämä käytäntö kuuluu ketterän tuotekehityksen tapojen perusteisiin, ja sillä tavoitellaan tiimin suorituskyvyn parantamista.