Rakkaalla lapsella on monta nimeä: Cbyte, CB, Contri, Countrybyte, Tri Con Byte, jne. Aikansa kutakin ja uudet seikkailut odottavat; pakkaamme muistoihin mukavimmat hetket ja reppuun parhaat opit. Mikään ei muutu, paitsi nimi ja muskelien koko. Contribyten markkinointi ja toiminnot löytyvät nyt Eficodelta.

Contribyte perustettiin markkinatarpeeseen

Contribyten perustivat vuonna 2006 Panu ja Lasse – tuttavammin ihan vaan Passe. Perustamispäätöstä siivitti, kun huomattiin, että Suomessa tarvitaan tiettyä erityisosaamista, joka jää isojen toimittajien tarjonnan väliin. Oli hyvät näkymät perustaa ALM (nyk. DevOps) tekemiseen keskittynyt konsultointi. Lisäksi Passe pääsi heti tekemään Nokialle juurikin omaan kiinnostukseen osuvaa hanketta.  

Oli selvää, että Contribyte syntyi tarpeeseen, koska liiketoiminta surrasi kasvuun heti ensimmäisistä kuukausista alkaen. Alkuaikoina meno oli sen verran kovaa ja uusia työntekijöitä tarvittiin koko ajan. Jopa niin, että ajan säästämiseksi työhaastattelut pidettiin Lassen autosta käsin. Rekrytointi oli joka tapauksessa sen verran onnistunutta, että moni on vieläkin, yli 10 vuoden jälkeen, mukana.

Isoimman tohinan jälkeen remmiin astui Henri, mikä osoittautui sen verran hyväksi päätökseksi, että Henristä tehtiin toimitusjohtaja. Toimintamalli saatiin uudistettua radikaalisti ja kasvu on pysynyt näihin päiviin asti. Nyt Henri jatkaa tiimin esihenkilönä Eficodella.  

Contribyte on one-stop-shop tuotekehitysorganisaatiolle

Myös markkinaa osattiin kuunnella. Alkuun haluttiin erottautua eikä tarjota samaa, mitä kaikki muutkin. Esimerkiksi tehtiin strateginen päätös, että ei konsultoida Jiraa. Mutta minkäs teet, jos teet sen paremmin kuin muut, niin eipä aikaakaan, kun tarjottiin apuja Jiraan ja muokattiin ensimmäinen versio Contribyte Tools-palvelusta Euroclearille, joka on yhä tänäänkin asiakkaana. Myöhemmin Tools-palvelusta koulutus-, tuki- ja lisenssipalveluineen kasvoi Contribyten liiketoiminnan merkittävä tukipilari.

Contribyten muita kulmakiviä ovat olleet ketterä kehittäminen ja reilu viisi vuotta sitten mukaan tullut tuotejohtaminen, joka saatiin yhdistettyä tarjontaan Prodman Oy:n liiketoiminnan ostamisenmyötä. Agile, lean, SAFe ja muut ketterän kehityksen airueet löytyy siis nykyään Eficodelta niin kuin mainittu tuotejohtaminenkin, vaikkakin jälkimmäinen omilta tutuilta sivuiltaan.  

Contribytella on vahva asiantuntijaosaaminen ja matala hierarkia

Contribyte nyt noin 20 henkilön yrityksenä on aina ollut hierarkialtaan matala. Niin matala, että jossakin vaiheessa lakkautettiin perinteinen myyntiosasto ja opeteltiin myynti asiatuntijoiden vetämänä. Contribyten asiantuntijat eivät ole noviiseja, vaan jokainen oman erityisosaamisensa senioriasiantuntija. Lisäksi on muutama diginatiivi omassa luokassaan. Monimuotoinen tiimi on iso vahvuus.

Dinosauruksia löytyy vain joistain tuotteista ja järjestelmistä, joissa Contribyten osaaminen on lähes ainoa laatuaan. Luurankoja ei löydy lainkaan, koska avoimuus ja suorapuheisuus ovat olleet Contribyten kulttuurin valttikortteja alusta lähtien. On hyödynnetty ”devil’s advocate”-lähestymistä, jos homma junnaa paikallaan ja mentorointiapua on tarvittu. Toistemme tekemiset on ”raadeltu lempeästi”, jotta asiakkaalle tuotetaan vain ensiluokkaista materiaalia.   

Tulevaisuuden tuotekehitys -seminaarit jatkuvat tulevaisuudessakin

Olemme olleet pieni konsulttiyritys isolla sydämellä ja suurilla tavoitteilla. Yksi niistä on joka vuotinen (pandemia-vuotta lukuun ottamatta) Tulevaisuuden tuotekehitys -seminaari. Ensimmäinen tapahtuma järjestettiin vuonna 2015. Ideana on tuoda yhteen tuotekehitystä tekevät yritykset ja käsitellä heille relevantteja aiheita. Seminaarissa keskitytään kokonaisvaltaisen tuotekehityksen edistämiseen, uudistamiseen sekä vahvistamiseen. Tulevaisuuden tuotekehitys jatkuu samannimisenä.

Tuoteorganisaation kulmakivet ovat ja pysyvät

Contribyten tuli ei sammu, vaan sulautuu osaksi Eficoden tarjontaa. Tekemistämme ohjaa edelleen tuotekehityksen kuusi osa-aluetta: liiketoiminta- ja asiakaslähtöisyys, toiminnallinen ja koettu laatu, operatiivinen tehokkuus, motivoitunut ja toimintaan valtuutettu henkilöstö, arvonluonti yhteistyöllä sekä valpas pitkäjänteisyys. Tuoteorganisaatio toimii tehokkaasti, kun kulttuuri, toimintamallit ja työkalut ohjaavat organisaatiota kohti tasapainoista ja tehokasta tuotekehitystä.

Ollaan yhteydessä

etunimi.sukunimi@eficode.com

info@eficode.com

eficode.com

Tuotepäällikön ja tuoteomistajan eroista ja vastuista on kiistelty reilut kaksi vuosikymmentä. Siitä asti, kun tuoteomistajan rooli alkoi vakiintua. Taustalla on väittely siitä, minkä vastuun kukin omistaa ja mihin raja pitäisi vetää. Lähtökohta kiistelylle on väärä. Ei ole yhtä oikeaa jakoa, vaan tuotepäällikön ja tuoteomistajan vastuut pitää jakaa aina tapauskohtaisesti.

Roolien ja tittelien historiaa

Tuotehallinta, tai modernimmin tuotejohtaminen, juontaa juurensa aina 30-luvulle asti. Procter & Gamble esitteli Brand Manager roolin, jonka vastuulla olivat markkinoinnin neljä P:tä (Product, Price, Promotion, Place). Ajan kuluessa P&G:n käytännöt levisivät saippuabisneksestä muillekin aloille ja organisaatioihin alkoi muodostua tuotehallinta- ja tuotemarkkinointiyksiköitä.

Näiden yksiköiden ja niissä toimivien tuotepäälliköiden vastuulla oli tuotteen määrittely (product), hinnoittelu (price), myyntikanava (place) ja markkinointi (promotion). Koska painotukset eri aloilla ja eri yrityksissä vaihtelivat, niin tuotepäällikönkin rooli muotoutui enemmän yrityksen tarpeiden kuin geneerisen roolikuvauksen mukaan. Mitä teknisempi ja monimutkaisempi tuote, sitä kehityslähtöisempi rooli yleisesti oli. Kuluttajatuotteissa markkinoinnin rooli korostui ja usein se myös eriytettiin tuotepäällikön tekemisestä.

Tuoteomistajan (Product Owner) historia on lyhyempi. Ohjelmistokehityksen alkaessa ketteröitymään 1990-luvun loppupuolella, luotiin scrum-viitekehys. Sen oleellisena roolina määritettiin Product Owner eli tuoteomistaja. Roolin tarkoitus oli toimia asiakkaiden tarpeiden ymmärtäjänä, niiden välittäjänä ja priorisoijana ohjelmistokehittäjille. Tarve roolille nousi kehitystiimin tarpeista ja tuoteomistajan rooli onkin säilynyt edelleen tuotekehityksen roolina, ei liiketoiminnan.

Kuka tuotteen lopulta omistaa?

Tuoteomistaja on harhaanjohtava nimike. Tuote ei nykyään ole välttämättä perinteisessä mielessä konkreettinen, myytävä esine. Se voi olla kuukausilaskutteinen palvelu tai jopa asiakasratkaisun keskeinen komponentti. Omistajuus tuotteesta on aina yrityksellä, vaikka vastuu kuuluisi tietylle henkilölle tai roolille.

