Työhön käytetty aika ja työstä saadut tulokset
Ohjelmistotuotannossa, kuten muillakin tietotyön aloilla, ovat työhön käytetty aika ja työstä saadut tulokset kaksi täysin eri asiaa eivätkä korreloi keskenään lineaarisesti. Parhaatkaan ohjelmistotuotannon osaajat ja koodarigurut eivät saa sprinttejä ja projekteja aikataulussa maaliin jos ympäröivän organisaation kulttuuri ei tarjoa työrauhaa ja mahdollisuutta keskittyä työhön täysillä. Tässä kirjoituksessa nostan esiin muutaman havaitsemani alaa kiusaavan ongelman joihin olen reissuillani törmännyt, sekä niihin soveltuvat ratkaisut.
Tiimin ajankäyttö
Kun ohjelmistoja kehitetään ketterästi, on tiimi roolina keskeinen. Tiimin odotetaan saavan tietyt yhdessä asetetut tavoitteet tehtyä määräajassa, esimerkiksi kahden viikon syklissä, sprintissä. Työmääriä arvioidaan monin keinoin joista parhaat voivat olla hyvinkin tarkkoja ja paikkaansapitäviä. Miksi sitten sprintti epäonnistuu ajan loppuessa kesken jos työmääräarvio on ollut kohdallaan ja mitoitettu tiimin pääluvun mukaan?
Tiimiä saattaa hidastaa ympäröivän kulttuurin aiheuttama kuorma. Tätä kuormaa ovat esimerkiksivanhat projektit joihin tiimin jäsenten ekspertiisiä tarvitaan silloin tällöin ”ihan hetkeksi vain”. Tätä kuormaa ovat palaverit joihin tiimin jäseniä kutsutaan ilman kunnollista perustetta tai ilman, että tätä on huomioitu sprinttiä suunniteltaessa. Jos kulttuuri yrityksessä korostaa palaverien merkitystä, istuu pahimmillaan koko kehitystiimi pitkissä palavereissa kuunteluoppilaana ja poissa oikean työnsä ääreltä. Hidaste voi olla innokas myyntimies joka käy hakemassa teknistä näkemystä kokeneelta ohjelmistokehittäjältä tarjoustaan varten. Tämäkin voi olla hyväksyttävää, mutta se tulee huomioida tiimin kuormitusta laskiessa etukäteen. Mikä hyvänsä hidasteen luonne onkaan, on olennaista muistaa, että kehitystiimin tehtävä on saavuttaa sprintille asetettu tavoite. Kaikki muu tulee tämän jälkeen.
Myös tiimin sisäisiä häiriötekijöitä löytyy. Uuden jäsenen kouluttaminen tiimin tavoille tai projektin teknisiin yksityiskohtiin ottaa aikansa ja kannattaa huomioida tiimin nopeutta arvioitaessa hidastavana tekijänä eikä uutena käsiparina. Myös tiimin jäsenten väliset työrauhan pelisäännöt kannattaa tarkistaa. Jos kehittäjä on uppoutunut tekemiseensä, ei ole kohteliasta häiritä häntä jokaisella mieleen juolahtavalla asialla. Yhtenä toimivana pelisääntönä olemme käyttäneet sopimusta, jossa kuulokkeet päässä olevaa kehittäjää ei häiritä. Maalaisjärki tietenkin kaikessa mukana, jos talo on tulessa, voidaan säännöt unohtaa.Jos sprinttejä ei saada maaliin aikataulussa eikä syy tähän ole tiedossa, voidaan sopia tiimin kesken että jokainen kirjaa ylös yhden sprintin ajan kaikki keskeytykset ja sprintin ulkopuoliset työt.Nämä voidaan käydä sprintin jälkeen retrospektiivissä läpi ja sopia mitä asialle tehdään jatkossa. Hyvän Scrum Masterin tulisi tällaiset esteet taklata, mutta se voi edellyttää ympäröivän kulttuurin muuttamista mikä puolestaan tapahtuu hitaasti ja vaatii paljon vaivannäköä.
Time-boxing
Kun olemme saaneet tiimin keskeytykset taklattua pois, voimme keskittyä jäljelle jääneiden rituaalien ajankäyttöön. Hyvä palaveri on sellainen, missa keskustellaan niin pitkään kuin asiasta riittää puhuttavaa? Ei ole! Hyvä palaveri on sellainen, jolla on tavoite, alku ja loppu. Palaveri alkaa ajallaan ja palaverin aluksi kerrataan palaverin tavoite. Kun loppu saavutetaan, osallistujat vapautuvat muihin hommiin eikä tapaaminen jatku sen jälkeen. Jos tavoitteeseen ei päästy, on joko aikaa ollut liian vähän varattuna tai palaverissa on keskusteltu epäolennaisia asioita.
On hyvä käytäntö kerrata palaverin aluksi miksi olemme koolla ja mitä palaverin päätteeksi tulisi olla sovittuna tai käsiteltynä. On myös hyvä pohtia onko kaikkien paikallaolijoiden läsnäolo olennaista vai meneekö jonkun arvokas työaika edes osittain hukkaan.
Retrospektiivi on erinomainen esimerkki palaverista joka helposti venyy sovittua pidemmäksi. Tähän olen havainnut hyväksi seuraavan menetelmän (esimerkin retrospektiiville on varattu aikaa 45min):
- Kerrataan retrospektiivin tavoite ja tarkoitus (1 min)
- Listataan osallistujien kesken käsiteltäviä aiheita (3min)
- Priorisoidaan kolme tärkeintä aihetta (2min)
- Käsitellään aiheita alkaen tärkeimmästä (35min)
- Loppuyhteenveto ja sovitut toimenpiteet ja päätökset (4min)
Näin ollen jos aika loppuu, olemme saaneet käsiteltyä tärkeimmät asiat eikä niiden takia tarvitse venyttää palaveria. Jos käsittelemättä jääneet asiat ovat ajankohtaisia vielä seuraavalla kerralla, ne ehditään käsittelemään tuolloin. Hyvä Scrum Master pitää myös tiimin sisäiset rituaalit aisoissa ajankäytön osalta.
Miten kokeilen?
Tarkastele tiimisi toimintaa. Onko ilmapiiri tuottelias, keskustelua käydään aiheesta ja yhteistyö toimii, mutta vastapainona myös rauha tekemiseen löytyy. Pysyvätkö palaverit aikataulussa ja onko niiden määrä kohtuullinen? Onko tiimilläsi rauha keskittyä vain sprintin tavoitteen täyttämiseen? Retrospektiivi on oikea foorumi uusien pelisääntöjen sopimiselle ja testaamiselle.
Lue lisää
Tutustu pinjalaisten uratarinoihin
Katso avoimet työpaikkamme
