Ketterä kehitys on ollut yksi kuluneen vuoden hype-termejä. Jopa julkishallinnossa ollaan oltu innostuneita ketterästä kehittämisestä. IT-integraattorit ovat myös sankoin joukoin liittyneet tähän ylistyshuutoon. Moni ketteryyteen ”hurahtanut” suhtautuu tähän ohjelmistokehityksen malliin myös korostuneen innostuneesti, jopa uskonnollisesti. Ja miksipä ei – onhan ketteryys yksi isoimpia paradigmamuutoksia mitä IT-alalla on vähään aikaan koettu.
Mutta muuttaako se aivan kaiken tekemisen tavan? Ja pitääkö asiakkaidenkin muuttaa toimintatapansa? Vastaan tässä intranet-projektien näkökulmasta tähän kysymykseen.
Väitän nimittäin, että esimerkiksi intranet-projekteihin ketterä kehitys ei tällä hetkellä liity mitenkään luontevasti. Ketterät menetelmät ovat ensisijaisesti räätälöityjen sovelluksien kehitysmenetelmiä ja niiden soveltaminen intranet-projekteissa voi olla jopa ongelmallista.
Isoimpana syynä tähän pidän sitä, että hyvä intranet-projekti on paljon muutakin kuin ohjelmistokehitystä. Väitän jopa, että onnistuneimmat intranet-projektit ovat vain pieneltä osin ohjelmistokehitysprojekteja – onnistuneimmat projektit ovat ennenkaikkea toimintatapamuutosprojekteja joissa ihmisten koulutus ja sisältöjen organisointi saavat isoimman huomion. Eikä näihin osa-alueisiin tarvita ketterän kehityksen tuomaa intensiivistä ohjelmistokehityksen mallia automaattisine testauskäytänteineen ja jatkuvine tuotantoonsiirtoineen.
Toisena merkittävänä syynä ketteryyden ja intranet-projektien huonoon yhteensopivuuteen pidän intranet-projektien tuotevetoisuutta. Riippumatta siitä otetaanko käyttöön SharePointtia vai vaikkapa Confluencea, niin hyvä intranet-projekti tapahtuu tuotetta kunnioittaen ja sen ominaisuuksia maksimaalisesti hyödyntäen. Tässä taas on kyse paljon enemmän vaikkapa ”ketterästä konsultoinnista” ja ”jatkuvasta pilotoinnista” kuin ketterästä kehittämisestä.
Kolmantena ketteryyden soveltamista rajoittavana asiana pidän intranet-palveluiden yleensä kovin maltillisia vuosittaisia kehitysbudjetteja. Vain maailman suurimmilla organisaatioilla on olemassa ”intranet-tiimejä”, jotka kehittävät palvelua jatkuvasti eteenpäin. Suurin osa intraneteista porskuttaa käyttöönoton jälkeen varsin pienillä kehitysbudjeteilla. Sisältöjä kyllä kehitetään ja uusia ominaisuuksia otetaan käyttöön jos päivitykset niitä tuovat, mutta aivan uutta ohjelmistokehitystä tehdään hyvin vähän vuosittain ”normaalille intranetille”.
Tosin tarkoitukseni ei tässä ole väittää, että ketterät menetelmät olisivat jotenkin epäyhteensopivia intranet-projektien kanssa. Uskon, että moni hyvä intranet voi syntyä aidon ketterän kehityksen kautta – ja olen pari tällaista isoa ja laadukasta projektia todistanutkin. En vain usko, että ketteryys auttaa ratkaisemaan niitä isoimpia ongelmia joita intranet-projekteissa on – enkä usko, että investoimalla ketteriin menetelmiin voidaan saavuttaa merkittävästi parempaa teknistä laatua intranetteihin – tai ainakaan sellaista laatua jolla olisi huomattavaa merkitystä käyttäjien näkökulmasta.
Nyrkkisääntönä sanoisinkin, että ketteriä menetelmiä kannattaa intranet-hankkeissa harkita jos toteutusprojektin ennakkoarviot tuntuvat menevän reilusti yli 200 henkilötyöpäivän. Tällöin alkaa todennäköisesti olla kyse jo varsin isosta ohjelmistokehitysprojektista jonka hallittavuutta voivat ketterät menetelmät parantaa. Tosin tuolloinkin ensisijaisesti suosittelisin projektin pilkkomista pienempiin osiin, ja näin mahdollistaen paremman keskittymisen sisältöprojektiin ja toimintatapamuutoksiin.
Tilaa blogin Parhaat palat -kooste, uutiskirje, joka ilmestyy noin neljä kertaa vuodessa.
Intranet-ostajan opas 
2.12.2013 at 16:13
Hei,
Hyvä kirjoitus, jälleen kerran. Olen samaa mieltä siitä, että useimmat suomalaiset intraprojektit eivät ole sen kokoisia, että niiden vaatimia toiminnallisuuksia tarvitsisi kehittää ketterällä ohjelmistokehitystiimillä esimerkiksi Scrumiin pohjautuen.
Valitettavasti vaihtoehtoina vaan usein tunnutaan nähtävän ainoastaan perinteinen vesiputousmalli ja täysin agiili ”avoin shekki”. Kuitenkin oman kokemukseni mukaan menettelytavat, jossa esimerkiksi tuotteen valmisominaisuudet tuodaan mahdollisimman pian todellisten käyttäjien käyttöön jo projektin alkuvaiheessa ovat varsin menestyksekkäitä. Se, ovatko nämä ”ketteriä”, ”iteratiivisia”, ”inkrementaalisia” vai ”agiilia konsultointia” on sitten toisen keskustelun aihe.
TykkääTykkää
2.12.2013 at 16:38
Moi,
oman kokemukseni mukaan ketterää filosofiaa voidaan hyvin soveltaa intran (jatko)kehittämiseen. Vuosi voidaan jakaa esim. neljään sprinttiin, joista jokainen sisältää jotain kehitystä intranetiin: sisällöllistä, teknistä, toimintatapamuutosta (kampanjointia, kouluttamista) ja/tai muuta. Ei siis pelkästään teknistä! Kullekin vuodelle sovitaan tietty budjetti, jonka raameissa sisäistä kehitystä tehdään ja ulkopuolista kehitystä ostetaan.
Tästä on etua sekä intran tekijöille että intran käyttäjille.
Tekijöille siinä mielessä, että työkuorma jakautuu tai jaetaan fiksusti koko vuodelle (eikä polteta itseään loppuun valtavassa uudistusurakassa). Kehittämiskohteita laitetaan ”jonoon” ja niitä priorisoidaan intravastaavien ryhmässä ja kiinnitetään sprintteihin/releaseihin. Kaikki kehitysryhmässä tietävät, mitä ollaan tekemässä, kehittämissuunta on koko ajan selvillä, eikä kenenkään yksittäisen henkilön agendat lähde keulimaan. Kokonaisuus pystyy siis paremmin hanskassa. Käyttäjien palaute ja toiveet käsitellään samassa ryhmässä ja aina pystytään kertomaan, mitä kehitystä on tulossa ja missä vaiheessa käyttäjän toive voitaisiin mahdollisesti toteuttaa.
Käyttäjille edellämainitun lisäksi tästä on se etu, että intraan tulee aina muutaman kerran vuodessa jotain uutta. Koko intra ei uudistu kertarysäyksellä (ja aiheuta ahdistusta: ”aina olen mennyt tästä, nyt se ei ole enää siinä”), vaan helposti pureskeltavin palasin. Kun intra kehittyy koko ajan, käyttäjälle myös tulee tunne, että organisaatio haluaa panostaa intraansa.
TykkääTykkää
2.12.2013 at 18:44
Henrik: Todellakin. Jyrkkä jako vesiputoustekemiseen ja ketteryyteen on todella yleinen, ja yhtä erikoinen. En voi itse sanoa nähneeni enää vuosiin todellisia vesiputouksia, koska käytännössä lähes kaikki selväjärkiset IT-talot ja näiden projektipäälliköt soveltavat käytäntöjä jotka ovat huomattavasti oppikirjamaista vesiputousta modernimpia malleja.
Tyypillisesti jäykätkin projektimallit sisältävät tänä päivänä jo viikkopalavereita, katselmointeja, roadmap-suunnittelusessioita ja tehtävälistojen läpikäyntejä. Ja moni toimittaja pilkkoo jo lähtökohtaisesti isot projektit pienempiin inkrementteihin/palasiin ja luovuttaa, testaa ja hyväksyttää osat asiakkaalla. Eli käytännössä tänä päivänä ”ei-ketterät” mallit ovat yleensä ihan jotain muuta kuin perinteistä vesiputousta ja mustaa boksia.
Jos asiakas haluaa läpinäkyvyyttä ja muutoskykyä, niin kyllä sitä saa kun osaa vaatia – riippumatta ollaanko tekemässä ”puhdasoppista ketterää projektia”. Jos taas ei osaa vaatia vaikutusmahdollisuuksia, niin sitten tietysti voi edelleen kokea olevansa pelkääjän paikalla, mutta tämä on kyllä harvinaista.
Etenkin intranet-puolella toimittajat tulevat aktiivisesti yleensä demoamaan jo alkuvaiheessa ja välituloksia katselmoidaan säännöllisesti. Sellaista ”me mennään nyt tonne kaappiin koodaamaan pariksi kuukaudeksi” ei enää tapahdu samalla tavalla kuin aiemmin. Ainakaan intranet-kentällä, sanoisin.
Sitäpaitsi intranet-kentällä saattaa joskus jopa olla niin, että toimittaja oikeasti tietää paremmin mitä asiakkaan kannattaisi haluta. Tällöin toimittajan ehdottamien mallien ja käytänteiden mukaan kannattaa edetä.
TykkääTykkää
2.12.2013 at 18:45
Hanna: Tuossa olisi ihan aihetta omaksi blogikirjoitukseksi, että miten ketteryyttä voi käyttää asiakkaan puolella toiminnan organisointiin. Etenkin jatkokehityksen suhteen. Itse olen vastaavaa kuullut vain Kelalta, joka sovelsi kela.fi-sisältösuunnitteluun ja sisältötuotantoonsa ketterän kehittämisen periaatteita jotta sai ison saitin sisällöt syntymään sovitussa aikataulussa ja riittävällä laadulla.
TykkääTykkää
2.12.2013 at 20:44
Hei Perttu,
kiitoksia mielenkiintoisesta kirjoituksesta – joka ainakin osoitti, että fiksuillakin ihmisillä on paljon kummallista käsitystä siitä, että mitä se ketterä kehitys on. Kirjoituksessa on hyviä ajatuksia, mutta ne olennaiset asiat jäävät kirjoituksessa — minun mielestäni –tarpeettoman väärinkäsityksen alle.
Kirjoitus antaa täysin turhaan kuvan, että ketterä kehittäminen olisi vain tekniseen kehitykseen ja räätälöityjen sovellusten rakentamiseen soveltuvaa. Yritän hieman purkaa auki selkeitä virheitä.
1) Ketterä kehitys on vain ohjelmistokehitystä
Totta kai, jos se vain rajataan sellaiseksi. Mutta kuka niin käskee tekemään? Eihän kukaan ammattilainen lokeroi esimerkiksi PRINCE2-projektimalliakaan vain tietynlaiseen työhön.
Eihän?
Ketterässä kehityksessä pitäisi olla kyse siitä, että tehdään oikeita asioita.
Oikeita asioita siis sen tavoitteen suhteen, mikä meillä on.
Tavoite voi muuttua, kirkastua tai pysyä samana koko matkan ajan – mutta me pysymme koko ajan kontrollissa ja tietoisena tilanteesta, sekä voimme tehdä valistuneempia päätöksiä lisääntynen tiedon ja ymmärryksen valossa.
Erilaiset ketterän kehittämisen toimintatavat ja mallit tähtäävät ihan samaan kuin perinteisemmätkin projektinhallintamenetelmät — onnistuneeseen lopputulokseen, riippumatta siitä mikä se konteksti oli.
Kirjoitat puhdasoppisesta ketterästä kehittämisestä automaattisine testauksineen ja tuotantoonvienteineen, mutta et kerro sen tarkemmin mihin käsityksesi perustuu. Oletan kuitenkin, että olet alan veteraanina hyvinkin tietoinen pinnalla olevista ketterän kehityksen erilaisista tyylisuuntauksista ja metodologioista ( esim. scrum, kanban, XP, DSDM tai Poppendieckien tulkinta leanista ) — ja pystyt kertomaan, että missä tämä puhdasoppinen ketterä kehitys tarkoittaa ” intensiivistä ohjelmistokehityksen mallia automaattisine testauskäytänteineen ja jatkuvine tuotantoonsiirtoineen”.
2) Tuotevetoisuus ei sovi yhteen ketterän kehityksen kanssa
Tämä on jatkumoa edelliselle ja esitteletkin kirjoituksessa ajatukset “ketterästä konsultoinnista” ja “jatkuvasta pilotoinnista”, vaikka koko ajan voisit puhua ketterästä kehittämisestä — mikäli et rajaisi sitä väärin perustein pelkäksi tavaksi suhtautua ohjelmistokehitykseen.
Erityisesti tuotevetoisuudessa ketterä kehitys pystyy auttamaan ja tuottamaan hyötyä, kun tehdään oikeita asioita ja ymmärretään miten esimerkiksi valittu tuote rajoittaa mahdollisuuksia saavuttaa jokin tavoite — ja toisaalta käyttää tuotteen kyvykkyyksiä myös paremmin hyödyksi tavoilla, mitä ei hankkeen aluksi osattu edes ajatella.
Mutta edelleen ydin on siinä, että tehdään oikeita asioita. Eihän ketterä tuotepohjainen kehitys tarkoita kenellekään sitä, että lähdetään täysin takki auki muokkaamaan tuotetta joksikin muuksi ihan vain sen takia että tehdään ketterää kehitystä?
3) Pienet budjetit eivät sovi …
Kun tehdään oikeita asioita, voidaan hyvässä tilanteessa esimerkiksi huomata – että ominaisuus mitä ennen projektia vaadittiin kovaan ääneen ennen projektia onkin muuttunut täysin tarpeettomaksi, kun tarve tyydytettiinkin uudessa ympäristössä aivan eri tavalla.
Ymmärrän erittäin hyvin kyllä pointin ja ajatukset, mitä yrität tuoda esiin — mutta kritisoin suunnattomasti tapaa rajata kysymys ja keskustelu tällä tavalla virheellisesti täysin turhaan.
Tietenkään sillä ei saa aikaiseksi yhtä raflaavia otsikoita kirjoitukseen, jos kirjoittaisi että “johtakaa intranet-projektia järkevästi”.
Mikäli haluat vaihtaa ajatuksia asiasta enemmänkin, tavoitat minut myös Twitteristä nimimerkillä huima tai Helsingissä vaikka lounaalla.
TykkääTykkää
3.12.2013 at 18:08
Kiitos kommentista. Minusta on mielenkiintoista, että ketterän kehityksen evankelistoilla on kova tarve puolustautua aina kun joku sanoo että ketteryys ei sovi johonkin täydellisesti. Tuntuu siltä, että ketteryys on ketterien menetelmien valmentajien ym. evankelistojen näkökulmasta hopealuoti/saippua joka sopii ihan kaikkeen – ja jos se ei sovi, niin vika on vain ollut siinä miten sitä on sovellettu – että oikeasti se kyllä sopii – tai toimii täydellisesti – jos vain olisi ymmärretty ja sovellettu oikein.
Harva teoriahan selviää törmäyksestä todellisuuden kanssa, ja minusta ketteryydessä on vähän tällainen prosessi juuri nyt käynnissä tässä maassa. Ymmärrän toki tuskan, koska ne hienot teoriat menevät juuri rikki siinä kun niitä ryhtyvät soveltamaan osaamattomat ihmiset.
Tämän blogin pointtina taas on nimenomaan keskustella intraneteista, ei yleisistä softakehityksen malleista. Ja iso pointtihan on se, että intranet-projekteissa asiakkailla pitäisi olla ihan muita asioita pohdittavana kuin prosessimenetelmät. Jos parhaaksi arvioitu toimittaja sattuu tarjoamaan jotain ketterää menetelmää, niin hieno juttu, antaa mennä vain. Mutta asiakkaan kannalta katsottaessa ketteriä menetelmiä ei kannata/tarvitse tunkea intranet-projekteihin liian innokkaasti – koska niiden tuoma lisäarvo on rajallista – ja vaadittu lisätyöllistävyys (etenkin asiakkaan näkökulmasta) taas melko merkittävä edelleenkin. Se on tässä se pointti.
TykkääTykkää
3.12.2013 at 21:24
Ennen kuin mennään nimittelyihin ja vihjauksiin, niin laitetaan ensiksi faktat kuntoon.
En ole ketterien menetelmien valmentaja tai evankelista. Olen harrastustoiminnassa Agile Finland-järjestön puheenjohtaja ja aktiivisesti mukana hankkimassa parempaa ymmärrystä siitä, miten saataisiin aikaan parempia projekteja / systeemityötä / johtamista — riippumatta siitä, minkä termin tai konseptin alle se tekeminen menee.
Olen opiskellut, käyttänyt ja suorittanut myös testejä perinteisemmistä projektinhallintamalleista — enkä millään tavalla vierasta erilaisten toimintatapojen käyttämistä erilaisissa tilanteissa, kunhan ajattelu ja päätöksenteko ko. tilanteen ja valittujen toimintatapojen suhteen on toimiva. Yritän olla älyllisesti rehellinen ja muodostaa ajatusrakennelmia, jotka ovat sisäisestikin koherentteja sekä olla aina avoin uudelle tiedolle, jotta voin korjata omia mentaalimallejani – jos olen väärässä.
Työskentelen konsulttina Affecto Finlandissa – ja vaikka kommentoinkin tässä yksityishenkilönä, nämä asiat ovat olennainen osa myös sitä työminääni. Kommentoin blogiin, koska se tuli työpaikan Salesforce-keskusteluissa vastaan ja minusta — kuten jo aikaisemmin argumentoin — artikkelisi peruspremissi on väärä.
Olet intranet-asioissa Suomessa kiistatta mielipidevaikuttaja ja tunnettu kouluttaja, joten pitäisin sitä harmillisena jos kirjoittamasi blogin ja pitämiesi puheiden / koulutusten kautta leviäisi turhaan perusteeton käsitys siitä että XYZ ei toimi.
Pidän vahingollisena sitä, että monimutkaisempaa todellisuutta yksinkertaistetaan väärin ja potentiaalisesti estetään sillä ihmisiä kehittymästä ja kohtaamasta niitä oikeita ongelmia ja haasteita joita maailmassa on.
Kirjoitat puhdasoppisesta ketterästä kehityksestä ja määrittelet sen ilmeisesti joksikin asiaksi, joka koskee vain teknistä ohjelmistokehitystä ja sisältää asioita, jotka eivät ole esimerkiksi minkään menetelmän osia ( poislukien mainituista XP, jossa test driven development on yksi päätoimintatapa ). Siinä missä XP on selkeästi ohjelmistokehitysmenetelmä ovat monet ketterät toimintatavat kuten scrum, kanban ja lean irrallaan siitä mitä ollaan tekemässä. Vai oletko eri mieltä?
Mitä siis tarkoittaa tämä puhdasoppinen ketterä kehitys jota intranet-projektit eivät tarvitse? Mistä sitä voi ostaa tai oppia? Onko heuristiikkaa, jonka mukaan tiedän – että teen puhdasoppista ketterää kehitystä?
Tämä on nyt jankkaamista, mutta olennainen osa kirjoituksesi sisältöä – ja se missä mennään metsään, vaikka kirjoituksessa ja kommenteissa onkin muuten hyviä ajatuksia.
Alleviivaan siis edelleen, että en ole missään nimessä sanomassa että ketterä kehittäminen on ainoa tapa tehdä projekteja – vaan kritisoin sitä, että artikkelissa esitetään suuri väitte asiasta X — määritellen asia X joksikin muuksi kuin mitä se markkinoilla sekä kirjallisuudessa on — sekä perustellaan väite irrallisilla argumenteilla. Vähän samalla tapaa kuin väittäisin kärjistetysti, että esimerkiksi high intensity training ei toimi kuntoilijoille koska lenkkikengät, makkara ja keskiolut.
Mikään projektinhallintamenetelmä tai toimintapa ei tee töitä puolestasi, eikä pelasta sinua omalta tai organisatoriselta tyhmyydeltä. Ei mikään ketterä menetelmä, ei PRINCE2 eikä adhoc työskentely. Edelleenkin jonkun pitää myös ajatella ja ymmärtää miksi sitä työtä ollaan tekemässä.
Erilaiset menetelmät antavat siis erilaisia lähestymisiä siihen, kuinka organisoidutaan tekemään työtä — kattaen siis kaikki mikä kuuluu suunnitteluun, viestintään, ohjaukseen, muutoksiin reagoimiseen ja sen itse asian tekemiseen. Riippuen kontekstista erilaiset määrät eri toimenpiteitä voi olla tarpeen.
Olennaista on ymmärtää se oma konteksti ja tehdä siinä niitä oikeita asioita.
Väännän loppuun vielä typistettynä:
1) Kirjoitat puhdasoppisesta ketterästä kehityksestä ilman että tunnut itsekään ymmärtävän mitä sillä tarkoitat. ( ts. ketterä kehitys on rajattu vain ohjelmistokehitykseen ja senkin sisällä vielä määritelty sisältäväksi epäolennaisia asioita )
2) Perustelet väittämän irrallisilla argumenteilla. Ja argumenttien irrallisuus johtunee kohdasta 1.
3) Eri menetelmien sopivuudesta tai sopimattomuudesta tietyntyyppiseen työhön olisi olemassa hyviäkin argumentteja, mutta niitä ei tässä artikkelissa ole
4) Artikkelin olennainen sisältö on, että intranet-projekteissa joita tehdään tuotevetoisesti pienillä budjeteilla ei ole järkevää lähestyä projektia ohjelmistokehitysprojektina.
5) Koska olet tunnettu mielipidevaikuttaja toimialallamme, pidän tällaisen keskustelun käymistä tärkeänä jotta se kollektiivinen osaaminen ja ymmärrys toimialallamme paranisi jatkuvasti
Alleviivaan tätä kohtaa viisi.
En reagoisi tällaiseen kirjoitukseen ja olisi näin anaalisen pedantti asian suhteen, jos asiasta kirjoitettaisiin jossain merkityksettömässä blogissa tai kirjoittajana olisi joku, jolla ei ole samanlaista kuulijakuntaa.
Paremman huomisen puolesta siis.
TykkääTykkää
4.12.2013 at 14:56
Kiitos kommentista. Arvostan tällaista keskustelua kovin, ja toivottavasti ei synny käsitystä että en jotenkin arvostaisi keskustelua.
Tuo ”puhdasoppinen” -sana pitäisi varmaan otsikosta poistaa, ja puhua ihan vain ketteristä menetelmistä – siten kuten ne itse satun ymmärtämään ja niiden käyttöä havainnoimaan alalla tällä hetkellä. Se muutos varmaan korjaisi ainakin osan kokemistasi virheargumenteista. (Blogiartikkelin otsikkoon en näin jälkikäteen koske, mutta todettakoon tämä tällaisena listaamiesi argumenttivirheiden tunnustamiseni.)
Kiteytät hyvin neljännessä kohdassa sen, että kirjoituksen todellinen pointti on se, että tuotevetoisissa intranet-projekteissa ei saavuteta suurta lisähyötyä asennoitumalla niihin ohjelmistokehitysprojekteina. Ja etenkin näin jos budjetti on vielä rajallinen.
Ehkä se todella kiinnostava kysymys olisikin, että ”Milloin pitää suhtautua ohjelmistoprojektiin ohjelmistokehitysprojektina?”. Nykyisinhän on muitakin vastaavia alueita kuin intranet-projektit joissa korostuvat erittäin paljon muut asiat. Lisäksi esim. pilvipalvelut ym. valmistuoteratkaisut mahdollistavat hyvinkin erilaiset mallit.
Minusta joku ”tuotevetoinen ketterä käyttöönotto -prosessi” olisi jotain sellaista mikä voisi toimia intranet-projekteissa varsin hyvin – mitä se sitten olisikaan käytännössä. En tällaista vastusta mitenkään – ja suorastaan toivoisin, että joku toimittaja tällaisen esittelisi. Itse asiassa viimeksi eilen yhden SharePoint-integraattorin kanssa siitä aiheesta keskusteltiin ja he lähtivät pohtimaan mitä se voisi olla.
Mutta. Miksi minä sitten tässä ”hyökkään” ketteriä menetelmiä vastaan tällä tavoin? Noh, ensinnäkin hyökkään sen takia että aiheesta saadaan keskustelua ja myös vähän erilaisia näkökulmia (vaikkakin kärjistettyjä). Törmään alalla itse nimittäin erittäin paljon siihen, että softa-ammattilaiset haluavat suhtautua kaikkiin projekteihin korostuneesti ohjelmistokehitysprojekteina, ja tällä hetkellä halutaan kaikesta tehdä ketteriä softakehitysprojekteja – riippumatta kohteesta – ja riippumatta asiakkaan kyvyistä ja tavoitteista.
Näin ostamiskonsultin näkökulmasta se ketteryys näyttäytyy siis tällä hetkellä turhan usein keppihevosena jolla it-talot ratsastavat sen sijaan että puhuisivat itse tekemisen kohteesta ja projektin fiksusta läpiviennistä (huomioiden myös asiakkaan näkökulma ja osallistuminen). Eli puhutaan ketteryydestä sen sijaan, että kerrottaisiin millainen on heidän mielestään hyvä intranet, miten valittua tuotetta käytetään intranet-projektissa fiksusti, millä tavalla projekti kannattaisi viedä läpi ja missä vaiheissa asiakkaalta odotetaan mitäkin.
Onneksi erilaistakin asennetta on olemassa. Yksi Euroopan merkittävimmistä CMS-integraattoreista oli tässä pari viikkoa sitten yhden ison kilpailutuksen finaalissa esittäytymässä Helsingissä ja heidän näkökulmansa oli aika virkistävän erilainen kun puhuttiin projektin läpiviennistä. Suora lainaus heiltä: ”We don’t do agile, we know what we are doing.”. (Ja tämä ei suinkaan tarkoittanut sitä, että heidän tapansa toimia olisi jotenkin jämähtänyt 90-luvulle vaan he ovat todella huippuammattilaisia hommassaan.)
Uskon kuitenkin että meidän molempien tavoite on saada tähän maahan parempia it-projekteja ja parempia tuloksia niistä projekteista. Olemme varmaan myös samaa mieltä siitä, että ketterät menetelmät ovat yksi kiistatta parhaista asioista joita alalle on tapahtunut viime aikoina.
Veikkaan, että siitä vain olemme eri mieltä miten ketterien menetelmien edistämistä kannattaisi tehdä tässä maassa. Itse katson asioita vahvasti asiakkaiden näkökulmasta ja sitten myös havainnoin ohjelmistofirmojen todellista osaamistasoa. Ja kummatkin ovat luvalla sanoen aika heikkoja suhteessa siihen mitä ketterät menetelmät vaativat (tai olettavat, tai mitä ne menetelmät ovat paperilla).
Paras menetelmähän on yleensä reaalielämässä se mitä oikeasti noudatetaan, ei se mikä on paperilla paras (kun reaalielämässä noudatetaan harvoin mitään menetelmää kunnolla).
TykkääTykkää
9.12.2013 at 23:16
Meinasin ensin kirjoittaa kommenttini tänne mutta asiaa oli sen verran paljon että päätin laatia ihan oman blogipostauksen aiheesta: http://digimarkkinoilla.blogspot.fi/. Pointtini taitaa olla se, että priorisointia kannattaa tehdä ihan kaikissa IT-projekteissa, myös tuotevetoisissa intraprojektiessa, ja ketterät metodit tarjoavat siihen hyvän mindsetin.
TykkääTykkää