Ketteryyden ydin

15.6.2010 Kirjoittanut Lare Lekman

Scrum Practitioners -ryhmässä käydään mielenkiintoisia keskusteluita, kuten When your company implemented Scrum, did they keep it pure or did they adapt it to their culture?

Otsikko on lähtökohtaisesti erikoinen, koska Scrum sovitetaan aina omaan kulttuuriin esimerkiksi valitsemalla sprintin eli kehitysjakson pituus. Tällöin organisaation kulttuuri myös sopeutuu Scrumiin.

Keskustelun kommentit jakautuvat karkeasti puristisiin ja pragmaattisiin. Toisten mielestä Scrumia ei tulisi muuttaa ja toisten mielestä hyvä lopputulos on tärkeämpää kuin mallin noudattaminen.

Huomaan lukeutuvani käytännöllisesti ajatteleviin. Uskon, että aluksi kannattaa soittaa nuoteista ja kuunnella opettajaa. Kun harjoituksen kautta oivaltaa pianon koskettimien yhteyden musiikkiin ja Scrumin elementtien yhteyden projektin lopputulokseen, voi tarvittaessa muokata yksittäisiä elementtejä ja ottaa vastuun lopputuloksesta.

Pari vuotta valmennettuani en muista tavanneeni montaa “puhdasta” Scrum-toteutusta, mutta monia kiitettäviä toteutuksia. Useimmilla organisaatioilla riittää tekemistä Scrumin perusteissa, kuten sprinttien rutiineissa, vaatimusten pilkkomisessa, priorisoinnissa tai kehitysnopeuden mittaamisessa vähintään sprintin lopussa.

Törmättyäni usein perustason haasteisiin olen karsinut ehdottomia vaatimuksiani ja päätynyt yhtäläisiin minimivaatimuksiin Scrum Practitioner -ryhmän Bruce Rennien kanssa:

  1. Toimita säännöllisesti jotain
  2. Varmista, että toimitat korkeimman prioriteetin asiat (ts. sopeudut nopeasti muutoksiin)
  3. Pyri parempaan jokaisessa iteraatiossa/julkaisussa

Nämä minimivaatimukset eivät vielä täytä esimerkiksi Scrumin kriteerejä, mutta muodostavat mielestäni ketteryyden ytimen. Ne antavat myös pohjan ketterien menetelmien soveltamiselle johtamisessa, julkishallinnossa ja valmistavassa teollisuudessa, jotka saattavat vaatia ohjelmistokehityksestä poikkeavia ratkaisuja.

Lopuksi Scrumin isän Ken Schwaberin viisaat sanat:

Scrum is an organizational change process masquerading as a project management process wrapper. If you adopt pieces of Scrum, you don’t get this benefit… and you will likely stop adopting pieces once the going gets hard.

Kategoria(t): Julkishallinto, Ketteryys, Scrum, Tuotekehitys, Tuottavuus | 2 Kommenttia »

Vesiputouksen alkulähteillä

31.5.2010 Kirjoittanut Lare Lekman

Amerikkalainen tiedemies Winston W. Royce (1929–1995) esitteli vuonna 1970 ohjelmistokehityksen vesiputousmallin. Hän ei tosin itse kutsunut malliaan vesiputoukseksi saati pitänyt sitä kovin onnistuneena.

I believe in this concept, but the implementation described above is risky and invites failure. -Winston W. Royce

Vesiputousmalli saavutti 1970-2000 suuren suosion, koska se auttoi ohjelmistofirmoja perustelemaan asiakkailleen määrittelyn ja suunnittelun merkityksen lisäkustannuksineen. Royce kuitenkin huomasi mallinsa puutteet, ts. ettei mikään vaiheista todellisuudessa tule kerralla valmiiksi vaan kussakin tarvitaan useampia iteraatioita.

