Ketterässä tuotekehityksessä on vain muutamia avainrooleja: itseohjautuva tiimi, scrum master ja kolmantena tuoteomistaja eli Product Owner (PO). Vaikka tiimi ei toimisikaan scrum-moodissa, on aika yleinen käytäntö, että tiimillä silti on scrum master. On yllättävää, miten usein kuitenkin törmään tilanteeseen, että tiimiltä itseasiassa puuttuu tuoteomistaja.
Nimetyn tuoteomistajan puuttuessa, hänen hommansa hoitaa joskus scrum master, toisinaan tiimin linjaesimies, joskus projektipäällikkö ja joskus myös tuotepäällikkö. Toisinaan törmään myös tilanteeseen, että on useita ihmisiä jotka ajattelevat yhtä aikaa hoitavansa Product Ownerin roolin töitä.
Product owner? Onko se oikea työ?
Jotenkin tuntuu, että tuoteomistajuuden arvoa ei oikein ymmärretä organisaatioissa täysin. Joskus tuntuu, että on hankalaa perustella miksi yhden ihmisen ”joka ei koodaa” pitäisi olla liitettynä aika täysipäiväisesti tiimin kylkeen. Jos teidän organisaatiossakin on tämä asia hankala perustella muille, toivottavasti tästä blogista saatte vähän aseita. Katsotaanpa seuraavaksi miksi tuoteomistajan rooli on niin tärkeä.
Tuoteomistajalla on valtavasti vaikutusvaltaa kehitystiimin tuloksiin ja siten myös lopputulokseen, siihen millaiseksi tuote muodostuu. Miksi näin on? Perussyyn voi nähdä, kun ymmärtää miten ketterä tuotekehitystiimi toimii.
Garbage in – garbage out
Tuoteomistaja on ainoa henkilö joka organisaatiossa viime kädessä päättää siitä mitä tuossa tiimille työtä syöttävässä backlog-suppilossa on, ja millaisina sieltä tiimille työ syötetään. Vaikka tiimi olisi kuinka hyvä, lopputulos eli output voi olla huonoa, jos sisään syötettävät työt (eli yleensä käyttäjätarinat) ovat huonolaatuisia, väärin priorisoituja tai väärin valittuja.
Opi sanomaan EI
Miten hyvä tuoteomistaja sitten pitää huolta siitä, että tiimin tuotos on mahdollisimman hyvälaatuista ja arvokasta yritykselle? Ensimmäinen päätös on se mitä EI tehdä. Eli tuoteomistajan pitää oppia rehellisesti sanomaan EI. On äärimmäisen yleistä, voisi jopa väittää, että on tuotekehityksen ”nollas laki” että ideasyötteitä kehitystiimille on aina enemmän kuin mitä kehitystiimi voi käytännössä saada aikaan. Uusikin tiimi päätyy todella nopeasti tilanteeseen, että backlogilla olevat asiat, vaikka olisivatkin prioriteettijärjestyksessä, ottaisivat yli vuoden tehdä kaikki pois.
Backlogin pituus – pidä se maksimissaan 3-6 kuukaudessa
Joskus backlog sisältää monen vuoden työt. On selvää, että tällainen backlog ei enää ole käytännössä toimiva, vaan tiimi ottaa lähes jatkuvasti uusia töitä ja sijoittaa ne ”keskelle” backlogia, niin että ne saadaan muutamassa kuukaudessa tehtyä. Olisi kuitenkin parempi, että keinotekoisen pitkää backlogia ei päästettäisi edes syntymään, ja tuoteomistaja pystyisi suodattamaan ideavirrasta vain todellisesti arvokkaat ideat backlogille asti.
Priorisoi aina – vaikka joutuisit arvaamaan
Tämä tietenkin tarkoittaa sitä, että tuoteomistajan pitäisi pystyä arvaamaan kuinka arvokas yksittäinen idea voisi olla, ja myös kuinka isotöinen se tulee olemaan. Effortin arviointikyky paranee, kun tuoteomistaja tutustuu ja kerää kokemusta tuotteestaan, mutta ennen kuin se on kehittynyt riittävälle tasolle, pitää sitten ottaa avuksi kehitystiimistä porukkaa ja tehdä ideoiden arviointia vaikkapa backlog grooming sessiossa tai sitten informaalisti.
Tarinoiden arvotus onkin todella hankalaa ja ehkä oman blogin paikka. Toisinaan tarinaan liittyy joku suora asiakastilaus ja silloin arvotus on helppoa. Monesti se menee ihan arvailuksi.
Työstä valitut tarinat yhdessä tiimin kanssa hyvälaatuisiksi
Sitten kun on pystytty valitsemaan mitä tarinoita otetaan työn alle, tuoteomistajan seuraava homma on varmistaa, että tarinat ovat sellaisia, että niissä saadaan just oikeat asiat tehtyä, ja tiimi saa tehtyä niiden kanssa työtä tehokkaasti ja ilman hukkatyötä. Eli, tarinoiden pitäisi olla tarpeeksi pieniä, selkeitä, toisistaan riippumattomia ja niistä pitäisi keskustella tiimin jäsenten kanssa, jotta kaikki ymmärtävät mitä ollaan tekemässä ja niihin voidaan myös tehdä tarvittavia toteutusteknisiä säätöjä.
Ole utelias, mutta älä kontrolloi tai painosta – jätä toteutustekniset asiat tiimin huoleksi
Työn alla oleviin tarinoihin tuoteomistajan kannattaa suhtautua uteliaisuudella mutta samalla kuitenkin niin että tiimille jätetään tekninen omistajuus tehdä toteutus niin että se on hyvälaatuista ja tervettä ja helposti ylläpidettävää. Eli, suosittelen että tuoteomistaja käy kyselemässä kehitystiimiltä, miten homma edistyy, ja onko tullut mitään tenkkapoota vastaan. Usein näissä ongelmakohdissa on hyviä tilaisuuksia hienosäätää tarinaa vieläkin arvokkaammaksi.
Keskustelut ovat tuoteomistajan arkea – varaa niihin tarpeeksi aikaa
Suuri osa tuoteomistajan työtä on tehdä ”koulututettuja arvauksia”. Arvauksia siitä mitkä tarinat ovat arvokkaimpia juuri nyt, tai siitä mitkä tarinat on nyt vaan pakko hylätä koska ne eivät ole tarpeeksi paljon lisäarvoa tuottavia, tai hankalia myydä, tai liian työläitä. Ehkä haastavin osa tuoteomistajan työtä onkin säilyttää tarpeeksi hyvä asiakaskontakti ja markkinaymmärrys, jotta nämä joka päivä vastaan tulevat arvaustilanteet menisivät mahdollisimman oikein. Asiakaskontaktien ja jatkuvan keskustelun arvo onkin todella suuri tuoteomistajalle, ja siihen on syytä osata varata tarpeeksi työaikaa.
Lähtövauhti tuoteomistajuuteen koulutuksesta
Tässä nyt vasta raapaistiin tuoteomistajuuden pintaa, mutta eikö jo vaikutakin hassulta miten tärkeästä työstä on kysymys, ja silti miten usein törmätään tilanteisiin, että tuoteomistajuus on vähän epäselvä rooli organisaatiossa? Tai miten usein törmätään tilanteeseen, että tuoteomistajan rooli annetaan jollekin ihmiselle ilman sen suurempaa koulutusta tai aikaisempaa kokemusta? Tuoteomistajan rooli on ketterän kehityksen keskiössä, ja vaikka se ei olekaan mikään ylettömän hankala rooli ja yleensä todella palkitseva ja opettava rooli, siihen on kuitenkin syytä suhtautua vakavasti ja varata siihen riittävästi aikaa ja kapasiteettia. Tuoteomistajuuteen oppii nopeasti, mutta parhaan lähtövauhdin uuteen rooliin saa asiantuntevasta koulutuksesta.
Tervetuloa maksuttomaan webinaariin kuulemaan lisää
Jos aihe kiinnostaa, kannattaa ilmoittautua maksuttomaan webinaariin, jonka pidän 6.6.2018 klo 9:00 – 10:00. Ilmoittautua kannattaa, vaikkei ajankohta natsaisikaan, sillä tarjolle tulee myös jälkitallenne!
Webinaarissa esitellään lyhyesti, miksi tuoteomistaja-rooli on niin tärkeä, ja mitä tuoteomistajan tehtäviin ja vastuisiin kuuluu. Lisäksi esitellään lyhyesti tärkeimpiä asioita ja hyviä käytäntöjä, ja tuoteomistajien yleisimpiä virheitä. Webinaari on suunnattu tuoteomistajille, joko aloitteleville, roolista kiinnostuneille, tai jo pari vuotta roolissa toimineille. Webinaari toimii hyvin pohjustuksena myös kurssilleni Product Owner – ketterä tuoteomistaja Scrum tai Kanban tiimille, jonka löydät Oppia.fi – Oppimisen verkkokaupasta.
Contribyte on suomen johtava tuotekehityksen auttaja. Meillä on kokeneet Product Owner kouluttajat, ja meiltä saat myös paljon muita palveluita organisaatiosi kehittämiseen!
Arto Kiiskinen
Kirjoittaja on toiminut tuotekehityksen erilaisissa projektijohto-, tuotepäällikkö, product owner ja scrum master tehtävissä vuodesta 1997. Kokemusta on kertynyt myös testauksesta, asiakastuesta, ongelmanratkaisusta ja deploymenteista. Kouluttajaksi Arto siirtyi vuonna 2017 Contribytelle.
* Scrum ja Kanban kokemusta 10+ vuotta
* Tuoteomistajakokemusta 10+ vuotta
* SAFe Agilist sertifioitu
* ISTQB sertifioitu testaaja
* Tuotekehityksen projektipäällikkö, program manager -kokemusta vuodesta 1997
* Scrum master kokemusta
* Asiakastuki- ja deployment-kokemusta
* Kokemusta monikulttuuri, monitimezone ja valtamerenylihankkeista
* Kouluttajana vuodesta 2017
* Muita Videoita kouluttajalta, katso video 1, video 2 ja video 3