Tuoteomistajan vastuulla on, että ohjelmistokehityksessä tehdään oikeita asioita oikeassa järjestyksessä. Tuotepäällikön vastuulla taas yleisemmin ovat kaikki neljä P:tä, eli tuotteen lisäksi sen paketointi, hinnoittelu ja asiakkaalle houkuttelevaksi tekeminen. Roolien päällekkäisyys koskee siis lähinnä tuotteen kehittämistä. Toisaalta päällekkäisyys voi olla koko tekemisen ytimessä esimerkiksi jatkuvasti kehittyvien ohjelmistojen tapauksessa, jossa tuote itsessään toimii jakelukanava ja asiakkaiden houkuttimena.

Hyvä esimerkki päällekkäisestä tekemisestä ja samojen termien käyttämisestä eri tarkoitukseen on tuotestrategia. Vaikka alkuperäiseen tuoteomistajan rooliin tuotestrategia ei kuulunutkaan, niin nykyisin se on poikkeuksetta osa tuoteomistajakoulutusta. Kuten se on osa myös tuotepäälliköiden koulutusohjelmia.

Kun tuotekehitysorganisaatiossa puhutaan tuotestrategiasta, tarkoitetaan yleensä suunnitelmaa siitä, minkälainen tuote halutaan kehittää, miten se kehitetään ja minkälaisissa vaiheissa. Teknologia-, arkkitehtuuri-, ja julkaisuvalinnoilla on tällaisessa strategiassa keskeinen rooli kehitettävien ominaisuuksien ohella. Sen sijaan hinnoittelua, tuotemarkkinointia, kohdemarkkinoita tai tuotteen asemointia niissä harvoin pohditaan. Mutta jos tuote on vaikka viini, niin menestys yleensä saavutetaan erilaisella strategialla, kuten Sinisen meren strategia meitä opettaaa.

Organisaation tarve määrittää roolit

Eri roolien, kuten myös titteleiden, sekaannus koskettaa lähinnä yrityksiä, jotka kehittävät ohjelmistoja. Näiden yritysten määrä kasvaa, joten haasteet roolien määrityksissä eivät tule katoamaan. On tapauskohtaista mitä rooleja organisaatiossa tulisi olla ja miten vastuut kannattaa jakaa.

Tuotevastuu alkuvaiheen startupissa

Perustettaessa uutta yritystä perustajilla on yleensä hyvä idea ja visio tuotteesta. Roolit jakaantuvat osaamisen perusteella ja tittelistä huolimatta tehdään juuri sitä, mitä seuraavaksi tarvitaan. Jossain kohdassa liiketoiminta laajenee ja perustajien pitää fokusoida tekemistään. Kehitystiimin kasvaessa tarvitaan joku ohjaamaan ja koordinoimaan sen suuntaa. Koska alussa tarve on yleensä kehityksessä, niin voisi olettaa, että on järkevä palkata tuoteomistaja perustajien keskittyessä kaupalliseen puoleen

Hyvä tiimi ymmärtää sekä omat osaamisensa että tulevaisuuden tarpeet. Tuoteomistaja voi olla se tarvittava rooli, mutta aina ei näin ole. Yrityksestä voi puuttua osaamista tuotemarkkinoinnista, hinnoittelusta tai liiketoimintamallin hiomisesta. Perustajien aika saattaa kulua yrityksen rahoituksen, palkkausten, myynnin tai teknologiavalintojen hoitamiseen. Silloin tuotepäällikkö, joka pystyy allokoimaan osan ajasta tiimin ohjaamiseen, on parempi ratkaisu.

Valinnassa pitää miettiä myös yrityksen tai tuotteen elinkaaren seuraavaa vaihetta ja tarvetta. Tuotepäällikkö, joka pystyy ohjaamaan kehitystiimiä, voi olla helpompi löytää kuin tuoteomistaja, joka pystyy tekemään tuotemarkkinointia.

Monimutkaisten asiakasratkaisujen kerrostuneet tai jakautuneet vastuut

Monimutkainen asiakasratkaisu voi tarkoittaa autoa, satamanosturia tai pankkijärjestelmää. Nämä ratkaisut ovat niin kompleksisia, että tuotejohtamiseen tarvitaan useita henkilöitä. Kehitystiimejä voi olla kymmeniä ja niiden vastuualueet erilaisia. Tällaisissa tapauksissa yleensä roolit määritetään organisoitumisen mukaan.

SAFe on esimerkki hierarkisesta kehitysmallista, jossa tuotepäälliköt ovat päätöksenteossa tuoteomistajien yläpuolella. Roolit ja vastuut on tarkasti määritelty. Toisaalta ne ovat kaukana siitä, mitä samat roolit ovat kasvuyrityksessä. Tuotepäälliköt ovat yleensä vastuussa isoista kokonaisuuksista ja niiden suunnasta, tuoteomistajat taas pienemmistä komponenteista ja niiden toteuttamisesta. Pahimmassa tapauksessa tuoteomistajista tuleekin vain sisäisten asiakkaiden toiveiden täyttäjiä ja käyttäjätarinoiden kirjoittajia, joiden työ on kaukana tuotestrategian pohtimisesta. Tuoteomistajien yläpuolella organisaatiokaaviossa olevat roolitkin voivat olla kehityspainotteisia. Samaa roolia toisessa organisaatiossa toimittava voi olla titteliltään Area Product Owner, kun SAFe-mallin sijaan onkin käytössä LeSS.

Tuotearkkitehtuuri ja tuotekehityksen organisoituminen ohjaavat suurten yritysten organisoitumista ja eri titteleillä tehtäviä töitä.

Itseohjautuvat tiimit

Viime vuosien suurimpia trendejä on ollut tiimien itseohjautuvuus, kattaen myös asiakastarpeiden tunnistamisen. Nykyaikaiset tiimit eivät ainoastaan kehitä organisaation sisältä tulevan tarvelistan mukaisia ominaisuuksia. Ne pyrkivät itse ymmärtämään asiakkaidensa ongelmat, testaamaan ratkaisuehdotukset ja tuottamaan lopulliset ratkaisut.

Jotta itseohjautuvat tiimit voisivat toimia, niin niissä pitää olla laajasti erilaista osaamista niin teknologioista, käyttökokemuksesta kuin asiakastarpeiden ja toimialan ymmärryksestä. Usein myös markkinointi- ja myyntiosaamista tarvitaan, jotta voidaan testata ratkaisun haluttavuutta.

Itseohjautuvia tiimejä syntyy niin kasvuyrityksiin kuin vakiintuneisiinkin firmoihin, jotka haluavat purkaa hierarkisia rakenteitaan ja antaa vastuuta enemmän tekijätasolle. Itseohjautuvissa tiimeissä on yleensä tuoteomistaja tai tuotepäällikkö, mutta kumpi näissä tapauksissa on parempi vaihtoehto?

Kysymys palaa tiimin vastuisiin. Itseohjautuva tiimi voi olla kehitystiimi tai vastuussa koko tuotteesta. Jos yrityksessä oletetaan tiimin kykenevän hoitamaan kehityksen lisäksi kaupallistamisen, niin osaamisen pitää ulottua tuotemarkkinointiin. Tämän osaaminen suurimmalta osalta tuoteomistajia puuttuu.

Mitä tai mitkä roolit tarvitaan?

Pääasiallisesti voi sanoa, että tuoteomistaja on kehityksen rooli ja tuotepäällikkö liiketoiminnan. Tämä yksinkertainen muistisääntö helpottaisi jo paljon hämmennystä näiden kahden roolin välillä.

Hyvä tuoteomistaja on usein erikoisosaaja. Tuotepäällikön rooli on laajempi ja vaatii leveää osaamispohjaa. Organisaatiota rakennettaessa ja uusia paikkoja avatessa yritysten kannattaa korostaa, mitä he uusilta rooleiltaan odottavat ja minkälaisia mahdollisuuksia he työnhakijoille tarjoavat.

Työnhakijankin näkökulmastakin on parempi, kun odotukset roolille on selkeästi kuvattu ja ennen kaikkea silloin, kun titteli ja rooli eroavat toisistaan. Työnhakijalle tärkeätä on ymmärtää urapolku ja omat kehittymisen mahdollisuudet, eli odotetaanko syväosaamista vai laajempaa strategista ja liiketoiminnallista näkemystä ja mihin kaikkeen työssä voi itse vaikuttaa.