Mikä sitten synnytti kankean ja utopistisen vesiputouksen? Uskon vastauksen löytyvän teollisesta vallankumouksesta, kun Henry Ford avasi vuonna 1913 ensimmäisen autojen sarjatuotantolinjan. Fordin T-mallin tuotantolinja koostui 84:stä kokoomispisteestä, joiden muuttaminen oli erittäin hidasta ja kallista. T-mallin kokoonpanolinjaa ei tämän vuoksi juurikaan muutettu lähes kahteenkymmeneen vuoteen.

Any customer can have a car painted any colour that he wants so long as it is black. -Henry Ford

Fordin menestyksen myötä monet teollisuudenalat omaksuivat sarjatuotannon ja fordismin. Näin toimi myös Winston W. Royce ohjelmistoteollisuuden kohdalla, vaikkei yhteyttä ehkä havainnut. Pyrkiihän vesiputous määrittelemään “kokoonpanolinjan”, jonka loppupäästä tulee kerralla valmis ohjelmisto ja jossa tarkasti erotellut työvaiheet voidaan tarvittaessa teettää osaamiseltaan rajoittuneilla työntekijöillä.

Fordin panos teolliseen vallankumoukseen oli merkittävä, mutta fordismin kangistavat vaikutukset tuntuvat ohjelmistoteollisuudessa yhä tänään.

Mielenkiintoisesti ohjelmistoteollisuus toistaa itseään lainaamalla taas autoteollisuuden parhaita oppeja. Tällä kertaa Toyota Production Systemin menestyksen taustalla olevaa lean manufacturingia, joka on yksi ketterän kehityksen tukijaloista. Siinä prosessia kehitetään vähentämällä työtä haittaavaa jätettä, toteuttamalla säännöllisesti pieniä parannuksia, mittaamalla parannusten tulokset ja vertaamalla tuloksia edellisiin.

Ympyrä sulkeutuu vuonna 2013, jolloin juhlitaan autoteollisuuden sarjatuotannon satavuotispäivää. Toivottavasti olemme yhtä fiksuja kuin autoteollisuus ja vaihdamme juhlan kunniaksi ketterämpään menopeliin.

Kategoria(t): Ketteryys, Tuotekehitys, Tuottavuus | 2 Kommenttia »

Ketteryyttä julkishallintoon

4.5.2010 Kirjoittanut Lare Lekman

Elinkeinoelämän Valtuuskunnan kohuraportti Nykyaikaa Etsimässä patistaa valtiota pikaiseen korjausliikkeeseen tietoyhteiskunnan pelastamiseksi:

Ilman saumattomasti toimivia digitaalisia palveluja emme selviä ikääntymisen, talouskriisin ja kiihtyvän globalisaation haasteista.

Yhdeksi tärkeimmistä keinoista raportti nostaa ketterät kehitysmenetelmät:

Ketterässä kehityksessä ei yritetäkään saada kerralla valmista. Toiminnan fokus ei ole ennalta annetuissa tai tehdyssä järjestelmän vaatimusten määrittelyssä vaan kansalaisten, yritysten ja yhteisöjen tarpeissa. Jatkuvasti kehittyvät järjestelmät ovat jatkuvassa evoluution tilassa, jota ohjaavat käyttäjälähtöisyys ja iteratiivisuus, kehittäminen pala palalta.

Tietoyhteiskunnan kehittämiskeskuksen ja Digian maksuttomaan Scrum-aamiaisseminaariin saapui tupa täyteen aiheesta kiinnostuneita. Sain kunnian avata tilaisuuden briiffillä ketteryyttä julkishallintoon (PDF).

Ketterästi lähes kymmenen vuotta toimineena uskon vilpittömästi, että julkishallinnon haasteisiin voidaan vastata ketterällä ajattelumallilla ja menetelmillä. Maa- ja metsätalousministeriöllä on jo hyviä kokemuksia julkishallinnon Scrum-hankkeista julkista tarjouskilpailua myöten.

Hankintalain kesyttäminen lähtee siitä, että pyydetään valmiin ohjelmiston sijaan tarjous osaavista henkilöistä, jotka organisoidaan kehitystiimiksi tilaajan omiin tiloihin ja projektijohdon alaisuuteen.

