Miten itseohjautuvuus viedään yrityksessä totuttua pitemmälle?

 

”Useimmille firmoille on valtavasti hyötyä siitä, että työntekijät pääsevät suoraan vaikuttamaan. Se taas vaatii, että yrityksen johto uskaltaa antaa työntekijöilleen tilaa menestyä.”

Lausuin noin Tivi-lehden haastattelussa ja uskon siihen vahvasti. Johtajuus ei silti häviä mihinkään vaikka sen antaa levitä organisaatiossa entistä tasaisemmin ja lähemmäksi asiakasta.  

Codento on mukavasti kasvanut konsultointialan yritys, jonka hallitus joutui reilun 20 hengen yrityksen koossa miettimään, miten yritys tästä kasvatetaan yli 100 hengen kokoon kentässä, jossa sekä tekijöistä että asiakkaista kilpaillaan verisesti, mutta hymyssä suin.

Totuttu tapa olisi ollut väliportaan johdon luominen, mutta me päätimme siirtyä alkavasta hierarkkisesta mallista täysin toiseen suuntaan, itseohjautuvuuteen.

Vanhat tavat istuvat sitkeässä, mutta S3 hurmasi lopulta

Alku oli vaikeaa, hierarkiset toimintatavat ovat meillä kaikilla reflekseissä eikä uudelle mallille syntynyt tilaa kun päätökset tapahtuivat kuten ennenkin.

Etsimme vaihtoehtoja ja malleja ja toivoimme löytävämme “avoimen lähdekoodin” mallin, joka näyttäisi meille sopivalta, ja ehkä jopa laajempaa suosiota saavalta. Pienen etsinnän jälkeen löysimme S3 (tai virallisesti Sosiokratia 3.0) -mallin, joka tuo uudet työkalut yhteisölliseen päätöksentekoon.

Parin S3-koulutuskerran jälkeen jätimme vanhan taakse, lopetimme johtoryhmän ja siirsimme vastuut S3-tyyppisesti piireille, eli yhden teeman ympärillä tapaaville päätöksentekoelimille.

Päätös oli pelottava…monet meistä tietotyöläisistä ovat tottuneet tehottomuuteen ja päättämättömyyteen porukassa. Juuri tämän ratkaisemiseen S3 keskittyy, eli sen ytimessä ovat palaverikonventiot, jotka tuovat kaikille tilaa ja pitävät kovaäänisimmät paremmin kurissa.

Codentolaisia S3-valmennussessiossa.

Plussia ja miinuksia

Nopeampaa, parempaa päätöksentekoa. Yksi S3:n periaatteista, “Riittävän hyvä juuri nyt, kelpaa kokeiltavaksi” (englanniksi “Good enough for now, safe enough to try”), kajahti yhdessä jos toisessakin palaverissa ja alkukankeuden jälkeen päätöksiä on syntynyt nopeammin, tehokkaammin ja tarkemmin asiakkaiden tarpeet huomioon ottaen kuin koskaan aiemmin.

Kasvua ja rekrytoinnin onnistumisia. Yritys kasvoi viime vuonna 14 uudella osaajalla, nopeammin kuin koskaan Codenton historiassa. Muutoksen hinta oli kuitenkin kova; useampi kokenut konsultti ei ollut valmis tähän muutokseen ja valitsi lähteä talosta.  

Parempaa asiakaspalvelua ja -tuntemusta. Mitä enemmän olemme siirtäneet strategisten kokeilujen päätöksentekoa niille, jotka elävät etulinjassa asiakkaiden kanssa, sitä paremmin kokeilumme ovat menneet ja sitä paremmin projektimme luistavat. Tyytyväinen asiakas on paras mittari.

Kuvassa Codenton devaajat Miili, Jukka ja Turo. Turo Mikkonen (oik.) on myös uusi hallituksemme puheenjohtaja.

Ensimmäinen S3-hallitus

Hallitus tekee monenmoista yrityksessä; seuraa, valvoo, hoitaa lakisääteiset tehtävät ja hyväksyy strategian ja tärkeät muutokset toimintatavoissa. Hallitus on osakkeenomistajien ääni yritykseen.

Ensimmäisen täyden S3-vuoden jälkeen huomasimme, että itseohjautuvuuden ja hyvän ulkopuolisista koostuvan hallituksen välillä on jännite. S3-malli korostaa jännitteiden huomaamista, nimeämistä ja ratkomista.

