Mikä tekee organisaatiosta ketterän?

Ongelma: organisaatiomuutoskulttuuri

Useissa yrityksissä tehdään uudelleenorganisointia usein ja säännöllisesti, keskimäärin n. 6-9kk välein. Lukuisia uudelleenorganisoitumisia läpikäyneenä voi todeta että seuraavat havainnot pitävät pitkälti paikkansa:

• Uudelleenorganisoiti luo sääntöjä ja suoritusmittareita
• Se mittaa yksilöllistä suorituskykyä ja sääntöjen noudattamista - 
• Se keskittyy vastuullisuuteen, ei arvoihin
• Se pakottaa onnistumaan ensimmäisellä kerralla
• Sen mittarit kytkeytyvät yleensä prosesseihin, ei tulokseen
• Se luo kaaosta, lannistavuutta, motivoituneisuuden puutetta
• Se pakottaa tiedonsiirtokierteeseen, jossa yritetään tehdä tiedonsiirtoa tiedonsiirron perään, juosta uusien roolien perässä ja jakaa vanhoja
• Usein se vain parantaa oireita, ei itse ongelmaa

(Lähde: Andrea Tomasini)

Mikä sitten tekee organisaatiosta ketterän?

• Näkyvyys
• Läpinäkyvyys
• Turvallisuus
• Ohjaus ja kontrolli
• Visio ja suunta
• Voima
• Mukavuus

Miten voi parantaa jos ei ole mahdollisuutta epäonnistumiseen?

Tiimityöskentelykokemus on osoittanut että ketteryydellä voi toimittaa arvoa nopeammin, suuremmalla laadulla ja se on tekijöille motivoivampaa. Mikä sitten tekee tiimistä ketterän?

Kuten jo Agile manifestossa sanotaan:

• Yksilöt ja vuorovaikutukset yli prosessien ja työkalujen
• Toimiva ohjelmisto yli kattavan dokumentaation
• Asiakasyhteistyö yli sopimusneuvottelujen
• Muutokseen vastaaminen yli suunnitelman seuraamisen

Venkat Subramaniamia lainaten: A professional who doesn't learn to fail, fails to learn.

Keinoja kehittyä tässä?

Empiirinen prosessikontrolli on pohjana Scrumille, ja sen sisäistäminen on avainasemassa kehittymisessä ketteräksi ja tehokkaaksi. Empiiriseen prosessikontrolliin ei kuulu oletuksia, eikä varsinkaan yritetä olettaa mitä asiakas haluaa. Prosessin kontrolloinnin määrittely ei ole myöskään ihan yksiselitteistä, mutta aika joka kuluu jatkuvien toimien suorittamiseen on pätevä mittari ennustamiseen. 

Pull vai Push?

Onnistuminen ei ole henkilökohtaista. Mantra, joka pitäisi pitää koko ajan esillä ja muistissa. Tiimi on se joka tuottaa arvon, ja vain sitoutuneilla yksilöillä voi luoda tiimin. 

Pull keskittyy arvoon, yhteistyöhön ja tiimiin, kun taas Push tuottaa enemmän kilpailua, sääntöjen noudattamista ja yksilöllisyyttä. 

Jatkuvaa parantamista tulisi tapahtua jatkuvasti. Muutoksen tulisi tapahtua jokaisessa iteraatiossa. Tämän voi skaalata niin sprintteihin kuin organisaatiouudistussykleihinkin, ja yrittää pitää mielessä että iteraation ei ole tarkoitus tuottaa lopullista kiveenhakattua ikuista, vaan se on nimenomaan iteraatio jonka jälkeen tulee seuraava iteraatio jossa on parannettu ne joista on edellisessä iteraatiossa opittu.

Toinen mantra jota tulisi hokea ja muistaa on Muri - Mura - Muda

Muri: vältä tuottamasta uudelleen tekemistä, poista ylikuormitus

Mura: tarpeettomat vaihtelut, normalisoi backlogin tulovirtaus, pidä virtaus tasaisena ja mahdollista turvallinen ympäristö epäonnistumiselle. Määrittele "valmis"

Muda: hukkatekeminen; poista arvoa tuottamattomat tehtävät jotka selvitetään retrossa.

Estimointia vai arvailua?