Mikäli projektin jakaminen 2-4 viikon kehitysjaksoihin tuntuu vaikealta, voidaan ketterä kehitysmalli rajata projektin toteutusvaiheeseen ja perustella riskien hallinnalla. Tällöin etupainotteista määrittelyä ja suunnittelua voidaan tehdä hieman aiempaa vähemmän, koska osa tästä työstä siirtyy kehitysjaksoihin. Lisäksi perinteinen testaus siirtyy projektin lopusta pääosin kehitysjaksojen sisään. Projektin loppuun voi tarvittaessa lisätä yhden tai useamman testijakson ennen järjestelmän käyttöönottoa.

Kiitos Digialle ja TIEKE:n Veli Riekille sekä Eppie Elorannalle onnistuneista seminaarijärjestelyistä.

Kategoria(t): Julkishallinto, Ketteryys, Scrum, Tuottavuus | 1 kommentti »

Suomenkielinen Scrum Guide

19.3.2010 Kirjoittanut Lare Lekman

Erinäisten sattumien summana sain kunniatehtävän suomentaa Ken Schwaberin ja Jeff Sutherlandin maksuttoman The Scrum Guiden.

Scrum-termien suomennokseen osallistuivat Arto Eskelinen, Petri Heiramo, Antti Järvinen, Lasse Koskela, Samuli Ruuskanen, Marko Taipale, Pentti Virtanen, Vesa Vänskä ja Lasse Ziegler. Kiitos koko tiimille idearikkaasta ja avoimesta yhteistyöstä!

Ehkäpä suurimpana saavutuksena saimme äänestettyä Scrum-termien suomennokset, joita oppaassa käytetään.

Lataa tästä suomenkielinen 22-sivuinen käännös: Scrum Guide – FI

Oppaan ylläpito siirretään mahdollisesti Agile Finlandille, joka voisi valita “tuoteomistajan” ylläpitämään opasta esimerkiksi vuodeksi kerrallaan, kun alkuperäisversioon tehdään muutoksia.

Kehittäviä lukuhetkiä Scrum Guiden parissa!

Ps. Voit lähettää korjaus- ja parannusehdotuksia kommenttina tähän artikkeliin.

Kategoria(t): Johtaminen, Julkishallinto, Ketteryys, Kirjallisuus, Scrum, Tuotekehitys, Tuottavuus | 4 Kommenttia »

Ongelman määritelmä ja ratkaiseminen

24.2.2010 Kirjoittanut Lare Lekman

Saat todennäköisesti palkkaa erilaisten ongelmien ratkaisemisesta. Mutta osaatko määritellä mikä on ongelma? Donald Gause ja Gerald Weinberg määrittelevät ongelman kirjassaan Are Your Lights On seuraavasti:

Ongelma on havaittu ero nykytilan ja tavoitetilan välillä.

Jokaisella meistä on oma käsitys nykytilasta ja tavoitetilasta. Erilaiset käsityksemme tekevät monimutkaisten ongelmien kommunikoinnista saati ratkaisemisesta haastavaa. Tässä muutamia kirjan vinkkejä:

  • Varmista kenen ongelmaa olet ratkaisemassa, ts. kenet halutaan tehdä onnelliseksi.
  • Älä hyväksy ratkaisuehdotusta ongelman määrittelyksi, varsinkin jos ratkaisuehdotus on omasi.
  • Et voi koskaan olla varma että ongelman määritelmäsi on oikea, mutta älä koskaan lopeta sen etsimistä.
  • Jokainen ratkaisu on seuraavan ongelman lähde.
  • Jos et keksi vähintään kolmea asiaa jotka voisivat mennä pieleen ratkaisussasi, et ymmärrä ongelmaa.
  • Jos kirjoitat ongelman määrittelyn, varmista että kaikki ymmärtävät tekstin samalla tavalla.
  • Älä ratkaise muiden ongelmia silloin kun he voivat hyvin ratkaista omat ongelmansa.
  • Ongelman lähde on usein itsessäsi.

