Lean and Kanban

[Kanban I Virpi Rowe – Helmikuu 2016]

Arvovirran maksimointi

Tärkeintä on seurata prosessin läpimenoaikaa; siitä hetkestä kun asiakas tekee tilauksen, siihen hetkeen kun suoritus näkyy tilillämme. Tavoitteemme on minimoida läpimenoaika poistamalla siitä arvoa tuottamattomat toiminteet (’turhuus’, ’hukka’).

Lean - perusteet 

1. Määrittele mitä asiakas haluaa (tuote, arvo) 
2. Tunnista arvovirta joka toteuttaa asiakkaan haluaman arvon ja poista kaikki turhat tai hukkaa aiheuttavat vaiheet 
3. Luo virtaus jäljelle jääneiden arvoa tuottavien vaiheiden välille 
4. Mahdollista imuohjautuvuus
5. Kun arvo ja arvovirta on tunnistettu, hukka tuotantolinjalta poistettu ja imuohjautuva prosessi käytössä, tähtää täydellisyyteen jatkuvan parantamisen kautta

Lean – Hukka, muda

Arvovirta-analyysi - Value Stream Analysis

Arvoa tuottavat vaiheet I Läpimenoaika 

 

Scrum vs. Kanban

• Kumpikin toteuttaa Lean ja Agile periaatteita 
• Kumpikin on imuohjausmalli 
• Kummassakin rajoitetaan WIP:iä 
• Kumpikin käyttää läpinäkyvyyttää prosessin parantamisessa 
• Kumpikin tähtää nopeaan julkaisusykliin
•  Kumpikin perustuu tiimien itseohjautuvuuteen

Kanban perusperiaatteet 

1. Kuvaa arvovirta (prosessi) 
2. Rajoita keskeneräisen työn määrää (WIP, work in progress) 
3. Hallinnoi virtausta

Kanban periaate 1: Kuvaa arvovirta (prosessi)

Kanban-taulu on yksinkertainen tapa visualisoida tiimin työt. Taulun tarkoitus on indikoida mahdolliset pullonkaulat mahdollisimman aikaisessa vaiheessa. 

• Kanban taulu voi olla joko fyysinen tai digitaalinen (esim. JIRA) jossa on esillä tiimin kaikki työ ja työvaiheet joiden läpi kukin työ kulkee 

• Taulun tarkoitus on helpottaa tiimin työn ja resurssien hallintaa. Jokainen näkee aina tiimin realistisen tilanteen 

• Taulu luo täyden läpinäkyvyyden niin tiimille kuin muillekin sidosryhmille 

• Kanban taulu on tiimikohtainen 

• Taulun pitää olla aina ajantasalla 

• Tiimi voi muokata taulua tarpeen mukaan 

• Taululla pitää olla näkyvillä kaikki sovitut säännöt 

Vinkkejä taulun hyödyntämiseen 

• Kaikki työt taululle, ei muuta työn ohjausta 

• Taulua hoidetaan aktiivisesti ja se on aina ajantasalla 

• Tiimi omistaa taulun! 

• Taulun määrityksiä muutetaan tarpeen mukaan 

• Taulu ei ole ikinä “valmis”

Kuvaa työvaiheet, näytä jokainen työ oikeassa työvaiheessa 

• WIP limit per työvaihe 

• “Bufferit” eli jono (vaihe jossa työtä ei aktiivisesti edistetä, esim, Analysis > Done) 

• Definition of Done per työvaihe 

• Indikaatio kuka tekee työtä juuri nyt 

Muut määritykset: 

• Työn tyyppi (bugit, kehitystyö) 

• Prioriteetit, poikkeukset 

• Muut sovitut praktiikat 

Kanban periaate 2: Rajoita keskeneräisen työn määrää

Jotta työn läpimenoaikaa saadaan lyhennettyä, yhtä aikaa meneillään olevan työn määrää tulee aktiivisesti rajoittaa 

• Tavoite: Tiimillä on mahdollisimman vähän keskeneräistä työtä 

• WIP limit määrittelee kuinka monta työtä voi maksimissaan olla tietyssä työvaiheessa samanaikaisesti. Työn suuruusluokalla ei ole merkitystä 

