Ketteryyden skaalautuminen on puhuttanut jo yli kymmenen vuotta. SAFe:ssa ja LeSS:ssä on vahvat sidokset Nokian Symbian-aikoihin ja NSN:n mobiiliverkon kehitykseen. Spotify-malli taas on nimensä mukaisesti tullut Spotifyltä. Näille ja muillekin malleille on yhteistä, että ne ovat syntyneet tietynlaiseen organisaatiokulttuuriin, ohjelmistoarkkitehtuuriin ja liiketoimintamalliin. Niiden hyvät puolet tulevatkin vahvimmin esille silloin, kun niitä käytetään samankaltaisessa ympäristössä johon ne on alun perin kehitettykin.

Voittavaa ketteryyttä voi skaalata vain yrityksen omista lähtökohdista

Mistä mahtaa johtua, että ketteryyden skaalautuminen ei kovin usein täysin saavuta siihen alussa kohdistettuja toiveita ja tavoitteita? Tähän on toki monia syitä, mutta yksi tärkeimmistä syistä on se, että valitulla mallilla ketteryyden skaalautumisessa ei ole ollut minkäänlaisia edellytyksiä onnistua. Varsinkin todella suosittua SAFe-mallia yritetään usein ottaa käyttöön myös organisaatioissa, joissa ei ole mitään yhteistä ohjelmistoplatformia tai -tuotetta, joka vaatisi kattavaa yhteistyötä arvontuotossa. Viime aikoina Spotify-mallia on taas alettu ottamaan käyttöön organisaatioissa, joissa on niin vahva komponenttitiimiarkkitehtuuri, että onnistunut muutos tulisi vaatimaan vuosien työn uudenlaisten tiimien luonnissa.

Yhteistä näille epäonnistuneille hankkeille on se, että niissä ei ole ymmärretty, että voittavan ketteryyden skaalautuminen onnistuu vain yrityksen omista lähtökohdista. Kun malli tuodaan ulkoa, se tuo myös tavoitteet ulkoa. Tämähän on aika lailla sama, kun että maratonille haaveileva kuntoilija ottaisi jääkiekkopelaajan kesäohjelman harjoitusohjelmakseen. Varmasti kehitystä tulisi, mutta ei halutuissa ominaisuuksissa.

Kun ketteryyttä lähdetään skaalaamaan, niin pitää ensin tarkastella skaalautumisen kannalta tärkeimpiä rajoittavia ja mahdollistavia tekijöitä. Tärkeimmät kysymykset organisaation ketteryyden skaalautumisen tapaa pohdittaessa liittyvät pitkälti tuote- ja palveluarkkitehtuuriin, teknologiseen arkkitehtuuriin sekä liiketoiminta- ja myyntimalleihin. On toki mahdollista, että näitä muutetaan samalla kun skaalautumista tehdään, mutta silti ne tulee huomioida hyvin tarkoin mallia valittaessa.

Miksi tuote- ja palveluarkkitehtuuri on merkitsevä ketteryyden skaalautumista pohdittaessa?

Tuote- ja palveluarkkitehtuurilla tarkoitetaan sitä, millaisia tuotteita tai palveluita organisaatio tuottaa. Eli onko organisaatiossa monia tuotteita tai palveluita, joita tulee kehittää, vai ainoastaan yksi vaan yksi palvelu tai tuote. Tämä ei suoraan ratkaise miten skaalautumista tulisi tehdä, mutta on ehdottoman merkitsevä asia siinä. Esimerkiksi SAFe:n koko alkuperäinen ajatusmaailma on kehitetty vastaamaan yhden massiivisen tuoteplatformin kehitykseen.

Toki parhaimmillaan yksittäinen tuote, esimerkiksi verkkopankki tai Spotify-soitin voidaan jakaa moniin alueisiin, jolloin yksittäiset tiimit voi toimia hyvin eristyksissä ja oma-aloitteisesti. Toisaalta taas monituoteympäristökin voi perustua yhteiseen platformiin, jonka takia tiimien tulee toimia vahvasti yhdessä. Tämän tuote- ja palveluarkkitehtuurin nykytilan ja tulevaisuuden toivetilan ymmärtäminen onkin ehdoton vaatimus ennen minkäänlaisia päätöksiä ketteryyden skaalautumisen menetelmistä.