Kuinka ongelma sitten ratkaistaan? Ken Watanaben mainio, alunperin lapsille suunnattu Problem Solving 101 -kirja opastaa ratkaisemaan ongelman kuin ongelman neljällä vaiheella:

1. Kirkasta nykytilanne.
2. Selvitä ongelman perimmäinen aiheuttaja.
3. Ideoi ratkaisuvaihtoehtoja ja tee toimintasuunnitelma.
4. Toteuta ja mukauta suunnitelmaa, kunnes ongelma on ratkaistu.

Vaiheet noudattavat japanilaista ajattelua, jossa tuotetta tai prosessia parannetaan pienin mitattavin askelin. Pienistä parannuksista syntyy ajan kuluessa suuria tuottavuus- ja kustannushyötyjä.

Suurimmat taloudelliset epäonnistumiset syntyvät, kun ratkaistaan väärää ongelmaa. Siksi ongelman perimmäisen aiheuttajan selvittäminen on usein viisas lähtökohta.

Ongelma voidaan ratkaista myös tavoitteen kautta. Joskus havaittuja ongelmia jäädään märehtimään kuukausitolkulla sen sijaan, että mietittäisiin mikä on tavoitetila johon pyritään.

Tarinan mukaan konsultti saapui vetämään työpajaa johtoryhmälle, joka oli pitkään märehtinyt ongelmiaan eikä uskonut löytävänsä ratkaisua. Ongelmien tonkimisen sijaan konsultti komensi johtoryhmän miettimään mihin tavoitetilaan se pyrkii. Tavoitetilan kirkastuttua hän kysyi, mikä estää yritystä toimimasta tavoitetilan mukaisesti välittömästi. Näin päästiin takaisin ongelmiin, mutta nyt ratkaisun näkökulmasta.

Tavoitelähtöisessä ongelmanratkaisussa on se merkittävä ero, että tällöin lähdetään tavoitetilan määrittelystä nykytilan ongelmien sijaan. Ongelmiin toki palataan ja niitä ratkaistaan, mutta vain siltä osin kuin tavoitetilan saavuttaminen edellyttää.

Harvardin professori Stephen Kosslynin mukaan todelliset ja kuvitellut mielikuvat käsitellään aivoissa pitkälti samoin. Myös Albert Einstein on sanonut, ettei ongelmaa voi ratkaista samassa mielentilassa, jossa se on aiheutettu. Kannattaa siis miettiä ajatteleeko ongelmia vai ratkaisuja.

Suosittelen lämpimästi kokeilemaan tavoitetilan määrittelyä ongelmiin jämähtämisen sijaan. Parhaat ratkaisut vaativat yleensä luovuutta, riskiä ja huumorintajua, joten lopuksi kannustusta kaikille luoville ongelmanratkaisijoille:

Älä vaivaudu ratkaisemaan ongelmia ihmisille, joilla ei ole huumorintajua.

Kategoria(t): Johtaminen, Ketteryys, Kirjallisuus | 2 Kommenttia »

Agile Record

5.2.2010 Kirjoittanut Lare Lekman

Agile Record on uusi ketterille ohjelmistokehittäjille ja testaajille suunnattu PDF-muotoinen aikakausilehti.

The magazine is for free and is open to interchange knowledge, opinions, case studies and project stories that help the community to move forward. There are no restrictions for anyone. We want to encourage you to send us your contribution.

Mainosrahoitteinen Agile Record ilmestyy neljä kertaa vuodessa ja sitä julkaisee saksalainen yritys.

Lehden ensimmäinen numero sisältää runsaasti testaamiseen liittyviä artikkeleita. Kannattaa tutustua.

Kategoria(t): Ketteryys, Kirjallisuus, Tuotekehitys | Jätä kommentti »

Onnistumisen kolme ulottuvuutta

26.1.2010 Kirjoittanut Lare Lekman