Muut kiistelyt roolien ja niiden vastuiden jakaantumisen osalta voidaan lopettaa. Vain organisaatiot itse voivat tietää mitä ne tarvitsevat.

Tuoteomistaja on tuotepäällikön apulainen. Keskittymällä lähitulevaisuuden backlogin priorisointiin ja määrittelyyn hän auttaa tiimiä tähtäämään tarkemmin maaliin.

Miten tuoteomistajan ja tuotepäällikön tehtävät eroavat? Kuka vastaa mistä? Miksi käytetään oudolta kuulostavaa ”omistaja” sanaa? Eikö tuotepäällikkö ole tuotteesta kokonaisvastuussa?

Tuotepäällikkö on paras tuoteomistaja

Tuoteomistajan roolin hoitaminen hyvin vaatii käyttäjien ja asiakkaiden tuntemusta, mutta myös kykyä ymmärtää ja kuunnella tiimiä ja teknisiä yksityiskohtia. On myös pystyttävä olemaan tarpeeksi läsnä tiimin kanssa.

Tuotepäälliköllä on paras käyttäjien ja asiakkaiden tuntemus. Hankkeen alussa tai kun kehitystiimi on pieni, tuotepäällikkö pystyy hyvin hoitamaan myös tuoteomistajan tehtävät. Ei välttämättä tarvita erillistä tuoteomistajaa.

Kiireinen tuotepäällikkö etääntyy kehitystiimistä

Kehityksen edetessä ja tuotteen menestyksen myötä tiimi kasvaa, asiakkaita tulee lisää ja saatetaan mennä uusille markkinoille. Aikaa kuluu enemmän asiakkaiden kanssa tai markkinoiden tarpeiden selvittämiseen. Tuotteen business case monimutkaistuu, ja tulee lisää työtä tuotemarkkinoinnin suunnalta.

Tiimin kasvaessa kasvaa aina myös backlog. Työn alle pääsee enemmän asioita, joka johtaa siihen, että määrittelyyn kuluu enemmän aikaa. Tiimi voi kasvaa niin paljon, että tarvitaan kohta yhden tiimin sijaan useita.

Kaikki nämä asiat johtavat siihen, että tuotepäällikön työkuorma sekä markkinoiden ja asiakkaiden suunnalta että kehitystiimien suunnalta kasvaa. Usein asiakkaat ja markkinat vievät etusijan. Tiimi tuntuu pärjäävän ilman ohjaustakin. Aikaa ei riitä enää niin paljon tiimille ja yksityiskohdille. Tuotepäällikkö etääntyy kehitystiimistä. Tällaisessa tilanteessa kasvaa riski sille, että tehdään vääriä asioita väärässä järjestyksessä.

Nyt tarvitaan erillistä tuoteomistajaa.

Tuoteomistajan rooli vaatii aikaa

Tuoteomistaja vastaa siitä, että backlogia hallitaan, priorisoidaan ja backlogin huipulla olevia asioita määritellään tarpeeksi tarkasti. Hän ei tee tätä yksin vaan yhdessä tiimin kanssa. Näin kaikilla on sama ymmärrys asioiden tärkeysjärjestyksestä ja siitä mitä ne tarkoittavat.

Yhteisen ymmärryksen saaminen ottaa paljon aikaa ja keskusteluja. Aikaa pitää käyttää riittävästi. Hyvä nyrkkisääntö on, että tuoteomistajan roolin hoitaminen ottaa vähintään 2 päivää viikossa. Paras tulos kuitenkin syntyy, kun tuoteomistajalla on mahdollisuus täysillä keskittyä roolin hoitamiseen.

Tuotepäällikkö vastaa aina kokonaisuudesta

Tuotepäällikön vastuulla säilyy tuotteen kokonaisuus, liiketoiminta ja pitkän tähtäimen suunnitelma, roadmap. Roadmap katsoo usean vuoden päähän. Backlog, jota voi ajatella lähitulevaisuuden tarkkana suunnitelmana, katsoo usein noin 6-12 kuukautta tulevaisuuteen.

Roadmap on tavoitteita, backlog on lupauksia

Roadmapilla olevat asiat ovat kauempana tulevaisuudessa, ja epävarmempia, enemmän tavoitteita ja toiveita. Niitä ei aina ole analysoitu ja tarkennettu yksityiskohtiin asti. Ne eivät myöskään ole aivan niin vahvoja lupauksia tuotteeseen kuin backlogilla olevat asiat. Niissä ei ole vielä selvitetty, millä tavalla ne rakennetaan. Niihin sisältyy oletuksia siitä, miten kallista ominaisuuksien rakentaminen on. Jos oletukset osoittautuvat vääriksi, ja jonkin asian rakentaminen onkin paljon kalliimpaa, täytyy asian tärkeyttä harkita uudelleen.

Lupauksen varmuus kasvaa

Roadmapilta siirtyy siis asioita backlogille. Asian siirtyessä backlogille, tuoteomistaja ja tiimi analysoivat, mikä tarkka asiakastarve olikaan ja miten uusi ominaisuus rakennetaan. Vasta kun tarve ja työmäärä ymmärretään paremmin, tehdään lopullinen päätös siitä, milloin ja miten asia toteutetaan vai toteutetaanko ollenkaan. Tämä tarkentaa ja nostaa lupauksen varmuutta.

Koska ideoita on aina paljon enemmän kuin pystytään toteuttamaan, priorisointi on käytännössä sitä, että joku sanoo asioille kyllä tai ei.
Backlogilla oleva asia onkin varsin vahva lupaus tiimiltä toimittaa. Koska tuoteomistaja on backlogin päätösvaltaa käyttävä henkilö, hänellä on vahva ”lupaajan” rooli organisaatiossa. Kun tuoteomistaja sanoo ”kyllä”, se tarkoittaa, että kohta työ alkaa.

Ei backlog-sihteeri vaan tuoteomistaja

Tämä on syy sille, miksi roolin nimi on tuoteomistaja eikä esimerkiksi backlog-sihteeri. Nimenomaan tuote hyötyy siitä, että joku henkilö vastaa asiakastarpeen ja työmäärän tarkasta selvittämisestä. Vahva selvittäjän ja hyväksyjän rooli – tuoteomistajuus – johtaa parempaan priorisointiin. Kyse ei siis ole siitä, että kukaan yksittäinen ihminen oikeasti omistaisi tuotetta. Tuoteomistajan roolin tärkeys on juuri siinä, että pakotetaan organisaatio tarkkaan harkitsemaan, mitä, miksi ja missä järjestyksessä asioita tehdään.

Olet sitten aloitteleva tai jo kokenut Product Owner tai et tuoteomistaja lainkaan tai sitten tuotepäällikkö, niin on hyvä kerrata, mitä tuoteomistaja tekee. Rooli avautuu, kun tilaat Contribyten ladattavan oppaan vierestä. Kysyäkin meiltä saa!

Contribyte tekee yhteistyötä Vesiurheilukeskus Laguunin kanssa. Laguuni toimii Helsingin Hietaniemessä ja Espoossa Keilaniemessä. Monipuoliset vesiurheilulajit toimivat luonnon ehdoilla ja Espoon Keilaniemen toimipisteellä wakeboarding-kaapeleiden sähkö saadaan ympäristöystävällisesti pitkäaikaisen kumppanin Fortumin aurinkopaneeleista. Laguunilla on kehityksen ensiasteilla myös toimipiste Helsingin Hietaniemessä.

Laguuni osallistuu myös Itämeren suojeluun, jonka Contribyte mahdollistaa muiden sponsoreiden rinnalla. Laguunin organisoima Itämeri Plogging tarjoaa kajakit kaikkien halukkaiden käyttöön roskien keräämiseksi Itämerestä. Lisäksi Laguuni järjestää joka kesä erillisen plogging-päivän, jolloin liikunnan merkeissä siistitään myös luontoa. John Nurmisen Säätiön Itämeripäivänä 26.8.2021 meren siivoustalkoot huipentuvat yhteisöllisesti, kun vesille lasketaan yli sata kajakkia ja muuta menopeliä pelkästään Keilaniemen ja Hietaniemen alueilla. Kaikki osallistumaan talkoisiin erilaisilla menopeleillä ympäri Suomen!

