Kulttuurimuutoksen myötä laadukkaampaa ohjelmistokehitystä

Suomalaista organisaatiokulttuuria tulisi kehittää

Suomalaiset ohjelmistoalan yritykset epäonnistuvat toistuvasti kehittäessään organisaatiokulttuuria, joka nostaisi meidät pois hiljaisen tiedon ja nurkkakuntaisuuden tilasta. Jo 150 kilometrin matka Tampereelta Helsinkiin on monesti ollut este yhteishengen muodostumiselle, tiedon kululle ja järkevien tiimien muodostamiselle. Toki tästä minulla on vain oma rajallinen kokemuspiirini. Sen ulkopuolella on varmasti sellaisiakin yrityksiä, joiden kulttuurissa vaalitaan peräänkuuluttamiani piirteitä.

Tässä kirjoituksessani keskityn DORA:n (DevOps Research and Assessment) julkaiseman State of DevOps -raporttiin. Raportissa kerrotaan organisaatioiden kulttuurin ja ohjelmistotiimien autonomisuuden vaikutuksista ohjelmistokehityksen nopeuteen ja laatuun. Erityinen painopiste on siinä, millaisia muutoksia autonomisuuden salliminen vaatii organisaatiolta.

Tutkimusta kulttuurin vaikutuksesta: autonomisuus lisää luottamusta

DORA julkaisee vuosittain State of DevOps -raportin, joka on pisimpään jatkunut akateeminen tutkimus ohjelmistoalasta ja alan organisaatioista. Yksi raportin keskeisiä aiheita on yritysten ja organisaatioiden ohjelmistokehitykseen liittyvä suorituskyky.

SDO-suorituskyky (Software Delivery and Operational) mittaa organisaatiota kahdella tavalla: 1) tiimien suorituskyky, johon kuuluu tiimin deployment -tiheys ja ohjelmistomuutosten läpimenoaika sekä 2) tuotteen stabiilius, jota mittaavat vikaantumisherkkyys, saatavuus ja ongelmien korjausnopeus.

Pelkkien metriikoiden lisäksi raportissa pyritään tunnistamaan erilaisia vaihtokauppoja, joita seuraa tiettyyn tehokkuuteen keskittymisestä. Kirjoituksen lopussa on linkki tähän raporttiin [1].

Vuoden 2018 raportissa painotetaan organisaatiokulttuuria ja sen vaikutusta SDO-suorituskykyyn. Osa löydöistä on jo alalla tunnettuja, joskaan ei silti aina hyödynnettyjä totuuksia Lean-tuotekehityksestä ja sen positiivisesta vaikutuksesta organisaation suorituskykyyn.

Eräs raportin keskeisistä havainnoista on se, että kun johtajat mahdollistavat tiimiensä autonomisuuden, seurauksena on tiimin jäsenten sisäinen luottamus ja tunne siitä, että heitä kuunnellaan. Luottamus kohdistuu nimenomaan siihen, että johtaja on rehellinen niin aikeiltaan kuin käytökseltään.

Tiimiläisten kuuntelu tai ylipäätään heidän “äänensä” kuvastavat kykyä sanoa asiat erityisesti konfliktitilanteissa. Tulosten mukaan ääni ja luottamus yhdessä vaikuttavat positiivisesti organisaatiokulttuuriin. Alla olevassa kuvassa on hahmoteltu nuolilla, kuinka eri tekijät vaikuttavat toisiinsa joko mahdollistamalla tai tukemalla toisiaan.

Kuvan Westrum-organisaatiokulttuuri on tutkijoiden käyttämä termi sellaisista kulttuurillisista seikoista, joiden he ovat havainneet tukevan organisaation ja ohjelmistokehityksen suorituskykyä. Tarkemmin Westrum-organisaatiokulttuurista voi lukea raportista.

Google havaitsi omassa 180 ohjelmistotiimin tutkimuksessaan [2] vastaavasti, että yksi viidestä tärkeimmästä korkeaa suorituskykyä ennustavasta tekijästä oli tiimin tuntema psykologinen turvallisuus. Psykologisella turvallisuudella tarkoitetaan sitä, että tiimin sisällä pystytään sanomaan asioita ääneen ja että epäonnistumisista ei rangaista. Googlen tulokset ovat identtisiä State of DevOps -raportin kanssa, joka toi esiin luottamuksen ja tiimiläisten äänen.