On luonnollista keskittyä liiketoiminnallisiin tavoitteisiin, jotta projekti onnistuu talouden mittareilla.

Seuraava hanke voi kuitenkin mennä teknisesti tai taloudellisesti metsään, jollei sen tavoitteisiin sisällytä piirteitä onnistumisen kaikista ulottuvuuksista:

  1. Lopputulokset
  2. Työskentelyprosessi
  3. Muodostuneet ihmissuhteet

Ketteryydessä pyrimme suoraviivaisesti tuloksiin, mutta arvostamme myös prosessin ja ihmissuhteiden säännöllistä kehittämistä. Synkronoidun ryhmätyön kautta saavutamme paremman yhteishengen, synergiaedun ja kasvatamme näin myös tulevien onnistumisten todennäköisyyttä.

Kehitettävään tuotteeseen muodostuu teknistä velkaa, kun tuotejulkaisu runnotaan kiireessä valmiiksi. Organisaatioon taas muodostuu prosessi- ja ihmissuhdevelkaa, kun näiden kehitystarpeet sivuutetaan.

Kehitysprosessia ei tarvitse (eikä pidä) kehittää jatkuvasti, koska loputon muutos vaikeuttaa työhön keskittymistä. On kuitenkin tärkeää kehittää prosessia säännöllisesti esimerkiksi retrospektiivien yhteydessä, noin kuukauden välein.

Retrospektiivi-tapaamisessa (Latinasta retrospectare, “katso taakse”) jokainen kertoo vuorollaan, mikä hänen mielestään onnistui hyvin, mikä huonosti ja mitä voitaisiin jatkossa kehittää. Näitä tietoja hyödynnetään seuraavien työjaksojen suunnittelussa ja prosessin kehittämisessä. Kun kaikki saavat vuorollaan puhua avoimesti vaikeistakin asioista, kehittyy prosessin lisäksi luottamus ja ihmissuhteet.

Kaikkia retrospektiivissä käsiteltyjä asioita ei välttämättä tarvitse edes toteuttaa – monesti riittää että asiasta keskustellaan. Tilaisuuden lopuksi onkin hyödyllistä äänestää tai muuten vahvistaa, mitkä ehdotuksista toteutetaan, kuinka laajasti, kenen toimesta ja millä aikataululla.

CC Attribution: charmcaster the sorceress@Flickr

Kategoria(t): Johtaminen, Ketteryys, Scrum, Tuotekehitys | Jätä kommentti »

Anna Adaptiivinen ja Pertti Prediktiivinen aurinkolomalla

21.1.2010 Kirjoittanut Lare Lekman

Anna ja Pertti aloittivat suunnittelun hyvissä ajoin yli puoli vuotta ennen lomaa. Anna oli seikkailullisella päällä ja ehdotti Pertille, että pakattaisiin vain välttämättömimmät ja mentäisiin Helsinki-Vantaalle bongaamaan ensimmäinen molemmille sopiva “äkkilähtö”.

Pertti oli toista mieltä. Täydellisen loman varmistamiseksi matka tulisi varata kuusi kuukautta etukäteen, jotta se saataisiin edullisemmin. Anna suostui Pertin toiveeseen arvaten, että Pertti stressaisi lomalla mikäli ei etukäteen tietäisi milloin siirrytään minnekin. Lopulta varattiin lennot ja hotelli Meksikon suositusta rantakohteesta.

Pari kuukautta ennen lomaa Pertti esitteli Annalle lomalistan. Tuohon pieneen ihmeeseen oli kirjattu kullekin päivälle ne aktiviteetit, jotka perillä tulisi kokea. Eikä Pertti pelleillyt, vaan perusteli Annalle naama vakavana, miksi jokainen listalle merkitty museo, teemapuisto tai retki olisi tärkeä ja ainutlaatuinen. Sitäpaitsi listan kirjoittaminen oli vaatinut Pertiltä useiden iltojen netissä surfaamisen, joten lomalista oli liian arvokas enää kritisoitavaksi.

