Ketteryyden haaste tiimin työnjaossa

Tiimin sisäinen työnjako voi aiheuttaa ongelmia ketteryyden toteuttamisessa, jos yhteisen tekemisen sijaan jokainen haluaa keskittyä omaan nurkkaansa. Henri Laine pureutuu blogissamme ketteryyden haasteisiin tiimin työnjaon näkökulmasta.

[tl;dr]

Ketteryys ei ole helppoa ja tiimien työnjaossa siihen liittyy erityisiä ongelmia. Hyvänä vertauskuvana onnistuneelle sprintille otetulle työlle on Koiramäen tilan yhteinen puurokuppi, josta jokainen lusikoi. Se, mitä kuitenkin usein tapahtuu muistuttaa enemmän klassista kattausta, jossa sprintille otettu työ on jo valmiiksi jaettu kunkin kehittäjän omiin annoksiin. Tässä blogissa käsittelen näitä vertauksia, niihin liittyviä pyrkimyksiä ja Scrumin niihin liittyviin ongelmiin tarjoamia vastauksia.

[/tl;dr]Agile tai ketterä kehitys on ollut puheissa pitkään, suorastaan kyllästymiseen asti ja yksi jos toinenkin organisaatio kertoo tätä toimintatapaa harjoittavansa. Ketteristä menetelmistä Scrum lienee edelleen suosituin ja hyvästä syystä: Scrum-oppaassa selvästi argumentoidut arvot ja lähestymistavat pitävät niitä soveltavan kehitysorganisaation oikealla polulla ja tarjoavat selvyyttä ketterän ohjelmistokehityksen julistuksen tulkintaan. Evankeliointiin taipuvaiselle kehys on oiva opetustyökalu, johon organisaatiossa sovellettua ketterää toimintamallia voi myös mukavasti verrata.

Scrumin pahimpana vikana omassa työssäni näyttäytyy se, että siitä puhuessaan kuulostaa väistämättä hieman smurffilta. Kun huomaa, ettei lause "Scrummataan scrummimme kuntoon" kuulosta aivan mahdottomalta, joutuu helposti miettimään viestintästrategiaansa uusiksi. Scrumin oikeammista ongelmista huomattava osa on onneksi ratkottavissa johtamisen keinoin, mutta osa niistä kuuluu selvästi tiimeille.

Keskitytään oikeisiin ongelmiin

Ongelmien kohtaaminen tapahtuu scrumissa tyypillisesti retrospektiiveissä. Retrospektiiveissä tiimin on tarkoitus tarkastella omaa toimintaansa ja miettiä, miten se voisi tehdä asiat toisin tavalla, joka palvelee tiimin tavoitteita mahdollisimman hyvin. Kun tiimin toimintaympäristö on täynnä sellaisia ketteryyden ongelmia ja esteitä joihin tiimi ei kykene puuttumaan, retrospektiivi vaikeutuu selvästi. Tiimi päätyy keskittymään näihin ongelmiin ja unohtaa pureutua niihin, joihin voi vaikuttaa.

Scrummasterin onkin siis tärkeää myötävaikuttaa siihen, että hänen tiiminsä maailmassa tosiaan toteutuisi se klassikkorukous, jossa pyydetään korkeammalta tyyneyttä hyväksyä asiat, joita ei voida muuttaa, rohkeutta muuttaa se mikä voidaan ja viisautta erottaa nämä toisistaan. Järjestelmäkehityksen maailmassa on hyvin harvoja muuttamiskelvottomia asioita, mutta suuri osa tiimin toimintaympäristöön vaikuttavista asioista on tiimin ulkopuolisen organisaation käsissä. Retrospektiivissä tulee siis keskittyä siihen, minkä tiimi joko scrum- tai sitten kehitystiiminä voi muuttaa.

Ja tästä pääsemmekin varsinaiseen aiheeseemme, ongelmaan, joka nimenomaisesti on tiimin omissa käsissä. Ongelmaan, joka on siinä määrin yleinen, että sen agile coach tai scrummaster -roolissa oleva kohtaa melko varmasti melkein missä tahansa organisaatiossa. Ongelmaan, jonka kohtaaminen ja selättäminen on itse asiassa pirullisen vaikeaa.

Nimittäin tiimin työnjakoon silloin, kun tähdätään ketteryyteen.

Työskenneltäisiinkö tiiminä?

