Vältä Pimeä Agile

Ketterästä ohjelmistokehityksestä, agilesta, pidetään niin paljon ääntä, että voisi luulla aivan kaikkien harjoittavan sitä. Ikävä kyllä agile on alkanut kärsiä vapaasti muuttuvien kuvausten ongelmasta, vähän kuin kilpailua syrjivää sääntelyä kutsutaan kapitalismiksi. Maailmalla on paljon esimerkkejä, että itse asiassa monet, jotka sanovat olevansa agileja, eivät sitä oikeasti ole. Nämä tahot harjoittavat Pimeää Agilea, ja näin sinä voit välttää syyllistymästä samaan.

Houkutus on suuri
Houkutus on suuri

Muista, mistä agilessa on kyse

Jotta voi välttää antautumasta agilen pimeälle puolelle, täytyy ensin muistaa mistä agilessa on kyse. Liike alkoi n. 15-20 vuotta sitten eri ideoiden koheesiosta. Ohjelmistokehitys oli hidasta ja kankeaa. Ohjelmoijat saivat olla kiitollisia jos näkivät saman koodin kehittyvän iteraatioissa, muuten kaikki tehtiin kerralla hyvin suunnitellusti. Agilen kenties tärkein vaikuttaja oli Extreme Programming -nimellä kulkeva joukko menetelmiä. Kirjoittamalla yksikkötestejä ja modulaarista koodia, harjoittamalla pariohjelmointia ja muokkaamalla koodia usein pystyy toimittamaan toimivia ratkaisuja hyvinkin nopeasti.

Scrum pähkinänkuoressa

Scrum on menetelmä, joka jakaa muutaman yksinkertaisen roolin kehittäjien ja liiketoiminnan kesken, antaen muutoin vapaat kädet toimia. Liikepuolelta kuullaan mitä tarvitaan. Tuoteomistaja päättää mitä voi ja pitää tehdä, toki pitäen liiketoiminnan mielessä. Kehitystiimi päättää aikataulut.

Päämääränä luottamus osapuolten välille

Liikepuolelle yrityksessä tämä on vaikea pala, koska hehän tuovat rahat sisään elättääkseen ohjelmoijia! Toisaalta, ohjelmoijat mahdollistavat tämän rahan tuomisen. Tällainen menetelmä, jolla laadukasta ohjelmistoa toimitetaan nopeasti, on tarkoitettu parantamaan luottamusta osapuolten välille. Liikemiesten ei tarvitse enää hönkiä ohjelmoijaparan niskaan kuukausikaupalla kun näytettävää tulee nopeammin. Ohjelmistopuoli alkaa luottaa liikemiehiin enemmän, kun palautetta saa nopeammin.

Ketterän ohjelmistokehityksen julistus kuvastaa muutamalla ranskalaisella viivalla ydinperiaatteet.

Tule pimeälle puolelle…

Ei mennyt kovinkaan kauaa, kunnes agilen pimeä puoli alkoi houkutella. Perinteiselle projektijohdolle Scrum Master -koulutus on tietysti yksi natsa CV:ssä muiden joukossa, mutta alunperin Scrummasterin piti olla yksi kehittäjistä. Mieluusti vähän väliä eri kehittäjä. Syyllistämättä tämän enempää projektipäälliköitä on käynyt niin, että ulkopuolinen Scrummaster lähestyy tilannetta usein komentavasti, ei fasilitoivasti.

Sen lisäksi, että Scrummasterin, tiimin fasilitaattorin, pitäisi olla kiinteä osa tiimiä, hänen pitäisi olla tekninen. Ymmärtämättä Extreme Programmingin tärkeyttä saatetaan ajautua tilanteeseen, jossa testit irrotetaan koodista tai kannustetaan ohjelmoijaa kirjoittamaan monoliitti, koska rajapintasuunnitteluun menee pidempi aika. Tai mitä tahansa muuta, johon ohjelmoijat samaistuvat pimeänä puolena. On valitettavaa, ettei Agile Manifesto nosta tätä yhdeksi periaatteeksi.

Toisin sanoen, Scrummasterin, tai minkä tahansa vastaavan, työ on puolustaa Scrumia ja teknistä laatua, eikä mitään muuta. Jos tämä ei pidä paikkaansa, et harjoita Scrumia, etkä luultavasti agilea muutenkaan.

