Scrum ja tuoteomistajan rooli

Innovaatiopalvelumallissa palvelut toteutetaan käyttämällä Scrum-viitekehystä. Asiakas toimii palvelun toteutuksen aikana tuoteomistajana (Product Owner, PO), joka on yksi Scrumiin kuuluvista rooleista.  Palvelun toteuttamisen kannalta ei haittaa, jos tuoteomistajan rooli ei ole asiakkaalle entuudestaan tuttu, sillä IT antaa valmennusta ja tukea roolissa toimimiseksi. Tässä kirjoituksessa käydään lyhyesti läpi tuoteomistjan roolia Scrumissa, mitä tuoteomistajana toimiminen pitää käytännössä sisällään ja kuinka rooli ja tehtävienjako poikkeavat perinteisemmistä tuotekehitykseen liittyvistä rooleista ja tehtävienjaosta.

Vaativa mutta palkitseva tehtävä

Tuoteomistajan rooli on vastuullinen ja vaativa tehtävä, mutta myös palkitseva, sillä tehtävässä pääsee vaikuttamaan kokonaisvaltaisesti kehitettävään tuotteeseen. Tuoteomistaja vastaa tuotteen korkean tason visiosta eli mitä projekti tuottaa, ketä varten ja miksi. Hänen tehtävänsä on hankkia rahoitusta tuotekehitystä varten ja optimoida kehitysinvestoinille saatavaa tuottoa eli ROI:ta. Lisäksi hän edustaa tuotteen sidosryhmien näkemyksiä ja vastaa tiedon keräämisestä  mitä ominaisuuksia tuotteessa pitää olla ja mikä on niiden suhteellinen arvo toisiinsa nähden, eli mitä ominaisuuksia toteutetaan ensin, mikä on julkaisun laajuus ja ajankohta. Käytännön kannalta merkittävä asia on, että tuoteomistaja omistaa tuotteeseen liittyvän tuotteen kehitysjonon (Product Backlog).  Hän on kehitysjonon ainoa omistaja ja vain hänellä on oikeus tehdä päätöksiä tai muutoksia siihen liittyen. Toki kehitysjonoon liittyviä päätöksiä varten tuoteomistaja kerää tietoa tuotteeseen liittyviltä sidosryhmiltä, joten aikaa kuluu yhteistyöhön sidosryhimen kanssa kokouksien, viestinnän ja raportoinnin muodossa.

Läpinäkyvyyttä, tarkastelua ja sopeuttamista

Tuoteomistaja on siis yksi Scrum-viitekehykseen kuuluvista rooleista. Tuoteomistajan lisäksi Scrumissa on kaksi muuta roolia:  Scrumaster ja kehitystiimi (Team). Scrum on menetelmä, joka pohjautuu empiiriseen prosessikontrolliin, ja siihen kuuluu kolme tukijalkaa:

  1. Läpinäkyvyyden luominen, mikä tarkoittaa että prosessin lopputulokseen vaikuttavien tekijöiden tulee olla näkyvissä prosessiin vaikuttaville henkilöille;
  2. Prosessin säännöllisen tarkastelun avulla pyritään havaitsemaan haitalliset poikkeamat riittävän ajoissa;
  3. Prosessin ja tuotteen kehitykseen liittyvien asioiden sopeuttamisella tuotteesta saadaan hyväksyttävä ja myöhemmät poikkeamat minimoidaan.

Scrumissa  (Kuva 1.) on kolme tapaa tarkastelun ja sopeuttamisen toteuttamiseen:

  1. Päivän Scrum -kokouksessa (Daily Scrum) seurataan edistymistä kohti sprintin tavoitetta ja tehdään sopeutuksia, joiden avulla työnteko olisi mahdollisimman tehokasta tavoitteisiin nähden.
  2. Sprintin suunnittelu- (Sprint Planning) ja katselmointikokouksissa (Sprint review meeting) suunnitellaan kuinka  tuotteen julkaisutavoitetteseen päästään. Vastaavasti tarkastellaan kuinka hyvin päättyneessä sprintissä onnistuttiin  ja mietitään mitä muutoksia (sopeutuksia) pitää tehdä, jotta seuraavan sprintin jälkeen tuote vastaisi entistä paremmin tavoitteita.
  3. Sprintin retrospektiivikokouksessa (Retrospective meeting) tarkastellaan kuinka kehitystiimin työskentely sujui sprintin aikana ja mietitään, että miten työntekoa voitaisiin kehittää,  jotta seuraavassa sprintistä työskentely olisi tuottavampaa ja mukavampaa.
