Olen blogannut aikaisemmin DevOpsista ja ketterän kehityksen skaalaamisesta, ja tämä blogi punoo nämä aiheet yhteen. Meillä muutkin ovat aikaisemminkin bloganneet ansiokkaasti DevOps-ajattelun tehokkuudesta. Tapio Rautonen totesi ansiokkaasti jo 2013, että ”infrastruktuurin hallinnasta tulee osa sovelluskehitystä”.
DevOps ohjaa yhteistyöhön
Johdon, tuotannon ja ylläpidon pitää toimia lähekkäin asiakkaan hyväksi, koska asiakas päättää mikä toimii
The Phoenix Project -kirjassa IT-pomo saa tehtäväkseen saattaa uuden, kriittisen ja pahasti myöhässä olevan tuotekehityshankkeen takaisin raiteille. Pääjohtaja uhkaa ulkoistaa koko IT-osaston. Tämä on arkipäivää monessa yrityksessä. Bisnes haluaa uudistua ja luoda uusia digitaalisia ratkaisuja, jotka integroivat vanhat järjestelmät osaksi uutta, älykästä tuotannonohjausta. Kirjassa tilanne pelastetaan saattamalla kehitys- ja ylläpitotiimit lähemmäs toisiaan ketteryyttä ja DevOps-ajattelua lisäämällä. Tämän myötä sekä bisnes, kehitys että ylläpito saavuttavat nopean palauteketjun. Idea viedään nopeasti tuotantoon, toteutuksesta saadaan palautetta ja päästään välittömästi hienosäätämään ideaa sekä toteutustapaa. Tähän päästään ketterällä priorisoinnilla ja automatisoinnilla. Meidän Tapio Rautonen on myös esitelmöinyt palauteketjun kriittisyydestä.
DevOps Handbook toteaa osuvasti, että tavoitteena on muodostaa positiivinen kierre, missä automatisoinnin vapauttamat resurssit hyödynnetään uuden innovointiin ja vanhan refaktorointiin. Vastakohtana on negatiivinen kierre, missä jatkuvasti vaikeutuva integrointi ja tuotantoonvienti johtaa viivästyksiin ja laadusta tinkimiseen, jolloin tekninen velka kasvaa johtaen yhä uusiin ongelmiin. Negatiivisessa kierteessä työskentely johtaa vähitellen psykologiseen avuttomuuteen, missä ei edes pyritä ratkaisemaan kohdattuja ongelmia ja pelätään seuraavaa, koko viikonlopun vievää tuotantoonvientiä. DevOps tehostaa koko organisaatiota ja organisaation yksittäisten funktioiden toimintaa (Dev, Ops, QA, Sec) sekä voimauttaa yksilöitä. Onko parempaa myyntipuhetta.
The Phoenix -kirja on fiktiivinen eikä ota kantaa kulttuurimuutokseen, jonka organisaatio todellisuudessa joutuisi käymään läpi tämän kokoluokan muutoksessa. Kirjahan on samaa sarjaa The Goal -teoksen kanssa, jossa fiktiivinen hahmo Lean konsultoi sekä tuotantolaitoksensa että avioliittonsa parempaan iskuun. Todellisuus on tarua ihmeellisempää.
DevOps nyrkkisääntöjä
State of DevOps 2017, Leading the Transformation, DevOps Handbook ja Marko Leppäsen väitöskirja pyörivät yksinkertaisten ideoiden äärellä:
- Älä keksi tekosyitä, nopeus on mielentila
- Työn kehittäminen on tärkeämpää kuin työn tekeminen
- Tehdään vain suunniteltu työ
- Valmis tarkoittaa läpi organisaation, että ominaisuudelle on kehitetty testiautomaatio, ajettu koodianalyysi ja ne täyttävät tavoitellun kattavuuden
- Kaikki käyttävät yhteisiä työkaluja ja ympäristöjä
- Kaikki käyttävät samaa versionhallinnan haaraa
- Arkkitehtuurin tulee olla modulaarinen, tai käsissäsi on iso läjä teknistä velkaa
- Teknologia-valinta on arkkitehtuuri-valinta, arkkitehtuuri-valinta on automatisointi-valinta
Aikaisempi DevOps blogini on helppo ja kevyt katsaus hieman syvemmälle aiheeseen.
DevOps mahdollistaa aidon ketteryyden
Muutos on aina käynnissä oleva prosessi ja ketterästi käytettynä huima kilpailuetu
Organisaation ketteröityminen on sekä haaste että -toteutuessaan- huima kilpailuetu. Ketteryys ohjaa tiimit aktiiviseen yhteistyöhön. Lean siivoa rönsyt. DevOps koneisto tarjoaa tuotekehitykselle välittömän näkymän ohjelmistotuotannon kapasiteettiin ja laatuun. Yritysjohdon tulee ymmärtää, että ohjelmistotuotantoa ei kannata organisoida samoin kuin tuotantoa, koska:
- Ohjelmisto on ainutkertainen kokonaisuus, joten sen tuottaminen sisältää enemmän epävarmuustekijöitä, kuin muu tuotanto.
- Ohjelmistomuutosten toimivuuden ennustaminen on vaikeaa.
- Hyvin toteutetun ohjelmiston muuttaminen on halvempaa ja nopeampaa kuin minkään muun tuotteen, mikä tarjoaa ainutlaatuisen kyvyn reagoida markkinamuutoksiin.
Raskas etukäteen suunnittelu on ohjelmistotuotannossa turhaa ja ohjelmistojen tarjoama ainutlaatuinen joustavuus kannattaa nähdä kilpailuetuna, ei uhkana.
DevOps mahdollistaa kokeilukulttuurin
Kukaan ei osaa sanoa etukäteen miten uusi ominaisuus toimii todellisuudessa. Ei varsinkaan johto
Mitä suuremmaksi yritys kasvaa, sitä tärkeämpää on säilyttää kyky kokeilla. Hierarkkisessa organisaatioissa syntyy usein jossain vaiheessa myytti, että johtajat tietävät mitä asiakas haluaa. Tätä joukkohypnoosia vastaan pitää taistella, ellei halua firmalle käyvän kuten vaikkapa Nokialle tai Kodakille, jotka yrityksinä onnistuivat uudistumaan vasta kun kaikki hypnotisoidut oli irtisanottu.
Agile, DevOps ja Lean kaikki peräänkuuluttavat jatkuvaa kehittymistä, kurinalaisuutta ja läpinäkyvyyttä läpi organisaation. Tavoitteena on saavuttaa kyky viedä muutoksia tuotantoon nopeasti. Tällöin voidaan optimoida bisnespäätöksiä tuotannosta saavutettujen kokemusten. Tämä johtaa tiiviimpään yhteistyöhön bisneksen, kehittäjien, ylläpidon ja asiakkaan välillä. Eli toisin sanoen saavutetaan läpinäkyvyyttä ja tarkempi tehtävien priorisointi.
Uuden ominaisuuden toteuttaminen on uhkapeliä. Ronny Kohavi et al. väittävät, että enintään joka toinen uusi ominaisuus osoittautuu asiakkaan kannalta tarpeelliseksi. Olsen nimittää tätä Product-Market Fit termillä The Lean Product Playbook -kirjassaan. Ohjelmistobisneksessä tämä ei tarkoita, että pitää suunnitella tarkemmin. Sen sijaan pitää voida kokeilla, epäonnistua ja oppia nopeasti. Kukaan ei osaa sanoa etukäteen miten uusi, ainutlaatuinen ominaisuus tulee todellisuudessa palvelemaan. Saadaksemme ohjelmistokehitykseen kaadettavat rahat poikimaan, ominaisuuksien pitää jalkautua tuotantoon nopeasti. ”Valmis” käyttämätön koodi on pahinta tuhlausta. Yksi Googlen menestyksen peruskiviä on beta-kokeilukulttuuri, jonka puolesta myös Intuit perustaja Scott Cook vahvasti puhuu. Goforen juuri painosta tulleessa kulttuurioppaassa todetaan osuvasti ”Post-it, Ikean litteiden pakkausten liiketoimintamalli, Amazonin pilviliiketoiminta ja lukuisat Googlen tuotteet ovat kaikki työntekijöiden keksimiä ja kehittämiä. Nämä henkilöt katsoivat asioita laajemmin kuin mitä heidät oli alun perin yritykseen palkattu tekemään.”
Tietoisuuteemme putkahtaa jatkuvasti uusia, teknologiassa edellä käyviä ja nopeasti kasvavia yrityksiä. Asiakkaana tilannetta on helppo arvottaa:
Itse pidän ensin listattuja laadukkaampina ja helppokäyttöisempinä, vaikka kaikkia näistä käytänkin. Yksi selitys parempaan käyttökokemukseen on aktiivinen ja avoin kokeilukulttuurin kehittäminen. Ja kulttuurin tukeminen toimivalla DevOps-koneistolla.
Säännöllinen julkaiseminen vaatii kehittäjien, testaajien ja tukitoimintojen saumatonta yhteistyötä, eli DevOpsia. Tavoitteena tulee olla automatisoitu julkaisuputki. Tämän saavuttaminen on usein työlästä, mutta onnistuessaan se vapauttaa resursseja asiakkaalle ja bisnekselle tärkeisiin kehityskohteisiin tulipalojen sammuttelun, manuaalisen konfiguroinnin ja testailun sekä jatkuvan muutosten jahtaamisen sijaan.
Muutos on yhteinen tavoite
Ketteryyden skaalaaminen on helpompaa, kuin kuvitellaan
Yrityksissä tavoitellaan ohjelmistotuotannon tuottavuusloikkaa Agilen ja ketteryyden avulla. Palkataan ketteriä konsultteja ja ajetaan yksittäisiä keihäänkärkitiimejä ketteriin työtapoihin. Tiimin työtapojen kehittäminen auttaakin pienessä organisaatiossa. Laajemmassa organisaatiossa tehottomuus syntyy tiimien välisestä yhteistyöstä. Tiimien prioriteetit tai aikataulut eivät kohtaa, joten tiimit pikemmin taistelevat toisiaan vastaan. Yksittäisten tiimien ketteröittäminen ei paranna suuren organisaation tehokkuutta. Sen sijaan tulee huolehtia tiimien välisestä yhteistyöstä ja tuotosten integroinnista. Sama pätee DevOps muutoksessa. Ei auta, että yksi keihäänkärkitiimi pilotoi tai kokeilee ideologiaa. DevOps tulee olla kaikkien yhteinen tavoite, johon myös ylin johto sitoutuu.
Kuva: Henrik Knibergin kuuluisasta Spotify-videosta lainattu esimerkki vapaudesta ja yhdensuuntaisuudesta. Mikromanageeraus tappaa tuottavuuden (vasen yläkulma), tiimien välisen yhdensuuntaamisen puute johtaa näennäisen tuottaviin tiimeihin, jotka todellisuudessa taistelevat toisiaan vastaan (oikea alakulma). Tavoiteltava optimitila oikeassa yläkulmassa, missä tiimit toimivat yhteisen tavoitteen hyväksi, lähestyen yhteistä tavoitetta omasta näkökulmastaan.
Johdon tulee kirkastaa tavoitteita ja prioriteetteja jatkuvasti, mutta myös tarjota vapaus niiden tavoitteluun. Gary Gruver toteaa Leading the Transformation kirjassaan, että suuressa organisaatiossa ketteryyden tulee valua ylhäältä alaspäin, johdon roolin rajautuessa siihen, että johto sanelee yhteisen kellosyklin ja prioriteetit. Ei varmasti ole sattumaa, että Netflix peräänkuuluttaa vastaavia vapautta ja vastuuta kannustavia arvoja. Myös SAFe-manuaali toteaa saman, lainaten legendaarista Leading Change artikkelia, että johdon tulee asettaa pelisäännöt muutokselle organisaation laajuisesti.
SAFe esimerkit ovatkin täynnä kertomuksia, missä organisaation lävistävä kellosykli ja priorisointi ovat johtaneet huimaan tuottavuusloikkaan. Salaisuus mielestäni ei ole SAFe prosessin erinomaisuudessa, vaan koko organisaation lävistävässä käyttöönotossa. Mitä aikaisemmin tiimien väliset prioriteetti- ja integrointiongelmat ratkaistaan, niin sitä vähemmän tiimit taistelevat toisiaan vastaan. Tämä johtaa olemassa olevien hankkeiden läpimenon paranemiseen. Mikä taas vapauttaa resursseja uudiskehitykselle.
Kaikkien muutoshankkeiden ytimessä tulee olla selkeä bisnes case. Muutos ei ole koskaan helppoa, joten tavoitteen ja motiivien pitää olla vahvoja. Johdolla tulee olla selkeä näkemys siitä miksi DevOps, Agile ja Lean muutokseen lähdetään. State of DevOps –raportti listaa menestyvän muutosjohtajan ominaisuuksiksi vahvan vision ja organisaatiota valtuuttavan, sekä inspiroivan johtajuuden. Gartner taas arvioi käänteisesti, että puolet niistä tietohallintojohtajista saa potkut, jotka eivät ole ymmärtäneet modernisoida IT-tukifunktioita vuoteen 2020 mennessä.
