Ketteristä menetelmistä apua kehityshankkeiden ongelmakohtiin

ICT-alan kehityshankkeiden toteutuksessa on historiallisesti huono kaiku. Oman kokemukseni pohjalta tilanne on tulosten osalta kehittynyt selkeästi parempaan suuntaan toimintaympäristön samalla vaikeutuessa.

Ennen sukeltamista kokemusperäiselle matkalle hanketyön evoluutioon teen alkuun kaksi määritelmää. Itselleni projektissa on aina kyse sovittujen tavoitteiden saavuttamisesta, jossa tyypillisesti tavoitteena on muutoksen kautta saavutettava liiketoiminnallinen hyöty. Käytännössä tämä tarkoittaa sitä, että kehitystyön tuloksena luotu kokonaisuus on otettu käyttöön.

Tässä tarkastelussa keskityn kehitysvaiheen ongelmallisten kohtien ratkaisuihin omien esimerkkien pohjalta. Huomasin, että on syytä erikseen palata aiheeseen projekti ja muutoksen läpivienti organisaatiossa ja tarkastella myös sitä menetelmien näkökulmasta.

Toinen määrittely on projektinhallinta, jonka Wikipedia määrittää, että  ”Projektinhallinta tarkoittaa resurssien (kuten työvoiman) organisointia ja hallintaa sellaisella tavalla, että projekti voidaan päättää suunnitellun sisältöisenä ja laatuisena, aikataulun sekä budjetin mukaisesti. Käytettäviin resursseihin luetaan esimerkiksi raha, työvoima, raaka-aineet, energia, tila ja palkat. Resurssien lisäksi huomioidaan esimerkiksi viestintä, laatu ja riskit.”

Sekalainen työkalupakki

Projektinhallinta oli pitkään yhtä kuin Project Management Instituten PMBOK pohjainen kehys, jossa on projektinhallinta prosessina, vaiheina ja metodeina. ICT-projektien ongelmat ovat moninaisia, mutta ongelmana on pidetty vesiputousmallin soveltumattomuutta. Sen  vaikutus on yleisesti ollut tämä karrikoitu kuva.

 

Kun kuvaa tarkastelee projektinhallinnan kuvausta vasten nousee esille kohdat ”suunnitellun sisältöisenä”, ”aikataulun mukaisesti”, ”viestintä”, ”riskit”. Nämä ovat olleet tyyppillisiä ongelmia, joista itselläkin on kokemusta ja näihin on aktiivisesti etsitty ratkaisuja. Projektipäällikölle ratkaisun löytäminen on merkittävää, koska hän pääosin kantaa vastuun muutoksen onnistumisesta.

PMBOK-pohjaisissa malleissa huomioidaan 9 osa-aluetta, jotka kattavat edellä mainitut ongelmalliset alueet. (Integration Management; Scope Management;  Time Management; Cost Management; Quality Management; Human Resource Management; Communications Management; Risk Management; Procurement Management)

ICT-puolella ratkaisuja on haettu agilesta ja lean-ajattelusta, jotka keskittyvät vain osaan projektinhallinnan kokonaisuudesta. Ketterät menetelmät eivät missään nimessä ole uusia ajatuksia, mutta esimerkiksi kehityspuolella scum on vallannut vahvasti alaa vasta 2003 lähtien, kun  Mary ja Tom Poppendieck julkaisivat kirjan 2003 Implementin Lean Software Development.

Menetelmien evoluutiota tarkasteltaessa välittyy mielikuva, että aina ei ole ollut ihan selvää, mikä on syy ja mikä seuraus ja toisaalta onko korjaukseen valittu laastari sopiva haavaan.

Kuvaus ketterien menetelmien kattavuudesta suhteessa toisiinsa. Nämä kukin sisältävät prosesseja, menetelmiä ja metodeja projektinhallintaan liittyen, mutta projektinhallinta on tietyllä tavalla omalla abstraktiotasolla ja toisaalta tuo toimintamalleja kehitystyön seurauksena tapahtuvien muutosten hallintaan.

Uutena kehitysvaiheena on luotu tietyllä tavalla synteesi kaikesta tästä ja esitelty Scaled Agile Network, joka pyrkii ratkomaan suuren yrityksen toiminnan problematiikkaa ja konkretisoimaan ns. ketterän organisaation mallia.

Oikea työkalu oikeaan työhön

Epäonnistumisen syynä tai laajemmin sen syynä ettei  saavuteta ns. high-performing-team-tilaa voi olla monta tekijää. Lähtökohtana on, että menetelmä on tapa jäsentää tekemistä ja selkeyttää miten ollaan tekemässä. Eri menetelmissä painotetaan eri metodeja, joiden avulla selkeytetään mitä ollaan tekemässä ja miksi.

