Vältä Agilen kantapää - huomioi nämä seikat ketterän projektin ostamisessa

Ketterät projektimallit (muun muassa Scrum ja Kanban) ovat olleet järjestelmäkehityksessäkin arkea jo vuosikausia. Aiheesta on kirjoitettu valtavia määriä artikkeleja ja kirjoja. Kaikki, jotka ovat millään tavalla tekemisissä IT-alan kanssa, tietävät mitä Agile on. Vai tietävätkö? Tuo kysymys herää aika usein ketterässä projektiarjessa. Tuo kysymys herää vielä useammin tarjouksia kirjoittaessa.

Tuon kysymyksen takia kirjoittelen myös nyt tätä artikkelia - jotta ostajan olisi helpompi ostaa ja toimittajan toimittaa.

Digitaalisten palveluiden toimittajan ominaisuudessa on hieman jännittävää nostaa keskusteluun toisen osapuolen valmiuksia, mitä tahansa valmiuksia. Tarkoitukseni ei ole esittää väitettä, että toimittaja olisi oikeassa, vaan tuoda päivänvaloon havaintoja jokapäiväisestä arjesta. Havaintoja, jotka voivat aidosti edistää toimittajan ja asiakkaan etua ja kykyä saavuttaa haluttu päämäärä. Vaikka puhkikäytetty termi “win-win” onkin markkinointibingon yksi ruksi, se on kuitenkin myös ihan mahdollinen skenaario. On kaikkien etu, jos projektin ostamisesta lähtien yhteistyö lähtee rakentumaan suuntaan, jossa molemmat kokevat voittavansa. Tämä on sitä todennäköisempää, mitä samansuuntaisempi hahmotus asiakkaalla ja toimittajalla on projektimallista kokonaisuudessaan.

Tässä artikkelissa käydään lävitse:

• Agile vs. vesiputousmalli
• Agilen vaaranpaikat tuoteomistajan näkökulmasta
• Projektin onnistumisen määritelmä & MVP-periaate
• Vuorovaikutuksen, yhteistyön ja kumppanuuden merkitys Agilessa

Agile vs. vesiputousmalli vai jotain näiden väliltä?

Aina ketterät projektit eivät mene niin ketterästi. Ongelmien siemenet voivat tippua ostohousujen taskuista (vahingossa) jo hankintavaiheessa. Ainakin yksi helposti ymmärrettävä syy ilmiölle on se, että kattavaa ja laadukasta tietoa Agilen ostamisesta on tarjolla hyvin vähän. Agilesta aiheena löytyy kyllä paljonkin tietoa, mutta Agilen ostamisesta kertovaa kirjallisuutta ja julkaisuja on tarjolla yllättävän vähän.

Perinteisessä projektinhallinnan (kuten vaikka vesiputousmalli) kolmiossa muuttujina on Projektin laajuus (Scope), budjetti (cost) ja aikataulu (Schedule) ja kolmion keskellä laatu. Vesiputousmallissa projektin laajuus on kiinnitetty projektin alkaessa. Käytännössä tosin usein kaikki kolmion muuttujat ovat olleet kiinnitettynä, mutta laajuus on ainakin se josta ei jousteta. Agilessa ajatellaan usein lähtökohtaisesti niin, että kolmio käännetään ylösalaisin ja projektin laajuus on se mikä joustaa. Tämän ymmärtäminen on välttämätöntä.

Perinteisessä projektimallissa on aina ennaltamäärätty tavoite, johon pääsemiseksi sekä aika- että budjettiresurssit joustavat.

Agileprojekteissa taas kiveen hakataan aika- ja budjettiresurssit ja tavoite voi muokkautua tarvittaessa.

Otsikkotasolla asian ymmärtäminen ei vielä valitettavasti riitä. Kun puhutaan käytännön projektityöstä ketterässä toimitusmallissa, projektitiimiltä odotetaan ketteryyttä, joustavuutta ja mukautuvuutta ja samaan aikaan usein tiimille annetaan odotus, jossa projektin laajuus on kiinnitetty. Tällöin seuraus on se, että tosiasiassa projektitiimillä ei ole todellista joustavuutta ja liikkumavara jää erittäin pieneksi. Vaikka laajuus olisikin se mistä voidaan joustaa, niin liikkumavara voi jäädä aivan liian pieneksi, jotta tekeminen säilyisi aidosti ketteränä.