Ennennäkemätön hanke tuo siivouskajakit Suomen rannikolle helposti kaikkien saataville kesän 2021 ajaksi. Hanke jalkautetaan Ouluun, Vaasaan, Poriin, Turkuun, Espooseen ja kolmelle eri toimipisteelle Helsinkiin samanaikaisesti. Konkreettiseen siivoustyöhön motivoi mittausjärjestelmä, jolla kaikki kerätty roska punnitaan, kirjataan ja kierrätetään. Hankkeesta vastaa Vesiurheilukeskus Laguuni.

Miksi Contribyte valitsi Laguunin?

Me Contribytella olemme urheiluintoilijoita ja halusimme tukea jotakin, mikä on meitä fyysisesti lähellä. Koemme, että voimme vaikuttaa paremmin johonkin sellaiseen, minkä äärellä olemme, kuten Itämeren, ja jonka hyvinvointiin voi konkreettisemmin osallistua.

Jokainen voi osallistua Itämeren suojeluun

Itämeri on vähävetinen sisämeri, jota rasittaa peräti 85 miljoonan ihmisen jätevedet ja maatalousalueilta huuhtoutuvat ravinteet. Itämeren pohjakerrostumissa majailee rehevöittäviä ravinteita ja myrkkyjä.

Suomellakin on Itämeren suojeluohjelma, johon jokainen suomalainen voi osallistua. Tehokas Itämeren suojelu parantaa myös järvi- ja jokivesien laatua ja sisämaan luonnon monimuotoisuutta. Teollisuus, maatalous ja mm. liikenne voivat vaikuttaa paljon Itämeren kuntoon. Yksityishenkilö voi vaikuttaa valitsemalla sellaisia tuotteita ja organisaatioita, jotka toimivat Itämeren puolesta, tai ei ainakaan saastuta sitä. Muutamia konkreettisia tekoja on kasvispainotteinen ravinto, ympäristöystävällisten kemikaalien ja uusiutuvan energian valinta. Tai poimimalla edes yhden roskan merestä tai sen läheisyydestä.

Itämeren suojelu edellyttää oma-aloitteista vastuullisuutta

Muutos lähtee aina yksilöstä: tahdosta ja tavoitteesta kohti haluttua. Contribyten arvoja on oma-aloitteinen vastuullisuus. Meitä ohjaa vastuu tekemisestämme ja asioiden viemisestä maaliin asti toisiamme tukien ja yhdessä asiakkaiden kanssa. Olemme kiitollisia osallistumisestamme Itämeren suojelun Laguunin toiminnan kautta – yhteisöllisen vastuullisesti.

P.S. Iso suositus Laguunille. Meidän tiimipäivämme oli superhauska!

Asiakkaan kommentti ”kun nämä scrum masterit ovat katoamassa” pysäytti miettimään – onko se todella näin? Kokeneet ketterät tiimit näkyvät pärjäävän ihan hyvin ilman scrum masteriakin.

On pelottavaa, että scrum masterin roolia arvostetaan näin vähän. Miksi rooli on näin aliarvostettu ja väärinymmärretty?

Onko rooli aliarvostettu, nähdäänkö vain kokousten järjestäjänä ja rooliin kuluvat muut vastuut on unohdettu?

Uhkaako scrum master -roolia sukupuutto?

On totta, että tiimeille on kertynyt paljon kokemusta ketteristä toimintatavoista. Kaikki scrum guiden seremoniat ovat tuttuja ja käytössä. Kypsä, pitkään yhdessä toiminut tiimi ei välttämättä tarvitsekaan scrum masteria siihen, että seremoniat pidetään. Mutta miten on jatkuvan parantamisen laita? Kuka haastaa ja auttaa tiimiä kasvamaan?

Jokainen organisaatio haluaa tiimeistä enemmän tehoa irti. Scrum master on rooli, joka hyvin hoidettuna auttaa tiimejä tehostamaan toimintaa.

Onko scrum masterin rooli taakka?

Onko rooli taakka? Usein scrum masterina toimitaan oman työn ohessa. Jos roolin muita vastuita ei tarpeeksi korosteta, OTOna toimiva scrum master helposti keskittyy vain kokousten järjestämiseen. Tällöin roolissa toimimista ei nähdä arvokkaana, se vain vie aikaa ”oikeilta töiltä” joista nauttii enemmän. Halukkaita scrum mastereita voi olla vaikea löytää.

Kun ei ole halukkaita scrum mastereita, lopetetaan niiden etsiminen. Rooli on varmaan tarpeeton, koska kukaan ei halua sitä hoitaa?

Mitkä ovat scrum masterin vastuut?

Hyvä scrum master tekee muutakin kuin järjestää kokouksia:

• työn esteiden poiston varmistaminen
• tiimin valmennus parempaan itseohjautumiseen ja yhteistyöhön
• tuoteomistajan apuna toimiminen backlogin jalostamisessa ja hallinnassa
• koko organisaation valmentaminen ymmärtämään scrumia paremmin ja toimimaan paremmin tiimin kanssa

Jos scrum master puuttuu, kuka näitä asioita hoitaa? Jos ne jäävät hoitamatta, sillä on väistämätöntä vaikutusta tuloksiin.

Jos scrum master puuttuu

• tuoteomistaja jää yksin backlogin kanssa
• backlogin jalostaminen kärsii, ja epäselvästi määritellyt asiat joudutaan tekemään moneen kertaan
• ennustamisen epätarkkuus kasvaa
• tiimin aikataululupauksiin ei voi enää luottaa
• pitkäjänteinen suunnittelu vaikeutuu
• tiimi ei kehity, vaan jää paikoilleen junnaamaan
• Organisaasiossa on jo ehkä tiimejä, joista scrum master puuttuu. Onko tehty vertailua, miten nämä jaksavat verrattuna tiimeihin, joilla scrum master on?

Ilman scrum masteria tiimien stressitaso on korkeampi ja työtyytyväisyys matalampi. Tämä johtaa suurempaan vaihtuvuuteen. Tilalle tarvitaan uusia tekijöitä, joiden oppiminen ja opettaminen syö tiimin tehoa.

Parhaiten pärjäävillä tiimeillä on hyvä tuoteomistaja ja hyvä scrum master, ja taas tiimeissä, joissa vaikka scrum master puuttuu, ilmapiiri latistuu ja kehitysvauhti putoaa.

Voiko tuoteomistaja olla scrum master?

Jos tuoteomistaja on samalla myös scrum master, siitä seuraa ongelmia.

Tuoteomistajan päätyö on tuotteen ominaisuuksien ja prioriteettien miettiminen. Tiimin toiminnan kehittäminen jää vähemmälle. Retrospektiivi-kokouksia laiminlyödään tai unohdetaan. Daily-kokous saattaa muodostua ”raportoidaan tuoteomistajalle”-kokoukseksi, eikä toimikaan tiimin työkaluna sprintin maaliin navigoimiseksi.

Tuoteomistaja scrum masterina johtaa siihen, että tiimin suorituskyky ei kehity, vaan pysähtyy tai taantuu.

Scrum masterin kanssa tiimi parantaa toimintaansa

Hyvä tiimi menee koko ajan eteenpäin. Kehittyvässä ja toimintaa parantavassa tiimissä on myös mukavampi työskennellä. Stressaavista tilanteista selvitään yhdessä. Hyvä scrum master vähentää tiimin stressitasoa. Matalampi stressi parantaa innovaatioherkkyyttä ja luovuutta. Se johtaa väistämättä parempaan laatuun.

Scrum master auttaa suurempien muutoshankkeiden läpiviennissä

Tiimin suorituskyvyn parantamiseen pitää lähteä toiminnan kehittämisen taitoja.

Jos tiimillä on scrum master, voidaan tämä kehittäminen keskittää yhdelle ihmiselle. On paljon helpompaa ja edullisempaa kouluttaa 15 hyvää scrum masteria, kuin kouluttaa koko 200 tuotekehittäjän henkilöstö hyviksi valmentajiksi. Scrum masterit toimivat tiimin sisällä muutoksen läpiviejinä.

Delegoi seremoniat – keskity kehittämään

Miten tehdä scrum masterin töistä houkuttelevampia? Tiimit pystyvät hoitamaan kokoukset pitkälti jo itse – miksi emme sitten sovi, että scrum mastereille ei kuulu kokousten järjestäminen, vaan sen hoitavat tiimit itse.

Scrum masterit keskittyvät sitten kaikkeen muuhun – tuoteomistajan auttamiseen backlogin hallinnassa ja jalostamisessa, tiimin haastamiseen olisiko parempia toimintatapoja, sen vahtimiseen osaako tiimi selvitä vastaantulevista esteistä. Scrum master voi keskittyä järjestämään loistavia retrospektiiveja, joissa tiimi tai useat tiimit yhdessä löytävät toiminnan tehostamisen keinoja.