Menetelmistä ja metodeista huolimatta tekijänä on aina ihminen, jonka merkitys ratkaisee, mutta yksilön merkitys yksittäisenä yksilönä vähenee, mitä korkeammalta toimintaa tarkastelee. Tällä on merkitystä projektin, järjestelmän tai organisaation kokoluokasta puhuttaessa.

Ketterä kehitystiimi

Oma oppimispolku ketterien menetelmien parissa lähtee 2000-luvun alusta. Ohjelmiston tuotekehityksessä kehitystiimit pohjasivat tekemistään user storyihin, XP:hen ja testiautomaatioon. Startuping R&D-prosessissa ei juuri otettu kantaa tuon tason tekemiseen eikä nuoressa yrityksessä ollut vertailupohjaa aiempiin käytäntöihin.

Toiminta oli kehittäjävetoista ja käytännöt vaihtelivat. Kehitystiimin tasolla mallit antoivat vastauksia kysymyksiin mitä, miksi ja miten, mutta kun on muistettava, että liiketoiminnan tarpeena on vastata asiakkaan tarpeeseen, jolloin eri sidosryhmien määrä kasvaa huomattavasti. Kehitystiimin ympärillä on tuotteenhallinta, liiketoiminnan kehittäminen, myynti, markkinointi.

Selkeänä hyöty oli se, että auki kirjoitettuna tarina oli selkeästi viestittävissä eri osapuolten välillä, mutta vastaus kysymykseen mitä tai miksi ei välttämättä ollut sama kaikille osapuolille. Tämä tarina päättyi valtavaan oppi- ja kokemusmäärään. Tuotteet ja markkina eivät kohdanneet eli mitä asiakas halusi ja miksi ei välittynyt samana viestinä ketjun läpi.

Ketterä ICT-palvelukehitys

Tästä matka jatkui kokoluokkaa 100x suurempaan organisaatioon. Tuotekehitys vaihtui ICT-ratkaisuihin. Prosessit olivat muodollisempia, oli ongelmia, ongelmiin haluttiin ratkaisuja. Ongelmat olivat tyypillisiä vesiputousmallin toiminnassa – projektin toimitusaikataulu venyi, kustannukset kasvoivat ja asiakas ei saanut sitä, mitä a) oli halunnut b) oli toimitushetkellä tarvittava toiminnallisuus.

Tilannetta korjattiin iteratiivisella timeboxed -mallilla, joka aika pitkälti noudatti scrum-menetelmää.  Saavutettuina etuina oli intensiteetin kasvun myötä tehokkaampi toiminta. Tämähän ei ollut poissuljettua vesiputousmallissakaan, mutta tekemisen rytmittäminen, toistuvat määräajat tuovat päivittäiseen tekemiseen ryhtiä.  Tarpeiden käsittelyn osalta product backlog, suunnittelutyöpajat ja sovitut featuretason vastuut teknisen ja liiketoimintaosaajien kanssa auttoivat vastaamaan aiempaa paremmin tarpeeseen niin toiminnallisuuden kuin ajallisen saatavuuden osalta.

Kustannusten osalta tilanne ilahdutti kaikkia, joilla tavoitteet ja tulospalkka oli sidottu projektin kustannusmittariin. Kustannukset olivat kontrollissa, kun projektin pyhässä kolminaisuudessa sisältö ja aikataulu joustivat.

Perinteisestä projektin lopussa tehdystä Lessons learnt -palautteesta päästiin eroon – miksi kerätä palautetta, kun projekti on ohi ja kirjattuna tieto hautautuu projektidokumentaation arkistoon. Tilalle tuli retrospektiivi, jolloin esille tulleisiin epäkohtiin puututtiin aktiivisesti.

Muutos toimintatavassa pienensi tai poisti kokonaan aiempia ongelmia. Linkitys tuotetasolta portfolionhallintaan ja strategiaan jäi kuitenkin löyhäksi – niissä toimittiin vanhojen rajapintojen kautta, joka sovitti iteratiivisen mallin ympäröivään maailmaan.  Rahaa jaettiin budjetista edelleenkin kaksi kertaa vuodessa ja tiekarttaa päivitettiin, kun budjettiin tarvittiin summa.

Ketterä strategisen muutoksen toteuttaminen

Pikku hiljaa kehitystiimien halusta ja tarpeestakin lähtenyt agile transformaatio alkoi levitä ympäröiviin rakenteisiin vuoden 2007 jälkeen. Muutoksessa luotiin käytäntöjä ja otettiin pala palalta käyttöön Scaled Agile Networkin kaltaisia malleja – tosin SAFesta ei tuolloin ollut kuullut kukaan.