Ratkoimme tätä jännitettä kirjaamalla hallituksen moninaiset roolit ja mietimme tarkkaan, miten ne voisivat parhaiten toteutua itseohjautuvassa yrityksessä. Onko hallitus edes tarpeen? Voiko ilman sellaista elää?

Hallitus onkin lakisääteisesti pakollinen, ja sen on oltava aktiivinen, mutta se voi olla aivan eri tavalla miehitetty kuin tavallisesti. Suuri osa entisestä hallitusroolista on nyt jakautunut erilaisille piireille, joista parhaat hoitavat jo vastuunsa selvästi paremmin kuin hallitus parhaina päivinäkään.

Mitä sitten oikeastaan päätimme tehdä?

  1. Olemme jakaneet kaiken jaettavissa olevan tiedon kaikille työntekijöille jo vuosien ajan.
  2. Hallitusvastuun voi jakaa helpommin kun kaikki tietävät jo kaiken, minkä haluavat tietää.
  3. Valitsimme työntekijöistä 1+1 hengen hallituksen.
  4. Hallituksen tärkeät seurantavastuut toteutuvat paremmin kuin koskaan ennen: konsulttiyrityksen sisältä näkee paremmin, miten yrityksessä menee ja missä riskit ovat.
  5. Virallisia hallituksen kokouksia tulee silloin, kun tarvitaan virallinen hallituksen päätös. Molemmat hallitusvastuussa olevat tekevät tuolloin yhteistyötä ja heille on saatavilla paras rahalla ostettava lainopillinen apu, tarvittaessa.
  6. Useimmat hallituspäätökset on vastuutettu Codenton viikkokokoukselle. Teemme yhdessä parempia päätöksiä kuin vain osa meistä – ja tämä koskee myös tärkeitä strategisia päätöksiä.
  7. Ulkopuolista näkemystä tuomaan kutsumme alojensa parhaita asiantuntijoita. He tuovat päätöksentekoon ulkopuolista näkemystä ja luovat tilaa pitkäjännitteiselle keskustelulle ja päätöksenteolle.  Olemme projektiorganisaatio ja uskomme projektien voimaan niin omassa työssämme kuin asiantuntijoiden neuvoissa.
  8. Kaikkein kimuranteimpia tilanteita varten olemme varautuneet pitämään ylimääräisiä yhtiökokouksia. Osakkeenomistajien ääni on hyvä käydä hakemassa suoraan silloin, kun oikea reitti ei ole selvä.

Olen aivan fiiliksissä. Päällimmäisinä innostus, kiitollisuus ja kasvava opinhalu. Opimme yhdessä joka päivä lisää.

Petri
Twitter @aukia

Katso Codenton avoimet työpaikat

Modern Agile – Miten organisaatiosi voi onnistua ketterässä kehityksessä?

Kun organisaatiossa otetaan käyttöön uusia toimintatapoja kuten ketterää kehitystä, yksi tärkeimmistä käytännön kysymyksistä on:

Miten työtapa skaalataan? Miten kaikki saavat sen käyttöön, ja miten se toimii eri laajuisissa projekteissa ja tiimeissä?

Kauttaaltaan ketterä tai lean organisaatio tarvitsee  usein melko kattavan valikoiman työvälineitä. On pystyttävä muodostamaan mielekäs visio, hahmottamaan omien työtapojen toimivuus ja tekijöiden hyvinvointi.

Tähän on saatava kytketyksi organisaation arjen jatkuva kehitystyö ja sen tulosten mittaaminen. Ja jotta työtapojen muutos olisi todellinen, tarvitaan  tiimeiltä ja ihmisiltä omakohtaisia oivalluksia.

Modern Agile -periaatteet lyhyesti

Perinteisesti tarvetta on ratkaistu erilaisten skaalattujen ketterien viitekehysten avulla. Nyt pari vuotta keskustelua herättänyt Modern Agile -liike pohtii asiaa uudesta kulmasta:
Mitä jos keskityttäisiinkin kehitysmekanismien sijaan ketteryyden perimmäisiin arvoihin?

Modern agile -ajattelu lähtee siitä, että ketterässä kehityksessä oleellista eivät ole kehitystyön käytännöt vaan sen arvot ja tulokset. Modern agilessa ajatellaan, että mikään ketterä kehitys ei voi onnistua ilman neljää keskeisintä periaatetta:

  1. Kehityksestä syntyy jatkuvasti mitattavaa arvoa loppuasiakkaille
  2. Kehitystä tehdään turvallisesti: riskit on rajattu ja ne kannetaan yhdessä
  3. Kehityksen haastavimmat osat tehdään kokeiluina, joiden tulokset mitataan ja niistä opitaan
  4. Innostuneet ja osaavat ihmiset ovat kaiken ytimessä