Autonomia tarvitsee johdon tukea ja vapautta

Tiimin autonomisuudella on tutkimuksen mukaan suora vaikutus SDO-suorituskykyyn. Lisäksi autonomisuus vaikuttaa epäsuorasti luomalla sisäisesti paremman organisaatiokulttuurin. Näistä syistä johtuen on mielestäni tärkeää ymmärtää, kuinka tiimien itsenäisyys voidaan mahdollistaa.

Jotta tiimit voivat tulla aidosti autonomisiksi, ne tarvitsevat tukea yrityksen johdolta. Autonomiselle tiimille pitää kertoa tavoitteet, mutta tiimin tulee selvittää itse, kuinka se pääsee parhaiten asetettuihin tavoitteisiin. Tiimille saa asettaa sääntöjä, muttei niin paljon, että niistä muodostuu esteitä työnteolle. Samalla tiimille pitää sallia sääntöjen muuttaminen, jos asetettuihin tavoitteisiin ei muuten päästä. Ja lopulta tiimille tulee antaa tilaa itse päättää ja priorisoida sitä tapaa, jolla loppukäyttäjälle luodaan paras mahdollinen lopputulos.

Poikkitoiminnallisuus on tiimin tärkein ominaisuus. Sen tulee pystyä kehittämään ohjelmistoa ilman toisten tiimien tukea. Jos kaikki tiimin toiminta vaatii jatkuvaa yhteistyötä yli tiimirajojen, syntyy odottelusta ja ylimääräisestä kommunikaatiosta ohjelmiston kehitystä hidastavaa kitkaa. Vuoden 2018 State of DevOps -raportissa tutkijat havaitsivat, että eliittitiimit olivat järjestäytyneet kaksi kertaa huonosti suoriutuvia tiimejä todennäköisemmin poikkitoiminnallisiksi.

Kun tiimit hajautetaan poikkitoiminnallisiksi, heijastuu muutos myös ohjelmiston arkkitehtuuriin. Conwayn laki sanoo, että organisaatiot suunnittelevat järjestelmiä, jotka heijastavat niiden sisäistä kommunikaatiorakennetta. Kun kommunikaatiorakenne muuttuu, muuttuu myös ohjelmiston arkkitehtuuri. Tämä mahdollistaa autonomisten tiimien tehokkaamman työskentelyn.

Organisaation IT:n pitää tukea liiketoimintaa

Pohjimmiltaan tässä muutoksessa on kyse organisaation liiketoiminnan ja IT:n linjausten yhdenmukaistamisesta. Aika harva organisaatio haluaa tietoisesti tuottaa asiakkailleen backendin, frontendin ja mobiiliapplikaation. Loppukäyttäjille tuotetaan ominaisuuksia ja toimintoja. On siis kaikkien edun mukaista, että on olemassa tiimejä, jotka vastaavat edellä mainituista arvoa tuottavista ominaisuuksista ja ottavat vastuun siitä, miten ne toimivat läpi koko teknologiapinon.

Hajautettu päätöksenteko tuo mukanaan omat ongelmansa. Jo pienissä suomalaisissa yrityksissä on kokemusteni mukaan hankala hallita tiimejä, jotka hajaantuvat esimerkiksi Helsingin ja Tampereen alueille. Suomalainen tapa päättää asioista kasvokkain johtaa helposti siihen, että päätökset tapahtuvat käytävillä. Näin työpaikan sijainti vaikuttaa mahdollisuuksiin osallistua päätöksentekoon.

Kun päätöksistä näkyvät vain ulospäin lopputulokset näy eivätkä niihin johtaneet kompromissit, on varmaa, että osa työntekijöistä tuntee olonsa ulkopuolisiksi. Tällainen tapa tehdä päätöksiä ei toimi silloin, kun päätöksenteko on hajautettu.

Case N26 Bank: päätöksenteon skaalautuvuus onnistuu myös kasvun yhteydessä

Olin taannoin kuuntelemassa N26 Bankin CTO Patrick Kuan esitystä siitä, kuinka yritys onnistui skaalaamaan arkkitehtuuria koskevaa päätöksentekoa samalla, kun yrityksen kasvu oli räjähdysmäistä. Kua kuvasi kasvun olevan raketin rakentamista samalla, kun raketti on jo laukaistu matkaan.