• WIP limitin tarkoitus on suhteuttaa työt tiimin kehityskapasiteettiin, eli minimoida “vaiheessa” olevan työn määrää 

• Jos WIP limit on liian pieni, silloin tiimi on alityöllistetty ja työtä valmistuu vähemmän kun tiimillä olisi kapasiteettia 

• Jos WIP on liian suuri, tiimi on ylityöllistetty. Tällöin usein laadulliset ja tuottavuuteen liittyvät haasteet ilmenevät 

• Oikeat WIP limitit löytyvät ajan myötä, niitä ei voi antaa valmiina 

Vinkkejä WIP:n löytämiseen 

• Virtaus toteutuu parhaiten kun työt ovat suurinpiirtein samaa kokoluokkaa 

• Tiimin jäsenten allokaatiot ovat stabiileja 

• Työtä hallitaan esim Jirassa jossa läpimenoaikoja voidaan mittaroida

Kanban periaate 3: Hallinnoi virtausta

“It is not the strongest of the species that survives, nor the most intelligent, but rather the one most adaptable to change.” 

• Kanban tiimin ensisijainen onnistumisen mittari on läpimenoaika 

• Ensimmäinen askel prosessin optimoinnissa on tuntea prosessi 

• Hukan tunnistaminen ja eliminointi 

• Työnkulun hallinnan tarkoitus on tehostaa tiimin toimintaa, parantaa laatua ja nopeuttaa läpimenoaikoja 

• Läpimenoaikoja on helppo mittaroida esim JIRAssa. Manuaalisella Kanban taululla kortteihin tulee merkitä milloin työ on tullut backlogille ja milloin työ on aloitettu/valmistunut  

Lead time, Aika työpyynnön vastaanottamisesta tuotantoonvientiin

Cycle time, Aika joka kuluu työn tekemiseen 

Kanban -tiimi

Kanban tiimin tavoite on Lean -periaatteiden mukainen arvontuoton maksimointi 

• Tiimi tekee töitä jotta tiimi saavuttaa tavoitteensa 

• Kanban ei määrittele pakollisia tiimin rooleja. Työn laatu ja määrä määrittelee tiimin kokoonpanon, osaamisen ja koon 

• Parhaimmillaan Kanban tiimi ei tarvitse erillistä työnohjausta, tiimi on itseohjautuva moniosaaja -tiimi 

• Tehokkaimmillaan yhdessä lokaatiossa 

• Tiimin jäsenet täydellä allokaatiolla 

• Tiimi on vastuussa prosessin kehittämisestä (Kaizen)

Scrum vs. Kanban, erot 

Mittarit: Cumulative Flow Diagram 

Lean säännöt arvovirran optimointiin

1. Value over flow
   Maksimoi arvontuotto virtauksen kustannuksella 
2. Flow over waste elimination
   Kasvata WIPpiä tarpeen mukaan jotta virtaus säilyy, vaikkakin se saattaa lisätä hukkaa 
3. Eliminate waste to improve efficiency
   Poista hukka tehokkuuden tieltä

 

Kanban vs Scrum

ScanAgile2015: Muut esitykset

Janne Sinivirta: One team to lean them all
http://www.slideshare.net/v3rtti/one-team-to-lean-them-all

https://www.youtube.com/watch?v=vY7zRhp5_sw

Joakim Sunden, Leadership @ Spotify
https://www.youtube.com/watch?v=gXIhoW5-Obg

Llewellyn Falco at Scan-Agile 2015 - Intro to Agile

https://www.youtube.com/watch?v=yDBOSKZ5k1g

Timo Lappi at Scan-Agile 2015 - Boards and Agile

https://www.youtube.com/watch?v=YaOj2R0wNpI
http://www.slideshare.net/TimoLappi/agile-boards-of-directors

ScanAgile2015: Antti Kirjavainen: 3 beliefs you need to let go to start your agile journey

Uskomukset ovat ne jotka estävät meitä kehittymästä

"Jokaisella toimituksella (batchilla) on kustannuksia, joten on kustannustehokkainta koota ne yhdeksi isoksi toimitukseksi joka toimitetaan kerralla"

