Neljä perusasiaa hyvään ketterään toimintaan

Muutos helpottuu paljon, kun se voidaan perustaa tukeville peruspilareille. Ongelmien ratkominen uusilla toimintamalleilla, prosesseilla tai työkaluilla tuntuu tällaisiin parannushankkeisiin osallistuvista ihmisistä usein turhalta hukkatyöltä. Perusasioiden laittaminen kuntoon mahdollistaa tehokkaammat muutoshankkeet.

Ketteryyden neljä peruspilaria

Huomio pitää ensin kiinnittää näihin neljään asiaan. Vasta kun nämä ovat kunnossa, kannattaa edes harkita muiden asioiden kehittämistä.

Perusasia 1: Tuotevisio

Tuotevisio on tärkein neljästä peruspilarista. Visio on se iso tavoite, mitä kohti tuotetta ollaan viemässä. Se kuvaa yleensä tilannetta usean vuoden päässä. On eri tapoja kuvata tämä tuotteen tavoitetila. On tärkeää määritellä asiakasongelma, minkä tuote ratkaisee ja edut kilpailijoihin nähden.

Tuotevisio toimii tiimille pohjantähtenä, opastavana ajatuksena taivaanrannassa. Sitä kohti ollaan matkalla. Jokainen pieni työtehtävä vie tiimiä ja tuotetta kohti tätä visiota. Vastaan tulevissa päätöksentekotilanteissa itse kukin voi miettiä, mikä vaihtoehdoista vie kohti tavoitetta.

Vuosien päässä tulevaisuudessa oleva visio tuntuu kaukaiselta ja sitä pitääkin jatkuvasti palautella tiimin mieliin. Sitä voi pilkkoa myös pienempiin askelmiin – vuositavoitteisiin tai release-kohtaisiin visioihin. Asiakaskohderyhmä voi muuttua vuodesta tai releasesta toiseen. Kun release kohdistuu palvelemaan hyvin tiettyä asiakasryhmää, priorisointi helpottuu.

Jos tuotevisio puuttuu, tuoteomistajan on mahdotonta priorisoida backlogia ja kehittäjien on mahdotonta kehittää ratkaisua pienin päätöksin oikeaan suuntaan.

Perusasia 2: Tuoteomistaja ja tiimi

Tärkeysjärjestyksessä oleva backlog on ketteryyden ydin.

Tuoteomistaja määrittelee prioriteetin

Jos prioriteetteja ei määrittele kukaan, tai priorisointi tapahtuu kovaäänisin tai suuripalkkaisin päättää -periaatteella, ketterä tiimi ei voi tehdä töitään tehokkaasti. Tällaisesta nollapriorisoinnista seuraa myös se, että tiimi ei tunne oloaan turvalliseksi. On hankala tuntea työn iloa ja motivaatiota tärkeän asian tekemiseen, jos ei ole varma, että asia on oikeasti tärkeä.

Priorisointipäätökset ovat mahdollisia vain, jos ne ovat selkeästi yhden henkilön vastuulla. Tämän takia tuoteomistaja on niin tärkeä rooli.

Kun priorisointi on kunnossa, seuraavaksi tärkein asia on itseohjautuva ja toimintaan valtuutettu tiimi.

Itseohjautuva ja valtuutettu tiimi

Itseohjautuvuus tarkoittaa sitä, että kukaan ei jaa tehtäviä tai käske tekemään asioita, vaan tiimin jäsenet vapaaehtoisesti aloittavat uudet työt backlogin huipulta.

Tiimin jäsenet myös valvovat ja auttavat toinen toisiaan. Ketään ei jätetä yksin ongelmien kanssa. Jos joku jää jumiin, muut hidastavat ja tulevat auttamaan. Tiimi kokee vastuuta tehdä hyvää työtä, tarpeellisella laatutasolla.

Toimintaan valtuutus tarkoittaa sitä, että tiimi ottaa vallan tehdä työtä ja päätöksiä, jotka vievät tiimiä ja tuotetta kohti visiota. Pyydetään mieluummin anteeksi, kuin lupaa tehdä jotain. Jos törmätään ongelmiin, ne ratkaistaan.

Perusasia 3: Backlog

Nyt meillä on suunta, tärkeysjärjestys ja intoa puhkuvat tekijät. Seuraavaksi pitää varmistaa, että ymmärretään mitä ollaan tekemässä. Tämä tarkoittaa backlogin jalostamista ja siihen liittyviä käsitteitä Definition of Ready ja Definition of Done.

Backlogin jalostaminen

Viikoittain toistuva backlogin jalostustilaisuus auttaa tiimiä ymmärtämään backlogilla olevia asioita, ja ottamaan ne työn alle oikean kokoisina ja oikein määriteltyinä. Tunti viikossa on tähän hyvä aikainvestointi. Backlogin jalostustilaisuudessa tuoteomistaja ja tiimi keskustelevat tärkeimmistä seuraavista töistä, ymmärtävät miksi ne tarvitaan, ja mitä ne sisältävät. Keskustelu on avain – ilman sitä ei voida olla varmoja siitä, että ymmärretään tehtävät asiat samalla tavalla.

