Agile-opas Pikaopas Leaniin ja ketteryyteen
Luontainen toimintamalli Olosuhteisiin ja muutoksiin mukautuminen on aikoinaan ollut meille elinehto. Nykyään ketteryys näkyy konkreettisimmin lapsissa, jotka keksivät leikkejä lähes tyhjästä, muuttavat niiden sääntöjä ja vaihtavat toiseen leikkiin lennosta. Työelämässä ketteryys kuitenkin joutuu valitettavan usein jäykkien prosessien jyräämäksi. Ketteryys edellyttääkin usein kulttuurin muutosta, mutta pieniä ketteriä kokeiluja on helppo tehdä. Ketterillä menetelmillä on melko pitkä historia: ensimmäiset menetelmät kehitettiin jo 1950-luvun lopulla, ja ne nousivat yleiseen tietoisuuteen 1980-90 -lukujen taitteessa. Tästä huolimatta monet asiakkaamme tutustuvat ketterään kehitykseen vasta meidän kauttamme. Koska me Druidilla uskomme vahvasti ketterään kehitykseen, haluamme levittää sen ilosanomaa muillekin. On yleinen harhaluulo, että ketterä kehitys olisi vain ohjelmistotalojen heiniä. Näin ei ole ketteriä menetelmiä voi hyödyntää lähestulkoon kaikilla toimialoilla! Toivottavasti tämä opas osoittautuu sinulle hyödylliseksi ajatusten tai jopa muutoksen herättäjäksi. Meiltä saat tarvittaessa koulutusta ja valmennusta ketteryyden saloihin. Tutustu koulutustarjontaamme tai ota yhteyttä, niin räätälöimme juuri sinun tiimillesi tai organisaatiollesi sopivan kokonaisuuden. Mikko Hämäläinen, Toimitusjohtaja, Druid Oy mikko.hamalainen@druid.fi 040 527 5945 2
Jatkuvan oppimisen ja kehittämisen kulttuurin omaksuminen edellyttää ajattelutavan muutosta. Tehdään asiat fiksusti ja joustavasti Lean-ajattelu on johtamisfilosofia, jossa pyritään toiminnan jatkuvaan kehittämiseen ja tuottamattoman toiminnan poistamiseen. Leanin juuret ovat Toyotan autotehtaan 1950-luvulla syntyneessä tuotantokonseptissa, josta se on levinnyt lähes kaikille toimialoille. Lean-ajattelun mukaan yrityksen tärkein tehtävä on tuottaa asiakkailleen arvoa. Asiakkaille tuotettava arvo siis määritellään ja maksimoidaan, ja vastaavasti arvoa tuottamattomat toiminnot eli hukka minimoidaan. Arvoa tuottavat työt järjestetään sujuviksi virtauksiksi, arvoketjuiksi. Näitä virtauksia parannetaan ja hukkaa poistetaan jatkuvasti. Leanilla siis tunnistetaan prosessin hukat ja keskitytään virtauksen maksimointiin. Tämä on jatkuvaa kehitystyötä, joka lähtee organisaation toiminnan ja prosessien analysoinnista, ongelmien tunnistamisesta ja korjaamisesta kestävällä tavalla juurisyihin pureutuen. Tämä ei onnistu ilman henkilöstön osallistamista ja heidän osaamisensa hyödyntämistä. On luotettava siihen, että ihmiset löytävät ratkaisut haluttuun lopputulokseen niin, että se samalla edistää yhteistä etua. Leanin avulla pyritään parantamaan asiakastyytyväisyyttä ja laatua, sekä pienentämään toimintakustannuksia ja lyhentämään tuotannon läpimenoaikoja. Kyse on keskittymisestä olennaiseen ja siitä, että asiat tehdään järkevästi enemmän vähemmällä. Kun prosessit tehostuvat, yritys parantaa tuottavuuttaan ja tulostaan. Lean on kuitenkin ennen kaikkea joustavuutta ja sopeutumista muuttuviin ja ennakoimattomiin olosuhteisiin, ei ainoastaan tehokkuuden lisäämistä. Reagoidaan muutoksiin nopeasti Leania pidetään ketterän kehityksen pohjana. Ketterät toimintatavat ohjelmistokehityksessä alkoivat yleistyä 1990-luvulla. Niillä haettiin ratkaisua ongelmaan, jossa kehitettävä tuote oli jo valmistuessaan vanhentunut, kun projektin suunnittelussa ja vaatimusmäärittelyssä ei ollut huomioitu ympäristön muutoksia ja ohjelmistokehityksen monimutkaisuutta. Tarvittiin menetelmiä, jotka hyväksyvät muutokset ja mahdollistavat nopean reagoimisen niihin. Vuonna 2001 julkaistu Agile Manifesto avaa niitä arvoja ja periaatteita, joihin ketterä ajattelu perustuu. Ketterässä ohjelmistokehityksessä arvostetaan: 1. yksilöitä ja kanssakäymistä enemmän kuin menetelmiä ja työkaluja 2. toimivaa ohjelmistoa enemmän kuin kattavaa dokumentaatiota 3. asiakasyhteistyötä enemmän kuin sopimusneuvotteluja 4. vastaamista muutokseen enemmän kuin pitäytymistä suunnitelmassa. Jälkimmäisilläkin asioilla on arvoa, mutta ensiksi mainittuja arvostetaan enemmän. Ketterässä kehityksessä painotetaan itseohjautuvuutta, vuorovaikutusta ja tiivistä, luottamukseen perustuvaa yhteistyötä asiakkaan kanssa. Yhteistyön toimivuus on elintärkeää, sillä asiakkaan tarpeet muuttuvat ja tarkentuvat projektin edetessä. Muutoksiin ja palautteeseen reagoidaan nopeasti ja joustavasti. 3
Miten ketterä kehitys eroaa perinteisestä vesiputousmallista? Vesiputous Vesiputousprojekteissa edetään suoraviivaisesti vaihe vaiheelta: tehdään vaatimusmäärittely ja projektisuunnitelma, joka toteutetaan, testataan ja toimitetaan. Kun suunnitelma on kerran tehty, sitä on vaikea enää muuttaa, ja palautetta toimintaympäristöstä saadaan hyvinkin pitkällä viiveellä. Pahimmillaan projektin määrittelyyn on käytetty vuosia, ja kun toteutusvaihe vihdoin alkaa, on aika jo ajanut tuotteen tai palvelun ohi. Ketterä Ketterissä projekteissa puolestaan suunnitellaan, kehitetään ja testataan jatkuvalla syklillä eli iteratiivisesti. Projektit toteutetaan lyhyinä, 1-4 viikon mittaisina iteraatioina, joista kukin itsessään on kuin pieni projekti. Jokaisen iteraation tavoitteena on tuottaa julkaisukelpoinen tuoteversio, joka tuottaa arvoa. Puhutaan inkrementaalisesta eli lisäävästä kehityksestä, eli tuotteeseen lisätään jotakin toiminnallisuutta jokaisessa iteraatiossa. Projektin prioriteetit tarkistetaan ja seuraavan iteraation sisältö suunnitellaan aina iteraation vaihtuessa. Tuotteen toimivuus on tärkeämpää kuin kattava dokumentointi, minkä vuoksi suunnitelma joustaa tilanteen ja saadun palautteen mukaan. Vesiputousmalli on alunperin luotu vaiheistetuille teollisuuden valmistusprosesseille ja sitä on jo 1970-luvulla kritisoitu sopimattomaksi malliksi monimutkaiseen ongelmanratkaisuun, kuten ohjelmistokehitykseen, jossa tarpeet muuttuvat lähes aina projektin kuluessa. Vesiputousmallilla on kuitenkin paikkansa, jos haluttu lopputulos on jo etukäteen tarkasti tiedossa ja muutokset projektisuunnitelmaan erittäin epätodennäköisiä. Tutkimusten mukaan ketterän kehityksen menetelmiä hyödyntävät projektit menestyvät keskimäärin huomattavasti vesiputousprojekteja paremmin. 4
Onnistumisprosentti Vesiputous Ketterä 56% 52% 39% 32% 12% 9% Successful Challenged Failed 5 Lähde: The Chaos Manifesto, The Standish Group 2015
Ketterän kehittämisen keskeisimmät hyödyt 1. Nopeus 2. Riskien minimointi Ketterissä projekteissa edetään pala kerrallaan niin, että asiakkaan liiketoiminnan kannalta tuotteen tärkeimmät osat saadaan ensimmäisinä käyttöön. Toistuva julkaiseminen mahdollistaa nopean käyttöönoton. Asiakas saa siis liiketoiminnallista hyötyä nopeammin. Lyhyet iteraatiot mahdollistavat myös virheiden nopean korjaamisen. Ja mitä aikaisemmassa vaiheessa virheet huomataan, sitä edullisempaa niiden korjaaminen on. Asiakas ei siis kohtaa ikäviä ylläatyksiä tuotteen valmistuttua. 3. Joustavuus 4. Läpinäkyvyys Lyhyiden iteraatioiden ansiosta muutoksiin reagoidaan ja sopeudutaan nopeasti. Suunnitelmaa voidaan muuttaa aina tarpeiden mukaan. Asiakkaalla on mahdollisuus aidosti vaikuttaa tuotteen kehitykseen. Asiakkaan kanssa tehdään tiivistä yhteistyötä, viestitään suoraan ja mielellään kasvokkain. Asiakas pysyy koko ajan kärryillä siitä, mitä on tekeillä ja milloin. 5. Fokus Oikein toteutettuina ketterät projektit pysyvät aikataulussaan eivätkä ylitä budjettiaan, sillä projektin laajuus (scope) elää ajan ja rahan ehdoilla priorisointia tehdään jatkuvasti. Vaikka asiakas ei välttämättä saa kaikkea haluamaansa, hän saa kaikki tärkeimmät tarvitsemansa asiat. Projektissa tulisi aina keskittyä niihin tehtäviin, jotka tuottavat kulloisellakin hetkellä korkeimman arvon asiakkaalle. 6
Scrum Kanban XP TTD RAD UP Ketterän kehityksen menetelmiä on useita, mutta periaatteet ovat yhteiset. Kanban ja Scrum ovat kaksi suosittua menetelmää, joita usein käytetään lomittain toisiaan täydentävinä toimintatapoina. Molemmat menetelmät ovat leanejä, ketteriä ja empiirisiä eli kokemusperäistä tietoa hyödyntäviä. Kanban ja Scrum ovat prosessityökaluja, joiden tarkoituksena on tehostaa työskentelyä tietyin toimintatapojen rajoituksin ja ohjeistuksin. Menetelmissä pyritään prosessin kehittämiseen ja optimointiin läpinäkyvyyden ja itseohjautuvien tiimien avulla. Yhteistä on myös työmäärän pilkkominen osiin ja tehtävien määrän rajoittaminen työn eri vaiheissa. Ohjelmistoa pyritään julkaisemaan mahdollisimman usein, ja julkaisuprosessia optimoidaan kokemusten perusteella Scrum-tiimin kehitysnopeutta tai Kanbanin läpimenoaikaa mittaamalla. Ohjelmistokehityksessä Scrumia käytetään usein projektinhallintaan vaikkapa uutta verkkopalvelua kehitettäessä. Kanban puolestaan soveltuu paremmin verkkopalvelun ylläpitotehtäviin, jotka voivat olla luonteeltaan reaktiivisempia ja vaikeammin ennakoitavia. Kanbanissa on enemmän liikkumavaraa, sillä toisin kuin Scrumissa, siinä ei ole määritelty rooleja, tapahtumia tai aikarajattuja iteraatioita. 7
Kanban Scrum Tekeminen Tiimi poimii tehtäviä kehitysjonosta tilanteen mukaan. Ei pohjaudu sprintteihin. Tehtävien määrä rajataan työvaiheittain. Tekeminen 1-4 viikon pituisissa sprinteissä. Tuotteen kehitysjonoa priorisoidaan ja tehtävien määrä rajataan sprinttikohtaisesti. Julkaiseminen Heti uuden version valmistuessa. Julkaiseminen Sprintin päätteeksi. Rakenne Ei standardoituja tapaamisia tai rituaaleja, mutta toiminnan jatkuva parantaminen keskeistä. Kanban-taulu on pysyvä. Rakenne Perustuu tarkkoihin toimintamalleihin ja rooleihin, jotka muodostavat systemaattisen rungon tekemiselle. Joka sprintillä on oma kehitysjononsa. Kanban-menetelmä syntyi lean-ajattelun myötä Toyotan autotehtaalla, jossa se kehitettiin tuotantojärjestelmän ohjausmenetelmäksi. 2000-luvulle tultaessa David J. Anderson kehitti Kanbanista tietotyöhön soveltuvan prosessinhallintatyökalun. Sana Kanban on japania ja tarkoittaa visuaalista korttia tai merkkiä. Kanban-menetelmä liittyy Just-In-Time -ajatteluun: se auttaa näkemään, mitä pitää tehdä, milloin, ja kuinka paljon. Kyse on arvoketjun optimoinnista ja visualisoinnista. Kanbanin avulla pystytään hallinnoimaan, ennakoimaan ja rytmittämään työn kulkua. Sitä voi hyödyntää minkä tahansa prosessin visualisointiin ja kehittämiseen. Kanbanissa työn kulku visualisoidaan taululle, jossa yksittäiset tehtävät siirtyvät kehitysvaiheesta toiseen. Tehtävien määrää kussakin vaiheessa rajoitetaan niin, ettei työtä hidastavia pullonkauloja pääse syntymään. Taulusta voi nähdä yhdellä silmäyksellä työn eri vaiheet ja nykytilanteen sekä näköpiirissä olevat esteet ja ongelmat. Työn kulkua ja tehtävien läpimenoaikoja mittaamalla prosessia voidaan optimoida. Scrum on ketterän kehityksen menetelmistä kenties tunnetuin. Scrum on monimutkaisten tuotteiden kehittämiseen tarkoitettu viitekehys, jonka sisällä voi käyttää erilaisia tekniikoita ja prosesseja. Scrumista sanotaan, että se on helppo ymmärtää mutta vaikea hallita hyvin. Onnistuakseen Scrum vaatii kurinalaisuutta, luottamusta ja avointa viestintää. Scrum pohjautuu empiiriseen prosessinhallintateoriaan, joka nojaa läpinäkyvyyteen, tarkasteluun ja sopeuttamiseen. Lisäksi Scrumissa käytetään iteratiivis-inkrementaalista (toistavaa ja lisäävää) lähestymistapaa riskien hallintaan ja ennustettavuuden optimointiin. Termi Scrum viittaa rugbyn rykelmäaloitukseen, josta pelaajat lähtevät liikkeelle nopeasti ja itseohjautuvasti. Scrumissa on valmiiksi määritellyt roolit, tapahtumat, tuotokset ja säännöt, joten kokemattomankin on helppo ymmärtää, kuinka viitekehys toimii. Ken Schwaber ja Jeff Sutherland kehittivät Scrumin 1990-luvun alussa ja julkaisivat sen vuonna 1995. Heidän kirjoittamansa Scrum Guide sisältää Scrumin pelisäännöt ja määritelmän. 8
Scrum: Ketteryys käytännössä Roolit Scrum-tiimi kehittää ja toimittaa tuoteversioita toistavasti ja lisäävästi niin että palautetta saadaan mahdollisimman usein. Tiimi on itseohjautuva ja monitaitoinen. Tiimi päättää itse, miten työ tehdään, ja heillä on kaikki tarvittava osaaminen työn tekemiseen. Ulkoista ohjausta ja riippuvuuksia ei siis näiltä osin ole. Tuoteomistaja (Product Owner) vastaa tuotteen arvon ja kehitystiimin työn arvon maksimoinnista. Hän on myös vastuussa tuotteen kehitysjonon sisällöstä, hallinnasta ja priorisoinnista niin, että tavoitteet saavutetaan parhaalla mahdollisella tavalla. Hän myös huomioi palautteen sidosryhmiltä. Rooli on vaativa, ja organisaation luottamus ja kunnioitus hänen päätöksiään kohtaan on projektin onnistumisen kannalta tärkeää. Tuoteomistaja on aina yksi henkilö, usein liiketoiminnan edustaja. Kehitystiimi muuttaa tuotteen kehitysjonon sisällön potentiaalisesti julkaisukelpoiseksi tuoteversioksi jokaisessa sprintissä. He päättävät itse, kuinka tuoteversio kehitetään, ja heillä on siihen kaikki tarvittava osaaminen. Kehitystiimissä ei ole alitiimejä, ja vastuu kehityksestä kuuluu koko tiimille, vaikka kehittäjillä voikin olla omia painopistealueitaan. Kehitystiimin koko on 3-9 henkilöä. Scrum Master on Scrum-tiimin palveleva johtaja, joka vastaa siitä, että kaikki ymmärtävät ja käyttävät Scrumia. Rooli on fasilitoiva ja valmentava: Scrum Master voi esimerkiksi ehdottaa tuoteomistajalle tekniikoita tuotteen kehitysjonon tehokkaaseen priorisointiin, auttaa tiimiä poistamaan esteitä työn etenemiseltä, valmentaa tiimiä itseohjautuvuuteen ja fasilitoida Scrumin tapahtumia. Scrum Master myös auttaa tiimin ulkopuolisia sidosryhmiä ymmärtämään Scrumia ja Scrum-tiimin kanssa toimimista. Tapahtumat Scrumin tapahtumat ovat valmiiksi määriteltyjä ja aikarajattuja. Tapahtumat luovat säännöllisyyttä, lisäävät läpinäkyvyyttä sekä mahdollistavat toiminnan jatkuvan tarkastelun ja sopeuttamisen. Sprintti on Scrumin ydin. Se on 1-4 viikon pituinen projekti, jonka aikana kehitetään potentiaalisesti julkaisukelpoinen tuoteversio, joka täyttää valmiin määritelmän. Sprintillä on aina tavoite, eikä sprintin aikana tehdä muutoksia, jotka vaikuttavat tavoitteeseen. Sprintin sisältöä voidaan kuitenkin tarkentaa työn edetessä. Vain tuoteomistaja voi keskeyttää sprintin siinä tapauksessa, että sprintin tavoite muuttuu tarpeettomaksi. Sprintti koostuu suunnittelupalaverista, päiväpalavereista, kehitystyöstä, sprintin katselmoinnista ja retrospektiivistä. Sprintin suunnittelussa määritellään sprintin tavoite: mitä tehdään ja millä tavalla. Aluksi kehitystiimi arvioi, mitkä asiat tuotteen kehitysjonosta se pystyy toteuttamaan sprintin aikana. Ennusteen pohjalta Scrum-tiimi määrittelee yhdessä seuraavan sprintin tavoitteen. Tämän jälkeen kehitystiimi suunnittelee, miten työ tehdään. Tuloksena on sprintin kehitysjono. Suunnitteluun käytetään enintään kahdeksan tuntia kuukauden mittaisella sprintille. 9
Päiväpalaveri (Daily) kestää enintään 15 minuuttia. Siinä kehitystiimi synkronoi työnsä ja suunnittelee seuraavan vuorokauden työt. Tiimiläiset kertovat vuorollaan, mitä tekivät eilen sprintin tavoitteen eteen, mitä aikovat tehdä tänään, ja onko tiedossa mitään esteitä, jotka vaikeuttavat tavoitteen saavuttamista. Sprintin katselmointi pidetään aina sprintin lopussa, ja siihen voi Scrum-tiimin lisäksi osallistua tuoteomistajan kutsumia sidosryhmiä. Palaverissa kehitystiimi esittelee valmiin tuoteversion (esimerkiksi demon muodossa) ja kertoo työn sujumisesta. Tuoteomistaja puolestaan kertoo tuotteen kehitysjonon tilanteen. Yhdessä pohditaan, mitä seuraavassa sprintissä kannattaisi tehdä, ottaen huomioon markkinatilanteen ja tuotteen mahdolliset käyttötavat. Katselmoinnin tuloksena on tarkistettu ja sopeutettu tuotteen kehitysjono. Kyse on epämuodollisesta palaverista, jolla luodaan pohja seuraavan sprintin suunnittelupalaverille. Katselmoinnin kesto on enintään neljä tuntia kuukauden sprintille. Sprintin retrospektiivi pidetään yleensä samassa yhteydessä katselmoinnin kanssa. Retrossa on kyse oppimisesta: Scrum-tiimi voi tarkastella, kuinka sprintti sujui yhteistyön, prosessin ja työkalujen näkökulmasta, ja suunnitella parannuksia työskentelytapoihinsa. Retron kesto on enintään kolme tuntia kuukauden sprintille. Tuotokset Tuotokset Scrumin tuotokset kuvaavat työmäärää tai lisäarvoa. Scrum Masterin tehtävänä on varmistaa tuotosten läpinäkyvyys työskentelemällä yhdessä Scrum-tiimin ja muun organisaation kanssa. Tuotteen kehitysjono on priorisoitu lista kaikista asioista, jotka tuotteessa saatetaan tarvita. Lista on elävä dokumentti, joka ei ole koskaan valmis. Se muuttuu ja kehittyy sitä mukaa, kun tuote ja sen käyttöympäristö, kuten markkinat tai teknologiat, kehittyvät. Tuotteen kehitysjono listaa kaikki ominaisuudet, toiminnot, vaatimukset ja parannukset, jotka tuleviin tuoteversioihin toteutetaan. Tuotteen kehitysjonoa työstetään toistuvasti. Tuoteomistaja ja kehitystiimi lisäävät listalle yksityiskohtia, kuten työmääräarvioita. Työstö tarkoittaa myös priorisointia ja kokonaisuuksien pilkkomista pienempiin osiin. Seuraavaan sprinttiin valitaan tuotteen kehitysjonon tärkeimmät kohdat, jotka on työstettävä niin pieniksi, että ne voidaan tehdä valmiiksi sprintin aikana. Työstöön käytetään enintään 10 % sprintin ajasta. Sprintin kehitysjono on näkyvä ja reaaliaikainen kuva työstä, jonka kehitystiimi aikoo toteuttaa sprintin aikana. Se sisältää sprinttiin valitut kohdat tuotteen kehitysjonosta sekä suunnitelman työn toteuttamisesta. Kehitystiimi omistaa sprintin kehitysjonon, muokkaa sitä työn edistyessä ja päivittää jäljellä olevaa työmäärää. Tuoteversio kehitetään sprintin aikana. Sprintin lopussa tuoteversion on oltava valmis, eli sen on täytettävä valmiin määritelmä ja oltava potentiaalisesti julkaisukelpoinen, vaikkei tuoteomistaja päättäisikään sitä vielä julkaista. Scrum-tiimillä on siis oltava yhteinen ymmärrys siitä, mitä valmis tarkoittaa. Näin kehitystiimi pystyy arvioimaan sprintin työmäärän oikein. 10
Miten tästä eteenpäin? Jos ketteryys kiinnostaa ja uskot oman organisaatiosi tai tiimisi hyötyvän siitä, kannattaa seuraavaksi pohtia, mikä menetelmä olisi teille tarkoituksenmukaisin ja parhaiten toimiva. Sitten vain kouluttautumaan! Vaikka ketterien menetelmien perusajatukset ovat melko yksinkertaisia, niiden vieminen ja soveltaminen käytäntöön nostaa todennäköisesti esiin paljon kysymyksiä. Uudenlaista ajattelua ei yleensä opi aivan sormia napsauttamalla. Kouluttaja tai valmentaja auttaa tiimejä ja organisaatioita ketterän prosessin käynnistämisessä. Sertifioinnit Scrumin tiimoilta on myös mahdollista suorittaa erilaisia sertifiointeja, kuten Scrum Master tai Product Owner -sertifioinnit. Sertifikaatteja myöntävät Scrum.org sekä Scrum Alliance, ja vaatimuksena on online-testin läpäiseminen. Scrum Alliance edellyttää lisäksi kaksipäiväiseen koulutukseen osallistumista. Druid tarjoaa sekä sertifiointiin johtavia Scrum-koulutuksia että yleistä perehdytystä leaniin ja ketterään toimintaan. Tuemme myös ketterien menetelmien omaksumista tarjoamalla tiimeille ja organisaatioille räätälöityjä konsultointipalveluita ja valmennuksia. Lisää tietoa koulutuksista: Kristo-Mikko Daniel, Agile Coach kristo-mikko.daniel@druid.fi 040 5888 877 11
Meillä tehdään vain timanttia Druid on suomalainen verkkopalvelutoimittaja. Rakennamme käyttäjäystävällisiä ja asiakkaan digitaalista liiketoimintaa tukevia verkkopalveluita ketterästi ja räätälöidysti. Olemme avoimen lähdekoodin Drupal-sisällönhallintajärjestelmän ja ketterän ohjelmistokehityksen huippuosaajia Suomessa. Uskomme kumppanuuksiin ja haastamme asiakkaitamme tekemään parempaa liiketoimintaa verkossa. Palvelumme kattavat verkkopalvelun koko elinkaaren tarvekartoituksesta ja konseptin suunnittelusta aina ylläpitoon ja jatkokehitykseen. Tarjoamme myös ketterän kehityksen koulutuksia ja konsultointeja. Mikko Hämäläinen Toimitusjohtaja, Druid Oy mikko.hamalainen@druid.fi 040 527 5945