• Batcheista tulee suunnattoman kokoisia
• toimitusten välillä on pitkä aika jolloin mitään ei toimiteta
• riskit löydetään myöhäisessä vaiheessa
• pitkä time to market
• menetetään sopeutuvuutta

"Asiantuntijoiden aikaa käytetään tehokkaimmin siten että hyödynnetään heitä vain siinä missä he ovat parhaimpia"

• asiantuntijoita käytetään samanaikaisesti moneen asiaan
• resurssien samanaikainen allokointi asettaa haasteita
• yhteistyö ja kommunikaatio hankaloituu
• johtaa multitaskaamiseen, tehtävien vaihtamiseen lennossa, hukkaan

"100% käyttöaste ihmisten osalta on tuottavaa"

• sopeutuvuus on hankalaa
• ei pystytä varautumaan yllätyksiin

"Prosessien jalkauttamisen positivismi"

• prosesseja kuvitellaan voitavan jalkauttaa johdon toimesta
• julkaistaan powerpoint, viedään se sharepointiin ja lähetetään sähköposti = jalkautus
• kuvitellaan että julkaisemalla organisaatiokaavio saadaan organisaatio muuttumaan sen tuloksena

"Jaetaan organisaatio suunnittelijoihin ja tekijöihin"

• päätyy siihen ettei ketään kiinnosta pätkääkään

Miten näistä uskomuksista pääsee eroon?

Vanhat uskomukset yleensä liittyvät johonkin oletuksiin, vanhoihin ideoihin tms. ja ne ovat usein tiedostamattomia

• Tuota kokemusta
• tuo kokemusta esim. erilaisilla peleillä ja leikeillä
• mahdollista erilaisten strategioiden kokeileminen

• Pohdi sessioita yhdessä
• analysoikaa pelien/leikkien kokemuksia
• muodostakaa yhteinen mielipide
• yhdistäkää kokemus johonkin teoriaan
  
• ota uusia teorioita käyttöön eri kontekstissa

Erilaisia kokeilumenetelmiä

• The Marshmallow challenge
• kokemukset, oletukset
• analysointisessio, opit
• käyttöönotto ja käytännölliset ideat
  
• Multitasking name game
• 5 asiakasta jotka haluavat nimensä kirjoitettavan paperille
• kehittäjä jolla on kirjoitustaito
• Verrataan:
• nimien kirjoittaminen aloitetaan samanaikaisesti kirjain kerrallaan
• nimet kirjoitetaan yksi kerrallaan kokonaan
  
• Ball flow game (process rollout positivism)
• jokainen pallo pitää käyttää jokaisen henkilön kautta ja jokaisen henkilön on käsiteltävä tietty määrä palloja
• iteraatiot, prosessimuutokset ja parannukset
• lopputuloksena stabiili prosessi jolla ei kuitenkaan ole välttämättä kykyä enää parantua
• jokaisen on ymmärrettävä mitä tekee
• jokainen prosessimuutos on kokemus
• vain tekemällä prosessi nopeammaksi ei välttämättä tee sitä paremmaksi
  
• Value stream mapping

Koko materiaali:
http://www.slideshare.net/AnttiKirjavainen/3-beliefs-you-need-to-let-go-to-start-your-agile-journey
https://www.youtube.com/watch?v=UP1Fgw0A_IA

ScanAgile2015: Andrea Tomasini: Stop scaling, start growing an agile organization

Skaalautuvuudesta on puhuttu paljon, mutta se ei ole aina vastaus kaikkeen. Erityisesti jos keskitytään ainoastaan skaalaamaan, eikä varsinaisesti kehittämään ketterää organisaatiota.

Tulos ja kustannukset

Organisaatiokulttuurissa olennaisesti on esillä tuloksenteko. Tämä on perinteisesti ollut sitä että seurataan tulosta, pyritään vähentämään kuluja markkinoilla pärjäämiseksi. Kulujen vähentäminen usein on tarkoittanut ns. low skill manpoweria, eli edullista työvoimaa jota ohjataan voimakkaasti johdon toimesta. Ei ole enää ihan tätä päivää eikä edes varsinaisesti tämän päivän ongelma, nyt on enemmänkin haasteita tuottaa riittävän nopeasti sitä mitä asiakas haluaa.