Scrum-prosessi
Kuva 1. Scrum-prosessi (http://www.waterfall-model.com/agile-scrum/)

Yhteistyötä kehitystiimin kanssa

Scrum-viitekehyksen mukaan tuoteomistajan kuuluu olla läsnä tuotteen kehitysjonon (Product Backlog) refaktoroinnissa,  sprintin suunnittelukokouksessa ja sprintin katselmointikokouksessa (review). Tuotteen kehitysjonossa listataan kaikki vaatimukset tuotteelle, jota kehitystiimi(t) kehittävät.  Scrumin sääntöjen mukaan kehitystiimi voi käyttää kehitysjonon refaktiorointiin 5-10% ajastaan.

Sprintin suunnittelukokouksessa suunnitellaan alkava kehitysjakso eli sprintti. Sprintin suunnittelukokous koostuu  “mitä?”  ja “miten?” osista. Suunnittelukokouksen “mitä” -osassa  tuoteomistaja esittelee kehitystiimille listan tuotteen vaatimuksista (kehitysjonon) sekä niiden prioriteetit.  Tämän jälkeen kehitystiimi ja tuoteomistaja yhdessä miettivät mitä asioita kehitysjonosta valitaan työstettävksi seuraavassa sprintissä.

Suunnittelukokouksen “miten” -osassa tuoteomistaja ja kehitystiimi  miettivät kuinka “mitä” -osiossa valitut asiat saadaan sprintin aikana toteutettua. Tuoteomistaja tarkentaa tarvittaessa kehitystiimille tuotteen kehitysjonon sisältöä ja auttaa löytämään kompromisseja. Sprintille valitaan myös tavoite, jonka tarkoituksena on antaa kehitystiimille konkreettinen näkökulma ja perustelu, miksi se on kehittämässä tuotteen ominaisuuksia. Jos kehitystiimi huomaa, että sprintissä onkin liikaa tai liian vähän tehtäviä, se voi neuvotella uudestaan tuoteomistajan kanssa kehistysjonon sisällöstä. Kehitystiimi ja tuoteomistaja voivat kutsua suunnittelukokoukseen mukaan muitakin henkilöitä saadakseen teknisiä tai liiketoiminnallisia neuvoja kehitettävään tuotteeseen liittyen.

Sprintin katselmoinnissa scrumtiimi ja muut asianosaiset henkilöt käyvät yhdessä läpi sprintin saavutukset. Katselmoinnin ja tuoteomistajan päivittämän tuotteen kehitysjonon perusteella selvitetään mitä seuraavaksi kannattaa tehdä.  Tuoteomistaja selvittää kehitystiimin kanssa mitkä sprinttiin valituista kehitysjonon kohdista on saatu valmiiksi ja mitkä ovat vielä kesken. Kehitystiimi keskustelee mikä sujui hyvin, mitä ongelmia ilmeni ja kuinka ongelmat ratkaistiin. Kehitystiimi myös esittelee tekemänsä työn ja vastaa kysymyksiin.

Scrumissä määriteltyjen tapahtumien lisäksi tuoteomistaja  on jatkuvassa  yhteistyössä kehitystiimin kanssa myös sprintin kuluessa muun muassa vastaamalla kehitystiimin hänelle esittämiin kysymyksiin.

Uskoa asiaansa, tietoa, valtaa ja aikaa

Kenen tulisi toimia tuoteomistajana? Koska tuoteomistaja joutuu perustelemaan eri sidosryhmille, kuten rahoittajille, käyttäjille sekä kehitystiimille, miksi tuotetta ollaan kehittämässä, täytyy hänen itsensä myös “uskoa asiaansa“, jotta hän saisi myös muut vakuuttuneiksi ja sitoutumaan tavoitteisiin. Pelkällä tahdonvoimalla ei kuitenkaan tule valmista, vaan tuotteen omistajalla pitää olla myös riittävästi tietoa kehitettävään tuotteeseen ja tuotekehitysprosessiin liittyen. Tuoteomistajalla tulisi olla tietoa liiketoimintaprosessista, jossa tuotetta tullaan käyttämään ja hänen pitäisi ymmärtää tuotetta myös loppukäyttäjän näkökulmasta. Tuoteomistajalla on hyvä olla myös riittävästi valtaa, sillä hän on vastuussa tuotteeseen liittyvistä päätöksistä, ja päätöksenteko usein edellyttää eri sidosryhmien näkökulmien huomioimista. Tuoteomistajalla täytyy myös olla riittävästi aikaa, sillä ilman aktiivista yhteistyötä tuotteen toutettavan kehitystiimin ja eri sidosryhmien kanssa, ei käyttäjilleen lisäarvoa tuottavan tuotteen toteuttaminen ole mahdollista.

Perinteisenen tuotekehitys ja Scrum

Tuoteomistaja vastaa tehtävistä, jotka perinteisesti ovat kuuluneet markkinointipäällikölle ja tuotepäällikölle. Tuoteomistajan pitää muun muassa ymmärtää markkinoita ja osata myös itse markkinoida, ylläpitää tuotteen tiekarttaa (road map) ja seurata tuotteen tuomia kumulatiivisia voittoja eri julkaisujen välillä. Suuremman kuvan ymmärtämisen lisäksi tuoteomistajan pitää kuitenkin pystyä kuvaamaan ja priorisoimaan tuotteen ominaisuuksia yksityiskohtaisemminkin ja keskustelemaan niistä kehitystiimin kanssa. Koska perinteisesti eri rooleille jakaantuneet tähtävät ovat nyt yhden ja saman henkilön vastuulla, vältytään tiedon siirtämiseltä eri yksiköiden välillä, jolloin syntyy vähemmän odottelua, viiveitä sekä väärinymmärryksiä että virheitä.

Sen lisäksi, että Scrumissa tuoteomistaja vastaa markkinointipäällikön ja tuotepäällikön tehtävistä,  kehitystiimi ottaa vastuun monista perinteisesti projektipäällikölle kuuluvista tehtävistä. Tiimi esimerkiksi tunnistaa itse sprintin tavoitteen sanelemat osatehtävät ja vastaa niiden työmäärien arvioinnista. Samoin tiimi itse hallinnoi tehtävien toteutusta ja toteutustapaa, aikataultusta ja allokointia sprintin aikana. Jos ongelmia tulee eteen, on tiimin itsensä, eikä siis projektipäällikön,  vastuulla puuttua niihin ja keksiä kuinka ne saadaan ratkaistua. Tiimi on siis itse vastuussa, että se tekee oikeita asioita oikeaan aikaan ja oikealla tavalla.