Anna alkoi voida hieman pahoin ja kysyi, mitkä lomalistan asiat olisivat Pertille kaikkein tärkeimmät. Pertin mielestä kaikki olivat kuitenkin tasan yhtä tärkeitä ja kaikki oli myös koettava. Kerranhan sitä todennäköisesti vain Meksikoon mennään!

Muutama viikko ennen lomaa Pertti laati yksityiskohtaisen pakkauslistan, jonka avulla hän hankki ja pakkasi omaan matkalaukkuunsa kaiken tarpeelliseksi kokemansa. Ihmeissään Pertti katseli Annaa, joka lyhyen neuvonpidon jälkeen pakkasi omaan matkalaukkuunsa vain murto-osan Pertin tavaramäärästä.

Ensimmäisenä iltana Meksikossa Pertti kaivoi lomalistan esiin ja kertasi Annalle tulevan ohjelman. Annaa etukäteen määritelty “suoritusloma” edelleen ahdisti, mutta hän puri hampaansa yhteen ja päätti osallistua parhaansa mukaan. Muutama päivä sujuikin hyvin ja Anna sekä Pertti kokivat ikimuistoisia elämyksiä, vaikka monta idyllistä kahvilaa ja ainutlaatuista hetkeä piti ohittaa tiukassa aikataulussa pysymiseksi.

Kolmannen päivän iltana Anna totesi olevansa niin väsynyt, että lepäisi seuraavan päivän hiekkarannalla. Pertti järkyttyi Annan ehdotuksesta, mutta myöntyi lopulta todettuaan, että kaipasi itsekin lepoa.

Annan kanssa rannalla lepäillessään Pertti tutki lomalistaa. Oltiin päivä aikataulusta jäljessä! Mikä pahinta, uutisten erikoislähetys oli juuri antanut alueelle korkeimman luokan hurrikaanivaroituksen. Rantakohteen puotien omistajat sulkivat kiireesti liikkeitään ja naulasivat vanerilevyjä näyteikkunoidensa suojaksi.

Seuraavan vuorokauden Anna ja Pertti pelkäsivät hotellin kellarissa kymmenien muiden turistien kanssa. Myrskyn laannuttua lomakohde oli muuttunut osin tuhoutuneeksi kriisialueeksi, jolta puuttui sähkö ja juokseva vesi. Onneksi armeija oli komennettu raivaamaan kaatuneita puita ja siellä täällä lojuvia talojen kattoja.

Anna ja Pertti olivat iloisia ollessaan hengissä, mutta Pertin lomatunnelma oli kateissa. Kaikki lomalistan kohteet oli tuhojen vuoksi suljettu, eikä loppulomalla voinut tehdä muuta kuin rentoutua! Kiukkuaan niellen Pertti puhisi, että Meksikoon täytyisi vielä palata tekemään loputkin lomalistan asiat. Anna taas oli muistorikkaaseen ja todelliseen tilanteeseen sovitettuun lomaan erittäin tyytyväinen.

Löydätkö tarinasta  yhtäläisyyksiä lomailuusi tai projektinhallintaan? Pidätkö jompaa kumpaa ajattelutapaa toista hyödyllisempänä? Kuinka itse suunnittelet ja sopeudut muutoksiin?

CC Attribution: Alaskan Dude@Flickr

Kategoria(t): Kahvitauko, Ketteryys | 3 Kommenttia »

Ketterän projektinhallinnan elementit – puuttuuko mitään?

18.1.2010 Kirjoittanut Lare Lekman

Ketterät menetelmät sisältävät riittävän paljon elementtejä ollakseen hyödyllisiä mutta riittävän vähän elementtejä soveltuakseen useimpiin kehityshankkeisiin.

Esimerkiksi Scrum sisältää vain yhdeksän elementtiä:

  • Kolme roolia
  • Kolme dokumenttityyppiä
  • Kolme aktiviteettia