Yleensä ongelma alkaa näkyä siten, että jo sprint-suunnittelussa mietitään, mikä käyttäjätarina tai tehtävä tulee kenenkin kehittäjän tehtäväksi. Korostuneemmassa tapauksessa sitten, miten tuoda sprinttiin riittävästi tekemistä kullekin kehittäjälle.

Kuulostaako tämä tutulta? Mietitkö juuri, että eikö sen kuulukin näin mennä? Arvelet kenties, että ihannetilanteessahan sitten tiiminvetäjä tai scrummaster pystyy JIRAa vilkaisemalla toteamaan jokaiselle riittävän töitä? Arvasitkin varmasti minun esittävän tähän eriävän mielipiteen.

Scrum-oppaan mukaan kehitystiimi sitoutuu tiettyyn sprint-tavoitteeseen ja toteuttaa sprintin jonoon siirretyn kehityskohteen suorittamalla tiiminä sen edellyttämät tehtävät. Tiimi on määritelmällisesti joukko ihmisiä, jotka työskentelevät yhdessä yhteisen ja jaetun päämäärän saavuttamiseksi. Kehitystiimin pitäisi olla tiimi.

Jos käytämme ruokapöytävertausta, tiimin sprintille ottaman työn pitäisi olla yhteinen astia, josta kukin kehittäjistä syö omalla lusikallaan tai kiinalaisen keittiön tapaan kattaus yhteiseksi tarkoitettuja ruokia, joista kustakin jokainen saa osansa.

Tuo kuvatun kaltainen ongelmatilanne taas näyttäytyy klassisena kattauksena, jossa jokaiselle tuodaan sprintille oma erillinen annoksensa. Tässä tilanteessa päivittäispalavereista on suunnilleen yhtä paljon hyötyä kuin ruokapöytäkeskustelusta. Keskustelu on viihtyisää ajankulua, muttei vaikuta mitenkään työn varsinaiseen tekemiseen. Koska tehtävä on henkilökohtainen, ei muu tiimi myöskään osallistu sen suoritukseen. Kehittäjä voi saada työtovereiltaan apua ongelmatilanteen ratkomiseen, mutta tehtävä ei koskaan muutu yhteiseksi.

Tilanne on varsin ymmärrettävä varsinkin kun muistetaan, millaisia me kehittäjät olemme. Introvertit luonteenpiirteet ovat keskuudessamme selvästi ns. valtaväestöä yleisempiä ja aika iso osa meistä vihasi ryhmätöitä niin peruskoulussa kuin myöhemminkin. Ehkä tyypillisin valitus, jonka scrumista ja ketteryyden varsinaiseen soveltamiseen liittyen kehittäjän suusta kuulee, on näkemys kaiken ajan kulumisesta koodaamisesta puhumiseen varsinaisen kehitystyön sijasta. On paljon mukavampaa ottaa oma kupillinen tehtävää ja vetäytyä miettimään sitä kaikessa rauhassa, kuin työskennellä kaaosta luovassa ryhmätilanteessa.

Scrum auttaa, kolme paikkaa korjata ongelmaa

Miten ongelmaa sitten pitäisi lähestyä? Scrum tarjoaa tähän kehyksenä joitakin lähestymistapoja, mutta scrummasterilla kannattaa yleensä olla muutama scrumin ulkopuolinenkin työkalu asian edesauttamiseen. Olisi verrattain helppoa ruveta tässä käymään läpi tiimiä ympäröivään maailmaan kohdistuvia edellytyksiä, mutta silloin sorruttaisiin tässäkin blogissa juuri yllä kuvattuun oman ongelman välttelyyn. Olettakaamme siis lähtökohtana, että tiimillä on kaikki tiimityön edellytykset eli tiimin jäsenet saavat osallistua tiiminsä työhön koko työajallaan, heillä on kaikki se osaaminen, jota päämäärän saavuttaminen edellyttää ja tiimi on rakentamassa mielekästä tuotetta.

Ensinnä: miltä näyttää kehitysjono?

Usein kehitysjono muuttuu tehtäviksi, joista osa sopii paremmin yhdelle ja osa toiselle tiimin jäsenelle. Keskittyminen luiskahtaa tiimin tavoittelemasta arvosta siihen, miten se tekee työnsä ja tuo työ totisesti henkilöityy helposti. Scrum sinällään ei ota kantaa kehityskohteiden muotoon, mutta apua voidaan etsiä ketterän ohjelmistokehityksen julistuksesta. Jo ensimmäinen julistuksen takana olevista periaatteista –  "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software" – tarjoaa ratkaisun. Jotta tiimi voisi tosiaan pitää tätä korkeimpana prioriteettinaan, on sen ymmärrettävä mitä asiakas tarvitsee. Vaikka tähän on erilaisia keinoja, on suosituin kirjoittaa kehitysjonon kohteet käyttäjätarinoina, jotka suuntaavat näkökulman nimenomaisesti käyttäjän kokemaan hyötyyn.

