Scrum Masterin ja Product Ownerin yhteistyö on ehdoton edellytys tehokkaalle tuotekehitykselle. Product Owner tarvitsee hyvän Scrum Masterin tuekseen, ja taas hyväkään Scrum Master ei voi auttaa tilannetta, jos Product Owner ei ole tilanteen tasalla. Rooleissa menestyminen vaatii kuitenkin sitä, että niistä keskustellaan, ja määritetään kuka vastaa mistä. Scrum guide sisältää perusteet tälle vastuunjaolle, ja siihen tutustuminen on pakollisia opintoja kaikille tuoteomistajille ja Scrum Mastereille!

Scrum Masterin ja Product Ownerin kultainen yhteistyö

Todella sulava yhteistyö tarvitsee lisäksi kahta muutakin asiaa: organisaation ja yksilöiden vastuukeskustelua. Tällä tarkoitan sitä, että porukassa määritellään, mitä meillä tarkoittaa Scrum Master ja mitä Product Owner. Kun roolien vastuut on selkeämmin määritelty, on yhteistyö paljon helpompaa. Organisaatiotasolla roolien vastuiden selventämiseen voi käyttää vaikka pelikirja-tyyppistä lähestymistapaa. Tämän keskustelun pohjaksi kannattaa tutustua mahdollisuuksiin, mitä vastuiden joukkoon voidaan kirjata.

Mitä Scrum Guide sanoo

Tässä blogissa halusin antaa eväitä ja ajatuksia tällaiseen rooli- ja vastuukeskusteluun. Ensin katsotaan tässä kirjoituksessa nimenomaan niitä asioita, mitä Scrum Master voi tehdä tuoteomistajan hyväksi ja työn helpottamiseksi. Seuraavissa blogeissa voidaan sitten katsoa asiaa toisesta näkökulmasta, eli mitä tuoteomistaja voi tukea tiimiä ja Scrum Masteria. Scrum Guide ottaa tähän mielestäni vähän yksipuolisen näkökulman.

Scrum Guide listaa seuraavat asiat, joissa Scrum Master voi auttaa tuoteomistajaa:

• Fasilitoida Scrumin eventtejä (jos tarvetta on)
• Ketteryyden puolestapuhuja tiimissä
• Varmistaa, että tuoteomistaja priorisoi backlogin business valuen mukaan
• Auttaa tiimiä ymmärtämään backlog refinementin arvon
• Parantaa tuotebacklogin hallinnan keinoja
• Varmistaa, että tiimi ymmärtää kehityksen tavoitteet ja scopen mahdollisimman hyvin

Huomaatko – kirjoitin listan käänteisessä järjestyksessä verrattuna Scrum Guideen. Käänteinen järjestys sen takia, koska minun mielestäni näistä asioista kaksi ensimmäistä, seremonioiden fasilitointi, ketteryyden profeettana oleminen ovat ”perinteisempiä” ja helpompia useille Scrum Mastereille ottaa omalle tontilleen. Kaikki loput ovat sitten asioita, jotka menevät useimmissa organisaatioissa kauemmas sitä kuvausta, millaista työtä Scrum Masterin on ajateltu tekevän. Kun näin on, on entistä tärkeämpää, että Scrum Master uskaltaa keskustella muiden kanssa näiden vastuualueiden hoidosta. On mielestäni myös muutamia muita vastuualueita, mistä Scrum Guide ei mainitse mitään, ja mitkä on hyvä tiedostaa.

Perinteiset vastuualueet: fasilitointi ja ketteryyden profeetta

Fasilitointi

Tämä on ehkä perinteisin ja helpoin asia ymmärtää. Useimmat Scrum Masterit tietävät, että heillä pitäisi olla vastuu siitä, että Scrumin kokoukset eli seremoniat, järjestetään. Scrum Guide tarkoittaa sanamuodollaan sitä, että Scrum Master ei välttämättä fasilitoi näitä tapahtumia, mutta vastaa siitä, että ne järjestetään. Eli, joku muu voi toimia fasilitaattorina. Tässä on yksi hyvä tilaisuus keskustelulle: Joitain seremonioita voi parhaiten itse asiassa fasilitoida tuoteomistaja! (esimerkiksi backlog refinement tai demo) Ja taas joitain voi fasilitoida joku tiimin jäsenistä (vaikkapa daily tai retrospektiivi).

