Bugit pois Lean Six Sigmalla?

Ensimmäinen Lean Six Sigma -harjoitukseni on loppusuoralla: jäljellä on enää vaikein osa eli parannusten keksiminen ja aikaansaaminen! Projektini aiheena on ollut ohjelmistovirheiden ehkäiseminen ja havaitseminen. Edellisissä vaiheissa kaivoimme dataa muutostietokannasta ja versionhallinnasta sekä tutkimme virheiden juurisyitä ja niiden esiintymistä ohjelmiston eri osissa.

Mitä mieltä olen Lean Six Sigmasta? Kokemuksen syvä rintaääni syntyisi vasta usean erityyppisen projektin myötä, mutta pari ajatuksenraakiletta sallittakoon:

DMAICin kaltainen vaihemalli tuo ryhtiä parannushankkeeseen: osapäiväiset projektit tuppaavat hiipumaan hiljaa pois alkuinnostuksen jälkeen, jollei niillä ole selvää rakennetta.

Päätöksenteon perustuminen faktoihin ja tilastotieteeseen eikä mieleenjuolahduksiin on kaunis periaate, mutta Six Sigman tilastolliset menetelmät jäivät omassa hankkeessani vähälle käytölle, koska dataa ei ollut ihan tarpeeksi. Lisäksi ohjelmistovirheet ovat alttiita tulkinnalle: Mikä on virhe, mikä puuttuva ominaisuus? Onko virheet kuvattu samalla tavalla kaikissa projekteissa? Miten erilaisia juurisyyanalyyseja syntyisi, jos saman datan antaisi analysoitavaksi kahdelle eri porukalle? Vähäinenkin data voi silti estää hyttysen ampumisen tykillä.

Käytänkö Lean Six Sigmaa seuraavassa parannushankkeessani? Aika näyttää.

Vihreän vyön metsästys

Olen viime aikoina tutkaillut Lean Six Sigmaa, jonka käyttö on laajentunut muualla firmassamme. Tämä menetelmähän on yhdistelmä japanilaislähtöistä lean-ajattelua sekä Motorolan ja GE:n kehittämää Six Sigmaa. Sillä pyritään parantamaan yrityksen toiminnan nopeutta ja lopputulosten tasalaatuisuutta, ja   loppujen lopuksi tietenkin myös asiakkaan ja osakkeenomistajan tyytyväisyyttä.

Onko kenelläkään kokemuksia Six Sigman käyttämisestä tuotekehityksessä? Oma vihreä vyöni on vielä hankkimatta, mutta pienen itseopiskelun perusteella näyttää siltä, että tämän menetelmän lean-osuutta on helpompi soveltaa tuotekehitykseen, esimerkiksi Scrum-tiimien työnkulun nopeutukseen. Six Sigmassa on iso työkalupakki erilaisia matemaattisia menetelmiä, mutta miten moni niistä sopii muuhun kuin tuotannon tehostamiseen?

Kaikki parannusmenetelmät ovat oikeastaan jonkin pelon torjuntaa. Mitä menetelmän valinta kertoo valitsijasta?

• CMMI vs. kaaos ja epärationaalisuus
• Lean vs. tuottamaton ajankäyttö
• Six Sigma vs. hutilointi
• Scrum vs. väärien asioiden tekeminen ja yhteistyön puute

My Excellency

How did Scrum affect different aspects of the project?

Vaihdoin maanantaina toimenkuvaa ja titteliä: melkein yhdentoista vuoden rupeama ohjelmistokehityspäällikkönä on ohi, ja keskityn nyt yksikkömme tuotekehityksen parantamiseen. (Mitä hieman koominen titteli R&D Excellence Manager voisi olla suomeksi?) Nyt pitää vain hillitä intoaan ja miettiä suurempia linjoja eikä vain syöksyä heti yksittäisten parannuskohteiden kimppuun.

Vantaan-yksikkömme on nyt muuttumassa nopeasti, kun kasvamme ja kehitämme Sonalleve MR-HIFU -tuotteen rinnalle uutta liiketoimintaa. Kaksi ohjelmistokehitystiimiämme on käyttänyt Scrumia vuoden ajan, ja kokemukset ovat olleet enimmäkseen myönteisiä: ensimmäisen projektin jälkeen kukaan ei olisi halunnut palata vanhaan toimintatapaan, vaikka Scrumin päivärytmi onkin välillä tuntunut liian intensiiviseltä vanhaan viikkopalaverikäytäntöön verrattuna. Nyt pääsen tarkastelemaan koko tuotekehityksen toimintatapoja ja miettimään niiden parantamista. Mielenkiintoisia aikoja edessä!