Toiseksi: sprintin suunnittelu

Jos tuotteen kehitysjono on kunnossa, eikä jo itsessään ohjaa tiimiläisiä suorittamaan yhden miehen sankaritekoja, on seuraava scrumista löytyvä tarkastelukohde sprintin suunnittelu. Tätä kirjoittaessani olen juuri samana päivänä päätynyt taas katselemaan tiimiä, jonka suunnittelutilaisuus alkoi sillä, miten etsittiin Jukka-Pekalle, Harri-Matiakselle ja Maija-Leenalle kullekin omat tekemisensä, ja suunnittelun loppupuolella mietittiin, että olihan kaikille tarpeeksi. Tämä ei ole sprintin suunnittelun tavoite. Sprintin suunnittelun tulisi vastata kahteen kysymykseen. Ensinnäkin, mitä voimme toimittaa sprintissä syntyvässä inkrementissä* ja toiseksi, miten saamme tuon inkrementin tiiminä aikaiseksi.

Jotta molempiin kysymyksiin saataisiin vastattua, kannattaa käyttäjälle syntyvän arvon kautta määritellyt kehityskohteet jakaa tehtäviin. Tehtävinä näkyvät esimerkiksi käyttöliittymään, toiminnalliseen logiikkaan ja tietokannan rakenteeseen kohdistuvat muutokset, ja samoin tietokannan rakennetta muutettaessa, on saman tien määriteltävä tietokannassa asuvan datan migraatio uuteen versioon. Jos tehdään logiikkaa, on sen toiminnallisuus varmistettava eli toivottavasti samalla kirjoitetaan koodin yksikkötestit ja toiminnallisuuden varmistavat funktionaaliset testit. Jos DevOps-muutos on vielä vaiheessa, on inkrementti toki saatava myös vietyä asianmukaisiin ympäristöihin, jotka on myös joskus pystytettävä. Toiminnallisuudet edellyttävät kaiken edellä kuvatun ja edettäessä, kuten scrumissa on tarkoitettu, rakennetaan valittu toiminnallisuus porukalla julkaisukuntoon ensin ja mietitään vasta sitten seuraavan tekemistä.

Edellä kuvattu on usein vaikeaa. Kaiken tarvittavan työn purkaminen auki suunnittelussa ei ole erityisen helppoa tai mukavaa. Kehitystyö on lähtökohtaisesti kokeilevaa ja vaikka projektiajatteluun suuntautunut tuoteomistaja tai "scrummaster" toki helposti haluavat kattavan suunnitelman, ei sen muodostaminen tässä vaiheessa ole itsestäänselvyys. Tuollaisiin tilanteisiin sopivat kokeilut, testit ja muut spike-tyypin tutkimustehtävät erinomaisesti. Ne sijoittuvat osaksi toteutusta ja voidaan tehdä samaan aikaan, kun toiminnallisuudelle pohditaan testejä. Niiden kanssa on syytä harrastaa parityöskentelyä ja rajata käytettävä aika tiukasti (n < 3 päivää), jottei kehittäjänä päädy kiehtovan tutkimuskohteen keijukaiskehään.

Tehtävien suunnittelussa kannattaa myös yleensä miettiä miten toteutuksessa viestikapula voidaan tarpeen vaatiessa antaa tiimikaverin kantoon ja homma tulee silti tehdyksi. Tähän kannattaa pyrkiä. Extreme Coding -piireissä suosittu parikoodaus palvelee tässäkin erinomaisesti, joskin introvertimpi ihminen arvostaa enemmän lyhyitä itsekseen tehtäviä tehtäviä, joista palataan sitten etsimään yhdessä etenemissuuntaa pari kertaa päivässä. Tällaisessa toimintamallissa backendin, frontendin ja testien kirjoitus yhtä aikaa toimii varsin näppärästi, kunhan vain pidetään kiinni yhteisistä ja jaetuista käsitteistä ja rajapintasopimusta päivitetään tarpeen mukaan. Peruskysymyksiin scrumin sprintin suunnittelussa voidaan lisätä: olemmeko suunnitelleet tulevan sprintin yhdessä tehtäväksi ja voimmeko sitoutua siihen tiiminä, vaikka yksittäinen jäsenemme sairastuisi yllättäen.