Itse olen aidosti Agilen “Agile kolmion” kannattaja, jossa kolmion kärjet ovat täysin erilaiset kuin perinteisessä mallissa. Asiaa lähestytään näkökulmalla, jossa kolmion kärjet ovatkin arvo, laatu ja yhdessä kärjessä perinteisen kolmion muuttujat (laajuus, budjetti ja aikataulu). Tällöin aletaan suunnata katsetta oikeaan suuntaan. Huomio kiinnittyy siihen, että projektilla pyritään tuottamaan maksimaalinen arvo liiketoiminnalle. Arvon tuottamisesta lopulta on kuitenkin aina kyse projektitoteutuksessa. Tässä lähestymistavassa myös laatu asetetaan paikalle, jossa siitä joudutaan tekemään tietoinen päätös. Usein laadusta puhuminen jätetään kokonaan pois, koska sitähän ei tarvitse käsitellä. Sehän määräytyy muiden tekijöiden tuloksena. Samoin perinteiset muuttujat asettuvat paikoilleen yhdeksi kokonaisuudeksi, jossa niitä voidaan tarkastella yhdessä.

Ketteryys syntyy joustosta ja näitä joustavia muuttujia ovat laatu, budjetti, laajuus ja aikataulu. Aitoa ketteryyttä projektissa ei synny mikäli ketterän mallin muuttujissa (laatu, budjetti ja laajuus) ei ole joustoa. Toisaalta jos budjetti ja projektin laajuus ovat kiinnitettyjä, silloin joustaa laatu ja/tai aikataulu.. Ja vertauskuvan kautta: Kuka haluaisi ostaa auton, jossa hinta ja ominaisuuksien määrä olisi kiinnitetty, ja jo lähtökohtaisesti tiedettäisiin, että laatu on se mistä joustetaan. Kun auto on valmis, ominaisuudet löytyvät kyllä, mutta auto hajoilee jatkuvasti. Tai että laadukkaampana auto on saatavilla, mutta vasta muutaman vuoden kuluttua...IT-maailmassa näitä autoja valitettavasti ostetaan yhä jossain määrin.

Tarjouspyynnöissä välillä törmää ostajan tahtotilaan “katsoa kakkua ja syödä kakku”. Projektille on annettu kiinteä hinta ja kiinteä laajuus, joten joustaviksi elementeiksi jäävät laatu ja aikataulu. Ei loppuen lopuksi kovinkaan ketterää – enemmänkin vesiputousmallin mukaista. Projektin edistäminen sprinteissä tai palasteltuna ei tee siitä vielä ketterää projektia.

Todellinen valmius ketterään tekemiseen ulottuu projektitiimiä laajemmalle

Ketterän projektin onnistumisessa tärkein henkilö on tuoteomistaja asiakkaan päässä. Wunderin toimitusmalli pitää sisällään tuoteomistajan perehdytyksen. Ilman perehdytystä projekteja on lähes mahdotonta, tai vähintäänkin järjetöntä tehdä. Tuoteomistajat saavat tarvitsemansa määrän tukea ja jopa kokemattomampikin tuoteomistaja pystyy hahmottamaan nopeasti osuutensa projektissa. Missä sitten vaanii Agilen kantapää? Ongelmia voi koitua esim. seuraavista:

• Tuoteomistajan työaikaa ei haluta kiinnittää tarpeeksi projektille
• Organisaatiossa ei ole osoitettu tuoteomistajalle mandaattia tehdä päätöksiä nopeatahtisessa projektiarjessa, eikä organisaatio tai sen osa ole tarpeeksi nopea päättämään asioista.
• Päätöksenteko on myös sidoksissa sopimuksiin, jotka on muodostettu vääränlaisen ostamisen tuloksena
• Aikaa käytetään sopimusten tulkintaan ja kiinteän toimituksen takuiden vatvomiseen, sen sijaan että keskitettäisiin kaikki resurssit parhaan mahdollisen lopputuloksen aikaansaamiseen ja liiketoiminnallisen arvon tuottamiseen projektissa.

Onnistumisen määrittäminen ja MVP-periaate

Koska moni haluaa Agilen hyödyt, niin miten yllämainituilta ongelmilta voitaisiin välttyä? Kysymystä on hyvä lähteä purkamaan onnistumisen määrittämisen kautta. Kun ryhdytään arvioimaan miten projekti onnistui, tulisi luonnollisesti huomioida ketterän tekemisen peruspiirteet. Ei ole realismia, että sanotaan kaikkien ominaisuuksien olevan yhtä tärkeitä ja että ne kaikki halutaan täysimääräisinä ja täydellä laadulla. Ai miksei ole järkevää? Puhtaasti siksi, että ketterä toimitusmalli perustuu priorisointiin ja näin ollen projektissa toiset asiat ovat tärkeämpiä kuin toiset. Projektin edetessä voi myös tulla ymmärrys jostain merkittävästä seikasta, joka vaikuttaa priorisointiin ja juuri priorisoinnilla saavutetaan ketteryyttä.

