Beta

Ahjo-järjestelmän kehitystyön työtavan muutos projektimuotoisesta ketterään

Tarpeen kuvaus

Ahjo on Helsingin kaupungin päätöksenteon ja asianhallinnan järjestelmä, jota käytetään kaikilla toimialoilla. Sen kehittäminen ja ylläpito on Tiedon ja Helsingin kaupungin yhteishanke, jota johdetaan kaupunginkanslian hallinto-osaston ja tietohallinnon yhteistyönä.

Ahjon kehitystapa on perinteisesti ollut projektimuotoista. Uusien ominaisuuksien kehittäminen määriteltiin erillisiksi kokonaisuuksiksi, jotka toteutettiin usein rinnakkain käynnissä olevina projekteina. Tässä työmallissa havaittiin ongelmalliseksi mm. hallinnoinnin ja työtavan monimutkaisuus sekä huono näkyvyys kehityksen tilaan ja kustannuksiin. Myös kehitystyön kokonaistehokkuutta haluttiin parantaa.

Valittu kehitystapa

Ahjo-kehityksessä päätettiin kokeilla ketterän kehittämisen työtapaa. Siirtymää pohjustettiin nykytilan kartoituksella, jossa yhteistyössä mallinnettiin nykyinen työtapa vahvuuksineen ja ongelmineen.

Ketterän tekemisen työtavaksi valittiin alun analyysin ja olemassa olevan osaamisen vuoksi Scrum. Uuteen työtapaan siirtymisen käytännön toimia pohjustettiin lyhyesti yhdessä eri osapuolien kanssa. Yleisenä ohjenuorana oli valmistella sen verran että muutos voidaan tehdä, aloittaa uudella mallilla mahdollisimman pian ja hioa tekemisen tapaa kertyneiden kokemuksien myötä.

Työtapamuutos koski Ahjoon teknistä toiminnallisuutta tekeviä. Perusylläpito on ainakin vielä tästä erillään. 

 

Tuotokset

Muutoksen tärkein tuotos on uusi yhteinen työtapa. Tämä pohjustettiin valmennuksin ja se kirjoitettiin auki yhteiseksi työtapasopimukseksi. Pohjana oli Scrum, tosin joitain yksityiskohtia hiottiin ja sovitettiin Ahjo-kehityksen tilanteeseen. Työtapasopimus on koko Ahjo-kehityksen nähtävillä yhteisessä Confluencessa.

 

Oleellinen elementti Scrumin käyttöönotossa ja toimivuudessa on jatkuva parantaminen. Työtavan kehitys tapahtuu sitä varten varatuissa toistuvissa retrospektiiveissä. Retrot ovat yleensä tiimikohtaisia, mutta välillä niitä järjestetään koko kehityksen laajuisina. Lisäksi työtapoja parannetaan tiimien yhteisessä viikottaisessa Scrum of Scrumsissa ja kompetenssiryhmille suunnatuissa tukivalmennuksissa.

 

Ahjo-kehityksessä oli aiemmin käytössä työnohjaukseen kaksi erillistä Jira-instanssia. Muutoksen myötä siirryttiin yhteen Jiraan, johon on pääsy kaikilla Ahjo-kehityksessä työskentelevillä ja joka sisältää tuotteen kehitysjonon ja kaikkien kehitystiimien työtilanteen. Tämä tuo yhteisen näkyvyyden kehitystyön tilaan ja helpottaa kommunikaatiota työnteon aikana.

 

Osana työtapamuutosta selkeytettiin myös Ahjon johtoryhmän ja ohjausryhmän vastuita ja työnjakoa. Johtoryhmä johtaa kehitystyötä ylemmällä tasolla, yhdessä toimialojen kanssa muodostetun Ahjon vision kautta. Ohjausryhmän rooli on tukea vision toteutusta ja erityisesti tuoteomistajien työtä.

 

Scrum työtapaan siirtymisen hyvät ja huonot puolet, opit ja seuraavat askeleet

Hyviä puolia uudessa työtavassa

  • Koko Ahjo-kehityksen näkyvyys työnteon tilaan ja kehitettävään järjestelmään kokonaisuutena on parantunut merkittävästi (yhteinen Jira-näkymä, suora säännöllinen kommunikaatio). Tämä on ollut erityisen arvokasta työnohjauksen ja tuoteomistajien työn kannalta, mutta auttaa myös kaikessa kehitystyöhön liittyvässä yhteistyössä.
  • Kommunikaatio kehityksen sisällä on parantunut kehitystyön kaikissa vaiheissa. Yhteisiä keskusteluja käydään mm. tuotteen työjonon työstöissä, sprinttien suunnitteluissa ja päivittäispalavereissa. Tämä on parantanut yhteisymmärrystä tehtävän työn vaatimuksista ja auttaa toteuttamaan asioita kerralla oikein.
  • Merkittävimpiä työtavallisia muutoksia oli siirtyminen organisaatiorajojen mukaisesta yksilökeskeisemmästä työstä läpileikkaavan kehitystyön vaatimaan tiimijakoon, suunnittelun määrämuotoistaminen ja rytmittäminen kolmen viikon sprintteihin sekä yhteisen näkymän luominen koko kehityksen työn tilaan. Nämä kaikki ovat käytössä ja hyviksi havaittuja muutoksia.
  • Kehitystyön kustannusten näkyvyys ja seurattavuus on parantunut merkittävästi.

 