N26:n tarina on mielenkiintoinen yrityksen tunnistamista kipupisteistä johtuen. Kipupisteet ovat itseasiassa täysin samoja, joita autonomisista tiimeistä koostuva, tai sellaiseksi tavoitteleva, organisaatio joutuu kohtaamaan.

Yritys tunnisti neljä selkeää ongelmaa, jotka haittasivat kasvua ja tiimien työtä: 1) Liikaa läsnäoloa vaativia palavereja 2) Tiimit olivat hajautuneet maantieteellisesti 3) Tehdyistä päätöksistä kerrottiin vain tulokset 4) Mistään ei löytynyt tietoa tehtyjen päätösten taustoituksesta tai valinnoista.

Palaverikäytännöt aiheuttivat siis ongelmia monella rintamalla. Kun päätökset tapahtuvat kasvotusten palavereissa, ne, jotka eivät pääse paikalle, tuntevat jäävänsä ulkopuolisiksi. Kun päätöksistä ei jää muuta kuin tulokset, on vaikea niellä päätösten vaatimia kompromisseja eikä myöhemmin voida enää palata päätöksen taustoihin.

Kuinka siis ottaa huomioon jokaisen autonomisen tiimin tarve saada äänensä kuuluviin organisaatiossa silloin, kun päätökset koskevat jotain, millä on välitön vaikutus tiimin työskentelyyn? Miten mahdollistaa jokaiselle tunne osallisuudesta, jos tiimit on hajautettu poikkitoiminnallisiksi itsenäisiksi yksiköiksi useammalle paikkakunnalle tai eri maihin?

Menestystekijöinä läpinäkyvä hajautettu päätöksenteko ja avoimuus

N26 Bankissä palaverit korvattiin RFC-menettelyllä (Request for Comment), jossa päätöksestä tehtiin yrityksen sisällä julkinen RFC-dokumentti. Dokumentti oli jokaisen työntekijän luettavissa ja kommentoitavissa, jolloin kuka tahansa pääsi halutessaan osallistumaan tärkeään päätöksentekoon.

Samalla kaikista päätöksistä jäi automaattisesti dokumentti, jossa huonot ja hyvät puolet oli käyty läpi ja vaihtoehdot keskusteltu auki. Jos myöhemmin törmättiin johonkin ongelmaan, voitiin palata takaisin dokumenttiin ja todeta, että tämä ongelma olikin juuri se kompromissi, joka jouduttiin tekemään. Parhaimmillaan dokumentissa oli jo valmiiksi keinoja, joilla kompromissin ongelmia oli mahdollista lievittää.

RFC-prosessi kasvoi N26 Bankissa orgaanisesti eli sitä ei pakotettu yrityksen johdon toimesta. Vasta kun prosessi oli havaittu toimivaksi, sille luotiin yhdessä raamit – nämä raamitkin käsiteltiin yhtenä RFC:nä. Jokaista RFC:tä piti kommentoida ainakin yksi henkilö sellaisesta autonomisesta tiimistä, johon RFC:n työ vaikutti.

RFC:n lopputuleman jalkauttamista varten N26 Bankissa kasattiin erityinen työryhmä (Working Group). Siihen nimetyillä henkilöillä on lopulta mandaatti tehdä päätös tai ratkaista ongelma. Työryhmä ei ratkaise ongelmaa itsenäisesti, vaan sen tehtävänä on kuunnella ja haastatella kaikkia tarvittavia tahoja. Asiantunteva ja nopea päätös tehdään eri osapuolten kuuntelemisen jälkeen.

Kaikista suurimpia ja koko yritystä koskevia ongelmia varten N26 Bankilla on vielä kolmas menettely, Architecture Guild. Tähän kiltaan kuuluu osallistujia jokaisesta yrityksen eri osasta, joten sillä on kaikki päätöksentekoon tarvittava tieto. Kokoontumisia järjestetään kuitenkin vain silloin, kun on oikea tarve, sillä ne ovat organisaatiolle kalliita.

En väitä, että N26 pankin käyttämät keinot olisivat ratkaisu jokaisen ohjelmistotalon ongelmiin. Päinvastoin jokaisen organisaation tulee tunnistaa omat kipupisteensä ja löytää omat keinot niiden ratkaisemiseen. Olen kuitenkin varma siitä, että vanhanmallinen siiloihin perustuva tiimien organisointi on tulossa tiensä päähän.

Teemu Stenhammar
Chief Architect

 

[1] https://services.google.com/fh/files/misc/state-of-devops-2018.pdf

[2] https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/