Kehitystiimin toiminta oli kypsynyt scrum-mallin mukaiseksi. Suurimpana poikkeamana oli, ettei testiautomaatiolla pystytty kattamaan kaikkea kehitystyötä, jolloin toiminnallisuuksien lisääntyessä myös regressoitavaan testaukseen menevän työn määrä kasvoi. Avokonttorin seinän valtasi scrum-taulu, tuntien ja työmäärän raportoinnin järjestelmät olivat korvautuneet Jira tai Excel backlogeilla.

Rinnakkaiset tiimit toimivat käytännön tasolla  hyvin yhteen. Yhteiset viestintä- ja muutoksenhallintakäytännöt oli sovittuna ja käytössä. Agile Release Train (ART) tyyppinen ”create factory” tuotti toiminnallisuuksia asiakkaan kanssa päivitettävän backlogin pohjalta.

Monia hyviä ketterän kehityksen periaatteita ja metodeja  oli käytössä, joiden avulla pystyimme vastaamaan käyttöönottoprojekteista tuleviin asiakastarpeisiin oikeaan aikaan.  Selkeänä epäjatkumona oli feature-tason tiekartan, budjetin ja budjettiin kytketyn resursoinnin linkitys ketterään malliin.

Budjetointi oli muovautunut vuosien varrella vuositasosta kuuden kuukauden sykleihin ja sen jälkeen ns. jatkuvaan päivitystilaan, MUTTA tyypillisesti haasteena oli linjaorganisaation resursointi sekä prokurementin sopimushallinta.  Erilaisista tavoitteista johtuen linja haluasi ”myydä” resurssinsa varhaisessa vaiheessa, koska se oli heidän tavoitteensa. Samoin haluttiin pitää tekijät kiinnitettyinä projekteihin, koska tavoiteallokaatio oli x%. Vastaavasti prokurement halusi määrittää selkeitä tuotospohjaisia sopimuksia toimittajien kanssa, joka oli vastoin ketterän kehityksen käytäntöjä.

Näitä ”opittiin” kiertämään, mutta siitä aiheutui täysin turhaa ”jätettä” ja osin väärinkäytösten takia yleisten toiminnan mittareiden antamat tulokset eivät olleet luotettavia. Vastaavanlaisia murrostilassa olevasta ketterän kehityksen jalkauttamisesta johtuvia epäjatkumoita oli vielä paljon.

Ytimestä kohti ulkokehää

Kun tätä kehityspolkua tarkastelee SAFe-mallia vasten on evoluutio vienyt menetelmäkehitystä ytimiestä eli tiimitasosta kohti ulkokehää eli portfoliota. Kunkin osa-alueen toiminta on matkan varrella pyrkinyt itse omien rajojensa sisäpuolella muuntautumaan kohti joustavampaa asiakaslähtöisempää toimintatapaa.

Keskeisiä puutteita on ollut ja SAFe-mallin tuomia parannuksia on value stream -ajattelu, joka auttaa punaisen langan kirkastamisessa, jos malli kulkee läpi koko organisaation. Esimerkiksi portfolionhallinnassa oli ja on varmasti edelleenkin prosessien vaiheina ja tuotoksina Epic ja Enabler  – tosin eri nimillä.

Toinen merkittävä kehitysvaiheen haaste oli epäjatkuvuuskohdat, joista resursointi ja sopimustenhallinta ovat esimerkkejä. SAFe-malliin peilattuna portfolionhallinnan, value stream ja program-tason rajapinnat etsivät vielä muotoaan program- ja tiimitason linkittyessä jo tehokkaasti toisiinsa.

Oman kokemukseni perusteella ketterässä kehityksessä ollaan suurissa kehityshankkeissa ja laajoissa organisaatioissa menevässä hyvään suuntaan, jos parannuksena pidetään aiempien ongelmakohtien poistamista. Näköpiirissä on tietyllä tavalla perinteinen ”over engineering”, jolloin menetelmän ja prosessin hiominen ottaa vallan agile manifeston alkuperäisistä periaatteista.

Täytyy muistaa, että mikään yksittäinen menetelmä ei ratkaise mitä ollaan tekemässä ja miksi. Niin sanottu post-it-malli, jossa menetelmä on vain trendin mukainen päälle liimattu paikka ei varmasti tässäkään tapauksessa tuo niitä tavoiteltuja ja asiakkaan kannalta tärkeitä hyötyjä. Kyky soveltaa vaatii osaamista ja kypsyyttä – jonka takana aina ovat osaavat ihmiset.