Huonoja puolia ja kehitettäviä asioita

  • Scrum olettaa ja hyvin toimiakseen myös vaatii moniosaajia, joilla on mahdollisuus keskittyä oman tiiminsä työhön. Kattava monitaitoisuus laajan järjestelmän koko toimintaan rajatun kokoisessa tiimissä on merkittävä vaatimus. Tämän toteuttaminen ei ole helppoa, ja on vaikeuttanut Scrum-tiimin jouhevaa toimintaa.
  • Iso työtapamuutos vaatii osallistuvilta paljon huomiota ja energiaa uusien asioiden opetteluun, ja luo myös epävarmuutta tuttujen asioiden muuttuessa tuntemattomiksi. Tämä koskee myös Scrumiin siirtymistä. Samalla kehitystyön teho laskee hetkeksi kun aikaa ja energiaa kuluu uusien työtapojen sopimiseen ja opetteluun. Tämä on normaalia. Tämän viestimiseen ja siihen liittyvään odotusten asettamiseen olisi tässäkin muutostyössä pitänyt kiinnittää enemmän huomiota. Sillä olisi vähennetty osallisten stressaantumista muutostyön aikana.
  • Scrum määrittää monia yhteisiä tilaisuuksia, joilla on kullakin tarkoituksensa työn suunnittelun ja hallinnoinnin osalta. Näiden käyttöönoton yhteydessä ei ehkä kiinnitetty tarpeeksi huomiota olemassa olevien toistuvien tilaisuuksien tarpeellisuuden tarkistamiseen, jolloin osalla nämä ja muut kokoukset päättyivät haukkaamaan liian ison osan työajasta.
  • Ahjon sovellusalusta ei täysin tue ketterää kehittämistä. Varusohjelmistojen versionostot vievät liian paljon aikaa ja aiheuttavat pitkiä katkoksia asiakkaan hyväksymistestaukselle.  On aloitettu sovellusalustan kontituksen suunnittelu, tavoitteena saada rakennettua pilvipohjainen kontitettu sovellusalusta, mikä mahdollistaa nopeammat varusohjelmistojen versionnostot ja uusien Ahjo-versioiden käyttöönotot. Lisäksi kehitetään Ahjon testausautomaatiota ja julkaisuprosessia.

Päätelmät ja seuraavat askeleet

  • Scrumin käyttöönotossa liikkeelle lähtö kevyesti ja opetellen on monella tapaa hyvä. Muutoksen yksityiskohtien läpikäynti kaikkien osallistuvien kanssa ja heidän palautteensa huomiointi ei saa kuitenkaan jäädä liian kevyeksi. Ahjo-kehityksen työtapamuutoksessa näin kävi, ja se loi turhaan epäselvyyttä ja epävarmuutta tähän muutostilanteeseen.
  • Ketterille työtavoille on ominaista että ne nostavat esille aikaisempia työtavallisia epäkohtia jotka eivät ennen ole saaneet huomioita. Tämä on hyvä asia, koska huomion kautta ongelmat pystytään ratkomaan. Tämä voi kuitenkin olla osallisille kuluttavaa ja tätä työstöä on pystyttävä tukemaan. Tämän tyyppiset ongelmat voivat myös luoda tunteen ettei uusi työtapa sovi kyseiseen tilanteeseen, vaikka todelliset syyt ovat muualla.
  • Muutokseen sisältyy paljon kommunikoitavaa, ja kommunikaation määrän tarve vaihtelee myös organisaatioden välillä. Sopivan tason löytäminen voi olla hankalaa, mikä vaatii huomiota ja osallistujien kuuntelua.

Mukana olleet organisaatiot ja ihmiset

  • Ahjo-järjestelmän kehittäminen -tiimi, Helsingin kaupungin kanslia ja Tieto
  • Tietohallinto, Helsingin kaupunginkanslia
  • Menetelmäkonsultit, Codento
  • Lisätietoja: Ahjo-kehityksen vetäjä Susanna Mäkelä ja Ahjo-sovellusalustasta vastaava Yrjö Vartio.

Aiheeseen liittyvät muut esimerkit

Luonnos