Mistä tiedät siirtyneesi Pimeään Agileen?

On paljon tunnusmerkkejä, joista tietää lipsuvansa:

  • Työskentelyssä väheksytään suunnittelua, koska sehän olisi vanhanaikaista. Tiimin täytyy ymmärtää, että nopea koodin muokattavuus ei ole hyväksyttävä peruste aikaa hukkaavalle uudelleenkirjoittelulle, jos kerran voi suunnitella paremmin etukäteen.
  • Tuoteomistaja on suorittavalla tasolla tekemisissä ohjelmoijien kanssa, vaikuttaen (tai edes yrittäen vaikuttaa) työskentelyyn. Tuoteomistajan rooli on selventää työtehtäviä, ei muuttaa niitä työn aikana tai kertoa ohjelmoijille miten työ kuuluu tehdä.
  • On olemassa projektipäällikkö, joka pääsee häiritsemään esimerkiksi Scrumin sprinttien pituutta.
  • Vähintään viikottaisia isompia tehtävälistan muutoksia. Tekemättömien töiden listaa voi olla järkevää hienosäätää vaikka jatkuvasti, mutta sprintin tavoitteeseen ei saa kajota kun se on lyöty lukkoon.
  • Yksittäiset pienet alitehtävät tai vastaavat yksityiskohdat näkyvät ulospäin. Liiketoiminnan ei pitäisi välittää kuin päätason tehtävistä ja bugikorjauksista.

Pysy agilen valoisalla puolella

Mitä täytyy sitten pitää mielessä, että pysyisimme agilen valoisalla puolella? Ladon tähän listan, joka pätee melko hyvin, oli käytössä Scrum tai jokin täysin itsekeksitty juuri sinun tiimillesi toimiva malli.

  • Valmiin määritelmä, Definition of Done, sisältää aina vähintään yksikkötestit ja mahdollisesti muita laatukriteerejä. Kukaan tiimin ulkopuolelta ei saa vaatia kriteerien poistamista tai heikentämistä. Ketteryys vaatii laadukasta työtä, joten tiimin täytyy aina varata puskuria mahdollisille ongelmille, olivat ne tiukasta laadunvarmistuksesta huolimatta ilmenneitä bugeja tai jotakin muuta. Kukaan tiimin ulkopuolelta ei saa vaikuttaa ajanvarauksiin tai deadlineihin.
  • Tiimin on ansaittava luottamusta kertomalla tiimin jäsenille ongelmista. Scrummasterin on fasilitoitava ongelmat pois tieltä.
  • Tuoteomistajan on luotettava tiimiin. Jos jotain jää tekemättä sprintissä, sille on varmasti syy ja siitä tulee keskustella, mutta ei syyllistää.
  • Liiketoiminnan ei tarvitse myöskään tietää mistään story pointeista tai velocitystä tai muusta tiimin sisäisestä kirjanpidosta. Ihanteellisesti liiketoiminnan, poislukien tuoteomistajan tai muun yhteyshenkilön, ei tarvitse edes tietää harjoittaako tiimi Scrumia vai jotakin muuta.

Loppuun pari havainnollistavaa Youtube-videota:

 

 

***
Ylin kuva: Flickr CC, Holley & Chris Melton

Mihin leania tarvitaan – eikö terve järki riitä?

Lean-menetelmiin ensimmäisiä kertoja tutustuva kysyy usein, mihin moisia lähestymistapoja tarvitaan? Eikö terve järki riitä? Eikö prosessimallit ole tehty vain ylemmän johdon iloksi? Voiko yksikään prosessikehitystekniikka itse asiassa tuoda mitään uutta jos ongelmaa on jo ratkaisemassa alan paras ammattilainen tai firman kokenein osaaja?

Hyviä kysymyksiä. Itselleni hyötyjen ymmärtäminen oli välttämätön ensimmäinen askel lean-menetelmiin tutustumisessa.

1) Osastokohtainen korjaaminen ei riitä