Scrum Masterilla on siis tässä tapauksessa vastuu siitä, että kokousten järjestäjät löytyvät, ovat motivoituneita, ja osaavat hommansa. Usein vaikkapa kiertävä retrospektiivivuoro on hauska piristys muuten vähän tylsänkulahtaneeseen seremoniaan, mutta retrojen järjestäminen ei suju ihan ilman opettelua ja tiedonetsintää.

Hyvillä seremonioilla on valtava vaikutus tiimin tehoon ja tuottavuuteen, ja sen takia tämä on tärkein tapa, jolla Scrum Master voi tuoteomistajaa auttaa. Seremoniataitojen parantamiseen Contribytellä on tarjolla super-seremonia -työpajasarja, jossa jokaisen seremonian järjestämisen taitoja parannetaan. Kannattaa kysyä meiltä lisää, jos tämä kiinnostaa.

Vinkki: tutustu seremonioiden laadun parantamiseen!

Ketteryyden puolestapuhuja

Pelkkä fasilitointi ei riitä. Jonkun pitää myös valvoa, että tiimi noudattaa ketteryyden periaatteita. Esimerkiksi tarpeeksi usein tehtävää releasointia, tai definition of donea. Hurjan yleistä on se, että Scrum Master nähdään vain kokousten järjestäjänä. Mutta olisi todella hyödyllistä tiimille ja tuoteomistajalle, jos Scrum Master kokisi olevansa ketteryyden lähettiläs tiimille. Tämä voi tarkoittaa vaikka ihan perusasioiden seuraamista – toimiiko tiimi ketteryyden periaatteiden mukaan, tai onko toiminta Scrumin arvojen mukaista. Tällainen valvontatyö unohtuu helposti, mutta se on ehdottomasti Scrum Masterin ydinvastuita – sitä ei kukaan muu oikein voi tehdä.

Vinkki: varmista että perusasiat (definition of done ja seremoniat) ovat kunnossa. Koe olevasi ketteryyden valvoja. Pidä Scrumin arvot, pilarit ja agile manifesto mielessäsi.

Haastavammat vastuualueet: Backlogin refinement ja hallinta-apu tuoteomistajalle

Nyt mennään todella tärkeälle alueelle. Backlogin refinement ja hallinta ovat usein juuri niitä alueita, joilla parantamisella tiimin tehokkuus tehdä oikeita asioita paranee valtavasti.

Backlogin refinement

Kuten jo aikaisemmin sanoin, backlog refinement on seremonia, jossa Scrum Masterin ja Product Ownerin yhteistyö punnitaan eniten. Refinement on yksi tärkeimpiä seremonioita, koska se vaikuttaa eniten tiimin inputin laatuun, eli siihen, miten speksattuja työtehtäviä tiimi pääsee aloittamaan. Tarkka työnjako refinementissa on siis asia mistä Scrum Masterin ja tuoteomistajan kannattaa puhua. Backlog refinementista olen kirjoittanut paljon blogeja, katsokaapa vaikka tämä.

Tuoteomistajahan ei yksin voi refinementtia tehdä, vaan siihen vaaditaan motivoitunut tiimi. Hyvä refinement voi olla seurausta vaikkapa siitä, että tiimin ekspertit ovat tutkineet ja valmistelleet käsiteltäviä asioita jo ennalta. Ennakkovalmistelu on helpompaa, kun sen arvon ymmärtää. Tähän saatetaan tarvita kokeneen Scrum Masterin näkemystä. Sanontaa ”hyvin refinetettu on puoliksi tehty” ei kannata unohtaa.

Vinkki: juttele tuoteomistajan kanssa, mitä keinoja voisitte kokeilla refinementin tehostamiseksi. Kokeilkaa erilaisia lähestymistapoja.

Backlogin hallinta

