Miten ketteryyttä johdetaan organisaatiossa jossa on monenlaisia toimintoja?

Moni organisaatio pohdiskelee, miten ketteröittämiseen kannattaisi suhtautua silloin kun on monia erityyppisiä toimintoja. On helppo tajuta, miten ketteryyttä skaalataan kun kyse on tuotekehityksestä ja esimerkiksi moni kehitystiimi työskentelee saman tuotteen kimpussa. Mutta mitenkäs kun ketteröitettävänä olisi digipalvelukehitysporukan lisäksi myös HR, markkinointi ja tikettipohjalta toimiva IT-tuki?

Tiimitaso: Scrum vai kanban? - tiimin tekemiset ratkaisevat

Kun tietylle tiimille lähdetään valitsemaan ketterää menetelmää, suosituimmat vaihtoehdot ovat yleensä scrum ja kanban. (Jälkimmäisellä ei tässä yhteydessä tarkoiteta pelkkää tehtävätaulua vaan koko kanban-menetelmää, ks. esim. https://www.lekman.fi/post/mika-ihmeen-kanban) Molemmat ovat hyviä vaihtoehtoja ja laajasti tuettuja ja osattuja, joten apua on helppo tarvittaessa saada. Scrum ja kanban sopivat kuitenkin keskenään eri tarkoituksiin. 

Scrum on hyvä valinta kohtuullisen isoille tiimeille (enemmän kuin 3 henkilöä), joilla on työn alla selkeä, suunniteltu kehityskokonaisuus joka vie ainakin osalla porukasta 100 prosenttia työajasta. Scrumissa on pyritty varmistamaan tiimin riittävä oppiminen ja havainnointi kiihkeätahtisessa kehitysympäristössä. Niinpä jos työtä tehdään ohuella kaistalla tai tekijöitä on vähän, parempi vaihtoehto on kanban.

Kanbanissa sääntöjä on vähemmän, mutta se tuo mukavasti läpinäkyvyyttä ja kehittymisen tuntua kaoottisiinkin työympäristöihin, jollaisia esimerkiksi henkilöstohallinnon tai markkinoinnin reaktiiviset ympäristöt monesti ovat. Sen myötä tekijät yleensä kokevat saavansa paremman hallinnan tunteen töiden kokonaisuuteen ja selkeämmän tunnun etenemisestä, jolloin työtyytyväisyys yleensä paranee. Tässä IT-tuet ovat monesti näyttäneet suuntaa.

On myös tiimejä, joille ei käy kumpikaan vaan perinteinen “suunnittele - toteuta” -malli on etenemiseen paras. Tällaisia voivat olla esimerkiksi vakioitujen tuotteiden käyttöönottotiimit. Näissäkin ympäristöissä voidaan kuitenkin tarkistaa, hyödyttäisiinkö kuitenkin ketteryyden (tai minkä tahansa hyvän projektinjohdon) periaatteiden paremmasta noudattamisesta. Katselmoidaanhan syntyviä tuloksia usein jotta saadaan palautetta ja lisäymmärrystä? Saavathan tekijät vaikuttaa käytännön työtapoihin ettei päädytä tekemään typeryyksiä? Kokeillaanhan silloin ensin pienellä otoksella jos jonkin ratkaisun toimivuudesta ei olla vielä varmoja?

Suurin osa ketterän organisaation tiimeistä kuitenkin yleeensä löytää sopivan toimintatapansa scrum - kanban -akselilta.

Tiimitaso: Työtapasopimukset selväksi

Mihin työtapaan sitten kussakin tiimissä päädytäänkin, on oleellista että kaikki ymmärtävät sen kohtuullisen samalla tavalla. Tarvitaan siis työtapasopimus.

Scrumin ymmärtämisen suhteen ongelmia tuottaa yleensä, että se päivittyy säännöllisesti ja siitä puhutaan sekaisin sekä suomeksi että englanniksi. Kahdella tiimin jäsenellä voi olla keskenään täysin erilainen käsitys esim. siitä, mitä Scrum Masterin tehtävään kuuluu: toinen ajattelee vuoden 2007 tapaan että kysymys on lähinnä rituaaleja pyörittävästä fasilitaattorista, mutta vuoden 2020 päivityksen lukenut tietää, että kyse on jatkuvan parantamisen varmistajasta, esteiden ratkojasta ja koko organisaation ketteryyden edistäjästä.

Kanbanissa ongelmana taas on monesti, että menetelmä ymmärretään liian suppeasti pelkkään tehtävätaulun käyttöön viittaavana.

Jos eri käsityksiä ei pureta auki rauhallisessa keskustelussa, ei koskaan saada tietää mitä juuri tässä tiimissä yhdessä nimetyltä työtavalta odotetaan. Mitkä esimerkiksi tarkkaan ottaen ovat meillä tuoteomistajan tehtävät ja missä muodossa haluamme tehtävänannot ympäröivältä organisaatiolta?

On siis tärkeää että kaikilla ketterän organisaation tiimeillä on työtapasopimus.

Tiimitaso: Jatkuva parantaminen on ketteryyden perusta

Tiimikohtaisesta menetelmästä riippumatta on oleellista, että kaikissa tiimeissä toimintatapoja kehitetään aidosti eteenpäin, edes joskus. Klassikko-ongelma on, että tiimissä pyöritetään rutiininomaisesti esimerkiksi scrumin retrospektiivejä, mutta kukaan ei vastaa löydettyjen haasteiden ja niihin ideoitujen ratkaisujen eteenpäin viemisestä. Silloin kokoonnutaan helposti toistelemaan samoja haasteita kuukaudesta toiseen, jolloin retroilu muuttuu korvaamattomasta jatkuvan parantamisen työkalusta piinaavaksi teatteriksi.

Sekä scrumissa että kanbanissa on siis ensiarvoisen tärkeää, että toimintatapaa arvioidaan säännöllisesti ja että arviointi muuttuu konkreettisiksi kokeiluideoiksi, jonka tuloksiin myös palataan. Myös perinteisissä projekteissa retroilulla on vissi paikkansa - edes kerran puolessa vuodessa.

Jatkuva parantaminen on ketteryyden perusta siinä mielessä, että jos toimintatapoja ei säännöllisesti tarkastella ja paranneta, ketteryys eli oppimisen hyödyntäminen tekemisen aikana jää vain tekemisen sisällön tasolle eikä ulotu itse tekemiseen.

Ilman tiimien jatkuvan parantamisen mekanismia ei siis voida puhua ketterästä organisaatiosta.

Apua tiimeille: Osaajaverkostot

Jotta tiimien osaaminen kehittyy suotuisaan suuntaan ja tiimien osaajien ketteryystaidot menevät eteenpäin, tarvitaan jokin tiimejä ylittävä tapa varmistaa että opit ja parhaat käytännöt leviävät. Tähän ketterien organisaatioiden ratkaisuksi on vakiintunut osaajaverkostot, killat tai toisella kotimaisella community of practicet.

Tyypillisimpiä rooleja joille ketterissä organisaatioissa perustetaan verkostoja ovat tuoteomistajat ja Scrum Masterit tai sisäiset ketteryysvalmentajat. Yhtä lailla näkee kuitenkin myös erikoistuneempien ammattiroolien verkostoja jos ne ovat organisaatiossa yleisiä (esim. käyttökokemusihmiset tai arkkitehdit), tai yleisiä ketteryyspohdintojen jakofoorumeita kuten ketterän tietotyön tai ketterän johtamisen verkostot. Muutosjohtajat neuvovat laittamaan tukea sinne missä tuntuu olevan energiaa, ja se on osaajaverkostojen suhteen erityisen hyvä neuvo.

Läpinäkyvyys: Kehitysaihioiden priorisointi

Taitavimmatkaan osaajat eivät kuitenkaan pysty ihmeisiin edes parhaimmalla osaamisen kehittymisellä, ellei ole selvää mitä pitäisi tehdä ja minkä verran mihinkin on tarkoitus panostaa. Puuttuvat tai epäselvät tavoitteet ja priorisoinnit ovat ketterien organisaatioiden tiimien ehkäpä yleisimmin esiin tuoma murheenaihe.

Ratkaisun tekniseen toteutukseen on monia vaihtoehtoja, mutta ydin on aina sama:
Tavalla tai toisella organisaation keskeisten päätöksentekijöiden on kokoonnuttava säännöllisesti laittamaan käynnissä olevat kehitysaihiot mieluiten absoluuttiseen prioriteettijärjestykseen. Esim. “tänä vuonna sähköisen asioinnin kehittäminen on meille tärkeämpää kuin asiakkuudenhallintajärjestelmän, ja CRM taas on tärkeämpi kuin tiketinhallintajärjestelmä”. Pelkät prioriteettiluokitukset eivät usein auta, koska kaikki kehitysaihiot tapaavat päätyä 1- tai 2-kategoriaan.

Syy siihen että tätä tiimien kiihkeästi tarvitsemaa keskustelua ei kaikissa paikoissa käydä, on että se on valmisteltava ja fasilitoitava. Jotta se onnistuisi, tarvitaan oikea halu päästä yhteisymmärrykseen siitä mikä on organisaatiolle kokonaisuutena oikeasti tärkeintä. Ja jotta keskustelussa olisi järkeä, kehitysaihioille tarvitaan yhteismitalliset selvitykset niiden vaikutuksesta liiketoimintaan sekä data niihin liittyvästä asiakas- tai käyttäjätarpeesta.

Mutta nuo yhteismitalliset kuvaustavat ovat täysin järjestettävissä, ja tämän jälkeen keskustelulle tarvitaankin enää fasilitaattori ja mahdollisesti työkalu jossa priorisointi- ja hanketietoa jatkossa säilytetään.

Moni ketterä organisaatio tekee hankeaihiopriorisointia onnistuneesti jo nyt, ja heidän tiimeillään on muita vähemmän harmaita hiuksia.

Läpinäkyvyys: Tavoiteohjaus ja tiekartta

Kun panostusten keskinäiset prioriteetit ovat selvillä, tarvitaan tiimeille enää kirkas tavoite jota kohti työskennellä sekä tiekartta sitä kohti. Ketterässä johtamisessa ajatellaan että tiimejä ohjataan mieluummin tavoitteilla kuin kertomalla, mitä toimenpiteitä heidän pitäisi tehdä. Parhaat tavoitteet ovat konkreettisia indikaattoreita innostavasta tulevaisuudesta: Jos asiakastyytyväisyytemme tämän digitaalisen tuotteen suhteen on puolitoistakertaistunut, olette onnistuneet. Ja hyvässä tapauksessa ne on määritelty yhdessä, kuten muodikkaassa OKR-ajattelussa.

Kun tavoite on selvillä ja konkretisoitu, tiimin on mahdollista piirtää tiekartta siitä, millaisilla panostuksilla he aikovat sinne päästä. Tuotekehitystiimeissä tiekartalta löytyy konkreettisia panostuksia asiakkaiden ongelmien ratkaisuun, reaktiivisemmissa tehtävätiimeissä enemmän vuosikelloasioita ja toiminnan kehittämisen panostuksia. Kummassakin tapauksessa kokonaisuus on kuitenkin tiekartan kanssa paljon helpompi hahmottaa.

Modern agile ja muut tiivistykset auttavat summaamaan

Modern agile (ks. kuva yllä) on yksi versio erilaisista summauksista, joita ketteryyden ytimen kiteyttämiseksi on tehty. Niissä kaikissa on sama viesti: ketteryyden mekanismi ei ole tärkeää vaan tärkeää on, että oikeat ydinarvot toteutuvat työn tekemisen tavassa

Ketterän organisaation arvojen muuttuminen arjeksi on kuitenkin kiinni käytänteistä, ja edellä piirretystä käytäntöpinosta syntyy käytännön kokemusten mukaan tehokas ja tarkoituksenmukainen ketterä organisaatio ilman turhia koukeroita.