Perinteisesti scrumtiimi arvioi tulevalle sprintille tulevaa työmäärää jonkinasteisella estimointikäytännöllä.
Usein on käytössä planning pokerin ja t-shirt sizingin välimuoto, työmäärän arviointi storyn perusteella, mutta tässä on omat haittansa ja riskinsä.

Planning pokerin etu on sen demokraattisuudessa. Jokainen tiimin jäsen saa korttipakan ja voi esittää oman näkemyksensä taskin koosta. Planning pokerin haitta on siinä että se on kohtuullisen aikaa vievä toimenpide. Pokeriarviointi saattaa myös helposti johtaa ajatukset aikamääreisiin, pisteiden ollessa esim. tunteja tai päiviä mielessä. Aikamääreiden käyttämistä on vältettävä ja painotettava suhteellisten kokoarvioiden arvoa.

T-shirt sizing - menetelmän etu on arvojen abstraktiivisuudessa ja siinä ettei varsinaisia välineitä tarvita, voi esim. kirjoittaa kokolaput XS, S, M, L, XL. Suhteelliset kokoluokitukset muunnetaan sovittuun arvoon joiden avulla esim. velositeettia ja burndown charttia voidaan mitata ja seurata.

Jos estimointia ei tehdä, kuinka tiimi voi arvioida sprintin työmäärää? Miten tiimi voi sitoutua toimittamaan jotain aikaikkunan sisällä, jos työmäärä ei ole tiedossa?

Scrum itsessään ei sano mitään estimoinnista. Scrum sanoo, että jokainen item backlogilla on oltava jonkin kokoinen, mutta miten koko luokitellaan riippuu täysin tiimistä. On myös muistettava että scrumtiimi sitoutuu sprintin tavoitteeseen joka on arvon toimittaminen, ei arvioitujen pisteiden toimittaminen.

Estimoinnin puolesta on argumentteja:
- estimointi auttaa meitä ennustamaan milloin sprintin tavoite on saavutettu
- estimoinnit auttavat tiimin sidosryhmiä suunnittelemaan ennalta
- estimoinnit auttavat vähentämään riskiä epämääräisten työmäärien osalta
- sprintin tekemisiä voidaan uudelleenjärjestellä vaihtamalla samankokoisia taskeja. Jos ei ole estimointeja, ei voi tehdä vaihtoja
- estimoinnin tekeminen itsessään tuo arvoa. Kun keskustellaan vaatimusmääritteyiden yksityiskohdista, saavutetaan parempi ymmärrys siitä mitä tarvitaan

Ja estimointia vastaan on argumentteja:
- estimoinnit harvoin ovat tarkkoja. Kaikki mitä estimoinnissa tehdään, on asetetaan vääriä odotuksia
- käytännössä estimointi nähdään sitoutumisena, ei parhaana arvauksena.
- estimointi on aikaavievää ja pois toteuttamiseen käytettävästä ajasta
- vain todellisilla mittareilla on väliä, ei arvioilla. Agiliteetti vaatii metriikkaa, ja ainoa todellinen metriikka on se joka mittaa toimitusta

Vaatimusmäärittelyillä on tapana olla epämääräisiä, monimutkaisia ja toisiinsa kietoutuneita. Sitoutumalla sprintin tavoitteisiin ja toimittamalla merkittävää arvoa, tätä riskiä voidaan hallita.
Epävarmat ja sidonnaiset vaatimusmäärittelyt niputetaan sprinttiin ja hallitaan yhtenä joukkona. Kun tämä tehdään hyvin, on tiimillä selkeä sprintin tavoite ja asianmukainen backlogi. Kun tämä tehdään huonosti, on tiimillä epämääräinen sprintin tavoite, sotku toimeksiantoja jotka ei palvele tiimin tarkoitusta eikä tiimitasoista sitoutumista toimittamiseen.

Lean ja Kanban keskittyy yleensä perustekemiseen. Lean Kanban - toimitus koostuu pienistä ja toistuvista muutoksista, jotka eivät välttämättä liity mitenkään toisiinsa eikä niiden pitäisikään liittyä. Tällaisia ovat esim pienet kehitykset, bugikorjaukset ja ylläpitotehtävät.

Miten sitten voi ja kannattaa arvioida, jos halutaan arvioida?