Definition of Done

Definition of Done (DoD) on tiimin sopimus siitä, milloin työn alla oleva asia voidaan katsoa valmiiksi. Se siis on kaikille backlogilla oleville asioille yhteinen. DoDin avulla kaikki tiimin jäsenet ymmärtävät mitä yleensä töille pitää tehdä.

DoDn avulla tehdään myös työmääräarviointi. Työmäärän arvioinnin perimmäisenä tarkoituksena on estää liian isojen ja epäselvien töiden aloittaminen kerralla. Sivutuotteena siitä saadaan ennustamista helpottavaa dataa (velocity).

[box] Ohjelmistokehityksessä esimerkki DoD voisi näyttää vaikka tältä:

• Koodi on versiohallinnassa
• Koodi läpäisee katselmuksen
• Koodi on testattu jonkun toisen kehittäjän toimesta
• Koodille on tehty tarpeelliset automaattitestit
• Tuoteomistaja on hyväksyntä-testannut toiminnon[/box]

Definition of Ready

Definition of Ready (DoR) on monille outo termi. Se tarkoittaa DoDin tapaan tiimin sopimusta. Nyt sovitaan siitä, millä tavalla määritelty työ on valmista aloitettavaksi. Sinäkään et syö raakaa lihaa, vaan paistat sen ensin. Vasta sitten se kelpaa syötäväksi. Definition of Ready tarkoittaa siis sitä, että pihvi on paistettu. Definition of Done on se, että se on syöty.

DoR kertoo siis tiimille sen, miten asiat pitää olla määritelty. Se estää sen, että kukaan ei ota liian isoa, tyhjää tai epäselvää asiaa työn alle.

Esimerkki DoR:

• Tehtävästä on keskusteltu backlogin jalostuksessa
• Tehtävässä on selkeä ratkaistava ongelma
• Asiakasarvoa on mietitty
• Tehtävälle on vähintään muutaman rivin kuvaus ja tarkentavat hyväksyntäkriteerit
• Ratkaisun rakentamiseen tarvittavat asiat on selvitetty ja ovat saatavilla
• Tehtävän koko on pienempi kuin sallittu yläraja (tiimikohtainen empiirinen arvo)

DoD ja DoR on helppo määritellä yhdessä tiimin kanssa. Se vaatii vaan noin tunnin kestävän työpajan. Backlogin jalostuskokoukseen käytetään säännöllisesti tunti viikossa

Nämä aikasijoitukset saadaan takaisin, kun tehty työ osuu maaliin paljon entistä suuremmalla tarkkuudella.

Perusasia 4: Palaute ja oppiminen

Nopea palaute

Kun työ on valmis, tärkeintä on varmistaa, että ongelma ratkaistiin oikealla tavalla. Pitää saada palautetta. Tämä onnistuu näyttämällä valmiiksi saatu työ sitä tarvitsevalle ihmiselle tai antamalla hänen kokeilla sitä. Jos tässä vaiheessa paljastuu, että tarvitseekin tehdä jotain muuta, voidaan korjaukset tehdä saman tien. Palautteen saamisessa tärkeää on, ettei odoteta liian pitkään.

Retrospektiivit säännöllisiksi

Tiimin pitää vielä miettiä, menikö kaikki hyvin, vai tehtäisiinkö seuraavalla kerralla jotain toisella tavalla. Tämä tehdään retrospektiivissa.

Kuten kehitysjonon jalostaminenkin, retrospektiivikäytännönkin pitää olla säännöllistä. Retroille riittää kerran kuussa tapahtuva mietintä. Tärkeää on paljastaa ongelmia, keskustella syvemmin jostain asiasta, miettiä sen juurisyitä ja sitten mahdollisia toimenpidevaihtoehtoja.

Retrospektiivit ovat ajanhukkaa, jos asioille ei tehdä mitään. Tiimi pitääkin valtuuttaa ja pakottaa tekemään parannustoimenpiteet ennen seuraavaa retrospektiiviä. Tiimi ei saa oppia tapaa, että sovitut toimenpiteet voidaan jättää tekemättä. Hyvä vinkki on nostaa sovitut toimenpiteet suoraan backlogin huipulle.

Visio – roolit – backlog – palaute

Lähde liikkeelle visiosta – anna tuotteelle selkeä tavoite. Seuraavaksi, valtuuta tiimi ja tuoteomistaja. Pidä huolta, että uskalletaan tehdä päätöksiä ja töitä. Avoimuus on tärkeää. Suunnitelmien, backlogin, tulosten ja parannuskohteiden on oltava julkisia.

Backlogin jalostamiseen käytetty aika ja energia on hyvä sijoitus. Tiimin sopimukset siitä, millaista työtä aloitetaan ja mitä sitten tehdään ovat olennaisia osia jalostamisessa.

Lopuksi – pakota tiimi ottamaan palautetta ja tekemään parannustoimenpiteitä.

Puutteet näissä asioissa johtavat kasvaviin ongelmiin myöhemmin. Jos taas nämä asiat saadaan ensin kuntoon, sitten voidaan lähteä rakentamaan tämän päälle mitä vaan.