Muutos onnistuu vain jos se auttaa koettuihin haasteisiin

Mikä sitten erottaa onnistuneen kehitystavan muutoksen siitä toisesta, joka kyllä alkoi reippaasti mutta joka jostain syystä vain hyytyi matkan varrella?

Rohkea väite: se, vastaako muutos tekemisessä oleviin akuutteihin haasteisiin.

Niinpä kehitystä kannattaa viedä eteenpäin käytännöillä, jotka parhaiten ratkovat kulloinkin kiperimpiä kehitystyön haasteita.

Moduuli joka neljänneksestä, kerralla korkeintaan viisi

Korporaation kypsään ketterän kehityksen systeemiin tarvitaan tyypillisesti seuraavat elementit, jotka käytännössä turvaavat arvontuotantoa, kehitystyön turvallisuutta, kokeilukulttuuria ja ihmisten onnistumista:

 

 

Näitä kaikkia ei kuitenkaan kannata yrittää laittaa paikoilleen kerrallaan. Kannattaa mieluummin valita ensin se kourallinen, joka parhaiten ratkaisee kehitystyön koettuja ongelmia, ja siirtyä seuraaviin sitten kun ensimmäiset pulmat on ratkottu.

Jotta tuloksena on menestyskelpoinen kehitysmalli, elementtejä on hyvä valita kaikista neljänneksistä. Omaksumisen kannalta niitä on hyvä olla harjoittelussa kulloinkin enintään viisi kappaletta – enemmän on useimmiten liikaa kerralla.

Mistä näissä moduuleissa sitten on tarkemmin kyse?

 

1. ..Toimita arvoa jatkuvasti

Kehitystyöllä ei ole edellytyksiä, ellei se tuota liiketoiminnalle eli lopulta asiakkaille ja/tai käyttäjille arvoa.

Mikä sinun organisaatiossasi tällä hetkellä auttaisi eniten siinä, että pystyisitte tekemään asiakkaat nykyistä onnellisemmiksi?

Käyttäjälähtöinen kehittäminen tähtää sen ymmärtämiseen, mikä asiakkaalle on arvokasta, ja oikeiden ratkaisujen löytämiseen. Käytännössä eri tutkimusmenetelmillä opitaan käyttäjän tarpeista ja testataan ja protoillaan mahdollisia ratkaisuvaihtoehtoja ennen kuin ratkaisuihin on investoitu liian paljon.

Kehityksen käytännön työtavat kuten Scrum tai Kanban varmistavat, että saadaan optimoiduksi arvon syntymistä suhteessa käytettävään kehitystyöhön. Menetelmät auttavat tiimejä tekemään kehityksestä ja sen synnyttämästä arvosta läpinäkyvää, optimoimaan työn virtausta ja havainnoimaan ja sopeuttamaan edistymistä ja suunnitelmia.

Ketterä julkaiseminen varmistaa, että kehitystyön tuloksia saadaan tarpeeksi usein asiakkaiden käyttöön. Liiketoiminnasta ja sen ympäristöstä riippuu, miten usein  tämä käytännössä on – mitä useammin, sitä oleellisempaa on että julkaisemisesta tehdään helppoa.

 

2. Tee turvallisuudesta lähtökohta

Muutos kehitystavoissa ei tule etenemään, elleivät kehitystyö ja muutos ole sitä tekeville ihmisille turvallista. Mikäli työympäristöstä puuttuu psykologinen turvallisuus, ihmiset alkavat suojautua ja taantua kohti perussuorittamisen tasoa, ja kehitys pysähtyy.

Mikä tällä hetkellä auttaisi eniten sinun organisaatiossasi turvallisuuden lisääntymistä?

Yhteinen työtapasopimus kertoo tekijöille, miten on tarkoitus toimia ja mitä on lupa odottaa kehitystyössä. Ennen työtapasopimuksen tekemistä sen sisältämiä käytäntöjä on hyvä pilotoida, jotta nähdään niiden toimivuus käytännössä. Työtapasopimuksen kannattaa olla mahdollisimman pieni, jotta tekijöillä on tilaa soveltaa sääntöjä älykkäästi tilanteen kulloinkin vaatimalla tavalla.

