Case Ancit Oy: Projektinhallinnan digitalisointi tiiviillä, jatkuvaa kehitystyötä tekevällä tiimillä

Tämä luku kertoo projektityön digitalisoinnista jatkuvassa kehitystyössä, jossa tietyn asian kehittämiseen on dedikoitu tiimi, jota ei häiritä muilla toimeksiannoilla. Tämä on yleistä esimerkiksi IT-yrityksen ohjelmointitiimeilä, mutta samoja periaatteita voidaan hyvin noudattaa markkinointitiimeissä tai missä vaan tiiviisti yhdessä tekevässä tiimissä. Asiakkaan tai markkinan ääntä kuunteleva "product owner" pitää yllä priorisoitua listaa kehitysideoista, joiden toteuttamisesta olisi kaikkein eniten hyötyä yritykselle, ja tiimii paiskoo töitä valmiiksi tasaisella tahdilla ja sovituissa jaksoissa.

Lyhyt tarina Ancit Oy:sta

Ancit Oy teki aiemmin IT-järjestelmiä asiakkaille projektityönä, mutta löysi n. 10 vuoden taipaleen jälkeen oman tiensä tuotebisnekseen. Se kehitti selainkäyttöisen NettiSetti-verkkokauppatuotteen yhdelle avainkohderyhmistään, ja alkoi tekemään pitkäjänteistä tuotekehitystä tämän tuotteen parantamiseksi. Asian ympärille kerättiin "tuotetiimi", joka koostui neljästä ohjelmoijasta, yhdestä tiimin vetäjästä sekä product ownerista, joka sukkuloi asiakasrajapinnan, johdon ja tiimin välillä.

Tämän tiimin vastuulla oli vain ja ainoastaan kehittää NettiSettiä mahdollisimman napakalla vauhdilla paremmaksi, jotta siitä tulisi kolmessa vuodessa alansa markkinajohtaja Suomessa. Tiimi valitsi työmallikseen Scrumin, jonka soveltamisen aloittamisessa koko organisaatiolla oli aika reilusti uutta opeteltavaa. Enää näiden kehittäjien huoneisiin ei marssittukaan asiakkaalta tulleiden pikapyyntöjen kanssa, vaan "tuotetiimillä" oli työrauha sprinttiensä aikana. Konflikteiltakaan ei säästytty. Scrumin soveltamisessa korostuu sprinttirytmi, töiden hyvä suunnittelu ennalta sekä tiimin itseohjautuvuus. Katsotaan seuraavaksi, miten Ancit Oy kehitysprojektejaan digitalisoi.

Ancit Oy:n kehitystyössä korostuvat tehtävien ennakkovalmistelu, priorisointi sekä tasainen output

Scrumin avulla Ancit Oy on uskoo saavansa hyötyjä sekä tehokkaasta työtavasta että fokuksesta, joka tiimillä on nyt aivan eri tasolla kuin aiemmin. Uuden product ownerin avulla tiimille halutaan saada myös jatkuva asiakasyhteys, jotta kaikkein hyödyllisimmät tehtävät loputtomasta uusien ideoiden listasta pystyttäisiin löytämään. Tiimi mittaa tarkasti omaa "velocityään" ja on hyvin nopeasti Scrumin käyttöönottamisen jälkeen oppinut erittäin tarkaksi oman työkykynsä arvioinnissa.

Ancit:lla järjestelmällinen ja avoin työmalli sekä sopivan kattava asioiden kirjaaminen ylös nähdään tärkeinä keinoina jatkuvaan parantamiseen, jonka yritys on ilmoittanut julkisestikin yhdeksi ydinarvokseen.

Vinkki no 1: Muista 80/20 -sääntö

Tätä kutsutaan myös Pareto-periaatteeksi. Ideana on, että yleisesti 20% tekemästäsi työstä tuottaa 80% koko ponnistelusi hyödyistä. Kehitystyön priorisoinnin näkökulmasta tätä sääntöä voisi tulkita niin, että tiimin kannattaa keskittää fokusta niihin 20%:in tehtävistä, joilla on eniten merkitystä. Usein esimerkiksi hyvin äänekkäät asiakkaat voivat saada turhan paljon huomiota, vaikka heidän toivomansa ominaisuudet kiinnostaisivat lopulta hyvin pientä osaa esimerkiksi NettiSetin kaikista käyttäjistä.

Ancit Oy:llä lisäksi tietyt tehtävät merkitään "kriittisiksi" sprinttiä alustavan "Sprint Planning" -palaverin aikana. Nämä voivat olla esimerkiksi tehtäviä, jotka pystyy hoitamaan vain yksi tiimin jäsen, tai jotka pysäyttävät koko työn etenemisen myöhästyessään. Ne pyritään tekemään heti kun mahdollista töiden alettua. Jokaisella tiimin jäsenellä on vastuuta näiden kriittisten tehtävien tunnistamisesta.

Vinkki no 2: Panosta jatkuvaan kehittämiseen

Ketterät työmallit, kuten Scrum, Extreme Programming ja Kanban, pyrkivät järjestelmällisen ja avoimen työtavan kautta tuottamaan tiimille mahdollisuuden jatkuvaan kehittämiseen. Ne tekevät epäkohtia näkyviksi, esimerkiksi töiden kerääntyessä johonkin työvaiheeseen tai jonkin työtehtävän etenemisen seisahtuessa.