Johtaja – tue scrum master yhteisöä

Johto voi painottaa scrum master -roolissa toimimisen tärkeyttä, ja varmistaa esimerkiksi scrum master yhteisön aktiivisen toiminnan antamalla yhteisön vetovastuun nimetylle henkilölle.

On myös annettava riittävästi aikaa ja rahaa järjestää yhteisön tapahtumia. Yhteisön aktiivisuus on olennainen osa sitä, että scrum masterin roolia aletaan arvostamaan enemmän.

Tietotyöläisille usein yksi tärkeä asia on se, että oppii uutta ja kehittyy. Scrum master -roolikin koettaisiin mukavampana, jos siinä kehittymiseen saa jatkuvaa tukea. Yksi tapa tukea scrum mastereita on Contribyten World Class Scrum Master -konsepti.

Kehity tai kuole

Scrum master on muutosvoima, joka auttaa tiimiä parantamaan toimintaa nopeammin. Evoluutiossa pärjäävät parhaiten ne, jotka sopeutuvat nopeimmin. Scrum mastereihin panostamalla on mahdollista nopeuttaa muutosta ja sopeutumista. Scrum masterit eivät ole uhanalaisia. Vaarassa saattavat sen sijaan olla ne organisaatiot, jotka laiminlyövät toimintatapojen kehittämisen ja parantamisen.

Olet sitten aloitteleva tai jo kokenut scrum master tai et scrum master lainkaan, mutta organisaatiossasi on scrum master, niin on hyvä kerrata, mitä scrum master tekee. Rooli avautuu, kun tilaat Contribyten ladattavan oppaan vierestä. Kysyäkin meiltä saa!

Yritysosto syventää strategisia kumppanuuksia ohjelmisto-organisaatioiden kanssa

Helsingissä 2.6.2021

Eficode, Euroopan johtava DevOps-yhtiö on ostanut Contribyten, Suomen johtavan yrityksen ketterien menetelmien (Agile) ja tuotehallinnan kehityspalveluissa.

Ohjelmisto-organisaatiot ottavat käyttöön DevOps- ja Agile-menetelmiä luodakseen kilpailuetua ohjelmistoista. Nopea ohjelmistojen laajentuminen kaikkiin toimialoihin on luonut yrityksissä runsaasti tarpeita kehitystyökalujen, -prosessien ja kulttuurin valmennukselle ja koulutukselle. Contribyten avulla Eficode lujittaa mahdollisuuksia auttaa yrityksiä siirtymään Agile- ja DevOps-menetelmiin sekä tehokkaiden ohjelmistokehitysympäristöjen käyttöönottoon.

”Uskomme, että Contribyten vahva osaaminen auttaa kunnianhimoisia organisaatioita omaksumaan ketteriä menetelmiä. Tarjoamme Contribyten osaamista asiakkaillemme Euroopassa, jotta he voivat vahvistaa tuote- ja ohjelmisto-organisaatioitaan”, sanoo Ilari Nurmi, Eficoden toimitusjohtaja.

Contribyten hankinnan myötä Eficode syventää asiakassuhteitaan yhä strategisemmiksi, ja kiihdyttää Agile- ja DevOps-menetelmien lisäksi myös pilvipalvelujen käyttöä. Yritysosto kiihdyttää entisestään konsultointi- ja valmennuspalveluita myös kestävän ohjelmistokehityksen alueella, ja nopeuttaa kasvua Eficode ROOT DevOps-alustalle; hallinnoidulle palvelulle, joka tukee yli 40 eri teknologiatoimittajan DevOps-työkaluja ja kattaa koko ohjelmistokehityksen elinkaaren vaatimustenhallinnasta jatkuvaan julkaisuun ja analytiikkaan.

”Liitymme mielellämme osaksi Eficodea. Contribytellä on paljon huippuosaamista organisaatioiden siirtymisessä ketteriin menetelmiin. Annamme neuvoa ja valmennamme asiakkaitamme strategisten muutosten aikana, jotta he saavat kilpailuetua ohjelmistoista. Asiakkaamme ovat pitkään toivoneet meiltä sellaisia palveluita mitkä ovat Eficoden ydinosaamista. Osana Eficodea osaamisemme ja palvelumme laajenevat, ja voimme auttaa asiakkaitamme ratkaisemaan yhä vaativampia haasteita”, sanoo Henri Hämäläinen, Contribyten toimitusjohtaja.

Contribytellä on yli 300 asiakasta Euroopassa ja sen ulkopuolella pankki- ja vakuutusalalla, teollisessa valmistuksessa ja liiketoiminnan palveluissa. Contribyten asiakkaita ovat mm. ABB, Vaisala, Nokia, CRF – tätänykyä Signant health, Helvar, ja DNA. Contribyten liikevaihto viimeisellä tilikaudella oli 3,8 miljoonaa euroa.

Yhteystiedot
Ilari Nurmi, Toimitusjohtaja, Eficode, ilari.nurmi@eficode.com, +358 40 577 5084
Lauri Palokangas, Markkinointijohtaja, Eficode, lauri.palokangas@eficode.com, +358 50 486 4918

Tietoa Eficodesta
Eficode on Euroopan johtava DevOps-yhtiö, joka edistää DevOps-toimintaa ja ketteriä menetelmiä ja rakentaa ohjelmistokehityksen tulevaisuutta kahdeksassa maassa yli 400 ammattilaisen voimin. Eficode opastaa asiakkaitaan DevOps- ja Agile-menetelmissä ja käytännöissä, ja auttaa heitä keskittymään kasvuun ja asiakkaidensa palvelemiseen.
Eficode ROOT DevOps-alusta tarjoaa hallinnoituna palveluna yli 40 ohjelmistokehitystyökalua, mukaan lukien Atlassian, Jenkins ja Kubernetes. Eficode tarjoaa asiakkailleen myös sovellushallinnan ja Atlassian-palvelut.

Tietoa Contribytestä
Contribyte auttaa organisaatioita vastaamaan tuoteliiketoiminnan tärkeimpiin kysymyksiin tietoon ja parhaisiin käytäntöihin perustuen.
Contribyte kouluttaa tuotekehityksen ihmiset, suunnittelee menestyksekkäitä organisaatioita, ja auttaa heitä saamaan enemmän arvoa työkaluistaan. Valmentajillamme on vuosien kokemus tuotekehityskäytäntöjen ja -prosession parantamisesta.

Backlog refinement eli kehitysjonon jalostaminen on seremonia, jossa tuoteomistaja ja tiimi yhdessä parantavat kehitysjonon laatua. Hyvät tiimit pitävät refinement-sessioita säännöllisesti viikoittain.

Backlog refinement -seremoniasta saa lisätehoa ottamalla käyttöön kaksi uutta toimintatapaa:

1. Skannaa ja suunnittele
2. Pilkkomisporukat

Huomio jonon huipulle:

Keskustelemalla, määritystä ja hyväksyntäkriteerejä tarkentamalla yhteinen ymmärrys työstä paranee. Näin varmistutaan siitä, että tehdään juuri oikean suuntainen toteutus, eikä mitään ylimääräistä. Huomio kohdistetaan lähiviikkojen aikana eteen tuleviin asioihin.

Kauemmas ei katsota:

Usein tiimi tekee kehitysjonon huipun jalostamisen todella hyvin, ja tulevaisuus kolmesta kuuteen viikkoa eteenpäin on hyvin selkeä. Kauemmas tulevaisuuteen, muutaman kuukauden päähän, ei tehdä suunnittelua lainkaan. Backlogia ei koskaan katsota läpi syvemmälle.

Backlogille kerrostuu yllätyksiä:

Lähellä huippua olevat asiat ovat hyvin ymmärretty ja jalostettu, ja juuri niiden alapuolelle tulee uudet tärkeät asiat. Loppuosaa backlogista ei hoideta.

Syvemmällä kehitysjonossa on

• tärkeysjärjestyksessä liian alhaalle unohtuneita asioita
• asioita, joiden työmäärä lähemmin tutkittaessa osoittautuu huomattavan suureksi
• asioita, joissa on yllättäviä riippuvuuksia muualle
• samoja asioita on useamman kerran
• asioita mitkä ovat ajan myötä muuttuneet tarpeettomiksi

Aikataulut ja asiakastyytyväisyys kärsivät:

Seurauksena on kooltaan hitaasti liian suureksi ja hankalasti hallittavaksi kasvava kehitysjono. Jonon huippu on kyllä kunnossa, mutta kukaan ei halua katsoakaan syvemmälle. Tiimille tulee ”oho, onpas tämä kymmenen kertaa enemmän työtä kuin luulin” tai ”ups, eihän tätä voikaan tehdä ennen kuin..” -hetkiä. Hankkeen luvatut aikataulut menevät mullin mallin, ja asiakkaat ja johtoporras ovat tyytymättömiä.

Miten käyttää säännöllisesti sopivan verran aikaa suunnitteluun?

Tilanteen ratkaisemiseksi pitää käyttää enemmän aikaa tulevaisuuden suunnitteluun. Tässä auttaa skannaa ja suunnittele -käytäntö.

1. Skannaa ja suunnittele

Skannaa ja suunnittele -toimintatavassa (englanniksi helposti muistettava ”Scan and Plan”) tuoteomistaja ja tiimi käyvät kerran kuussa koko backlogin läpi. Jos refinement-kokous kestää suositellusti tunnin joka viikko, käytetään siis puoli tuntia kuukaudessa backlogin skannaamiseen.

Siivoa backlog kerran kuussa:

Puolituntisessa asioita käydään läpi tärkeysjärjestyksessä ylhäältä alas. Tiimi kysyy itseltään joka asian kohdalla seuraavat kysymykset:

• onko asia tärkeämpi kuin sen yläpuolella olevat asiat?
• onko asia tarpeeton tai jonkin toisen asian toistoa?
• onko asia teknisesti tai asiakastarpeen ymmärtämisen osalta riskialtis ja vaatii esitutkimusta?
• onko asian toteuttamiseen tarvittavat riippuvuudet selvillä ja varmistettu?
• onko asia työmäärältään liian suuri ja pitäisikö se nyt jakaa asia pienempiin osiin erillisessä pienryhmässä?

Backlogilla saa olla isoja asiakokonaisuuksia, kunhan ne eivät ole ajallisesti liian lähellä. Mitä ylemmäs asiat ajan kuluessa kohoavat kehitysjonossa, sitä ajankohtaisemmaksi niiden pilkkominen tulee.

Tee tarpeelliset toimenpiteet:

Liian alhaalla olevat asiat siirretään oikeaan kohtaan ja turhat asiat poistetaan. Esitutkimusta vaativat asiat otetaan tutkittavaksi seuraavaan sprinttiin.

2. Pilkkomisporukat jakavat isot tarinat tehokkaasti

Puolessa tunnissa ei ehditä pilkkoa asioita pienemmäksi. Asioiden jakamiseen kannattaa perustaa työpareja tai pienryhmiä, pilkkomisporukoita (englanniksi helposti muistettava ”Splitting Squad”), jotka pilkkovat asioita pienempiin palasiin. Pilkkominen vie paljon aikaa ja on usein tehokasta tehdä pareittain eikä koko porukalla.

Pilkkomisporukalla saa seuraavat hyödyt:

• Pilkkomisen yhteydessä työpari miettii käytännössä hyväksyntäkriteerejä
• Pilkkominen voidaan tehdä rauhassa, eikä refinement-kokouksen aikaboksissa pienessä kiireessä
• Valmistelutyön vastuu jakaantuu useammalle ihmiselle

Käytännössä pilkkomisporukan jäsenet kannattaa yrittää sopia heti. Vapaaehtoiset ovat paras ratkaisu. Jos vapaaehtoisia ei heti löydy, voidaan pilkkomisporukka ottaa seuraavan sprintin backlogille, Sitten siihen menevä työmäärä arvioidaan samalla tavalla kuin muukin sprinttisisältö. Sitten tiimi varmasti ymmärtää, että tämä työ on tärkeää.

Siivous pitää backlogin kunnossa

Skannaa ja suunnittele -käytäntö auttaa tiimiä ymmärtämään paremmin koko backlogia ja isoa kuvaa. Käytäntö auttaa myös siivoamaan turhia asioita pois ja helpottaa backlogin hallintaa. Yllätysten riski pienenee ja vaikeiden asioiden ratkaisemiseen saadaan enemmän aikaa.

Pilkkomisporukat tehostavat isojen ja epäselvien asioiden jakamista ja määrittelyä. Niiden avulla tehostat backlog refinement -kokousta. Tehokas refinement takaa tiimin hyvän tuottavuuden ja motivaation.

Asiakaskokemuksen kehittäminen näkyy taloudellisessa tuottavuudessa, joten asiakaskeskeisen tekemisen pitäisi olla osa kaikkien työtä.

Parempi asiakaskokemus, parempi taloudellinen tulos. Forbes on kerännyt lukuja eri tutkimuksista: Asiakaslähtöiset yritykset ovat 60% tuottavampia kuin ne, jotka eivät panosta asiakkaisiin. 84% yrityksistä, jotka kehittävät asiakaskokemustaan, ovat onnistuneet kasvattamaan liikevaihtoaan.

Asiakaskokemuksesta ei saa nappia painamalla lukuja tai yksityiskohtaista kaaviota. Se on kokonaisuuksien summa, joka pitää valjastaa teoiksi. Johto ei yksin päätä, millainen asiakaskokemus on. Sen tekee lopulta asiakas. Yritys voi kuitenkin ohjata ja johtaa asiakaskokemuksen dialogia, joka syntyy asiakasta kuunnellen ja palvelumuotoilun keinoilla. Niiden pitää olla aktiivisesti käytössä läpi organisaation.

Hyvä asiakaskokemus saa kantamaan omat ja ystävienkin rahat yritykseen

Ajatus siitä, että asiakaskokemuksella on yhteys liiketoiminnan tulokseen, lienee selvä. Jotkut yritykset olettavat voittaneensa ainakin osan asiakkaiden sydämistä, mutta mikään ei ole turmiollisempaa tuottavuudelle kuin valheellinen usko johonkin, mitä ei voi todistaa. On tärkeää ratkaista, miten kehittää asiakaskokemusta.

Asiakaskokemusta voi kehittää monin pienin, pitkäjänteisin teoin, joita palvelumuotoilu tarjoaa. Esimerkiksi Asiakaspolun visualisointi avaa ymmärrystä siitä, miksi asiakkaat poistuvat palvelusta ennen ostoa. Kun on löydetty se, mitä korjata, korjauksen vaikuttavuus poistumisiin on mitattavissa. Asiakaskokemuksen mittari on tekojen vaikuttavuus, ei yksittäiset teot.

On turhaa tuijottaa liiketoiminnan katetta ja verrata sitä asiakastyytyväisyyteen, esimerkiksi NPS-mittarilla. Kysyttäessä asiakas on tyytyväinen ja ehkä suosittelee tuotetta, palvelua tai yritystä. Asiakaskokemus menee syvemmälle. Hyvässä asiakaskokemuksessa asiakas vie omatoimisesti positiivista tunnettaan tuotetta, palvelua tai yritystä kohtaan omalle viiteryhmälleen. Asiakastyytyväisellä ei ole aihetta olla tyytymätön, mutta hyvän kokemuksen kokenut muistaa tunteen, jonka tuote, palvelu, yritys tuotti.

Jatkuva palvelumuotoilu on asiakaskokemuksen moottori

Asiakkaan on vaikea määrittää sitä, mikä teki asiakaskokemuksesta hyvän. Vastaus on usein: ”tuli vaan sellainen hyvä tunne.” Asiakas ei osaa määrittää, mikä hyvän tunteen aiheutti tai missä vaiheessa se tapahtui. Epämääräisyys johtuu siitä, että hyvä asiakaskokemus on monen asian kokonaisuus, jossa palaset loksahtavat paikoilleen lopulta tuottaen hyvän tunteen asiakkaassa.

Epämääräisyys ei lohduta yritystä, joka pyrkii erinomaiseen asiakaskokemukseen. Asiakaskokemuksen kehittämisessä asiakkaan tulee olla keskiössä kautta linjan. Siksi palvelumuotoilun keinoja on syytä valuttaa organisaation kaikille tasoille. Palvelumuotoilulla en tarkoita asiakaslähtöisen kehittämisen projekteja tai tuplatimantin säntillistä noudattamista. En edes sitä, että yritys tulisi kyllästyttää palvelumuotoilun armeijalla tai varaamalla siivun budjetista ulkoisille palvelumuotoilutoimistoille.

Palvelumuotoilu kuuluu kaikille