Minimalistisuuden vuoksi ketteriä menetelmiä on lähes aina hyödyllistä täydentää lisäämällä piirteitä toisista menetelmistä. Ketteryyden soveltamisessa vallitseekin synerginen “sekä että” -ajattelu “joko tai” -ajattelun sijaan.

Tuotekehityksen prioriteetit (product backlog) perustuvat tuotteen visioon, jonka tuoteomistaja määrittelee. Ketterät menetelmät eivät kuitenkaan ota kantaa siihen, kuinka visio tuotetaan, kommunikoidaan ja ylläpidetään linjassa yhtiön strategian kanssa.

Kuinka ketterää kehitystä sitten ohjataan johtotasolla, varsinkin kun tuoteomistajia ja kehitysryhmiä on useampia?

Taulukossa on listattu ketterän projektinhallinnan tärkeimpiä elementtejä johtamisen näkökulmasta:

Mikä Mitä
Projektin johtoryhmä
 Ylläpitää tuotekehityksen Tiekarttaa ja synkronoi tuoteomistajien tuotevisiot yhtiön strategiaan
Kehitysryhmä Auttaa paloittelemaan ja aika-arvioimaan Product Backlogia
Jakson suunnittelukokous Suunnittelee jakson realistisen tavoitteen ja sisällön
Jakson arviointikokous Arvioi jakson tavoitteen ja sisällön toteutumista (demo)
Daily Scrum Suunnittelee ja synkronoi päivän työt
Retrospektiivi Opitaan jakson tai julkaisun virheistä ja onnistumisista

Projektin johtoryhmä on hyväksi havaittu keino ylläpitää tuotekehityksen Tiekarttaa (roadmapia) ja synkronoida sen avulla tuotevisiot yhtiön strategian mukaisiksi. Näin tuoteomistajat saavat säännöllisesti palautetta ja voivat kehitysryhmineen helpommin ylläpitää tuotteensa työjonoa.

Tuotekehityksen johtoryhmä tapaa yleensä 1-4 viikon välein. Johtoryhmään kannattaa valita pysyvät jäsenet tuotekehityksen, tuotehallinnon, myynnin sekä markkinoinnin johdosta ja hyödyntää tarvittaessa vierailevia asiantuntijoita. Osan jäsenistä olisi hyvä kuulua myös yhtiön johtoryhmään, jotta strategiatieto on saatavilla.

Kuinka teillä johdetaan ketterää kehitystä? Hyödynnättekö projektin johtoryhmää tai muita lisäyksiä, joihin alan kirjallisuus ei ota kantaa?

Kategoria(t): Johtaminen, Ketteryys, Scrum, Tuotekehitys | 5 Kommenttia »

Hävitä erillinen innovaatioprosessi

14.1.2010 Kirjoittanut Lare Lekman

Suomi on Pelle Pelottomien luvattu maa. Meillä innovaatioihin liittyy vahva tunnelataus ja kansallinen ylpeys.

Tutkimuksen* mukaan suomalaisilla oli vuonna 2005 seitsemänneksi eniten kansainvälisiä patenttihakemuksia asukaslukuun suhteutettuna. Tämä tarkoittaa noin 50 kv-patenttihakemusta per miljoona suomalaista.

Uusista keksinnöistä odotetaan ratkaisuja niin ilmastonmuutokseen kuin maamme talouden elpymiseen. Innovointi onkin taas kuuma aihe yrityksissä, joissa innovaatioprosesseja viilataan vauhdilla. Mutta mietimmekö riittävästi innovoinnin tarkoitusta ja toteutustapoja?

Tulos = Idea x Toteutus x Kaupallistaminen

Yhtälö julkaistiin alunperin 1950-luvulla, tosin ilman mausteeksi lisäämääni kaupallistamista, joka on nykyisin yhä tärkeämpää.

Kaavan mukaan täyden kympinkin idea on käytännössä arvoton, jos sitä ei koskaan toteuteta ja kaupallisteta (10 x 0 x 0 = 0). Tyypillisesti organisaation tarpeettomat ideat varastoidaan vastaisen varalle, vaikka toimintaan selvästi sopimattomat jätekeksinnöt voitaisiin varastoinnin sijaan trendikkäästi kierrättää yhteiskunnan hyväksi.