Tämä ajattelu toimii erittäin hyvin silloin, kun tiimi toimii jatkuvasti yhdessä ja sen tulee pystyä tuottamaan samaa, tehokasta ja korkealaatuista työjälkeä viikosta toiseen. Tällöin työt vaihtelevat ja muodostavat "projekteja", mutta tiimi ja työn luonne pääosin pysyvät samoina, joten jatkuvalla kehittämisellä tiimi voi viikosta toiseen pikkuhiljaa parantaa menoaan. Eikä aina tarvitse lähteä "nollista" liikkeelle, kuten perinteisemmissä projekteissa.

Näin Ancit Oy:n kehitystyötä ohjataan digityökaluin

1. Avoin kehitysbacklog, jonka kommentointiin koko organisaatio voi osallistua

Product owner hoitaa NettiSetti-kehityksen "product backlogia", joka on siis priorisoitu lista kehitysideoista, jotka tekisivät NettiSetistä vieläkin paremman. Osa näistä tulee kehittäjiltä, osa asiakaspalautteena, osa PO:n päästä, osa myynnistä ja niin edelleen.

Backlog on jaettu kategorioihin, joiden avulla kehityssprinttien aihepiirejä voidaan fokusoida. Ancit on huomannut, että esimerkiksi "Self-Service" -ominaisuuksiin keskittyvä sprintti saattaa olla huomattavan paljon tehokkaampi, kuin sekalainen kattaus erilaisia kehitysideoita. Product Backlog on julkisesti koko tiimin kommentoitavissa ja nähtävissä, vaikka product owner hoitaakin priorisoinnin.  

P.s. Yhdestä kortista backlogilla käytetään Scrumissa nimitystä PBI, eli Product Backlog Item.

2. Sprintin työt (PBIt) jaetaan omiksi, priorisoiduiksi työlistoikseen

Ancit käyttää 2-viikkoisia sprinttejä. Näiden alussa tiimi nappaa backlogin alusta X kpl PBI:tä, joiden tekemiseen sprintin aikana se sitoutuu. Näitä varten tehdään oma kansionsa, Sprint Backlog, sekä omat työlistansa. Tämä on tiimin yksityinen näkymä, jonka parissa se toimii seuraavat kaksi viikkoa. Työlistoille annetaan Sprint Planning -palaverissa annettujen kokoarvioiden perusteella myös tuntibudjetit, jonka osumista varsinaiseen tarvittavaan työhön verrataan myöhemmin.

Kun työt on valittu mukaan sprinttiin, niitä aletaan osittaa tarkemmin. Ne jaetaan tehtäviksi, jotka yhdettä muodostavat tämän PBI:n työlistan. Jokaiselle tehtävälle annetaan työarvoi - tässä vaiheessa jo tunteina eikä enää pisteinä (kuten Scrumissa aluksi). Avaintehtävät kohdistetaan jo tässä vaiheissa sopiville tekijöille; Ancitilla graafisesti osaavin tyyppi tekee monesti näkymiä ja kovin koodarivelho syvimpiä teknisiä kiemuroita. Avaintehtäviin voidaan myös kohdistaa alitehtäviksi tärkeimmät relevantit kohdat definition of donesta (valmiin määritelmä, jonka tiimi itselleen määrittelee Scrumissa laadun varmistamiseksi), jotta niiden toteutuslaatu olisi mahdollisimman hyvä.

Tässä toimintamallissa on se hyvä puoli, että töiden etenemistä ja tuntiarvioiden osuvuutta voidaan seurata todella selkeästi. Ancit pyrkii lisäksi siihen, että maksimissaan 2 PBI:tä on käynnissä samanaikaisesti. Kun tehtävät ovat selvissä omissa listoissaan, tämän havaitseminen on helpompaa. Kolmanteen siirrytään vasta, kun joku kahdesta ensimmäisestä on yhdessä hoidettu valmiiksi.

3. Tehtävien selkeä järjestys, kokoarviot ja vastuutus tiimin jäsenille

Tehtävistä ainoastaan kriittiset tehtävät, jotka ovat erityisen tärkeitä tai jotka vain yksi tiimin jäsen pystyy toteuttamaan, vastuutetaan suoraan tiimin jäsenille. Muiden työt jätetään vapaiksi, joten kukin tekijä voi siirtyä jonossa seuraavaan, kunhan hänen edellinen tehtävänsä on valmistunut. Kun kaikki ovat osallistuneet sprint planning -palaveriin, kaikkien pitäisi myös ymmärtää jokaisen tehtävän sisältö. Näin töiden eteneminen pysyy joustavana ja tiimin on helpompi reagoida myös niihin tilanteisiin, kun joku jäsen ei olekaan paikalla.

4. Tehdyn työajan kirjaaminen ja vertaaminen arvioihin

Ancitin omat kehittäjätkin tykkäävät ja arvostavat työajan raportointia, koska tuloksien avulla opitaan arvioimaan töitä vielä tarkemmin ja pystytään seuraamaan päivätasolla sprintin etenemistä. Jokainen voi kirjata tuntinsa suorittamiensa tehtävien oheen joka päivä. Näin voidaan tunnistaa järjestelmällisesti pieleen arvioitavia tehtäviä ja muita ongelmakohtia, joihin voidaan retrospective-palaverin yhteydessä hakea ratkaisuja.

Entäpä työskentely isommissa hankkeissa, jotka koostuvat useista aliprojekteista ja monista eri organisaatioista?

Isomman hankkeen koordinoinnissa projekti- tai hankepäällikön päivistä voi koostua viestinnästä ja ihmisten pitämisestä ajan tasalla; asioista, jotka sisäisessä kehitystiimissä ovat melkein itsestään selvyyksiä. Mennään nyt hajanaisemman projektitiimin maailmaan, jossa työ on hyvin erilaista.