Palvelumuotoilulla tarkoitan laajaa asiakaslähtöisten menetelmien ja työkalujen kattausta. Jokaisen työntekijän, tiimin, osaston pitäisi olla kosketuksissa asiakkaaseen ja siten osallistua asiakaskokemuksen kehittämiseen. Joskus asiakas löytyy oman organisaation sisältä, mutta kerrannaisvaikutus ulottuu ulkoiseen asiakkaaseen. Osallistuminen ja asiakaskokemuksen edistäminen voi olla lähes huomaamatonta ja pienimuotoista, siksi vain vähän työllistävää, joten ei ole perusteltua jättää sitä tekemättä.
Palvelumuotoilun laajentaminen organisaation lonkeroihin ja siiloihin ei saa olla päälle liimattua tekemistä tekemisen takia. Sitä ei edes tarvitse kutsua palvelumuotoiluksi. Olennaista on hyödyntää palvelumuotoilun käytännönläheisiä työkaluja, jotka edistävät asiakaslähtöistä ajattelua ja tekemistä. Näitä ovat muun muassa arvolupauskanvas, asiakas- ja käyttäjäpolut sekä palvelupyyntöjen analysointi. Kun palvelumuotoilun keinot otetaan eri tavoin käyttöön, asiakkaan kokemus ”sellaisesta hyvästä tunteesta” saa sisällön.

Palvelumuotoilu – oli sen nimi, mikä tahansa – on pieniä ja isoja tekoja kohti parempaa asiakaskokemusta. Jokaisen työntekijän tulisi löytää sisäinen palvelumuotoilijansa ja muotoilla yhdessä sovittu asiakaslähtöinen harjoite. Asiakaslähtöisen teon valinnassa ja toteutuksessa auttaa organisaation palvelumuotoilutiimi, millä nimellä se toimiikaan, tai ulkopuolinen asiantuntija. Asiakaskeskeisen tekemisen pitää olla osa jokaisen työntekijän työtä. Siinä pitää näkyä ilo palvella asiakasta. Tulos seuraa perästä.

Jos haluat kassaa, kasvata asiakasymmärryksen massaa.

Lataa voittavan asiakaskokemuksen -opas!

Kun ketteriä toimintatapoja otetaan käyttöön tai lähdetään parantamaan, on syytä ensin varmistaa, että ketteryyden perusasiat ovat kunnossa. Muutos helpottuu paljon, kun se voidaan perustaa tukeville peruspilareille. Ongelmien ratkominen uusilla toimintamalleilla, prosesseilla tai työkaluilla tuntuu tällaisiin parannushankkeisiin osallistuvista ihmisistä usein turhalta hukkatyöltä. Perusasioiden laittaminen kuntoon mahdollistaa tehokkaammat muutoshankkeet.

Ketteryyden neljä peruspilaria

Huomio pitää ensin kiinnittää näihin neljään asiaan. Vasta kun nämä ovat kunnossa, kannattaa edes harkita muiden asioiden kehittämistä.

Perusasia 1: Tuotevisio

Tuotevisio on tärkein neljästä peruspilarista. Visio on se iso tavoite, mitä kohti tuotetta ollaan viemässä. Se kuvaa yleensä tilannetta usean vuoden päässä. On eri tapoja kuvata tämä tuotteen tavoitetila. On tärkeää määritellä asiakasongelma, minkä tuote ratkaisee ja edut kilpailijoihin nähden.

Tuotevisio toimii tiimille pohjantähtenä, opastavana ajatuksena taivaanrannassa. Sitä kohti ollaan matkalla. Jokainen pieni työtehtävä vie tiimiä ja tuotetta kohti tätä visiota. Vastaan tulevissa päätöksentekotilanteissa itse kukin voi miettiä, mikä vaihtoehdoista vie kohti tavoitetta.

Vuosien päässä tulevaisuudessa oleva visio tuntuu kaukaiselta ja sitä pitääkin jatkuvasti palautella tiimin mieliin. Sitä voi pilkkoa myös pienempiin askelmiin – vuositavoitteisiin tai release-kohtaisiin visioihin. Asiakaskohderyhmä voi muuttua vuodesta tai releasesta toiseen. Kun release kohdistuu palvelemaan hyvin tiettyä asiakasryhmää, priorisointi helpottuu.

Jos tuotevisio puuttuu, tuoteomistajan on mahdotonta priorisoida backlogia ja kehittäjien on mahdotonta kehittää ratkaisua pienin päätöksin oikeaan suuntaan.

Perusasia 2: Tuoteomistaja ja tiimi

Tärkeysjärjestyksessä oleva backlog on ketteryyden ydin.

Tuoteomistaja määrittelee prioriteetin

Jos prioriteetteja ei määrittele kukaan, tai priorisointi tapahtuu kovaäänisin tai suuripalkkaisin päättää -periaatteella, ketterä tiimi ei voi tehdä töitään tehokkaasti. Tällaisesta nollapriorisoinnista seuraa myös se, että tiimi ei tunne oloaan turvalliseksi. On hankala tuntea työn iloa ja motivaatiota tärkeän asian tekemiseen, jos ei ole varma, että asia on oikeasti tärkeä.

Priorisointipäätökset ovat mahdollisia vain, jos ne ovat selkeästi yhden henkilön vastuulla. Tämän takia tuoteomistaja on niin tärkeä rooli.

Kun priorisointi on kunnossa, seuraavaksi tärkein asia on itseohjautuva ja toimintaan valtuutettu tiimi.

Itseohjautuva ja valtuutettu tiimi

Itseohjautuvuus tarkoittaa sitä, että kukaan ei jaa tehtäviä tai käske tekemään asioita, vaan tiimin jäsenet vapaaehtoisesti aloittavat uudet työt backlogin huipulta.

Tiimin jäsenet myös valvovat ja auttavat toinen toisiaan. Ketään ei jätetä yksin ongelmien kanssa. Jos joku jää jumiin, muut hidastavat ja tulevat auttamaan. Tiimi kokee vastuuta tehdä hyvää työtä, tarpeellisella laatutasolla.

Toimintaan valtuutus tarkoittaa sitä, että tiimi ottaa vallan tehdä työtä ja päätöksiä, jotka vievät tiimiä ja tuotetta kohti visiota. Pyydetään mieluummin anteeksi, kuin lupaa tehdä jotain. Jos törmätään ongelmiin, ne ratkaistaan.

Perusasia 3: Backlog

Nyt meillä on suunta, tärkeysjärjestys ja intoa puhkuvat tekijät. Seuraavaksi pitää varmistaa, että ymmärretään mitä ollaan tekemässä. Tämä tarkoittaa backlogin jalostamista ja siihen liittyviä käsitteitä Definition of Ready ja Definition of Done.

Backlogin jalostaminen

Viikoittain toistuva backlogin jalostustilaisuus auttaa tiimiä ymmärtämään backlogilla olevia asioita, ja ottamaan ne työn alle oikean kokoisina ja oikein määriteltyinä. Tunti viikossa on tähän hyvä aikainvestointi. Backlogin jalostustilaisuudessa tuoteomistaja ja tiimi keskustelevat tärkeimmistä seuraavista töistä, ymmärtävät miksi ne tarvitaan, ja mitä ne sisältävät. Keskustelu on avain – ilman sitä ei voida olla varmoja siitä, että ymmärretään tehtävät asiat samalla tavalla.

Definition of Done

Definition of Done (DoD) on tiimin sopimus siitä, milloin työn alla oleva asia voidaan katsoa valmiiksi. Se siis on kaikille backlogilla oleville asioille yhteinen. DoDin avulla kaikki tiimin jäsenet ymmärtävät mitä yleensä töille pitää tehdä.

DoDn avulla tehdään myös työmääräarviointi. Työmäärän arvioinnin perimmäisenä tarkoituksena on estää liian isojen ja epäselvien töiden aloittaminen kerralla. Sivutuotteena siitä saadaan ennustamista helpottavaa dataa (velocity).

Definition of Ready

Definition of Ready (DoR) on monille outo termi. Se tarkoittaa DoDin tapaan tiimin sopimusta. Nyt sovitaan siitä, millä tavalla määritelty työ on valmista aloitettavaksi. Sinäkään et syö raakaa lihaa, vaan paistat sen ensin. Vasta sitten se kelpaa syötäväksi. Definition of Ready tarkoittaa siis sitä, että pihvi on paistettu. Definition of Done on se, että se on syöty.