Mittaaminen

Sen sijaan että mitattaisi arvoa, mitataan enemmänkin aikaa ja rahaa. Miksi ei arvoa? Keskityttäisikö enemmän

• asiakkaaseen ja arvon tuottamiseen
• itseohjautuvuuteen ja autonomiaan
• tiimi onnistuu, yksilöt eivät epäonnistu
• jatkuvaan parantamiseen
• jos tehdään aina samanlaista scrumia, ei mikään muutu
• iteratiiviseen ja inkrementaaliseen muutoshallintaan riskien vähentämiseksi

Muutos?

Sopiiko yksi koko kaikille? Tuskin käytännössä (koskaan) mutta teoriassa (aina).

Periaatteet:

1. Keskity pieniin inkrementaalisiin muutoksiin
• perinteisessä kehitysmallissa muutoshallinnassa keskitytään standardointiin ennen vakauttamista
• agilessa fokus on vakauttamisessa, uusiutuvasti standardoiden

2. Keskity arvon tuottamiseen ja organisoidu sen mukaisesti

3. Vähennä keskitettyä kontrollia aina kun mahdollista

4. Vältä vaiheiden synkronointia tarpeettomasti

Ajattelemisen aihetta.

Cynefin Framework

4 organisaatiokulttuuria

Yrityksen transition viitekehys

Koko materiaali:


Andrea Tomasini: Stop scaling, start growing an agile organization
http://www.slideshare.net/tumma72/stop-scaling-start-growing-an-agile-organization

Clarity before speed: Plan-Do-Check-Act applied in practise

Eveliina Vuolle /Nokia


Perinteisestä Demingin syklin soveltamisesta käytännön tasolla havainnollistava esitys, paneutuen siihen miksi sen soveltamisessa usein koetaan haasteita.

Tärkeimpänä nostona: tee aina koko ympyrä, uudelleen ja uudelleen. Menetelmästä ei ole juurikaan hyötyä, jos siitä toteutetaan vain osia, tai jos se tehdään vain kerran. Hyöty saavutetaan vain, jos se tehdään kunnolla ja toistuvasti.

Monesti ollaan hyvisä suunnittelussa ja ehkä vielä toteuttamisessakin, mutta seuranta ja toimet havaintojen pohjalta jää tekemättä ja hyödyntämättä seuraavalla kierroksella.

Suunnittelu (Plan)

• mitä ollaan tekemässä, miten se pitäisi tehdä?
• Tarve & tavoite
• Prosessi & organisointi
• Resurssit

Toiminta (Do)

• Toteutetaan suunniteltu
• testaus & käyttöönotto

Seuranta (Check)

• Opi
• Analysoi
• Tarkasta
• Mittaa
  Kun seuranta-vaiheen tekee oikein, saa siitä hyötyä
• KPI:den näkyvyydelle
• juurisyyanalyyseille
• Retro-nostoille
• asiakaspalautteella

Toimi (Act)

• Innovaatio & muutos
• Parantaminen
• uudistuminen
• suunnitelmien uudelleensuunnitteleminen
• Seuranta-vaiheen tulosten katselmointi

Jatkuva parantaminen

Parannusehdotukset ja suunnitelmat olisi hyvä viedä aina konsolidoidulle backlogille. Tiimi on se, jonka tulisi ensisijaisesti tutkia, etsiä, ideoida ja löytää parannusehdotuksia toteuttaessaan menetelmää. Ehdotukset katselmoidaan; parannusehdotusten  ja suunnitelmien osalta tulisi aina tarkistaa 

• Viekö tämä meitä tavoitteeseen?
• kyllä
• ei

jonka jälkeen ne viedään backlogille ja niitä seurataan. Tiimien tulisi muistaa, että ei ole muuttumatonta ympäristöä, vaan tähdätään jatkuvaan parantamiseen ja Plan-Do-Check-Act-menetelmällä saadaan yksinkertainen ja toimiva kehä.

ScanAgile2015: Titanic does not need to sink - Large scale scrum works /Ericsson