Funktionaalinen, standardisoitu Cosmic-menetelmä tarjoaa esimerkiksi selkeän tavan suorastaan laskea storyn toteuttamiseen tarvittavaa työmäärää. Näin arvioitava koko mittaa toiminnallisuuden toteuttamista ja on täysin riippumaton tekniikasta ja tekijöistä, esim. koodaus/konfigurointi-tekemisessä.
Cosmicin mainittavia etuja on:
- helposti omaksuttava ja stabiili
- kustannustehokas
- parantaa estimoinnin tarkkuutta
- koon määrittäminen antaa paremman mahdollisuuden kontrolloida vaatimusmäärittelyjen laatua

Cosmicilla arvioidaan prosessia ja sen tapahtumia, esim:
toimeksianto tulee sisään -> toimeksianto kuitataan vastaanotetuksi
taskin tekeminen aloitetaan -> aloituspäivä kirjataan

Näistä kaikista summauksena voisi todeta, että jonkinlainen estimointi on tarpeen, mikäli tekemistä halutaan suunnitella ja toteuttaa se jonkin määritellyn aikaikkunan sisällä jollain määritellyillä resursseilla, tekemistä jota halutaan mitata ja seurata. Koon mittaaminen on estimoinnissa tärkeää, jos sen perusteella esim. mitataan ja seurataan ja esim. laskutetaan toimittajayhteistyössä.
Tällöin voi olla haasteellista lähteä tekemään estimointeja demokraattisen arvioinnin perusteella, ja on ehkä perusteltua ottaa käyttöön funktionaalisempi ja standardisoidumpi menetelmä.

Cosmic on standardi, mutta sekin on muokattavissa erilaisiin tarpeisiin. Esim. jos Cosmicin perustana on mitata prosessin tietokannan kirjauksia (entries & reads), voidaan konfigurointitaskeissa ajatella kirjaukset esim tietue-taulu - tasolla vaikkapa näin:
Story: Rakenna hinnoittelut x, y, z tuotteeseen A jota käyttää valikoima 1
Prosessi:
kirjaus x tauluun x = 1*1=1
kirjaus y tauluun y = 1*1=1
kirjaus z tauluun z = 1*1=1
kirjaus x,y,z tauluun A = 3*1=3
kirjaus A tauluun 1= 1*1=1
Storyn koko: 1+1+1+3+1= 7


Lähteitä:
http://www.cosmicon.com/portal/public/COSMIC%20Method%20v3.0.1%20Measurement%20Manual.pdf
http://agile.dzone.com/articles/large-scale-scrum-and-cosmic

http://blogs.versionone.com/agile_management/2013/10/14/scalable-agile-estimation-and-normalization-of-story-points-introduction-and-overview-of-the-blog-series-part-1-of-5/

http://agile.dzone.com/articles/agile-estimation-practice

http://www.slideshare.net/alimenkou/agile-estimation-techniques

http://scrummethodology.com/scrum-effort-estimation-and-story-points/

Lean vs Scrum by Pavel Dabrytski

Hyvä kooste, josta löytyy perustietoa ja uusia ideoita.
Edelleen keskitytään periaatteisiin ja hukkaan, mutta painotetaan sitä miten scrumia voi kehittää leanin avulla.
Scrum on arvo-ohjattu kehys kehitykselle, ja lean auttaa optimoimaan sitä.
"Leania ei voi tehdä, mutta voimme käyttää sitä parantaaksemme prosessiamme"

Esim.
- user storyissä
- backlog-jäävuoren hallinnassa
- WIP-limiteissä
- testausohjatussa kehityksessä
- jatkuvassa toimituksessa

Lean startupissa:
Minimum viable product

• smoke test product
• deploy first, code later
• measure
• beware of vanity metrics
• generate more ideas

1. vältä hukkaa
2. korosta oppimista
3. päätä mahdollisimman myöhään
4. toimita mahdollisimman nopeasti
5. vahvista tiimiä
6. rakenna eheyttä
7. näe kokonaisuus

Perusasioita, joita korostetaan jatkuvasti. Silti, miksi se on niin vaikeaa?
- hukkaa tulee, koska hukkaa tehdään
- oppimista korostetaan, mutta opitaanko oikeita asioita?
- päätöksiä pakotetaan tekemään liian aikaisessa vaiheessa ja niihin jäädään jumiin
- toimitukset odottavat jumeja ja päätöksiä ja lopullisen kokonaisuuden valmistumista
- eheys kärsii, koska kokonaisuutta ei nähdä
- kokonaisuutta ei nähdä, koska keskitytään pieniin asioihin

Lean vs scrum from Pavel Dabrytski