Miten olla Lean

Osallistuin 21-22.4.2016 Mary ja Tom Poppendieckin Lean Development and Testing workshoppiin jossa paikalla oli iso joukko asiakkaitamme. Mary ja Tom toivat esiin erittäin kiinnostavalla tavalla Lean-periaatteita ja kertoivat, miten niitä saa käytäntöön. Työpajatyöskentely osallisti meidät kaikki osallistujat soveltamaan periaatteita suoraan oikeisiin tilanteisiin.

Itselleni päällimmäisenä jäi mieleen muutama konsepti, jotka ovat Leanin ytimessä.

1. Flow efficiency on tärkeämpää kuin Resource Efficiency. Tärkeää on siis saada yksittäinen asia, vaikkapa asiakkaan toive, läpi tuotekehityksen ja käyttöön asiakkaalle. Ei pidä optimoida resurssien käyttöä, kuten yksittäisen henkilön tai koneen työtunteja - se ei johda parhaaseen tulokseen, vaikka siltä voikin tuntua. Tämän virheen tekee suuri osa yrityksistä - ja se on helppoa korjata. Tutustuin periaatteeseen itse asiassa jo vuonna 1995 kun tein Wisconsin-Madisonin yliopistolla harjoitustyötä, jossa analysoitiin Leanin periaatteilla tietokonekorjaamon tavaravirrat - pystyimme suosittelemaan yhden työntekijän lisäämistä pullonkaulaksi muodostuvaan kohtaan, jolloin tietokoneet saatiin korjauksesta läpi merkittävästi nopeammin ja enemmän tuloja korjaamolle, vaikka tuo toinen työntekijä ei ollutkaan täystyöllistetty. Tuo harjoitustyö teki itsestäni Lean-fanin, mutta IT-maailmassa Leania tulee vaan sovellettua aivan liian harvoin. Yritysten tyypillinen painotus resurssien hyödyntämiseen ei  kannusta tähän.
2. Analysoi arvovirtaa (Value-Stream Mapping). Kun piirretään auki kaikki vaiheet, jotka ovat matkalla ajatuksesta käytössä olevaksi tuotteeksi, ja kirjataan kaikki viiveet ja odotusajat ylös, on se silmiä avartava kokemus. Ovatko kaikki ne backlogit oikeasti tarpeellisia. Miksi odotellaan useita viikkoja päätöstä yhdessä kohtaa? Miksi tehdään montaa asiaa yhtä aikaa - miksei keskitytä yhteen asiaan kerrallaan. Kaikilla näillä kysymyksillä löytyy helposti keinot tiputtaa läpäisyajat puoleen. Yhdistetään tiimejä, pannaan päätöksentekovalta suoraan prosessiin. Arvovirta on kaikille tuttu konsepti, mutta niiden lyhentäminen ei olekaan niin helppoa. Helposti vain toimitaan kuten toimitaan, kun ennenkin toimittu. Jotkut muutokset vaativat isompia muutoksia asenteissa ja organisaatioissa, mutta maksavat vaivan.
3. Delivery Pipeline. Rakennetaan tiimejä, jotka voivat automaattisesti tehdä kaiken designista kehityksen ja testauksen kautta käyttöönottoon asti. Toisin sanoen Full Stack team. Tai DevOps-toimintatapa. Kun annetaan tiimeille aito valta viedä oma (pieni) asiansa läpi ihan tuotantoon asti, alkaa syntyä arvoa nopeasti. Tarvitaan paljon monipuolista osaamista tiimiin, jotta se voi olla itseriittoinen, sekä hyvät kontaktit kaikkiin sidosryhmiinsä. Joskus arkkitehtuuri pitää ajatella ihan uusiksi, mutta sekin kannattaa. Saadaan nopeammin arvoa tuottava organisaatio, joka voi myös kokeilla asioita kustannustehokkaasti, kun oikeilta asiakkailta saadaan palautetta nopeasti eikä vuosien kuluttua. DevOps ja poikkitieteelliset tiimit ovat olleet lähellä sydäntäni pitkään - ne käyvät järkeen. Nyt oli taas upeaa kuulla vahvistusta omiin näkemyksiin.

Paljon muutakin erinomaista oppia kuultiin, esim. hieno harjoitus Customer Journeyn uudelleen pohtimisesta.

Kiitokset Marylle ja Tomille upeasta työpajasta.