Hae it-yrityksiä
osaamisalueittain:

Asiakkuudenhallinta CRM BI ja raportointi HR Tuotekehitys ja suunnittelu Toiminnanohjaus ERP Taloushallinto Markkinointi Webkehitys Mobiilikehitys Käyttöliittymäsuunnittelu Tietoturva Verkkokaupparatkaisut Ohjelmistokehitys Integraatiot Pilvipalvelut / SaaS Tekoäly (AI) ja koneoppiminen Lisätty todellisuus ja VR Paikkatieto GIS IoT Microsoft SAP IBM Salesforce Amazon Web Services Javascript React PHP WordPress Drupal
Contribyte » Bloggaus

Ketteryyden skaalautuminen onnistuu vain yrityksen omista lähtökohdista

BloggausKetteryyden 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.


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.


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.

- Pitää luoda 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.

- Toimintamallin, 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.

- Erottakaa liiketoiminnalliset vastuut ja henkilöstön kehittyminen ja hyvinvointi. 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.

- Varmistakaa 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.

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.

Pinterest
Contribyte logo

Lisätietoja

Yritysprofiili Contribyte kotisivut

Tagit

Jos tarjontatagi on sininen, pääset klikkaamalla sen kuvaukseen

Liiketoimintaprosessi

Tuotekehitys ja suunnittelu

Erikoisosaaminen

Ketterät menetelmät
Mobiilikehitys
Ohjelmistokehitys

Toimialakokemus

IT

Tarjonnan tyyppi

Konsultointi
Koulutus

Omat tagit

SAFe
Agile
ketteryyden skaalaaminen

Siirry yrityksen profiiliin Contribyte kotisivut Yrityshaku Referenssihaku Julkaisuhaku

Contribyte - Asiantuntijat ja yhteyshenkilöt

Premium-profiilia ei ole aktivoitu. Aktivoi premium-profiili näyttääksesi tässä lisäämäsi 3 asiantuntijaa.

Contribyte - Muita referenssejä

Contribyte - Muita bloggauksia

Löydä sopivimmat it- ja ohjelmistoyritykset liiketoiminnan kehityskumppaneiksi

ite wikin yrityshaku »

It- ja ohjelmistoalan työpaikat

Kaikki it-alan työpaikat »

Premium-asiakkaiden viimeisimmät referenssit

ite wikin referenssihaku »

Tapahtumat & webinaarit

Kaikki it-alan tapahtumat »

Premium-asiakkaiden viimeisimmät bloggaukset

ite wikin julkaisuhaku »

Digitalisaatio & innovaatiot blogimedia

Blogimediamme käsittelee tulevaisuuden liiketoimintaa, digitaalisia innovaatioita ja internet-ajan ilmiöitä
Huhti 10
Kannattaako tietojärjestelmää jatkokehittää, vai investoida uuteen ohjelmistoon? Sofokuksen Digikehityksen katsastus auttaa digipalvelun elinkaaren suunnittelussa
Katsastuksella autetaan varmistamaan, että teknologia palvelee asiakasta, eikä päinvastoin
Huhti 5
HiQ ostaa Ambientian julkisen sektorin liiketoimintayksikön - kilpailuviranomaiselta hyväksyntä yrityskaupalle
HiQ on viestinyt pyrkivänsä kasvamaan markkinoita nopeammin ja yritysostot ovat keskeisessä roolissa tämän tavoitteen saavuttamisessa
Huhti 2
Ite wiki laajentaa markkinointikenttään - mm. somemarkkinointi, SEO, SEM ja sisältömarkkinointi uusina hakuehtoina
Ite wiki laajentaa hakuehtojaan ja toivottaa uudet eri markkinoinnin substanssien osaajayritykset käyttäjikseen
Siirry blogiin

Etusivu Yrityshaku Pikahaku Referenssihaku Julkaisuhaku Blogimedia