Lean-portfolionhallinta varmistaa osaltaan turvallisuutta huolehtimalla, että kehityshankkeet ovat järkeviä suhteessa yhteiseen tavoitteeseen ja että niiden keskinäinen priorisointi on mietitty. Se auttaa hahmottamaan strategiakytkyn lisäksi kehityshankkeista asiakkaille syntyvää arvoa ja varmistaa tekemisen edellytykset rullaavalla ennustamisella ja budjetoinnilla.

Ketterä ohjaus ja hankinta huolehtii, että yksittäisillä kehityshankkeilla on niiden tarvitsema tuki ja resurssit. Ketterässä ohjauksessa kehitystyötä ohjataan tavoitteiden ja niiden toteutumisen mittaamisen tasolla. Toisin sanoen päivittäinen päätöksenteko jätetään tekijöille, joilla on hallussaan arjen kontekstiymmärrys ja tarkin näköyhteys muuttuviin olosuhteisiin. Jos resurssien turvaamisessa tarvitaan hankintaa, se tehdään ketterien toimintatapojen pohjalta.

 

3. Kokeile ja opi nopeasti

Kehitystyöstä saadaan nopeimmin hyötyjä irti, kun siihen sisältyy kokeilemisen ja nopean oppimisen elementti.

Miten kokeiluja pystyisi tällä hetkellä sinun organisaatiossasi parhaiten mahdollistamaan, jotta päästäisiin kohti jotakin mitä asiakkaat tällä hetkellä kaipaavat?

Nopeiden kokeilujen PDCA-sykli on oppimisen ytimessä. PDCA tulee sanoista plan, do, check, act, ja sillä on myös toisin nimettyjä sovellutuksia esim. lean startup – ja lean change management -kehyksissä. Kaikissa niissä on sama idea: tunnistetaan mahdollinen ratkaisu, kokeillaan sitä, analysoidaan palaute ja toimitaan tulosten pohjalta.

Jatkuva parantaminen on ehkä tärkein ketterän kehitystavan filosofinen ydin: mikäli omasta toiminnasta ei jatkuvasti opita ja pyritä kehittämään sitä, kehitystyön potentiaalista jää ajan mittaan toteutumatta valtava osuus. Jatkuvan parantamisen luuppi myös tekee tekijöille työstä valtavasti mielekkäämpää.

Sisäiset startupit ovat hyvä ratkaisu silloin, kun jokin tiimi yrittää tehdä jotakin, joka on hyvin uutta toimintaympäristölle. Silloin saadaan kehityksen tekijöille aikaiseksi suojattu ympäristö, jossa he voivat keskittyä tulosten aikaan saamiseen sen sijaan että kamppailisivat ympäristön kanssa uudenlaisen toimintatapansa puolesta.

 

4.  Auta ihmisiä onnistumaan

Paras kehitysympäristö syntyy lopulta silloin, kun siinä toimivat ihmiset ajavat asioita eteenpäin innostuneina ja intohimolla. Tulokset moninkertaistuvat, kun tekemiseen tulee ihmisten henkilökohtaisen panoksen myötä valtava määrä lisäenergiaa.

Mitä teidän organisaationne ihmiset tällä hetkellä eniten kaipaisivat onnistuakseen ja kukoistaakseen?

Lean tavoitteenasetanta yhdistää organisaation yhteisen pyrkimyksen henkilökohtaiselle tasolle. Ihanteellisimmillaan ihmiset ovat aktiivinen osa keskustelua, jossa tiimeille ja ihmisille etsitään omat tavoitteet jotka edistävät organisaation yhteistä visiota.

Valmennus ja oppien jakaminen varmistaa, että ihmisillä toisaalta on yhteinen käsite- ja työvälinekehys jonka puitteissa toimia, ja toisaalta että innostuneilla on tukea toisistaan ja opit ristipölyttyvät organisaation osien välillä. Tuen oppimiseen voi käytännössä järjestää koulutuksilla, valmennuksilla ja tietopankeilla. Keskinäistä oppimista voi tukea esimerkiksi samassa rooli- tai teemaverkostoilla tai avoimilla retroilla ja kehitysympäristöillä.

Itseohjautuva kulttuuri huolehtii siitä, että ihmiset kokevat pystyvänsä kantamaan vastuuta päivittäisestä päätöksenteosta ja kehitystä kaipaaviin asioihin tartutaan. Aluksi itseorganisoituminen kaipaa usein voimakasta rohkaisua ja arjen päätöksenteon viemisen tekijöille on oltava hyvin eksplisiittistä, että uusi kulttuuri lähtee syntymään.

 