DoR kertoo siis tiimille sen, miten asiat pitää olla määritelty. Se estää sen, että kukaan ei ota liian isoa, tyhjää tai epäselvää asiaa työn alle.

DoD ja DoR on helppo määritellä yhdessä tiimin kanssa. Se vaatii vaan noin tunnin kestävän työpajan. Backlogin jalostuskokoukseen käytetään säännöllisesti tunti viikossa

Nämä aikasijoitukset saadaan takaisin, kun tehty työ osuu maaliin paljon entistä suuremmalla tarkkuudella.

Perusasia 4: Palaute ja oppiminen

Nopea palaute

Kun työ on valmis, tärkeintä on varmistaa, että ongelma ratkaistiin oikealla tavalla. Pitää saada palautetta. Tämä onnistuu näyttämällä valmiiksi saatu työ sitä tarvitsevalle ihmiselle tai antamalla hänen kokeilla sitä. Jos tässä vaiheessa paljastuu, että tarvitseekin tehdä jotain muuta, voidaan korjaukset tehdä saman tien. Palautteen saamisessa tärkeää on, ettei odoteta liian pitkään.

Retrospektiivit säännöllisiksi

Tiimin pitää vielä miettiä, menikö kaikki hyvin, vai tehtäisiinkö seuraavalla kerralla jotain toisella tavalla. Tämä tehdään retrospektiivissa.

Kuten kehitysjonon jalostaminenkin, retrospektiivikäytännönkin pitää olla säännöllistä. Retroille riittää kerran kuussa tapahtuva mietintä. Tärkeää on paljastaa ongelmia, keskustella syvemmin jostain asiasta, miettiä sen juurisyitä ja sitten mahdollisia toimenpidevaihtoehtoja.

Retrospektiivit ovat ajanhukkaa, jos asioille ei tehdä mitään. Tiimi pitääkin valtuuttaa ja pakottaa tekemään parannustoimenpiteet ennen seuraavaa retrospektiiviä. Tiimi ei saa oppia tapaa, että sovitut toimenpiteet voidaan jättää tekemättä. Hyvä vinkki on nostaa sovitut toimenpiteet suoraan backlogin huipulle.

Visio – roolit – backlog – palaute

Lähde liikkeelle visiosta – anna tuotteelle selkeä tavoite. Seuraavaksi, valtuuta tiimi ja tuoteomistaja. Pidä huolta, että uskalletaan tehdä päätöksiä ja töitä. Avoimuus on tärkeää. Suunnitelmien, backlogin, tulosten ja parannuskohteiden on oltava julkisia.

Backlogin jalostamiseen käytetty aika ja energia on hyvä sijoitus. Tiimin sopimukset siitä, millaista työtä aloitetaan ja mitä sitten tehdään ovat olennaisia osia jalostamisessa.

Lopuksi – pakota tiimi ottamaan palautetta ja tekemään parannustoimenpiteitä.

Puutteet näissä asioissa johtavat kasvaviin ongelmiin myöhemmin. Jos taas nämä asiat saadaan ensin kuntoon, sitten voidaan lähteä rakentamaan tämän päälle mitä vaan.

Onnistunut yksinkertaistus vaatii monimutkaisten asioiden laajaa ja syvällistä ymmärrystä. Monimutkaisuus ja yksinkertaisuus eivät ole toistensa vastakohtia, ne ovat kolikon kääntöpuolia.

Monimutkaisen asian yksinkertaistus

Jokaiselle monimutkaiselle ongelmalle on vastaus joka on selkeä, yksinkertainen sekä väärä (alkuperäinen lainaus: For every complex problem there is an answer that is clear, simple, and wrong.). Edesmennyt amerikkalainen yhteiskuntakriitikko H.L Mencken tiivisti yksinkertaistamisen haasteet hyvin.

Monimutkaisten asioiden yksinkertaistaminen on aikamme suurimpia haasteita. Uuden monimutkaisen haasteen kohdatessaan osasta ihmisiä tulee alan asiantuntijoita, ja he löytävät yksinkertaisen ratkaisun monimutkaiseen ongelmaan. Tämä ratkaisu on lähtökohtaisesti väärä.

Yhteiskuntien kohtaamat haasteet ovat oma lukunsa, mutta sama asia on totta organisaatiossa. Kun joku asia ei toimi, niin siihen mielellään löydetään ratkaisu, joka on helppo ja helposti ymmärrettävä. Suoraviivainen päättelyketju jonka avulla ongelma ratkeaa.

Nämä yksinkertaiset ratkaisut monimutkaiseen ongelmaan vievät ongelmaa syvemmälle. Ongelmat poistavaa hopealuotia tai kaikki vaivat parantavaa käärmeöljyä on harvoin olemassa.

Yksinkertaistaminen menestyksen takana

Yksinkertaistaminen on lähes jokaisen menestyvän tuotteen ja aatteen takana. Yksinkertaistaminen siis on tärkeä menestymisen taito.

Esimerkkeinä tuotemaailmasta ovat Google -haku tai iPhone. Ne yksinkertaistivat oman ongelmakentän ja tulivat tämän kautta supersuosituiksi. Toimintatapamaailmassa tällaisia löytyy tuotekehityksen scrum-mallista tai markkinoinnin inbound-ajattelusta. 

Harva kuitenkin ymmärtää, kuinka paljon työtä onnistunut yksinkertaistaminen vaatii. Yksinkertaistaa voi vain ymmärtämällä syvällisesti monimutkaisen ongelmakentän.

Tuotekehitysmaailmassa, jossa itse valmennan, moni aate on menestynyt yksinkertaistamisen vuoksi. Ketteryys esimerkiksi on helppo käsite. Se sisältää ajatuksen, että reagoidaan nopeasti muuttuvaan tilanteeseen. Kuitenkin organisaatioilla on mieletön määrä interaktioita ja rajoitteita niin sisäisesti kuin ulkoisestikin, joista ei voi luopua vain siksi että valitaan olla ketteriä. 

Teknologisella puolella pilveistäminen on samanlainen ilmiö. Viedään sovellukset pilveen, jotta ne ovat turvallisesti saatavilla ympäri maailman. Samalla ne skaalautuvat kaikkiin tarpeisiin ja maailma on auki menestykselle. Tämän yksinkertaistuksen voi tehdä kuka vaan, mutta harva ymmärtää sen alla olevan logiikan, jolla tuo kaikki saadaan toimimaan.

Ajatukset siis ovat oikeita ja tärkeitä, mutta niiden toteuttaminen vaatii paljon muuta kuin yksinkertaisen termin ymmärrystä.

Uskalla ensin monimutkaistaa

Asioiden tarkastelu monilta eri suunnilta luo ymmärrystä. Jokaisella ilmiöllä on aina monia täysin valideja tarkastelukantoja. Ilmiöt ovat monimutkaisia ja monimutkaistaminen kannattaa uskaltaa tehdä. Vain sitä kautta voi mahdollisesti päästä yksinkertaistukseen.

Esimerkiksi menestyvä tuote on hyvin monimutkaisen ilmiön lopputulema. Sen takana voi olla hyvä kiteytys tai oivallus, joka luo pohjan löytää tuotteelle ainutlaatuisen kilpailuedun.

Tämän kilpailuedun saavuttaminen vaatii hyvinkin monimutkaista toteutusta, jotta se saadaan päällepäin näyttämään yksinkertaiselta.

Monimutkaisuuden ymmärtämisestä voi tulla yksinkertaista ja yksinkertaisen toteutus vaatii lopulta monimutkaista ajattelua.

Yksinkertainen vai monimutkainen

Yksinkertaisuus voi olla vain monimutkaisuuden ymmärtämisen lopputulema. Jos yksinkertaisen ilmiön tai ajatuksen takaa ei löydy kuvausta monimutkaisuudesta, niin kannattaa epäillä yksinkertaisuuden todenmukaisuutta.

Yksinkertaista ideaa kannattaakin katsoa pintaa syvemmälle. Onko idean takana ymmärrys monimutkaisuudesta vai onko kyseessä vain tietämätön heitto? Monimuotoisessa mediassa moni tietämätön heitto otetaan vastaan samalla tapaa kuin hyvin pohdittu yksinkertaistus. 

Yksinkertaisia ohjeita rakastetaan ja niitä halutaan kuulla. Se yksi ohje, jolla menestyt. Voi olla, että yksi oivallus tuo menestyksen. Useimmiten sen takana on monimutkainen tapahtumaketju tai ilmiö, joka pitää vain ensin ymmärtää.