Tuoteomistajan tärkeimpiä tehtäviä on varmistaa, että tiimillä on fokus oikeissa asioissa
Ei ole tavatonta, että punaisen langan sijaan kehitystiimi lähteekin seuraamaan sinistä lankaa tai solmuun menneitä keltaista ja purppuraa lankaa. Kaikille on varmasti päässyt käymään näin. Tällöin on hyvä ottaa paussi ja tarkastella, että miksi fokus on kateissa ja mistä se löytyisi. Alla joitakin näkökulmia, joiden kautta tuoteomistaja voi lähestyä tilannetta.
Tuoteomistaja rajoittaa tehtävien asioiden määrää
Kuinka monta kokonaisuutta tai tehtävää tiimi työstää samalla kertaa? Tutkimukset osoittavat, että multitaskaaminen heikentää ihmisten tuottavuutta, ja tehtävien välillä hyppiminen lisää tehottomuuden lisäksi stressiä ja henkistä pahoinvointia.
Lisäksi monen asian tekeminen yhtä aikaa ei nopeuta asioiden saamista valmiiksi, vaan teemme vain enemmän potentiaalisesti happanevaa kehitystyötä varastoon, mitä emme pysty toimittamaan asiakkaille ja käyttäjille. Jos sen sijaan kehitystiimin fokus on saada vain yksi asian kerralla valmiiksi, niin arvon toimittaminen nopeutuu.
Ja vaikka yksilöt työskentelisivätkin vain yhden asian parissa, mutta tiimissä tehtäisiin useita eri asioita samaan aikaan, niin menetämme tiimityöskentelyn tuoman hyödyn.
Fokus siinä, mikä on tärkeintä suhteessa investointiin
Kuka määrittää backlogilla olevien tehtävien järjestyksen ja mihin dataan perustuen? Onko teillä arvioitu, kuinka paljon kukin tehtävä tuottaa arvoa ja kuinka ison siivun kehitystyöstä tehtävä nappaa? Ilman potentiaalisen arvon ja investoinnin suuruuden arvioimista, on hankala määrittää tehtävien ja ominaisuuksien tärkeysjärjestystä.
Tuoteomistaja leikkaa sprinttien hännät
Fokusta on vaikea pitää, jos aiemmat työt eivät valmistu suunnitellusti. Sprintistä toiseen mukana roikkuvat tehtävät tekevät ennustamisesta mahdotonta mutta myös sotkevat tiimin keskittymistä olennaisen tekemiseen.
Jos häntiä tuppaa jäämään sprintin lopuksi, niin hyvä käytäntö on kriittisesti arvioida sprint planningissä niiden tarpeellisuutta. Jo käytettyjen työtuntien perään ei kannata itkeä. Tärkeämpää on miten tiimin tulevan työajan voi parhaiten hyödyntää.
Toinen hyvä käytäntö on panostaa hieman lisää backlogin refinementiin, jolloin häntiä pystyy taklaamaan jo etukäteen. Kun tehtävät on valmiiksi pilkottu pieniksi, ja tiimillä on selkeä käsitys tehtävien tavoitteista, niin työt tulevat todennäköisemmin valmiiksi suunnitellusti aikana.
Tuoteomistaja tietää, mitä tiimi tekee
Yllätytkö sprintti toisensa perään asioista, joita tiimi dailyissä tai katselmoinneissa kertoo tehneensä? Onko yhtäkkiä valmistunutkin jotain, mitä ette planningissä suunnitelleet tekevänne? Jos näin on, niin tilanne on huolestuttava.
Tuoteomistajan tehtävänä on päättää, mitä tehdään. Tiimin tehtävänä on päättää, miten tehdään. Jos tiimi ottaa tehtäviä tekoon sprinttisuunnitelman ohi, niin asiaan tulee puuttua pikimmiten. Oikea paikka asian käsittelylle on retrospektiivi. Ja selvittelyä ei kannata aloittaa syyttelyllä. Tarkoituksena on saada selville, että miksi näin on käynyt ja sopia yhdessä, miten jatkossa tältä vältyttäisiin.
Tuoteomistaja pitää backlogin maltillisena
Pursuaako backlog yli äyräiden? Onko suurin osa backlogin tehtävistä yli vuosi sitten luotuja? Backlogilla on turha roikottaa kuukausien tai vuosien edestä tekemistä. Liian pitkä backlog on turhaa kohinaa, mikä sotkee keskittymistä ja oikeasti tärkeimpien asioiden tunnistamista. Ja onhan satojen tehtävien hallintakin haastavampaa kuin muutaman kymmenen.
Helpointa on tylysti poistaa massana ikivanhat tehtävät. Jos niihin ei olla tartuttu vuoteen, niin tartutataanko niihin seuraavanakaan vuotena? Ja jos poistaminen ahdistaa, niin aina voi luoda oman backlogin, jonne voi ottaa käsittelyyn potentiaaliset tehtävät ja jättää varsinaiselle backlogille ainoastaan lähisprinttien kannalta oleelliset tehtävät, jolloin kehitystiimille lähitulevaisuuden ja tekemisen tavoite on selkeämpää.
Ja muista, ettei mahdollisesti kuukausien päästä tehtävien töiden määrittämiseen kannata käyttää vielä aikaa. Mitä myöhemmin päätökset tehdään, sitä enemmän ymmärrystä ja tietoa päätöstä tehtäessä on. Ja mitä myöhemmin määrittelet tehtävät tarkemmin, niin sitä epätodennäköisempää on, että tekisit turhaa työtä, jota ei koskaan tulla hyödyntämään. Muutamassa kuukaudessa tekemisen prioriteetit voivat muuttua, jolloin backlogin kärkeen nouseekin ihan uusia tehtäviä.
Tekninen velka ei ole kirosana
Jos tuotekehitystä on tehty yhtään pidempään, niin teknistä velkaa on kertynyt sadan prosentin varmuudella. On se sitten tiedossa tai piilevää.
Vaikka teknisen velan purkamiseen ja ylläpitoon liittyvät tehtävät kuten bugikorjaukset ovat poikkeaminen varsinaisen kehityksen fokuksesta, niin hyvä tuoteomistaja muistaa allokoida näihin työaikaa joka sprintissä. Mikäli näin ei tee, niin joko kertarysäyksellä tai hiljakseltaan kehitystyö hidastuu ja vaikeutuu. Tällöin edessä onkin sitten suuremmat talkoot, eikä varsinainen kehitystyö ei edisty.
Uskalla tehdä poikkeuksia
Sääntöihin löytyy aina poikkeuksia. Joskus sen merkityksettömän, mutta kehittäjän mieltä kiusanneen tehtävän nappaaminen backlogin hänniltä voi olla perusteltua. Päivän loppupuolella voi olla paikallaan tehdä jokin pieni rästihomma uuden isohkon tehtävän aloittamisen sijaan. Tai jos aivosolmu estää etenemisen, niin tuore näkökulma uuden tehtävän parissa voi laukaista tilanteen. Mutta nämäkin toki pitää olla priorisoituja ja esipureskeltuja töitä, eikä täysin puskista tulevia pikku yllätyksiä, joissa meneekin sitten puoli sprinttiä.
Toivottavasti näiden vinkkien avulla kehitystiiminne fokus ja oikean langan pää taas löytyvät. Lisää hyviä työkaluja löytyy myös koulutuksistamme.