Asiaa pohdittuani lakkasin pihtaamasta ideoitani. Nykyisin jaan tarpeettomat ideani auliisti kiinnostuneille, koska toteutus, rahoittaminen ja kaupallistaminen vaativat merkittävää sitoutumista. Miksi pihdata lähes ilmaista ideaa jos ei ole ryhtymässä tuumasta toimeen?

Vastaavasti täydellinen toteutuskaan ei auta jos idea on surkea tai markkinointi, hinnoittelu tai myyntikanava puuttuu. Tällöin lopputulos lähestyy edelleen nollaa. (0 x 10 x 0 = 0)

Loistava kaupallistaminen on samoin hampaaton, jos idea tai toteutus on sutta ja sekundaa. (0 x 0 x 10 = 0)

Jone Nikula sivusi aihetta Yrittäjä-lehden artikkelissaan Inspiraatio vs. perspiraatio – innovaatio ei yksin riitä. Kirjoituksessa hän korostaa sinnikkään toteutuksen merkitystä hyvässä lopputuloksessa.

Saku Tuomisen ja Katja Lindroosin syksyllä 2009 julkaistu kirja Ravistettava, omskakas pureutuu myös asian ytimeen:

Monet ovat sitä mieltä, että ei maailmasta ideoita puutu, maailmasta puuttuu tekijöitä. Tämä ajatus lähtee siitä virheellisestä oletuksesta, että toteuttaminen ei olisi osa ideointiprosessia, että kyseessä olisi kaksi erillistä prosessia.

Laadukas toteuttaminen kuitenkin koostuu sarjasta vaiheita, jotka usein ovat ihan omia ideoitaan. Lopputulos koostuu sadoista pienistä yksityiskohdista, jotka voivat olla joko oivaltavia tai ennalta arvattavia.

Maailma on täynnä huonosti toteutettuja hyviä ideoita ja hyvin toteutettuja keskinkertaisia ideoita. Näistä kahdesta heikompikin idea hyvin toteutettuna voittaa aina. Siksi on olennaisen tärkeää muistaa, että idea on loppujen lopuksi ainoastaan niin hyvä kuin sen osakseen saama toteutus.

Ideoinnin ei siis pitäisi olla muista työvaiheista erillinen prosessi, kuten 90-luvun projektimalli uskotteli, vaan normaali osa koko organisaation päivittäistä toimintaa. Näin ideoiden soveltuvuutta, toteutusta ja kaupallistamista arvioidaan ja ohjataan säännöllisesti yhteistyönä.

Yhdistämällä innovaatioprosessi strategiaan, tuotekehitykseen sekä myyntiin ja markkinointiin voidaan innovointi kohdistaa liiketoiminnan tärkeimpiin ongelmiin. Scrumin avulla toteutuksessa voidaan reagoida hyvin nopeasti (1-2 viikon välein) uusiin sekä muuttuneisiin ideoihin ja hyödyntää toteutuksessa opittuja asioita parempiin keksintöihin. Ottamalla mukaan myynti ja markkinointi päästään lisäksi testaamaan idean kaupallistamista yhtä aikaa toteutuksen kanssa.

Liittämällä innovaatioprosessi osaksi yhtiön normaalia toimintaa voidaan ideaa, toteutusta ja kaupallistamista arvioida ja kehittää rinnakkain nopeissa 1-2 viikon jaksoissa.

Hävitä erillinen innovaatioprosessi liittämällä se (ketterään) kehitysprosessiin, jonka luonnollisena piirteenä on säännöllinen innovoiminen, mahdollisuuksien arvioiminen ja oppiminen.

* Tutkimustulokset: The Conference Board of Canada

Kategoria(t): Johtaminen, Tuotekehitys | Jätä kommentti »

Vanhemmat artikkelit