Ericcsonilta Norma Acevedo Lopez ja Almudena Rodriguez Pardo esittelivät Ericssonin käytäntöjän suurten hankkeiden läpivientiprosessista scrumin avulla. Perinteisesti tunnutaan ajattelevan ettei agile tai ainakaan scrum sovellu isoihin projekteihin tai kehityshankkeisiin, mutta selvästi siinä onnistutaan, kun niin halutaan.

Arkkitehtuurillinen suunnittelumalli

Ericssonilla on ollut käytössä arkkitehtuurillinen suunnittelumalli, joka edellisenä versiona oli koettu raskaaksi prosessimielessä, eikä tukenut kovin hyvin ketterien scrumtiimien tekemistä.
Vanha malli oli raskas, mutta tuote vakaa. Hyväksyntäprosessi oli kuormittava, kaikki muutokset käytettiin erillisten hyväksymistiimien kautta.

Arkkitehtuurillista suunnittelumallia uudistettiin, ja uudessa mallissa poistettiin raskas kiinnitetty hyväksyntätiimikäytäntö-
Uuden mallin hyödyt on lähinnä siinä että siinä ei tule pullonkauloja missään kohdassa, vaan eteneminen on ketterää ja tehokasta.
Kuitenkin haasteina on esim. se, ettei mallissa ole kiinnitettyjä jäseniä, ei virallista kunkin alueen kiinnitettyä asiantuntijaa ja arkkitehtuurimallin omistajaa.
Ideana on pitää kiinnitetyt SoS-tiimit, joihin kaikkien scrumtiimien scrum masterit osallistuvat. SoS-tiimi:
- konsultoi ja hyväksyy
- omistaa arkkitehtuurimallin
- on pysyvä jäsenten osalta

Riskienhallinta

Ericssonilla on selvästi ymmärretty ja sisäistetty  että siitä kannattaa maksaa, että oppi löydetään mahdollisimman pian projektin alkuvaiheissa. Suunnittelumallissa kiinnitetään huomiota erityisesti riskienhallintaan, Featureista tunnistetaan "spiket", joihin kiinnitetään huomiota heti alkuvaiheessa

Spikes

- jos jokin asia ei ole selkeä, se saattaa aiheuttaa riskin
- näiden vaikutusten tutkiminen ja arviointi suoritetaan mahdollisimman pian
- koodin laadunvarmistus tiimeissä

NBC

- Non Backward Compatibility
Koska Ericssonilla pyritään tuomaan jatkuvasti versioita, kiinnitetään kehityshankkeissa huomiota myös erityisesti yhteensopivusshaasteisiin joita multiversiointi tuo tullessaan.

[Wikipedia: In programming languages, backward compatibility refers to the ability of a compiler for version N of the language to accept programs or data that worked under version N - 1.^[2] By this definition, if previous versions (N - 1, N - 2, etc.) were also backward compatible, which is often the case, then, by induction, version N will also accept input that worked under any prior version after, and including, the latest one that was not backward compatible. However, in practice, features are often deprecated and support is dropped in a later release, which is yet thought of as backward compatible.

In other contexts, a product or a technology is said to be backward compatible when it is able to fully take the place of an older product, by inter-operating with products that were designed for the older product]

Tehokkuus

Automated washing machine

Ericssonilla on kehitetty automatisoitu menetelmä nimeltä X-WM, jonka tarkoitus on automatisoida testausta systeemi- ja integraatiotestauksen osalta. Kaikki featuret ja koodit pyöräytetään washing machinen kautta, joka vähentää huomattavasti ongelmia integraatiovaiheessa ja lisää tehokkuutta.

Tehokkuutta saadaan myös sillä, että huolehditaan siitä että storyt ovat riittävän palasteltuja eikä yritetä tehdä kerralla liian isoja kokonaisuuksia. Resurssien ja tekemisen tehokkuutta saadaan tällä kasvatettua myös. Hyvä kirjoitus storyjen leikkaamisesta riittävän ohuiksi siivuiksi löytyy täältlä:
Alistair Cockburn: Elephant carpaccio

ScanAgile 2015: Gojko Adzicin esityksestä, aiheena Transforming the software development industry

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

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ä