Mistä tietää miten kannattaa aloittaa?

Usein kehitystyön tekijöitä haastattelemalla pääsee hyvin kiinni kiperimpiin ratkaistaviin teemoihin. Tyypillisesti ihmisillä on melko hyvä konsensus siitä, mikä seuraavaksi kaipaisi tarttumista. Ja niille teemoille työtapauudistus on hyvä perustaa.

Ihmisten kuulemisen lisäksi on kuitenkin tunnistettava myös, mihin kehityksellä pyritään ja minkälaisessa ympäristössä sitä tehdään, esimerkiksi arvoketjukartan avulla.  Esimerkiksi syntymässä olevien teknologioiden parissa puurtavan startupin Modern Agile on yleensä erittäin erinäköistä kuin vakiintuneella teollisuudenalalla tahkoavan konserniyhtiön. Ja niin sen kuuluu ollakin.

Tärkeimmäksi kysymykseksi jää, miltä tehokkain mahdollinen ketterä kehitys juuri nyt teidän tavotteillanne ja haasteillanne näyttäisi. Mikä juuri nyt auttaisi eniten tai vaatisi kipeimmin ratkaisua? Kun kuva siitä on tunnistettu, muutostyö on jo puolivälissä.

Karoliina Luoto
Twitter @totoroki

Arvoketjukartta hahmottelee toimintaympäristösi – ja visioi herkullisemman tulevaisuuden

Teimme budjetoinnin ja projektien arvioinnin tueksi lean-projektikartan. Olemme nyt käyneet usean asiakkaan kanssa keskusteluja siitä, miten lean-projektikartta auttaa heitä ja miten sitä voi hyödyntää tekemisen suunnittelussa. Vaikka lean-projektikartta on yksinkertainen täyttää, tarvittavat päätökset eivät aina ole itsestään selviä. Useamman kerran olemme päätyneet keskustelemaan siitä, millä perusteilla pitäisi painottaa toiminnan ylläpitoa tai milloin pitäisi tehdä mullistavaa kokeilua asiakkaan kanssa. Kysymyksiin vastaamiseen tarvitaan kaksi asiaa: 1) Missä tilanteessa ollaan nyt ja 2) Mihin tilanteeseen toivotaan päästävän.

Vastaukset eivät selviä täyttämällä lean-projektikarttaa. Tarvitaan näkemystä toimintaympäristöstä yli ajan – tarvitaan visio.
– Toimiva visio johdattaa organisaatiota kohti haluttua tilaa ja auttaa linjaamaan päivittäiset ratkaisut pitkän ajan tavoitteeseen
– Päivittäisessä työssä auttavan vision pitää olla ymmärrettävä, sitä kohti pitää voida edetä ja sen pitää olla motivoiva

Toimintaympäristön kokonaisvaltaisen ymmärtämisen kautta muodostettu tahtotila organisaation paikasta toimintaympäristössä on tukeva pohja visiolle. Kun vielä ymmärretään organisaation kyvykkyys vaikuttaa omaan positioonsa toimintaympäristössä, ollaan jo hyvän vision jäljillä.

Me Codentolla olemme käyttäneet muun muassa Simon Wardleyn arvoketjukarttaa, kun fasilitoimme toimintaympäristön kuvaamista. Tämä malli on tehokas väline kiinnittämään keskustelu yhteiseen viitekehykseen ja luomaan yli keskustelutilanteiden kantava ja asteittain yhä tarkentuva malli toimintaympäristöstä. Wardley map eli arvoketjukartta esittää asiakkaan keskiössä. Asiakas näkee käyttämänsä palvelun muodostavasta arvoketjusta lähinnä itseään olevat osat. Asiakasta ei yleensä suuremmin kiinnosta, millä alustalla palvelu pyörii tai miten palvelu on varmistanut internet-yhteytensä tai sähkönsaantinsa – palveluntarjoajalle tämä on kriittistä tietoa.