Miksi ketteryyden skaalautuminen vaatii teknologisen arkkitehtuurin huomioimista?

Teknologinen ympäristö sanelee pitkälti kuinka paljon tiimien tulee tehdä yhteistyötä keskenään. Pystyvätkö yksittäiset tiimit toimittamaan arvoa yksin vai pitääkö heidän tehdä yhteistyötä toisten kanssa, jotta saadaan asioita asiakkaalle valmiiksi? On hyvin yleistä, että organisaatiot on luotu teknologioiden ja komponenttien pohjalta, ja sitä kautta yhteistyötä tarvitaan todella paljon. Tämmöisestä tilanteesta siirtyminen vaikkapa Spotify-tyyppiseen malliin vie vuosia ja vaatii todella hyvää muutosjohtamista. On surullista, miten vähän monet ketteryyttä ajavat valmentajat, niin sisäiset kuin ulkoisetkin, tästä puhuvat. Kerrotaan kyllä miten pitäisi toimittaa kokonaisia storyja tai featureita, mutta ei anneta mitään lääkkeitä korjata tilannetta. Voi suoraan sanoa, että jos ketteryyden skaalautumisen hankkeessa ei tästä asiasta puhuta, niin se ei tule onnistumaan.

Miksi myynti- ja liiketoimintamallit ovat niin keskeisessä asemassa ketteryyden skaalautumisessa?

Vaikka projekteista on tullut kirosana 2010-luvulla, niin todellisuudessa monen organisaation liiketoiminta on vielä hyvin projektivetoista. Ulospäin kyllä kehutaan ja puhutaan olevamme tuoteliiketoiminnassa, mutta käytännössä suurin osa kehityksestä tehdään asiakaspyynnöistä eli asiakasprojekteina. Tämä projektimainen toimittaminen ei salli tuotetiimeille paljoakaan vastuuta roadmapistä ja iteratiivisesta kehittämisestä. Enkä ole mitenkään projektimaista toimintaa vastaa, se on monelle organisaatiolle varmasti liiketoiminnan kannalta paras tapa toimia. Ongelma tulee siitä, että ketteryyden skaalautumisen lähtökohta on tuotepohjainen organisaatio ja todellinen liiketoimintamalli on projektitoimitukset.

Toinen liiketoimintamalleihin liittyvä merkitsevä tekijä on se, mitä myydään (tuoteportfolio). Ovatko palvelut esimerkiksi osa jotain kokonaisuutta, kuten esimerkiksi pankkimaailmassa usein on. Vai myydäänkö useita tuotteita yhteisenä toimituksena, vaikka näennäisesti tuotteet ovatkin toisistaan irrallisia? Nämä määrittelevät merkittävästi yksittäisen tiimin autonomiaa ja mahdollisuuksia toimia. Siksi nämäkin asiat tulee selvittää, ennen kuin sopiva ketteryyden skaalautumisen malli organisaatiolle löytyy.

Valmiit skaalautumismallit tai niiden muunnelmat sopivat harvalle yritykselle.

Miten voittava ketteryyden skaalautumisen malli sitten luodaan?

Varmasti monelle pettymykseksi mitään hopealuotia ei ole tarjolla. Valmiit skaalautumismallit tai niiden muunnelmat sopivat harvalle yritykselle. Suurimmalle osalle ne ovat kuitenkin vievät ketteryyden skaalautumista väärään suuntaan.

Kokonaisvaltainen ketteryyden skaalautuminen on niin kompleksinen asia, että blogipostauksen sijaan se vaatisi kirjan. Mutta kaikista tärkeimmät asiat olemme koittaneet kiteyttää näihin kuuteen asiaan:

• Organisaation yhteinen ymmärrys strategiasta ja sen alistrategioista sekä asiakaspersoonista. Niin klisee, kun tämä onkin, niin se on yleisimmin ongelmia aiheuttava asia tuoteorganisaatioissa, varsinkin organisaation kasvaessa. Tämähän ei sinänsä liity ketteryyden skaalautumiseen, mutta ilman tätä voittava ketteryyden skaalaaminen ei onnistu.
• Päätöksentekomalli, jossa osaavimmat henkilöt tekevät päätökset tuotteista ja palveluista. Tämä pitää siis sisällään niin investointi, erilaiset portfoliotasot kuin tuotteiden riliisitkin. Oikeat ihmiset ovat välillä alhaalla, välillä ylhäällä organisaatiossa, tärkeintä on se, että malli mahdollistaa oikeat ihmiset tekemään päätökset oikeista asioista.
• Organisaatiomalli, joka on toimituskykyinen ja mahdollistaa dynaamisen resurssien uudelleenorganisoitumisen. Eli tiimien pitää pystyä toimittamaan mahdollisimman valmista tiiviissä yhteistyössä myynnin ja markkinoinnin kanssa. Lisäksi tiimirakenteeseen pitää voida tehdä dynaamisia muutoksia markkinatarpeiden muuttuessa.
• Toimintamalli, joka varmistaa liiketoiminnan jatkuvuuden ja toimitusten laadun. Dynaamisuuden vastavoimaksi tulee olla toimintamallit, jotka varmistavat, että nykyliiketoiminnasta ja -teknologiasta pidetään huolta. Liiketoiminnan jatkuvuus ja tuotteiden ylläpito pitää varmistaa samalla kun uutta luodaan mahdollisimman ketterästi.
• Liiketoiminnallisten vastuiden ja henkilöstön kehittymisen ja hyvinvoinnin eriyttäminen. Yksi viimeisen lähes sadan vuoden organisaatiomallien ongelma on ollut se, että linjaesimiesorganisaatiosta on tullut vallan väline ja suuri hidaste liiketoiminnalliselle ketteryydelle. Tämän purkaminen tuo mahdollisuuksia organisaation dynaamisemmalle mallille. Tämä tuo henkilöstön kehittämiselle ja kehityskeskusteluille erilaisia haasteita, mutta ei mitään, joka ei olisi ratkottavissa.
• Tiimien ja tuoteorganisaaion tärkeimpien henkilöiden ketterän kehityksen osaaminen. Jos tiimitaso ei ole ketterä, niin ei ketteryyttä voi skaalatakaan. Perusasiat toimintamalleissa siis pitää laittaa aina kuntoon.

Pohtikaa, mikä tuottaisi haluttuja tuloksia juuri teidän uniikissa ympäristössänne.

Yhteenveto: Ketteryyden skaalautuminen lähtee organisaation omista lähtökohdista.

Ketteryyden skaalautuminen onnistuu vain organisaation omista lähtökohdista. Jossain tapauksissa valmiit mallit vastaavat kaikkiin organisaation tarpeisiin ja niillä skaalautumista kannattaa lähteä rakentamaan. Useimmissa tapauksissa näin ei ole ja skaalautumisen mallia kannattaa pohtia tarkoin. Kyseenalaistakaa niin sisäisten kuin ulkoisten profeettojen ajatukset ketteryyden skaalautumisesta, ja pohtikaa, mikä tuottaisi haluttuja tuloksia juuri teidän uniikissa ympäristössänne. Digitaalinen kehittäminen ja ketteryyden skaalautuminen tulee ennemmin tai myöhemmin lähes kaikkiin organisaatioihin, sen ymmärtämiseen kannattaa käyttää aikaa.

Haluatko oppia lisää ketteryyden skaalaamisesta? Olemme pitäneet aiheesta myös webinaarin, jonka voit katsoa tästä! Mikäli tarvitset apua ketteryyden kanssa, tutustu myös Agile, Lean ja SAFe-valmennuksiimme!

[embedyt] https://www.youtube.com/watch?v=yPNI3tXqjVQ[/embedyt]