ScanAgile on perinteisesti ollut Se Tapahtuma suomalaisessa agilemaailmassa, johon olen ehdottomasti halunnut osallistua. Niin tälläkin kertaa, enkä pettynyt. Päivä alkoi Gojko Adzicin vauhdikkaalla avausesityksellä ohjelmistokehityksen muutoksesta. Kirjoitin kynä höyryten muistiin asioita, ja onneksi järjestäjien toimesta myös tallennettiin esitykset jotta pääsin jälkeenpäin vielä kertaamaan ja käymään läpi muistiinpanot tarkentaen. Siitä poiki sitten tämä kooste, koska mielestäni Gojkolla oli sen verran paljon painavaa asiaa jota haluan pureksia ja laittaa muistiin.
Paljon on tutkittu ja seurattu erilaisilla yrityksillä ohjelmistokehityksen menetelmiä, ja todettu että WaterScrumFall on se tehokkain. Näinköhän todella? Varmaan on, jos mitään todellista muutosta ei oikeasti tehdä. Seuraavan "silver bulletin" etsiminen agilekehityksessä onkin melkoisen kuuma peruna, ja jokseenkin moni esitys keskittyi pohtimaan sitä samaa; mikä on se seuraava Juttu?
Gojko kävi havainnollistavasti asiaa läpi vanhaan tehdaskulttuuriin peilaten. Ennen tehtaat olivat korkeita, pinta-alaltaan pieniä mutta korkeussuunnassa suuria ja siihen oli erittäin painavat perusteet. Tehtaissa nimittäin käytettiin suuria höyrykoneita, jotka räjähtäessään räjähtävät ylöspäin. Miksi sitten edelleen rakennetaan korkeita tehtaita? Ei enää ole suuria räjähtäviä höyrykoneita jotka tarvitsisivat korkeaa tilaa.
Miksei rakenneta matalia, laajoja tehtaita jotka tukisivat paremmin nykyisiä koneita ja toimintoja?
Ihan vastaavasti kehitysmaailmassa ollaan menty eteenpäin, vanhan maailman haasteet ja ongelmat eivät ole enää tätä päivää.
Yksi selkeä havainto on, että monissa yrityksissä ohjelmistokehitys kulkee kovemmalla vauhdilla kuin liiketoiminta. Kehitys tuottaisi nopeammin kuin mihin liiketoiminta ehtii reagoimaan, ja tähän hoitokeinona on sitten hidastettu kehitystä.
Nopea, jatkuva kehitys saattaa usein hukata kokonaiskuvan ja ymmärryksen liiketoimintaprosesseista sen ympärillä, porskuttaa omaa vauhtiaan ja pakottaa muut nielemään vauhdilla tekemänsä tuotokset.
Pakkosyöttö ei yleensä ottaen toimi, se koetaan vaikeana vastaanottavilla tahoilla eikä johda välttämättä kovinkaan toivottuun lopputulokseen. Liiketoiminnalla on oltava valmiudet jalkauttaa tuotokset ja prosessien omaksua ne. Ohjelmistoja käyttävät tahot eivät pidä hyvänä asiana jatkuvasti puskettavia muutoksia joita ei ehditä omaksua ja joita tulee ikään kuin pakkosyötettynä.
Paljon on tutkittu ja seurattu erilaisilla yrityksillä ohjelmistokehityksen menetelmiä, ja todettu että WaterScrumFall on se tehokkain. Näinköhän todella? Varmaan on, jos mitään todellista muutosta ei oikeasti tehdä. Seuraavan "silver bulletin" etsiminen agilekehityksessä onkin melkoisen kuuma peruna, ja jokseenkin moni esitys keskittyi pohtimaan sitä samaa; mikä on se seuraava Juttu?
Gojko kävi havainnollistavasti asiaa läpi vanhaan tehdaskulttuuriin peilaten. Ennen tehtaat olivat korkeita, pinta-alaltaan pieniä mutta korkeussuunnassa suuria ja siihen oli erittäin painavat perusteet. Tehtaissa nimittäin käytettiin suuria höyrykoneita, jotka räjähtäessään räjähtävät ylöspäin. Miksi sitten edelleen rakennetaan korkeita tehtaita? Ei enää ole suuria räjähtäviä höyrykoneita jotka tarvitsisivat korkeaa tilaa.
Miksei rakenneta matalia, laajoja tehtaita jotka tukisivat paremmin nykyisiä koneita ja toimintoja?
Ihan vastaavasti kehitysmaailmassa ollaan menty eteenpäin, vanhan maailman haasteet ja ongelmat eivät ole enää tätä päivää.
Yksi selkeä havainto on, että monissa yrityksissä ohjelmistokehitys kulkee kovemmalla vauhdilla kuin liiketoiminta. Kehitys tuottaisi nopeammin kuin mihin liiketoiminta ehtii reagoimaan, ja tähän hoitokeinona on sitten hidastettu kehitystä.
Miksi pitäisi hidastua, eikö olisi parempi auttaa muita pääsemään samaan vauhtiin?
Nopea, jatkuva kehitys saattaa usein hukata kokonaiskuvan ja ymmärryksen liiketoimintaprosesseista sen ympärillä, porskuttaa omaa vauhtiaan ja pakottaa muut nielemään vauhdilla tekemänsä tuotokset.
Pakkosyöttö ei yleensä ottaen toimi, se koetaan vaikeana vastaanottavilla tahoilla eikä johda välttämättä kovinkaan toivottuun lopputulokseen. Liiketoiminnalla on oltava valmiudet jalkauttaa tuotokset ja prosessien omaksua ne. Ohjelmistoja käyttävät tahot eivät pidä hyvänä asiana jatkuvasti puskettavia muutoksia joita ei ehditä omaksua ja joita tulee ikään kuin pakkosyötettynä.
Nopeampi ei ole aina parempi
Nopeammalla toimituksella saatetaan ainoastaan kuluttaa rahaa nopeammin, ei välttämättä saada enemmän aikaan. Nopeus on usein se toivottu asia, pyritään tavoitteissa nopeuteen, vaaditaan nopeampaa toimitusta, nopeampaa kehitystä, nopeammin tuloksia. Voitaisiko sanoa vain suoraan että halutaan tuhlata enemmän rahaa nopeammalla tahdilla?
Mitä mitataan?
Miten menestystä mitataan? Hyvällä mittaamisella estetään se, ettei toimiteta vain nopeasti kuraa. Usein tunnutaan mittaavan sitä mikä on helppoa mitata, ei välttämättä sitä mikä on tärkeää. Miten sitten tunnistetaan se mikä on tärkeää? Oliko se siihen käytetyn rahan arvoista?
Yksi aika selkeä mittari voisi olla esimerkiksi voidaanko sen perusteella tehdä päätöksiä? Jos mitataan jotain josta saadaan tuloksena tietoa jonka perusteella voidaan oikeasti tehdä päätöksiä, on sillä tiedolla selkeästi arvoa.
Pelkkien tulosten mittaaminen siksi että niitä voidaan mitata mutta niiden perusteella ei voi päätellä saati päättää mitään, ei anna tuloksille arvoa. Olisi syytä pohtia tarkemmin mikä on sellaista tietoa jolla on oikeasti arvo, ja suunnitella miten sitä voidaan mitata ja hyödyntää.
Jatkuvalla toimittamisella on vaikutuksia markkinointiin. Liiketoiminta voi mahdollistaa sen avulla uusien liiketoimintamallien avaamisen. Yksinkertaisimmillaan voisi esimerkki olla autoteollisuudesta, jota Gojko käytti tämän havainnollistamiseen.
Perinteinen autoteollisuus tuottaa uuden automallin vuodessa, ne nimetään vuosien mukaan ja niillä on vuosittaisten mallien mukaiset ominaisuudet.
Tesla sen sijaan tuo automallin, jota voi päivittää. Automalli voisi olla jopa sellainen, että siihen voi ladata lennosta verkon yli uusimmat päivitykset ja saada uusimmat ominaisuudet heti käyttöön. Tässä tosin on melkoiset riskit, jos esimerkiksi tuodaan versio jossa onkin jokin virhe. Vaikutukset saattavat olla arvaamattoman pahat liikenteessä...
Markkinoinnin ja teknisen toimittamisen erottaminen
Gojkon mukaan olisikin erittäin tärkeää, että aletaan erottaa oikeasti markkinointitapahtuma teknisestä toimituksesta. Nämä ovat erillisiä asioita, niiden pitäisi olla todellisuudessakin erillisiä asioita.
Käyttöönotto (deployment) ja julkaisu (release) ovat erillisiä asioita ja niiden pitäisi olla siis todellisuudessakin erikseen.
Multiversiointi
Tämä saattaa nyt olla se tulevaisuuden hopealuoti, se seuraava iso asia johon kaikki keskittyvät. Gojko pitää tätä olennaisen tärkeänä jatkuvan toimittamisen kannalta tulevaisuudessa, ja olen valmis allekirjoittamaan sen.
- Eri versioita pitäisi voida markkinoida ja toimittaa eri kohderyhmille eriaikaisesti
- liiketoiminnallisia vaikutuksia voitaisi mitata näiden osalta erikseen ja
- saada määriteltyä sen avulla arvo eri toimituksille
Multiversioinnin ei pitäisi olla edes teknisesti haasteellista, mikäli ohjelmisto suunnitellaan alunperinkin tukemaan sitä.
Mistä sitten tiedetään onko turvallista ottaa käyttöön uusia versioita?
Kriteeristö tälle puuttuu usein, ja silloin se onkin vaikea tietää. Käyttöönoton turvallisuuden määrittämiseksi tulisi siis olla kriteeristö joka on läpinäkyvä ja perustuu riskien analysointiin ja sen pitäisi olla yhteisesti jaettu näkemys. Usein eri alueiden tahot näkevät oman alueensa asiat ja riskit tärkeimpinä ja jättävät huomiotta muiden alueiden riskit. Tämä tulee esiin esim. MOSCOW-mallin priorisoinnilla, jos huomataan että kaikki ovat Must-riskejä.
Jotta tämä ei tapahtuisi, tarvitaan läpinäkyvä keskustelu alueiden välillä:
- kuinka paljon riskiä meillä on mahdollisuus/lupa ottaa
- millaisia riskejä meillä on mahdollisuus/lupa ottaa
Jatkuva toimittaminen on kilpailuetu
Kun tehdään päätöksenteko- ja arviointiprosessi helpoksi, npoeaksi ja halvaksi. Mitataan oikeat asiat, käytetään niitä päätösenteossa, saadaan hyödynnettyä tuloksia esim. eri versioiden samanaikaisesta toimituksesta nopealla tahdilla ja voidaan reagoida niihin.
Siirrytään pois lineaarisista backlogeista, aletaan tuomaan arvoa.
Muunnetaan tekniset ongelmat liiketoimintamahdollisuuksiksi.
Gojkon esitys nähtävillä kokonaisuudessaan täällä