Jos liiketoimintasi on tuottaa asiakkaillesi välitöntä nautintoa vaikkapa ketterällä macaron-keksien toimituspalvelulla, sinun kannattaa miettiä hyvin tarkkaan miten palvelua tuotat nyt ja jatkossa. Siinä missä teknologian hype-sykli kuvaa yksittäisten teknologioiden kypsymistä yli ajan, Wardley map auttaa ymmärtämään sitä toimintaympäristöä, jossa organisaatio toimii nyt ja yli ajan. Siksipä arvoketjukartassa organisaation arvontuottoketjun kannalta olennaiset toimijat kuten esimerkiksi kilpailijat, toimittajat ja jakelijat kuvataan yhteen kuvaan. Samalla arvioidaan, millä tahdilla ne ovat kypsymässä uutuudesta massahyödykkeeksi. Lisäksi mietitään, mihin omaa organisaatiota kannattaisi toimintaympäristössä luotsata. Mikä olisi sen visio.

Saattaa olla että ketterä macaron-keksien toimituspalvelu menestyy juuri nyt hyvin – mutta jatkoa suunniteltaessa on vaarallista katsoa sitä mitä tapahtuu juuri nyt. Asiakkaasi sanovat, että haluavat makuja mielialansa mukaan. Lähdetkö toteuttamaan toivetta upouutta tilausdrone-konseptia kehittämällä vai pelaatko korttisi niin, että olet ensimmäisten joukossa käyttämässä Amazonin tarjoamaa “välittömästi mitä vain” -alustaa? Molemmat voivat olla voittava käsi, mutta onko organisaatiollasi varaa tehdä molemmat? Ja jos ei, millä kriteerillä valitset? Arvoketjukartta auttaa hahmottamaan tulevaisuuden menestysvisiot.

Jos haluat sparrausta, ota yhteyttä! miika.kuha@codento.com

 

 

DevOps on kuin robotisaatio

DevOps on mukavan lähestyttävä trendi. Sitä voi tavoitella pienissä pätkissä ja jo ensi askeleista voi olla suuri hyöty, kunhan ne on oikein valittu.

Hyvien tai erittäin hyvien ohjelmistojen kehittäminen oli ennen kuin Rolls Roycen käsin rakentamista. Hidasta, kallista ja jokainen työvaihe vaati erikoisammattilaisen, jotta kokonaisuus ei kärsisi. Jokaisen vaiheen käsityö on asiakkaasta tuntunut tärkeältä, sillä onhan valitulla mallilla ennenkin saatu hyviä rollsseja.

Kokeilua ja yhteistyötä

DevOps on kokeilevan kehityksen toimintamalli, jossa sovelluksia kehitetään pikaisesti iteroiden ja matalalla kynnyksellä. Aiemmin kehittäjät (Development) ja tuotanto (Operations) ahersivat omissa siiloissaan ja yhteistyö ei ollut aina kovin tiivistä. Kehittäjät kehittivät ja tuotanto vastasi järjestelmien pyörityksestä. Siilojen väliin katosi paljon tärkeää tietoa.

Enää edes maailman superrikkailla ei ole varaa tehottomiin työtapoihin. Tehtailla noudatetaan kiltisti tehokkaita Lean-menetelmiä ja ne työvaiheet, jotka voidaan, automatisoidaan robotein ja alihankinnan kautta. Turhat siilot on purettu. Kun kokonaisuus on hyvin hallittu, teknologia ei heikennä laatua vaan itse asiassa parantaa sitä.

“DevOps tarvitsee olutta”, innosti seminaaripuheessaan virolainen DevOps-evankelista Kaimar Karu, tarkoittaen sitä, että kehittäjien ja tuotannon tulee viettää aikaa yhdessä ja tutustua toisiinsa.

DevOpsilla parempaa softaa nopeammin

DevOps on toimiva kattonimi sille, että ohjelmiston kehittämistä, testausta, käyttöönottoa ja ylläpitoa lähestytään prosesseina, jotka kannattaa mahdollisuuksien mukaan saada kerrasta toiseen tehtyä juuri samalla tavalla. Investoimalla alussa työaikaa, ja ehkä vähän työkaluihinkin, saadaan työvaiheet, joiden teko oli ennen työlästä, toimimaan täysin tai osin automaattisesti.

Kun DevOpsissa onnistutaan, yritys menestyy ja paradoksaalisesti Rolls Roycen tai Valmetin autotehtaan tavoin, palkkaa lisää väkeä tekemään yhä enemmän tulosta. Suurin hyöty on usein siinä, että hyvin robotisoitu, eli devopsattu, ohjelmistokehitys tuottaa parempaa softaa nopeampaan tahtiin. Tällaista on mukava kaupata asiakkaille.