MVP-periaatteesta (Minimum viable product) puhutaan myös usein ketterän kehityksen yhteydessä. Yksittäistä ominaisuutta tai vaatimusta käsitellään MVP-viitekehyksessä niin, että tehdään rajaus yksittäisen ominaisuuden sisällä siitä mitä se minimissään täytyy sisältää. MVP-periaate tuo, ainakin teoriassa, mahdollisuuden saada kaikki ominaisuudet, jotka projektissa halutaan, mutta minimitasoisena. Jos olet harkitsemassa ketterää projektimallia oman organisaatiosi kohdalla, pelkästään ketterän mallin priorisoinnin ja MVP:n merkityksen ymmärtäminen antaa jo huomattavasti paremmat edellytykset tehdä hankinnasta ja projektista onnistunut. Näiden lisäksi on toki muutakin oleellista.

Panosta vuorovaikutukseen, ole yhteistyöhaluinen - ja oikean kumppanin kanssa

Ketterän toimitusmallin julistuksen (Agile manifestoAvautuu uuteen välilehteen) ensimmäinen kohta korostaa vuorovaikutuksen merkitystä. Tämä pitää paikkansa myös ketterässä projektiarjessa. Projektitiimin toimiva vuorovaikutus on kaiken perusta. Toimiva vuorovaikutus perustuu luottamukselle, kuten kaikki tietävät. Kaikissa menestyksekkäissä ketterissä projekteissa toteutuu aina se, että asiakkaan ja toimittajan välille syntyy luottamussuhde. Luottamuksen tulisi ulottua myös projektitiimiä laajemmalle molemmissa organisaatioissa. Mikäli tätä asiaa ei ole tunnistettu asiakkaan organisaatiossa jo lähtökohtaisesti, projektit ovat yleensä ihan liian lyhyitä asian muuttamiseksi. Organisaation asenteen muutoksessa ketteryyttä ei yleensä ole ja luottamus syntyy, jos on syntyäkseen, paljon pidemmän yhteistyön tuloksena.

Ketteryys rakastaa toimivaa yhteistyötä! Optimaalisessa tilanteessa asiakkaan liiketoimintaymmärrys yhdistyy tuottajan digiosaamiseen ja syntyy vahva konsensus siitä, että miten tuotettavilla ratkaisuilla päästään liiketoiminnallisiin tavoitteisiin. Moniosaajatiimissä saumattomasti toimiminen luo parhaat edellytykset onnistumiselle.

Toimiva yhteistyö merkitsee kumppanuutta - eikä välttämättä ajallisesti vaan ajatuksellisesti mitattuna. Toimivan yhteistyön tunnistaa mm. siitä, että projektitiimissä toimittajan ja tilaajan roolien rajat hämärtyvät ja tiimistä tulee aidosti yksikkö. Projektitiimi ponnistelee yhteisen päämäärän puolesta yhdessä työskennellen sekä toinen toistaan tukien ja kunnioittaen. Vaikka kumppanuus kestäisi vain sen yhden projektin ajan, se on kuitenkin kumppanuutta. Usein nykyään ymmärretään se, että yhteistyö jatkuu projektitoimituksen jälkeenkin, koska palveluja tulee kehittää jatkuvasti ja näin ollen kumppanuuden merkitys korostuu entisestään. Toimittajan vaihtaminen on aina mahdollista, mutta se ei ole koskaan kokonaisvaltaisesti kannattavaa mikäli verrataan siihen, että oltaisiin lähtökohtaisesti panostettu sopivan kumppanin löytämiseen ja onnistuttu siinä.

Valmiudet ketterään projektiin ovat todennäköisesti olemassa jos organisaatiossa tunnistetaan nämä:

• Ymmärrys ketterän toimitusmallin perusperiaatteista ja sitoutuminen niihin (joustavat muuttujat: budjetti, projektin laajuus, laatu, aikataulu)
• Projektille tulee olla valmius osoittaa tuoteomistaja, jolla on:
  • Oman liiketoiminnan ymmärrys
  • Riittävä resurssointi projektille, koska ketterä toimitusmalli vaatii tuoteomistajalta paljon huomiota
  • Organisaation luottamus ja mandaatti tehdä päätöksiä projektiarjessa
• Ymmärrys luotettavan toimittajakumppanin merkityksestä yli annettujen vaatimusten

Innovoidaan, ratkaistaan ja onnistutaan yhdessä!

Keskustelemme mielellämme juuri teidän tarpeisiinne parhaiten sopivista projektimalleista ja tekemisen tyylistä, joten ota rohkeasti yhteyttä.