Sprintin suunnittelu on epäilemättä keskeisimmässä roolissa pyrittäessä tiiminä siihen, että sprintin työt ovat yhteinen ja tiimin kaikkien jäsenten kesken jaettu kokonaisuus. Scrumista löytyy tämän toteutumisen seurantaan ja varmistamiseen vielä muitakin tapahtumia.

Ensimmäinen näistä on scrumin päivittäispalaveri (Daily). Scrumissa päivittäispalaveri on tarkoitettu kehitystiimille sprint-suunnitelman tarkistamiseen. Päivittäispalaverissa on helppo huomata, jos joku on päätynyt omimaan työn itselleen. Ikävimmin tuo yleensä ilmenee siten, että tiimijäsen kertoo "sen olevan ihan kohta valmis" päivä toisensa jälkeen ilman, että tiimin muut jäsenet voisivat osallistua ongelman ratkaisemiseen. Scrum ja scrumban onneksi tarjoavat tähän myös loogisen ratkaisun. Koska tiimi on sitoutunut sprintin tavoitteisiin yhdessä, se myös tavoittelee niitä yhdessä ja tuolloin on täysin hyväksyttyä ja toivottavaa edellyttää myös sen vetäytyvän jäsenen avaavan tilanteensa ja hyväksyvän muiden osallistumisen.

Kuten todettua, tämä voi olla alkuun introvertille kehittäjälle inhaa, mutta pilkkomalla tehtäviä pienemmiksi ja harjoittelemalla jakamista, käytäntö muuttuu luontevammaksi. Scrummasterin on tärkeää auttaa tiimiläisiä iloitsemaan yhteisistä onnistumisista, mutta kehittäjät itse ovat jakamisessa keskeisessä roolissa.

Kolmanneksi: retrospektiivi

Kolmas scrumin tarjoama tapahtuma työn jakamisen kehittämiseen on retrospektiivi. Retrospektiivejä on hyvä toteuttaa vaihtelevilla malleilla ja välillä jakaminen voi olla retron keskipisteenä. Malleista mm. appreciative retrospectiven pohjalta voidaan sovittaa tarkoitukseen soveltuva retro tutkimalla kysymystä, missä kollegat ovat kaikkein parhaimmillaan tuotekehityksessä. Tähän on helpointa vastata, kun tiimikaverien kanssa tehdään yhteistyötä. Samalla siinä (ainakin toivottavasti) käyvät ilmi myös tuotteen sisällä syntyneet guru-statukset. Hyvillä guruilla on kuitenkin yleensä myös opetuslapsia, joten tiimi voi miettiä myös mahdollisuuksia viisauden levittämiseen.

Scrumin ohella myös monet muut tiimityön käytännöt tarjoavat apua henkilöityvän työn ongelmiin. Tällaisia ovat pienikokoisina pidetyt commit-operaatiot, jotka yhdessä koodikatselmointikäytäntöjen kanssa edesauttavat tiedon jakamista ja koodipohjan yhteisomistajuutta. Kysymys on viime kädessä lähestymis- ja ajattelutavan valinnasta eli sinällään yksinkertaisista, mutta vaikeasti muutettavista asioista.

Kaikki yllä kuvatuista ongelmista ovat sellaisia, joiden kanssa Digian scrummasterit, agile coachit ja agilistit työskentelevät leipätyönään ja usein mielelläänkin. Jos siis rakas lukija, yrityksesi tai organisaatiosi on päättänyt tavoitella muutosta, pyrkiä irti perinteisestä projektiajattelusta ja hamuta kaikkea sitä hyvää ja kaunista, mitä ketteryydellä on tarjota, niin me autamme mielellämme. Voimme kulkea kanssanne niin ketterien tiimien päivittäisessä työssä, kuin johtoryhmänne kanssa raivatessanne menneisyyden esteitä, jos ketteryys teitä sattuu houkuttamaan. Edellytyksenä on kuitenkin se, että haluatte aidosti muuttaa toimintaanne. On rahan tuhlausta ostaa agile-valmennusta ja tukea silloin, kun haluaa pitää kiinni projektimaailmasta. Silloin, kun ketteryys ei tarkoita muuta kuin uusia nimilappuja vanhoille toiminnoille.

* Inkrementti on scrumin määritelmän mukaisesti tuotteen eheä ja julkaisukelpoinen versio.