Moni uusi johtamismalli on haastava ottaa käyttöön, sillä monista malleista saadaan hyötyjä vasta vuosien kuluttua. DevOps on käyttäjäystävällisempää ja ketterämpää. Useimmissa organisaatioissa ensivaiheet, kuten ohjelmiston automaattinen kääntäminen lähdekoodista ajokelpoiseksi (continuous integration eli CI) tai ohjelmiston automaattinen asentaminen käännöksen jälkeen testilaitteistoon, kuten servereille, on varsin suoraviivaista.

Oletko ottanut jo ensimmäisen askeleen devopsiin yrityksessäsi? Mitä ajattelit tehdä tämän eteen seuraavassa strategisessa suunnittelupalaverissa?

-Petri
Twitter @aukia

 

DevOps tuo yrityksellesi strategista kilpailuetua

DevOps on siitä upea termi, että harvoin löytää sanaa, jolla on eri merkitys käytännössä kaikille. Yhdelle se tarkoittaa tiettyä valikoimaa työkaluista, joilla toimintaa tehdään. Toiselle taas sitä, että koodille ajetaan välittömästi muutosten jälkeen testit, joiden onnistuttua uusi versio softasta otetaan automaattisesti käyttöön yhdessä tai useammassa ympäristössä. Nämä näkemykset eivät ole vääriä, mutta mielestämme DevOps voi kuvata laajemminkin organisaatioiden toimintaa ja tuoda strategista kilpailuetua, jonka avulla yritys voi toimia vikkelämmin ja huomioida asiakkaidensa tarpeita nopeammalla syklillä.

CALMS – DevOps viidellä kirjaimella

The DevOps Handbookin kirjoittajanakin toiminut Jez Humble loi CALMS-käsitteen kirjan muiden kirjoittajien aiemmin luoman CALMS-akronyymin pohjalta. CALMS muodostuu sanoista Culture, Automation, Lean, Measurement ja Sharing. Mallissa ei mainita ensimmäistäkään palvelua, ohjelmistoa tai työkalua, vaan nämä ovat toteutuskysymyksiä. Vaikka esimerkiksi ohjelmistokehityksen ja tuotantoonviennin automatisointi tapahtuu usein muutamalla yleisesti käytetyllä työkalulla ja järjestelmällä (Ansible, Jenkins, Docker, Kubernetes jne.) on tärkeää, ettei toimintaa suunniteltaessa takerruta liiaksi tiettyyn ratkaisuun.

“Kuka haluaa antaa devaajille rootit?”

Kulttuuri, CALMSin C eli culture, tarkoittaa DevOpsissa jaetun vastuun kulttuuria, jonka myötä perinteiset raja-aidat ohjelmistokehityksen ja järjestelmien pyörityksen väliltä kaadetaan. Itselleni tämä osa DevOps-käsitettä tuntui aikanaan erityisen vastenmieliseltä. Sysadminina olin usein tilanteessa, jossa devaajat rikkoivat muutoksilla tuotantojärjestelmiä ja omana työnäni oli ongelmien korjauksen lisäksi vastaavien tapausten ennaltaehkäisy, käytännössä käyttöoikeuksien rajaaminen. Stabiiliutta korostettiin siis merkittävästi yli muutosten.

Vastuurajojen kaatuminen on kuitenkin muuttanut pelikenttää merkittävästi. Kun aiemmin kiisteltiin, pitäisikö kehittäjillä olla pääsy tuotantoon, puhutaan nyt siitä miksi ylläpitäjänkään pitäisi kirjautua sinne. Automatisointi on kääntänyt asian päälaelleen, jolloin tuotannon testauksesta ja pystyssä pysymisestä on tullut prosessiasia, ei yksittäisten ihmisten vastuualue.

“Mä teen tän aina uuden version tullessa.”

Automatisoinnista, joka on CALMSin A eli automation, puhutaan DevOpsissa usein turhaan vain tuotantoautomaationa (Continuous Integration & Deployment), vaikka se kuuluu olennaisena kaikkeen tekemiseen. Organisaatioista löytyy usein käsin tehtäviä rutiinihommia, jotka ovat jääneet jonkun vastuulle. Yleinen perustelu on, että hommassa ei mene kuin pari minuuttia, mutta päivittäin tehtävänä tähän alkaa kulua melkoisesti aikaa. Kiireessä voi myös sattua virheitä, joista seuraa huomattavasti lisää työtä.