Lean-metodit ovat parhaimmillaan silloin, kun katsotaan kokonaista prosessia hankinnasta asiakaspalveluun saakka. Tätä kokonaisuutta ei yksityiskohtaisesti tunne kukaan asiantuntija yrityksessä; päinvastoin, osaaminen on pilkottu siiloihin. Tässä kohtaa ammattiylpeys estää kysymästä naapurisiilon toiminnasta oikeita kysymyksiä, jotka voisivat tuottaa parhaan tuloksen. Väärät luulot muiden tarpeista tekevät todellisen muutoksen mahdottomaksi. Tyypillisessä organisaatiossa kunkin siilon prosesseja kehitetään itsenäisesti, miettien talousosaston, varaston tai tuotekehityksen tehokkuutta yrityksen kokonaisedun sijaan.

Ongelmat, jotka jäävät hierarkisten siilojen rajoille, eivät helposti ratkea hierarkisen johtamisen menetelmillä. Tarvitaan jotain muuta.

2) Yhteinen kieli ja ymmärrys välttämättömiä

Muutoksen johtaminen vaatii yhteisen sanaston ja termistön. Lean-sanasto on luonteva valinta, sillä sitä ei tarvitse itse keksiä eikä se jää organisaation sisäiseksi omaksi slangiksi. Varsin suoraviivaiset ja helposti omaksuttavat termit ja niiden takana olevat mallit on kehitetty jatkuvan kehittämisen viemiseen tehdastyöhön ja ovat myöhemmin osoittautuneet toimiviksi sekä toimistoissa että tuotantopuolella. Ilman yhteistä kieltä ei voi olla yhteistä muutosta. Wittgensteiniä siteeraten: ”Mistä ei voi puhua, siitä on vaiettava.”

3) Radikaali tehostaminen

Lean-filosofiassa osa kannattavuuden parantamisen arvoista ovat päälaellaan totuttuun länsimaiseen toteutustapaan nähden. Liialliset varastot nähdään turhana ja liiallinen testaus nähdään liian huonona laatuna prosessin edellisessä vaiheessa. Nämä uudet arvot ja uusi kokonaisuuden hallintatapa on ollut Toyotan salaisuus, jolla valmistaja on noussut pienestä paikallisesta yrityksestä alan suurimmaksi noin 50 vuodessa. Kun kaikki tehdään hyvin, säästö on odotettua suurempi.

4) Pomottelu kielletty

Lean-filosofia lähtee mittaamisesta, sekä ennen muutosta, että muutoksen jälkeen. Tämä näennäisen vaatimaton vaihe muuttaa  päätöksenteon kokonaan. Useimmissa hierarkisissa organisaatioissa prosessimuutokset ovat esimiestyönä tehtyjä valintoja, jotka heijastavat voimakkaasti päätöksentekijän persoonaa ja preferenssejä. Jälkipuheet ja kaipuu vanhaan ovat tavallisia muutoksen jälkeisiä reaktioita, jos muutoksen hyödyt eivät ole näkyviä. Lean-muutoksia mitataan aina. Hyöty tehdään näkyväksi, epäonnistumiset myös. Muutosta on tämän jälkeen vaikea käyttää tai nähdä vallankäytön välineenä.

5) Nopea käyttöönotto ytimessä

Todellisen muutoksen suurin este on usein muutoksen suunnittelijat ja jopa kokonaiset muutoksen suunnitteluyksiköt. Tällaisten kehityspäälliköiden helmasynti on suunnittelun korostaminen ja tekemisen viivyttely. Lean-menetelmän ytimessä on joukko hyväksi havaittuja tapoja, joilla havaitut muutostarpeet voidaan viedä käytäntöön välittömästi. Keskittymällä niihin muutoksiin, joilla on suurin vaikutus ja jotka voi helpoimmin viedä käytäntöön muutoshanke alkaa tuottaa hyötyä nopeasti. Tehokkuuden parantuessa prosessiin kuuluvilla on enemmän aikaa tehdä vaikeampia ja hitaammin käyttöönotettavia muutoksia.

Terveellä järjellä voi muuttaa oman työnsä ja oman osastonsa toimintatapoja, mutta kokonaisen monen osaston prosessin parantamiseen kannattaa ottaa käyttöön parhaiksi havaitut ajattelun työkalut. Lean-menetelmät kuuluvat ehdottomasti tähän joukkoon. Kun lean-työtä on tehty aikansa, lean-filosofiasta tulee osa koko yrityksen terveen järjen käyttöä.