Agile-ambivalenssi
Agilen ajatteleminen jättää minut ambivalentiksi.
Toisaalta kannatan kaikkea, mikä kehittää kehitystä.
Toisaalta aiheesta keskustelu lähiympäristöni Agile-konsulttien kanssa tuo mieleen ne keskustelut, joissa ei niin monta vuotta sitten yritin myydä samoille ihmisille ajatusta siitä, että lähdekoodin versionhallintaa ei kannata jättää vain sähköpostin varaan.
Onko se edistystä, mitä kutsutaan edistykseksi?
Olen kehittänyt softaa eri rooleissa yli 15 vuotta, ja tämä aika on opettanut minulle, että useimmilla maailman ilmiöillä, sekä hyvillä että huonoilla, on minulle paljon opetettavaa, ja silmien sulkeminen jokapäiväisiltä opetuksilta vain siksi ettei niiden takana ole auktoriteettia, on elämän hukkausta.
Samalla kun opin monenlaisista ilmiöistä niiden läksyn, tiedostan kuitenkin, ettei välttämättä näitä itsessään opettavaisia ilmiöitä ja tapoja toimia kannata yrittää jäljitellä omassa toiminnassa, sillä opetuksen hyödyllisyys on sidoksissa toiminnan kontekstiin.
Tehdashallin lean-ajattelun takana olevien kahden peruspilarin: ihmisten kunnioittamisen ja jatkuvan (tai jokapäiväisen, kokoaikaisen) toiminnan parantamisen/sopeuttamisen takana on tehdashallin konteksti.
Siinä kontekstissa, kuten tietävät ne, jotka ovat joskus tehdashallissa työskennelleet, on karkeasti ottaen kaksi roolia: työntekijät ja esimiehet. Vaikka tämä vaikuttaa pintapuolisesti varsin samalta asetelmalta kuin mitä käytämme koodausprojekteissa, se ei voisi olla erilaisempi. Koodari on asiantuntija joka ohjaa hyvin pitkälle omaa työtään, kun taas tehdashallissa duunari tekee yleensä ottaen mitä käsketään.
Tehdashallin Lean tuo duunari-työyksikön autonomian lähelle sitä paikkaa, jossa koodarin henkilökohtainen autonomia on koko ajan ollut. Tehdashallissa ei kyse ole demokratiasta, vaan siitä, että työyksiköllä, mukaan lukien tiimi työntekijöitä ja heidän työnjohtonsa, on mahdollisuus muuttaa omaa toimintatapaansa, yhdessä, työnjohdon ohjaamana.
Se, että Lean tuo ihmisten kunnioittamisen tehdashallin peruspilariksi on suhteellisen uusi juttu. Se tarkoittaa merkittävää henkistä muutosta asenteissa, alkaen asiakkaista ja yrityksen ylimmästä johdosta, välijohtoon ja työnjohtoon. Se toi tehdashalliin jotain sellaista, joka on aina ollut koodaajan maailman vakiokalustoa. Arvostuksen tunteen.
Tehdashallissa Lean oli merkittävä mullistus, jota on yritetty vaihtelevalla menestyksellä jäljitellä ympäri maailmaa. Sen vaikutus tehdastoimintaan on validoitu, ja ainoa este sen toistettavuudelle on asiakkaiden ja johdon päässä.
Ohjelmistokehityksessä Leania kutsutaan Agilen peruspilariksi.
Leanin validointikehystä tehdashallissa, ja sen vaikutusta tehdashalliin, myydään Agilen validointikehyksenä ja vaikutuksena ohjelmistokehitykselle.
Agilella ei ole muuta konkreettista validaatiota, sillä näkemäni Agile- projektit epäonnistuvat useammin kuin onnistuvat tuomaan Agile-konsulttien lupaamia etuja, ja onnistumisetkin selittyvät helpoimmin muutoksen ja lisääntyneen seurannan luomana placebo-vaikutuksena.
Siinä missä tehdashallin Leanin vaikutukset olivat seurattavissa, ja koko prosessin vuorovaikutusketju on ymmärrettävissä ja toistettavissa, ei Agilella ole sellaista kuvausta Agile-konsulttien lupaamiin positiivisiin lopputuloksiin johtavasta syy-seurausketjusta, josta eri merkittävät Agilistit olisivat edes lähestulkoon samaa mieltä, saati että ketjun osien vaikutuksia voitaisiin validoida pienemmissä osissa.
Täällä meillä Suomessakin Agileksi kutsutaan toimintatapoja, jotka eroavat toisistaan kuin yö ja päivä.
Eräs firma kutsuu toimintatapaa, jossa ohjelmistoja kehitetään demokraattisesti, ja ohjelmistoarkkitehtuurista päättävät äänekkäimmät ja itsepintaisimmat, Scrumiksi ja Agileksi. Toinen käyttää samoja termejä omasta perinteisestä toimintatavastaan, jota on vähän kuorrutettu Agile- terminologialla.
Toisaalta kannatan kaikkea, mikä kehittää kehitystä.
Onko se edistystä, mitä kutsutaan edistykseksi?