Hyvä alku manuaalisen työn poistamiselle on kirjoittaa asia skriptiksi, jolloin samat asiat tapahtuvat riippumatta kuka sen ajaa. Paremmaksi tilanne menee, kun skriptin ajaminen kytketään suoraan siihen toimintoon, joka sitä edellyttää. Näin asia tapahtuu aina oikea-aikaisesti ja sovitun määrän kertoja.

“En mä osaa sanoa, milloin tää on valmis.”

Lean eli CALMSin L tuo tiimin tekemää työtä näkyväksi niin tiimille kuin sen ulkopuolellekin. Työn palastelu järkeviksi kokonaisuuksiksi ja siitä vielä yksittäisiksi kehitystehtäviksi tekee suuremmankin ominaisuuden kehityksen paremmin nähtäväksi – ja tilanne aukeaa nopealla vilkaisulla myös tiimin ulkopuolisille.

Leaniin voi liittyä myös asioiden tekeminen näkyväksi esimerkiksi palvelun omalla kojelaudalla, josta löytyy yhdellä vilkaisulla sekä metriikat että ongelmatilanteet. ChatOps-käsitteellä tarkoitetaan palvelussa tapahtuvien asioiden näyttämistä ja hallintaa erilaisten integraatioiden avulla. Mikäli firma toimii muutenkin Slackissä tai Flowdockissa on luonnollista, että myös järjestelmät raportoivat tekemisistään sinne.

“Valvomme, että palvelu vastaa.”

Monitorointi, CALMSin M eli measurement, on usein palvelun saavutettavuuden tarkkailua. Kun sivuston latauksessa kestää useampi sekunti tai se ei lataudu ollenkaan, lähetetään asiasta sähköposti tai tekstiviesti. Infrapuolella valvontaan kuuluu usein myös palvelinten saavutettavuus ja kuormitus, mutta useimmiten valvonta tapahtuu noin minuutin välein ja muutaman minuutin alhaallaolon jälkeen aiheutuu hälytys. Valvonta on tällöin pakostakin reaktiivista, ja ennakointi jää usein tekemättä.

DevOps tuo monitoroinnin seuraksi mittaamisen (instrumentation), joista voi yhdistettynä puhua havaittavuutena (observability). Havaittavuus korostaa nimenomaan järjestelmien toiminnan ymmärtämistä ja sen hallintaa erilaisilla mittaristoilla. Esim. API-rajapinnan virhemäärien tarkkailu on tärkeää, mutta virheen taustalta on hyvä nähdä myös syy, mistä virheet aiheutuvat. Palvelu voi olla täysin kunnossa, vaikka APIn pyynnöistä 50 % tyssäisi virheeseen, mikäli kyse on häirintäyrityksestä. Häirintä on syytä havaita, mutta siihen on osattava reagoida eri tavoin kuin palvelun rikkinäisyyteen.

“Eihän me voida kaikille kertoa, miten nää tehdään!”

CALMSin viimeinen kirjain S eli sharing sisältää tiedon jakamisen kehityksen ja ylläpidon välillä. Vaikka työtehtävät ja vastuut sekoittuvatkin, voi tietyn tiimin pääasiallinen työ edelleen liittyä ylläpitoon. Tässä kontekstissa on äärimmäisen tärkeää, että eri asioita tekevien tiimien välillä on avoin ja toimiva keskusteluyhteys, tapahtui tämä sitten toimistolla tai jotain viestintä käyttäen. Yllättävän moni asia lakkaa hajoamasta, kun kehittäjä pääsee näkemään oman koodinsa toimintaa tuotannossa.

Jakamisen käsitettä voidaan haluttaessa laajentaa myös oman firman ulkopuolelle. Esimerkiksi Suomen OpenStack -operaattorit juttelevat kuukausittain OpenStack Finland -ryhmän myötä erilaisista ongelmista ympäristöissään. Salaisuuksien varjelun ja verisen kilpailun sijaan ratkaisuja jakamalla voidaan saavuttaa etua kaikille.

CALMS on mainio lähtökohta yritykselle, joka hakee DevOpsista parannusta ja ketteryyttä toimintaansa. Vaikka DevOpsista puhuttaessa kannattaakin sivuuttaa teknologia hetkeksi, ei tätä toki voida käytännön sovellutuksissa unohtaa. Jakamisen opit pätevät myös teknologiavalintoihin eli työkaluista ja järjestelmistä kannattaa keskustella ja kysellä. Mikäli et oikein tiedä mistä aloittaisit, kannattaa kysyä asiasta vaikka meiltä!