Backlogin hallinnalla tarkoitetaan kaikkea backlogin ”housekeeping” tyylistä toimintaa. Roskan tunnistaminen ja siivous, puuttuvien tarinoiden tunnistaminen, epätarkkojen kuvausten ja otsikoinnin parantaminen, feasibility-tutkimuksia todennäköisesti vaativien tarinoiden skannaus, backlogin koon monitorointi… Scrum Master voi sopia tuoteomistajan kanssa, millä tavalla näiden asioiden vastuita voisi jakaa tuoteomistajan, Scrum Masterin ja myös itse tiimin kanssa. Jos kaikki jätetään tuoteomistajan harteille, se on pois siitä ajasta, mitä tuoteomistaja voi käyttää asiakas- ja stakeholder -kommunikaatioon.

Vinkki: juttele tuoteomistajan kanssa, millaista housekeepingiä backlog tarvitsee, ja miten voisit auttaa

Vaikeimmat vastuualueet: tuoteomistajan priorisoinnin haastaminen ja hankkeen tavoitteiden jalkautus

Nyt mennään alueelle, joka on useimmille Scrum Mastereille vaikea. Miksi se on niin vaikeaa? Itse näen niin, että Scrum Mastereille on usein helpompaa antaa muiden ihmisten organisaatiossa tehdä priorisointipäätökset, ja miettiä tavoitteita. Scrum Masterit ovat usein taustaltaan ohjelmistokehittäjiä, ja heille on lähempänä sydäntä itse se koodin luontiprosessi. Priorisointi, asiakasarvon miettiminen ja hankkeen tavoitteiden pohtiminen ovat monille uusia ja vieraita asioita.

Priorisoinnin haastaminen

Olisi kuitenkin todella tärkeää, että tuoteomistajan ja tuotepäällikön vastavoimana voisi olla joku taho, joka auttaa ja haastaa priorisointipäätöksissä. Ohjelmistokehityksessä, varsinkin markkinalähtöisessä sellaisessa, joudutaan aina tekemään arvon osalta arvauksia. On jatkuva riski siitä, että nämä arvaukset menevät liikaa tuoteomistajan oman mielipiteen mukaan. Osaako tuoteomistaja olla tarpeeksi objektiivinen? Scrum Masterin pitäisi luoda sellainen suhde tuoteomistajaan, että hän voi haastaa priorisointipäätöksiä tarpeen vaatiessa. Uskon, että usein riittää vain se, että tuo toisen mielipiteen, ja pysäyttää tuoteomistajan miettimään tarkemmin jotain, mikä saattaa olla menossa väärään prioriteettijärjestykseen.

Vinkki: mene rohkeasti mukaan priorisointikeskusteluihin, ja haasta päätöksiä faktoilla perustellen. Aina ei tarvitse saada edes vaikutusta, pelkkä keskustelussa mukanaolo parantaa priorisointia

Tavoitteiden jalkautus

Tavoitteiden jalkautus tiimille on tärkeää, koska ihmiset pitävät siitä, että heidän työllään on merkitys. Olisi tärkeää maadoittaa jokainen tehtävä asia ja työ siihen, mitä tuotteen tai hankkeen tavoitteissa lukee. Itseohjautuvuus paranee, kun jokainen tehtävä voidaan linkittää isompaan kuvaan. Scrum Masterilta tämä sujuu paremmin kuin tuoteomistajalta, koska Scrum Master on lähempänä tiimiä. Vielä tärkeämpää tämä on, jos tavoitteista vastaa tuotepäällikkö, joka ei ole ihan joka päivä tai edes joka viikko tiimin kanssa tekemisissä. Miksi tämä on sitten niin vaikeaa? Uskon, että tavoitteista puhuminen koetaan usein sellaiseksi, joka menee näiden ”tuotevastaavien” tontille.

Vinkki: printtaa ihan paperille tavoitteet, ja laita ne daily-huoneen seinälle. Pidä huoli, että tavoitteet vaihtuvat kuukausittain tai releasen mukaan.

Tärkeät asiat mitä Scrum Guide ei mainitse

