Mitä tehdä, jos tiimin backlog on kokoelma henkilökohtaisia to do -listoja?
Onko tiimin backlog vain kokoelma ihmisten omia to do -listoja?
Monessa tiimissä on sellainen tilanne, että osa tiimin backlogilla olevista asioista on vain yhden henkilön tehtävissä. Toisissa tiimeissä tällaisia asioita on vain vähän, mutta joskus tilanne pääsee kärjistymään niin, että koko tiimin backlog on täynnä asioita, jotka vain yksi henkilö voi tehdä. Ja tämä puolestaan on hieman ongelmallinen asia!
Työryhmä – ei tiimi
Jos backlog on yhdistelmä yksittäisten henkilöiden to do -listoja, ei tällaista porukkaa oikein voi oikeaksi tiimiksi kutsua. Kyseessä on ennemminkin työryhmä tai pseudotiimi. Oikealla tiimillä on yhteisiä tavoitteita ja yhteinen tahto päästä tavoitteisiin yhteistyön avulla. Millaista yhteistyötä ryhmässä voi olla, jos kaikki tekeminen koostuu vain asioista, jotka ovat yksittäisen ihmisen työlistalla?
Jonoteoria ja tiimin backlog
Useimpia tiimin backlogeja ei voida käsitellä puhtaina “jonoina”, koska backlogilla olevat asiat on epätäydellinen kuvaus siitä, mitä tiimin täytyy oikeasti tehdä. Tärkeämpää on, että tiimi ja tuoteomistaja jatkuvasti haastavat, jalostavat ja kartoittavat sitä, mitä backlogilla pitäisi olla (varsinkin sen kärjessä). Tätä työtä ei ainakaan helpota, jos tiimi ja tuoteomistaja uskottelevat itselleen tekevänsä työtä yhden backlogin kanssa, kun oikeasti backlog koostuu “piilossa olevista” useiden eri ihmisten backlogeista.
Mitä haittaa aiheuttaa tällainen ”kokoelma-backlog”?
Mitä haittaa tällaisesta tilanteesta voi olla? Ainakin seuraavat haitat tulevat mieleen:
1. Refinement- tai groomaus-keskusteluissa voi olla hankala saada koko tiimiä kiinnostumaan keskusteltavista aiheista. Kun vain yksi ihminen voi oikeastaan kuvata ja keskustella asiasta, muille tulee helposti olo, että kysymykset ja kommentointi olisi ajanhukkaa. Todellista keskustelua ei saada helposti aikaan.
2. Motivaatio kirjoittaa tarinoita auki on vähäinen – kun se yksi ja ainoa ihminen, joka asian osaa tehdä, tietää mitä tehdä, miksi pitäisi ”hukata aikaa” kirjoittamalla se tarina backlogin kuvaukseen ja hyväksyntäkriteereihin? Tämä johtaa siihen, että on täysin mahdotonta kenenkään ottaa tehtäväkseen toisen asioita, edes opetellakseen tai haasteena.
3. Definition of Ready ja Definition of Done voi olla hankala sopia ja ylläpitää. Kun asiantuntija itse on ainoa, joka asiasta jotain ymmärtää, hän ei ehkä ole kovin vastaanottavainen, jos joku muu haastaa, että onko asia oikeasti valmis.
4. Työmääräarviointi on todella vaikeaa tehdä niin, että saataisiin monta arviota. Pitää luottaa vain yhteen arvioon, joka sitten saattaa johtaa liian nopeisiin arvioihin ja liian vähäiseen arviota seuranneeseen keskusteluun.
5. Tiimi ei voi tehdä aina tärkeintä asiaa. Vaikka toisella tiimin jäsenellä olisi aikaa, niin hän voi valita vain ”omia” tehtäviä backlogilta. Jos oikeasti tärkeät asiat ovat yhden ihmisen takana, vaikka muilla olisi aikaa auttaa, he eivät voi tehdä tärkeitä asioita, vaan tekevät vähemmän tärkeitä asioita. Tämä saattaa lisäksi johtaa siihen, että vähemmän tärkeiden asioiden tekeminen luo muutosten tai regression kautta vain hidastusta todella tärkeisiin asioihin.
6. Tiimiltä saattaa puuttua kokonaan paine ”mutual accountabilityyn” eli yhteinen toimittamisen henki. Miksi sellaista voisi syntyäkään? Jos toimitus on kiinni yhden ihmisen asioista, eivätkä muut voi tehdä mitään asian hyväksi, tiimille ei voi muodostua ”soudamme samaa venettä” -fiilistä.
Mikä neuvoksi?
Seuraavat toimenpiteet voivat auttaa, jos kokoelma-backlog vaivaa:
1. Vaihda Scrumista Kanbaniin. Scrumin perushyöty tulee juuri siitä, että tiimi kokee yhteistä tahtoa tehdä toimitus tiettyyn deadlineen mennessä. Koska tällainen yhteinen tahto on hankala muodostaa ylläolevista syistä, tiimin ilmapiiri ja sitä kautta suorituskyky voi parantua.
2. Määrittele mahdollisimman hyvin yhteiset tavoitteet ja tiimin tai työryhmän tarkoitus. Koska tiimin backlog koostuu yksittäisistä pienistä backlogeista, tuoteomistajan priorisoiva vaikutus on heikentynyt. Ekspertit joutuvat itsenäisemmin miettimään, mikä on oikea prioriteettijärjestys, ja mikä on oikea tehtävien sisältö. Hyvin selkeät yhteiset toimitustavoitteet, joita toistetaan säännöllisesti ja säädetään jatkuvasti, auttavat jokaista yksilöä muistamaan ja miettimään oman tekemisen prioriteetteja.
3. Kaikkien tiimien ei tarvitse olla ”oikeita tiimejä”. Jos näyttää siltä, että ei ole järkeä opetella toisten taitoja, voidaan ihan hyvin päättää olla omissa taitolokeroissamme. Tämä kannattaa sopia yhteisesti.
4. Ollaan uteliaita ja opitaan toisten taitoja. Jos näyttää siltä, että tiimissä olisi hyödyksi jakaa taitoja ja osaamista, sitten kannattaa aktiivisesti miettiä miten oppiminen järjestyisi. Tässä kannattaa joskus unohtaa tehokkuuden mantra. Antakaa joku helpompi tehtävä ”oppipojalle” ja mentoroikaa toisianne.
5. Muistakaa käyttäjähyöty. Vaikka refinement ja groomaus olisikin hassun tuntuista, kun vain yksi ihminen osaa toteutuksen taustat, niin voitte ihan hyvin keskustella enemmän user storyn käyttäjähyödystä ja miettiä hyväksyntäkriteereitä käyttäjän näkökulmasta.
Tiimin kehityskurvi – retrospektiivi
Kuten monet lukijat tietävät, retrospektiivit ovat mieliaiheeni. Jos haluatte keskustella retrossa tästä tämän blogin aihealueesta, siihen voisi sopia parhaiten Team Evolution Curve -retrospektiivi.
Retrospektiivien e-koulutus
Olen tehnyt retrospektiiveista nyt myös e-learning moduulin. Tässä noin 90 minuuttia kestävässä etäkoulutuksessa käydään retrospektiivien perusteet läpi. Koulutukseen liittyy myös erillinen ”retro-työkaluboksi”, jossa esittelen 35 omaa retrokeinosuosikkiani. Kysy koulutusta osoitteesta sales@contribyte.fi. Voimme tarjota sen joko yksittäiselle henkilölle, tiimille tai vaikka koko organisaatiollesi.
Toivottavasti näistä ajatuksista oli hyötyä, jos sinun tiimisi on tässä tilanteessa. Voit aina laittaa palautetta kirjoituksista suoraan minulle arto.kiiskinen@contribyte.fi.
Contribyte - Asiantuntijat ja yhteyshenkilöt
Contribyte - Muita referenssejä
Tilaaja suosittelee!
Contribyte - Muita bloggauksia
ite wikin yrityshaku »
Kaikki it-alan työpaikat »
ite wikin referenssihaku »
Kaikki it-alan tapahtumat »
ite wikin julkaisuhaku »
