Friday, April 24, 2015

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



Tuesday, April 7, 2015

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