Scrum guide jatkaa kertomalla millä tavalla Scrum Master auttaa dev tiimiä ja muuta organisaatiota. Osittain nämä asiat tukevat myös tuoteomistajaa, mutta otan tähän esiin muutaman asian, joista Scrum Guide ei oikeastaan mainitse mitään.

Auta tuoteomistajaa käyttämään riittävästi aikaa asiakas- ja stakeholder-kommunikaatioon

On yleinen haaste tuoteomistajilla, että aikaa ei ole tarpeeksi asiakaskommunikaatioon. Jos aikaa olisikin, joskus käy niin, ettei vaan huomaa tai muista käyttää sitä riittävästi. Scrum Masterina voit muistuttaa tuoteomistajaa keskusteluiden ja demojen tarpeellisuudesta.

Toisesta näkövinkkelistä – voit auttaa tuoteomistajaa ajan löytämisessä asiakaskommunikaatioon myös sillä tavalla, että otat jotain asioita hänen lautaseltaan pois, eli vapautat hänen agendaa. Tästä kannattaa puhua.

Auta tuoteomistajaa ottamaan riittävästi huomioon solution health -tarinat backlogilla

Ratkaisun terveyttä ylläpitävät tarinat backlogilla (käytännössä refaktorointi) jäävät usein organisaatioissa uusien featurejen jalkoihin. Tämä käy koska tuotehallinta on usein kovin äänekäs vaatimaan ja perustelemaan uusien feature bullet pointien tarvetta. Muista tämä – uudet featuret menevät entisten jatkoksi, ja pitkällä featurelistalla ei ole koskaan hurmattu asiakkaita. Pidä huoli siitä, että kaikki ymmärtävät mitä kamalaa tapahtuu, jos ratkaisun terveyttä laiminlyödään jatkuvasti. SAFen arkkitehtuuri runway on hauska konsepti sen muistamiseen, että ratkaisun terveydenhuolto on tarpeellista.

Auta tuoteomistajaa pitämällä silmällä tiimin hyvinvointia – fiilistä

Hyvinvoiva tiimi on tuottava! Scrum Masterina olet lähellä tiimiä, ja voit olla tiimifiiliksen sykkeellä koko ajan. Tunnista tilanteet, missä tiimi alkaa stressaantua. Keskustelkaa mitkä asiat stressaavat tiimiä. Ketteryyden perusperiaatteita on pitää jatkuvasti sopiva työtaakka. Nosta kissa pöydälle, jos tavoitteet ovat epärealistiset. Muista, että tuoteomistaja on hiukan kauempana tiimistä, eikä aina osaa tai huomaa tarkkailla samoja signaaleja. Älä oleta mitään, vaan ota asiat puheeksi.

Jos tiimi taas tarvitsee ”team buildingia”, ota asia puheeksi. Paras on jos tiimi itse osaa ylläpitää tiimihenkeä ja tehdä asioita yhdessä aika ajoin. Mutta jos tällainen itse-team-building puuttuu, sinun vastuullasi on se, että tiimi saa tarvitsemansa rakennuksen!

Scrum Masterin ja tuoteomistajan yhteistyön pitää toimia

Kuten yllä olevasta jo nähdään, on paljon asioita, missä Scrum Master voi auttaa tuoteomistajaa. Scrum Masterin ja Product Ownerin yhteistyö on niin tiivistä, että keskusteluja käydään varmasti monta kertaa päivässä. Hyvällä yhteistyöllä tiimi itseohjautuu Scrum Masterin kaitsennassa yhä tehokkaammin kohti oikeita päätöksiä, ja tuoteomistajalle jää aina vaan enemmän aikaa tärkeään kommunikaatiotyöhön. Tiimin ja tuotteen menestys (ja sen juhlistaminen, älä unohda!) synnyttää positiivisen kierteen. Tuntuuko tämä tavoittelemisen arvoiselta? Keskustelkaa keskenänne, miten vastuunjako menee tällä hetkellä, ja miten voitte kokeilla tehdä asioita jatkossa.

Haluatko oppia lisää Scrum Masterin roolista? Lataa tästä kattava oppaamme aiheesta!