Lu

ku

:

1

392 vuotta ketteriä kokemuksia

392 VUOTTA KETTERIÄ KOKEMUKSIA

2.5.2013, toinen painos, versio 2.0 beta 2

© 2013, tekijät, CC BY This work is licensed under the Creative Commons Attribution 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/.

Kirja verkossa: http://www.sytyke.org/julkaisut/kettera-kirja/

Lu

ku

: Esi

pu

he

3

ESIPUHE

Kun minut valittiin Sytykkeen puheenjohta-jaksi vuodelle 2013, aloin kypsytellä ajatuk-sia yhdistyksen toiminnan uudistamisesta ja jatkamisesta. Idea tähän kirjaan ja sen nope-aan kirjoitustapaan syntyi, kun halusin yh-distää hieman vanhaa ja hieman uutta.

Syystalvella 2012 lehtori Vesa Linja-aho to-teutti kaksi viikonlopun mittaista oppikir-jamaratonia, joissa hän keräsi joukon alan ammattilaisia yhteen kirjoittamaan lukion matematiikan oppikirjoja. Viikonloppu on lyhyempi kuin yleensä maailmalla käytetty 3–5 päivän mittainen kirjapyrähdys (engl. booksprint) ja oppikirjojen tekemisessä huomattiinkin, että varattu aika ei aivan riittänyt.

Sytyke julkaisi 1980- ja 90-luvuilla Sytyke-raportteja, joissa suomalaiset huippuammat-tilaiset kirjoittivat yhdessä kirjoja uusista, mullistavista tietojärjestelmätyön trendeis-tä, kuten oliolähestymistavasta. Näitä ra-portteja työryhmä kirjoitti yleensä 1–3 vuot-ta.

Näistä kahdesta erillisestä tapahtumasta syntyi ajatus yhden viikonlopun aikana kir-joitetusta ”Sytyke-raportista”, jossa tuodaan yhteen kotimaisten alan ammattilaisten näkemykset jostakin ajankohtaisesta aihees-

ta, joka ei vielä ole vakiintunut rutiiniksi. Aiheista ei sinänsä ole pulaa: cloud compu-ting, big data, service design, no-sql... Silti omaakin sydäntäni lähellä oleva ketterä työskentely nousi näistä päällimmäiseksi. Vaikka ketterä on yleistynyt, alalla on vali-tettavan paljon hypeä, ”agile-washingia” ja reseptin seuraamista. Osaltaan tätä käsitystä vahvisti Agile Finland ry:n järjestämä vuo-den 2012 Scan Agile konferenssi, jossa Dave Snowden kävi puhumassa. Snowdenin avainviesti oli, että jos seuraat ketterää me-netelmää X, et ole ketterä. Menetelmäkoh-taisista dogmeista olisi siis päästävä seuraa-valle tasolle. Olisi ymmärrettävä, miksi tie-tyllä tavalla kannattaa toimia ja missä tilan-teissa kannattaa kokeilla mitäkin tekniikoi-ta. Tähän toivon tämän kirjapyrähdyksen tuloksen vastaavan – suomalaisen työn te-kemisen kontekstista.

Kirjan versio 1.0 tehtiin yhdessä viikonlo-pussa, versio 1.1 sisälsi muutamia muotokor-jauksia sekä parin kirjoittajan täydennyksiä. Version 2.0 kirjoitti yhden lauantain aikana noin puolet alkuperäisistä kirjoittajista.

Tarmo Toikkanen

Lu

ku

: Esi

pu

he

4

KIRJAPYRÄHDYS

Kirjapyrähdys eli booksprint oli itselleni tuntematon käsite, kun Tarmo lähestyi Agile Finlandin hallitusta kirjanteko-ehdotuksellaan vuoden lopussa. Annoin ehdotuksen muhia alitajunnassa jonkin ai-kaa ja talven pimeydessä päätin heittäytyä mukaan haasteeseen fasilitoijan roolissa.

Ennen viikonloppua selkeää oli ainoastaan se, että olemme kirjoittamassa kirjaa kette-ryydestä. Tästä ei tarvinnut sen enempää keskustella, joten pystyimme aloittamaan viikonlopun miettimällä kenelle kirjoitam-me.

Kirjan tarkoituksesta – eli siitä miten kirja palvelisi perusteet tuntevia ammattilaisia ja alan opiskelijoita – oli enemmän mielipiteitä kuin paikalla oli ihmisiä. Päädyimme siihen tulokseen, että kirjoitamme ketteryydestä jakamalla omakohtaisia kokemuksia.

Kirjaa on ollut mukana kirjoittamassa suuri joukko kokeneita alan ammattilaisia, jotka eivät välttämättä aina ole kaikista asioista samaa mieltä. Yksittäisten lukujen välillä voi olla pieniä vivahde-eroja kirjoittajien erilais-ten kokemusten vuoksi. Kaikki kirjoittajat eivät välttämättä allekirjoita kaikkia kirjassa esitettyjä kannanottoja.

Kirjapyrähdysviikonloppu oli loistava ko-kemus ja lopputuloksesta todellakin kehtasi kertoa myös ystäville. Työtä jatkettiin vii-konlopun jälkeen ja palasimme vielä reilu kuukausi myöhemmin yhteen selkeyttämään kirjan rakennetta, yhdenmukaistamaan ja parantelemaan kokonaisuutta. Versiota 2.0 kehtaa jo kutsua kirjaksi.

Jussi Hölttä

SISÄLTÖ

Esipuhe .................................................................................................................................................................. 3 Johdanto ................................................................................................................................................................ 6 Matkalla kohti ketteryyttä ............................................................................................................................... 9 Tiimit ....................................................................................................................................................................21 Kehitysjono ......................................................................................................................................................... 27 Valmiin määritelmä .......................................................................................................................................... 36 Toteutus .............................................................................................................................................................. 39 Dokumentointi .................................................................................................................................................. 48 Käyttöönotto ...................................................................................................................................................... 50 Ohjelmistokoodin kokonaishinta .................................................................................................................. 52 Ketterä liiketoiminta ........................................................................................................................................ 54 Onnistumisen määritelmä ............................................................................................................................... 60 Asiakas–toimittaja-suhde ............................................................................................................................... 62 Tuotekehitysvirran johtaminen ..................................................................................................................... 72 Ketterä muutosjohtaminen ............................................................................................................................. 76 Skaalaus ............................................................................................................................................................... 79 Kiitokset .............................................................................................................................................................. 90

JOHDANTO

Tämä kirja sisältää kokemuksia ja oppeja ket-teristä menetelmistä. Ketterien menetelmien tavat hoitaa perinteisistä menetelmistä tuttuja työtehtäviä ovat hyvin moninaisia. Niillä voi-daan tehostaa ja järkeistää projektisuunnitte-lua, tuotemäärittelyä, arkkitehtuurin ja laa-tuominaisuuksien suunnittelua, teknistä suunnittelua, toteutusta, testausta, muutos-hallintaa ja ylläpitoa, riskien hallintaa, asioi-den organisointia ja ihmisten johtamista. Ket-terät menetelmät soveltuvat periaatteessa kaikkiin työvaiheisiin, joita tarvitaan matkalla ideasta valmiin ratkaisun toimitukseen.

Ketterän (engl. agile) tuotekehityksen konsep-ti on syntynyt vastareaktiona perinteisen oh-jelmistokehityksen jäykkyydelle. Ketteryys tarkoittaa, että projektissa pystytään nopeasti tekemään muutoksia, sopeutumaan muutok-siin — proaktiivisesti tai reaktiivisesti — ja oppimaan muutoksista. Tämän ansiosta pys-tytään jatkuvasti tuottamaan aitoa lisäarvoa asiakkaalle (Conboy, 2009). Lähestymistapa toimii parhaiten nopeasti muuttuvissa ympä-ristöissä, kuten esimerkiksi ohjelmistoalalla.

Ketterät menetelmät eivät oikein käytettynä hylkää suunnitelmallisuutta, mutta painopiste siirtyy dokumentaatiosta prosesseihin. Kette-rän suunnitteluprosessin päämääränä on, että kaikki projektiin liittyvät henkilöt ja sidos-ryhmät pääsevät synkronoimaan ymmärryk-sensä siitä, missä juuri nyt ollaan ja mihin suuntaan halutaan mennä. Suunnitelma on tilapäinen työväline, joka on hyödyllinen suunnittelun aikana. Se alkaa kuitenkin van-

heta heti suunnitteluprosessin jälkeen. Suun-nitelma ei ole tärkeä – tärkeää on suunnittelu.

Perinteisesti korkea laatu on tarkoittanut sitä, että tuote on spesifikaation mukainen. Kette-rässä maailmassa korkean laadun ajatellaan sen sijaan tarkoittavan, että prosessi on järke-vä ja että sitä myös käytetään. Ketteryydessä tarkkojen, hierarkkisten suunnitelmien sijalle tulee enemmän prosessien kuvauksia, asioiden tärkeysjärjestyksiä, töiden etenemisen seuran-taa sekä menetelmiä, joilla pyritään lisäämään tiimiläisten ymmärrystä ja helpottamaan kes-kinäistä yhteistyötä. Ketteryydessä asiakkaal-le tarjotaan korkealaatuisen tuotteen lisäksi kehitystyötä tukeva joustava prosessi.

Maailma voidaan jakaa neljään osa-alueeseen asioiden ennustettavuuden mukaan: yksinker-taiset asiat, monimutkaiset asiat, kompleksi-set asiat ja kaaos. Yksinkertaisella alueella ennustettavuus on liki täydellinen. Jokainen ymmärtää, mistä on kyse, miten asiat toimivat ja millä tavalla ongelmia kannattaa korjata. Yksinkertainen on rutiinityötä.

Monimutkaisella alueella tarvitaan asiantun-temusta ja usein myös monelta eri alalta. Mo-nissa hankkeissa voidaan tarvita esim. teknis-tä, taloudellista ja oikeustieteellistä asiantun-temusta. Kommunikaation ja koordinaation tarve kasvaa. Näiden tehtävien hoitamiseen nimetään usein esimerkiksi toimitusjohtaja tai projektipäällikkö. Perinteisesti nämä kommu-nikaatio- ja koordinaatiohaasteet on hoidettu määrittelemällä projektin kulku etukäteen

(projektisuunnitelma). Tämä toimii hyvin silloin, kun maailma on verraten ennustettava ja kun uusia asioita kumpuaa ainoastaan teh-tävän itsensä puitteista. Monimutkainen on asiantuntijatyötä.

Kompleksisella alueella ennustettavuus on niin huono, että asioita pitää tutkia ennen kuin ratkaisua voidaan edes esittää. Suunni-telmia ei ehditä kirjoittaa ja ylläpitää, koska maailma on joko kartoittamaton tai muuttuu niin nopeasti, että käyttökelpoista karttaa ei löydy. Syy-seuraus-suhteet ovat toki selvitet-tävissä jälkikäteen, mistä voi syntyä harhaku-va, että kompleksisen alueen asiat olisivat myös ennustettavissa ja suunniteltavissa. Kompleksisuus on tutkimustyötä.

Ketterä työskentely tasapainoilee kompleksi-sen ja monimutkaisen välillä. Välillä prosessin annetaan elää ja komplisoitua, välillä taas vedetään ohjaksia tiukemmalle ja siistitään prosessia kohti monimutkaista. Jos ohjakset ovat liian tiukalla, päädytään näennäisesti yksinkertaiseen prosessiin, jonka monimut-kaisuus/kompleksisuus on kuitenkin vain piilossa, ei poissa. Jos taas prosessia ei hallita, ollaan kaoottisessa code’n’fix-menetelmässä, joka johtaa suurella varmuudella epäonnistu-miseen vähänkään pientä suuremmissa hank-keissa.

Tietojärjestelmäala on oiva esimerkki edellä mainitusta näennäisestä yksinkertaisuudesta. Kompleksisella alueella epäonnistumisen riski nousee jyrkästi, jos vanhoista suunnitelmista yritetään pitää väkisin kiinni. Jälkikäteen epäonnistuminen voidaan aina jäljittää johon-kin tapahtumaan, jota ei ollut huomioitu suunnitelmassa tai riskilistalla. Kilpailijalta tuli ehkä odottamaton iTuote, tulivuoren tuh-kapilvi lamaannutti logistiikan tai virkamie-hen lakitulkinnan takia syntyi ylimääräisiä kustannuksia. Näitä asioita ei tietenkään ollut otettu huomioon projektisuunnitelmassa. Loogisesti ajatellen ensi kerralla pitäisi suun-nitella vielä paremmin ja tarkemmin ja ehkä rakentaa pitempi riskilista. Uusi projekti on kuitenkin vielä alttiimpi epäonnistumiselle, koska jämäkämpi suunnittelu aiheuttaa entis-tä enemmän vaikeuksia sopeutua muutoksiin.

Näemme, että ketteryys on vahvasti sukua lean-ajattelulle. Kyseessä on kuitenkin selke-ästi eri asia. Lean on kokonaisvaltainen orga-nisaation johtamisen filosofia, joka tukee mai-

niosti ketterien menetelmien käyttöä projek-tinhallinnassa. Monissa ketterissä menetel-missä on mukana lean-filosofian mukaisen organisaation ominaisuuksia, kuten tiimityö, jatkuva parantaminen, systemaattinen mit-taaminen ja niin edelleen. Ketterät menetel-mät on kehitetty sovellettavaksi erityisesti kompleksisella alueella, ratkomaan sille tyy-pillisiä ongelmia. Lean-filosofia on puolestaan alun perin kehitetty ennustettavampiin olo-suhteisiin. Sen perusperiaatteita voidaan silti soveltaa menestyksekkäästi myös muualla, kunhan konteksti otetaan huolellisesti huo-mioon. Ketteryys toimii parhaiten vaatimus-ten selvittämisessä ja järjestelmän suunnitte-lussa. Näitä tehtäviä ei voida automatisoida ja niiden ennustaminen on vaikeaa. Niiden te-kemiseen tarvitaan edelleen ihmisaivoja ja joustavaa kommunikointia. On myös tunnet-tua, että ohjelmistotuotannon suurimmat kustannukset syntyvät juuri tällä alueella. Ketteryys ja lean-ajattelu ovat molemmat hyödyllisiä lähestymistapoja, joissa on paljon yhtenäisyyksiä. Yhdistäviä tekijöitä ovat esi-merkiksi asiakaslähtöisyys, työmäärien rajoit-taminen ja nopeat vasteajat. Ketterälle ohjel-misto-organisaatiolle on erittäin hyödyllistä ymmärtää ja soveltaa lean-periaatteita.

Ketteryys kuuluu uuteen informaatioyhteis-kunnan paradigmaan. Tässä uudessa para-digmassa monet vanhat viisaudet ja perintei-set menetelmät käännetään ylösalaisin. Kette-ryyttä on hankala sisäistää, mikäli vanhat instituutiot kummittelevat taustalla. Tämä on juuri se syy, miksi tämä kirja kirjoitettiin. Kirja antaa vinkkejä tietojärjestelmäkehityk-sen hallintaan niin, että tuloksia saadaan ai-kaan optimaalisella ajan ja resurssien käytöllä.

Lähteet

K. Conboy. Agility from First Principles: Re-constructing the Concept of Agility in Infor-mation Systems Development. Information Systems Research, 20(3): 329–354, September 2009. 10.1287/isre.1090.0236.

T. Toikkanen ja E. Kalliala. Ketteryyden kompleksinen olemus: Scan Agile 2012. Sys-teemityölehti, 2: 16–18, 2012. Systeemityöyh-distys Sytyke ry.

http://fi.wikipedia.org/wiki/Ohjelmistotuotanto

MATKALLA KOHTI KETTERYYTTÄ

Tässä luvussa kerrotaan erään suomalaisen ohjelmistotuotteita kehittävän yrityksen kehi-tyskaaresta kohti ketterää toimintakulttuuria. Tarinan kirjoittajat ovat työskennelleet käy-tännön kehitystehtävissä, keskijohdossa ja ylimmässä johdossa. Tarkastelujakso oli erit-täin voimakkaan kasvun aikaa. Yrityksen henkilöstö kasvoi alle sadasta työntekijästä noin tuhanteen. Samaan aikaan tuotekehityk-sen toimipisteiden määrä kasvoi yhdestä kuu-teen.

Yrityksellä oli useita tuotelinjoja, merkittävää alihankintaa sekä vaativia sisäisten järjestel-mien kehityshankkeita. Tuotteet sisälsivät huipputeknologiaa. Kehityshankkeiden koko vaihteli yhden tiimin lyhyistä projekteista yli sadan hengen hankkeisiin, jotka saattoivat kestää toista vuotta. Yrityksen tuotekehitys-osastolla työskenteli ihmisiä monista eri kult-tuureista, ja monilla osastoilla oli myös yrityk-sen sisällä oma kulttuurinsa.

APINAT SIRKUKSESSA

Oli vuosi 1999. Maailmalla kiehui suuri IT-buumi. Yrityksen listautumispäivänä osakkei-ta jonotettiin kuin teinibändin konserttilippu-ja. Espoossa sijaitsevassa neljän kerroksen toimistotalossa lähes asui joukko nuoria ja innokkaita C++- ja Java-koodaajia koneidensa kanssa. Heitä ei lainkaan haitannut, että talon

ilmastointi ei pystynyt jäähdyttämään monien huoneiden lämpötilaa alle 30 asteen. Kaksi yrityksen tuotteista tuotti voittoa, toinen niistä merkittävästi.

Päätuotteen kehityksessä oli ollut reilun vuo-den ajan käynnissä arkkitehtuurin sukupol-venvaihdos. Uuden arkkitehtuurin piti olla valmis jo useita kuukausia aikaisemmin, edel-lisenä vuonna. Erään testaajan kesälomia siir-rettiin eteenpäin, koska tuote olisi valmis ”aivan kohta” ja häntä tarvittaisiin projektin parin viimeisen viikon aikana. Näin tehtiin jo toisen kerran saman projektin takia. Edellinen kerta oli edellisvuoden kesällä.

Päätuotteen kehityksen lisäksi meneillään oli lukuisia teknologia-, tuotehaara- ja uustuote-projekteja. Projekteja käynnistettiin monella tavalla. Toisinaan yrityksen perustaja itse kertoi yksittäiselle sankariohjelmoijalle, että tämän tulisi aloittaa uusi tuoteprojekti vanho-jen rinnalle, toisinaan taas suuri joukko stra-tegisia johtajia antoi linjaorganisaatiolle teh-täväksi uuden tuotteen kehittämisen.

Kun työmäärästä huolestunut tuotekehityk-sen vetäjä kulki läpi kaikki neljä kerrosta ja laski yhteen kaikki käynnissä olevat projektit, hän päätyi summaan, joka oli merkittävästi suurempi kuin T&K:ssa työskentelevien oh-jelmoijien, testaajien, teknisten kirjoittajien ja linjaesimiesten kokonaismäärä. Jokaisessa

projektissa olisi ollut työtä parille uudelle työntekijälle.

Ratkaisuna ylivoimaiseen projektimäärään johto nimesi seinätaululla prioriteettiprojek-tit, jotka ”eivät saa epäonnistua”. Yhtään käynnissä olevaa projektia ei lopetettu; edel-leenkin odotettiin, että ne valmistuisivat. Työyhteisö muistutti sirkusta, jossa tirehtööri ohjaili vallattomana temppuilevaa apinalaumaa. Vuosia myöhemmin yrityksen silloiset ohjelmoijat muistelevat aikaa lämmöl-lä ja nostalgialla; aikatauluista, järjestelmälli-syydestä ja laadusta murehtinut keskijohto kauhulla.

TERÄSTÄ SELKÄRANKAAN

Yritykseen palkattiin jämäkkä johtaja telealal-ta. Miehellä oli riittävästi selkärankaa häm-mästellä prioriteettiprojektipelleilyä suoraan toimitusjohtajalle: Miksi meillä pitäisi olla projekteja, joilla ei ole edellytyksiä onnistumi-selle? On noloa kirjoittaa isolla tekstillä sei-nälle, että vain projektien vähemmistö on tar-koitettu onnistumaan. Samalla epäsuorasti hyväksytään, että suurin osa projekteista vie tärkeimmiltä projekteilta sekä huomiota että tekijöitä.

Terässelkärankainen johtaja sai tehtäväkseen määritellä tuotekehityksen prosessin. Vuoden sisällä tuotekehitys muuttui kaoottisesta ja energisestä sekamelskasta kurinalaiseksi pro-jektiorganisaatioksi. Projektien aloittamisesta tuli huomattavasti byrokraattisempaa ja aino-astaan taloudellisesti parhaiten perustellut projektit saivat aloitusluvan.

Aivan kaikkea ei saatu ruotuun. Merkittävä osa tuotekehitystä karkasi prosessin ulkopuo-lelle, koska tuolla organisaation osalla oli eri linjaesimies ja koska organisaation tuon osan nimessä ei suoraan mainittu, että heidän pää-tehtävänsä oli kirjoittaa tuotekoodia.

Prosessi oli tyypillinen vaiheistettu tarkistus-pistemalli (phase gate model). Tarkistuspis-teitä käytettiin menestyksekkäästi viestimään projektien edistymistä. Merkittävin kehitys-työ tapahtui kahden pisteen välillä, projektin aloitusluvan saamisesta beta-testauksen al-kamiseen.

Yritys saavutti ensimmäistä kertaa selkeän ennustettavuuden tuotekehitysprosessia nou-dattavissa projekteissa. Määrittely ja liiketoi-minnan suunnittelu oli edelleen luovaa kaaos-ta, mutta siihen käytetty työmäärä ei ollut kovin merkittävä osuus projekteihin käytettä-västä kokonaistyömäärästä. Projektiaikataulu määrittyi toistettavalla algoritmilla ja aikatau-lut pitivät kohtalaisen hyvin.

Liiketoiminnan vaatimukset käytännössä sanelivat julkaisupäivän, josta luonnollisesti neuvoteltiin ankarasti vähähappisissa neuvot-teluhuoneissa. Testausvaihe kesti kaikissa projekteissa kolme kuukautta riippumatta tehtyjen tuotemuutosten määrästä. Jäljellä oleva aika määräsi ohjelmointiin käytettävän ajan.

Prosessin käyttöönoton jälkeen yritys pystyi tekemään kaksi merkittävää tuoteprojektia vuodessa. Näissä kummassakin kaksi kuu-kautta meni uusien ominaisuuksien ohjel-mointiin, kolme kuukautta testaamiseen ja tuotteen stabilointiin. Vuodesta jäi jäljelle kaksi kuukautta, jotka voitiin käyttää lomiin, ylläpitoprojekteihin ja muuhun pienempään sälään. Tätä aikaa muisteltiin myöhemmin suurten saavutusten ja nopean tuotekehityk-sen aikakautena. Aika kultaa muistot. Todelli-suudessa 12 kuukaudesta vain murto-osa oli tehokasta uuden toiminnallisuuden kehitystä. Merkittävästi enemmän aikaa kului ”valmiin” työn saattamiseen julkaisukuntoon.

Kaikesta huolimatta uusi prosessi toi merkit-tävän laatuparannuksen julkaistaviin tuottei-siin. Koska testaukselle ja laadun parantami-selle annettiin aikaisempaa merkittävästi enemmän aikaa ja näkyvyyttä, ei täysin rikki-näisiä tuotteita enää julkaistu. Suurin yksit-täinen toimintatapamuutos on beta-testauksen pakollisuus. Beta-testauksella onnistuttiin toistuvasti poistamaan muutamia pahoja ongelmia, joiden tyyppiset olivat aina aikaisemmin vaatineet ylimääräisen projektin.

Organisaatio oli jaettu teknisen arkkitehtuu-rin perusteella. Yksittäiset tiimit tekivät omaa komponenttiaan omassa ryhmässään juuri-kaan huolehtimatta kokonaisuudesta (tiimi-sanaa käytetään tässä luvussa varsin vapaasti tarkoittamaan sellaistakin ryhmää tai joukkoa ihmisiä, joka ei välttämättä täyttäisi tiimien vaativampia kriteereitä). Komponentit koot-tiin yhteen viikoittain. Toistuvasti kävi ilmi,

ettei kokonaisuus toiminut. Kukaan ei kui-tenkaan kokenut ongelmaa omakseen. Tes-tausvaiheen alussa meni tyypillisesti kaksi viikkoa, ennen kuin tuote pysyi sen verran kasassa, että sitä voitiin testata. Feature Complete -termillä tarkoitettiin tuotetta, joihin komponenttitiimit1 väittivät tehneensä kaikki ominaisuudet, mutta tuskin mikään uusista tai vanhoista ominaisuuksista toimi. Sen ajan kokeneille systeemitestaajille Feature Complete kuulostaa yhtä pahalta ajatukselta kuin koodaajien kahvin vaihtaminen salaa kofeiinittomaan.

VALOA TUNNELIN PÄÄSSÄ

Organisaatio oli nyt toiminut pääasiassa tar-kistuspistemallisten projektien tuottajana muutamia vuosia. Osa tiimeistä oli kuitenkin jäänyt vähälle huomiolle, saanut tarpeekseen tehottomista toimintatavoista tai koostui asiakastarpeista niin etäälle joutuneista teki-jöistä, että oli tarpeen kokeilla uusia mene-telmiä.

Jotkut yksittäiset työntekijät tutkivat maail-malla huomiota herättäneitä ketteriä mene-telmiä. Toiset pitivät prosessin byrokratiaa ja dokumentointivaatimuksia liian raskaina, radikalisoituivat ja kirjoittivat speksin lop-puun lupauksen karkeista ja kaljasta kaikille, jotka olivat jaksaneet lukea sinne asti. Alettiin ymmärtää dokumenttien rajoitukset sekä kommunikaatiovälineinä että niiden kyvyttö-myys pysyä ajan tasalla muuttuvan todelli-suuden mukana.

Eräässä sisäisessä projektissa huolellisesti laadittu projektisuunnitelma heitettiin roska-koppaan, koska sen ei todettu tuottavan mi-tään lisäarvoa. Johto vaati suunnitelmaan pe-rustuvaa edistymisen raportointia. Projektissa valmistumispäivä sen sijaan ennustettiin las-kemalla lappujen määrä seinällä ja kertomalla se lappujen yhteisesti arvioidulla jakautumis-kertoimella. Ennuste oli tässä puolen vuoden

1 Komponenttitiimit perustuvat ajatukseen koodin omistajuudesta ja jakamattomuudesta. Vain komponent-titiimi voi muuttaa kyseistä komponenttia. Koodin jakamattomuuden tarkoituksena on saada koko sovel-luksen vastuut jaettua arkkitehtuurin mukaan. Ongel-maksi muodostuu tietenkin se, että tämä on sisäinen vastuujako, jolla ei ole näkyvyyttä asiakkaalle. Mikään tiimi ei myöskään koe olevansa vastuussa integroinnista tai kokonaisuudesta.

projektissa viikon tarkkuudella oikein. Tästä huolimatta johto kehotti projektipäällikköä siivoamaan ”sen lippulappuhärdellinsä sieltä käytävän seinältä”. Tämän projektin tuotta-man järjestelmän laatu osoittautui myös poik-keuksellisen hyväksi. Tähän vaikutti merkit-tävästi se, että ongelmat käsiteltiin heti (ts. saman viikon aikana), kun ne löydettiin. Uut-ta toiminnallisuutta ei lähdetty tuottamaan vanhan päälle, ennen kuin vanha aihio oli ehjä.

Toisaalla eräs projektipäällikkö aiheutti pel-koa keskijohdossa kertomalla, että hänen projektissaan tehtiin kulloinkin vain tärkeintä asiaa.

No mutta täytyyhän teidän jossain kohtaa se dokumentaatiokin tehdä!?

Jos se täytyy tehdä, silloin se epäile-mättä on jossain kohtaa tärkein asia.

KETTERIÄ SAAREKKEITA

Ymmärryksen ketteristä menetelmistä paran-tuessa ja yleistyessä muodostui kokonaisia tiimejä, jotka osasivat soveltaa menestykselli-sesti ketteriä periaatteita ja luoda itselleen toimivat menetelmät.

Eräästä tiimistä muodostui suunnannäyttäjä. Historiallisesti kyseinen tiimi oli saanut pal-jon vapauksia. Tiimi oli jo jonkin aikaa vas-tannut yksinään useamman tuotteen kehittä-misestä, joten organisointi oli hyvin helppoa. Teknisestikin tiimillä oli yrityksen mittakaa-vassa hyvin vähän riippuvuuksia muihin tuot-teisiin ja yhteisiin komponentteihin. Kun muualla monitiimisissä projekteissa pähkäil-tiin komponenttitiimi-mallin ongelmien kans-sa, tässä tiimissä niitä ei käytännössä ollut. Lisäksi tiimin vastuulla olleet tuotteet olivat kannattavia, mutta eivät firman tärkeimpien joukossa, joten yrityksen johdon mielenkiinto kohdistui muualle.

Tavallinen tarina ketteryyden tavoittelussa lienee sellainen, jossa tiimi alkaa käyttää esi-merkiksi scrumin tarjoamaa tapaa toimia ja oppii sitä kautta pikkuhiljaa ketterämmän ajatusmaailman. Aluksi uudet toimintatavat aiheuttavat konflikteja, koska ne eivät sovi olemassa olevaan ajatusmaailmaan ja kulttuu-riin. Tässä kuvatussa tiimissä ajatusmaailma oli jo ennestään oikeansuuntainen, eikä scru-

min käyttöönotto tuntunut ongelmalliselta, vaan usein pikemminkin helpottavalta.

Tiimi oli vastuussa useista tuotteista kymme-nille eri käyttöjärjestelmille monilla eri kielil-lä. Koska tiimissä oli vain kymmenisen tekijää ja samankaltaisena toistuvaa testaustyötä valtavasti, tiimin testaus- ja laatuasiantuntija ryhtyi kehittämään työvälineitä aluksi oman työnsä helpottamiseksi. Työvälineet havaittiin tiimissä nopeasti vaivan arvoisiksi. Tiimi ke-hittikin työkalut ja prosessit iteratiivisesti ja ennakkoluulottomasti niin edistyksellisiksi, että menestyksellinen toiminta oli mahdollis-ta. Tiimin testaus- ja laatuasiantuntijan kuu-luisa mielipide olikin: ”Ei mua huvita tehdä tommosta savottaa ite, joten mä sit automa-tisoin kaiken”.

Toisaalla oli tiimi, joka kehitti ensimmäistä versiota uudenlaisesta huipputeknologian komponentista olemassa olevan tuotteen si-sään. Tiimi toimi sujuvasti scrum-sprinteissä ja tiimin jäsenet tukivat toisiaan yhteisten tavoitteiden saavuttamiseksi. Kun tiimin laa-tu- ja testausasiantuntija kertoi, ettei pysty enää hallitsemaan työkuormaansa. Silloin algoritmitutkija totesi, ettei kyllä ymmärrä paljon testaamisesta, mutta auttaa mielellään jos vain voi. Tämä olisi ollut ennenkuuluma-tonta vielä vuotta aiemmin. Tiimi toimi osana suurempaa projektia, jonka julkaisupäivää jouduttiin toistuvasti siirtämään. Tiimi lisäsi toiminnallisuutta, kunnes tuli tieto, että jul-kaisupäivä on lyöty lukkoon. Se olisi kahden viikon päästä. Reaktio tähän ei ollut tyypilli-nen kuumeinen toiminta (paniikki!), vaan toiminnan selkeä rauhoittuminen. Ei haluttu tehdä mitään, mikä voisi vaarantaa julkaisun. Laadustakin oli huolehdittu koko projektin ajan.

LAAJEMMAN YMMÄRRYKSEN TAVOIT-TELU

Yrityksen tuotekehityksen vetäjä vaihtui. Ketterät menetelmät olivat saaneet niin paljon yleistä huomiota alalla, että niistä on tulossa salonkikelpoisia itseään edistyksellisiksi pitä-vissä yrityksissä. Scrum ja Extreme Program-ming ovat kuumimmat suuntaukset. Ken Schwaber ja Kent Beck kävivät yrityksessä puhumassa ketteryydestä.

Ketterät saarekkeet olivat kasvaneet ja alka-neet koskettaa toisiaan. Tuotekehityksen johto halusi muuttaa teräksisen projektimallin ketterämmäksi ja parantaa siten tuottavuutta ja laatua. Uuden mallin tekijäksi nimitettiin koko tähänastisen kehityksen nähnyt asian-tuntijaystävällinen ja johdon kieltä kohtalai-sesti puhuva kehitysjohtaja.

Edellinen terästekstinen prosessikuvaus oli noin 50-sivuinen, ylhäältä saneltu opaskirja. Sen koulutusta varten oli tuotettu lukuisia kalvoja ja pitkiä koulutustilaisuuksia. Kette-ryyttä hakeva muutosjohtaja otti tavoitteeksi tehdä asiat tällä kertaa eri tavalla:

tekijät kirjoittaisivat yhteiset toimin-tatavat (prosessin)

prosessin tulisi olla mahdollisimman lyhyt ja korkealla tasolla,

yksityiskohdat toiminnassa määräisi kulttuuri, ei dokumentoitu prosessi, ja

toimintatapojen muutos pitäisi ajaa sisään käytännön kokeiluilla, ei pel-källä koulutuksella.

Syntynyt prosessikuvaus kasvoi tekijöiden kommentoinnin jälkeen alle kymmenestä ku-vitetusta sivusta kahteenkymmeneen. Lisätty-jä yksityiskohtia ei kukaan enää koskaan lu-kenut.

Muutosta vetävä johtaja nimitettiin puoleksi vuodeksi yrityksen suurimman projektin vetä-jäksi, jotta uusi toimintatapa saataisiin käy-täntöön arjen työn kautta. Kyseessä oli noin 100 hengen scrum-projekti, jossa kokeiltaisiin ensimmäistä kertaa teoriassa opittua asiaa näin suuressa kokoluokassa.

Tuore projektipäällikkö loi tuotehallinnon kanssa tuotteen kehitysjonon. Se tehtiin niin korkealla tasolla, että puolen vuoden aikana koko projektin vauhdiksi todettiin 18–22 tuotteen kehitysjonon kohtaa per kuukauden sprintti. Tuotehallinto ei ottanut tuotteen kehitysjonon ylläpitoa omakseen koko puolen vuoden aikana. Ystävällinen projektipäällikkö sai rautaisella otteellaan tuotepäälliköt osal-listumaan kahteen kokoukseen kussakin sprintissä. Ensimmäisessä kokouksessa sprin-tin aikana tuotteen kehitysjonoon lisättiin uudet esille tulleet kehitystarpeet. Jälkimmäi-sessä kokouksessa – pari päivää ennen seuraa-van sprintin alkamista – tuotteen kehitysjo-non noin 30 tärkeintä kohtaa priorisoitiin

ylimmäksi. Muiden vaatimusten todettiin tippuvan ulos seuraavasta sprintistä. Samalla katsottiin, mitä vielä ylipäätään voi mahtua julkaisuaikatauluun ja mitä ominaisuuksia ainakin tippuu projektin laajuudesta ulos. Yksittäisten jääräpäiden ja neuvottelukykyi-sen tuotehallinnon ansiosta organisaatio hy-väksyi viestin, ettei kaikki haluttu mahtuisi julkaisuun. Työmäärä oli valtava ja päivät pitkiä.

Tässä tarinassa sprintit olivat kuukauden mittaisia. Sprintin ensimmäisenä päivänä suu-rin osa projektihenkilöstöä mahtui rakennuk-sen suurimpaan huoneeseen noin tunnin mit-taiseen kokoukseen, jossa esiteltiin tiimien koostumus, tuotteen kehitysjonon järjestys sekä se, mitkä tiimit tekevät mitäkin kehitys-jonon kohtaa. Tuotehallinnon edustajat esitte-levät kuhunkin sprinttiin todennäköisesti mahtuvan tuotteen kehitysjonon kohdan. Lisäksi he esittelivät myös suuremman kuvan, eli roadmapin tulevista tuotejulkaisuista liike-toiminnan sanelemine julkaisupäivineen. Toi-sinaan tämä sujui hyvin, toisinaan oli nähtä-vissä, etteivät kaikki ymmärtäneet kokoon-tumisen ja tehtävien syvempää tarkoitusta.

Ennen jokaisen sprintin alkua oli välttämätön-tä suunnitella uudelleen myös tiimien koos-tumus. Koska tiimit olivat edelleen pääsään-töisesti komponenttitiimejä, usealta tiimiltä puuttui mm. käyttöliittymäosaaminen. Var-sinkin käyttöliittymiä tekevät ohjelmoijat huomasivat joutuvansa vaihtamaan tiimiä usein. Lisäksi he olivat usein jäsenenä ainakin kahdessa tiimissä yhtä aikaa.

Jokaisessa tiimissä Scrum Masteriksi oli ni-metty joko yksi linjaesimiehistä, arkkitehdeis-tä, testaajista tai kokeneemmista ohjelmoijis-ta. Scrum Masterin työnkuvasta ei ollut roo-liin nimetyillä kovin selkeää kuvaa ja siksi tehtävän luonne ja laajuus vaihteli runsaasti. Koska tiimit olivat komponenttitiimejä, Scrum Mastereita tarvittiin varsinkin ratko-maan tiimien välisiä ongelmia. Esimerkiksi virheraportin omistajuutta saatettiin vaihtaa tiimistä toiseen monta kertaa, kun kaikki arvelivat korjaajan löytyvän parhaiten jonkin toisen komponentin tekijöistä.

Parhaita toimintatapamuutoksia oli kesken-eräisen tuotteen laatutason nostaminen. Tes-tiautomaatiota oli toteutettuna vain parille yksittäiselle komponentille, joten päivittäistä

tuoteversiota testasi aamulla aina ensimmäi-seksi töihin tullut. Jos päivän versio oli mer-kittävällä tavalla rikki, joku korjasi sen aina samana päivänä. Moderniin jatkuvaan integ-raatioon verrattuna tämä oli vielä pronssikau-den toimintaa, mutta silti suuri parannus ai-kaisempaan. Ehjän version ylläpidosta seurasi se etu, että testausvaihe lyheni alle kuukau-teen. Beta-testit aloitettiin jo keskeneräisellä tuotteella. Siten pahimmat asiakasympäristös-tä johtuvat ongelmat löytyivät jo ennen pro-jektin loppua.

Toinen merkittävä muutos oli se, että kahta samaan koodiin pohjautuvaa päätuotetta ke-hitettiin yhtä aikaa. Aikaisemmin tuotteita tehtiin peräkkäin. Aina toista kehitettäessä tehtiin ratkaisuja, jotka haittasivat toisen tuotteen valmistumista. Tämä ongelma pois-tui uuden toimintatavan myötä.

Muutosprojektijohtaja pyrki aktiivisesti ja-kamaan projekti- ja tuotevastuuta tiimeille, itse tekijöille. Komponenttitiimit ja niiden vetäjät olivat aiemmin tottuneet olemaan vas-tuussa vain omasta hiekkalaatikostaan. He olivat pääsääntöisesti haluttomia astumaan tämän mukavuusalueen ulkopuolelle. Yksit-täiset henkilöt organisaatiossa ottivat vastuu-ta ja ajoivat sitkeästi kokonaisuuden toimi-vuuden asiaa. He olivat vähemmistönä. Kult-tuuri kuitenkin parani puolen vuoden aikana hitaasti kohti laajemman vastuun ottamista tiimeissä.

Projektipäällikkö alkoi kutsua scrum of scrumsin pidettäväksi päivittäin. Ensin ko-keiltiin samaa sisältöä kuin normaaleissa päi-vittäisissä tiimikokouksissa. Pian huomattiin, että lisäarvoa ei tuota se, että jokaisen tiimin edustaja kertoo, mitä heidän tiiminsä tekee (ellei se vaikuta muihin tiimeihin). Parhaaksi toimintatavaksi vakiintui kokouksen 15 mi-nuutin aikaraja ja muuttuva sisältö. Kokouk-seen osallistujat kirjoittivat seinälle, mitä asi-oita haluavat kokouksessa käsiteltävän. Siten kokouksen päätarkoitukseksi nousi ongelmi-en poistaminen tiimeiltä ja projektilta.

Samaan aikaan eräs merkittävä tuotekompo-nentti kirjoitettiin uudestaan. Työn piti ensin kestää vain pari kuukautta, mutta se venyi lähes vuoden mittaiseksi projektiksi. Valitet-tavasti jossain vaiheessa muu arkkitehtuuri mukautui olettamaan, että uusi komponentti-versio valmistuisi ajoissa julkaisuun. Arkki-

tehtuurissa ei ollut enää mahdollista palata vanhaan versioon. Tämä nousi projektin suu-rimmaksi aikatauluriskiksi. Ilman kyseistä komponenttia ei olisi julkaistavaa tuotetta. Keskeneräisen komponentin kanssa taas puuttui vanhaa toiminnallisuutta ja laatutaso oli riittämätön. Suuren ketterän projektin onnistumista rajoitti kohtalaisen pienen kom-ponentin kriittisyys. Lopullisesti epäselväksi jäi, tehtiinkö missään päättävässä elimessä koskaan todella päätös siitä, että kyseinen komponentti kirjoitettaisiin uudestaan – tai että tuotteen julkaisu saisi riippua siitä.

Vastaavassa tilanteessa kannattaa aina pyrkiä vanhasta arkkitehtuurista vähittäisillä muu-toksilla uuteen ja varmistaa, että joka vaihees-sa voidaan julkaista tuote. Tämä voi näennäi-sesti – mutta ei välttämättä todellisuudessa – suurentaa työmäärää. Vain näin voidaan var-mistaa, että julkaisupäivänä voidaan aina toi-mittaa jotain asiakkaalle.

Ison scrumin käyttöönoton jälkeen projektien ennustettavuus säilyi tai parani. Tuottavuus ainakin näytti paranevan. Vuodessa tehtiin kuusi merkittävää julkaisua kahden sijasta. Laatu oli oleellisesti samalla tasolla kuin en-nenkin, mutta sen tuottaminen oli monin osin huomattavasti pienemmän tuskan takana.

Etäältä katsottuna toiminta näytti scrumilta ja olikin verrattuna moneen muuhun scrum-työskentelyyn. Tarkemmin tutkittaessa mo-nessa tiimissä tai kohdassa noudatettiin kui-tenkin vain seremoniaa ymmärtämättä sen tarkoitusta. Toisaalla yrityksessä oli jopa osas-toja, joissa vain siirryttiin käyttämään muodin mukaista terminologiaa muuttamatta itse toimintatapoja tai ymmärtämättä, mistä ket-teryydessä on kyse.

KETTERÄ TUOTEKEHITYS KÖMPELÖS-SÄ YMPÄRISTÖSSÄ

T&K-osasto kehitti ketterien periaatteiden soveltamista eteenpäin voimakkaasti seuraa-vina vuosina. Asiantuntijasta Scrum Master roolin kautta keskijohtoon ylennetty henkilö asetettiin kehittämään tuotekehityksen mene-telmiä ja prosesseja. Prosessidokumentaatio uusittiin siten, että pohjana käytettiin scru-mia ja organisaation eri osien asiantuntijoiden siihen kehittämiä, yhdessä hyväksyttyjä lisä-

yksiä ja virityksiä. Dokumentaatio oli laajuu-deltaan noin 20 sivua.

Saavutettiin tilanne, jossa valtaosassa noin kolmestakymmenestä scrum-tyyppisestä tii-mistä toiminta oli varsin edistynyttä. Myös tiimien välinen yhteistyö kehittyi. Vuotta myöhemmin ytimekäs tuotekehityksen pro-sessi kuvattiin yhdellä A3-paperilla. Sisältö oli lähes identtinen aikaisempaan versioon näh-den, mutta tarjoiltiin helpommin pureksitta-vassa muodossa. Mukaan oli tullut Dean Lef-fingwellin mallin inspiroima tuotteen kehitys-jonon tehtävien abstraktiohierarkia.

T&K-osasto organisoitui uudelleen siten, että linjaesimiesten roolia muutettiin ja tarkennet-tiin. Tiimien kehitystyön sisältöä ohjasivat tuoteomistaja ja tiimien toimintaa tukivat Scrum Masterit. Linjaesimiehen tehtävä oli huolehtia eri asiantuntijuuden alojen osaa-misyhteisöjen toiminnasta, urapoluista ja kompetenssien kehittymisestä. Näin linjaor-ganisaatio tuki tuotekehitystä, muttei sekaan-tunut varsinaisen työn sisältöön.

Tuoteomistajilla ja Scrum Mastereilla oli omat kompetenssiesimiehensä ja omat osaamisyh-teisönsä. Tiimeissä siirryttiin yhä enemmän featuretiimi-malliin, jossa tiimit tuottavat erilaisia kokonaisia ominaisuuksia järjestel-mään ja ovat vastuussa koko järjestelmän laa-dusta.

Samaan aikaan yrityksellä oli kuitenkin on-gelmia toimittaa asiakkaille luvattuja järjes-telmiä ja ominaisuuksia sovitussa aikataulus-sa. Tilanteen helpottamiseksi organisaatioon perustettiin tuotehallinnon funktio, jonka tehtävä oli huolehtia, että asiakkaiden tarpeet ja mielipiteet ymmärrettiin kunnolla yrityk-sessä.

Aloitettiin suuri ja kunnianhimoinen projekti, jossa oli tarkoitus uusia päätuotteen arkkiteh-tuuri kokonaan, luoda alusta tuleville uusille liiketoiminta-alueille sekä tuoda tuotteeseen uusia ominaisuuksia – kaikki tämä puolessa vuodessa. Tuoteomistajat, laatuasiantuntijat ja T&K:n keskijohto yrittivät viestiä, ettei tämä tulisi onnistumaan. Siitä huolimatta hanke käynnistettiin, ja siihen kiinnitettiin lähes kaikki T&K:n resurssit.

Hankkeen massiivisuuden vuoksi sitä lähdet-tiin suunnittelemaan uudella ketterällä mene-telmällä Joint Release Planning mallin mukai-

sesti. Mallissa tuotekehityksen tuolloin käyt-tämien iteraatioiden, sprinttien, ympärille muodostettiin suurempi vaiheyksikkö, joka sai käytävillä monia nimiä. Viralliseksi käsit-teeksi muodostui vähitellen business iterati-on, liiketoimintatason sprintti. Ensimmäisen viisipäiväisen koulutus- ja suunnittelutapah-tuman veti Dean Leffingwell, mallin kehittäjä. Tapahtumaan osallistui satakunta henkeä.

Jo ensimmäisen liiketoimintatason sprintin aikana havaittiin merkittäviä ongelmia. Seu-raavaa suunnittelukokousta lykättiin muuta-malla viikolla, jotta päästäisiin sprintille ase-tettuihin tavoitteisiin. Katsottiin, että ei ollut järkevää suunnitella uutta tekemistä, kun entistäkin oli vielä jäljellä. Aikataulumuutok-sen takia yrityksen oli hoidettava seuraavat suunnittelutapahtumat yksinomaan omalla henkilöstöllä.

Suunnittelutapahtumat kehittyivät ja muut-tuivat ajan myötä tehokkaammiksi. Niissä oli täysin uudenlainen mahdollisuus löytää ja ratkoa yhteistoimintatason ongelmia erittäin lyhyessä kalenteriajassa. Toisaalta tapahtumat saivat kritiikkiä siitä, että ne olivat kalliita ja veivät liikaa työaikaa.

Tarkasteltavana olevan suuren projektin aika-na tuotekehityksen menetelmät edistyivät merkittävästi. Perustettiin globaali, yli tusi-nan eri tiimin päivittäiskokous, joka alkoi heti myös kehittää omaa toimintaansa. Kehitys-työkalut kehittyivät nopeasti. Erityisen paljon kehittyivät hierarkkiset integraatio- ja testi-automaatiojärjestelmät sekä niitä valvovat raportointijärjestelmät. Kahden viikon sprin-tissä saatettiin tehdä tuhat buildia ja joka päivä käynnistettiin tuhansia virtuaalikoneita testaamaan integroituja buildeja. Arkkiteh-tuurityötä koordinoi erillisen arkkitehtitiimin jäsen, ja arkkitehtitiimin toimintaan osallistui teknisiä edustajia kaikista tiimeistä.

Projektin kuluessa vastuuta ja vapautta valu-tettiin yhä enemmän tiimeille ja tiimien päi-vittäiskokoukselle. Virheet käsiteltiin välit-tömästi tiimeissä tai viimeistään päivittäisko-kouksessa. Jos avoimien virheiden määrä ylitti määritellyn rajan, uuden toiminnallisuuden kehitystyö pysäytettiin (stop the line). Tiimi-en päivittäiskokous sai myös vallan päättää beta-version julkaisusta koekäyttäjille kahden viikon välein. Kaoottisesta projektitilanteesta

huolimatta julkaisu onnistui 1–2 kertaa kuu-kaudessa.

Projekti kesti pitkään. Venyminen oli selvästi nähtävissä jo etukäteen sekä tuotteen kehitys-jonoon perustuvissa projektiraporteissa että 2–3 kuukauden välein toistuvissa suunnittelu-tapahtumissa. Projektia ei kuitenkaan voitu ohjata tehokkaasti. Tähän olivat syynä yrityk-sen johtamisprosessit sekä uuden tuotehallin-non ja T&K:n väliset kommunikaatio-ongelmat.

Näistä ylätason ongelmista huolimatta monet tuotekehityksen tiimit jatkoivat ammatillista kehittymistään. Ne tutkivat erilaisia mm. kanban-pohjaisia ratkaisuja edetäkseen kehi-tysasteelta, johon ne olivat scrumin avulla päässeet.

Business Iteration Planning -tapahtumia la-kattiin jossain vaiheessa järjestämästä suu-rimmassa tuotelinjassa. Syy tähän on edel-leenkin hieman epäselvä. Eräs toinen tuotelin-ja oli kuitenkin jatkanut niiden käyttöä me-nestyksellisesti. Tärkeimpänä saavutuksena nähtiin varsin hyvä yhteisymmärrys ja luotta-mus tuotehallinnon päättäjien ja suorittavan työn asiantuntijoiden välillä.

TUOTEHALLINTO JA KETTERYYS

Vaikka ketterät menetelmät etenivät T&K:ssa, yritys kokonaisuutena tunsi suurta tuskaa tuotekehityksen hitaudesta. Hitauson-gelmaa tutkittiin huolellisesti ja siihen löydet-tiin toistuvia syitä:

yrityksessä aloitettiin liian suuria pro-jekteja

tehtävät asiat kiinnitettiin liian pit-kän aikavälin osalta

tuotekehitykseen ei varattu lainkaan valmiuksia reagoida muuttuviin tilan-teisiin

projektit luotiin siten, että ne olivat toisistaan riippuvaisia sekä teknisesti että henkilöresursseiltaan.

Yrityksen johto reagoi havaintoihin perusta-malla työryhmän, joka tutki ongelmia ja etsi niille ratkaisuja yli organisaatiorajojen. Työ-ryhmän tärkeimpiin tuloksiin kuului yhteen-veto siitä, kuinka organisaation läpi kulkeva asiakasarvoa tuottava prosessi olisi luotava.

Eri osastoilla työskentelevien ihmisten olisi välttämätöntä ymmärtää, millaista arvoketjua heidän työnsä palvelee. Päätökset prosessin kaikissa vaiheissa tulisi tehdä

kokonaisuuden kannalta eri funktioiden näkökulmat huomioon

ottaen järkiperusteisesti

läpinäkyvästi.

Tämän uuden prosessin määrittely ja sovelta-minen antoi yritykseen aivan uudenlaista kor-kean tason näkyvyyttä siihen

mitä yrityksessä kulloinkin kehitet-tiin

mitkä kehitystehtävät oli päätetty ja mitkä olivat vielä harkinnan alla

mikä oli eri kehitystehtävien kunkin hetkinen tila

mitkä kehitystehtävät mahtuisivat tuotekehityksen kapasiteettiin ennus-tettavissa olevassa tulevaisuudessa

mitä asiakkaille voitaisiin luvata, ja mitä ei.

Tähän tilannekuvaan liittyvät kiinteästi yri-tyksen operatiivisen laadun mittarit. Opera-tiivisen toiminnan tietopohjainen johtaminen on mahdollista vasta, kun siihen saadaan mi-tattavaa näkyvyyttä. Mittareilla voidaan seu-rata ja ohjata toiminnan parantamista yrityk-sessä.

Valitut, edelleenkin käytössä olevat operatii-visen laadun mittarit olivat:

Lead Time: kalenteriaika tuotekehitys-päätöksestä tuotteen käyttöönottoon asiakkaan tuotantoympäristössä

Value Throughput: arvioidun lisäarvon tuotto aikayksikössä

Net Promoter Score: tuotettujen järjes-telmien suosittelualttius

Work-in-Progress: keskeneräisiin hank-keisiin tehty investointi ja kesken-eräinen työ.

Osassa yritystä uusia toimintatapoja sovellet-tiin järjestelmällisesti, muissa osissa sammu-teltiin vanhaan tapaan operatiivisia tulipaloja. Näillä muutoksilla oli saavutettu merkittävää edistystä myynnin, tuotehallinnan ja T&K:n välisessä kommunikaatiossa. Hankkeiden

koko oli pienentynyt ja ennustettavuus suu-rentunut. Reagointikyky mahdollisuuksiin ja uhkiin oli parantunut. Myös johdon näkyvyys toimintaan oli parantunut merkittävästi. Sa-malla oli parantunut ongelmienkin esiintulo, mikä lisäsi erityisesti keskijohdon ja ylimmän johdon tuskaa.

TIIMIEN KEHITTYMINEN

Oltiin vielä ottamassa ketteryyden ensiaskelia. Jälkiviisaus tulisi osoittamaan, että valmiudet itseohjautuvaan toiminnan kehittämiseen vaihteli tiimeissä hyvin paljon. Vielä tästä ei kuitenkaan ollut kuin kalpea aavistus. Osa tiimeistä oli itse asiassa jo omaksunut oikean asenteen. Nämä tiimit saivat pian selkeää etumatkaa uusien toimintatapojen käyttöön-otossa ja pystyivät tehostamaan toimintaansa. Yleisesti ottaen nämä tiimit olivat tähän men-nessä saaneet johdolta vähiten huomiota, hy-vässä ja pahassa. Niiden työstämät tuotteet eivät ehkä olleet kaikkein asiakaskriittisim-piä. Lisäksi kyseisten tiimien teknistä erikois-osaamistakin kunnioitettiin, mikä vähensi johdon halua puuttua tiimien sisäiseen työs-kentelyyn. Tiukan ulkopuolisen ohjauksen puute oli ajanut tiimejä itseohjautuvuuden suuntaan jo pidempään ja pakottanut ne luot-tamaan omaan arviointikykyynsä. Aivan toi-sessa ääripäässä olivat liiketoiminnan kannal-ta kaikkein kriittisimpien tuotteiden kanssa toimineet tiimit. Ne olivat joutuneet suoras-taan mikromanageeratuiksi. Painetta riitti oikealta ja vasemmalta. Tiimit eivät olleet tottuneet nauttimaan luottamusta tai päättä-mään juuri mistään itse. Puhumattakaan siitä, että ne tiimit olisivat edes osanneet tarkastella ongelmia koko projektin näkökulmasta – ko-ko organisaation näkökulmasta puhumatta-kaan.

Suurin osa tuotekehitysorganisaation henki-löstöstä työskenteli erilaisissa komponentti-tiimeissä. Tiimien kokoonpanot vaihtelivat jatkuvasti, ihmisiä siirrettiin aina tarpeen mukaan sinne, missä kunkin teknistä osaa-mista tarvittiin. Tässä toimintamallissa ei nähty mitään vikaa. Jokaisella henkilöllä oli omat vastuualueensa. Lähes jokaiselle oli mää-ritelty henkilökohtaiset tavoitteet, joita käy-tettiin suoritusarvioinnissa. Yhteinen tavoite oli häilyvä. Niin yksittäisten henkilöiden kuin kokonaisten tiimienkin vastuualueiden väliin

jäävän harmaan alueen jatkuva kartoittaminen aiheutti projektihallinnolle harmaita hiuksia.

Ketterän toimintatavan aamunkoitossa tiimit ohjattiin tekemään retrospektiivejä eli retroja. Alkuasetelmasta huolimatta lähes jokainen tiimi aloitti helpoista, tiimiä lähellä olevista ongelmista. Ensi alkuun ongelmia vain listat-tiin. Lista saatettiin korkeintaan toimittaa lähimmälle esimiehelle, jonka toivottiin rat-kaisevan listatut ongelmat tiimin puolesta. Sprintit olivat kuukauden mittaisia, mutta retroon käytettiin yleensä hädin tuskin tunti. Monikaan tiimi ei ollut motivoitunut retroi-hin, ja tuskastuneet kehittäjät kiemurtelivat tuoleissaan: ”Ei kai taas, meillä olis oikeitakin töitä!”

Asiaa ei helpottanut se, että useimmat Scrum Masterit olivat vielä tehtävässään aivan aloit-telijoita. Juuri kukaan heistä ei toiminut teh-tävässään täysipäiväisesti. Kenelläkään ei ollut aikaisempaa kokemusta siitä, millainen vaiku-tus hyvällä fasilitoijalla voisi olla tiimityön tekemiseen ja tiimin kehittymiseen. Scrum Master oli vain rooli, jonka työn oletettiin koostuvan lähinnä kokoussihteerin tehtävistä. Heillä oli tiimeissään ”oikeakin työ”. Paineen alla tämä ”oikea työ” otti yleensä ykköspriori-teetin. Osa tiimeistä kierrätti Scrum Masterin tehtävää, joten kehittyminen tässä taiteenla-jissa tapahtui hitaasti. Kun vielä tiimit vaih-tuivat usein, oli myös mahdotonta toimia niin pitkäjänteisesti, että suurten ongelmien käsit-tely ja ratkaiseminen olisi onnistunut. ”Miksi näkisin paljon vaivaa vaikean ongelman paris-sa? Seuraavassa projektissa se ei ole ainakaan minun päänsärkyni. Juuri löydetyn ongelman ratkaisuun menevä aika olisi sitä paitsi pois niiltä tavoitteilta, joita vasten suoritukseni piakkoin arvioidaan.”

Lopulta tiimin pysyvyyden arvo oivallettiin. Uudelleenorganisoinnin tuskasta huolimatta komponenttitiimeistä päätettiin luopua. Tuo-tekehitys järjestettiin toiminnallisuustiimeik-si2 (feature team). Näiden tiimien oli tarkoitus olla miehitykseltään pysyvämpiä ja vastata kokonaisen toiminnallisuuden toimittamises-ta tietyn komponentin kehittämisen sijaan.

2 Featuretiimit perustuvat ajatukseen asiakkaalle näky-vän ominaisuuden (toiminteen) omistajuudesta. Featu-retiimillä on oikeus muuttaa mitä tahansa komponenttia ominaisuuden toteuttamiseksi. Lähdekoodia ei omista kukaan; kaikilla on oikeus kaikkeen koodiin. Featuretiimi on aina vastuussa asiakkaalle.

Henkilövaihdokset tiimeissä eivät loppuneet, mutta muutokset vähenivät huomattavasti. Siirtyminen henkilökohtaisista vastuualueista ja tavoitteista yhteiseen tiimitavoitteeseen aiheutti aluksi paljon päänvaivaa. Tiimien oli löydettävä tavat selviytyä harmaista alueista tiimin sisällä itse.

Vähitellen tiimit oppivat napsimaan pieniä voittoja ja ratkaisemaan tiimin hallinnassa olevia ongelmia. Näiden alun onnistumisen jälkeen monet tiimit törmäsivätkin seinään. Retrojen avulla oli saatu poimittua kaikki matalalla roikkuvat hedelmät. Jäljellä olikin enää ongelmia, jotka eivät olleet kokonaan tiimin toimivallassa. Niihin ei koskettu muu-toin kuin raportoimalla ne ylöspäin. Samat ongelmat tuppasivat silti päätymään Post-it-lapuille sprintti toisensa jälkeen. Tässä vai-heessa osa porukasta alkoi menettää motivaa-tiotaan ja halusi – ymmärrettävästikin – laka-ta hukkaamasta aikaa turhuuksiin: ”Mehän toimitaan jo niin hyvin kuin mahdollista!”

Ennen kuin Scrum Masterien potentiaali kunnolla käsitettiin, tarvittiin toiminnan ke-hittämisessä auttaneen konsultin luja suositus roolin vahvistamisesta. Seuraavassa organisaa-tiomuutoksessa Scrum Mastereista tehtiin päätoimisia, kokopäiväisiä Scrum Mastereita. Samalla siirryttiin kompetenssiesimiesmalliin ja luovuttiin tiimiesimiehistä.

Tiimeillä oli projektinsa kontekstissa nyt enemmän valtaa ja vastuuta kuin koskaan aikaisemmin. Pian ne alkoivat huolehtia myös tiimien väliin jäävästä harmaasta alueesta varsin menestyksekkäästi. Ongelmat, jotka eivät kuuluneet kunnolla minkään tiimin en-sisijaiseen vastuualueeseen, ratkaistiin Scrum Masterien fasilitoiman yhteistyön avulla.

UTOPIA

Kaikkien edellä kuvattujen vaiheiden aikana kaikilla yrityksessä toimivilla henkilöillä oli varmaankin jonkinlainen visio tavoitetilasta, nirvanasta Windowsin vihreän taustaku-vanurmikon tuolla puolen. Tässä hahmotel-laan eräs tällainen utopia.

Yrityksen toiminnan ohjaamisen ytimessä on asiakkaiden odotusten täyttäminen ja asiak-kaiden aktiivinen kuunteleminen. Kaikki asi-akkaat eivät välttämättä ole sopivia asiakkaita

tälle yritykselle. Yritys ei pyri miellyttämään kaikkia, vaan on uskollinen omalla sisimmäl-leen ja niille asiakkaille, jotka uskovat samaan kuin yritys itse. Yrityksen itsekunnioituksen suurin tuki on asiakkaiden uskollisuus ja halu suositella yritystä ystävilleen ja kollegoilleen.

Asiakastarpeiden ymmärtämiseksi yrityksellä on monta herkkää korvaa. Sen jokainen työn-tekijä on säännöllisesti yhteydessä asiakkai-siin. Eräs johtoryhmän jäsen soittaa joka viik-ko jollekin yrityksen asiakkaalle tiedustellak-seen heidän kokemuksiaan yrityksestä ja sen tuotteista. Vastaanottotiskin yläpuolella on aina nähtävissä tuoreimman asiakaspalaute-tiedustelun tulos.

Henkilöstöjohtaminen perustuu viimeisim-pien motivaatiokyselyiden tuloksiin. Johtami-sen menetelmät keskittyvät työntekijöiden sisäisen motivaation, hyödyllisyyden tunteen, työn mielekkyyden ja tarpeellisuuden tunteen tukemiseen. Palkka on kilpailukykyinen eikä aiheuta merkittävää keskustelua yrityksessä. Luovuutta vaativaa asiantuntijatyötä ei kan-nusteta tavoitepalkkioin. Asiantuntijatyö ei ole lumenluonnin kaltaista rutiinityötä, josta on perusteltua maksaa urakkapalkkio. Yritys-kulttuuriin kuuluu kiittää kahden kesken ja toisinaan myös ryhmässä hyvistä työsuorituk-sista ja asiakkaan ilahduttamisesta. Myöntei-sen palautteen säännöllistä antamista odote-taan erityisesti jokaiselta linjaesimieheltä. Yrityksessä vallitsee onnistumista tukeva ja haasteiden voittamiseen kannustava ilmapiiri.

Ohjelmistokehityksessä tavoitteena on asia-kastarpeiden mahdollisimman nopea tyydyt-täminen. Vaikka jokin asiakasprojekti olisi kestoltaan vuosia, toimittaa se ensimmäisen version tuotteesta tuotantoon jo kuukauden työn jälkeen. Uusi päivitys integroituu asiak-kaan vanhaan järjestelmään ja ratkaisee aina-kin osittain asiakkaan pahimmaksi kokeman ongelman. Kehitystiimin jäsenet vierailevat viikon päästä jälkeen asiakkaan luona pyytä-mässä palautetta toimitetusta ohjelmistosta. Samalla he esittelevät senhetkisen kehitysver-sion suuntaa. Projektin päättyessä suunnitel-lun projektiaikataulun mukaisesi projekti on muuttanut suuntaa joustavasti useita kertoja. Jo ennen projektin lopullista valmistumista asiakas on säästänyt osittaisten toimitusten tuomilla hyödyillä toimittajan laskuttamat projektikustannukset.

Yrityksellä on myös kuluttajatuotteita tekeviä tuotekehitysryhmiä. Niille kaikille yhteistä on jatkuva uuden kokeilu, lukuisat epäonnistu-miset ja epäonnistumisen myöntämiset sekä nopea kuluvirran katkaisu. Kokeilujen seura-uksena löydetään usein räjähdysmäisesti kas-vavia uusia tuotealueita.

Merkittävät investointipäätökset tehdään datan pohjalta. Uudet tuote- ja liiketoiminta-mallit testataan käytännössä mahdollisimman nopeasti, ennen kuin niihin sijoitetaan kestä-mättömiä rahasummia tai muuten sitoudu-taan liikaa.

Tavallisen tuotekehitystyön ohessa kehitys-tiimi poistaa tuotteesta ominaisuuksia, joita asiakkaat eivät käytä tai joista he eivät pidä. Tämä yksinkertaistaa tuotteen käyttöä (asi-akkaan etu) ja sen arkkitehtuuria (kehittäjien etu). Samalla tuotteen ylläpitokustannuksia pystytään vähentämään merkittävästi.

Ohjelmistovirheiden vakavuutta ei luokitella. Asiakkaiden kanssa yhteydessä olevat kehi-tystiimit itse priorisoivat virheet kolmeen luokkaan: 1) korjataan heti, 2) korjataan en-nen kuin otetaan muuta uutta työtä, tai 3) suljetaan korjaamatta. Jos ongelma luokitel-laan virheellisesti viimeiseen kategoriaan, asia tulee kyllä uudelleen esille.

Tuotteesta on olemassa vain yksi kehityshaa-ra, josta voi olla useita kypsyysasteita. Viimei-sin toimiva asiakkaalle toimitettavaksi kel-paava versio ei ole koskaan viikkoa vanhempi. Näin ei ole edes silloin, kun tuote on turvalli-suuskriittinen lääketekniikan laite. Tähän varmuuteen on päästy jatkuvilla automaatti-silla tarkistuksilla ja testauksella. Suuri rooli luotettavuuden lisäämisessä on myös tuotteen jatkuvalla yksinkertaistamisella. Tuotteen integrointijärjestelmä hyväksyy vain muutok-set, jotka ovat läpäisseet automaattiset perus-testit. Vakaan version leiman saa vain ohjel-misto, joka on läpäissyt kaikki automaatiotes-tit. Julkaistavan version leima on tämän lisäksi vaatinut tutkivaa testausta tekevän tiimin antaman laatuarvion. He ovat jatkuvassa yh-teydessä sekä beta-testaajiin että tuotetukeen ja ymmärtävät siksi ongelmien kriittisyyden. He ymmärtävät, minkälaiset ongelmat alenta-vat asiakasuskollisuutta ja minkälaiset voi-daan puolestaan hyväksyä korjattavaksi myö-hemmin tai jättää kokonaan huomiotta.

Turvallisuuskriittistä tuotetta tekevään tii-miin kuuluu (tai on jatkuvasti tiimin käytet-tävissä) vähintään yksi asiantuntija, joka voi auttaa priorisointipäätösten teossa. Löydetty-jen ongelmien priorisointia ei koskaan lykätä, jotta jokin muu ominaisuus saataisiin nope-ammin valmiiksi. Tunnistetut ongelmat pyri-tään käsittelemään aina niin nopeasti kuin mahdollista. Tällöin ne pääse estämään jatko-kehitystä, testaamista tai julkaisua.

Kun useita vuosia aikaisemmin kirjoitettuja tuotteen osia tarvitsee muuttaa, tuotekehitys jättää aina jälkeensä aikaisempaa paremmin järjestellyn koodipohjan ja edelleen toimivat automaatiotestit. Automaatiotestikoodia käsi-tellään samalla huolellisuudella kuin tuote-koodia. Automatisoidut testit mielletään osaksi tuotetta.

Kun uusia työntekijöitä palkataan, hakupro-sessiin kuuluvilla ohjelmointi-, testaus- ja organisointitaitojen osoituksille annetaan suurempi painoarvo kuin hakijan akateemisel-le taustalle. Vakavat puutteet sosiaalisissa taidoissa ovat peruste hakijan hylkäämiselle.

Työntekijöiden osaamista pyritään jatkuvasti kasvattamaan. Yritys on luopunut konferens-seista ja ulkopuolisista kursseista pääasialli-sena työntekijöiden koulutustapana. Niitä käytetään lähinnä uusien toimintatapojen haisteluun ja verkostoitumiseen. Perusasioita opiskellaan yhdessä muiden työntekijöiden kanssa, verkkokursseilla ja kokeneempien työntekijöiden mentoroimana. Jokaisen tuote- ja testauskoodin – myös kaikkein kokeneim-man ja osaavimman ohjelmoijan kirjoittaman koodin – katselmoi ainakin yksi koodaaja ennen kuin koodi hyväksytään integroitavak-si.

Julkaistuista tuotteista on olemassa helposti ymmärrettävä korkean tason arkkitehtuuri- ja rajapintadokumentaatio. Tuotantojärjestel-mästä löytyy ainakin yksi kuva, jota käytetään arkityössä ja sitä päivitetään aina, kun se huomataan virheelliseksi. Nopeasti tapetuista kokeiluista ei dokumentaatiota välttämättä koskaan edes ehditä luoda.

Aina kun uutta toiminnallisuutta kehitetään, ryhmän seinällä on vähintään yhden virkkeen mittainen määritelmä tavoitteesta. Se kertoo, kuka toiminnallisuutta tarvitsee, mitä hän haluaa sillä tehdä ja miksi. Usein tämä määri-

telmä poikii tarpeen analysoida ja myös do-kumentoida tarvittavaa arkkitehtuurimuutos-ta ja ohjelmiston sisäistä kommunikaa-tiovuota. Ylläpidettävään dokumentaatioon sisällytetään tärkeimmät työdokumentit, rei-lusti alle puolet tai jopa vain yksi prosentti tuotetusta dokumentaatiosta.

Ohjelmistoyritysten suuri haaste on myynnin ja johdon kyky visioida uusia tuotteita ja tuo-teominaisuuksia nopeammin kuin ohjelmisto-kehittäjät pystyvät niitä toteuttamaan. Tämä haaste myös aiheuttaa usein tulehtuneita hen-kilösuhteita ja sisäisiä ristiriitoja. Kun into tuottaa uutta yhdistetään inhimilliseen ha-luun uskoa hyviä uutisia ja epäillä huonoja, on vaikea saada johto hyväksymään realistisia työaika-arvioita. Tämän kirjan esimerkit ker-tovat varmasti sekä perustellusta että perus-teettomasta tuotekehityksen alhaisen tuotta-vuuden kritisoinnista.

Utopistinen sirkuskummajaisen ketteryyden saavuttanut yritys pystyy kiertämään koko ongelman. Myyjät keskittyvät myymään vain olemassa olevia tuotteita. He eivät lupaa asi-akkaalle vuoden kuluttua markkinoilla olevan tuotteen olevan kilpailijan tuotetta parempi. Jos asiakas kuitenkin tätä vaatisi, myyjät selit-tävät heille yrityksen filosofian aina kuunnella asiakasta ja toimittaa nopeita ratkaisuja kii-reisimpiin tarpeisiin. Yrityksen historia vah-vistaa tämän väitteen. Myyjä kehottaa asia-kasta vertaamaan yrityksen kykyä täyttää tämän tarpeet kilpailijan vastaavaan kykyyn. Jos kilpailijalla on tällä hetkellä tarjolla pa-rempi tuote kuin ketterällä yrityksellä, voi myyjä sanoa että asiakkaalla on edessään vai-kea valinta. Asiakkaan pitää arvioida, uskooko hän ketterän yrityksen toimivan jatkossa, kuten se on toiminut ennenkin. Jos asiakas luottaa, että yrityksen tuotteet täyttävät asi-akkaan odotukset jatkuvasti paremmin – myös kilpailijaa paremmin – yritys on oikea kumppani asiakkaalle. Muussa tapauksessa asiakkaan kannattaa valita kilpailija.

Suurten tuotekehityshankkeiden koko- ja resurssiarviointi on erittäin vaikeaa. Yrityksen johto välttää tällaisia hankkeita viimeiseen asti. Vaikka näyttäisi, että olemassa olevan teknologian vähittäinen muuttaminen moder-niksi maksaa tuplasti enemmän kuin sen kor-jaaminen kertarysäyksellä isossa projektissa, yrityksen johto valitsee lähes aina inkremen-taalisen tavan. Asteittaisen kehitystavan on

todettu johtavan huomattavasti useammin onnistuneeseen lopputulokseen. Isot projektit epäonnistuvat usein. Usein niiden kustannus- ja aika-arviot osoittautuvat katastrofaalisen vääriksi. Yrityksen johto on oppinut omista ja muiden kokemuksista ja suhtautuu lupauk-siin onnistua ”tällä kertaa” epäilevästi, vaikka projektilla näyttäisi olevan onnistumisen edel-lytykset. Hyvältä näyttäviä edellytyksiä on nähty ennenkin, eivätkä hankkeet ole silti onnistuneet.

Yritys ei tee yli kuukauden mittaisia sopimuk-sia ilman, että kumpikin sopijaosapuoli voi purkaa sopimuksen kuukauden varoitusajalla ilman erillisiä sakkoja. Pitkissä asiakastoimi-tusprojekteissa yritys laskuttaa asiakasta kuukausittain ja vastaavasti toimittaa aitoa hyötyä tuottavia väliversioita jatkuvasti.

Koko yritys ymmärtää, ettei tuotekehityksen nopeus parane nopeasti ilman kompromisseja. Kompromisseja joudutaan tekemään esimer-kiksi laadussa. Tuotekehityksen pitkän aika-välin toimitusnopeus tunnetaan hyvin. Sen lisäksi ymmärretään, että vaikka pitkälläkin aikavälillä tuotekehityksen jokin tietty sisältö voidaan luvata ennustettavasti, sitä ei tehdä. Sitä ei haluta tehdä, koska aiempien kokemus-ten perustella ajan mittaa on aina opittu jo-tain, joka on johtanut pitkän aikavälin suun-nitelman radikaaliin uusimiseen.

Kaiken yllä olevan ansiosta asiakas kokee yrityksen jatkuvasti toimittavan parempia

ratkaisuja kuin mitä hän osasi projektin alussa ongelmiinsa pyytää.

Uutta teknologiaa vaativaa isoa tuotetta, esi-merkiksi uudentyyppisen lentokoneen, ava-ruusaluksen, laivan tai tehtaan ohjausjärjes-telmää ei kekseliäästikään ajatellen ole mah-dollista toimittaa tuotantoon osissa. Aikatau-lu voi edellyttää esimerkiksi, että fyysinen tuotantoympäristö, laiva, ydinvoimala tai len-tokone on käytettävissä samaan aikaan kuin ohjelmisto, ehkä vasta vuosia projektin aloit-tamisen jälkeen. Silloin ketterä tuotekehitys-projekti rakentaa osana tuotekehitystä tuo-tantoympäristön simulaation. Ohjelmiston ja rakennettavan järjestelmän osia integroidaan ja testataan jatkuvasti yhdessä, vaikka se näyttäisi kasvattavan kustannuksia. Tällä tavalla havaitaan virheitä, jotka perinteisesti olisi havaittu vasta juuri ennen tuotantoon siirtymistä.

Tuotekehitys kehittää työvälineitään jatku-vasti vastaamaan yhä paremmin sen omiin tarpeisiin osana normaalia tuotekehitystä. Huolellisesti suunniteltu mittarijärjestelmä ylläpitää yrityksen tilannekuvaa ja ohjaa pro-sessien jatkuvaa parantamista. Koko henkilös-tö ymmärtää ja hyväksyy tämän ja on sitoutu-nut tällaiseen toiminnanohjaukseen. Kette-ryys tukee yksilöiden ja organisaation oppi-mista, mikä parantaa jatkuvasti myös loppu-tuotteita.

TIIMIT

Ohjelmistoalan projektihenkilöstö muodostuu työntekijöistä, joiden töiden jäsentäminen hoidetaan yhdessä tai useammassa tiimissä. Tiimien muodostustapa, henkilöiden osaami-nen, tiimiroolit ja henkilökemiat vaikuttavat työnteon sujuvuuteen ja hankkeiden onnis-tumiseen. Organisaation johtamiskäytännöt ja strategia vaikuttavat siihen, kuinka työt jae-taan useiden tiimien kesken.

Ketterä tiimi on suhteellisen itsenäinen yk-sikkö. Sen tulee kuitenkin pysyä organisaati-ossa sille sovituissa raameissa. Tiimin toimin-taympäristössä on monia asioita, joita ei voida muuttaa tiimin omalla päätöksellä. Lisäksi sekä yrityksiä että yksilöitä ohjaavat eri sidos-ryhmien ja asiakkaiden muuttuvat tilanteet. Asiakkaiden tarpeet ja vaatimukset saattavat muuttua. Yritykset joutuvat mukauttamaan liiketoimintaansa. Kaikki tällaiset muutokset asettavat tiimille haasteita.

Johtaminen voidaan määritellä toiminnaksi, jolla ihmiset saadaan tekemään yhdessä töitä yhteisen päämäärän eteen. Tiimissä ajatellaan usein, että jokainen on oman työnsä johtaja. Mitä tämä käytännössä oikein tarkoittaa? Entä kuinka käy yhteistyön, jos jokainen joh-taa itseään?

Tarina: Siiloja tiimissä

Olipa kerran tiimi, joka oli toiminut perintei-sillä menetelmillä jo vuosia. Tiimi päätti ryh-tyä ketteräksi tiimiksi muunkin organisaation tehdessä näin. Monella suhteessa muutos

menikin hyvin. Scrum alkoi toimia mukavasti tiimin projektinhallintakäytäntönä, ja tiimin työskentely kehittyi suotuisasti. Toisaalta tiimin jäsenten työkuorman jakautuminen muuttui huomattavan epätasaiseksi. Aikai-semmin käyttöliittymää ohjelmoineet henkilöt tekivät töitä nyt kahdelle erilliselle tiimille. Käyttöliittymärajapinnan toisella puolella taustajärjestelmään muutoksia tekevät henki-löt saivat sprinteissä merkittävästi enemmän tehtäviä kuin käyttöliittymän parissa työs-kentelevät ohjelmoija. Tämä epäsuhta alkoi aiheuttaa huomattavaa närkästymistä tiimissä ja henkilösuhteiden kärjistymistä. ”Olen vain käyttöliittymäohjelmoija”, ”minä teen täällä vain testausta” ja muut vastaavat lausahduk-set olivat osoitus siitä, että tiimin työ oli sii-loutunut. Ketterässä tiimissä tarkoituksena on, että tiimissä on mahdollisimman paljon ihmisiä, jotka pystyvät suorittamaan laaja-alaisesti erilaisia tehtäviä. Ei ole tehokasta, että ihmiset tekevät pelkästään yhtä tarkkaan rajattua tehtäväaluetta, esim. testausta tai yhden tietyn komponentin koodaamista. Ket-terässä tiimissä tehtävien pitäisi olla koko tiimin – eivät yksilön – vastuulla. Tämä lisää vaihtoehtoja, ketteryyttä ja joustavuutta eri tavoitteiden toteuttamisessa.

Tarina: Monta asiakasta ja pieni ti imi

Eräs kuuden hengen kiinteä tiimi toteutti verkkopalveluita suurelle joukolle asiakkaita. Tiimin työt koostuivat uusista projektimuo-toisista toteutuksista sekä olemassa olevan ohjelmiston ylläpidosta. Tiimi oli toiminut

menestyksellisesti pitkään. Kaikkien asiak-kaiden aktivoituessa samaan aikaan seurasi kuitenkin tilanne, jossa tiimille kasautui mer-kittävästi enemmän töitä kuin mistä se pystyi suoriutumaan. Asiakkaat olivat tyytymättö-miä myös toimitettujen töiden laatuun. Tiimi-läiset stressaantuivat ja tekivät pitkiä päiviä. Kaikki pyrkivät mahdollisuuksien mukaan tekemään mahdollisimman monia tehtäviä. Tästä huolimatta – tai ehkä juuri tämän takia – tiimin taloudellinen tuottavuus laski mer-kittävästi. Tilanne kävi lopulta kestämättö-mäksi sekä ihmisten että yrityksen kannalta.

Ratkaisua tiimin tilanteeseen haettiin erilai-sista ketteristä työkaluista, kuten scrumista. Käytännössä scrumin käyttäminen oli kuiten-kin mahdotonta töiden pienen koon tai niiden prosessiluonteen takia. Lopulta toimivaksi ratkaisuksi osoittautui kanban-menetelmän käyttöönotto. Menetelmä koulutettiin tiimil-le. Tämän jälkeen samaan aikaan aktiivisena olevien töiden määrää rajoitettiin asettamalla tiimille samanaikaisten töiden maksimiraja (Work-in-Progress Limit; WIP). Uusia töitä ei saanut ottaa ennen kuin jokin vanhoista oli saatu valmiiksi. Rajana käytettiin noin kahta–kolmea käynnissä olevaa asiaa per tiimin jä-sen. Lisäksi tiimille kohdistuvien uusien toi-minnallisuuksien myynti kiellettiin (tiettyjä avainasiakkaita lukuun ottamatta) varsin pitkäksi ajaksi.

Kanbanin käyttöönoton alkuvaiheessa tiimi teki kaiken työnsä näkyvämmäksi itselleen ja muille. Tässä käytettiin apuna tiimin huo-neessa olevalla valkotaululle tehtyä kanban-seinää. Kaikkien tietoteknisten välineiden käyttöä töiden kuvaamisessa vähennettiin merkittävästi. Tällä pyrittiin siihen, että kaik-ki työt olisivat varmasti kuvattu yhdessä ja samassa näkymässä. Samaan aikaan käynnissä oleville töille määritettiin uimaradat, joista osa nimettiin tiettyjen tärkeiden asiakkuuksien mukaan. Ylläpitotyöt olivat mukana samalla seinällä.

Kanban-taulu teki työn näkyväksi. Tämän jälkeen tiimin oli mahdollista ottaa sisään lisää töitä vasta, kun tiimi oli saanut yhden työn varmasti valmiiksi. Tiimissä koettiin välillä suurta kiusausta hyväksyä aikaisem-man mallin mukaisesti enemmän työtä tilan-teissa, joissa osa töistä jäi jostakin syystä ju-miin. Kiinteä WIP-raja pakotti kuitenkin siihen, että jokin töistä oli saatava ensin pois

alta ennen kuin seuraava tehtävä voitiin ottaa työn alle.

Kanbanissa jokaiselle vaiheelle oli sovittu tiimin kesken valmiin työn määritelmä (Defi-nition of Done; DoD). Määritelmän täytyttyä työn sai siirtää seuraavaan vaiheeseen. Tiimi koki suuria vaikeuksia noudattaa itse luomi-aan sääntöjä. Vähitellen määritykset alkoivat kuitenkin vaikuttaa toimintaan, minkä seura-uksena tiimin työn laatu ja sujuvuus paranivat selkeästi. Myös asiakkaat huomasivat tämän.

Lopulta tiimin kautta kulkeva työvirta saatiin toimimaan siten, että tiimi pystyi vetämään itselleen töitä juuri sen verran kuin se pystyi laadukkaasti suorittamaan. Myöhemmin tiimi hajautui useaan toimipisteeseen. Kanban-näkymä siirrettiin samassa yhteydessä valko-taululta tehtävänhallintajärjestelmään. Töiden ohjaus toimi kuitenkin edelleen samoilla peri-aatteilla, minkä ansiosta tiimi pystyi pitämään asiakkaat tyytyväisinä ja tekemään töitä stres-saantumatta.

Tarina: Aloitteleva tiimi

Ketterää tuotekehitystä aloitteleva uusi scrum-tiimi ryhtyi kompleksisen ison uuden tuotteen kehitysprojektiin. Ketterä tuotekehi-tys oli lähes kaikille uutta eikä tiimi ollut vielä työskennellyt yhdessä. Uutta oli myös se, että tuote kehitettiin, integroitiin, testattiin aina valmiin tuotteen tuotantoon asti. Aikaisem-min oli ollut tapana, että toiminnallisuuksil-taan valmis tuote luovutettiin integroinnista vastaavalle tiimille integroitavaksi. Tiimin opetteli tuotteen tuotantoon asti vientiä te-kemällä pienen ”valmiin” tuoteversion ennen kuin varsinainen tuotekehitys alkaa. Tiimi lisäsi yhteiseen Definition of Done -listaan tarvittavat uudet säännöt.

Tarina: Tiimiytyminen alkaa alusta, kun tiimin kokoonpano vaihtuu

Eräs toimiva scrum-tiimi hajotettiin ja entisen tiimin pohjalta muodostettiin kaksi uutta tiimiä. Kumpaankin tiimiin otettiin mukaan myös uusia jäseniä. Edellisen tiimin hyväksi havaitut toimintatavat, mm. yhdessä sovitut Definition of Done käytännöt otettiin uuden tiimin käyttöön. Tiimissä oli muutama jäsen,

joiden mielestä perinteinen vesiputousmallin mukainen toimintatapa olisi ollut miellyttä-vämpi. Päivittäinen edellisenä päivänä tehty-jen töiden listaus ja samana päivänä tehtävien töiden luetteleminen tietotaululle koettiin turhaksi. Monet asiat haittasivat työntekoa, ja ryhmätyö oli tuskaista. Käytännössä tiimi teki vesiputousmallin mukaista tuotekehitystä pienessä mittakaavassa.

Ryhmätyötä tutkineiden tutkijoiden mukaan tiimin on käytävä läpi erilaisia tiimiytymisen vaiheita ennen kuin tiimi voi alkaa työsken-nellä tehokkaasti yhdessä. Käyttäytymistietei-lijä Bruce Tuckmanin luokittelun mukaan vaiheet ovat englanniksi Forming, Storming, Norming ja Performing (vapaasti suomennet-tuna: tiimin muotoutuminen, kyseenalaista-minen, sääntöjen vakiintuminen ja menestyk-sekäs toiminta). Ensi kertaa yhdessä uudella menetelmällä toimivassa tiimissä Norming-vaihe korostuu. On käytettävä yhdessä aikaa yhteisten käytäntöjen sopimiseksi, joiden perusteella työtä tehdään. Erityisen tärkeää on sopia yhdessä jokaisen tiimiläisen tehtävään liittyvä valmiin työn määritelmä (Definition of Done) sekä yhteiset laatukriteerit, joihin tii-min kaikki jäsenet sitoutuvat. Yhteiset peli-säännöt on syytä kirjata seinälle tai muuhun kaikkien saatavilla olevaan välineeseen. Silloin pelisääntöihin on helppo palata työn aikana. Kehitystyön aikana tulee väistämättä vastaan tilanteita, joissa tiimin jäsenet joutuvat arvi-oimaan työtään yhdessä sovittuja sääntöjä vasten.

Tarina: Scrum Master ryhtyy projektipää l-liköksi

Eräässä projektissa Scrum Master päätti oma-toimisesti olla tiiminsä projektipäällikkö. Hän laati projektisuunnitelman ja alkoi seurata tiimiläisten työajan käyttöä. Projektisuunni-telmassa todettiin, että projektin hallinnassa käytetään scrumia. Tiimi oli ihan tyytyväinen, koska joku osoitti heille töitä. Tiimin jäsenten ei tarvinnut kantaa vastuuta tehtävien valin-nasta, jäsentämisestä eikä oikeastaan täysi-määräisesti niiden tekemisestäkään.

Kun tiimin toimintatapaan puututtiin, kaikki olivat hämillään. Tiimissä luettiin yhdessä scrum-opasta ja pohdittiin, että ”miten tässä nyt näin kävi”. Scrum Masterin käsitys oman roolinsa tehtäväkentästä oli jäänyt epäselväk-

si. Hän oivalsi, että oli ollut paljon helpompi jatkaa tutummassa ja paremmin ohjeistetussa projektipäällikön roolissa ja jakaa töitä tietyil-le tekijöille. Tiimiläiset eivät selvästikään ol-leet riittävän oma-aloitteellisia toimiakseen muutosvoimana. He eivät oikeastaan olleet halukkaita ottamaan vastuuta muusta kuin oman osaamisensa ja itselleen varaamansa asiantuntijuuden mukaisista tehtävistä. Töi-den tekeminen yhdessä jonkun toisen kanssa tuntui vieraalta. Tiimiläiset eivät halunneet, että heidän koodiinsa kajoaisi tai sitä kom-mentoisi joku muu. He eivät halunneet näyt-tää omaa työtään ennen kuin se oli heidän mielestään varmasti valmis.

Tilannetta ryhdyttiin korjaamaan. Projektin ohjausryhmä jakoi tehtävät uudelleen. Nimi-tettiin projektipäällikkö, jolle keskitettiin projektin ne tehtävät, jotka eivät liittyneet tuotteen valmistamiseen. Scrum Master alkoi harjoitella valmentajatyyppistä asennoitumis-ta ja opasti tiimiä silloin, kun se poikkesi scrumin periaatteista ja käytännöistä. Toisin sanoen, hän alkoi toimia juuri, kuten Scrum Masterin tuleekin toimia. Kehitystiimi koetti parhaansa mukaan pitäytyä päiväpalavereissa sovituissa tehtävissä, mutta havaitsi useasti rönsyilevänsä muihin asioihin. Sprinttien ede-tessä tiimi tajusi, kuinka ankara menetelmä scrum oli verrattuna aiempaan projektin suo-ritusvaiheisiin perustuvaan tapaan toimia. Projektiryhmänä toimiminen oli ollut erilaista. Muutos teki kipeää.

Tarinan opetus: Kun tiimi aloittaa scrumin käytön, se tarvitsee tukea scrumia jo käyttä-neiltä ihmisiltä. Silloin tiimi mukautuu nope-ammin toivottuun toimintatapaan. Hanki tästä syystä kokenut Agile Coach, joka voi osoittaa tiimille ja Scrum Masterille, kuinka on paras toimia.

Tarina: Kehitystiimin johtaminen

Eräässä organisaatiossa yhdistettiin esimiehen ja Scrum Masterin roolit rooliin. Yhdistelmän oletettiin näppärästi säästävän palkkakuluis-sa, mutta myöhemmin kävi ilmi, että roolit ovat konfliktissa.

Scrum Master roolin etu perustuu tasaveroi-seen valmentamiseen eli johtamiseen ilman käskemistä. Tiimin esimiehellä on valtaa tii-miläistensä tekemiseen. Historiallisista syistä

moni organisaation työntekijä myös odotti esimiehen olevan asiantuntija alaistensa teh-tävissä ja kykenevän määräämään tehtäviä – tai ainakin neuvomaan, miten työt tulee tehdä. Asiantuntijaorganisaation laaja-alaisessa tii-missä tämä oli kuitenkin käytännössä mahdo-tonta. Kuinka neuvoa alansa parhaita, varsin-kin, kun kaikilla heistä on omat erityisosaami-sensa ja jopa täysin erilaiset työnkuvat?

Toimittuani pari vuotta eräässä tiimissä Scrum Masterina minusta tuli lisäksi kyseisen tiimin esimies. Uskoin – ja uskon edelleen – että Scrum Masterilla on esimiestä paremmat lähtökohdat kehittää tiimin näkemystä, toi-mintaa, itseohjautuvuutta ja yhteistyötä. Yri-tin tietoisesti pysyä samoissa toimintatavois-sa, eli käyttää esimiehenä mahdollisimman vähän auktoriteettia ja antaa tiimin päättää asioistaan mahdollisimman suurelta osalta. Esimerkiksi tehdessäni arvioita alaisistani kehityskeskustelussa tukeuduin vahvasti tii-miläisten itsensä ja sidosryhmien antamaan palautteeseen ja esitin oman näkemykseni vain osana kokonaisuutta. Tiimin toimintata-voista päätettiin edelleen yhteisesti. Tämä tapahtui useimmiten retrospektiiveissä siten, että itse toimin fasilitoijan roolissa. Edistystä saavutettiin edelleen, mutta koin, että tehtävä vaikeutui huomattavasti. Suora lainaus tiimin toimintatavoista käydyn keskustelun katkais-seesta tokaisusta kiteyttää tilanteen: "You’re the manager, you could just tell us”.

Myöhemmin olen päätynyt esimieheksi tii-meille, joita en ole tuntenut entuudestaan. Tavoitteeni on ollut sama, eli rakentaa tiimei-hin itseohjautuvuutta, luottamusta ja itsetun-toa valmentavaa johtamistapaa käyttäen. Ikä-vä sanoa, mutta en ole kokenut onnistuneeni näissä tehtävissä yhtä hyvin kuin Scrum Mas-terina. Tasavertaisen luottamuksen puuttues-sa olen kokenut, että huonon arvioinnin pelko estää tiimiläisiä puhumasta suoraan ongelmis-ta. Tämä puolestaan estää tiimin kehittymisen toivottuun suuntaan.

Tarina: Omat roolit

Erään vuosia tiimiesimiehenä, Scrum Masteri-na ja Scrum Mastereiden kompetenssiesimie-henä toimineen henkilön mielestä tähän men-nessä paras vaihtoehto on ollut organisaatio, jossa jokaisessa tiimissä on päätoiminen

Scrum Master, ja tiimiläisten esimiestehtävät hoitaa linja- tai kompetenssiesimies.

Mallissa kaikkien tiimien kaikilla ohjelmoijilla on yhteinen kompetenssiesimies, samoin laa-tuinsinööreillä ja Scrum Mastereilla. Kompe-tenssiesimiehen ensisijainen tehtävä on kehit-tää alaistensa henkilökohtaista ammattitaitoa. Scrum Master saa silloin toimia lähellä tiimiä, ja esimiehen tehtävä on tarkoituksella rajattu kauemmaksi jokapäiväisestä työstä.

Tarina: Fasilitoinnin ihanuudesta

Scrum Mastereita rekrytoidessani olen usein pyytänyt haastateltavia kertomaan, mitä on fasilitointi. Harva on pystynyt määrittelemään termin selkeästi; osa ei ole tuntenut sitä lain-kaan. Tämä on ollut yllättävää, koska Scrum Masterina ja muita Scrum Mastereita mento-roineena koen, että fasilitointi on Scrum Mas-terin tärkein ja monipuolisin työkalu.

Fasilitointi on tärkeää, koska se mahdollistaa koko tiimin osaamisen hyödyntämisen ja laa-jentamisen. Samalla se lisää tiimin itseohjau-tuvuutta sekä parantaa itseluottamusta ja valmiutta tarttua monenlaisiin tehtäviin ja ongelmiin. Parhaimmillaan koko tiimi toimii toistensa valmentajana ilman ulkoista ohjaus-ta.

”Fasilitointi tarkoittaa ryhmäprosessien

suunnittelua ja toteuttamista. Fasilitointi-sanan alkuperä on latinankielen sanassa 'fa-cil', joka tarkoittaa helppoa. Fasilitointi tar-koittaa suppeammassa merkityksessä koko-usten suunnittelua ja johtamista. Fasilitointi keskittyy rikastavan ja rakentavan yhteis-työn edellytysten luomiseen. Fasilitaattori 'opettaa kalastamaan', eli hän auttaa ihmisiä tekemään sen itse. Kun fasilitoiva johtaja johtaa ihmisiä ihmiset toteavat: 'me teimme sen itse!'”

Wikipedia

Käytännön kokemuksemme perusteella fasili-tointi on helpointa, kun fasilitoija ei itse edes tunne hyvin koko käsiteltävää asiaa. Vaikeinta taas on silloin, kun fasilitoijalla on vahva mie-lipide siitä, mihin lopputulokseen tiimin tulisi päätyä. Tarve osallistua asiantuntijana estää puolueettoman fasilitoinnin. Jos fasilitoija voi irrottautua kontekstista ja suhtautua kiihkot-

ta käsiteltävään aiheeseen, hän voi vaivatta keskittyä siihen, kuinka keskustelua käydään, edistytäänkö käsiteltävässä asiassa ja kuinka keskustelua voi tarvittaessa auttaa eteenpäin. Tästä johtuen on mielestäni huono ajatus, että Scrum Masterilla on tiimissä muitakin rooleja. Ainakaan hänellä ei tulisi olla laajoja asiantun-tijavastuita.

Käytännössä kokeneidenkin Scrum Masterien fasilitointitaito ja työkalupakin laajuus vaihte-levat suuresti. Vastaavasti moni tiimi ei ole koskaan kokenut, millaista esim. ongelman-ratkaisu voi olla tehokkaasti fasilitoituna. Potentiaalisen ongelman tiimin toiminnassa havaitessaan ideologiaa sisäistämätön Scrum Master kehittää ongelmaan ratkaisun itse ja keskittyy sen jälkeen myymään ratkaisunsa tiimille. Astetta ylemmän kehitystason Scrum Master esittää tiimille ongelman ja muutaman ratkaisuvaihtoehdon, joista tiimi valitsee. Hy-vä Scrum Master tuo ongelman tiimille ja aut-taa sitä löytämään ratkaisun itse. Erinomainen Scrum Master taas aloittaa kertomalla ha-vainnosta tiimille ja kysyy, onko tämä ongel-ma joka kannattaisi ratkaista. Vasta sitten hän etenee ratkaisun etsimiseen yhdessä. On iha-naa, kun tiimillä on hyvä fasilitoija!

HAJAUTETUT TIIMIT

Organisaation kasvaessa tiimejä joudutaan väistämättä rakentamaan hajautetusti. Suo-men mittakaavassa jo tuhannen ohjelmistoin-sinöörin toimistoa voi pitää valtavana.

Mikäli toisella paikkakunnalla työskentelee vain muutama henkilö, käytännössä on usein koettu parhaaksi integroida heidät pääkontto-rilla olevan tiimin käytäntöihin. Etäpaikka-kunnalla toimiville henkilöille tämä tarkoittaa usein sitä, että he joutuvat osallistumaan päi-vittäisiin scrum-palavereihin omalta kannal-taan epäedulliseen kellonaikaan. Yhteistyön edellytys on se, että sprintin tehtävälista on jaettu tietotekniikkaa käyttäen koko tiimille. Erilaiset sähköiset yhteydenpitokeinot hel-pottavat kommunikointia, samoin koko tiimin kesken yhdessä pidetty alkutapaaminen.

Mikäli toisella paikkakunnalla työskentelee useampia tiimiläisiä, toimivimmaksi ratkai-suksi on usein todettu se, että kummatkin paikkakunnat muodostavat oman scrum-tiiminsä. Näillä tiimeillä on yhteinen tuote-

omistaja ja yhteinen korkeamman tason jul-kaisusuunnittelu. Usein käytetään yhtä ja samaa tuotteen kehitysjonoa, toisinaan tii-meillä on erilliset kehitysjonot.

Erikoisosaamista vaativissa tapauksissa on syntynyt käytännön kokemusta myös tiimeis-tä, joissa kaikki tiimin jäsenet ovat kukin omalla paikkakunnallaan. Yllättävää kyllä, jopa tällaisissa tiimeissä scrum on saatu toi-mimaan hyvin. Tällöin tiimi on pitänyt sään-nöllisesti virtuaalisia retrospektiivejä, suun-nittelupalavereja ja päivittäispalavereja. Tii-min jäsenet ovat myös viihtyneet tiimissä ja pystyneet jakamaan kokemustaan toistensa kesken. Tällainen ratkaisu on vaatinut kaikil-ta tiimin jäseniltä sitoutumista sekä itse tuot-teeseen että tiimiin. Välttämättömäksi on havaittu myös johdon tuki tällaiselle työsken-telylle.

Hajautettujen tiimien tiimiytymistä on käy-tännössä edesauttanut mahdollisimman usein tapahtuvat tapaamiset kasvotusten. Alkuvai-heessa muutama yhteinen, toisinaan jopa vii-kon mittainen työpaja on välttämätön tiimiy-tymisprosessin käynnistämiseksi. Tämänkin jälkeen on hyvä pitää yhteisiä työpajoja vähin-tään muutaman kerran vuodessa. Työpajoissa voidaan esimerkiksi opetella uusia menetelmiä tai pohtia tuotteen tulevaisuuden visioita.

Käytännössä epäonnistuneeksi tavaksi jakaa työtä on toistuvasti todettu ratkaisu, jossa tiimin Scrum Master tai tuoteomistaja on yksinään toisella paikkakunnalla. Työskente-lyn onnistuminen on vaarassa myös, mikäli tuotteen kehitysjono peitetään (tiedon salaus-syistä tai muista syistä) joko osittain tai ko-konaan näkyvistä joiltakuilta tiimin jäseniltä. Hajautetut tiimit vaativat erityisesti Scrum Masterilta ja tuoteomistajalta aktiivista otet-ta, ulospäin suuntautumista ja tehokasta kommunikointia. Usein myös käyttöliittymä-suunnittelijalta ja arkkitehdeiltä vaaditaan joustoa ja aktiivista oma-aloitteista kommu-nikointia.

Erään kyselytutkimuksen pohjalta havaittiin, että hajautetut tiimit kokivat ketterien käy-täntöjen parantaneen tuottavuutta keskimää-rin enemmän kuin samalla paikkakunnalla toimivat tiimit. Kyselyn avovastauksina saa-duista kommenteista pääteltiin tämän johtu-van lisääntyneestä kommunikaatiosta. Aktii-visempi kommunikaatio paransi käsitystä

siitä, millaista tuotetta ollaan yhdessä raken-tamassa. Samalla kasvoi myös työntekijöiden työmotivaatio.

Vaikka kyselytutkimuksessa todettiin kom-munikaation ja tuottavuuden parantuneen hajautetuissa tiimeissä, lähes kaikki ihmiset toivoivat tästä huolimatta, että he voisivat työskennellä samalla paikkakunnalla. Alistair Cockburn (2002) on julkaissut tutkimuksen eri kommunikaatiotapojen ja kommunikaati-on tehokkuuden suhteista (Kuva ???). Tehok-kain tilanne on, kun kaksi henkilöä keskuste-lee valkotaulun äärellä. Tällöin sanallista in-formaatiota voidaan tukea piirretyin kuvin ja näytetyin objektein ja visuaalista informaatio-ta sanoin.

Toinen esimerkki hajautetusta tekemisestä on yleinen isoissa organisaatioissa. Kukin tiimi voi olla keskitetysti samalla paikkakunnalla, mutta työskentely tai projekti itsessään on hajautettu useammalle paikkakunnalle. Tässä avuksi tulevat ylemmän tason toiminnalli-suuksien työjono (feature backlog), siitä vas-taava tuoteomistaja sekä hänen tekemänsä ominaisuuksien priorisointi.

Tarina: Hajautettu kansainvälinen tiimi

Eräässä EU-hankkeessa oli tarve rakentaa ohjelmistoprototyyppejä ketterästi. Hank-keessa oli mukana yhden tiimin verran henki-löitä ja partnereita neljästä maasta. Töitä olisi siis tehtävä hajautettuna tiiminä (dispersed team), jossa osa jäsenistä työskenteli yksin omassa maassaan.

Havaittiin seuraavia ongelmia:

tiimin jäsenten osaamistasot vaihteli-vat

osa organisaatioista oli huonosti si-toutunut hankkeen tavoitteisiin

organisaatioilla oli ristiriitaisia piilo-agendoja ja

kulttuurierot haittasivat avointa kes-kustelua.

Projektin alusta asti läpinäkyvä toimintatapa oli tärkeää. Kunkin jäsenen tekemiset näkyi-vät versionhallinnassa, joka oli kytketty tiket-tijärjestelmään. Kaikki tehtävät työt hallittiin tiketteinä. Työt järjestettiin neljän viikon sprintteihin, joihin tekijät itse sitoutuivat. Commit-viesteissä vaadittiin ajankäyttörapor-tit ja tikettireferenssit, jotka käsiteltiin auto-maattisesti.

Projektin hallinto osoittautui ongelmalliseksi. Osa tekijöistä ei hallinnut teknistä alustaa, osalla ei ollut oman organisaationsa tukea ja osalle itse työ vain oli liian haastavaa. Alisuoriutuminen näkyi selvästi. Yksinkertai-sen 10 minuutin tiketin sulkemiseen meni tuntikausia. Heikko suoritustaso tulehdutti videokokousten keskustelut ja aiheesta tuli tabu, yhteisesti vaiettu asia.

Missä meni pieleen? Projektin aluksi olisi ai-nakin pitänyt täsmentää, miksi kukin organi-saatio oli projektissa mukana. Tämä olisi pois-tanut piiloagendat varsinaisen työn ajalta. Projektin tavoitteet olisi pitänyt linjata täs-mennysten mukaiseksi. Tällöin kukin organi-saatio olisi sitoutunut osallistumiseen ja tu-loksiin samalla tavalla. Projektihallinto mää-räsi välineet, alustat ja työmenetelmät, minkä vuoksi ristiriitaiset tavoitteet jäivät aiheutta-maan ongelmia koko monivuotisen projektin ajan.

KEHITYSJONO

Kehitysprojektissa on jollakin tavoin oltava tiedossa, mitä asioita ollaan kehittämässä ja missä järjestyksessä. Tässä kappaleessa tätä työtehtävien hallintaa kutsutaan scrum-maisella termillä tuotteen työjonoksi. Hallin-tamuoto voi olla millainen tahansa. Ketterän kehityksen sydän ei ole mikään tietynlainen lista, vaan ihmisten yhteistyö, tekemällä op-piminen ja tulosten mittaaminen. Erilaiset luettelot vain auttavat mieltämään, mitkä ovat työn tavoitteet ja vaiheet.

Tuotteen kehitysjono määrittelee, mitä teh-dään. Työjonon avulla toteutuksen moottori pysyy käynnissä. Jono voi saada monenlaisia muotoja, ja scrum-työskentelyssä se on erityi-sen vahvasti määritellyssä roolissa. Tuotteen kehitysjonossa pitäisi aina olla tekemättömiä töitä prioriteettijärjestyksessä. Jos kehitysjono on tyhjä, tuotekehitys pysähtyy. Jos taas kehi-tysjono kasvaa koko ajan, siitä voi tulla tuote-kehityksen pullonkaula.

Tyypillinen tilanne on sellainen, että yksi taho (yritysjohto tai tuoteomistaja) tietää, mitä tarvitaan. Toisaalla on toinen taho (kehitys-tiimi), joka tietää, kuinka tarvittavia asioita tehdään. Tuotteen kehitysjono on priorisoitu lista ominaisuuksia toimeksiantoja, jotka läh-tökohtaisesti voidaan toimittaa kukin erik-seen. Ominaisuudet voidaan järjestää liike-toiminnan prioriteettien pohjalta. Järjestystä voidaan muuttaa sovittujen pelisääntöjen mukaisesti. Kesken olevien asioiden muutta-mista vältetään aktiivisesti.

Tuotteen kehitysjonon kohdat (ominaisuu-det) ovat tuoteomistajan määrittelemässä tärkeysjärjestyksessä. Kehitysjonon kohdat eivät yleensä ole suoraan sellaisenaan valmiita sprinttien tehtävälistoille otettavaksi. Kohtia pitää työstää toisinaan paljonkin, ennen kuin työtehtäviä voidaan alkaa suunnitella. Yhdestä tuotteen kehitysjonon kohdasta voi poikia useita työstettäviä käyttäjätarinoita.

Uuden kehitysjonon kohdan työstämiseen osallistuu aina sekä tuoteomistaja että tiimi. Työstämiseen voi osallistua myös käytettä-vyyssuunnittelijoita, arkkitehteja, tietoturva-asiantuntijoita yms. Aluksi on tärkeintä luoda tiimille ymmärrys siitä, miksi asia halutaan tehdä ja millaista lisäarvoa se tuottaa. Lisäar-voa voidaan käyttää myös kriteerinä sille, voi-ko työstäminen siirtyä seuraavaan vaiheeseen. Työstäminen voi päättyä tähän, mikäli tode-taan, ettei asian tekeminen tuota tarpeeksi lisäarvoa kenellekään. Kehitysjonoa on tar-peen työstää säännöllisesti. Jonon työstämi-seen tulisi käyttää vähintään viisi prosenttia kulloisenkin sprintin työajasta. Kehitysjonon työstämistilaisuuksia kutsutaankin englan-niksi nimellä 5% workshop.

Kun yhteinen ymmärrys tietyn kehitysjonossa olevan ominaisuuden tuottamasta lisäarvosta on saavutettu, kohta pyritään jakamaan pie-nempiin käyttäjätarinoihin. Hyvä käyttäjäta-rina on yksinkertainen, tarpeeksi suppea ja keskittyy loppukäyttäjään. Käyttäjätarinassa pitää olla määritellä

1. käyttäjä (rooli – kotikäyttäjä, yritys-käyttäjä, ylläpitäjä, markkinoija…)

2. toiminnallisuus, jota ollaan toteutta-massa

3. lisäarvo – mitä hyötyä käyttäjälle on toiminnallisuuden toteuttamisesta.

Jokaiselle käyttäjätarinalle määritellään myös hyväksymisperusteet. Ne tulee määritellä siten, että tiimi tietää yksiselitteisesti, milloin käyttäjätarina on valmis. Hyväksymisperus-teet voidaan kirjata käyttötapauksina. Tällöin hyväksymisperusteista saadaan helposti myös johdettua testitapauksia. On syytä pohtia, kuinka paljon dokumentaatiota käyttäjätari-naan kannattaa sisällyttää. Tarinan kirjaami-nen wiki-dokumenttiin voi olla toimivin rat-kaisu. Ideaalitapauksessa tiimi toteuttaa testi-automaation hyväksymisperusteiden pohjalta jo ennen kuin käyttäjätarinan toiminnallisuu-den toteutus on valmis. Tällöin voidaan todeta tarinan olevan valmis, kun ohjelmisto läpäisee automaattiset hyväksymistestit. Hyvä hyväk-symisperuste on täsmällinen, yksityiskohtai-nen ja mitattava.

Käyttäjätarina ei tässä vaiheessa kuitenkaan ole vielä valmis sprintin tehtävälistalle otetta-vaksi. Seuraavassa vaiheessa tiimi – yhdessä tuoteomistajan sekä mahdollisten asiantunti-joiden kanssa pyrkii löytämään ulkoisia riip-puvuuksia, jotka saattavat vaikeuttaa käyttä-jätarinan toteuttamista. Tällaisia voivat olla esimerkiksi

riippuvuus jonkun toisen tiimin to-teuttamasta toiminnallisuudesta

erikoisosaaminen, jota tiimillä ei ole

jokin muu tiimin ulkopuolelta tarvit-tava asia.

Mikäli ulkoisia riippuvuuksia löydetään, ne dokumentoidaan ja otetaan huomioon käyttä-jätarinan toteutusarviota tehdessä.

Tässä vaiheessa käyttäjätarina on valmis to-teutusarviota varten. Yksi menetelmä toteu-tusarvion tekemiseksi on niin sanottu suun-nittelupokeri (planning poker). Siinä jokaisel-la tiimin jäsenellä on pakka kortteja, joissa on (yleensä) numerot 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 ja 100. Eri tiimeillä numerot voivat tarkoittaa eri asioita, jotka johdetaan tiimin suorituskyvys-tä. Lisäksi voidaan käyttää erikoiskortteja (kuten kysymysmerkki tai kahvikuppi). Arvi-oinnissa jokainen tiimiläinen nostaa esiin yh-

den kortin, joka kuvaa hänen omaa arviotaan käyttäjätarinan toteutuksen työläydestä. Mi-käli arviot eivät osu yksiin, seuraa keskustelua ja mahdollisesti uusi arviointi. Näin jatketaan, kunnes saadaan aikaan yhteisymmärrys käyt-täjätarinan vaativuudesta.

Kun käyttäjätarinan toteutusarvio on tehty, se on valmis otettavaksi tiimin seuraavan sprin-tin tehtävälistalle. Sprintin suunnittelupalave-rissa tiimi jakaa käyttäjätarinan vielä pienem-piin tehtäviin.

On havaittu hyväksi käytännöksi määritellä yhdessä tiimin ja tuoteomistajan kanssa, mit-kä asiat pitää olla tehtyinä (valmiin määritel-mä, Definition of Ready), ennen kuin tiimi voi ottaa kehitysjonon kohdan tai käyttäjätarinan työstettäväksi. Tuotteen kehitysjonon kohdan valmiin määritelmä kannattaa myös kirjoittaa paperille ja teipata vaikkapa tiimihuoneen seinälle.

Yksittäisen tuotteen parissa työskentelevä yksittäinen tiimi hoitaa tuotteen työjonoaan syöttämällä eritasoisia asioita tehtävienhallin-taohjelmistoon ja ottamalla niitä työn alle prioriteettijärjestyksessä. Suurimpia haasteita on ollut sen vakiinnuttamisessa, mitä on kir-jattava muistiin ja missä vaiheessa. Tässä voi olla avuksi ollut 3xC-periaatteen muistami-nen. Ensin kirjoitetaan muistiin ihan vain jotakin keskustelun tueksi (Card). Ennen toteutusta on tärkeää keskustella, tarkentaa tavoitetta, ymmärtää, mitä tavoitteella tarkoi-tetaan sekä miettiä tarvittavan ratkaisun laa-juutta niin, että toteutetaan pienin ja yksin-kertaisin mahdollinen asia (Conversation). Keskustelu on hyvä kirjata jollakin tasolla ylös myös johtopäätösten osalta (Confirmation). Asiakkailla on nimittäin taipumus muuttaa mieltä, kun he unohtavat, mitä on sovittu. Tätä kummempia järjestelyjä ei välttämättä ole tarpeen pystyttää.

ESISELVITYS ENNEN TUOTTEEN KE-HITYSJONOON PÄÄSYÄ

Käynnistettävän projektin koko vaikuttaa siihen, paljonko ideoita esiselvitetään ennen kuin ne tuodaan tuotteen kehitysjonoon. Suu-rissa projekteissa käytetään useita alustavia listoja ja niihin liittyviä selvityksiä, kun taas pienissä projekteissa ideat saatetaan laittaa listalle saman tien.

Selvittelyssä on hyvä muistaa varastoa (inven-tory) koskeva lean-periaate. Varaston käsitte-ly maksaa. Jos moni ihminen käsittelee varas-toa, se maksaa vielä enemmän. Kustannukset muodostuvat työajasta. Lisäksi tässä tapauk-sessa hintaa saatetaan joutua maksamaan motivaatiokatona, kun työntekijät miettivät ”eikö mikään koskaan riitä”.

Toisinaan voi olla vaikeuksia päättää, mikä on ensisijainen, julkaisusuunnitelma, joka kertoo korkean tason julkaisuihin tulevista tuote-ominaisuuksista, vai tuotteen työjono, joka kertoo ominaisuuksien tekemisjärjestyksen. Molemmilla työstetään lupauksia. Julkaisu-suunnitelma on usein suunnattu enemmän kehitystiimistä ulospäin ja työjono enemmän sisäänpäin, kehitystiimille itselleen. Näiden kahden yhteensovittaminen vaatii jatkuvaa työtä, ja molempien näiden kuvausten viestin-tävoimaa tarvitaan. Viime kädessä työn ete-nemistä ohjaa tiimikoko ja tiimin kyky edistää asioita. Hyvistä periaatteista (sustainable pace, tasainen ylläpidettävissä oleva tahti) huolimatta usein voi käydä niin, että tärkeitä luvattuja ominaisuuksia pusketaan väsyneenä vasten määräaikaa.

TUOTTEEN KEHITYSJONON LAATIMI-NEN

Kehitysjonot voivat olla muodoiltaan monen-laisia. Toiset vannovat tarinapohjaisten työ-jonojen nimiin, eli haluavat kirjoittaa sekä isoja (epic) että pienempiä tarinoita (story). Toiset taas näkevät olennaisena lähinnä sen, että listan alkiot ovat riittävän pieniä nopeasti toimitettaviksi. Myös alkiot voivat olla mo-nenlaisia, esim. käyttötapauksien skenaarioi-den askelia, käyttöliittymän ruutuja, paksun yksityiskohtaisen määrittelyn kappaleita. Työjono on viime kädessä tehtävien asioiden lista. Listalle voidaan laittaa juuri sellaisia asioita kuin kussakin tilanteessa on tarpeen.

Jatkuvassa tuotekehityksessä on hyvä laatia julkaisusuunnitelma, jossa ominaisuuksien kehitystyötä voidaan suunnitella pitkällä ai-kajaksolla. Tällöin kyseisen julkaisun uusien ominaisuuksien voidaan ajatella muodostavan teemoja. Teemoja on helppo työstää markki-noinnin näkökulmasta. Tiettyyn teemaan liittyvät käyttäjätarinat voidaan siirtää omaan julkaisukohtaiseen kehitysjonoonsa. Toisaalta

ne voidaan tarvittaessa sijoittaa kehitysjonon hännille, mikä saattaa helpottaa lähimmän julkaisun kehitysjonon suunnittelua. Julkai-sukohtaisessa kehitysjonossa on tietysti ole-massa vaara, että tarinoita joudutaan siirtele-mään useiden kehitysjonojen välillä, kun tilan-teet muuttuvat.

Tuotteen kehitysjonon laatimiseen voidaan käyttää erilaisia työkaluja alkaen paperikor-teista aina erikoistuneisiin ohjelmistoratkai-suihin, jotka tukevat vaiheittaista kehitysjo-non työstöä ja hyväksyntää.

Tuotteen kehitysjonon omistajuus ja varsinkin priorisointioikeus perustuu yleensä liiketoi-minnan vaatimuksiin. Se kuuluu siten luonte-vasti tuotehallinnolle, yritysjohdolle tai muul-le tällaiselle taholle. Tuotteen kehitysjonon ohjauksen valta voidaan kuitenkin hajauttaa. Tällöin on pystyttävä ratkaisemaan, kuinka suoritetaan valinta kehitysjonon useiden nä-kökulmien väliltä.

Tarina: Tuotteen kehitysjonon tehtävät eri yksiköistä

Eräässä organisaatiossa sovittiin, että tuote-kehitysyksiköllä on oikeus kohdistaa puolet tuotteen työjonon tehtävistä. Perusteluna oli se, että tuotteen elinkaaren omistajuus ja suunnittelu oli enemmän tuotekehitysyksikön kuin markkinointiyksikön vastuulla. Tuote-omistajaksi oli kuitenkin asetettu markki-noinnin edustaja. Tämä on tyypillistä silloin, kun liiketoiminnan johdossa painotetaan nä-kyviä nopeita ominaisuuksia teknisen velan ottamisen kustannuksella.

Tarina: Yksi esimerkki kokonaisuudesta

Tavoitteena oli saada monelle eri käyttäjä-ryhmälle yhteiseen käyttöön ohjelmisto, joka tukisi tärkeiden liiketoimintaprosessien suju-vaa toimintaa. Käyttäjäkuntaan kuului erilai-sia rooleja ja kansallisuuksia monesta eri yksi-köstä Osa käyttäjistä tunsi ketterät menetel-mät, osa ei. Lisäksi koko liiketoimintaprosessi oli muutosten kourissa, mikä aiheutti luonnol-lisesti painetta myös tietojärjestelmän kehit-tämiseen.

Jatkuvaan muutokseen oli varauduttu. Osal-taan sen vuoksi jäykän vesiputousmallin si-jaan valittiin ketterä työmalli. Tuotteen kehi-tysjono oli tyhjä. Ylätason visio, oikea tahtoti-la sekä käyttäjäkunta olivat olemassa. Tavoit-teena oli kehittää yhteinen ohjelmisto, josta kaikki sidosryhmät näkisivät helposti ja suo-raan omien projektiensa ja tehtäviensä tilan-teen. Enää ei kaikkien tarvitsisi käsitellä sa-maa tietoa päällekkäisesti eri Excel-taulukoissa ja sähköposteissa.

Vaihe 1: Vaatimusten keräily ja jäsen-täminen

Ennen kuin tuotteen kehitysjono oli saatu muodostettua, monesta suunnasta tuli hyviä ideoita vaihtelevilla tarkkuustasoilla. Osa ajatuksista lähetettiin sähköpostilla, osa kir-jattiin sovittuun ideatyökaluun ja osa tunnis-tettiin yhteisissä palavereissa, joissa mietittiin ohjelmiston eri osia ja kokonaisuutta. Saatuja ideoita pureskeltiin. Puntaroitiin, mitkä ide-oista pysyisivät alkuperäisen tehtävänannon piirissä ja parantaisivat alkuperäistä tavoiteti-laa. Tässä vaiheessa huomattiin, että vaati-muksia ei tullut tasaisesti jokaiselta käyttäjä-ryhmältä. Jotkut ryhmät pystyivät sitoutu-maan paremmin kuin toiset, jolloin aktiivisilta tuli myös eniten vaatimuksia. Ongelmana olivat toisaalta tulevat liiankin suuret vaati-mukset ja toisaalta liian vähäiset ja epämääräi-set. Tavoite oli kuitenkin tehdä kaikille sopiva ohjelmisto!

Ongelmaan mietittiin ratkaisuja ja parhaaksi ratkaisuksi arvioitiin, että tilanne selitettiin kaikille sidosryhmille. Sen jälkeen sovittiin yhdessä, mikä on tavoiteltava päälinja. Osa käyttäjistä suostui luopumaan vaatimuksis-taan tai vähintäänkin pienentämään niiden prioriteettia. Lopulta saatiin kokoon lista asioista, jotka lisättiin tuotteen kehitys-jonoon. Osa ideoista oli hyvin pureskeltuja, osa vaati lisää määrittelyjä ja osa piti yhdistel-lä tai jakaa pienemmiksi osiksi.

Vaihe 2: Alustavan tuotteen kehitysjo-non muodostaminen

Kun parhaat ideat oli esikäsitelty, päästiin tuotteen kehitysjonon laatimiseen. On syytä huomata, että kehitysjono elää koko kehittä-mistyön ajan, mutta selkeä kehitysjono on lähtötila, josta lähdetään eteenpäin. Alustavaa listaa jäsenneltiin lisää ja ominaisuudet pyrit-

tiin saamaan kehitysjonoon sillä tarkkuusta-solla, että ne olisivat valmiita toteutettaviksi – ja siis loppujen lopuksi myös testattaviksi. Lukuisat tehtävät paljastuivat liian suuriksi sprintin pituuteen nähden. Näitä tehtäviä alettiin jakaa useampaan sprinttiin. Kunkin yksittäisen tehtävän tarkoitus oli olla selkeä kokonaisuus, jonka tuotos pystytään testaa-maan erillisenä. Tässä kohtaa huomattiin haasteeksi, että määrittelyä ja dokumentaatio-ta tekeviä henkilöitä oli liian vähän. Oli luo-vuttava alkuperäisestä toiveesta saada koko kehitysjono täysin määritellyksi. Lähdettiin siis määrittelemään ensimmäiseksi vain kaik-kein tärkeimpiä asioita. Näin lopputuotteessa olisi tärkeimmät asiat ensimmäisenä valmiina. Aluksi valmistuisivat taustatoiminnot ja sen jälkeen liiketoimintaprosessin toiminnot vai-heiden loogisessa järjestyksessä.

Jos aikaa ja tekijöitä on liian vähän, niin vii-meistään silloin on valittava, mihin työpanos laitetaan. On arvioitava, missä työpanos edis-tää projektia eniten. Tuoteomistaja ja tiimi päättivät yhdessä, mitkä asiat tarvittiin kul-loinkin seuraavaksi. Nämä ominaisuudet mää-riteltiin sitten tarkemmin.

Tuotemäärittely dokumentoitiin käyttötapa-uksina. Käyttäjätarinoita käytettiin myös hahmottamaan tekemistä ja pitämään käyttä-jän tarpeet koko ajan tuoreena mielessä. Aluk-si tehtiin käyttöliittymä tarvittavilta osiltaan sekä muuta syvällisempää järjestelmän toi-minnan mallinnusta.

Vaihe 3: Tuotteen kehitysjonon toteuttami-nen ja jatkuva muutos

Myös sidosryhmät olivat jatkuvassa muutok-sessa. Kehityksen aikana huomattiin, että alkuperäisiin tehtävänkuvauksiin tarvittiin muutoksia. Nyt alettiin hyötyä siitä, että tär-keimmät tehtävät oli priorisoitu jo aiemmin. Tuotteen kehitysjonon keskeltä tai pohjalta poistuvat tehtävät olivat toteutusryhmälle helpotus. Kukaan ei joutunut murehtimaan turhaa työtä, koska listan alimmaksi priori-soiduille kohdille ei ollut vielä edes tehty mi-tään.

Jatkuvat muutokset kävivät raskaaksi. Ne aiheuttivat uuden vaatimusaallon. Uudet vaa-timukset menivät ristiin ja lomittain aikai-semmin keskusteltujen asioiden kanssa. Osa käyttäjäkunnasta ei edes ollut tietoinen näistä

asioista, koska myös sidosryhmien edustajat olivat vaihtuneet.

It’s all about communication. Huomattiin, että oli parasta ylläpitää jatkuvaa sidosryhmien välistä kommunikointia. Joidenkin kanssa tämä vaati palavereita, työpajoja, joidenkin kanssa riitti sähköpostikirjeenvaihto tai lyhy-et puhelut. Tuotteen kehitysjonosta asiat siir-rettiin valmisteltuina sprintin tehtävälistaan.

Projektin opetukset:

hyvä tuoteomistaja priorisoi sekä tun-teella että järjellä

asiakkaat tulee ottaa mukaan koko kehitystyön ajaksi

on tärkeää varmistaa jatkuvasti, että tehdään oikeita asioita ja

jatkuva muutos on hyväksyttävä.

Tarina: Esimerkkejä tuotteen kehitysjonon kohdista

Seuraavassa taulukossa on muutamia esi-merkkejä siitä, mitä kaikkea tuotteen työ-jonossa voi lukea (Taulukko 1).

Taulukko 1: Kehitysjonon kohtia

Kehitysjonon yksi kohta Konteksti ”Lisää pikahelppitoiminnallisuus tilauslomakkeelle” Yhdenkin rivin selitys riittää, koska samaa toiminnallisuut-

ta tehty muualle ja yhteinen ymmärrys asiasta on olemassa ”Managerin roolissa, haluan valita elementit järjestetystä listasta, jotta virheiden mahdollisuus vähenee.” (as a <role>, I want <stuff>, so that <business benefit>)

Tosielämässä jakautuu kolmeksi osatehtäväksi a) kyseisen näytön muuttaminen b) listatoiminnallisuuden lisääminen c) listan järjestäminen

Tuloksena uusi ja parannettu käyttötapaus jo olemassa olevalle toiminnolle – jotakin uutta, jotakin vanhaa.

”Lisää rooli X ohjelmistoon” Hyvinkin monimutkainen, ohjelmistoon kokonaisuutena vaikuttava muutos, joka on pilkottava ja analysoitava perusteellisesti yhdessä tiimin kanssa. Huomioitavaa mm.

a) käyttöliittymää, ja sen kenttiin b) muutoksen vaikutukset taustatoimintoihin c) muutoksen vaikutukset käyttäjäoikeuksiin d) olemassa olevan datan konvertointi e) …

TUOTTEEN KEHITYSJONON TYÖSTÄ-MINEN

Tuotteen kehitysjonon työstämisen (re-finement) lähtökohta on se, että liiketoimin-taosasto ei yksin pysty määrittelemään tuot-teen kehitysjonoa sellaiseen muotoon, että useat kehitystiimit voivat tehokkaasti ottaa töitä toteutukseen.

Tarina: Yhteisen ymmärryksen sijainti

Eräässä projektissa tuotteen kehitysjonoon kirjattiin erilaisia ideoita. Niitä pyrittiin sitten kehittämään erillisissä dokumenteissa, joista osa oli laadittu liikkeenjohdon tarpeisiin, osa käyttöliittymän määrittelyä varten ja osa kon-septointia tukemaan. Työ pyrittiin saatta-maan sille tasolle, että sen pohjalta voitaisiin lähteä suunnittelemaan sprinttejä.

Eri lähtökohdista ja eri käyttötarkoituksiin tehdyt dokumentit olivat kuitenkin tulkin-nanvaraisia ja sprintin alkaessa usein jo osit-tain vanhentuneita. Suunnittelun alussa suunnittelijat ja testaajat joutuivat tekemään tulkintoja ja vetämään osittain arveluun pe-rustuvia johtopäätöksiä. Käyttäjätarinoita muokattiin, pilkottiin ja kirjoitettiin uudel-leen. Itse dokumentaatiota hajautettiin käyt-täjätarinoihin, sprintin tehtäviin ja testitapa-uksiin sen mukaan, työstikö dokumentaatiota koodaaja vai testaaja. Lopputulema tästä oli se, että dokumentaatiota syntyi paljon, mo-neen eri paikkaan ja siinä oli paljon päällek-käisyyksiä.

Ongelma ratkaistiin sillä, että dokumentointi siirrettiin wiki-järjestelmään. Wiki-dokumentaatioon laadittiin käyttäjätarinoi-den kuvauksia standardoidun käyttötapaus-mallin mukaan. Näin dokumenttien teko ja ylläpito oli jatkuvaa. Käyttötapaukset toimi-vat yksikäsitteisenä toteutuksen ja testausdo-

kumentaation lähdemateriaalina. Samalla voitiin myös keventää tuotteen kehitysjonon käyttäjätarinoita ja testitapauksia viittaamalla niissä suoraan asianomaiseen wiki-sivun koh-taan.

Tarina: Tehtävälistojen rytmitys

Eräässä laajassa client-server- tuotekehitys-projektissa tiimit jaettiin kehitettävän tekno-logian mukaisesti erillisiksi, scrum-ohjatuiksi client- ja server-tiimeiksi. Tiimit työskenteli-vät eri paikkakunnilla ja, kumpikin tiimi toimi oman tuoteomistajansa ohjauksessa.

Ajatuksena oli, että ominaisuuksia voidaan kehittää eri tiimeissä toisistaan riippumatta, eikä tekemisiä tarvitse synkronoida ajallisesti. Koko hankkeen kannalta oli tietysti edullista, että tehtäviä suunniteltaisiin ja seurattaisiin määrävälein. Niinpä käytännössä tiimit toimi-vat yhtä pitkissä (kahden viikon) jaksoissa. Sprintit oli lisäksi lomitettu niin, että toinen tiimi toimi parillisilla ja toinen parittomilla viikoilla. Näin ominaisuuksia voitiin kehittää suurin piirtein samaa tahtia. Usein kävi kui-tenkin niin, että tiimien työskentelynopeus oli erilainen. Toisaalta tiimit olivat riippuvaisia toistensa tuotoksista. Tämä johti siihen, että sprinttien lopussa ominaisuudet olivat usein rikki järjestelmätasolla tarkastellen. Toisin sanoen tiimien nopeusero muodostui ongel-maksi koko tuotteen kehittämisen kannalta.

Ongelman ratkaiseminen olisi vaatinut 1) yh-teisen tuoteomistajan, 2) yhteisen tuotteen kehitysjonon sekä 3) samaan aikaan pidetyt sprintit. Tällöin kummallakin tiimillä olisi ollut tarkka tieto siitä, mitä toinen tiimi tar-vitsee samaan aikaan. Näin olisi voitu varmis-taa tiimien sprinttijulkaisun yhteensopivuus yhteisen sprinttijakson lopussa. Yhteinen tuotteen kehitysjono olisi myös ollut helpom-pi hallita, koska se olisi sisältänyt vain koko tuotteen kannalta merkittäviä asioita.

Tarina: Aloittelevat scrummaajat

Eräässä tiimissä oli juuri siirrytty ketteriin menetelmiin. Yhdessä tekeminen eritaustais-ten asiantuntijoiden kesken ei aina ollut kovin suoraviivaista. Sprintin suunnittelussa pyyde-tyt asiat ositettiin tehtäviksi, jotka kohdistet-

tiin yksittäisille tekijöille. Kulttuurimuutok-sessa oli vielä monta askelta matkaa siihen, että ihmiset olisivat tarjoutuneet vapaaehtoi-sesti auttamaan naapuriaan. Vain sovitut, itselle osoitetut työt hoidettiin.

Tarina: Aina ei tarvita sprintin tehtäväli s-taa

Eräs web-kehitysporukka oli suoraviivaista-nut toimintatapaansa niin, että tehtäviä ei ositettu tuotteen työlistan jälkeen tehtäviksi. Sen sijaan porukka teki itseohjautuvasti teh-täviä tuotteen työlistan perusteella. Tämän työtavan mahdollistivat yhteinen ymmärrys valmiin määritelmästä sekä hyvähenkinen keskusteleva porukka, joka uskalsi ottaa apua vastaan toisiltaan.

ONGELMANA SCRUMMERFALL

Usein kuvitellaan, että kun sprintille laaditaan tehtävälista, niin kukin valittu tuoteominai-suus käy läpi joukon ohjelmistokehityksen vaiheita. Jokaisella tuoteominaisuudella olisi siis kohtalonaan vesiputousmallin vaihejaon mukainen työnkulku. Työnkulku sisältää kaikki tehtävät, joilla ominaisuus saadaan valmiiksi valmiin määritelmän (Definition of Done) mukaisesti.

Tämän vuoksi useissa projekteissa on synty-nyt työtapa, jossa vesiputous etenee viikoit-tain. Vaihtoehtoisesti kehitys etenee siten, että jokaisesta sprintistä tulee vesiputouksen vaihe. Töiden suunnittelun rituaalit noudatta-vat ketterien menetelmien muotoa, mutta eivät niiden henkeä. Tätä mallia kutsutaan tuttavallisesti nimellä Scrummerfall, vesipu-tousmalli toteutettuna scrum-inkrementtien sisälle. Tehtävälista tai tuotteen kehitysjono laaditaan vesiputousmaiseen tapaan: määritte-ly – suunnittelu – toteutus – testaus. Sen jäl-keen edetään scrum-menetelmän mukaan, jossa tehtävälistan tai kehitysjonon kohtaa ei saa merkitä tehdyksi, ennen kuin se täyttää valmiin määritelmän.

Scrummerfall-oireyhtymää voidaan ratkoa muuttamalla työtapoja rytmiltään sellaisiksi, että työt on mahdollista saada valmiiksi jat-kuvana töiden vuona. Viikkojen ei tule rytmit-tyä eri näkökulmille. Esimerkiksi testaus al-

kaa määrittelystä esimerkein, jatkuu koko kehityksen ajan testien automatisointina ja päättyy automatisoitujen testien täydentämi-seen tutkivalla testauksella.

MUUTOSHALLINTA

Ketterässä kehityksessä ei käytetä samanlais-ta muutoshallintaa kuin perinteisessä vesipu-tousmallissa. Kun toiminnallisuutta toimite-taan osa kerrallaan, tarpeiden muutokset ote-taan tuotteen työlistalle ja toteutetaan sovel-tuvan prioriteetin mukaisessa järjestyksessä. Jos muutoksia tulee paljon, kokonaisuuden ennustettavuus vaatii erityisesti huomiota.

Tarina: Eikös tämäkin ole jo kertaalleen tehty.. .

Eräässä projektissa oli haasteita ymmärtää, että ketterien menetelmien muutoshallinta on poikkeaa hengeltään hyvin paljon perinteises-tä tavasta. Asiakas muutti toistuvasti mieltään ja hyödynsi oikeuksiaan laittamalla asioita tuotteen työlistalle. Tiimi toteutti asioita kil-tisti asiakkaan kunkinhetkisen toiveen mu-kaisesti.

Puoli vuotta myöhemmin asiakas ihmetteli ääneen, minkä vuoksi hän oli saanut puolessa vuodessa niin vähän ominaisuuksia järjestel-mään. Kun listaa käytiin läpi, huomattiin, että kehitystiimissä tehtiin samoja asioita useaan kertaan. Näin projektissa ei päästy juuri lain-kaan eteenpäin. Tämä oli johtanut askel eteen, askel taakse syndroomaan.

Kokemuksesta opittiin kaksi asiaa. Ensinnä-kin on tärkeää tarkastella asioita myös yksit-täisen sprintin ulkopuolelta lisäarvon näkö-kulmasta eikä ainoastaan toimittaa sitä, mitä tilataan. Toiseksi on tärkeää panostaa työn alle otettavaan asiaan riittävästi, ettei sitä tarvitse tehdä moneen kertaan. Pieni keskus-telu kokonaisuuden tarpeesta olisi saattanut herättää asiakkaan aikaisemmin ymmärtä-mään ohjauksensa vaikutuksia.

PRIORISOINNIN JA SUUNNAN TÄRKE-YS

Kehitystiimi tekee asioita tuotteen kehitys-jonosta teoriassa järjestyksessä. Järjestyksen järkevyys ja onnistuneisuus varmistuu käy-tännössä parhaiten yhteistyöllä. Toisinaan vastuu järjestyksestä jää kokonaisuudessaan tuoteomistajan roolissa toimivalle asiakkaalle. Jos priorisoinnin perustana ei ole visiota siitä, mihin suuntaan tuotetta kehitetään, tai jos tiimi ei ole kovin aloitteellinen auttamaan, ei homma yleensä toimi kovin hyvin.

Tarina: Kauemmaskin tulisi kyetä suunni t-telemaan

Asiakas oli tietoinen toimialaansa kohdistu-vista suurista muutoksista, jotka tulisivat vaikuttamaan hänen sovellukseensa. Myös toimittaja oli tietoinen näistä muutoksista. Toimittaja ei kuitenkaan tiennyt kovin hyvin, kuinka sovellusta tulisi muuttaa niiden joh-dosta. Asiakkaalla ei ollut tarpeeksi aikaa viestiä kunnolla tarvittavia asioita.

Kehitystä tehtiin scrumilla, ja sprintteihin otettiin tehtäviä tuotteen kehitysjonosta. Uu-sia tarpeita ei kuitenkaan viety kehitysjonoon. Asiakkaaseen oltiin yhteydessä päivittäin, mutta kasvotusten tapaamisia oli vain muu-taman viikon välein. Muiden muutosten lisäk-si valmisteltiin integraatiota erääseen toiseen sovellukseen. Vikatilanteisiin ei varauduttu riittävän hyvin ja integraation testaus järjes-tettiin melko myöhäisessä vaiheessa.

Tärkeät asiakastarpeet saatiin selville aivan liian myöhään. Scrum muuttui lähemmäksi scrum-bania: scrum-tiimi alkoi käyttää kan-ban-taulua toiminnan ohjaamiseen. Toiminta-tavan muutosta perusteltiin seuraavilla sei-koilla: 1) kehitystiimillä oli nyt tiedossa tule-vat tehtävät, 2) odottamattomasti ilmaantu-neet tehtävät veivät noin puolet kehitystiimin ajasta ja 3) tiedossa olevien tehtävien työ-kuorma oli niin valtava, että sprinttien suun-nittelemisesta ja sprinttikatselmuksesta saa-tavat näkyvyys- ja viestintähyödyt eivät olleet riittävän suuria, jotta niillä olisi voinut perus-tella käytetyn työpanoksen.

Projektin käytettävissä olevia resursseja vä-hennettiin tässä vaiheessa alle puoleen. Pian

tämän jälkeen sovelluksen jakelua laajennet-tiin. Tämä johti useiden uusien ongelmien havaitsemiseen ja joidenkin ongelmien osalta myös niiden korjaamiseen. Useat uudet käyt-täjät alkoivat tutkia sovellusta, mikä johti yhä uusien ongelmien esille tuloon.

Integrointi toiseen järjestelmään vaati jatku-vaa seurantaa ja tutkimustyötä. Parempi va-rautuminen ja arkkitehtuurisuunnittelu olisi-vat voineet helpottaa tätä tehtävää. Osa kehit-täjistä, joiden tietämystä olisi kaivattu kipeäs-ti, oli tässä vaiheessa lomalla.

Vaaditut toimenpiteet saatiin arvioitua vasta muutama päivä ennen julkaisupäivää. Havait-tiin, että vaadittu työ tulisi viemään vielä usei-ta viikkoja. Sovellusta ei saatu toimimaan tarvittavalla tavalla määräpäivään mennessä. Toimialan muutosten vuoksi merkittävä osa jo tuotannossa olevan sovelluksen hyödystä me-netettiin ja loppukäyttäjien työskentely vai-keutui huomattavasti.

Toimittajan mielestä ongelma olisi voitu eh-käistä seuraavilla toimenpiteillä:

tulevien muutosten seurausten selvit-täminen aiemmin

sovelluksen tarkoituksen perinpohjai-sempi selvittäminen

tuotteen kehitysjonon parempi ylläpi-to

edellä mainittujen toimialamuutosten vaikutusten arviointi sovelluksen nä-kökulmasta

asiakkaan parempi sitouttaminen pro-jektiin

toimittajan aktiivisempi yhteydenpito asiakkaaseen, ”yhdessä tekemisen meininki”

tiedon jakaminen toimittajan oman ryhmän sisällä, jotta avainhenkilöiden lomat eivät olisi päässeet halvaannut-tamaan kaikkea työskentelyä (mu-kaan lukien dokumentointityö).

KEHITYSJONO JA TEKNINEN VELKA

Kun keskitytään toteuttamaan ominaisuuksia nopeasti tuotteen kehitysjonosta, voi kehitys-pohja rapautua laadullisesti. Tämä tekee jat-kokehityksestä yhä haastavampaa. Teknisen velan olemassaolo ilmenee usein regression

kasvuna. Tällä viitataan siihen, että jo toteu-tettuihin ominaisuuksiin ilmaantuu vikoja ja että vikojen korjaaminen aiheuttaa uusia viko-ja. Pahimmillaan vikojen määrä ei pienene, vaikka niitä kuinka korjattaisiin. Puhutaan teknisestä velasta. Termillä viitataan siihen, että kehitystyö on jatkuvasti kalliimpaa tek-nisten syiden vuoksi. Näitä syitä ovat mm. löytämättä jääneet ja korjaamatta jätetyt vir-heet.

Kun ohjelmistoa kehitetään nopeasti, ominai-suus kerrallaan, teknistä velkaa syntyy luon-nostaan. Tästä johtuva välttämätön uudelleen tekeminen (refaktorointi) on tunnustettava osaksi ketterän menetelmän hintaa. On hyvä kirjata nämä kustannukset ylös myös retro-spektiivissä vaikkapa kysymällä jokaiselta tiimijäseneltä: ”Mitä haluaisit tehdä toisin?”.

Pitkään ylläpidettävänä ollut koodi sisältää yleensä myös ns. kuollutta koodia. Kuollutta koodia syntyy, kun uusi toiminnallisuus ja viankorjaukset toteutetaan ohittamalla vanha koodi sitä kuitenkaan poistamatta. Tällöin varsinainen hyötykoodi voi olla heikosti erot-tuvaa ja siksi vaikeasti ylläpidettävää.

Erittäin huono ratkaisu on se, että kehityspro-jekti siirtää kaiken teknisen velan ylläpidon vastuulle toiseen organisaatioon. Mikäli kyse on alihankinnasta, teknisen velan määrää voi olla erittäin vaikea arvioida. Näin on etenkin silloin, kun tilaaja herää pohtimaan tätä näkö-kulmaa vasta toimituksen hyväksymisvaihees-sa.

Tarina: Velan maksu

Eräässä tuotekehitysorganisaatiossa havah-duttiin siihen, että hyvästä jatkuvan integ-roinnin järjestelmästä huolimatta tiimien tuottavuus oli varsin heikko. Alettiin keskus-tella syistä, ja arveltiin, että tekninen velka haittaa itse tekemistä. Keskustelun pohjalta päätettiin arvioida teknisen velan määrä. Ar-veltiin, että eräs tapa olisi mitata paljonko kuollutta koodia 20 vuoden aikana oli kerty-nyt. Tarkistettaisiin toisin sanoen, paljonko kehitetystä koodista oli oikeasti käytössä ja kuinka paljon ei.

Mittauksen tulos järkytti kaikkia, sillä vain viisi prosenttia kaikesta koodista oli käytössä tuotannossa. Havainto johti koodikerrostumi-

en siivoamiseen. Siivouksen jälkeen tiimien tuottavuus nousi kerrassaan toiselle tasolle.

VALMIIN MÄÄRITELMÄ

Työn suunnitteluun kuuluu sprintin tehtävä-listan laatiminen ja valmiin määritelmästä (Definition of Done) sopiminen. Valmiin mää-ritelmällä ohjataan työn vastuiden siirtymistä. Monitiimityöskentelyssä yksittäisen tiimin vastuulla on usein jokin komponentti tiettyyn varmuustasoon asti. Tiimillä ei välttämättä ole vastuuta esimerkiksi komponentin integroin-nista tai tuotantoon siirrosta. Työtä jätetään toisin sanoen tarkoituksella tietyn tiimin ja tietyn sprintin töiden ulkopuolelle, jonkin toisen tiimin vastuulle.

Tarina: Valmiin määritelmästä puuttui testituloksia

Eräässä ketterässä monitoimittajaprojektissa toimeksiantajan ja toimittajan ymmärrys toi-mialasta oli varsin vähäistä. Projekti käynnis-tettiin toimittajan alihankkijan konsultin johdolla. Tiedot määriteltiin yhdessä käyttäji-en kanssa luokkakaavion avulla. Kiireisen aikataulun vuoksi edettiin suoraan käyttöliit-tymän määrittelyyn ja käyttötapausten mää-rittely jätettiin pois. Määritykset käännettiin englanniksi ja lähetettiin ohjelmoijille Intiaan.

Tietojärjestelmän käyttöönoton jälkeen käyt-täjät raportoivat hankalasta käyttöliittymästä. Sovelluksessa oli myös selviä virheitä, joista osa johtui siitä, että toimeksiantaja ja toimit-taja eivät tunteneet toimialaa riittävän hyvin. Raportoidut muutosehdotukset liittyivät sekä käyttöliittymään että itse järjestelmän logiik-kaan. Muutospyynnöt olivat osin keskenään ristiriitaisia. Osa pyynnöistä toteutettiin, osa

jätettiin odottamaan. Muutaman kuukauden kuluttua käyttäjille ilmoitettiin, että järjes-telmän kehitys on toistaiseksi jäädytetty.

Järjestelmää käytettiin, mutta sen rinnalla tietoja välitettiin perinteiseen tapaan puheli-mitse ja sähköpostitse niissä tilanteissa, joita järjestelmä ei pystynyt hoitamaan. Osa tapah-tumista ei siis koskaan kirjautunut järjestel-mään eikä näkynyt järjestelmän tuottamissa, alan kehitystä kuvaavissa tilastoissa.

Kun järjestelmää oli käytetty pari vuotta, mää-riteltiin käyttötapaukset käyttäjien kanssa yhteistyössä. Niiden perusteella tietojärjes-telmästä kehitettiin uusi versio. Määrityksistä kehitettiin testitapaukset, joilla käyttäjät tes-taisivat järjestelmää kesäkuun puolivälin jäl-keen, juuri ennen pääasiallista kesälomakaut-ta. Kävi ilmi, että suurin osa testaajiksi ilmoit-tautuneista käyttäjistä olikin tuolloin lähtenyt jo kesälomille.

Elokuussa pidettiin uuden tietojärjestelmän käyttökoulutus. Parin kuukauden kuluttua järjestelmästä paljastui selvä looginen virhe. Testitapauksia määriteltäessä ei ollut ajateltu, että toiminnan logiikka voitaisiin ymmärtää niin väärin. Testauksen epäonnistuneen ajoi-tuksen vuoksi oli käyty läpi vain määritellyt testitapaukset. Ei ollut kokeiltu, tuottaisiko järjestelmä yllätyksiä, joihin ei ollut osattu varautua.

Virheestä raportoitiin toimeksiantajalle. Kiih-keän viestinvaihdon jälkeen virhe myönnet-tiin, mutta sen korjaaminen olisi vaatinut kohtuuttoman suuren remontin järjestelmään.

Purkkaratkaisuna sovittiin, että tiettyjä tieto-kenttiä alettaisiin käyttää uudella tavalla, jolloin tiedot näkyisivät oikein. Käyttäjäkou-lutusta ei kuitenkaan uusittu, minkä vuoksi monet käyttäjät käyttivät kyseisiä tietokenttiä alkuperäisellä tavalla. Järjestelmä välitti edel-leen osin virheellistä tietoa mm. laskutusra-porteissa.

Eräissä organisaatioissa laskuttajat tiesivät ongelman ja osasivat korjata laskutuksen kä-sin. Osassa organisaatioista laskutettiin mah-dollisesti tietojärjestelmän antamien tietojen perusteella sovittua pienempiä summia.

ROIKKUVAT HÄNNÄT

Sprintti on ajallisesti rajoitettu jakso tekemis-tä. Kun sprintti päättyy, saattaa joitakin sprintille valittuja asioita olla vielä tekemättä. Näitä tekemättömiä asioita kutsutaan roikku-viksi hänniksi. Joillekin tiimeille saattaa jäädä roikkuvia häntiä jatkuvasti sprintistä toiseen. Silloin tiimeillä on useampia aikaisempien sprinttien tehtävälistoja, joiden keskinäinen prioriteetti on määrittelemättä. Tämä hämär-tää käsitystä tiimin kehitystyön todellisesta nopeudesta sekä siitä, mitä tehtäviä on tär-keintä tehdä seuraavaksi.

Roikkuvia häntiä voi syntyä esimerkiksi siitä, ettei tiimi koe joitakin työvaiheita tarpeeksi tärkeiksi. Toisaalta häntiä syntyy myös silloin, kun tiimissä ei ole tarpeeksi jotakin erityis-osaamista. On myös mahdollista, että tiimi ei saa työrauhaa sovitun sprintin sisällön toteut-tamiseen, vaan sivusta tulee koko ajan ylimää-räisiä lisätehtäviä. Sprintin aikana tekemättä jääneet tehtävät kannattaa siirtää uudelle sprintille, mikäli ne edelleen koetaan tärkeiksi ja lisäarvoa tuottaviksi. Muussa tapauksessa ne on syytä yksinkertaisesti poistaa.

Tiimillä olisi syytä olla vain yksi priorisoitu tehtävälista, joka kuvaa tulevia tehtäviä. Yksi kokoava tehtävälista on tarpeen myös silloin, jos samassa tiimissä kehitetään rinnakkain jotain muuta tuotetta tai demonstraatiota johonkin tulevaisuuden julkaisuun.

Mikäli tiimiltä jää jatkuvasti roikkuvia häntiä, on joko tiimin kokoonpanossa tai toiminnassa jotakin korjattavaa. Saattaa olla, että tiimi arvioi väärin tehtävien koon tai että tiimi on

erityisosaamisten suhteen siiloutunut siten, että toteutuksessa syntyy pullonkauloja.

Arviointia voidaan kehittää esimerkiksi siten, että seuraavaan sprinttiin otetaan tarkoituk-sella vähemmän tehtäviä mukaan. Erityis-osaamista voidaan tiimissä jakaa siten, että jostakin asiasta vähiten tietävät henkilöt otta-vat erityisosaamista vaativat tehtävät tehdäk-seen ja tekevät sitten parityötä erityisosaajien kanssa. Jos tehtävät ja kehitettävä tuote ovat yksinkertaisesti sellaisia, että häntiä syntyy, on syytä harkita kanban-menetelmää. Siinä roikkuvia häntiä ei lähtökohtaisesti ole.

SISÄLLÖN TARKENTAMINEN

Sisällön tarkentamisella tarkoitetaan tässä sitä osaa määrittelystä, joka tehdään tiimita-solla. Tätä tarkennusta tehdään yleensä kes-kustelemalla. Sisällön tarkentamisen tarpeista on kehittynyt myös esimerkeillä tehtävä mää-rittely (Specification by Example, SBE). Siinä ajatuksena on, että keskustelut käydään esi-merkkien ympärillä: ”Miten tämä käytännössä toimisi?”.

Esimerkeillä tehtävä määrittely tunnetaan monilla nimillä hyväksymistestiohjatusta ke-hitystavasta (Acceptance Test Driven Deve-lopment, ATDD) käyttäytymisohjattuun kehi-tystapaan (Behavior-Driven Development, BDD). Jokaiseen termiin liittyy omat erityis-piirteensä, mutta niiden voidaan katsoa käsit-televän yleisesti samaa ongelmakenttää.

Sovelluksen käytön asiantuntijoilta pitää saa-da konkreettisia vastauksia siitä, miten ohjel-misto toimii. Ajatuksena on tiivistää näitä kokemuksia avainesimerkeiksi. Toisin sanoen jo tekemisen alkuvaiheessa on käytävä kes-kustelu, jollaiseen yleensä turvaudutaan vasta kriisitilanteissa: ”Voitko antaa jonkin esimer-kin?”.

Esimerkit voidaan kirjata muistiin määrämuo-toisesti. Ne muistuttavat yllättävän paljon perinteisiä testitapauksia. Keskustelun ja kirjaamisen pohjalta syntyneet esimerkit oh-jaavat sekä kehitystä että testiautomaation kehitystä. Tarkoituksena usein onkin, että esimerkkeihin liitetään testiautomaatio.

Tarina: Sisältösuunnittelu voi erota sprin t-tisuunnittelusta

Eräässä scrumiin siirtyneessä organisaatiossa suhtauduttiin suunnittelupäivään varsin pe-dantisti. Suunnittelupäivänä mietittiin tehtä-vät ja tämän pohjaksi tehtiin myös tarkenta-vaa suunnittelua. Monasti kävi kuitenkin niin, että oppiminen ja asioiden sisäistäminen vaati kalenteriaikaa. Usein asioita oli siten tarpeen tarkentaa myöhemmin.

Kunkin ominaisuuden osalta sovittiin pidet-täväksi (etenkin työmääriin keskittyvän) suunnittelupäivän lisäksi työpajoja. Työpa-joissa työstettiin tarkemmin arkkitehtuuria, laatuominaisuuksia sekä toteutettavan muu-toksen laajuutta. Näin varmistettiin, että kaikki todellakin ymmärsivät laajuuden sa-malla tapaa.

Keskusteluissa paljastui usein vielä eriäviä käsityksiä siitä, mitä jokin ominaisuus käy-tännössä tarkoittaisi. Jo sovittujen työmäärien

puitteissa sitten ideoitiin, mikä olisi näihin puitteisiin mahtuva minimaalinen lisäys kohti oikeaa tavoitetta.

Tarina: Esimerkeillä tehtävä määritt ely ilman automaatiota

Eräässä projektissa aloitettiin määrittely työs-tämällä esimerkkejä refaktoroinnin yhteydes-sä. Haluttiin varmistaa, että olemassa olevat ominaisuudet säilyvät tarkoituksenmukaisina lähes uudelleen toteutetussa versiossa. Esi-merkit auttoivat tiimiä näkemään ennen to-teuttamista, että edellinen ”hyvin toimiva versio” oli täynnä epäyhdenmukaisuutta ja että varsinaista ydinasiaa ei aina ollut kovin hyvin ymmärretty. Toisaalta, kun tämä kes-kustelu käytiin ajoissa, asian ymmärtämisen tuska oli jossain määrin pienempää kuin mi-käli samat asiat olisivat nousseet esiin vasta testauksessa.

TOTEUTUS

Jatkuva integraatio tarkoittaa työn koostamis-ta säännöllisesti yhteen muiden tekemien muutosten kanssa. Tämä vaatii versionhallin-tajärjestelmän tehokäyttöä ja erillisten integ-raatiokehityshaarojen tai tuoteominaisuuksi-en kehityshaarojen (feature branch) ylläpitoa. Tuoteominaisuuksien kehityshaarat voivat elää hyvinkin pitkään. Tällöin jatkuvaa integ-raatiota joudutaan tekemään ristiin eri kehi-tyshaarojen välillä. Usein jatkuvan integraati-on tukena käytetään versionhallintaan yhdis-tettyä ohjelmistoa, joka ajaa testejä ja muita tarkistuksia koodiin aina, kun uutta työtä integroidaan.

Jatkuvan integraation käyttöönotossa voi ongelmaksi muodostua turhat integrointion-gelmat, joita joudutaan ratkomaan useasti. Työkalujen valinnalla ja oikealla käytöllä voi-daan ehkäistä tällaisia riskejä.

KETTERÄN TEKEMISEN PUITTEET

Töitä jäsennetään monenlaisilla ketterillä kehikoilla. Joillekin keskeinen menetelmä on scrum (”kiinnitetään tehtävät sprintti kerral-laan”), toisille kanban (”otetaan rajoitettu määrä asioita työn alle imuohjauksella”), kol-mansille Extreme Programming (”käytetään kurinalaisia kehityskäytäntöjä”). Enemmistö käyttää kuitenkin erilaisia sekoituksia. Siinä missä pienet tiimit voivottelevat scrumin suunnittelumekanismien aiheuttamaa lisätyö-tä, suurissa tiimeissä ja suuressa skaalassa työskentelevät ihmiset vannovat yhteisen rytmin ja aikataulun nimeen. Yleisin viiteke-

hys tuntuu olevan ScrumBut. Tällöin käyte-tään joiltain osin scrum-mallia, mutta mallista jätetään pois vaihtelevasti osia, jotka eivät sovellu omiin mieltymyksiin tai kokemuksiin. Joku on jopa joskus sanonut, että jos scrum näyttää scrumilta puolen vuoden jälkeen, teet luultavasti jotain väärää. Et ilmeisesti opi, miten toimintaasi tulisi kehittää.

Tekemisen puitteiden keskeinen tekijä on myös itse tiimi: kuinka työt organisaatiossa jaetaan, mitä rooleja käytetään ja miten ne tulkitaan? Johtamiskäytännöt ja organisaation vastaanottavuus ovat myös merkittäviä teki-jöitä ketteryyden onnistumisen kannalta.

RYTMI JA TYÖJAKSOJEN PITUUS

Välillä ihmiset haluaisivat löytää lopullisen totuuden sprintin ihanteellisesta pituudesta. Yhdelle optimipituus on kaksi viikkoa, toiselle neljä ja kolmannelle jotakin muuta.

Tarina: Sprintin pituuden lyhentäminen

Eräässä tuotekehitysporukassa oli vaikeuksia pitäytyä luvatussa inkrementtisisällössä. Eri-näisillä kokeiluilla neliviikkoiset sprintit vaih-tuivat kaksiviikkoisiin ja lopulta viikkoihin. Lyhyellä aikavälillä oli helpompaa pitää lupa-ukset. Toisaalta samalla vastuu kokonaisku-vasta ulkoistettiin. Yhä useammat kehittäjät alkoivat kokea menettäneensä merkittävän

osan työnsä sisällöstä ja heidän motivaationsa alkoi laskea.

Kun töitä piti jakaa monille tiimeille, niitä työstettiin aluksi tuotteen työjonon tasolla. Näin varmistettiin, että teemallisiin kokonai-suuksiin kuuluvat asiat päätyivät tiimeille sopivasti synkronoituina. Kalenterirytmi aut-toi synkronoinnissa, Silloin tiedettiin, koska asiat saadaan päätökseen ja koska uusia asioi-ta voidaan ottaa työn alle.

Tarina: Kehityshaarojen käyttämisen si e-tämättömyys

Eräs tekninen tuoteomistaja otti minuun yh-teyttä sprinttien pituudesta. Olimme sopineet käyttävämme kahden viikon pituisia sprintte-jä. Tuoteomistajan mielestä kaksi viikkoa oli riittämätön aika minkään järkevän työhön, koska aktiiviseen kehitykseen jää käytännössä ainoastaan kuusi työpäivää. Yksi päivä kului sprintin suunnitteluun, yksi päivä demoihin ja retrospektiiviin ja viimeiset kaksi päivää sprintin lopusta tiimit käyttivät ominaisuuk-sien integroimiseen.

Ihmettelin tuoteomistajalle, miksi integroimi-seen kuluu kaksi päivää. Hän selitti, että ensin jokainen tiimi teki useita ominaisuuksia sa-manaikaisesti eri kehityshaaroissa. Kaksi päi-vää ennen sprintin päättymistä ominaisuudet julistettiin jäädytetyiksi, jotta integrointityö saattoi alkaa. Tämän jälkeen kaikki integroi-vat omat muutoksensa tuotteen pääkehitys-haaraan samanaikaisesti. Tämä johti usein konflikteihin.

Tilanne parani, kun tiimeissä otettiin käyt-töön integrointihaara, johon jokaisen piti in-tegroida omat muutoksensa vähintään kerran päivässä. Integrointihaara yhdistettiin tuot-teen pääkehityshaaraan sprintin viimeisenä päivänä, mutta tämä ei enää johtanut pahoihin konflikteihin.

Tarina: Teknisen velan suuruus yllättää

Eräässä projektissa päätettiin suorittaa koo-din uudelleen järjestelyä (refaktorointi). In-krementaalisen kehityksen myötä syntyneet ominaisuudet olivat hajautuneet rakenteiksi, joissa yhden ongelman korjaaminen aiheutti

tusinan muita ongelmia. Lisäksi oli tyypillistä, että samaa ongelmaa löydettiin useista pai-koista, mutta korjauksia tehtiin aina vain kä-sillä olevaan kohtaan.

Refaktoroinnin tarve oli kasvanut niin merkit-täväksi, että sovittiin neljän kuukauden jak-sosta, jonka aikana tehtäisiin suuria muutok-sia. Neljä kuukautta kasvoi seitsemäksi. Osit-tain syynä oli se, että tuotteeseen lisättiin samalla ominaisuuksia. Toinen syy oli se, että koodin sisältämiä ominaisuuksia katosi järjes-telyssä, koska ne eivät olleet käyneet koodista itsestään selvästi ilmi. Jakson alun ja lopun välissä koodimassasta kutistui pois kaksi kolmasosaa, vaikka toiminnallisuuksia tuli lisää.

Kun työ saatiin päätökseen, uskottiin, että tekninen velka oli nyt maksettu. Lähdettiin lisäämään yksikkötestejä ja todettiin, että ylläpitoa helpottavat ratkaisut koodimassan minimoimiseksi oli tehty siten, että rakenteet olivat muuttuneet testattavuuden kannalta vaikeiksi. Tästä alkoi loppumaton keskustelu siitä, pitäisikö refaktorointia tehdä ollenkaan.

Onnistuiko kyseinen refaktorointi? Toisaalta onnistui, sillä ylläpidossa aikaa kului työn jälkeen merkittävästi vähemmän. Toisaalta ei, sillä testauksessa aikaa kului paljon, koska testausautomaatio ei ollut apuna. Jos saisin valita, ottaisin mieluummin parhaat puolet molemmista tilanteista. Ei lopputilanne sinäl-lään mikään huono ollut.

Kun asiasta keskusteltiin jälkikäteen ryhmäs-sä, opittiin myös uusia asioita. Joidenkin teo-rioiden mukaan ei ole olemassa kunnollista refaktorointia, joka tapahtuu ilman yksikkö-testejä. Joskus vain osaamisen, teorian ja käy-tännön yhteen sovittamien ei ole kovin help-poa silloin, kun asiat ovat työn alla.

KOODIN KATSELMOINTI

Koodin katselmointi kuuluu olennaisena osa-na monen ketterän tiimin työskentelymene-telmiin. Katselmointi toimii yhtenä laadun-varmistusmenetelmänä. Lisäksi sen avulla saadaan myös jaettua tietoa ja osaamista tii-min sisällä. Koodikatselmoinneissa olisi hyvä käyttää jotakin työkalua, joka mahdollistaa koodin katselmoinnin ennen sen julkaisemista versionhallintajärjestelmään. Kun koodia kat-

selmoidaan usein ja pienissä paloissa, on pro-sessi kevyt. Silloin katselmointi toimii tiimin hyödyksi sen sijaan, että se muodostuisi rasit-teeksi ja kuluttaisi arvokasta kehitysaikaa.

Tarina: Koodin katselmoinnin käyttöönotto

Tuotekehitystiimiin palkattiin uusi kehittäjä, joka oli aikaisemmassa työssään tottunut sii-hen, että kaikki koodimuutokset katselmoi-tiin. Jonkin aikaa uudessa tiimissä toimittu-aan, hän ehdotti muille tiimiläisille samaa käytäntöä. Perusteina hän esitti muun muassa, että hänen olisi uutena tiimiläisenä helpompi tulla tutuksi koodin kanssa, kun hän näkisi mitä muutoksia muut koodiin tekevät.

Tiimi päätti – osin vastahakoisesti – kokeilla koodin katselmointikäytäntöä yhden sprintin ajan. Katselmoinnit toteutettiin siten, että kun tiimiläinen oli tehnyt koodiin muutoksen, hän julkaisi muutokset koodikatselmointi-työkalun avulla muille tiimiläisille, jotka pys-tyivät halutessaan kommentoimaan muutok-sia.

Aluksi katselmointi koettiin raskaaksi proses-siksi. Pian tiimiläiset kuitenkin oppivat jul-kaisemaan muutoksia pienemmissä paloissa, jolloin niiden katselmointi oli huomattavasti nopeampaa. Noin viikon kuluessa lähes kaikki tiimiläiset oppivat arvostamaan kirjoittamas-taan koodista saamaansa palautetta.

Katselmoinneissa löydettiin päivittäin virhei-tä, jotka pystyttiin näin korjaamaan aikaisessa vaiheessa. Tärkeänä opetuksena huomattiin, että tiimiläinen ei ole yhtä kuin hänen kirjoit-tamansa koodi eikä koodin arvostelu ole koo-din kirjoittajan arvostelua. Tämän asian ta-juamiseen meni jokaisella tiimiläisellä useita päiviä.

PARIOHJELMOINTI

Koodikatselmoinnin lisäksi – tai sijasta – voi-daan käyttää myös pariohjelmointia. Parioh-jelmointi toimii myös tehokkaana osaamisen jakamisvälineenä. Pariohjelmoinnissa kaksi tiimiläistä istuvat saman näppäimistön äärellä kummankin toimiessa vuorollaan koodin kir-joittajana (”kuski”) ja vuorollaan koodin kat-

selmoijana (”kartanlukija”). Vuoroja vaihde-taan tiheään tahtiin.

Tarina: Pariohjelmoinnin käyttöönotto

Tiimissä oli eräs vanhempi kehittäjä, joka ei halunnut kokeilla pariohjelmointia. Hän ei pitänyt siitä, että ”hänen olkansa yli kurki-taan”. Sama kehittäjä myös koki, että häntä itseään arvosteltiin, jos hänen kirjoittamaansa koodia arvosteltiin. Tämän takia hän ei olisi myöskään halunnut julkaista omaa koodiaan katselmoitavaksi.

Yksi tiimiläisistä alkoi pyytää tältä vanhem-malta kehittäjältä päivittäin apua ja pyysi tämän istumaan kanssaan koneensa ääreen. Vanhempi kehittäjä sai näin toimia pariohjel-moinnin kartanlukijana – asiaa itse tajuamat-ta. Ei mennyt kauan, kun vanhempi ohjelmoija huomasi, että on tehokkaampaa ottaa näp-päimistö itselleen kuin osoitella sormella tai yrittää puhumalla kommunikoida tarvittavia koodimuutoksia. Huomaamattaan vanhempi ohjelmoija alkoi siis tehdä pariohjelmointia. Pariohjelmoinnin hyödyt oivallettuaan hän oli valmis myös itse ottamaan apua vastaan.

HAVAINTOJEN KÄSITTELY TEKEMISEN AIKANA

Virheettömiä ohjelmistoja ei ole olemassa. Kun ohjelmistoa testataan ja käytetään, siinä havaitaan virheitä. Nämä virheet pitää käsitel-lä aktiivisesti. Kaikkia havaittuja virheitä ei välttämättä tarvitse korjata. Toisinaan virhe-havaintoja kerätään varastoon, mutta niitä ei käydä tarpeeksi usein aktiivisesti läpi. Tällöin syntyy iso varasto asioita, jotka pitäisi ehkä joskus korjata tai ainakin käsitellä. Tähän käsittelyyn ei sitten yleensä tahdo löytyä kos-kaan aikaa.

Joissakin projekteissa käytetään kovetuss-printtejä. Kovetussprinttien aikana ei kehitetä uusia ominaisuuksia, vaan tehdään ainoastaan korjauksia. Tämä ratkaisu ei aina toimi käy-tännössä kovin hyvin, koska aika virheen ha-vaitsemisesta sen korjaamiseen saattaa venyä hyvinkin pitkäksi. Lisäksi malli saattaa johtaa havaittujen virheiden korjaamisen laiminlyön-tiin.

Eräs toimiva käytäntö havaintojen käsittelyyn on määritellä avoimien virhehavaintojen mää-rälle suhteellisen alhainen yläraja. Kun raja saavutetaan, kaikki tiimiläiset lopettavat muun tekemisen ja korjaavat havaittuja virhei-tä, kunnes hyväksyttävä taso on taas saavutet-tu. Isoissa projekteissa voi olla tarpeen määri-tellä avoimien havaintojen määrä komponent-tikohtaisesti.

Havaintojen vakavuuden määrittelemiseen ei välttämättä kannata käyttää aikaa. Havaittu virhe on virhe ja se tulee oletusarvoisesti kor-jata. Hyvä käytäntö on käydä havaintoja läpi usein, esimerkiksi päivittäin, ja tehdä jokaisen uuden havainnon kohdalla nopea päätös kor-jaamisesta: korjataan heti, korjataan seuraavan sprintin aikana, ei korjata lainkaan tai siirre-tään tuotteen kehitysjonoon uutena ominai-suutena. Tällaiseen havaintojen läpikäymiseen ei tarvita isoa komiteaa. Jokainen tiimi voi tehdä sitä kevyenä prosessina. Usein riittää, että yksi henkilö tiimistä käy päivittäin läpi uudet havainnot.

Tarina: Havaintovarastosta aktiiviseen ha-vaintojen käsittelyyn

Eräässä isossa projektissa alettiin kiinnittää huomiota avoimien virhehavaintojen suureen määrään. Kun ohjelmistoversiota julkaistiin asiakkaalle, avoinna saattoi olla usein satoja havaintoja. Laadunhallinnasta vastaavat hen-kilöt ottivat asian esille projektin ohjausryh-män kanssa. Laatuihmiset kritisoivat sitä, kuinka on mahdollista julkaista asiakkaille ohjelmistoversio, jonka tiedetään olevan laatu-tasoltaan heikko.

Päätettiin ottaa käyttöön uusia käytäntöjä. Eräs käytäntö oli projektinlaajuinen havain-tokatto. Jos avoimien virhehavaintojen määrän huomattiin ylittävän 100, tuli kaikkien tiimien keskittyä pelkästään havaintojen korjaami-seen, kunnes avoimien havaintojen määrä on alle 80. Korjausmoodin aikana uusien ominai-suuksien kehittäminen oli kiellettyä. Havain-toja piti käydä läpi aktiivisesti useita kertoja viikossa, mielellään päivittäin. Jokaisen uuden havainnon kohdalla piti tehdä nopea päätös: korjataan tässä sprintissä, korjataan seuraa-vassa sprintissä, ei korjata lainkaan tai siirre-tään tuotteen kehitysjonoon.

Menetelmä ei toiminut täysin toivotulla taval-la. Jotkut tekivät uutta toiminnallisuutta sil-loinkin, kun olisi pitänyt korjata havaintoja. Jotkut tiimit joutuivat odottamaan, että muut saivat korjattua havaintoja, koska ne työsken-telivät sellaisten komponenttien parissa, joissa ei ollut korjattavaa. Käytäntöön tehtiin sitten muutamia korjauksia. Havaintokatoista teh-tiin komponenttikohtaisia. Versionhallintajär-jestelmään toteutettiin portinvartijaominai-suus, joka esti muiden kuin korjausten julkai-semisen, mikäli avoimia havaintoja oli liikaa. Komponenttikohtaisesti avoimia havaintoja sai olla avoinna huomattavasti vähemmän. Yhden komponentin kohdalla katto oli 30 avointa havaintoa. Määrän piti laskea 20:een tai alle, jotta uusien ominaisuuksien kehitys-työtä saisi taas jatkaa. Korjausten julkaisemi-sessa piti käyttää tietyillä sanoilla alkavaa kommenttia, joka kertoi versionhallinnan portinvartijalle, että julkaisu piti päästää läpi.

SUURTEN OMINAISUUKSIEN KETTERÄ TOTEUTTAMINEN

Usein ominaisuudet ovat niin suuria, ettei niiden toteuttaminen mahdu yhteen sprint-tiin. Tämä ei yleensä ole ongelma, mikäli omi-naisuus voidaan jakamaan sellaisiin pienem-piin osiin, joista jokainen tuo lisäarvoa loppu-käyttäjälle. Mutta mitä tehdä ominaisuudelle, jota loppukäyttäjä ei voi käyttää ennen kuin se on kokonaan toteutettu? Tällainen ominai-suus voi olla esimerkiksi käyttöliittymässä selvästi näkyvä muutos, joka ilmentää toimin-nallisuutta, jonka toteuttamiseen menee pal-jon aikaa.

Yksi vaihtoehto toteuttaa iso ominaisuus on tehdä sille oma kehityshaaransa. Tätä kehi-tyshaaraa synkronoidaan ohjelmiston päähaa-ran kanssa koko toteutuksen ajan aina siihen asti, kunnes ominaisuus on kokonaan valmis. Tämä ratkaisu ei yleensä toimi käytännössä kovin hyvin. Lähestymistavan seurauksena integrointi päähaaraan saattaa osoittautua vaikeaksi, kun ominaisuus lopulta valmistuu. Näin käy helposti varsinkin silloin, jos synk-ronointia ei ole tehty aktiivisesti ja päivittäin. Kehityshaarassa kehitettäviä toimintoja voi olla myös vaikeaa testata. Tämä tarkoittaa käytännössä sitä, että ohjelmistosta joudutaan rakentamaan useita eri versioita. Mikäli testi-automaatiokoodi ei sijaitse samassa koodisäi-

lössä kuin tuotantokoodi, tulee myös testiau-tomaatiokoodille tehdä kehityshaara. Tämä monimutkaistaa asioita entisestään.

Yksi toimivaksi todettu menetelmä isojen ominaisuuksien toteuttamiseksi on ominai-suuksien ajonaikainen piilottaminen. Tällöin ominaisuus voidaan toteuttaa ohjelmiston pääkehityshaaraan ja toimittaa loppukäyttäjil-le siten, että se on käännetty pois päältä oh-jelmiston asetuksissa. Ominaisuus on silloin myös helposti testattavissa. Ajonaikainen piilottaminen on ratkaisu, joka pitää ottaa huomioon heti ominaisuuden toteutuksen alusta lähtien. Ratkaisun liittäminen ohjelmis-toon jälkeenpäin voi olla sangen työlästä.

TESTAUS

Valmiin määritelmään kuuluu monenlaista asiaa, mutta erityisen haastavia alueita ovat dokumentaatio ja testaus. Testauksen puut-teet näkyvät usein siten, että ketterän projek-tin tuotos ei toimikaan oletetulla tavalla tuo-tannossa. Halutun toiminnallisuuden kunnol-linen dokumentointi vähentää olettamuksia myös ketterissä menetelmissä. Tiedämme, mitä tulee testata, kun tiedämme, mitä tulee toimittaa.

Testaus on tiedon keräämistä ohjelmiston tilasta. Tämänkin kirjan kirjoittajissa on hen-kilöitä, joiden mielestä testaus on liiketoimin-nan haasteiden jälkeen yksi ketterien projek-tien vaikeimpia ja väärinymmärretyimpiä ai-healueita. Tätä ilmentää ohimennen kuultu toteamus, että ”meillä pomo on kyllä sitä miel-tä, että TDD on kaikki se testaus mitä me tarvitaan”.

Ketteryys vaatii jatkuvaa palautetta. Palaut-teen tulee olla mahdollisimman nopeaa. Jos odotetaan asiakkaan hyväksyntää siitä, onko kaikki yksityiskohdat toteutettu toiveiden mukaisesti ja otetaan muutoksenhallintana seuraaviin tekemisiin, menetetään jotain oleel-lista läpimenevän arvon osalta. Palaute pitää saada lähelle tekemistä.

Testaaminen sisältää kaksi näkökulmaa, vah-vistuksen ja tutkimisen. Ei riitä, että automa-tisoituja testejä toistetaan ja laajennetaan. Lisäksi on oltava sellaisia mekanismeja, joilla oppia käyttämällä ohjelmistoa. Nämäkin opit

voivat osaltaan taas vaikuttaa siihen ymmär-rykseen, jolla automaatiota kehitetään

Kuvassa ??? esitetään testausta jäsentävä neli-kenttä. Nelikentän kussakin kulmassa on esitetty erilainen tarve ja tavoite:

Teknologiasuuntautuneet vahvistavat testit tehdään teknologiaan liittyvien odotusten pohjalta. Näiden testien tarkoituksena on vahvistaa, että tarkoitettu suunnittelun peri-aate täyttyy niin ensi kertaa tehdessä kuin myöhemminkin.

Liiketoimintasuuntautuneet vahvista-vat testit tehdään määrittelyjen poh-jalta. Ketterien ajatusmallien mukaan testeistä on enemmän apua tiimille, mikäli ne ovat automatisoituja. Niihin liittyvien oppimisprosessien tulee ta-pahtua mieluummin ennen toteutusta kuin sen jälkeen (mikä johtaisi uusiin toteutuskierroksiin).

Teknologiasuuntautuneilla tutkivilla testeillä haetaan uutta tietoa järjes-telmän sisäisiin laatuominaisuuksiin (ylläpidettävyys, suorituskyky, tieto-turva jne.) liittyvistä riskeistä.

Liiketoimintasuuntautuneilla tutki-villa testeillä haetaan uutta tietoa, jo-ka liittyy järjestelmän ulkoisiin laa-tuominaisuuksiin, erityisesti toimin-nallisuuksiin, prosesseihin ja käytön tuottamaan lisäarvoon.

Vahvistavilla testeillä testataan samoja asioita kerta toisensa jälkeen. Tutkivilla testeillä tar-kastellaan eri asioita eri kerroilla. Samojen asioiden testaaminen voidaan yleensä automa-tisoida, mutta uusien ja yllättävien asioiden tarkasteluun automatisaatio mukautuu han-kalammin. Molempia lähestymistapoja tarvi-taan. Pääperiaatteena on, että pitkää palaute-sykliä ei pitäisi hyväksyä. Nopeaan palaute-sykliin ei päästä ilman automaatiota.

Tarina: Tutkivaa suorituskykytestausta

Eräässä projektissa oli tuotettu järjestelmä, ja tiimi ajoi sille ensimmäisiä suorituskykyteste-jä. Havaittiin, ettei valittu toteutustapa voinut vastata liiketoiminnan asettamia skaalautu-vuuden vaatimuksia. Suorituskyvyn riskejä päätettiin selvittää vaihtuvin testein eri toteu-tuksille. Suorituskykytestaus auttoi suuntaa-

maan työskentelyä ja antoi sellaisia ymmärrys-tä, jota ei pelkästään suunnittelemalla olisi voitu saavuttaa.

Tarina: Kertakäyttöinen dokumentaatio

Eräässä ketterässä projektissa päädyttiin käyttämään kanban-menetelmää. Käyttäjäta-rinat ja testitapaus oli oppien mukaan kirjoi-tettu omiksi korteikseen seinätaululle. Projek-tissa kehitettiin kokonaan uutta sovellusta ja ketterän menetelmän ansiosta kyettiin mu-kautumaan muuttuviin vaatimuksiin. Projek-tin edetessä käyttäjätarinat testattiin ja kortit merkittiin tehdyiksi. Projekti valmistui ja julkaisu saatiin tehtyä. Tämän jälkeen ilmeni, että toinenkin projekti olisi halunnut hyödyn-tää testausdokumentaatiota oman sovelluk-sensa testaamisessa. Kanban-kortit oli kui-tenkin heitetty pois.

AUTOMATISOITU YKSIKKÖTESTAUS

Automatisoitua yksikkötestausta käytetään nopeuttamaan ja yksinkertaistamaan refakto-rointia ja muita vanhaa toiminnallisuutta säi-lyttäviä muutoksia. Tällaisia testejä käytetään myös lisäämään regressiotestien kattavuutta. Tässä luvussa käytämme yksikkötesteistä seuraavaa määritelmää: automaattisesti ajet-tava testi, jonka suorittaminen on nopeaa.

Usein automaattisille yksikkötesteille pyri-tään tekemään sellainen kattavuus, että ne käyvät läpi jokaisen eri suorituspolun koodin läpi. Tämä vaatii hyvin paljon työtä. Yksikkö-testien tehokas käyttö vaatii hitaasti toimivi-en järjestelmien (esim. tietokantayhteydet ja levyjärjestelmät) helppoa simulointia. Silloin testeissä voidaan käyttää niiden sijasta nope-asti toimivia ja kontrolloituja komponentteja.

Tarina: Arkkitehtuuri on niin sotkua, ettei yksikkötestaus onnistu

Sovellukseen tarvittiin suhteellisen pieni muutos, jota kehitystiimi alkoi työstää. Sovit-tuna käytäntönä oli tehdä uudelle koodille yksikkötestit. Alkuun päästiinkin helposti. Tietokantayhteys korvattiin nopeammalla simulaatiolla. Yksikkötesti ei kuitenkaan vai-kuttanut toimivan samalla tavalla kuin järjes-

telmän oikean rajapinnan kautta. Pitkän selvi-tystyön jälkeen havaittiin, että sovellukseen oli aiemmin tehty vaikeasti löydettävissä ole-vaa automatiikkaa, mikä piti huomioida myös yksikkötesteissä. Lopputulos oli, että yksik-kötestien laatimiseen käytettiin moninkertai-nen määrä aikaa kuin itse toteutukseen. Tes-tauskoodista tuli myös moninkertaisesti pi-tempi ja monimutkaisempi kuin toteutuksen koodista.

TESTIVETOINEN KEHITYS

Tässä luvussa käytetään testivetoisesta kehi-tyksestä (Test Driven Development, TDD) seuraavaa määritelmää: ohjelmistokehitysme-netelmä, jota tuetaan voimakkaasti testeillä (myös muilla testeillä kuin yksikkötesteillä). Testivetoisessa kehityksessä suunnittelu aloi-tetaan tavoitteiden asettamisesta, eli sen mää-rittelystä, mitä halutaan. Testin vaatimat asiat toteutetaan yksinkertaisella tavalla. Tämän jälkeen toteutus refaktoroidaan, jotta koodista saadaan poistettua toistumat. Sitten testien tekemistä jatketaan ja prosessia toistetaan, kunnes kaikki vaaditut toiminnot on toteutet-tu. Tällaista sykliä kutsutaan usein nimellä punainen-vihreä-refaktorointi.

Testivetoisella kehityksellä pyritään varmis-tamaan, että koodi tekee sen (ja vain sen), mitä sen on tarkoitus tehdä. Tiukkaa testive-toista kehitystapaa noudattavat henkilöt eivät kirjoita yhtään riviä tuotantokoodia ennen kuin he ovat kirjoittaneet komponenttia tes-taavan yksikkötestin.

Testivetoista kehitystä käyttävissä tiimeissä vaarana on varsinaisen testauksen jättäminen pois. Yksikkötestejä kertyy toki runsaasti ja niitä tukemaan tehdään usein myös muita hitaita järjestelmiä, kuten tietokantoja, käyt-täviä integrointitestejä. Silti kehittäjien teke-mät testit testaavat parhaassakin tapauksessa vain kehittäjien jo huomioimia ongelmia. Siksi on suuri riski jättää perinteinen testaus pois. Tällaisia ongelmia jää järjestelmään ja käyttö-liittymät toimivat normaalisti, mutta eivät näytä hyviltä. Muutoksen jälkeen kaikki yk-sikkötestit voivat näyttää vihreää ja käyttöliit-tymässä näkyy kyllä jokin teksti, mutta puolet tekstistä jää näytön ulkopuolelle.

Tarina: Testivetoisuus poisti kärsimykset

Tarpeettoman monimutkaisesti määritellyn toiminnallisuuden pelkkä kokeileminen käyt-töliittymän kautta vei useita minuutteja. Li-säksi toiminnallisuus asetti ajastetun toimin-non laukeamaan aikaisintaan seuraavana päi-vänä. Toiminnon onnistuminen voitiin käydä tarkastamassa vasta vuorokauden kuluttua toisesta, integroidusta järjestelmästä.

Testausta ja kehitystä nopeutettiin muutta-malla tietokannasta päivämääriä ja ajamalla ajot käsin. Näilläkin apukeinoilla toiminnalli-suuden testaus käyttöliittymän kautta kesti pitkään. Pienetkin muutokset kyseiseen toi-mintoon vaativat useita päiviä. Ne tehtiin yleensä nopeimmalla mahdollisella tavalla, koska aina oli kova kiire.

Erään muutoksen kohdalla kehittäjän kipura-ja kuitenkin ylittyi. Kehittäjä päätti tehdä muutoksen testivetoisesti. Hän rakensi melko paljon testikoodia tarkastamaan vain oleelli-sen osan logiikan toiminnosta. Ajastuksissa, tietojen tallentumisessa ja integraatiossa oli hyvin harvoin vikoja, joten niitä ei tarvinnut testata. Toimintoa muuttavien kehittäjien mieliala ja kehitysnopeus parantuivat mitta-vasti. Myös toiminnon käyttäytymistä alettiin ymmärtää paremmin.

MYÖS KORJAUSVERSIOITA

Jatkuvassa tuotekehityksessä sovellusta kehi-tetään julkaisusuunnitelman mukaan, jolloin uusia ominaisuuksia julkaistaan eri vaiheissa. Vanhoihin ominaisuuksiin voidaan myös teh-dä korjauksia. Testauksessa on tällöin kyettä-vä testaamaan, että vanhat ominaisuudet ovat muuttumattomia tai että niissä on vain halu-tut muutokset.

Silloin tällöin joudutaan tekemään julkaisu-suunnitelman lisäksi ns. korjausjulkaisuja. Korjausjulkaisu sisältää ainoastaan viankorja-uksia. Tällaisen julkaisun tekeminen on pää-osin testausta. Jatkuvassa tuotekehityksessä testauksen suhteellinen määrä uuden koodin määrään verrattuna kasvaa. Siten testauksesta muodostuu helposti pullonkaula.

Tarina: Korjauksetkin vaativat edelleen aikaa

Erään laajan järjestelmän kehittämistä varten perustettiin neljä scrum-tiimiä ja yksi järjes-telmätestaustiimi. Kahden viikon sprintin jälkeen järjestelmätestaustiimi testasi sprint-tijulkaisut ja laati vikaraportit. Julkaisun tes-taaminen kesti noin viikon. Vikakuvaukset lisättiin sprinttien työlistoille, mutta kaikkia löydettyjä vikoja ei enää ehditty korjata käyn-nissä olevissa sprinteissä. Monilla löytyvillä vioilla saattoi olla jo lähtökohtaisesti 2–3 vii-kon korjausviive.

Ongelman korjaamiseksi olisi testaaminen pitänyt muuttaa sprintin aikana tehtäväksi. Järjestelmätestaukset olisi myös pitänyt suunnitella uudestaan, osaksi julkaisusuunni-telmaa. Esimerkiksi käyttäjätarinoiden (so. uusien ominaisuuksien) testaaminen painot-tui yleensä sprintin loppupuolelle. Seuraavan sprintin alkuvaiheissa olisi siis voitu tehdä tarvittavat regressiotestaukset. Myös vikojen kirjaaminen olisi kannattanut tehdä samaan, yhteiseen tehtävälistaan. Näin viankorjaus olisi päässyt priorisoinnissa samalle viivalle kuin muukin tekeminen.

Tarina: Etätestaus toisessa maassa

Eräässä projektissa tiimi tarvitsi lisää tes-tausosaamista. Tiimin perusmiehitys ei pysty-nyt löytämään kaikkia ongelmia tekemisen aikana, minkä vuoksi testausta vahvistettiin ottamalla mukaan testaaja halvempien työ-voimakustannusten maasta. Valittu palvelun-tarjoaja oli erikoistunut tutkivaan testauk-seen.

Työnohjaus ja tiedonvälitys tapahtuivat Jira-tehtävänhallintajärjestelmässä olevan tuotteen kehitysjonon avulla. Jonoa ei ositettu tehtäviin muutoin kuin tarvittaessa. Testausta doku-mentoitiin kaksitasoisesti sekä ideakartoilla että määrittelyesimerkin tapaisilla avainesi-merkeillä. Näiden esimerkkien automatisointi oli vielä alkutekijöissään, mutta kuitenkin työn alla. Kokonaisuuden kasaaminen oli tii-min vastuulla, ja käytännössä automaatioon liittyvissä tehtävissä oli tässä tiimissä vahvasti toteuttajapainotusta.

Tiimin kyky toimittaa ominaisuuksia toimivi-na parantui lisääntyneen asiantuntijapalaut-teen myötä jonkin verran. Samalla kuitenkin opittiin, että virheiden livahtaminen tuotan-toon saattaa olla myynnin kannalta arvokasta asiakassuhteen hoitoa, kunhan kyky korjata nopeasti on olemassa. Hieman yllättävää oli se, että testaajan etäisyys muusta tiimistä ei muodostunut ongelmaksi. Nimetty henkilö oli ollut aktiivinen viestijä, ja tuotteen kehitys-jonolta tehtävien valitseminen ohjasi hyvin yhteistyötä.

Tarina: Testausympäristöt hallintaan

Eräässä yrityksessä testauksen oli käytössä neliportainen ympäristö: kehitys-, järjestelmä-, hyväksyntä- ja tuotantoympäristö. Ajatukse-na oli se, että kutakin ympäristöä voitiin käyt-tää eri vaiheissa. Tällöin toisiaan vastaavan maturiteetin komponentteja voitiin testata yhdessä ja samassa ympäristössä. Kehitysym-päristö oli varattu kehitystyön aikaiseen in-tegrointitestaukseen, järjestelmäympäristö sovellusten järjestelmätestaukseen ja hyväk-symisympäristö tuotantoon siirtoon tarvitta-viin hyväksymistestauksiin. Tuotantoympä-ristössä tehtiin sovellusten todentamista.

Yritys ei ollut tarkoin määritellyt, millä hy-väksymiskriteereillä eri ympäristöihin voidaan tuoda uusia komponentteja, milloin päivityk-siä voidaan tehdä tai miten sidosryhmille (ts. niille, joilla oli kyseisiin komponentteihin riippuvuuksia) tiedotetaan. Epäselvyys johti siihen, että jo järjestelmätasolla testaaminen jouduttiin tekemään tietämättä, mitä tarkal-leen ottaen testataan. Ympäristö saattoi muuttua kesken testaamisen. Tilanteen kor-jaaminen olisi vaatinut yhteisiä pelisääntöjä. Olisi esimerkiksi pitänyt sopia, että sprinttien tai inkrementtien hyväksymiskriteerit sisältä-vät vaadittavat testaus- ja tiedottamistavoit-teet eri ympäristöille. Inkrementeille olisi voitu myös sopia oma valmiin määritelmänsä, jonka pitäisi täyttyä ennen komponentin siir-tämistä järjestelmätasolle.

Tarina: Monella oivalluksella kohti kette-ryyttä

Eräässä projektissa lähdettiin soveltamaan ketteriä menetelmiä. Tiimiläiset olivat monin

tavoin jo valmiita tähän, sillä heillä oli toisaal-ta kokemusta tutkivasta testauksesta (ei tarkkoja testitapauksia) ja toisaalta yksikkö-testiautomaatiotakin oli jossakin määrin jo toteutettuna.

Matkalla kohdattiin isojakin muutoksia. Aluksi päiväkoonnit vaihdettiin jatkuvaan integraatioon, mikä tarkoitti testauskohteen jatkuvaa muuttumista. Sitten huomattiin, kuinka vaikeaa on päästää irti suunnittelusta, ja tehtiin minuuttien aikarajaus epätarkkojen työmääräarvioiden käyttöön oikean osittami-sen sijaan.

Seuraavaksi havaittiin, että testaus kannattaa hajauttaa tiimeihin eikä pitää omana tiimi-nään. Tiimin ulkopuolelle jäävä testauspääl-likkökään ei edistä oikeanlaisen syntymistä, vaikka valmennustarvetta saattaa monitiimiti-lanteessa jäädäkin.

Oivallettiin, että testaussuunnittelu voidaan tehdä tuotteen kehitysjonon tasolla, kunhan jokainen listan alkio ymmärrettiin kokonai-suutena, joka sisältää testauksen. Lisäksi mahdolliset laatuvelkaan liittyvät asiat pää-tettiin tuoda tuotteen kehitysjonolle sitä mu-kaa, kun niitä kertyy. Laatuvelalla tarkoite-taan tässä virheitä, jotka pitää korjata, mutta ei välttämättä heti. Laatuvelkaa alettiin mitata ja maksaa.

Määrittelemistä alettiin tehdä työpajamaises-ti. Näin tieto siitä, mitä ollaan tekemässä, syntyisi kaikille osapuolille yhdessä. Monessa kohtaa mentiin silti vielä metsään. Toisinaan työpajoista tultiin ulos täysin erilaisten käsi-tysten kanssa. Tajuttiin, kuinka vaikeaa on pitää lupauksensa toimituksesta, kun osaami-set ja intressit eivät ole niin moniosaajaa kuin ideologit toivoisivat. Huomattiin, kuinka tär-keää on saada mittaamalla näkyville, mitä osataan. Viime kädessä kaikkein tärkeintä on pitää keskustelu käynnissä.

Keskusteluista opittiin myös, että valmiin määritelmää pitää mukauttaa riskipohjalta. Erityisesti testausmielessä ei kannata laittaa yhtä paljon paukkuja siihen keskeisimpään toiminnallisuuteen kuin asiaan, joka markki-nointimielessä tuotteesta on löydyttävä.

Opittiin, että testauksessa on kahdenlaisia töitä. Toisaalta on niitä töitä, joita tehdään, kunnes työ on valmis (työmääräarviot). Toi-saalta on niitä töitä, jotka päättyvät, kun niille

varattu aika loppuu (aikarajatut). Testaus luonteeltaan on enemmän sellaista työtä, joka loppuu kun aika loppuu. Opittiin myös, että oikeiden päätösten tekeminen paineen alla vaatii kurinalaisuutta.

Pitkän väännön jälkeen huomattiin, että vaik-ka ketterää kehitystä voi pyörittää myös vä-häisellä testiautomaatiolla, ongelmaksi voi muodostua ihmisten jaksaminen ja motivaa-tio. Lisäksi korjausliikkeet ovat isoja, jos ti-lanne on jo päällä. Kaikessa pitäisi aina muis-taa ajatella ihmisen kasvupolkua (mitä minus-ta tulee isona) ja työn sisältöjen mielekkyyden varmistamista.

Tämä tarina loppuu näkyvyyden loppumiseen kyseisessä projektissa. Silmien poistuessa otettiin juuri käyttöön ominaisuustiimejä, joissa luovuttiin enenevässä määrin tutuista ja turvallisista alueista toimituksen prioriteet-tienmukaisuuden varmistamiseen.

DEMO JA RETROSPEKTIIVI

Ketterissä menetelmissä sprintin katselmuk-seen sisältyy sopivassa ympäristössä toimiva demonstraatio eli demo. Demossa näytetään käytännössä, miten toteutus sillä hetkellä toimii. On hyvä pitää selvänä se, tehdäänkö demonstraatio tuotantoon tarkoitetulla in-

krementillä vai ainoastaan demonstraatioon tarkoitetulla toteutuksella, jolla haetaan mah-dollista käyttäjäpalautetta. Jos demossa ei saada palautetta ilmiselvistä puutteista huo-limatta, niin demonstraatioon ilmeisesti osal-listuu henkilöitä, joilla ei ole todellista mie-lenkiintoa tai sitoutumista kyseisen inkre-mentin sisältöön.

Sprintin katselmuksessa tapahtuva tuotteen demonstraatio on mahdollinen (mutta ei vält-tämätön) osa sprintin hyväksymistä. Sprintin katselmuksen jälkeen pidettävässä retrospek-tiivissä voidaan miettiä, kuinka asiat voitaisiin tehdä paremmin tai jäikö toteutukseen jon-kinlaisia refaktorointitarpeita.

Sprintin katselmuksia ja retrospektiiviä ei pidä väheksyä. Ne ovat oleellinen keino saada palautetta tuotetusta sisällöstä ja kehittyä tiiminä. Sprintissä tuotetusta sisällöstä ei pidä hyväksyä tekemättömiä ja testaamattomia käyttäjätarinoita. Retrospektiivissä ei pidä keskittyä toistensa kehumiseen; oleellista on keskittyä sisällön ja tekemisen ongelmiin.

Kehitysideat tulee kirjata. On myös päätettävä niiden ottamisesta sopivan sprintin tehtävä-listalle. Mikään ei ole niin turhauttavaa kuin kehitettävien asioiden ja ideoiden kerääminen retrospektiivissä, mikäli kukaan ei ryhdy ak-tiivisesti toteuttamaan ehdotettuja parannuk-sia.

DOKUMENTOINTI

Ketterässä filosofiassa toimiva ohjelmisto on ensisijainen asia suhteessa dokumentaatioon. Tämä ei suinkaan tarkoita sitä, ettei doku-mentaatiota pitäisi laatia lainkaan. On kui-tenkin syytä kriittisesti pohtia, mitä doku-mentaatiota todella tarvitaan ja millä mene-telmillä dokumentteja tehdään. Myös doku-mentit voidaan tuottaa ketterästi (esimerkiksi wikin avulla).

Puhuminen on hyvin tehokas tapa kommuni-koida, mutta kirjallista dokumentaatiota ei tulisi unohtaa. Alistair Cockburnin artikkelis-sa 3todetaan, että kaksi ihmistä saman pöydän äärellä on selvästi tehokkaampi kommuni-kointitapa kuin yksisuuntaisen paperimateri-aalin käyttö. Lisäksi osa ihmisistä suhtautuu nykyisin esimerkiksi sähköpostiin puhtaasti tiedotusvälineenä, ei kommunikointityökalu-na. Tämä kannattaa pitää mielessä, kun uudet ihmiset perehtyvät toimintaympäristöön.

Tarina: Puuttuva dokumentaatio ja tiimin vaihto

Eräässä projektissa mukana olleet työntekijät irtisanoutuivat ja yhtiöön jääneillä työnteki-jöillä ei ollut juurikaan tietoja koko projektis-ta. Ketterästi toteutetussa projektissa asioita oli käsitelty runsaasti puhumalla, joten vaati-mukset sekä järjestelmän tuntemus olivat jääneet suurelta osin dokumentoimatta. Uusi-en kehittäjien aloittaessa heillä oli vaikeuksia

3 Cockburn A. 1999. Characterizing people as non-linear, first-order components in software development

saada otetta projektista. Asiakaskin oli alka-nut tulla kärsimättömäksi odotettuaan puoli vuotta uusia toimintoja. Kun uudet kehittäjät yrittivät tiedustella varovasti järjestelmän toiminnasta, asiakkaalta tuli melkoisen tulista tekstiä takaisin. Kehittäjät kuluttivat pitkän tovin jo selvittäessään pelkkää sovelluksen käyttötarkoitusta, puhumattakaan sen toi-mintojen ymmärtämisestä. Kehittäjät saivat loppujen lopuksi selvitettyä asiat ja toiminnot toteutettua. Samalla vastaavan varalle tehtiin dokumentaatio, mikä vaati huomattavasti työtä.

JUURI SOPIVASTI DOKUMENTAATIO-TA

Runsaan dokumentaation olemassaolo ei ole itseisarvo. Useimmiten tärkeintä on doku-mentaatiosta käyty keskustelu: millaista do-kumentaatiota juuri kyseisessä tilanteessa tarvitaan, jotta tiimi, projekti tai tuote edistyy. Kannattaa muistaa, että dokumentaatio on myös työväline. Dokumentoiminen auttaa jäsentämään ajatuksia, dokumentaatioon saa kerättyä kokonaisuudeksi eri henkilöiden ajatuksia, jolloin dokumentaatiosta on enem-män kuin osiensa summa.

Useimmiten kannattaa myös harkita, pitäydy-täänkö dokumentaation vakiomallipohjissa ja niiden tuomissa raameissa. Toisinaan pohjia kannattaa muokata, lisätä puuttuvia näkö-kulmia tai poistaa tarpeettomia. Lisäksi on syytä harkita myös, mitä muotoa on parasta käyttää. Dokumentaatiota tehtäessä kannat-

taa ottaa lukijakunta huomioon: toimisivatko graafit, diagrammit ja kuvat kenties paremmin kuin vapaamuotoinen proosa – vai juuri toi-sinpäin. Tiimi ja sidosryhmät sopivat doku-mentaation muodosta ja tarvittavasta doku-mentaatiotasosta.

Tarina: Liika on liikaa

Eräs asiakasorganisaatio siirtyi ensi kokeiluna vesiputousmallista ketterään, scrumista joh-dettuun toimintatapaan. Keskusteltiin doku-mentaatiosta ja todettiin, että ketterää kehi-tystä voidaan kyllä tehdä, mutta dokumentaa-tion pitää olla yhtä perusteellista kuin ennen-

kin. Kyseisessä vakuutussektorin organisaati-ossa tämä tarkoitti yksityiskohtaisen tarkkaa määrittelyä. Sprinttimalli toi esiin, että työ-määristä yli puolet kului pelkästään doku-mentaation tekemiseen. Perinpohjainen do-kumentointi ei kuitenkaan palvellut tekemis-tä.

Dokumentaation oleellisuudesta voidaan olla montaa mieltä. Keskeinen oppi tässä on kui-tenkin se, että dokumentaatio on syytä jakaa siihen, mitä 1) tarvitaan ylläpitoa varten ja mitä 2) tarvitaan tehdessä. Tekemistä tukevan dokumentaation kehittäminen ja muuntami-nen ketterämpään suuntaan vienee tässä ta-pauksessa vielä vuosia.

KÄYTTÖÖNOTTO

Ketterään tuotekehitykseen sisältyy jatkuvan käyttöönoton (continuous deployment) peri-aate. Toisaalta muistutetaan, että kyky jul-kaista ei tarkoita pakkoa julkaista. Ketterissä projekteissa myös käyttöönotto voidaan suunnitella vaiheittain. Esimerkiksi pilotit voidaan suunnitella tehtäväksi sopivalla in-krementillä ja sisällyttämällä niistä saadut uudet käyttäjätarinat tai muutokset tuotteen kehitysjonoon.

Tuotesuunnitteluun kuuluu se, että on päätet-tävä, milloin kyseiseen julkaisuun liittyviä uusia käyttäjätarinoita ei kirjoiteta lisää, mit-kä tarinat siirretään seuraaviin julkaisuihin ja mitä päätetään yksinkertaisesti jättää koko-naan toteuttamatta. Tähän suunnitelmaan sisältyy myös se ajatus, että tietty jakso kes-kittyy tuotantoon siirtoon priorisoimalla vi-kakorjaukset tehtävälistalla korkeimmalle. Ennen tätä jaksoa on kaikkien tarvittavien refaktorointien ja koodihaarojen yhdistämis-ten oltava myös tehtynä. Tämä on välttämä-töntä, jotta viimeisen jakson hyväksymistes-taus voidaan tehdä riittävän stabiililla ja tuo-tantoon tarkoitetulla koodilla. Tuotantoon siirron jaksolla voidaan tarvittaessa aloittaa myös uuden julkaisun tekeminen jakamalla koodi tuotantoon menevään haaraan ja tuote-kehityshaaraan. Näin tuollakin jaksolla voi-daan jatkaa normaalia kehitystyötä ja samalla taata, että tuotantoversioon tehdään pelkäs-tään korjauksia. Huono puoli asiassa on tie-tenkin se, että monet korjauksista on tehtävä sekä tuotantohaaraan että tuotekehityshaa-raan.

Hyväksymistestauksessa on muistettava se, että siinä ei enää testata mitään ominaisuutta ensimmäistä kertaa. Lähtökohtaisesti testauk-sesta ei enää odoteta löytyvän virheitä. Jos tässä vaiheessa vikoja löytyy paljon, ne tulee käsitellä niin, että vain julkaisua estävät viat korjataan. Loput korjaukset siirretään seuraa-viin julkaisuihin. Suuret vikamäärät kielivät koodin heikosta laadusta ja teknisestä velasta, joten asia on otettava puheeksi retrospektii-vissä.

Esimerkiksi mobiilisovelluksissa tuotantoon siirto voi sisältää myös jakelukanavan omia testauksia. Nämä testit voivat aiheuttaa vii-vettä ja virheilmoituksia. Laajemmissa järjes-telmissä tuotantoon siirto voi olla hyvin mo-nimutkainen prosessi, joka vaatii tarkkaa en-nalta suunnittelua. Itse tuotantoon siirto voi aiheuttaa tuotantokatkoksen, josta on hyvissä ajoin ilmoitettava loppukäyttäjille. Tuotan-toon siirtoon sisältyy myös tarvittava kelpuu-tus, jolla varmistetaan, että tuote ja palvelu toimivat tuotantoympäristössä. Tässä vaihees-sa ei yleensä voida tehdä mitään laajamittaista testausta. Ongelmien ilmetessä voidaan tehdä ainoastaan palautus, eli aiottu tuotantoon siirto peruutetaan ja entinen, toimiva sovellus palautetaan käyttöön.

Tarina: Jatkuva julkaisu

Eräässä projektissa tuotantoon julkaiseminen muutettiin jatkuvaksi prosessiksi. Uudet ominaisuudet ja muutokset siirtyivät tuotan-toon sitä mukaa kun ne valmistuivat. Projek-

tin tuottama järjestelmä oli web-sovellus. Ennen jatkuvaan päivitykseen siirtymistä käyttäjäkunta oli jo tottunut kuukausittaisiin julkaisuihin. Päivittäisten julkaisujen muka-naan tuomat ominaisuudet kerättiin edelleen totuttuun malliin kuukausikirjeisiin. Toisi-naan sovellukseen tuotiin sellaisia ominai-suuksia, joista tiedottaminen ennakkoon ko-ettiin tarpeelliseksi. Tällöin tiedottaminen synkronoitiin asennuspäivän kanssa.

JATKUVA KEHITTÄMINEN

Perinteisissä projekteissa puhutaan ylläpidos-ta, jonka kustannus on vanhojen oppien mu-kaan 80 prosenttia tuotteen koko elinkaaren kustannuksista. Ketterässä tuotekehityksessä olisi hyvä puhua ylläpidon sijaan jatkuvasta kehittämisestä. Elävä ja käytössä oleva ohjel-misto tarvitsee aina ylläpitoa – ei kannata petkuttaa itseään ajattelemalla, että ohjelmis-ton voi vain jättää nykytilaansa.

Tuotekehitysprojektin päätyttyä ylläpito voi siirtyä omaan tiimiinsä tai pysyä nykytiimin vastuulla. Ylläpitoon sisältyy myös uusien ominaisuuksien kehittelyä sen pohjalta, mil-laisia muutospyyntöjä käytön aikana kirja-taan.

Jatkuvalla kehittämisellä säästytään perintei-seltä ”alkuräjähdys, uusi projekti, nyt korja-taan kaikki" kierteestä. Kierteessä perustetaan yhä uusia projekteja joilla yritetään ratkaista jatkuvasti samoja ongelmia. Organisaation tulee ymmärtää pitkäkestoisen työn ja projek-tiorganisaation matkan aikana keräämän hil-jaisen tiedon arvo. Määritelmänsä mukaisesti hiljaista tietoa on hankala konkretisoida. Hil-jaisen tiedon arvo kumuloituu strategisesti, eikä se ole helposti siirrettävissä uudelle pro-jektiorganisaatiolle. Kyseessä on suuri siirty-misprosessi, joka on suunniteltava hyvin.

OHJELMISTOKOODIN KOKONAISHINTA

Kustannuksia laskettaessa on järkevää arvioi-da eri vaihtoehtojen kokonaishintoja (total cost of ownership, TCO). Kokonaishintaan sisältyy hankintahinnan lisäksi kaikki muut kustan-nukset, mm. ylläpitokustannukset.

Ohjelmiston koodia muutetaan lähes aina sen jälkeen, kun se on alun perin kirjoitettu. Koo-dia muutettaessa siihen on perehdyttävä eli sitä on luettava. Itse asiassa koodaajat lukevat vanhaa koodia paljon enemmän kuin kirjoitta-vat uutta. Tämän takia koodin luettavuuteen tulee kiinnittää huomiota, silloin kun koodia kirjoitetaan. Hyvin kirjoitettu ns. puhdas koodi on helppoa lukea ja ymmärtää. Tämä tarkoittaa, että koodin korjaamiseen ja edel-leen työstämiseen kuluu vähemmän aikaa. Puhtaan koodin ylläpito maksaa vähemmän kuin sellaisen koodin, joka on vaikealukuista ja hankalaa ymmärtää.

Koodin muuttaminen on myös huomattavasti helpompaa, mikäli koodille on kirjoitettu hy-vät yksikkötestit. Hyvät yksikkötestit toimi-vat paitsi refaktoroinnin mahdollistajana, myös koodin dokumentaationa. Koodiin lisä-tyt kommentit voivat joskus auttaa koodin ymmärtämisessä, mutta hyvin kirjoitettu puhdas koodi yksikkötesteillä katettuna eli-minoi koodia dokumentoivien kommenttien tarpeen. Koodikommentit voivat olla jopa vaarallisia. Näin käy silloin, mikäli koodia muutetaan, mutta kommentteja ei muisteta päivittää vastaamaan muuttunutta koodia.

Puhtaan koodin ominaisuuksia ovat muun muassa seuraavat:

koodi tekee vain sen, mitä sen on tar-koitettu tekevän

koodin yhden kohdan muuttaminen ei vaadi muutoksia koodin sellaisiin osiin, jotka eivät liity loogisesti muu-tettavaan koodiin

luokat ja funktiot ovat pieniä

koodi on yksinkertaista (mittana voi-daan käyttää esimerkiksi syklomaat-tista kompleksisuutta)

riippuvuuksien määrä on minimoitu

koodille on laadittu kattavat yksikkö- ja hyväksymistestit

luokat, funktiot ja muuttujat on ni-metty kuvaavasti.

Koodin kokonaishintaa laskettaessa tulee ottaa ennen kaikkea huomioon sen ylläpidet-tävyys. Aika, joka kuluu koodin ensimmäisen version kirjoittamiseen, on vain murto-osa siitä ajasta, joka kuluu koodin ylläpitämiseen. On hyvä ajatus kirjata tiimin valmiin määri-telmään asioita, jotka tekevät koodin ylläpi-dosta helpompaa. Myös tuoteomistaja voi määritellä käyttäjätarinoiden hyväksymiskri-teereihin ylläpidettävyyttä edesauttavia koh-tia.

JÄRJESTELMÄKEHITYKSEN KOKO-NAISHINTA

Jatkuvassa kehittämisessä tai ylläpidossa yksi organisaation huolenaihe on järjestelmän ko-konaishinta. Järjestelmän kokonaishinta koos-tuu työkaluista, lisensseistä, ammattitaitoisis-

ta tekijöistä, operatiivisen tuen ja markki-noinnin kuluista. Vuosibudjetteja tulee ja menee; niissä seurataan organisaation panos-tusta tiimeittäin ja toiminnoittain eri tasoilla.

Yksittäisen tuotteen omistamisen kokonais-hinta voi hämärtyä vuosien varrella. Ihmiset vaihtuvat organisaatiossa. Tuotteen koko-naishyödyn ja kulujen laskelma voi unohtua, tulla epäselväksi tai kiinnostus laskelman seuraamiseen voi kadota organisaatiomuutok-sissa. On muistettava aina laskea sekä konk-reettiset hyödyt (tuotot asiakkailta) että epä-suorat hyödyt, joita tuote tuo esim. goodwill ja asiakastyytyväisyys.

Kannattaa aina muistaa, että uudella tietojär-jestelmällä ei voida ratkaista kaikkia liiketoi-minnan ongelmia. Joskus Suuren ja Mahtavan Ohjelmistohankkeen käynnistämisen sijaan parempi vaihtoehto on muokata prosessia, sopia yhteisiä käytäntöjä käyttäjäryhmien kesken, harmonisoida tekemistä jne. ennen kehitysprojektin alkua. Kun ohjelmistoa ale-taan tehdä, niin onnistumisen yhtenä mittari-na voi pitää kuinka kauan järjestelmää voi käyttää. Kun järjestelmää käytetään, seuraa kuluja. On pyrittävä mittaamaan hyödyt ja kulut ja selvittämään jo alussa päästäänkö plussan puolelle. Jos näyttää hyvältä, niin siitä vain ketterät ammattilaiset töihin ja hankki-maan lisää ketteriä kokemuksia.

KETTERÄ LIIKETOIMINTA

Yrityksen johto ”ostaa” ketteryyden usein kustannuksien säästäjänä. Valitettavasti useat toimittajat pyrkivät myymäänkin sen tällaise-na hopealuotina. Ketteryydestä oppineet asi-antuntijat taas myyvät ketteryyttä työkaluna, joka helpottaa muutosten tekemistä ja hallin-taa kehittämisen aikana. Sekä kustannussääs-töjä että työn tehokkuutta toki tavoitellaan ja molempia todennäköisesti saadaankin, tosin välillisesti. Mutta ovatko nämä tekijät todel-lakin niitä tekijöitä, joilla on suurin arvo liike-toiminnalle?

Nykyaikaisen liiketoiminnan kannalta arvok-kaita asioita ovat mm.:

läpimenoaika maksavien asiakkaiden tyytyväisyys

tuloksen ja tekemisen laatu ja

läpinäkyvyys, josta seuraa ohjattavuus ja ennustettavuus.

Parhaimmillaan näitä hyötyjä saadaan ketteriä menetelmiä soveltamalla. Mikään yksittäinen ketterä menetelmä (esim. scrum) ei kuiten-kaan näitä takaa. Seuraavissa luvuissa käy-dään läpi asioita, jotka kokemusten perusteel-la vaikuttavat onnistumiseen eniten.

EROON KÄSKYTTÄMISESTÄ

Kun organisaatio on päättänyt ottaa ketteriä menetelmiä käyttöön, johtaja törmää jokseen-kin ensimmäiseksi tiimien itseohjautuvuuden käsitteeseen. Aluksi se saattaa näyttää varsin isolta peikolta. Mihin johtamista (eli siis joh-

tajia) enää tarvitaan, jos tiimit alkavat itse johtaa itseään?

Keskijohdon vastuulla on perinteisesti ollut tiimien välisten riippuvuuksien ja ongelmien käsittely ja ratkaisu, uusien ihmisten rekry-tointi, työntekijöiden palkitseminen ja irtisa-nominen. Projektin johdolla on vastuu projek-tin onnistuneesta läpiviennistä. Hyvin toimiva jatkuvan integroimisen järjestelmä ja tiimien valtuuttaminen poistaa tarpeen käyttää keski-johtoa tiimien välisten riippuvuuksien ja on-gelmien ratkaisijana. Kun tuotekehityksen tiimit suunnittelevat yhdessä seuraavan in-krementin, tiimit myös sopivat mahdollisia ongelmia varten vastuuhenkilön. Ainoastaan kaikkein hankalimmat, usean tiimin koor-dinointia koskevat ongelmat jäävät enää kes-kijohdon ratkaistavaksi.

Palveluorganisaation toimintaketju on usein asiakaspalvelutehtävissä istuvien työntekijöi-den välinen tai yhdessä tekemä työsuorite. Mitä enemmän palveluorganisaatiossa tapah-tuvia töitä voidaan virtaviivaistaa ja niistä poistaa hukkaa, sitä tehokkaampi kyseinen palveluorganisaatio on. Tällainen tuotekehi-tyksen johtaminen ja toiminnan parantami-nen, on eräs keskijohdon tärkeimmistä tehtä-vistä. Organisaation oppiminen ja tehokkuus on pitkälti sidoksissa siihen, miten nopeasti organisaatio pystyy ratkomaan toimitusket-jussa olevia ongelmia. Johdon käyttämä kan-ban-taulu ja siinä olevien tikettien läpi-menoajan seuraaminen ovat tähän hyviä työ-kaluja.

Tarina: Eri organisaatiotasoilla omat kan-ban-taulut

Eräässä ison tuotekehitysorganisaation pro-jektissa ymmärrettiin, että keskijohdon ja ylimmän johdon keskeinen tehtävä on ratkoa niitä kompleksisia ongelmia, joita tiimit olivat löytäneet retrospektiiveissä. Keskijohdolla, projektijohdolla ja jopa ylimmällä johdolla oli omat kanban-taulunsa, joihin ongelmat kirjat-tiin tiketteinä. Ongelmien ratkaisut ja läpi-menoajat tulivat siten kaikkien näkyville. Organisaation kyky oppia uutta, kehittää toimintaansa ja tehdä toimitusketjusta lean-filosofian mukainen on pitkälti sidoksissa organisaation kykyyn ratkoa ongelmia. Johta-jien kanban-taulu sai kyseisen projektin ta-kaisin raiteilleen, kun projekti oli jo pahasti karkaamassa hallinnasta.

Maaritin teoreema. Organisaation kyky tehdä muutoksia ja uudistua on suoraan verrannollinen kykyyn, jolla retrospek-tiiveissä esille nousseita ongelmia pystytään sovittelemaan ja ratkaisemaan.

PROJEKTIN JOHTAMISESTA PROJEKTIN FASILITOINTIIN

Onko projektinjohto sitten jatkossa pelkäs-tään ongelmien ratkaisemista? Miten projek-tin voi viedä onnellisesti läpi ilman käskyttä-mistä? Ratkaisu tähän on inkrementtien suunnittelu ja inkrementeittäin johtaminen. Inkrementti koostuu tyypillisesti noin neljäs-tä–kuudesta sprintistä. Isonkin tuotekehitys-projektin voi johtaa maaliin vaikkapa kuudella inkrementillä. Johtajan tehtävä on asettaa tiimeille kunkin inkrementin yhteiset tavoit-teet.

Projektin onnistunut läpivienti vaatii näky-vyyttä jo tehtyihin toiminnallisuuksiin. Johta-jan tehtävä on ohjata tehtyjä päätöksiä met-riikkaan perustuen: miten projekti voidaan saada maaliinsa annetussa ajassa? Sen sijaan tarpeetonta on, että johtaja piiskaisi tiimiä täyttämään tavoitteet ja saamaan projektin valmiiksi tiettyyn päivämäärään mennessä. Aikataulussa pysymisen kysymys annetaan koko projektin henkilöstön yhdessä ratkaista-vaksi. Tehtävistä toimenpiteistä sovitaan yh-dessä, mikä takaa kaikkien projektin jäsenten

sitoutumisen. Näin scrumissa tapahtuva tii-mien valtuuttaminen laajenee tarkoittamaan koko projektin valtuuttamista.

Projektinvetäjältä vaaditaan käskemisasen-teen sijasta ensisijaisesti hyviä fasilitoijan ja valmentajan taitoja. Entinen projektinvetäjän ongelma (miten projekti saadaan maaliin aika-taulussa) siirtyy yhteiseksi ongelmaksi. Koko projektin onnistuminen on kaikkien harteilla; koko projekti myös kantaa seuraukset. Onnis-tuneet projektit takaavat tekijöilleen lisää töitä yhdessä, epäonnistuneet projektit päät-tyvät henkilöstön hajaantumiseen. Edellä ole-va tietysti edellyttää, että ylin johto toimii rationaalisesti, ts. palkitsee onnistumisista. Joissakin firmoissa vallalla oleva ”mikään ei riitä” suuntaus on varsin surullinen. Onnis-tuneetkin projektit lopetetaan, jos onnistumi-nen on yltiöpäisillä tavoitteilla mitattuna ”lii-an vähäistä”.

On huomattava, että edellä olevassa sanaa projekti ei ole käytetty perinteisessä mielessä. Ketterä tekeminen muuttaa itse tekemisen jatkuvaksi toiminnoksi. Projektien käynnis-tämiseen ja lopettamiseen liittyy aivan liian paljon hukkaa. Silti vain pelkästä ohjelmistos-ta koostuvan tuotteen toimitus voi toimia jatkuvalla periaatteella. Fyysisiin tuotteisiin liittyy aina tietty transaktiokustannus. Tällöin ”projekti” on käsitettävä joukoksi ketterän toimitusketjun inkrementtejä, jotka on vain paketoitu yhteen tuotteeseen/tuoteversioon.

Johtajien tehtävä ihmisten rekrytoijana, pal-kitsijana ja irtisanojana ei ole kadonnut min-nekään. Joskus scrum-tiimit tarvitsevat johta-jien apua myös tiimin sisäisten kiistojen sovit-teluun, kun tiimin muodostuksen kuohunta-vaihe käy liiankin kiivaaksi. Sovitteluhan on perinteisesti Scrum Masterin tehtävä, mutta storming-vaihe voi päätyä myös siten, että tiimi ei pystykään tulemaan toimeen keske-nään. Tällöin tiimi saattaa päättää, että jon-kun tiimin jäsenen on lähdettävä. Joku tiimin jäsenistä voi myös itse päättää lähteä. On näh-ty myös Scrum Mastereita, jotka päättävät ratkoa ristiriitatilannetta noin vain tiimiä käskyttämällä. Tällaisessa tilanteessa hyvä linjaesimies muistuttaa Scrum Masteria hänen alkuperäisestä roolistaan.

On hyvä huomata, että tällainen kuohunta on täysin normaalia ja kuuluu asiaan ennen kuin tiimit voivat todella toimia tehokkaasti. Tiimit

muotoutuvat muodostusvaiheen, kuohunta-vaiheen, vakiintumisvaiheen ja kypsän toi-minnan vaiheen kautta. Muodostusvaiheessa tiimi sopii työskentelymenetelmistä, esimer-kiksi ”tämä tiimi käyttää scrumia”. Kuohuntaa tapahtuu, kun tiimin jäsenten keskinäiset arvot ja ajatukset menevät ristiin keskenään. Tiimi saattaa esimerkiksi antaa palautetta jäsenelleen, joka aina ilmestyy päivittäiseen scrum-palaveriin myöhässä. Vakiintumisvai-heessa tiimi sopii yhteisistä pelisäännöistä (tai sovittaa pelisäännöt juuri kyseisen tiimin tar-peeseen). Kypsän toiminnan vaiheessa tiimi on tuottavimmillaan.

Kyseiset vaiheet ovat havaittavissa myös siinä, miten toimintatapojen muutos isoissa organi-saatioissa tapahtuu. Johtajien eräs tehtävä on juuri tämän muutoksen johtaminen. Ensim-mäisessä vaiheessa kerrotaan yleiset toiminta-tavat esim. kuinka kyseisessä organisaatiossa ketteryyttä toteutetaan. Seuraavassa vaiheessa organisaation keskeiset mielipidejohtajat käy-vät leireineen keskustelua, onko toteutettu muutos hyvästä vai pahasta. Tämän perusteel-la seuraa uusi normi. On huomattava, että kuohuntavaiheessa käyty keskustelu pohjau-tuu usein paljolti ihmisten mielikuviin ja vai-kutelmiin. Mitä enemmän tämän keskustelun tueksi voidaan tarjota mitattua dataa, sitä parempi on lopputulos.

Tarina: Hiljainen, tyytyväinen enemmistö

Eräässä tuotekehitysorganisaatiossa tehtiin päätös, että kaikkien tuotekehitystiimien on noudatettava scrumia. Yleinen vaikutelma oli, että muutos oli pahasti epäonnistunut, koska kovaäänistä kritiikkiä esiintyi niin runsaasti. Organisaatiossa päätettiin tehdä kysely sen selvittämiseksi, mikä on organisaation todel-linen mielipide. Selvisi, että yli 70 prosenttia oli muutoksen puolesta ja vain alle 10 prosent-tia vastusti sitä. Iso, hiljainen ja tyytyväinen enemmistö ei pitänyt meteliä asiastaan. Mieli-pidekartoituksen seurauksena muutos jäi pysyväksi. Organisaatio päätti jatkossakin tehdä laajoja mielipidekyselyitä sen sijaan, että kuunneltaisiin muutamien äänekkäiden yksittäisiä mielipiteitä.

Johtajatyypeistä

Johdon tehtäviin kuuluvat henkilöstön palk-kaamiseen ja ohjaamiseen liittyvät tehtävät,

toiminnan parantaminen ja muutoksen joh-taminen. Käskyttämistä ei enää tarvita, vaan palvelevaa johtamista.

Johtajat voidaan jakaa asiantuntijajohtajiin, koordinaattoreihin sekä ihmisten kehittämi-seen tähtääviin johtajiin. Asiantuntijajohtaja on tyypillisesti henkilö, joka on juuri ylennet-ty tehtäväänsä. Tämän johtamistyylin etuna on, että asiantuntijajohtajat osaavat antaa yksityiskohtaista apua johtamilleen tiimeille. Riskinä tai haittana on se, että johtaja ryhtyy helposti mikromanageeraamaan alaisiaan. Mikromanageeraus ja käskyttäminen ovat asioita, joista ketterässä tuotekehityksessä yleensä halutaan eroon. On parempi antaa kokemattomalle tiimin jäsenelle kokeneempi opastava pari kuin tehdä niin, että esimies ohjaa harvakseltaan mutta yksityiskohtaisesti tekemistä.

Koordinaattorijohtaja osaa orkestroida isoja organisaatioita toimimaan yhteistyössä tavoit-teen saavuttamiseksi. Tällaiseen johtamiseen liittyy tyypillisesti se, että johdetuilla henki-löillä tai organisaatioilla on kapeita osaamis-alueita. Ketterässä kehityksessä kapeista osaamisalueista ja organisaatioiden siiloista halutaan nimenomaan eroon. Mikäli tiimien tai organisaation osien itseorganisoituminen ei tapahdu halutulla tavalla, tarvitaan koor-dinaattorin apua. Liiallisen koordinoinnin tilanteessa on kuitenkin olemassa riski, että koordinaatio johtaa itseohjautuvuuden puut-teeseen, passivoitumiseen ja siihen, että kaikki työskentelevät vain kovemmin ja kovemmin. Tällöin ei oivalleta sitä potentiaalia, jonka yhteistoiminta voisi vapauttaa.

Johtaja, joka toimii ihmisten kehittämiseksi, on palveleva (tai valmentava) johtaja. Hän on ymmärtänyt, että johtaminen on ihmisten valmentamista. Tällaista johtamista pidetään usein ”todellisena johtajuutena” ja tällaiset johtajat ovat alaistensa arvostamia ja kunni-oittamia. Tällaiset johtajat ovat tyypillisesti hyviä motivoimaan toisia ja he myös jakavat kunnian tuloksista kaikille. He tyypillisesti näkevät oman roolinsa osana isoa jatkumoa ja kokevat suurta yhteisöllistä vastuuntuntoa.

Koska ketterässä kehitysmallissa johtajuuden mitta ei ole enää organisaation koko (organi-saation koko saattaa vaihdella joustavasti), muotoutuu johtajan tehtäväksi myös verkos-toituminen ja verkostojohtaminen. Johtami-

sesta tulee toimintaa sen sijaan, että se olisi rooli. Verkostosta joku ottaa jonkun tehtävän (virtuaaliprojektin, esteen poistamisen tms.) hoidettavakseen. Häntä arvioidaan sen perus-teella, miten hyvin hän tehtävästä suoriutuu. Verkostojen arvo on siinä, että verkosto löytää helpommin täsmäasiantuntijuutta kuhunkin käsillä olevaan tehtävään. Hyvä verkostoitu-minen auttaa siis hoitamaan tehtäviä entistä paremmin.

LÄPIMENOAIKA

Pelkästään ICT-kehitystä (määrittely, suun-nittelu, toteutus, testaus) ketteröittämällä ei kehityksen läpimenoaika (ideasta tuotantoon) juurikaan lyhene. Myös monia muita ICT-kehitystä ympäröiviä asioita on tarpeen muut-taa.

Useilla organisaatioilla on raskaita päätösme-nettelyitä, jotka on läpäistävä ennen kuin ideaa voidaan ryhtyä toteuttamaan. Päätök-senteon pohjaksi joudutaan laatimaan paljon dokumentteja ja suorittamaan tarkkoja kus-tannuslaskelmia. Päätöksentekoon osallistuu iso joukko ihmisiä, jotka pahimmassa tapauk-sessa joutuvat vielä hakemaan hyväksyntää kukin omilta tahoiltaan. Tarjouspyyntöjen laatiminen, hankkeiden laajuuden arviointi, tarjousten odottaminen ja arviointi voivat kestää kauan, joskus jopa kauemmin kuin itse kehitystyö. Päätöksiin kuluvaa aikaa pitäisi merkittävästi lyhentää.

Läpimenoaika lyhenee merkittävästi, jos käy-tettävissä on valmis kehitystiimi, jonka työlis-talle kehitystyö saadaan. Monet organisaatiot ovat tilanteessa, jossa kehitystyö organisoi-daan kertaluonteiseksi projektiksi, jolloin kehitystyön käynnistämiseen – ennen kaikkea resursointiin – kuluu paljon aikaa.

Yleensä organisaatiot ovat ymmärtäneet, että kehitystiimin jäsenet pitäisi kiinnittää vain yhteen kehitystyöhön (tiimiin) kerrallaan. Töiden vaihtaminen luo aina lisävaivaa ja siten hidastaa läpimenoaikaa. Usein kuitenkin unohdetaan, että sama pätee myös liiketoi-minnan edustajiin. Tuoteomistajalla saattaa olla vastuullaan useita eri projekteja, jolloin kehitystiimi voi joutua odottamaan tuote-omistajan päätöksiä. Samantyyppinen ongel-ma nousee esiin myös niissä organisaatioissa, joissa päätöksentekoon tarvitaan laaja joukko

henkilöitä. Elävässä elämässä liiketoiminnan henkilön suusta kuultua: ”Pomo toi työpöy-dälle taas yhden projektin, meneehän se siinä viiden muun projektin sivussa.”

Läpimenoaikaa voidaan lyhentää karsimalla tarpeetonta monimutkaisuutta. Samalla voi-daan parantaa myös asiakastyytyväisyyttä. Perinteisestä vaatimusmäärittelystä ja vaati-musten priorisoinnista seuraa usein, että liike-toiminta ei pysty näkemään, mitkä toiminnal-lisuudet ovat aidosti tärkeitä ja mitkä voitai-siin jättää pois. Usein liiketoiminnan ensim-mäiset kommentit ovatkin, ettei mitään toi-minnallisuutta voida jättää pois. Tietojärjes-telmien käyttäjät kuitenkin kokevat yleisesti, että tietojärjestelmät ovat liiankin monimut-kaisia ja sisältävät ominaisuuksia, joita he eivät tarvitse. Kun vaatimusten ja tuoteomi-naisuuksien priorisointia aletaan vaatia sys-temaattisesti, opitaan näkemään oleelliset asiat. Joitakin asioita voidaan jättää kokonaan pois, ja joitakin asioita voidaan hoitaa muulla tavalla kuin ominaisuuksia lisäämällä, esim. toimintatapoja muuttamalla.

Isoissa yrityksissä läpimenoaikaa voi lyhentää myös massiivinen kehitystyön ulkopuolinen ohjaus (mm. riskienhallinta ja yritysarkkiteh-tuuripolitiikat). Jos ohjaus perustuu tiukkaan ja määrämuotoiseen ulkopuolisen tahon do-kumentteihin perustuvaan hyväksymiskäy-täntöön, kehitystyö hidastuu merkittävästi. Parempi käytäntö on pitää vain todella tärkeät asiat tällaisen ohjauksen alla. Silloinkin ohjaa-vien tahojen tulee vaikuttaa työhön vain sil-loin, kun se on ajankohtaista. Voimakkaan ohjauskulttuurin sijaan hyödyllisempää olisi panostaa siihen, että kehitystiimeissä on val-miiksi tarvittava osaaminen.

Yhtäaikaisten kehitystöiden ja projektien määrä on syytä pitää läpimenokyvyn puitteis-sa. Kullakin kehittäjällä saa olla vain yksi työ kerrallaan käynnissä. Kehitystoimia saadaan tehtyä enemmän, kun ne ovat peräkkäin sen sijaan että niitä yritetään tehdä rinnakkain. Asioiden aloittaminen ei vielä takaa, että ne saadaan päätökseen.

ASIAKKAIDEN TYYTYVÄISYYS

Asiakkaalla tarkoitetaan tässä yhteydessä todellista loppuasiakasta. Asiakas saadaan tyytyväiseksi, kun hänelle tehdään oikeita

tuotteita ja palveluja oikea-aikaisesti. Kette-rässä kehittämisessä tärkeimmät asiat teh-dään aina ensin. Usein tärkeimmät asiat ovat niitä, joilla on suurin arvo asiakkaalle.

Ketteryys mahdollistaa iteratiivisen kehityk-sen sekä varhaisen palautteen saannin todelli-silta käyttäjiltä. Oikeat asiakkaat (koke-musasiakkaat) pitää saada työhön mukaan jo varhain. Ei siis riitä, että asiakkaita edustaa joku liiketoimintaosastolla työskentelevä ko-kemuskäyttäjä. Tarvitaan ymmärrys loppu-asiakkaista, loppukäyttäjistä ja heidän tar-peistaan.

Projektiorientoituneissa organisaatioissa on-gelmana on usein, että kehitystyössä ei oteta asiakasta huomioon kokonaisvaltaisesti. Sa-malle asiakkaalle suunnattuja palveluita saat-taa tehdä usea eri projekti kukin omilla tahoil-laan. Tällöin lopputuloksena on yleensä asi-akkaan kannalta tilkkutäkki. Projektimaiseen kehitykseen liittyy toinenkin ongelma. Usein kehitystyössä huomataan, että kokonaisuuden kannalta jokin asia kannattaisi tehdä toisin, kuin projektissa alun perin ajateltiin. Valitet-tavan harvoin suuntaa kuitenkaan muutetaan.

LAATU

Laatu on moniselitteinen käsite ja koostuu monesta osatekijästä. Laatua voivat olla esim. onnistunut käyttökokemus tai tekninen toi-mivuus. Tekninen toimivuus varmistetaan mm. kyvykkäällä ja motivoituneella kehitys-tiimillä, testauslähtöisellä kehitystyöllä sekä lyhyillä kehittämissykleillä, joissa lopputulos on aina valmis ja myös testattu. Tiimi kehittää jatkuvasti omaa toimintaansa, mikä vaikuttaa laatuun myönteisesti.

Laadulla voidaan tarkoittaa myös ylläpidon laatua. Joissain organisaatioissa kehitystyö ja ylläpito on vastuutettu eri tiimeille. Tämä johtaa usein teknisen velan syntymiseen. Yleensä teknistä velkaa ei korjata, ellei siitä aiheudu isoa ongelmaa. Siinä vaiheessa kor-jaaminen onkin jo kallista.

LÄPINÄKYVYYS, OHJATTAVUUS JA ENNUSTETTAVUUS

Perinteisesti kehitystyötä ohjataan seuraamal-la toteutuneita kuluja ja valmiusastetta. Ket-terä kehitysmalli mahdollistaa kehitystyön ohjauksen painopisteen siirtymisen mennei-syyden seurannasta tulevaisuuden ennustami-seen.

Koska toimivaa ohjelmistoa syntyy jo varhain ja koko ajan, kehitystyön todellinen tilanne on hyvin tiedossa. Tällöin ei tarvitse arvailla ke-hittämisen elinkaareen perustuvia valmius-prosentteja (esim. 80 % määritelty), jotka eivät todellisuudessa kerro juuri mitään. Työn ohjaamisen kannalta on mielekkäämpää tie-tää, mitkä ominaisuudet ovat valmiina kuin missä vaiheessa kaikkien ominaisuuksien kehitystyö on. Tiedon perusteella pystytään tekemään sangen luotettavia ennustuksia siitä, mikä on tiimin kyky tuottaa uusia omi-naisuuksia.

Scrumiin perustuvassa kehitystyössä aikatau-lu ja kustannukset (ts. resurssit) halutaan tyypillisesti pitää vakiona. Joustaminen ta-pahtuu toteutettavien ominaisuuksien mää-rässä tai toteutustavassa. Hinta on siis vakio, joten kustannusseurannan merkitys pienenee. Asiakas voi keskittyä oikeiden ominaisuuksi-en tekemiseen.

Ketterä kehitysmalli mahdollistaa siis siirty-misen kulujen seurannasta arvon seurantaan. Arvon seurannan kannalta erityisen suuri merkitys on sillä, että jo työn hyvin varhaises-sa vaiheessa nähdään toimivaa ohjelmistoa. Konkreettinen lopputulos on aina havainnol-lisempi kuin papereilla esitetyt, epämääräi-seen logiikkaan perustuvat luvut.

KANNUSTIMET JA BONUKSET

”Kysehän on vain rahasta.” Saatko ihmisen tekemään mitä vain, jos hinnasta sovitaan? Usein viitatussa TED-puheessaan The Puzzle of Motivation tutkija kertoo, että tutkimusten mukaan ne jotka ovat ”vaarassa” saada suu-rimman bonuksen annetun tavoitteen saavut-tamisesta, suoriutuivat tehtävästä heikoim-min. Vastaavanlaisia tutkimuksia on tehty kasapäin samansuuntaisin tuloksin: ulkoiset

kannustimet näyttävät häiritsevät luovaa työ-tä.

On paljon esimerkkejä siitä, mitä väärin vali-tut kannustimet voivat saada aikaan. Jos tii-mejä esimerkiksi palkitaan siitä, että vikamää-rä on pieni, saatetaan joutua tilanteeseen, jos-sa vikaraportteja hylätään kirjanpidosta tai siirretään muille tiimeille juuri ennen mittari-en laadintaa. Jos palkitsemisen perusteena käytetään tehtyjen käyttäjätarinoiden määrää, saadaan helposti julkaisuja, joissa refaktoroin-ti ja dokumentointi jätetään tekemättä.

Usein puhutaan myös nuoresta X-sukupolvesta, jolle palkka ei välttämättä ole-kaan tärkein työssä viihtymisen tekijä ja moti-vaation lähde. Työmotivaation synnyttäjiä ovatkin mielenkiintoiset tehtävät, työkaverien arvostus ja muut ei-rahalliset hyödyt. Usein oikea-aikainen kiitos ja positiivinen, rakenta-va palaute saa enemmän hyvää aikaan kuin vuoden päätteeksi saatu bonus joka on ”an-saittu” ylittämällä epämääräisten tavoitteiden keinotekoiset kriteerit.

ONNISTUMISEN MÄÄRITELMÄ

Mitä tarkoittaa onnistuminen? Miltä se näyt-tää, kuulostaa ja tuntuu? Jotta onnistuminen olisi saavutettavissa, tulee ensin sopia, mitä onnistuminen käytännössä tarkoittaa. Perin-teisessä projektinhallinnassa onnistumisen määritelmä on muuttunut viime vuosikym-menten aikana:

1960: Projektin lopputulos on toimiva

1980: Projekti pysyy aikataulussa, budjetissa ja täyttää tavoitellun sisäl-tö/laatutason (Kerzner)

1990: Projekti täyttää sisäiset suori-tusvaatimukset (aikataulu, kustan-nukset ja määritelty sisältö) ja ulkoi-set (projekti ja sen tuotos on asiak-kaiden hyväksymä)

2010: Kokonaisvaltainen onnistumi-nen, joka sisältää projektin ja tuotteen onnistumisen sekä tiedon luomisen ja levittämisen organisaatiossa (Ander-sen)

Perinteisen projektinhallinnan uudemmat näkökulmat lähestyvät ketterän kehityksen filosofiaa, jossa korostetaan sekä lopputulos-ten hyödyllisyyttä käyttäjille että kehittämi-sen jatkuvuutta. Tällöin onnistuminen on luontevaa määritellä käyttäjille tuotetun arvon ja tuotteen elinkaaren kautta. Arvontuotto mitataan viime kädessä liiketoiminnan menes-tyksellä tai epäonnistumisella, joihin vaikut-tavat tuotekehityksen lisäksi tuotteen lansee-raus, markkinointi ja myynti.

PROJEKTI VAI PROSESSI

Koko projektin käsitteen voi säännöllisesti kyseenalaistaa kysymällä, mihin projekteja tarvitaan. Projektista voi helposti tulla itse-tarkoitus, joka vaatii huomiota, paperityötä ja puuhastelua sen sijaan, että keskityttäisiin käyttäjille hyödylliseen ja arvokkaaseen lop-putulokseen. Saatetaan esimerkiksi toteuttaa jo syntyessään vanhentunut projekti, jos sille on saatu rahoitus.

Perinteinen projektimyynti johtaa usein sii-hen, että vaatimukset lukitaan etukäteen. Tällöin looginen tarve vaatimusten keskinäi-selle priorisoinnille poistuu. Ilman priorisoin-tia tuotamme väistämättä turhia ominaisuuk-sia, siis hukkaa. Ongelma voidaan välttää so-pimuksella, jossa etukäteen määritellyn sisäl-lön sijaan ostetaan kehitystiimin työaikaa. Tällöin priorisointia tehdään jatkuvasti, eikä vain kertaluonteisesti projektin alussa.

Ketterä kehitys pyrkii luomaan lisäarvoa sillä, että kehitysprosessia hiotaan pikkuhiljaa jopa vuosien ajan. Tällöin ”projekti” on vain nimi-tys kehitettävälle sisällölle sen sijaan, että se tarkoittaisin perinteistä projektia, jolle luo-daan uusi hallinto, henkilöstö, ohjausryhmä, raportointi jne. Tällaisten väliaikaisten pro-jektistruktuurien on vaikeaa kilpailla tuotta-vuudessa tai työviihtyvyydessä vuosien kulu-essa hioutuneelle pysyvälle kehitysprosessille ja organisaatiolle.

Seuraavassa on lueteltu eräitä ketterän projek-tin ja tuotteen onnistumisen mittareita:

sijoitetun pääoman tuotto (Return On Investment, ROI)

kehityksen ja ylläpidon kokonaiskus-tannukset (Total Cost of Ownership, TCO),

markkinoillemenoaika (Time to Mar-ket),

liikevoitto

markkinaosuus

tuotoksen laatu

aikataulu käyttäjätyytyväisyys

oheistuotteena syntynyt kehityspro-sessi

organisaatiossa syntyneet ihmissuh-teet.

1960-luvulta tuttu tavoite, toimiva tuote, on edelleen hyvä onnistumisen lähtökohta. Tuot-teen toimivuus ei kuitenkaan vielä takaa sopi-vuutta loppukäyttäjän tarpeeseen. 1980-luvulla alettiin korostaa perinteistä projektin-hallinnan näkökulmaa (”aika, sisältö ja bud-jetti”), johon 1990-luvulla lisättiin asiakkaan hyväksynnän vaatimus. Onko asiakkaan hy-väksyntä kuitenkaan sama asia kuin tyytyväi-nen loppukäyttäjä?

Aivan viime aikoina, 2010-luvulla on alettu mielenkiintoisesti korostaa kokonaisvaltaista onnistumista sekä organisaation oppimista, ihmissuhteita ja kehitysprosessia. Onnistu-neissa projekteissa korostuvatikin käyttäjille aidosti hyödyllinen lopputulos ja kehitysmalli, joka minimoi muutoksen hinnan, tukee tois-tuvia julkaisuja, jatkokehitystä ja siten tuot-teen elinkaarta.

Tarina: Organisaatiomallin onnistunut kehittäminen

Noin 300 hengen organisaatiossa kehitettiin hanketta, joka koostui kuudesta kehityspro-jektista. Kullakin projektilla oli oma johto-ryhmänsä. Lisäksi oli hankkeen yhteinen joh-toryhmä. Hallinnollisiin kokouksiin ja riippu-vuuksien selvittelyyn kului tällä kaksoismal-lilla merkittävästi aikaa ja rahaa. Asiakkaalle ei kuitenkaan ollut pienintäkään merkitystä sillä, montako projektia hankkeen taustalla oli. Ratkaisuna raskaaseen hallintoon projek-tien omista ohjausryhmistä luovuttiin ja ne korvattiin kaikille kuudelle projektille yhtei-sellä johtoryhmällä. Yksi ainoa johtoryhmä vastasi nyt sekä osaprojektien että koko hankkeen ohjaamisesta. Taustalla säilytettiin kuusi tuotealuetta, joiden kehitystiimit toimi-vat ketterällä prosessilla. Hallinnon muutos-ten avulla työn ohjaamiseen tarvittavaa pala-veriaikaa säästettiin vuositasolla 1,3 miljoonaa euroa. Lisäksi saatiin merkittävää hyötyä var-sinaisen kehitystyön tuottavuuden parantu-misesta.

YHTEENVETO ONNISTUMISEN MÄÄ-RITELMÄSTÄ

On syytä pohtia, tarvitaanko yksittäisiä, ai-nutkertaisia projekteja, vai kannattaisiko nii-den sijaan kehittää vahvaa prosessikulttuuria, jossa samankaltaisia projekteja voidaan to-teuttaa business as usual tyyppisesti koko tuotteen elinkaaren ajan. Kannattaa keskus-tella asiakkaan tai tuoteomistajan kanssa, kuinka ketterän projektin tai tuotejulkaisun onnistumista mitataan. Kannattaa myös pitää mielessä, että onnistuminen vaatii lähes aina oppimista ja oppiminen puolestaan epäonnis-tumista.

ASIAKAS–TOIMITTAJA-SUHDE

Monet ketteryyden haasteista näyttävät olen-naisesti erilaisilta tuotekehitysorganisaatiossa kuin kahden organisaation yhteistyössä asia-kas–toimittaja-suhteessa.

PROJEKTINHALLINNAN JA KETTERYY-DEN KOHTAAMINEN

Toisinaan tilaaja ostaa projektin puuttumatta siihen, miten toimittaja suorittaa projektin toteutuksen. Tärkeintä on haluttu tuotos. Tällöin voidaan menetellä hyväksi koetun projektinhallinnan keinoin. Sen enempää scrum kuin projektinhallinta eivät ole ristirii-dassa keskenään. Projektissa yksi tai useampi kehitystiimi tuottaa ratkaisua. Samaan aikaan muu projektiorganisaatio huolehtii itse toteu-tuksen ulkopuolisista asioista, mm. eri osa-puolien, etenkin ulkoisten sidosryhmien väli-sestä viestinnästä. Muita vastaavia tehtäväko-konaisuuksia, jotka eivät välttämättä sisälly kehitystiimin tehtäväjonoon, voivat olla jat-kuva integrointi sekä julkaisujen tietoturvaan, laadunparantamiseen tai käyttöönoton val-misteluun liittyvät tehtävät. Kun projektin ulkoinen ohjaus kulkee hyvän projektityöta-van mukaan ja sisäinen ohjaus scrum-menetelmän mukaan, yhdistelmä on saatu toimimaan. Seuraava kuva ??? havainnollistaa näiden kahden työalueen keskinäistä suhdet-ta.

On olemassa monia erilaisia tapoja tilata ket-terä projekti alihankkijalta. Julkisen ja yksi-tyisen puolen hankintaprosessit poikkeavat toisistaan paljon. Samoin yksityisellä puolella

on suuria eroja yksittäisten yritysten välillä. Yksityisellä puolella on saatu hyviä kokemuk-sia esimerkiksi menettelystä, jossa tilaajan projektipäällikkö anoo yrityksen johtoryhmäl-tä tuotekehityshankkeeseen tietyn budjetin. Tällä budjetilla palkataan scrum-tiimi tunti-veloituksen pohjalta 100 prosentin allokaatiol-la ja kuukauden irtisanomisajalla. Tilaukseen voi sisältyä koko tiimi tuoteomistaja mukaan lukien. Toisaalta tiimiin voi sisältyä haastatte-lujen pohjalta valikoituja yksittäisiä henkilöi-tä eri yrityksistä. Pääasia kuitenkin on, että tarvittava scrum-kompetenssi ostetaan työ-tuntien mukaisella veloituksella ja tekemään yksinomaan tuoteomistajan määräämiä tehtä-viä. Mikäli mahdollista, tiimi sijoitetaan tilaa-jan toimitiloihin. Työtä tilataan korkeintaan puolen vuoden sopimuksella, jota jatketaan tarvittaessa. Tällöin kuluseuranta ja tuotejo-non hallinta yksinkertaistuu. Tilaajan projek-tipäällikkö voi parhaimmillaan omistautua tuoteomistajan tukemiseen. Näin voidaan keskittyä tuotetun arvon maksimointiin anne-tussa budjettiraamissa.

Jos hankinnassa päädytään kiinteään hintaan tai kiinteään sisältöön, määrittelytyö vie hel-posti runsaasti aikaa sopimusneuvotteluissa ja kaikkinainen muutoshallinta kulkee tilaajan johtoryhmän ja projektisuunnitelman muu-toksen kautta. Yksinkertaisissa toimeksian-noissa tämä ei liene ongelma. Yleensä kuiten-kin joudutaan perimmäisten kysymysten ää-relle: Mikä on muutoshallinnan osuus kysei-sessä projektissa? Miten hyvin voimme ennus-taa ohjelmistotyötä? Jaammeko vastuuta tii-meille vai lisäämmekö johtoryhmän kontrol-

lia? Luotammeko ihmisten kykyyn ratkoa ongelmia itsenäisesti? On syytä muistaa, että kaikki arvoketjun sisällä olevat tiimi-, organi-saatio-, yritys- ja paikkakuntarajat tuottavat hävikkiä valitusta kehitysmenetelmästä riip-pumatta. Oletetaan esimerkiksi, että kehitys-tiimi ja hyväksymistestaustiimi ovat eri orga-nisaatiossa ja että ne kumpikin noudattavat kahden viikon scrum-jaksoa. Tällöin kehitys-, testaus-, korjaus- ja verifointisykli kestää pa-himmassa tapauksessa kahdeksan viikkoa. Tällöin olisi helppo piikitellä, että vesipu-tousmalli olisi nopeampi vaihtoehto. Silloin kuitenkin unohdettaisiin se tosiasia, että vesi-putousmallissa johtoryhmätason muutoskä-sittely veisi luultavasti saman ajan. Perushaas-teet molemmissa tavoissa olisivat samat eli organisaatiorajojen muodostamat siilot, kom-munikointi sekä vastuunotto muutostilan-teessa. Ketterissä menetelmissä muutoshallin-ta on osa normaalia hajautettua päätöksente-koa. Vesiputousmallissa muutoshallinta to-teutetaan yleensä keskitettynä poikkeusme-nettelynä johtoryhmätasolla.

On kuitenkin koko joukko muita syitä, miksi erilaisiin kehitys- ja hankintamenetelmiin on päädytty. Niistä aiheutuvia ongelmia on mah-dollista lieventää seuraavien esimerkkien avulla.

Tarina: Sopimukset

Eräs organisaatio teetti kaikki ohjelmistonsa talon ulkopuolisilla toimittajilla. Toimituspro-jekteja edelsi huomattavan perinpohjainen vaatimusmäärittely, jonka tarkoituksena oli kuvata kiinteähintaisessa toimituksessa tuo-tettava kokonaisuus.

Organisaatiossa ryhdyttiin kokeilemaan ket-teriä menetelmiä. Yhdessä toimittajan kanssa havaittiin, että vuosikausien sopimusvääntö asiakkaalle tärkeisiin puitesopimuksiin ei tukenut ketterän kehitysprojektin käynnis-tämistä. Projekti päädyttiin tilaamaan time-and-material-pohjalta tuntityönä. Kokonai-suuden sisällöstä keskusteltiin, mutta siihen ei kokonaan sitouduttu.

Tarina: Määrittelyt

Eräässä projektissa tuotettiin asiakkaan sisäi-seen tarpeeseen järjestelmää, joka automatisoi asiakkaan liiketoiminnan kannalta keskeisiä liiketoimintasääntöjä. Nämä säännöt olivat vuosien varrella kertyneet asiakasorganisaati-on liiketoimintaosaajien hiljaiseksi tiedoksi. Toimittajaorganisaatio tiedosti haasteet toi-minnallisuuden sopimisessa ja vaati yksityis-kohtaisen sääntökokoelman kirjallisesti.

Ketteryys muotoutui tarkoittamaan sitä, että palveluita tuotettiin inkrementaalisesti siten, että aluksi toteutettiin tekninen runko. Tä-män jälkeen kehitystyön ohjauksessa käytet-tiin periaatteena kokonaisia liiketoiminnan ominaisuuksia, jotka voitaisiin hyväksyä tuo-tantoon. Jokainen toimitus oli toimittajan termein testattu. Hyväksymistestaus kuiten-kin osoitti toistuvasti, että järjestelmä ei ol-lutkaan valmis tuotantoon. Ongelmat liittyi-vät määrittelyjen inkrementaaliseen tarken-tamiseen korjausmäärittelyjen pohjalta.

Lisäksi haasteeksi muodostui tekninen runko. Se oli toteutuksen suoraviivaistamiseksi ra-kennettu siten, että runkoon syntyi paljon päällekkäistä koodia. Teknisesti samoja asioi-ta toteutettiin moneen kertaan erikseen jokai-seen yksittäiseen tarkoitukseen. Ylläpidettä-vyys ja asiantuntijoiden laatimat soveltuvat koodirakenteet haluttiin tulkita suoraviivai-sena käännöksenä asiakkaan määrittelyistä. Ajoittain heräsi kysymys, olivatko valinnat asiakkaan edun mukaisia, vai varmistettiinko niillä vain toimitusorganisaation laskutuksen jatkuvuus.

OSTAMINEN KIINTEÄLLÄ HINNALLA

Ketterän projektin voi myös hankkia joko kiinteällä hinnalla tai ennalta määritellyllä, kiinteällä sisältöaihiolla – mutta ei molemmil-la yhtä aikaa. Mikäli tätä asiaa ei ymmärretä tai hyväksytä, on parempi pitäytyä vesipu-tousmallissa.

Hinnan, ajan ja sisällön ”kultainen kolmio”, ei ole muuttunut mihinkään. Vanha totuus on, että vain kaksi kolmesta voi lyödä lukkoon. Ketterän ohjelmistokehityksen yhtenä peri-aatteena on preferoida lyhyempää kehityssyk-liä eli ohjelmistokehitykseen käytettävää ai-

kaa rajoitetaan. Tästä periaatteesta ja kultai-sesta kolmiosta seuraa, että tilaaja voi valita joko hinnan tai sisällön.

Ketterän ohjelmistokehityksen sisäänraken-nettuna ajatuksena on, että ympäristön ja vaatimusten muutoksia tulee aina eteen – monesti pyytämättä ja yllätyksenä. Niihin reagoidaan käytännössä siten, että tuoteomis-taja karsii tuotteen kehitysjonosta asioita pois, jotta jokin uusi vaatimus tai toiminnalli-suus saadaan toteutettua. Vaikka riippuvuu-det pitäisikin pyrkiä karsimaan minimiin, niin käytännössä tehokas karsinta ei useinkaan onnistu. Tyypillinen tilanne onkin, että josta-kin ulkoisesta riippuvuudesta johtuen kehi-tystiimillä menee arvioitua enemmän aikaa tietyn sovitun asian tekemiseen. Tiimistä voi myös poistua asiantuntia, jolloin toisilta jä-seniltä menee ennakoimatonta työaikaa pois-tuneen asiantuntijan osaamisen hankkimi-seen. Näissä tapauksissa siis hinta (ja aika) pysyvät ennallaan, mutta tuotteeseen tulee vähemmän ominaisuuksia kuin alun perin ajateltiin, ts. sisältö joustaa.

Ketterän ohjelmistokehityksen hinta-laatusuhdetta voidaan tarkastella 80/20-säännöllä (Pareton periaate). Ohjelmistokehi-tykseen sovellettuna se tarkoittaa sitä, että 80 prosenttia ohjelmistotuotteen tavoitelluista hyödyistä saavutetaan 20 prosentilla toivo-tuista ominaisuuksista. Käytännön sovellu-tuksena tämä konkretisoituu tuoteomistajan jatkuvaksi priorisoinniksi, ts. päätöksiksi jättää joitakin ominaisuuksia toteuttamatta (ainakin käynnissä olevassa projektissa tai sprintissä).

On myös ohjelmistokehitysprojekteja, joissa sisällössä ei voi joustaa. Kaikki suunnitellut ominaisuudet kuuluvat must have luokkaan. Tyypillisiä esimerkkejä ovat lainsäädännön vaatimukset. Näissä tapauksissa, mikäli tilaaja edellyttää kiinteää hintaa tai hintakattoa, on parempi luopua ketteristä kehitysmalleista. On parempi tehdä suosiolla perinteinen sitova määrittely ja kysyä vasta sitten hintaa toimit-tajalta.

Projekteissa, joissa on kiinnitetty sekä hinta (eli käytännössä kehitystiimin koko ja aika) että ominaisuudet, ei ole mitään elementtiä, joka voisi joustaa siinä vaiheessa, kun jokin asia yllättäen muuttuu. Toisin sanoen kiinteän sisällön, ajan ja hinnan yhdistelmää voidaan

käyttää ainoastaan projekteissa, joissa kaikki tulevaisuuteen vaikuttavat tekijät tunnetaan (eli tulevaisuutta voidaan ennustaa 100 pro-sentin tarkkuudella) ja muutoksia ei tule. Mikäli tällainen ideaaliprojekti tulee eteen, ei ole mitään syytä tehdä ketterällä viitekehyk-sellä, koska ketteryyttä ja joustavuutta ei tar-vita.

Käytännössä ohjelmistokehityshankkeissa on aina jokin minimiominaisuus- ja toiminnalli-suusmäärä, joka on toteutettava. Toimittajal-lekaan ei yleensä haluta antaa rajatonta piik-kiä. Vaikka ketterä ohjelmistokehitys perus-tuu asiakkaan ja toimittajan väliseen luotta-mukseen, niin tätä keskinäistä luottamusta on hankala kirjoittaa hankintasopimuksiin – varsinkin julkisella sektorilla. Seuraavilla käy-tännön neuvoilla on kuitenkin mahdollista saada täysin kelvollisia hankintasopimuksia aikaan ketterän ohjelmistokehityksen projek-teihin:

Määrittele sopimukseen minimita-voitteet, jotka projektin on täytettävä. Minimitavoitteiden vaatima työmää-rä(arvio) tulee olla huomattavasti (esim. 50 %) pienempi kuin koko pro-jektin arvioitu työmäärä.

Määrittele sopimukseen yksikäsittei-nen enimmäishinta.

Määrittele sopimukseen asiakkaalle sekä koko toimittajaa että yksittäistä henkilöä koskeva välitön irtisanomis-oikeus.

Käytä toimittajia, jotka antavat tyyty-väisyystakuun eli jotakin tämän tyyp-pistä: ”annamme 25 prosentin alen-nuksen sprintin hintaan, mikäli asia-kas ei ole täysin tyytyväinen toimin-taamme sprintin aikana”.

Määrittele asiakkaalle riittävät imma-teriaalioikeudet ohjelmistokoodiin, eli oikeus käyttää, muuttaa, kehittää, kopioida ja siirtää koodia ilman että (ex-)toimittaja voi sitä rajoittaa.

Ehkä tärkeintä on kuitenkin kokeilla toimit-tajaa jossakin pienessä hankkeessa. Jos kokei-luprojektissa ilmenee ongelmia, jotka liittyvät työn tuottavuuteen tai toimittajan toiminta-malleihin, ei mitään isompaa kannata kyseisel-tä toimittajalta hankkia.

KETTERÄ KEHITYS JA HANKINTA, KIINTEÄHINTAISET TOIMITUKSET

Usein hankitaan kiinteähintaisia toimituksia. Ketteryyden yhdistäminen näihin on hiukan hankalaa; ainakaan kovin suuria hyötyjä ei saada. Parempi tapa on ostaa osaamista. Esi-merkiksi Maa- ja metsätalousministeriö hankkii osaamista eikä toimituksia ja katsoo toimivansa ketterästi.

Tarina: Sopimus määräsi henkilöiden roolit

Erään yrityksen ICT-yksikkö teetti alihankin-tana tietojärjestelmän siten, että he itse teki-vät määrittelytyön ja osan testauksesta. Toi-mittajalta ostettiin vain toteutus ja osa testa-uksesta. Projektissa otettiin käyttöön scrum. Alussa työ tuntui toimivan ja tiimijäsenet alkoivat auttaa toisiaan jopa yli yritysrajojen. Henkilöiden roolit oli kuitenkin määrätty sopimuksessa, joten määräajan lähestyessä ja paineiden kasvaessa jokainen alkoi huolehtia vain omalle vastuulleen kuuluvista töistä. Kokonaisuus kärsi. Alkoi esiintyä myös syyt-telyä: ”kyllähän minä olisin tehnyt, mutta kun sitä ja sitä ei ollut vielä tehty”.

Tarinan opetus on, että ensimmäisiä askelei-taan ketterän ohjelmistokehityksen parissa ottavien organisaatioiden kannattaa pitäytyä varsin uskollisesti ketterän ohjelmistokehi-tyksen julistuksen (Agile Manifesto) periaat-teissa ja menetelmän ohjeissa ts. scrumin pe-lisäännöissä. Mikäli kuvatussa projektissa olisi noudatettu seuraavia ketterän ohjelmis-tokehityksen periaatteita

arvostamme asiakasyhteistyötä enemmän kuin sopimusneuvotteluita

liiketoiminnan edustajien ja ohjelmis-tokehittäjien tulee työskennellä yh-dessä päivittäin koko projektin ajan

sekä scrumin sääntöjä, joiden mukaan

kehitystiimin jäsenten tittelinä on ”kehittäjä” riippumatta siitä, mitä ky-seinen henkilö tekee; tähän sääntöön ei ole poikkeuksia ja

kehitystiimin jäsenillä voi olla erityis-tä osaamista tai erilaisia työn paino-pisteitä, mutta vastuu kehityksestä kuuluu koko kehitystiimille yhdessä,

olisi lopputulos saattanut olla parempi.

Onnistumisen edellytyksenä olevaa molem-minpuolista luottamusta ei perusteta sopi-muksilla. Kummankin osapuolen on ansaitta-va luottamus omalla toiminnallaan. Yhteinen kehitystiimi joko onnistuu tai epäonnistuu tiiminä, ei kahtena osapuolena.

PROJEKTISUUNNITELMA TÄSMENTÄÄ PUITESOPIMUSTA

Yleiset sopimusehdot, kuten IT2010-sopimusehdot, julkisen hallinnon IT-hankintojen JIT 2007 ja Hanselin JIT-sopimusehdot, eivät käsittele ketterin mene-telmin tehtäviä hankintoja. Hanselin sopi-musehtoihin ketteryyttä ei ole otettu mukaan. Syynä tähän on, että menetelmä sisältää suu-ren budjettiriskin ja vaatii asiakkaiden aktii-vista osallistumista koko toteutuksen ajan. Valtionhallinnon asiakkaat eivät myöskään yleensä ole perehtyneitä ketteriin menetelmiin ja sen tuomiin haasteisiin. Useimmissa puite-sopimuksissa ei mainita ketteryyttä sinänsä, mutta sopimus voi sallia projektikohtaisen sopimisen työmenetelmistä. Tällöin projekti-suunnitelma liitteineen voi toimia sopimus-asiakirjana tilaajan ja toimittajan välillä.

Sopimusjuristin näkökulmasta olisi parasta, jos kukin sprintti olisi oma projektinsa, josta tehdään suunnitelma ja jolle sovitaan kiinteä hinta. Tämä on käytännössä raskas menettely. Sopivasti tehdyllä koko tilauksen kattavalla tavoitehinnoittelulla on saatu sekä tilaajaa että toimittajaa hyödyttäviä tuloksia.

Projektisuunnitelma

Projektisuunnitelman tarkoituksena on kuva-ta tulevan projektin vastuut, valtuudet, re-surssit ja työtavat siten, että kaikki projektiin osallistuvat ymmärtävät asiat vaivatta. On huomattava, että projektisuunnitelma täs-mentyy ja täydentyy sprinttien edetessä.

Scrumin käsitteistö voi tuntua asiakkaan lii-ketoiminta-asiantuntijoiden kannalta vieraal-ta ja kummalliselta. Tästä syystä on hyvä ku-vata projektikohtaisesti, miten kyseisessä projektissa scrum-viitekehystä sovelletaan. Roolit, tapahtumat ja työn suunniteltu ete-neminen kannattaa kuvata pääpiirteittäin. Kuvauksen tulee olla kiinnitetty tilaajan ja

toimittajan organisaatioon siten, että yhdellä silmäyksellä on helposti havaittavissa mihin ja miten tilaajan resursseja tarvitaan sekä se, mitkä tehtävät kuuluvat asiakkaan vastuulle. Näin varmistetaan liiketoiminta-asiantuntemuksen ja muun asiakkaalta tarvit-tavan asiantuntemuksen saaminen projektin aikana.

Tilaajan ja toimittajan vastuut

Tuoteomistajan tulee olla tilaajan organisaati-osta. Esimerkiksi vakuutusyhtiöissä järjestel-mien toiminnallisuuden määrittelevät lait, vakuutusehdot, vakuutusyhtiön tarjoamat palvelut, organisaatioiden väliset rajapintaku-vaukset (EU-standardit) ja yhtiön sisäiset rajapintakuvaukset. On selvää, että ei ole ole-massa yhtä yksittäistä henkilöä, joka hallitsisi koko tämän kokonaisuuden. Tällöin tilaajan on hyvä koota asiantuntijajoukko tuoteomis-tajaa tukemaan. Kehitystiimiin päin kaikki valta ja vastuu on kuitenkin tuoteomistajalla.

Testaussuunnitelma

Testaussuunnitelmaan kannattaa panostaa erityisen paljon silloin, kun tarvitaan liiketoi-minnallisten kokonaisuuksien testaamista. Tällaisten kokonaisuuksien valmistumisen aikataulu täytyy arvioida vähintään niin tar-kasti, että liiketoiminnallisten kokonaisuuk-sien asiantuntijaresurssit voidaan irrottaa testaamaan. Testaajille on kirjallisesti kerrot-tava, mitkä osat ovat testattavissa ja mitkä osat ovat valmistumassa myöhemmin. Testaa-jat ovat tyypillisesti asennoituneet testaamaan kokonaisuutta; puuttuvat osuudet aiheuttavat testaajissa suurta pettymystä ja epäluotta-musta rakennettavaan järjestelmään. Näin ollen testattavuuden tulee vaikuttaa merkit-tävästi sprinttien sisällön suunnitteluun.

Hyväksymismenettelystä sopiminen

Scrumin periaatteiden mukaan kussakin sprintissä toimittaja tuottaa dokumentteineen ja ohjeineen valmiiksi testatun version, joka on periaatteessa tuotantoonvientikelpoinen. Näin ollen tilaajan tekemä hyväksymistestaus voidaan tehdä sprinttikohtaisesti. Usein on kuitenkin järkevää kerätä usean sprintin tuo-tokset liiketoiminnallisesti testattaviin koko-naisuuksiin, joille toimittajan voi tehdä mie-lekkään systeemitestauksen ja tilaaja hyväk-symistestauksen. Käytännössä tilaajan on kaikkein järkevintä hyväksymistestata koko

projektin tuotos kerrallaan. Näin on varsinkin silloin, kun tuotantoonsiirtopäivät on lyöty lukkoon ja niitä on vain neljästä–kuuteen vuodessa.

Katselmointisuunnitelma

Ketteryys ei poista katselmointien tarvetta. Tilaajan on syytä katselmoida ainakin projek-tisuunnitelma liitteineen, tiedotussuunnitel-ma sekä testaussuunnitelma. Vesiputousmal-lista poiketen nämä suunnitelmat täydentyvät sprinttien edetessä. Tarvittaessa katselmoi-daan myös sprinttien aikana syntyvät doku-mentit.

Tiedotussuunnitelma

Tiedottamista ja koulutusta tarvitaan kaikille projektiin osallistuville jo ennen projektin varsinaista aloittamista. Erityisen tämä pitää paikkansa silloin, kun työmenetelmissä siirry-tään vesiputousmallista ketterään (toistuvaan ja lisäävään) lähestymistapaan. Vesiputous-malliin tottuneille muutos on suuri. Syntyy luonnollista muutosvastarintaa, josta selviy-tymiseksi tulee antaa sulatteluaikaa. Aikaa tarvitaan sekä vanhojen mallien poisoppimi-seen että uusien omaksumiseen. Tarvitaan siis normaalia muutosjohtamista. Projektin ede-tessä sprinttien tuotokset tulee olla läpinäky-västi esillä kaikille osapuolille mukaan lukien tilaajan resurssit.

Koska projektin alussa ei laadita vesiputous-mallin mukaista määrittelydokumenttia, pro-jektin lopputuloksen esittelyyn on syytä pa-nostaa sitäkin enemmän. Ketterän projektin aikana tehdään muutoksia ja kehitystyötä, josta tilaajan organisaatiossa ei ole tietoa. Tu-leville käyttäjille on siis annettava realistinen käsitys tuotoksesta, jotta vältytään liiallisten odotusten aiheuttamilta pettymyksiltä. Toi-saalta järjestelmän hyödyt on hyvä tuoda sel-keästi esille.

Tiedotuksen piiriin kannattaa ottaa mukaan myös mahdollisimman laajalti sidosryhmiä. Puutteellinen tiedottaminen projektien aikana on perinteisesti aiheuttanut kaikkein eniten pettymystä projektien tuotokseen. Joskus on päädytty jopa koko projektin tuotoksen hyl-käämiseen. Tiedotusta ja kommunikointia ei koskaan voi olla liikaa. Siispä: kommunikoi, kommunikoi ja kommunikoi. Näin lisätään onnistumisen todennäköisyyttä.

Tarina: Ketterän palvelukehityksen ekosys-teemi ja monitoimittajaympäristö

Asiakas halusi uudistaa sekä koko kehityksen ja tuotannon tavan että useita verkkopalvelui-ta samalla kertaa. Lähtötilanteessa palvelut olivat eri tahojen tekemiä, eri teknisiin alus-toihin perustuvia ja palvelinympäristöt sijait-sivat eri hostaustoimittajilla eri maissa. Kah-dessa vuodessa kaikki palvelut saatiin uudis-tettua ja nippu uusia rakennettua samalle palvelin- ja teknologia-alustalle. Niin kehitys-työ kuin tuotanto saatiin uudistettua täysin.

Lähtötilanne oli varsin tyypillinen suurelle, jo useita vuosia toimineelle yritykselle. Liike-toimintayksiköt olivat siiloja. Eri tarkoituk-siin ja eri kohderyhmille tehtyjä verkkopalve-luita oli vähintään kymmenen. Järjestelmiä ei oltu konsolidoitu millään tavoin. Palvelut olivat eri toimittajien eri teknologioilla teke-miä ja ylläpitämiä. Konesalit sijaitsivat kah-della eri toimittajalla eri maissa. Jokainen uusi projekti törmäsi ennemmin tai myöhemmin suuriin ongelmiin ja hidasteisiin. Tämä koski kaikkia projekteja, olipa kyseessä sitten uu-den palvelun tai järjestelmän kehityshanke tai aiemman työn muutosprojekti. Ongelmat alkoivat viimeistään siinä vaiheessa, kun tuo-toksia ryhdyttiin siirtämään tuotantoympäris-töön. Myös pienet ylläpitoluonteiset tehtävät kestivät viikkoja – tai jopa kuukausia. Sovel-lustoimittajat syyttivät hostaustoimittajia ja toisin päin. Käytännössä palveluiden kehitys-työ oli niin halvaannuksissa, että se uhkasi vaarantaa koko yrityksen tulevaisuuden.

Oli selvää, ettei millään yksittäisellä toimenpi-teellä saataisi korjattua tilannetta. Johdolla oli näkemystä ja rohkeutta käynnistää mullistava muutos. Muutos pantiin liikkeelle keskittä-mällä palvelukehitystä ja tietohallintoa sekä rekrytoimalla uusia henkilöitä useille avain-paikoille. Yrityksessä oli paljon ”pyhiä lehmiä” eli luutuneita ajatustapoja ja vanhentuneita toimintamalleja ja käsityksiä, joista oli päästä-vä eroon. Johdon näkemyksen mukaan vanha organisaatio ei kykenisi ”tappamaan omia rakkaita lapsiaan”.

Ensimmäinen yritys ketteröittää palveluiden kehitystyötä oli scrumin ”käyttöönotto” kou-luttamalla ja julistamalla, että nyt käytetään scrumia. Kannettu vesi ei kuitenkaan kaivossa pysynyt. Toisella yrityksellä jalkautettiin en-siksi ketterän sovelluskehityksen julistuksen

(Agile Manifesto) periaatteet ja vasta sitten menetelmäviitekehykset, kuten scrum ja kan-ban.

Toimittajien hallintamallit muutettiin täysin. Luotiin reunaehdot, joihin jokainen toimittaja sitoutettiin. Keskeinen vaatimus oli, että työskentely tapahtuisi asiakkaan tiloissa. Pis-te. Toinen keskeinen toimenpide oli yleisten sopimusehtojen käyttöönotto toimittajakoh-taisten sopimusten sijasta.

Yleisistä sopimusehdoista vääntäminen eri toimittajien kanssa katsottiin ajanhukaksi. Scrum-tiimit muodostettiin asiakkaan tuote-omistajasta, eri toimittajien työntekijöistä muodostuvasta kehitystiimistä ja Scrum Mas-terista, joka ei saanut olla samasta yrityksestä kuin varsinaisen kehitystiimin jäsenet. Toi-mittajilta poimittiin rusinat pullasta eli kehi-tystiimeihin tulevat henkilöt haastateltiin tarkkaan. Ovi kävi rivakasti myös ulospäin, mikäli joku henkilö ei sopinut kehitystiimiin. Myös useita eri toimittajayrityksiä testattiin pienissä hankkeissa. Jatkoa ei tullut, mikäli toiminta ja tuotokset eivät tyydyttäneet asia-kasta. Tämä oli melko kovaa toimittajahallin-taa. Toisaalta mankelista läpi päässeiden kes-ken muodostui erittäin toimiva kumppanuus-suhde, joka kesti yksittäiset vastoinkäymiset.

Isoille ja jähmeille hostaustoimittajillekin etsittiin vaihtoehtoja. Haluttiin löytää toimit-taja, joka tarjoaisi sekä palvelinkapasiteettia että siihen kytkeytyviä palveluita ilman koh-tuutonta byrokratiaa. Toivottiin sellaista pal-veluntarjoajaa, joka noudattaisi ketterän kehi-tyksen periaatteita, mutta sellaista ei Suomes-ta löytynyt. Kaikki palvelinkapasiteetti- ja palvelutoimittajat vannoivat ITIL-prosessien nimeen. Käytännössä kaikkia julistuksen peri-aatteita rikottiin ja niiden sijaan periaatteena sovellettiin muutosten vastustamista.

Onneksi 2000-luvulla näillekin palvelutoimit-tajille alkoi löytyä vaihtoehtoja. Internet tap-panee jäljelle jääneetkin dinosaurukset. Nyt-hän meillä on käytössämme pilvipalvelut. Palvelinkapasiteettia voidaan ostaa pilvestä itsepalveluna välittömästi, joustavasti tarpeen mukaan ja kaiken lisäksi edullisesti. Tässä kohtaa varoituksen sana: palvelutoimittajien ns. private cloud palvelut eivät ole oikeita pilvipalveluita, vaan käytännössä samaa kal-lista ja joustamatonta palvelinkapasiteetti- ja palveluntarjontaa. Ainoa ero on se, että niissä

hyödynnetään virtuaalipalvelintekniikkaa. Älä sekaannu niihin!

Tuotanto- ja kehitysympäristön pystyttämi-nen ei kuitenkaan ollut ihan helppoa. Asia ei hoitunut niin, että olisi vingutettu luottokort-tia internetissä ja sitten koko ympäristö olisi ollut valmiina. Palvelinkapasiteetin lisäksi tarvittiin mm. tietoturva-, valvonta-, testaus- ja tuotantoonsiirtoratkaisut sekä niiden yllä-pito. Kaikkiin tarpeisiin löytyi sovelluksia ja palveluita. Ratkaisuja oli erihintaisia, alkaen maksuttomista aina erittäin kalliisiin ja erilai-silla lisensiointimalleilla tarjottaviin ratkai-suihin. Ensimmäisten uuden toimintamallin kehitysprojektien yhteydessä asiakas rakensi näitä välttämättömiä ratkaisuja. Asiakas käyt-ti ratkaisujen rakentamisessa kyseisen alueen toimittajia. Erityisalueiden toimittajien työn-tekijöitä vaadittiin niin ikään työskentele-mään asiakkaan tiloissa. Näin he olivat scrum-tiimien välittömässä läheisyydessä ja tiiviissä vuorovaikutuksessa voitiin varmistaa, että ratkaisut olivat varmasti kehitystiimien työtä helpottavia. Kun perusratkaisut oli toteutettu, ne yleistettiin jokaiseen kehitysprojektiin. Ratkaisut olivat sellaisia, että kehitystiimien kehittäjät pystyvät itse osittain operoimaan niitä; osittain tarvittiin erikoistuneita henki-löitä. Nämä erikoistuneet henkilöt olivat osaksi omaa henkilöstöä ja osaksi palvelun-toimittajien henkilöstöä. Säännöt olivat kui-tenkin kaikille samat. Työskentely tapahtui asiakkaan tiloissa scrum-tiimien välittömässä läheisyydessä ja samaa tuotteen kehitysjonoa käyttäen.

Tuotteen kehitysjonon hallitaan käytettävä työkalu kuulostaa pieneltä asialta, mutta siitä on syytä sanoa pari sanaa. Sillä, mikä työkalu valitaan, ei ole väliä. Sen sijaan paljonkin väliä on sillä, että työkaluja on vain yksi ja että jo-kainen scrum-tiimissä ja sidosryhmissä pääsee siihen käsiksi. Tämän lähestymistavan valinta oli erinomainen asia hankkeen kannalta. Pe-rinteiset hostaustoimittajat olivat omien työ-kalujensa vankeja. He halusivat sitkeästi käyt-tää omia tikettijärjestelmiään, koska heidän ITIL-prosessinsa olivat niihin konfiguroituja. Kyseessä oli hallinnollinen työkalu, joten to-teutukseen ja konfigurointiin ei kannattanut ainakaan aluksi käyttää liikaa aikaa. Näitäkin työkaluja sai aitoina pilvipalveluina (sovellus-palvelu, SaaS). Nopeinta oli ottaa pilvipalvelu käyttöön ja antaa projektien aluksi luoda omat käytäntönsä. Pilvipalvelun valinta oli

perusteltua myös siksi, että silloin ei oltu si-dottuja asiakkaan lähiverkkoon. Kun koke-musta oli jonkin verran tullut, jatkuvan kehit-tämisen periaatteita noudattaen parhaat käy-tännöt yleistettiin kaikkiin projekteihin.

Projektien viitekehykseksi muodostui jonkin-lainen yhdistelmä scrumin ja kanbanin par-haista puolista. Aluksi olikin hyvä lähteä standardista liikkeelle. Kokemuksen myötä pystyttiin viitekehystä sitten sovittamaan yhteen mahdollisimman hyvin yrityksen mui-hin toimintamalleihin. Kun ensimmäiset pal-velut olivat menneet tuotantoon, sovelletusta kanbanista tuli ylläpidon viitekehys ilman varsinaista tietoista päätöstä.

Lopputuloksena – tai oikeammin välitulokse-na – saatiin asiakkaalle aikaan toimiva palve-luiden kehittämisen ja ylläpidon ekosysteemi. Kehitysprojekteihin luotiin säännöt. Ensim-mäinen sääntö oli, että ensimmäisen kuukau-den aikana projektin piti tuottaa oikeassa tuotantoympäristössä toimiva pilotti. Toinen sääntö oli, että kehitysprojektin maksimikesto sai olla kolme kuukautta. Projektien sisältö tuli sovittaa niin, että näissä aikarajoissa py-syttiin. Jatkuvan kehityksen periaatteet otet-tiin käyttöön eli jatkokehitystä tehtiin oikei-den käyttökokemusten perusteella.

Mitä opimme:

Tuoreet avainhenkilöt tuovat uusia näkemyksiä ja ovat vapaita vanhoista ajatustavoista ja toimintamalleista.

Ensin tulee opetella ketterän kehityk-sen periaatteet, sitten vasta työkalut, kuten scrum.

On syytä käyttää yleisiä toimitusehto-ja, ei toimittajakohtaisia sopimusehto-ja. Tällöin ei tarvitse käyttää aikaa so-pimusneuvotteluihin, jotka eivät tuo mitään lisäarvoa palveluiden kehittä-miseen.

Projekteille on asetettava reunaehdot (esim. arkkitehtuuri, ympäristöt). Ketterän sovelluskehityksen julistuk-sen periaate ”parhaat arkkitehtuurit, vaatimukset ja suunnitelmat syntyvät itseorganisoituvissa tiimeissä” ym-märretään usein väärin. Vaatimuksia ei kehitetä tyhjästä, vaan ne perustu-vat siihen mitä tuotetta ollaan raken-tamassa ja kenelle. Sama pätee koko-naisarkkitehtuuriin. Scrum-tiimit

pääsevät nopeammin oikeiden asioi-den kimppuun, jollei aluksi tarvitse sopia ja rakentaa kehitysympäristöjä ja muita perusasioita.

Toimittajien käyttö kehitystiimeissä on suositeltavaa. Omalla henkilöstöllä on tyypillisesti koko ajan menossa monia asioita ja projekteja. He eivät usein pysty täysipainoisesti osallis-tumaan scrum-projekteihin. Asian-tuntijalla tyypillisesti myös vahva oma vastuualue, jota hän painottaa yli ko-konaisedun.

Koko scrum-tiimin, asiakkaan tuote-omistaja mukaan lukien, pitää työs-kennellä samoissa tiloissa ja mielel-lään puhe-etäisyydellä toisistaan.

Monitoimittaja-kehitystiimien käyttö on suositeltavaa. Näin ehkäistään yh-den toimittajan Scrum Master & ke-hitystiimi klikkien syntyminen.

Kehitystiimien jäsenet tulee karsia tiukaste sekä osaamisen, viitekehyk-sen (scrum) tuntemisen ja käyttämi-seen sekä henkilökemioiden pohjalta.

Käytä pilvipalveluita. Luovu perintei-sistä palvelinkapasiteetti- ja palvelun-toimittajista.

Yhteinen tuotteen kehitysjonon hal-linta ja tikettijärjestelmä on ehdotto-man tärkeä asia. Pilvipalvelut ovat tä-hänkin hyvä vaihtoehto. Niiden puo-lesta puhuu käyttöönoton nopeus se-kä järjestelmän käyttöä aloitettaessa että uusien henkilöiden tullessa mu-kaan tiimiin.

Pidä tiukasti kiinni projektien mak-simikestoista ja siitä, että tuotantoon laitetaan oikeasti toimivia järjestel-miä.

Muista jatkuvan kehittämisen peri-aatteet eli kehitä, laita tuotantoon, hanki kokemuksia ja palautetta – ja kehitä lisää niiden perusteella.

TOIMITTAJIEN HALLINTA

Ainakin laajemmissa ohjelmistokehitysprojek-teissa ostajan pitää kerätä monien eri osa-alueiden osaamista, jota ostajaorganisaatiolta puuttuu. Tyypillisesti tarvittavat kompetens-sit liittyvät projektihallintaan, tietokanta-osaamiseen, käyttöliittymäsuunnitteluun,

tietoturvaan, testaukseen sekä myös kommu-nikointiin ja konseptointiin. Joskus kaikki tämä osaaminen saadaan yhdeltä toimittajalta, mutta usein päädytään valitsemaan monia toimittajia. Tähän voivat olla syynä myös ris-kien minimoiminen tai halu värvätä parhaat asiantuntijat projektin onnistumisen varmis-tamiseksi.

Tarina: Useiden asiakkaiden palveluksessa

Eräässä asiakasorganisaatiossa hyödynnettiin yhteisiä taustajärjestelmiä, joita kehitettiin usean asiakasorganisaation yhteistilauksen pohjalta. Välikätenä toimiva asiakkaiden yh-teisorganisaatio ryhtyi hyödyntämään ketteriä menetelmiä ensisijaisesti siksi, että asiakkai-den tarpeista nousevat muutosmäärittelyt saataisiin nopeammin toteutukseen.

Useiden asiakkaiden ristiriitaisten tarpeiden selkiyttäminen ennen kehitystyön aloitusta oli hyvin tärkeää. Kun asiakasorganisaatiot olivat mukana ketterässä kehitysmallissa, tekeminen muuntui jatkuvaksi, mikä koettiin hyvänä.

Haasteeksi muodostui se, että asiakasorgani-saatioiden dokumentointitarpeita oli vaikea muuttaa perinteisestä mallista kevennettyyn, koska asioista piti sopia useiden asiakasorga-nisaatioiden kanssa. Asiakasorganisaatioiden edustajien tietämys ja kokemukset ketteristä menetelmistä olivat vähäisiä eivätkä he olleet vielä saaneet riittävää ketteryyden perustei-den koulutusta.

Tarina: Päälle liimattu scrum

Asiakas halusi laajan ja monimutkaisen koko-naisuuden toteutettavaksi vuodessa. Projekti oli tarkoitus tehdä yhteistyönä. Asiakas mää-rittelisi liiketoimintavaatimukset ja priorisoisi toiminnallisuudet. Toimittaja suunnittelisi, toteuttaisi, testaisi ja lopulta pyörittäisi koko järjestelmää. Myyntivaiheessa toimittaja – kaiken muun ylimyynnin lisäksi – ilmoitti käyttävänsä kaikessa kehityksessä scrumia. Todellisuudessa projektinhallinta kuitenkin noudatti vesiputousmallia scrum-terminologialla. Ponnistus ei päättynyt onnel-lisesti. Projekti keskeytettiin vähän yli vuoden päästä, koska mitään toimivaa ei ollut saatu tuotantoon.

Projektin tarkoituksena oli uudistaa laaja kokonaisuus täysin puhtaalta pöydältä tai ainakin periaatteessa puhtaalta pöydältä. Suu-ren hankkeen monimutkaisuutta lisäsi se, että uuden järjestelmän tulisi integroitua lu-kuisaan määrään muita järjestelmiä. Osa näis-tä järjestelmistä olisi uusia ja osa pitkäänkin tuotannossa olleita. Asiakas oli kilpailutusta varten tunnistanut kuusi keskeistä toiminnal-lisuuskokonaisuutta eli liiketoimintaproses-sia. Niistä neljä oli pakko tehdä ja kaksi muu-ta olivat lähinnä toivomuksia eli sellaisia, jot-ka voisi tehdä myöhemminkin. Lisäksi oli suuri joukko vaatimuksia, jotka oli luokiteltu must-, should-, ja nice-to-have luokkiin.

Tarjoukset pyydettiin kolmelta eri toimittajal-ta. Tässä ei kuitenkaan sovellettu perinteistä tarjouspyyntömenettelyä, vaan tarjousta työs-tettiin yhdessä toimittajien kanssa. Kaksi toimittajaehdokasta tarjosi räätälöityä valmis-ohjelmaa. Kolmas ehdotti ratkaisua, jossa he tekisivät käytännössä räätälöidyn järjestel-män. Siinä kuitenkin hyödynnettäisiin ohjel-mamoduuleja, joita he olivat aikaisemmin tehneet muille asiakkailleen. Hintaerot olivat suuret. Räätälöity järjestelmä oli halvin sekä alkuinvestoinniltaan että käyttökustannusten osalta. Edullinen hinta epäilytti suuresti. Toi-mittaja kuitenkin vakuutti, että heillä olisi valmiita ohjelmamoduuleja, jotka kattavat yli 80 prosenttia toiminnallisuustarpeista. Lisäk-si koodausta suoritettaisiin edullisen kustan-nustason maassa. Vaikka edullinen hinta epäi-lytti, se myös houkutti kovasti. Toimittaja sitoutui tekemään kattohinnalla – käytännös-sä siis kiinteällä hinnalla – kaikki kuusi liike-toimintaprosessia sekä kaikki must- ja should-tason vaatimukset. Lopulta asiakas uskaltautui valitsemaan kyseisen toimittajan ja ratkaisun. Päätöstä edesauttoi vielä se, että toimittajan myynnistä vastaava johtaja tuntui ymmärtävän asiakkaan liiketoimintaa ja tar-peita erittäin hyvin. Toimittajan toimistokin oli täynnä scrum-julisteita. Myöhemmin tuli sellainen tunne, että ne oli laitettu seinälle vain asiakasta varten.

Sopimuksen allekirjoituksen jälkeen kävi van-hanaikaisesti. Asiakasta ymmärtänyt myyjä katosi takavasemmalle ja tilalle tuli projekti-organisaatio perinteisine projektipäälliköi-neen, määrittelijöineen ja suunnittelijoineen. Toimittajalta kysyttiin, missä Scrum Master ja kehitystiimit olivat. Vastaukseksi saatiin, että he ovat halvemman kustannustason maassa,

mutta ryhtyvät toimeen vasta kun kolmen kuukauden määrittelyvaihe on valmis. Projek-tipäällikkö ja määrittelijät eivät ymmärtäneet asiakkaan liiketoiminnasta tai tarpeista höl-käsen pöläystä. He eivät myöskään tunteneet edes omia ohjelmamoduulejaan. Myöhemmin kävi ilmi, että moduulitkin olivat olemassa enimmäkseen kalvoilla.

Ulkopuolinen arvioija suoritti projektin ris-kiarvioinnin. Arvioijan tuomio oli, että projek-tilla ei ollut minkäänlaisia onnistumisen edel-lytyksiä. Perusteluina hän esitti mm. sen, että projekti oli myyty scrum-projektina, mutta koko toimittajan toiminta oli puhdasta vesi-putousta.

Kuuden kuukauden jälkeen tietokanta oli määritelty, kehitysympäristö pystytetty ja varsinainen toteutustiimi pystyi aloittamaan työnsä. Samalla loppui jatkuva kommunikoin-ti asiakkaan kanssa. Toimittaja ei tuonut näy-tettäväksi mitään toimivaa. Neljän viikon sprintit päätettiin hallinnolliseen kokoukseen, jossa todettiin, ettei työjono ollut lainkaan lyhentynyt. Tuoteomistaja matkusti kuukau-deksi toiselle puolelle maapalloa kehitystiimin luokse. Palattuaan takaisin hän kommentoi, että ”voi olla, että kehitystiimillä on nyt joku haju, mitä ovat tekemässä, mutta ihan varma en ole.”

Ensimmäinen versio järjestelmästä tuli testa-ukseen vuoden kuluttua projektin aloitukses-ta. Testikäyttäjät raportoivat viikossa nelinu-meroisen määrän bugeja. Toimittaja ilmoitti, että rahat eli alun perin sovittu kattohinta on nyt käytetty ja halusi lisää rahaa. Jatkosta neuvoteltiin pari kuukautta. Asiakas keskeytti projektin.

Mitä opimme?

Aloita uuden toimittajan kanssa pie-nillä projekteilla ja etene suurempiin hankkeisiin vain, jos yhteistyö sujuu ja tuotosta syntyy.

Laita homma nopeasti poikki, jos se ei tunnu toimivan (fail fast).

Mikäli toimittaja haluaa tehdä kehi-tystyötä omissa tiloissaan, se vahva merkki siitä, että ketterän ohjelmis-tokehityksen julistusta ei ole täysin sisäistetty. Tällöin on suuri riski, että esimerkiksi scrumin käyttö on me-

kaanista termien ja tapahtumien suo-rittamista.

Ketterää kehitystä ei voi tehdä ilman jatkuvaa vuorovaikutusta asiakkaan kanssa. Vuorovaikutus on luontevin-ta, kun ollaan samoissa tiloissa. Jos ihmiset työskentelevät kaukana toi-sistaan eri aikavyöhykkeellä ja ilman yhteistä kieltä, ei onnistumisen edel-lytyksiä ole.

Ennen vanhaan iteratiivinen ohjelmistokehi-tys piti myydä lineaarisena, koska asiakkaat eivät ymmärtäneet sen etuja. Nykyisin asiak-kaat vaativat ketterien menetelmien käyttöä. Kaikilla toimittajilla ei kuitenkaan ole niiden vaatimaa osaamista, ja ketterää työtä myydään usein terminologialla ilman sisältöä.

TUOTEKEHITYSVIRRAN JOHTAMINEN

Tässä luvussa johtamisella tarkoitetaan pää-asiallisesti organisaation ymmärtämistä, suunnittelemista sekä muutosten toteutta-mista ja seuraamista. Laajennamme siis joh-tamisen käsitettä perinteisestä asioiden joh-tamisesta (management) ja ihmisten johtami-sesta (leadership) jatkuvaan organisaation systeemisen ymmärtämiseen, kehittämiseen ja ylläpitämisen.

Oletamme lukijan tuntevan scrum-menetelmän ja ketterän ohjelmistokehityksen perusteet. Tarvittaessa hyvät perustiedot saa lataamalla ja lukemalla ilmaisen scrum-oppaan4. Scrumin skaalaamisesta oppaassa ei valitettavasti kerrota. Skaalaamisesta saa yleiskuvan lukemalla Henrik Knibergin ilmai-sen Scrum and XP from the Trenches -kirjan5.

Tämän luvun viesti on: radikaalisti parannuk-sia organisaation toimintaan saadaan vasta kun ketteryyttä tuetaan systeemiajattelulla ja johtamisella.

Tarina: Skaalatusta ketteryydestä tuoteke-hitysvirran johtamiseen

Tämä tarina kertoo kansainvälisestä ohjelmis-totuoteyrityksestä, jonka liikevaihto oli noin sata miljoonaa euroa. Yrityksessä työskenteli satoja ihmisiä.

4 http://scrum.org/Scrum-Guides 5 http://www.crisp.se/bocker-och-produkter/scrum-and-xp-from-the-trenches

Yrityksen johto määritti ongelman: ”Liiketoi-mintamme ei skaalaudu, koska ohjelmistoke-hitys on niin hidasta”. Yrityksen tuotekehi-tysosaston katsottiin oleva pullonkaula ja tuotekehitysosasto alkoi tehdä työtä käsket-tyä. Tuotekehitysosastolla työskenteli joukko kehittäjiä, joilla oli mielessä kaksiosainen rat-kaisu: uudistetaan tuotteiden alla oleva vanha tekninen alustaratkaisu ja pilotoidaan samalla ketterää ohjelmistokehitystä scrumilla. Mikäli pilotti onnistuisi, kaikki ohjelmistokehitys-tiimit voisivat siirtyä vähitellen käyttämään scrumia tai jotakin muuta ketterää menetel-mää.

Kahden vuoden ja monen monituisen kään-teen jälkeen tekninen alusta saatiin uudiste-tuksi. Myös ketterä pilotti osoittautui onnis-tuneeksi. Uusien toimintatapojen ja alustan vuoksi uuden tuoteohjelmisto kehittämiseen kuluva aika saatiin leikattua kuudesta kuu-kaudesta kahteen kuukauteen. Tuotekehitys-osaston tuottavuus kolminkertaistui. Urakan tehneet kehittäjät olivat ylpeitä onnistuneesta lopputuloksesta.

Samaan aikaan scrum laajentui koko tuoteke-hityksen tavaksi kehittää ohjelmistoja. Scrum oli uudistuksen jälkeen käytössä yli kymme-nessä kehitystiimissä. Tiimit synkronoivat toimintaansa yrityksen laajuisiin kuuden vii-kon sprintteihin. Tiimien omat sprintit olivat kahden tai kolmen viikon pituisia, joten ku-hunkin yrityksen laajuiseen sprinttiin mahtui kaksi tai kolme tiimisprinttiä. Yrityksen laa-juinen sprinttien suunnittelu toimi loistavasti,

vaikka suunnittelun osallistui paikoitellen yli sata ihmistä.

Yrityksen tuotekehitystä ohjattiin usean ta-soisilla tuotteen kehitysjonoilla. Koordinoin-tia sekä tuotehallintaa tehtiin tuoteomistajien ryhmissä. Työntekoa kehitettiin ja koordinoi-tiin scrum of scrumeissa. Yrityksen laajuisen jatkuvan integraatiojärjestelmän avulla yrityk-sen kymmenistä järjestelmistä voitiin tehdä uusi julkaisu päivässä. Aikaisemmin tähän olisi kulunut viikkoja. Kehitystiimit olivat itsenäisiä tuotetiimejä, jotka kehittivät kaik-kia arkkitehtuurikerroksia oman tuotteensa osalta. Kehittäjien työmoraali oli noussut erit-täin korkeaksi tiimityön tuoman vapauden, fokuksen ja korkean laadun vuoksi.

Tuotekehitysosaston johtajalla oli erityinen syy tyytyväisyyteen. Johtajan henkilökohtaiset kannustimet oli sidottu tuotekehitysosaston tuottavuuteen. Hänelle maksettiin bonuksia sen perusteella, kuinka nopeasti hänen osas-tonsa tuotti tuotekehitysaihioista valmiita tuotteita. Moninkertainen tuottavuus tarkoit-ti merkittäviä bonuksia.

Juhlallisuuksien lomassa muutoksesta vastan-neet keskijohdon edustajat tapasivat liiketoi-mintayksikön johtajan. Hän kertoi karun nä-kemyksensä edistymisestä: ”En tiedä mitä olette saaneet aikaan, mutta liiketoiminnan näkökulmasta mikään ei ole muuttunut. Tuot-teiden saaminen asiakkaalle kestää kaksi vuotta, eikä tyytyväisyys ole noussut tippaa-kaan”. Tämä herätti suurta kummastelua. Keskijohto käynnisti selvityksen, jossa kah-den vastuuhenkilön tuli selvittää, mistä kom-mentti oikein kumpusi. Tuotekehitysosastolla vallitsi hämmennys. Eikö kahden vuoden on-nistuneen projektin jälkeinen juhlinta olekaan aiheellista?

Asiaa selvittävät esimiehet vaihtoivat näkö-kulman tuotekehitysosastosta koko organi-saatioon. He kartoittivat yrityksen tuotekehi-tysvirran aina tuoteideasta konseptoinnin kautta kehitykseen ja asiakastoimitukseen. Virran kartoitus tehtiin kahdesti eri osallistu-jilla, jotta tuloksia voitaisiin verrata toisiinsa. Kahden kuukauden selvityksen jälkeen selvit-täjillä oli esittää mykistävä tulos: tuotekehi-tyksen tehostuminen oli hidastanut läpi-menoaikoja suhteessa alavirtaan. Viivästykset johtuivat osastojen väleihin syntyneistä työjo-noista. Niitä esiintyi sekä ennen ohjelmisto-

kehitystä että sen jälkeen. Radikaaleimmat luvut saatiin, kun laskettiin tuotekehityskaa-ren kokonaiskestoaika (läpimenoaika) ja eri-teltiin omiin ryhmiinsä työvaiheet, joissa tuot-teeseen lisätään arvoa, sekä työvaiheet, joissa arvoa ei lisätä (esim. jonossa odottelu). Tuot-teen läpimenoajaksi saatiin kaksikymmentä kuukautta. Siitä ainoastaan neljän kuukauden ajan tuotteeseen lisättiin arvoa eli tuotetta kehitettiin. Loput kuusitoista kuukautta työn alla oleva tuote odotti seuraavaa työvaihetta. Onnistuneen ketteryyden skaalaamisen jäl-keen teholliseen tuotekehitysprosessin osuus oli laskenut 33 prosentista 20 prosenttiin!

Tuotekehityksen ketteröittäminen ja uusi alustaratkaisu olivat leikanneet tuotekehityk-sen sisäistä läpimenoaikaa kuudesta kuukau-desta kahteen kuukauteen. Samalla tämä muutos kasvatti käyttöönoton jonoa yhä kiih-tyvällä tahdilla. Käyttöönoton jonon kasvun syynä oli epävakaa tuotantoympäristö, johon ei haluttu viedä muutoksia kuin kokemuksen synnyttämällä varovaisella prosessilla. Käyt-töönoton jonoa tarkasteltaessa sieltä löydet-tiin tuotteita, jotka olivat kaksi vuotta vanho-ja ja joista oli jo uusi versio kehitteillä. Jonojen syntyyn löytyi lukuisia syitä. Näitä olivat esi-merkiksi tuotekehitysvirran vaiheiden vas-tuuttaminen organisaatio eri osille, joiden kannustimet johtivat virran optimin sijasta paikalliseen optimiin (alioptimointiin) koko järjestelmän kärsiessä.

Tuotekehitysvirtaa lähdettiin korjaamaan merkittävin muutoksin:

tuotekehitys- ja käyttöönotto-osastot järjesteltiin uudestaan

kehitystiimit muodostettiin poikki-funktionaaliseksi siten, että ne pys-tyivät itsenäisesti kehittämään tuot-teen konseptin, ohjelmiston ja myös viemään sen asiakaskäyttöön

teknistä infrastruktuuria kehitettiin edellisen mahdollistamiseksi

jonoihin tartuttiin hanakasti: joko ne poistettiin tai niiden kokoa rajoitet-tiin hylkäämällä vanhentuneita tuo-toksia

tuotekehitysvirran tarkastelu otettiin keskeiseksi johtamisen fokukseksi.

Edellä mainituilla muutoksilla yritys leikkasi tuotekehityksen läpimenoaikaa (concept-to-cash) kahdestakymmenestä kuukaudesta

kolmeen kuukauteen. Yrityksen kyky reagoida asiakastarpeeseen parani huomattavasti ja asiakastyytyväisyys nousi merkittävästi.

Jälkitarkastelu: Mitä tapahtui?

Jälkikäteen tarkasteltuna tarinassamme on useita mielenkiintoisia kohtia. Huomiota on syytä kiinnittää aina ongelman asettelusta kokonaiskuvan johtamiseen ja organisaation siiloihin.

Tarinan alkuvaiheessa liiketoiminnasta vas-taavien henkilöiden asettama ongelma oli oikea, mutta ratkaisuun hypättiin liian lyhyel-lä pohdinnalla. Syitä tähän oli muutamia. Lii-ketoimintaosasto oli jo pidemmän aikaa ollut tyytymätön tuotekehitysosaston tuottamien ohjelmistojen määrään. Toisaalta tuotekehi-tysosaston sisällä graafisesta suunnittelusta vastaavat henkilöt olivat kummissaan, koska näkivät kättensä jäljen asiakkaalla vasta vuo-sien viiveellä. Lisäksi ikääntynyt tekninen alusta oli yleinen jupinan aihe ja toimi valmii-na syntipukkina. Havaittuun ongelmaan (hi-das kehitys) oli valmiina selkeä syy (vanha tekninen alusta) ja tähän ratkaisu (uusi tek-ninen alusta). Näin ollen kenellekään ei tullut mieleen ryhtyä selvittämään syvällisemmin, mistä tuotekehitysputken tukkoisuus voisi johtua. Tuotekehitysosasto lähti siis korjaa-maan eniten jupinaa aiheuttavaa oiretta. Taus-talla vaikuttavat hiljaiset perusongelmat jäivät huomiotta.

Tuotekehitysosaston kahden vuoden projek-tin voitonjuhlien jälkeen aiheutunut krapula on helppo selittää. Osastolle oli asetettu haas-tava tavoite, joka oli saavutettu. Tavoite oli kuitenkin valitettavan väärin asetettu yrityk-sen liiketoiminnan näkökulmasta. Tuotekehi-tyksen ensisijaiset pullonkaulat olivat 1) val-miiden konseptien suuressa määrässä ja 2) käyttöönotossa. Konseptien määrän selitti suurelta osalta liiketoimintaosaston innok-kuus. Osasto olisi halunnut myydä ja markki-noida kymmenkertaisen määrän ohjelmistoja taustalla olevan tuotekehitysorganisaation tuotantokapasiteettiin verrattuna. Kymmenit-täin valmiita konsepteja ja ohjelmistoja kasau-tui jonoihin vanhentumista odottamaan. Mikä pahinta, kasvavat jonot tarkoittavat sitä, että uuden tuotteen kehitykseen kuluva aika kas-voi kasvamistaan. Tilanne paheni entisestään ajan kuluessa.

Oman kortensa kekoon kantoi osastojen sii-loutumisen aiheuttama eripura. Liiketoimin-taosaston näkökulmasta hidas tuotekehitys-osasto oli syyllinen hitaaseen kehitykseen. Tuotekehitysosaston näkökulmasta liiketoi-mintaosasto toivoi mahdottomia eikä ymmär-tänyt käytännön tekemisen rajoituksia. Myö-hemmässä vaiheessa tuotekehitysosaston nä-kökulmasta käyttöönotosta ja tuotannosta vastaava osasto oli syyllinen. Sehän ei kyennyt viemään uusia tuotteita tuotantoon tarpeeksi tehokkaasti. Kukin osasto täytti kuitenkin tehtäväänsä parhaalla näkemällään tavalla. Liiketoiminta myi mahdollisimman paljon, tuotekehitys kehitti mahdollisimman paljon, käyttöönotto yritti viedä tuotantoon mahdol-lisimman paljon pitämällä monimutkaistuvan tuotantojärjestelmän samalla vakaana ja toi-mintakuntoisena. Osastot muodostivat siis omat siilonsa, joilla oli omat tavoitteensa ja kannustimensa. Yrityksen liiketoiminnan näkökulmasta tavoitteet olivat ikävästi risti-riitaisia. Kassavirta muodostui asiakkaiden käyttämistä ohjelmistoista, joten tavoitteena olisi pitänyt olla tuottaa asiakkaille mahdolli-simman paljon ajantasaisia ohjelmistoja. Eri osastot eivät jakaneet tätä yhteistä tavoitetta eivätkä ymmärtäneet toimitusketjua kokonai-suudessaan. Siten pohja osastojen väliselle yhteishengelle ja yhteistyölle olivat hutera.

Tarinamme keskivaiheilla keskijohto tarkaste-li organisaatiota kokonaisuutena. Näkökul-maksi otettiin asiakasarvon tuottaminen. Ar-von syntyminen hahmoteltiin ja piirrettiin yrityksen tuotekehitysvirran valkotaululle. Arvovirtaa tarkasteltaessa selvisi hyvin nope-asti, että lukuisat jonot estivät yritystä tuot-tamasta systeemiajattelusta tuttua value de-mandin mukaista arvoa. Tämän takia failure demandin tutkimiseen ei käytetty aikaa. Spe-kulointi ongelmien syistä ja syntipukeista sai väistyä. Sen korvasi karun todellisuuden kat-sominen silmiin liiketoiminnallisesti merkit-tävien mittarien (kassavirta ja läpimenoaika) avulla. Selvisi, että ongelma ei ole yhdessäkään osastossa vaan osastojen välisessä interaktios-sa. Ongelma oli siis systeeminen. Ymmärrys mahdollisti sen, että syyttelyn sijaan voitiin keskittyä organisaation uudelleensuunnitte-luun ja parantamiseen. Yrityksen tuotekehi-tysvirtaa johdettiin ensimmäistä kertaa koko-naisuutena.

Tämän oppiakseen yrityksen piti ensin tehos-taa tuotekehitysosaston tuottavuutta. Siinä

jouduttiin kulkemaan vaikeimman kautta, koska vasta tämä harjoitus todisti sen, ettei tuotekehitysosasto ollutkaan yrityksen pul-lonkaula. Tieto sai keskijohdon muuttamaan ajatteluaan ja tarkastelemaan tuotekehitystä systeemisenä kokonaisuutena asiakkaan nä-kökulmasta.

Ilmiöitä selittäviä teorioita

Tässä luvussa tarkasteltuja ilmiöitä selittävät muun muassa seuraavat mallit ja teoriat:

Responsibility model (Christopher Avery)

Lean thinking (Taiichi Ohno, Jeffrey Liker, Womack & Jones)

Theory of constraints (Eliyahu Goldratt)

Principles of flow (Donald G. Reinertsen, W. Edwards Deming)

Value demand, failure demand (John Seddon)

Systems thinking (Russell Ackoff, John Seddon, W. Edwards Deming) http://youtu.be/OqEeIG8aPPk

Complex adaptive systems (Dave Snowden, Ralph D. Stacey)

Double-loop learning (Chris Argyris)

Mitä opimme?

Pysyvä muutos vaatii muutoksen joh-don ajattelutavassa.

Liiketoiminnallisen hyödyn saaminen ketteryydestä edellyttää systeemin johtamista.

Järjestelmän tarkastelu on aloitettava sen tarkoituksesta, arvon tuotannon ja saajan näkökulmasta (yrityksissä asiakkaat).

Organisaation rakenteet (siilot) saat-tavat olla este ketteryydelle ja tulos-ten aikaansaamiselle.

Ketteryyttä kannattaa soveltaa tun-nistetun, mitatun tarpeen mukaan, ei itseisarvoisesti.

KETTERÄ MUUTOSJOHTAMINEN

Periaatteita

On muistettava, että ketteryyden perusajatus on tuottaa asiakkaan tarpeisiin parempi rat-kaisu nopeammin ja vähemmillä resursseilla. Tätä perusajatusta kaikki eri ketterät mene-telmät ja käytännöt pyrkivät edistämään. Niinpä organisaation asiakasfokus ja asiak-kaan todellinen ymmärtäminen ovat avain-asemassa. Organisaation tulee pyrkiä pois käsky-vastuu-raportointi kulttuurista kohti kulttuuria, jossa asiakasta kuunnellaan, asi-akkaan tarpeet ymmärretään ja niihin vasta-taan.

Ketteröityvä organisaatio saattaa törmätä ongelmiin, jotka johtuvat sidosryhmien puut-teellisesta ketteryyden ymmärryksestä tai soveltamiskyvystä. Tällaisessa tilanteessa omaa organisaatiota kannattaa ketteröittää edelleen. Ketterä organisaatio pystyy aina palvelemaan perinteisempää organisaatiota.

On olemassa valtaisa määrä erilaisia ketteriä tavoitteita, periaatteita, menetelmiä ja käytän-töjä. Organisaation on pystyttävä valitsemaan, mitä niistä se pyrkii soveltamaan – ja mitä ei. Tähän ei ole olemassa suoraviivaista vastausta, sillä organisaatiot toimivat eri ympäristöissä ja ovat ketteryydessä eri kehitysasteilla. Vas-taus riippuu aina organisaatiosta itsestään.

Mikäli organisaatio yrittää toteuttaa yhtäkkiä liian edistyneitä menetelmiä tai liian radikaa-leja muutoksia, riski epäonnistumiseen on suuri. On tärkeää, että organisaatio ymmärtää oman ketteryyden kehitysasteensa ja tavoitte-

lee asioita, joiden toteuttaminen todennäköi-sesti onnistuu.

Jokin ketterä menetelmä voi olla eri organisaa-tioille yhtä aikaa vanhoillinen, otollinen tai liian haastava. Organisaation suorittavan por-taan edustajat eivät myöskään usein ole ky-vykkäitä arvioimaan heille vielä tuntematto-mien menetelmien hyödyllisyyttä tai päättä-mään siitä, kuinka kyseistä menetelmää sovel-lettaisiin heidän ympäristössään. Menetelmi-en käyttöönotossa onkin tärkeää varmistaa kaikkien osapuolten aito ymmärrys menetel-män tarkoituksesta. Lisäksi on vastustettava sellaista muuttamisen halua, joka motiivina on vain halu pysytellä mukavuusalueella.

On ymmärrettävää, että useimpien ihmisen on vaikeaa ajatella työtään käytännössä ja mene-telmätasolla yhtä aikaa. Tästä syystä ulkopuo-linen tarkkailija näkee usein ilmiselviä ongel-mia ja mahdollisuuksia henkilön tai tiimin työmenetelmissä. Työntekijöiden on yleensä vaikea huomata näitä itse nähdä yksityiskoh-tien runsauden tähden. Ulkopuolinen tukija eli fasilitoija onkin melkein aina arvokas lisä ryhmän työn tukemisessa, vaikka ryhmä ei aina sitä itse ymmärrä.

Fasilitointi vaatii ryhmädynamiikan asiantun-temusta. Fasilitoijan on hyödyllistä ymmärtää ryhmän työtä käytännössä, mutta se ei ole välttämätöntä. Vanhaa kansanviisautta mu-kaillen: on tärkeää nähdä sekä puut että met-sä.

Uuden ketterän menetelmän mukanaan tuo-ma tuska organisaatiossa ei useinkaan johdu

siitä, ettei menetelmä olisi organisaatiolle sovelias. Syynä on useammin se, että organi-saation muiden toimintatapojen aiheuttamat ongelmat tulevat tuskallisen selviksi. Valistu-nut johtaja voi kuitenkin kääntää tämän tus-kan edukseen. Se nimittäin kertoo peittele-mättä, mihin kehityspanostus kannattaa seu-raavaksi suunnata.

Matkalla ketteryyteen ihmisten välinen yh-teistyö ja kommunikointi, tiimien työskente-lyvälineet, työnohjaus, linjaorganisaation joh-tamiskulttuuri, palkitseminen ja yrityksen bisneskulttuuri voivat kehittyä hyvin epätah-dissa. Eri alueiden välinen tasapaino tai mah-dollinen epätasapaino on syytä ottaa huomi-oon johtamispäätöksissä.

Eräs tärkeimpiä johtamishaasteita on vallan, vastuun ja luottamuksen antaminen tiimita-son ihmisille. Muutos ei saa olla liian raju, muttei toisaalta liian epämääräinenkään, muuten sillä ei päästä haluttuihin lopputulok-siin.

Jokaisessa organisaatiossa on aina muutamia henkilöitä, jotka mielellään kokeilevat uutta. Lisäksi on suuri joukko ihmisiä, jotka sopeu-tuvat kulloinkin meneillään olevaan muutok-seen melko hyvin. Aina on kuitenkin myös niitä, joiden on hyvin vaikeaa ajatella entistä työtään uusien menetelmien valossa. Tämä kolmijako tulee ottaa huomioon, kun muutos-ta johdetaan ja tarkastellaan.

ALOITTAMISEN VAIKEUS

Ketterien kehitysmenetelmien käyttöönotto organisaatiossa alkaa tyypillisesti joko johdon aloitteesta tai siten, että yksittäinen tiimi soveltaa jotakin tuntemaansa/löytämäänsä menetelmää. Kummassakin tavassa on omat sudenkuoppansa.

Johdon julistuksella alkanut ketteryys saattaa päätyä täysin suohon, kun asiaan vihkiyty-mättömät työntekijät alkavat mekaanisesti soveltaa päätettyä menetelmää. Pilottiprojek-tit tyypillisesti epäonnistuvat, ja koko kette-ryys koetaan pikemminkin vitsiksi.

Yksittäisen tiimin alkaessa käyttää osaamaan-sa menetelmää menestys on yleensä parempi – ainakin kyseisen tiimin työssä. Haasteet tule-vat yleensä vastaan siinä vaiheessa, kun mene-

telmää ryhdytään käyttämään laajemmin, eli skaalautumisvaiheessa. Johto ei välttämättä ymmärrä tällaisia toimintatapoja, eikä voi siksi olla sitoutunut ketterien menetelmien käyttöönottoon.

Seuraavilla kokemusperäisillä ohjeilla ketteri-en kehittämismenetelmien käytön aloittami-nen onnistuu paremmin:

Johdon pitää tietää, mitä ketterien kehittämismenetelmien käyttämisellä tavoitellaan. Tavoitteiden tulee olla realistisia.

Johdon pitää ymmärtää, että kyseessä on koko organisaation läpäisevä muu-tos. Jos ainoa asia, mikä muuttuu, on terminologia, on turha odottaa tavoit-teiden saavuttamista, toisin sanoen lopputulosten muuttumista.

Organisaation toiminnan muuttumi-selle pitää antaa aikaa. Isoissa organi-saatioissa muutos voi vaatia jopa vuo-sia. Tämä ei ole ristiriidassa välitavoit-teiden olemassa olon kanssa. Muutos-ta pitää johtaa pitkäjänteisesti.

Aluksi kannattaa jalkauttaa ketterän kehittämisen periaatteet ja sen takana oleva filosofia. Vasta sitten kannattaa ottaa käyttöön varsinainen kehittä-mismenetelmä.

Pilottiprojektin toteuttajien tulee olla kokeneita, ymmärtää uudet periaat-teet ja osata käytettävä menetelmä hyvin. Jollei omassa organisaatiossa ole riittävä osaamista, niin sitä kan-nattaa hankkia organisaation ulko-puolelta. Pilottiprojektien epäonnis-tuminen saattaa vaarantaa koko muu-toksen. Organisaatiossa ei välttämättä ymmärretä epäonnistumisen johtu-neen toteutuksesta, ei menetelmästä.

Tietoja ja esimerkkejä onnistuneista kokemuksista tulee levittää projek-teista projekteihin ja organisaatioyk-siköstä toisiin yksiköihin.

JOHDON SITOUTUMINEN

Muutoksen aikaansaamisessa johdon sitou-tuminen on välttämätöntä. Johdon sitoutumi-sen suurin este on se, että johto ei ymmärrä ketterän tuotekehityksen taustalla olevaa filosofiaa ja periaatteita. Toiseksi suurin este

on se, että tavoitteet – eli muutoksella tavoi-teltavat hyödyt – ovat epärealistisia.

Johdon sitoutumisen puutteita esiintyy eri-tyisesti silloin, kun jokin ketterä kehittämis-menetelmä on otettu käyttöön ilman johdosta tullutta aloitetta tai lupaa kysymättä. Sitou-tumista ei välttämättä synny, vaikka projekti onnistuisikin. Yksittäinen projekti voikin aivan hyvin onnistua ilman johdon jämäkkää tukea. Muutoksen leviäminen organisaatioon eli skaalautuminen ei kuitenkaan koskaan onnistu, ellei johto seiso asian takana.

Yllättäen johdon sitoutumattomuutta voi ilmetä myös silloin, kun aloite on lähtenyt johdosta itsestään. Erityisesti näin voi käydä, mikäli muutokseen on lähdetty epärealistisin tavoittein. Toisinaan saatetaan kuvitella, että tuotekehityskustannukset alenisivat merkit-tävästi ketterien kehittämismenetelmien käyt-töönoton myötä tai että asiakastyytyväisyys kasvaisi hypähtäen seuraavassa vuosineljän-neksessä. Pahimmassa tapauksessa ylin johto nimittää vastuuhenkilön vastaamaan organi-saation ketteröittämisestä ja palaa sitten van-haan liiketoiminnan johtamiseen unohtaen tuen nimittämälleen henkilölle.

Myös keskijohto tulee sitouttaa muutokseen. Tämä on jopa tärkeämpää kuin ylimmän joh-don sitouttaminen, sillä keskijohdon rooli asioiden jalkautumisessa organisaation jatku-vaksi toiminnaksi on merkittävä. Erityisesti ketterien kehittämismenetelmien käyttöön-otossa keskijohdon sitouttamisen merkitys on suuri. Ketterässä filosofiassahan lähdetään siitä, että hallinnollinen työ (jota keskijohto yleensä enimmäkseen tekee) on hukkaa. Kes-kijohto pelkää usein oman asemansa ja työnsä puolesta. Todellisuudessa keskijohdosta ei yleensä luovuta, ei voida luopua eikä edes pitäisi luopua. Sudenkuoppana voi olla siis se, että unohdetaan keskijohdon sitouttaminen ja jätetään esimiehet miettimään että heidän työnsä ”on hukkaa, joka ei ketterään toimin-taan kuulu”.

Kokemusperäisiä oppeja:

Aseta muutoksen tavoitteet ja aika-taulu realistisesti.

Huolehdi, että johto ja keskijohto ymmärtävät ketterien kehittämisme-

netelmien taustalla olevan filosofian ja periaatteet sekä muutoksen tavoit-teet.

Tunnista keskijohdosta muutosagen-tit ja pyri liittoutumaan heidän kans-saan.

Organisaation muutos ketterämmäksi ei pääty koskaan. Käytännössä voidaan saavuttaa ha-luttu taso ja asetetut tavoitteet. Halutun tason ylläpitäminen vaatii jatkuvaa työtä. Tyypilli-sesti saavutetut tavoitteet johtavat uuden, entistä kunnianhimoisemman tavoitteen aset-tamiseen.

Jatkuva kehittäminen ja kehittyminen ovat ketteryyden filosofian periaatteita. Periaate on sovellettavissa myös itse ketteryyden kehit-tämiseen.

TUOTEOMISTAJAN ROOLI

Moni lean-kouluttaja tai -konsultti hokee mantranomaisesti opetusta ”tuoteomistaja on oman tuotteensa toimitusjohtaja”. Näin voi todellakin olla pienessä autotalliyrityksessä, jossa kaikki pyörii yhden tuotteen ympärillä. Vähänkään tätä suuremmassa organisaatiossa, jossa on useampia tuotteita, ei väite kuiten-kaan pidä paikkaansa. Tuotteilla on keskinäi-siä riippuvuuksia. Tyypillisesti myös isom-massa organisaatiossa tuotekehitykselle asete-taan reunaehtoja ulkopuolelta. Vaatimuksia voi tulla esimerkiksi konsernijohdolta, myyn-niltä, arkkitehdeiltä ja tietohallinnolta. Tuo-teomistaja ei toisin sanoen yleensä ole toimi-tusjohtajamaisen riippumaton tehtävässään.

Tuoteomistajan riippumattomuuden ja pel-kästään oman tuotteensa edistämiseksi tehtä-vän päätöksenteon korostaminen johtaa en-nemmin tai myöhemmin konfliktiin muun organisaation kanssa. Pahimmassa tapaukses-sa ihmiset kaivautuvat omiin poteroihinsa, vaikka yhteistyö olisi onnistumisen edellytys. Koko organisaation kannalta tämä voi olla suorastaan tuhoisaa.

Fiksu tuoteomistaja ottaa reunaehdot huomi-oon. Parhaassa tapauksessa hän ottaa reuna-ehtojen asettajat mukaan miettimään, kuinka vaatimukset parhaiten toteutetaan.

SKAALAUS

Fred P. Brooks selittää mainiossa kirjassaan The Mythical Man-Month (Brooks, 1975), kuinka ohjelmistoissa jokainen yksityiskohta on ehdottoman tärkeä. Ohjelmistosta voidaan tehdä erilaisia mallinnuksia, esimerkiksi tila-kaavioita, vuokaavioita ja oliokaavioita. Näissä abstraktionäkymissä katoaa aina kuitenkin välttämättömiä yksityiskohtia. Brooks muo-toili asian sanomalla, että tietokoneohjelmien visualisointi on mahdotonta. Koska ihmisaivot toimivat paljolti visuaalisesti, tämä on ongel-ma.

Ohjelmistoista on jo kauan sitten tullut niin monimutkaisia, etteivät yhdet aivot pysty enää jäsentämään kaikkia yksityiskohtia. Rat-kaisujen tekemiseen tarvitaan työryhmiä eli tiimejä, monesti jopa useampia tiimejä. Ih-mismäärän kasvaessa kasvaa kuitenkin myös kommunikaatiopolkujen määrä. Kasvu on eksponentiaalista suhteessa henkilömäärään, joten kompleksisuus kasvaa merkittävästi.

Antropologi Robin Dunbar on esittänyt teori-an, jonka mukaan apinalajin aivokuoren uloimman osan (neokorteksi) koko määrittää, kuinka monen yksilön kanssa keskimääräinen lajin edustaja pystyy rakentamaan ja ylläpitä-mään jatkuvaa sosiaalista suhdetta (Dunbar, 1992). Hän rakensi teoriansa eri apinalajeista keräämänsä datan perusteella ja laski ihmisel-le keskiarvoksi 148 (suurella virhemarginaalil-la). Jotta tämän kokoinen ryhmä pysyisi sosi-aalisesti kasassa, jokaisen jäsenen pitää käyt-tää yli 40 prosenttia ajastaan sosiaaliseen kanssakäymiseen. Dunbar esitti myöhemmin, että ihmisillä puhekielen kehittäminen ja

käyttö oli omiaan lisäämään sosiaalista ko-heesiota, jolloin varhaisten ihmisryhmien ko-ko saattoi nousta ilman suurempaa ajankäyt-töä. Dunbarin lukua on ehdotettu myös orga-nisaation toimivaksi maksimikooksi.

Kun organisaation koko kasvaa, säännöllisyyt-tä ja järjestystä pitää lisätä kompleksisuuden vastapainoksi. Mikäli halutaan rakentaa py-ramidi, kivien kasaaminen suureen kasaan ei välttämättä johda haluttuun lopputulokseen; skaalaaminen vaatii struktuuria. Ilman struk-tuuria kasvava organisaatio on vaarassa luisua kaaokseen. Struktuuria voidaan tuoda kasva-vaan organisaatioon monella eri tavalla. Perin-teisesti rakennetta on synnytetty määrittä-mällä ja jalkauttamalla erilaisia hierarkioita, rooleja ja prosesseja.

Robin Dunbar ja monet muut ovat oivaltaneet, että ihmiset ovat luonnostaan sosiaalisia eläi-miä, jotkut meistä voimakkaammin, jotkut lievemmin. Osaamme ja haluamme toimia ryhmissä, omaksumme automaattisesti erilai-sia rooleja ryhmän vahvistamiseksi ja kek-simme yhteisiä toimintatapoja. Terminologi-an, roolien, ryhmäpaineen, prosessien, kadens-sien ja/tai teknologian avulla voidaan lisätä säännönmukaisuutta ja sosiaalista koheesiota. Skaalaaminen onnistuu parhaiten, kun tunnis-tetaan, mitkä asiat pitää luoda sisäisesti tai tuoda ulkoa, ja mitkä hoituvat itsestään.

Tässä luvussa käydään läpi erilaisia skaalauk-sen malleja ja lähestymistapoja. Jotkut niistä toimivat ohjelmistoteollisuudessa muita pa-remmin, jotkut toimivat ehkä paremmin muil-

la aloilla. Osa malleista ei ehkä toimi enää informaatioyhteiskunnassa juuri missään. Yhteistä kaikille on kuitenkin se, että mitä korkeammalle noustaan, sitä pelkistetympiä malleja on otettava käyttöön. Yksityiskohdat piilotetaan, ja struktuuri nousee tärkeäksi.

"All models are wrong, but some are use-

ful."

- George H. Box

KUN SKAALATAAN YLÖSPÄIN, ON YK-SINKERTAISTETTAVA

Perinteinen tapa skaalata ohjelmiston kehitys-tä on arkkitehtuurin redusointi modularisoin-nin avulla. Ohjelmisto jaetaan osa-alueisiin tai komponentteihin, joiden toteutuksesta huo-lehtii yksi tiimi. Perinteisesti johdon vastuulla on ollut huolehtia näiden komponenttien väli-sistä rajapinnoista.

Ketterän menetelmän tapa skaalata ohjelmis-tokehitystä on toinen. Koska ohjelmisto halu-taan toteuttaa ja julkaista toiminnallisuus kerrallaan, on luonnollista myös muodostaa tiimejä, jotka voivat toteuttaa eri toiminnalli-suuksia yksi kerrallaan. Tällaista tiimiä kutsu-taan featuretiimiksi.

Lähestymistapaa kuvaa hyvin Conwayn laki, joka sanoo että tuote on organisaation kom-munikointistruktuurin peilikuva. Organisoin-ti kannattaa siis toteuttaa siten, että ne henki-löt ja tiimit, joilla on tarve synkronoida ja kommunikoida keskenään, sijoitetaan toisten-sa lähettyville niin organisaatiokaaviossa kuin toimistollakin.

Ketterässä kehityksessä suositellaan, että sen sijaan että johto ratkoisi ohjelmistomoduulei-den (tai tässä tapauksessa toiminnallisuuksi-en) välisiä riippuvuuksia, ohjelmoijat puhuisi-vat suoraan toistensa kanssa ja sopisivat riip-puvuuksista ja rajapinnoista. Tämä säästää paitsi aikaa, myös estää väärinymmärrysten muodostumista. Johto ei ole koskaan yhtä hyvin perillä toteutuksen yksityiskohdista kuin toteuttajat. Johdon tehtäväksi jää var-mistaa, että ohjelmoijat voivat vaivatta puhua toistensa kanssa ja tehdä yhteisiä päätöksiä, jotka toteutetaan suoraan ohjelmaan.

Tässä mallissa lähdekoodista tulee tehokas suora kommunikointiväline. Jatkuvasti ajan-tasainen integraatio on välttämätön edellytys tiimien hyvälle toiminnalle. Ilman jatkuvaa integraatiota tiimit saattavat toimia viikkoja tai kuukausia ristiriitaisten olettamusten alla. Tällöin toteutetaan toisistaan riippuvia kom-ponentteja siten, etteivät ne loppujen lopuksi olekaan yhteensopivia. Nämä ristiriitaisuudet ilmenevät viimeistään projektin loppuvaihees-sa, kun tuote on ”90 prosenttisesti valmis” ja jäljellä on vain ”pelkkä integrointi”.

Tiedetään tapauksia, joissa alun perin kom-ponenttitiimeissä toimineet kehittäjät ovat suoraan järjestyneet featuretiimeiksi ilman asiaankuuluvan jatkuvan integroimisen järjes-telmän käyttöönottoa. Tällöin kehittäjät ovat suuren haasteen edessä. Heidän tulisi omak-sua yhtäkkiä kaikki tiedot ja taidot, mitä tar-vitaan koko ohjelmiston ymmärtämiseksi niin hyvin, että he pystyvät tekemään muutoksia rikkomatta jo olemassa olevaa toiminnalli-suutta.

Vastaavasti ohjelmoijat saattavat tehdä hy-vinkin paljon muutoksia hyvin lyhyessä ajassa. Jos integrointijärjestelmä on hyvin hidas, jää pelkälle kommunikaation kautta tapahtuvalle synkronoinnille suhteettoman suuri osuus. On sangen helppoa kurkata ajan tasalla olevasta koodista viimeiset muutokset. Kohtuuttoman työlästä sen sijaan on yrittää ottaa yhteyttä kaikkiin niihin moniin suunnittelijoihin koko organisaatiossa, jotka ovat saattaneet muuttaa kyseistä koodia sitten viime näkemän.

Featuretiimien haaste onkin juuri säilyttää ohjelmistosuunnittelijoiden erityisasiantun-temus silloin, kun ohjelmiston tekeminen vaatii jonkin erikoisalueen syvällistä ymmär-rystä. Ymmärrys voi liittyä esim. salausalgo-ritmeihin, standardeihin tai protokolliin. Täl-laisessa tilanteessa toiminnallisuuden onnis-tunut ohjelmointi vaatii syvällistä asiantun-temusta myös kyseisestä alueesta. Käytännös-sä hyväksi ratkaisuksi on monissa tapauksissa osoittautunut feature- ja komponenttitiimien yhdistelmä.

Usean ohjelmistotiimin ohjaus vaatii myös useita tuotteen kehitysjonoja. Kun tiimien yhteisen kehitysjonon tehtävien määrä nousee yli sadan, yhteisen tuotteen kehitysjonon priorisointi on havaittu aikamoiseksi haas-teeksi. Tässä auttaa abstraktiotason nosto.

Luonnollinen seuraava abstraktiotaso on toi-minnallisuuden taso eli featuretaso. Tämän päällä on usein eeppinen taso, jossa epiikat menevät kukin yhteen tuotteeseen (tai jois-sain tapauksissa elävät jopa tuoteperheiden yli). Tällöin featuret ja epiikat ovat muodol-taan samanlaisia kuin käyttäjätarina; niiden abstraktiotaso on vain suurempi. Vaihtoeh-toinen tapa skaalata vaatimustenhallintaa on ryhmitellä käyttäjätarinat kokonaisuuksiin. Tällöin samaan toiminnallisuuteen liittyvät käyttäjätarinat niputetaan yhteen ryhmäksi, vaikka ne ehkä ulottuvatkin useamman sprin-tin ylitse. Liiketoiminnasta ja liiketoiminta-mallista riippuu, kumpi skaalaustapa kannat-taa valita. On myös mahdollista käyttää mo-lempien tapojen yhdistelmää. Siinä tapaukses-sa toiminnallisuudet ovat lähinnä kokoelmia käyttäjätarinoista.

Tuotteen kehitysjonot siis skaalautuvat hie-rarkkisesti ja muodostavat tavallaan fraktaa-lin. Hyvä skaalautuva työjonojen (esim. tuot-teen kehitysjono tai sprintin tehtävälista) hallintatyökalu tarjoaa mahdollisuuden tar-kastella tätä kokonaisuutta erilaisista näkö-kulmista käsin (esim. vain tietyn tiimin näkö-kulmasta tai toiminnallisen julkaisun testauk-sen näkökulmasta). Hyvä työjonojen hallinta työkalu tarjoaa myös mahdollisuuden auto-maattisten metriikoiden luomiseen niin tiimi-, projekti- kuin tuotetasollakin.

Mikään työkalu ei kuitenkaan korvaa ihmis-ten välistä kommunikaatiota. Työjonohierar-kiaa tukemaan tarvitaan joukko tuoteomista-jia, jotka ovat vastuussa tuotteesta näillä eri tasoilla. Aikaisemmin ajateltiin, että yksi tuo-teomistaja voi ohjata jopa neljää scrum-tiimiä. Hyvä tuoteomistaja kuitenkin paneutuu huo-lellisesti tehtäväänsä ja tuntee tuotteen läpi-kotaisin. Tähän menee paljon aikaa, minkä vuoksi roolin on syytä olla kokopäivätoimi-nen. Tiimin työskentelyvauhti riippuu osal-taan siitä, saako tiimi tuotetta koskevat vas-taukset viipymättä (ts. onko tuoteomistaja käytettävissä aina tarvittaessa). Tiimien kan-nattaa seurata suorituskykyään. Mikäli tuote-omistaja muodostuu pullonkaulaksi, organi-saatiota on tarpeen muuttaa siten, että tuote-omistaja on paremmin saatavilla. Tästä syystä nykyisin useimmiten suositellaan, että yhtä tiimiä ohjaisi vain yksi tuoteomistaja.

Toisaalta asiaa on tarkasteltava myös siitä näkökulmasta, kuinka monta tuoteomistajaa

tarvitaan yhden tuotteen tai tuoteperheen tekemiseksi. Tuoteomistajien ryhmän ei pidä sallia kasvaa liian isoksi, niin ettei se voi työs-kennellä tehokkaasti yhdessä. Tuoteomistajan roolia ei kannata sekoittaa projektipäällikön rooliin. Myöskään ei pidä pyrkiä taivuttele-maan ketterää organisaatiota toimimaan pe-rinteisten hierarkkisten komentosuhteiden mukaan. Ketterä organisaatio on aina pikem-min verkosto kuin hierarkia.

Tiimien tuoteomistajat saavat ohjeet tuotteen kehitysjonon priorisointiin siltä tuoteomista-jalta, joka vastaa featuretason työjonosta ja sen priorisoinnista. Tämä puolestaan saa oh-jeet epiikkatason työjonon omistajalta. Häntä puolestaan ohjaa koko yrityksen työjonosta vastaava tuoteomistaja. Käytännössä tällaisel-la ylimmän tason tuoteomistajalla on usein kokonainen tiimi tukenaan. On kuitenkin huomattava, että scrumin hengen mukaan vain yksi henkilö antaa ohjeita eteenpäin. Täl-löin vältetään mahdolliset tulkintojen ja vas-tuiden ristiriidat.

Tarina: Useita tuoteomistajia

Eräässä tuotekehitysorganisaatiossa oli erik-seen liiketoimintatason tuoteomistajia ja tek-nisiä tuoteomistajia. Tiimin kannalta tilanne oli sekava. Ohjeita tuli kahdelta eri tuoteomis-tajalta. Ratkaisu ei ollut scrumin hengen mu-kainen.

LISÄÄ NÄKÖKULMIA SKAALAAMISEEN

Kun agile-gurut puhuvat skaalaamisen ongel-mista, he usein pohtivat, kuinka itseohjautuva ja valtuutettu toiminta saadaan leviämään koko organisaatioon. Tämä onkin usein isojen organisaatioiden todellinen haaste ja voi vaa-tia useamman oppimis-iteraation.

Itseohjautuva, itseään kehittävä ja päätöksiä tekevä tekijöistä muodostuva scrum-of-scrums voidaan muodostaa laajoillekin koko-naisuuksille, kunhan fasilitoinnista vastaavat ihmiset osaavat asiansa.

Eräs käytännössä huonoksi koettu ratkaisu skaalaamiseen on, että yksi tiimi on vastuussa useamman tuotteen samasta moduulista. Täl-löin kyseisen tiimin tuoteomistaja joutuu

priorisoimaan keskenään monen tuotteen vaatimuksia tuohon samaiseen moduuliin. Käytännössä tämä tarkoittaa sitä, että yrite-tään tehdä rinnakkain montaa tuotetta yhtä aikaa. Parempi vaihtoehto on jaksottaa työtä siten, että tehtävät tuotteet priorisoidaan aidosti siten, että organisaatio tekee vain yhtä toimivaa tuotetta kerrallaan. ”Yksi kerrallaan” on lean-filosofian mukaan kaikkein tehok-kainta ja johtaa teoreettisesti lyhyempiin tuo-tekehityssykleihin.

Edellä olevaa ei pidä sekoittaa tilanteeseen, jossa sama koodimoduuli toimii useammalla alustalla. Alustan vaatimat laiteajuritason muutokset on usein eristettävä omiksi kom-ponenteikseen, joita voidaan aidosti kehittää rinnakkain. Myös testaus on mahdollista suo-rittaa aidosti rinnakkain ja kalenteriaikaa säästäen vain lisäämällä testiympäristöjen määrää.

Joissakin tapauksissa tuote koostuu useam-masta erillisestä tuotteesta, jotka vain toimite-taan yhdessä. Käytännössä parhaimmaksi ratkaisuksi on tällöin havaittu se, että tuotteet kehitetään ja integroidaan mahdollisimman itsenäisesti, mutta kaikki tiimit laitetaan vas-tuuseen siitä, että kokonaisuus toimii. Itse integroimis- ja testausympäristö toki voi olla yhteinen. Jossakin tapauksessa voidaan käyt-tää laajennettua valmiin määritelmää. Tällöin mikään tuote (tai tiimi) ei ole vastuussa pel-kästään siitä, että oma julkaisu toimii. Lisäksi ollaan vastuussa siitä, että usean tuotteen (tai tiimin) yhteinen integroitu tuotos toimii.

Kolmas tapa skaalata on itse asiassa downsca-ling, eli asioiden tekeminen pienemmällä po-rukalla, mutta osaavammin ja tehokkaammin. Koska ketterät tiimit toimivat tehokkaammin, tuote syntyy vähemmällä määrällä tiimejä. Tämä puolestaan vähentää organisaation kompleksisuutta ja nostaa sitä kautta tiimien tehokkuutta. Downscaling tarvitsee onnistu-akseen paitsi osaavat henkilöt, myös joustavan ja kevyen organisaation sekä huippuun virite-tyt työkalut. Ketterien menetelmien perus-teellinen ymmärtäminen tiimitasolla sekä lean-filosofian mukainen johtaminen ovat välttämättömiä.

JATKUVAN INTEGRAATION SKAALAA-MINEN

Jatkuva integrointi pitää sisällään myös testa-uksen. Yhteinen jatkuvan integroinnin järjes-telmä on tärkein väline tiimien väliseen synk-ronointiin. Tiimien ei voi olettaa tuottavan hyvälaatuisia julkaisuja kahden viikon välein, jos välineet eivät anna mahdollisuutta integ-roida ja testata tuotetta useampaan kertaan kahden viikon kuluessa ennen julkaisua.

Skaalatun jatkuvan integroinnin järjestelmän luominen on kovaa työtä. Vaatii kekseliäisyyt-tä oivaltaa, miten ennen käsin hoidetut toi-minnot voidaan automatisoida. Integrointi-vaiheita yhdistämällä voidaan päästä välivai-heista eroon ja nopeuttaa itse integraatiota. Vanhoillakin järjestelmillä voidaan päästä jopa päivittäissykliin. Todella nopea integraa-tio vaatii kuitenkin uudentyyppisten hajautet-tujen versionhallintajärjestelmien käyttöönot-toa. Tällöin jokaisella kehittäjällä on oma ko-pio varsinaisesta ohjelmiston päälinjasta. He voivat verifioida oman muutetun koodinsa ennen kuin laittavat sen integroitavaksi. Muu-toksia tehdään useita päivittäin. Todennäköi-syys sille, että useampi kehittäjä samaan ai-kaan muokkaa juuri samaa palasta ohjelmis-tosta, kutistuu häviävän pieneksi. Jokainen muutos aiheuttaa automaattisesti koko koo-din kääntämisen ja koodimuutoserojen kopi-oitumisen kehittäjien koneille. Näin kaikilla kehittäjillä on käytännössä koko ajan käytös-sään ohjelmiston ajantasainen kopio.

Parhaimmissa järjestelmissä yrityksen työ-jononhallinta-, integrointi-, testaus- ja mitta-usjärjestelmät on linkitetty toisiinsa helpot-tamaan kehittäjän työtä entisestään. Ideaali-sesti toteutus alkaa testitapauksen tekemisel-lä. Sitten seuraa käyttäjätarinan toteutus. Kun koodi on saatu onnistuneesti integroitua jär-jestelmään, integroinnista vastaava järjestelmä merkitsee tehdyksi työjononhallinnan työka-lussa käyttäjätarinan. Mittarijärjestelmä seu-raa työjonojen sekä testaus- ja integrointijär-jestelmien tilaa automaattisesti. Mikäli tehtä-vän suorittaminen ei onnistu, ongelmat kirja-taan järjestelmään. Johto seuraa kirjattuja ongelmia ja ratkoo etenemisen esteitä. Yritys seuraa suoritusaikoja ja asiakaspalautetta. Asiakastyytyväisyyden mittaus ei tapahdu pelkästään jälkijättöisesti, vaan yritykseen on

rakennettu kyvykkyys ennustaa tulevien tuot-teiden menestystä jo kehityksen aikana.

Ohjelmistopäivitys saattaa usein olla tuot-teen arvokkain ominaisuus

Kehittyneimmät jatkuvan integroinnin järjes-telmät pitävät sisällään paitsi testauksen myös tuotteistuksen. Jos tuote koostuu muus-takin kuin ohjelmistosta, saattaa tuotantoon-vienti vaatia fyysistä toimintaa, esim. tuotteen valmistuksen ja kuljetuksen asiakkaalle. Kun organisaatio on kerran luonut kyvyn tehdä tuotetta pienissä inkrementeissä, saadaan tästä osaamisesta kaikki arvo irti vasta, kun otetaan käyttöön automatisoidut ohjelmisto-päivitykset. Ilman ohjelmistopäivityksen mahdollisuutta kerran tehty ja asiakkaalle viety tuote ei pysy ajan tasalla. Jos ohjelmis-tossa on linkkejä muihin internetissä tai pil-vessä sijaitseviin ohjelmiin, tuote vanhentuu ilman ohjelmistopäivitystä heti, kun nuo ul-koiset olevat ohjelmat päivittyvät seuraavaan versioon. Vanheneminen tapahtuu siis varsin nopeasti. Automaattinen, taustalla tapahtuva ohjelmistopäivitys mahdollistaa tuotteen päi-vittämisen samassa syklissä kuin edistynyt jatkuvan integroimisen ja toimittamisen jär-jestelmä päivityksiä tuottaa.

ORGANISOINTI JA ORGANISAATIO-MALLIT

Ketterän projektin skaalaaminen on monita-hoinen asia, joka koskettaa niin arkkitehtuu-ria, työkaluja, ihmisten roolituksia, työn orga-nisointia ja ihmisten organisoitumistakin. Vähäisin ongelmista ei ole se, kuinka ison tuotteen voi paloitella osiin niin, että toteu-tus- ja julkaisujärjestys on mielekäs. Kussakin toimitettavassa julkaisussa pitää olla kokonai-sia toiminnallisuuksia. Käytännössä toimiva tapa on ollut toteuttaa ensimmäisissä tiimien yhteisissä julkaisuissa jokin uusi toiminnalli-suus perustasolle. Seuraavissa julkaisuissa tätä toiminnallisuutta voidaan sitten laajen-taa.

Miten tällaisen julkaisun toteutus pitäisi sit-ten kohdentaa tiimeille niin, että kaikilla on sopivasti työtä? Scrumin mukaan kukin tiimi mittaa itse omaa vauhtiaan ja varaa itselleen sopivasti kuormaa. Edistyneiden organisaati-oiden toteuttama laajennus tähän on se, että ne pystyvät sopeuttamaan organisaationsa

tehtävien toiminnallisuuksien mukaisesti. Organisaatio pystyy toisin sanoen järjesty-mään featuretiimiksi, kun työjonossa on tu-lossa toteutettavaksi isompi kokonaisuus. Toisaalta osataan pitäytyä komponenttitii-meissä, kun toteutettavat asiat ovat kooltaan rajallisia ja koskevat vain yksittäisiä kom-ponentteja.

Tässä vaiheessa on syytä mainita, että kompo-nentti on järjestelmän geneerinen osa. Moduu-li puolestaan on standardoitu komponentti, jonka voi irrottaa ja vaihtaa. Esimerkiksi tyy-pillinen Linux-jakelu koostuu muutamasta sadasta komponentista, joista esim. näyttöaju-rit tai Java-virtuaalikoneet voivat olla modu-laarisesti vaihdettavissa.

Toteutusta on huomattu käytännössä nopeut-tavan, mikäli kuhunkin julkaisuun tulee ker-rallaan vain muutamia isoja toiminnallisuuk-sia. Loppujen on syytä olla pienempiä, vain yhteen tiimiin kohdistuvia muutoksia. Tällai-nen toiminnan edistynyt jaksotus edellyttää, että organisaatio osaa mitata toimitusnopeut-taan ja optimoida omaa toimintaansa. Tällai-nen organisaatio kuormittaa kaikkia jäseniään tasaisesti. Perinteisempien organisaatiomalli-en haasteena on nimittäin usein se, että kuor-mitus ei jakaudu tasaisesti eri tiimeille. Työ-jonohierarkian ensisijainen tavoite on varmis-taa, että koko organisaatio saa yhtenäisen ohjauksen siitä, mikä on ensisijaista ja mikä toissijaista tekemistä. Työjonoissa esiintyvää näkemystä voi toki itse kukin haastaa jutte-lemalla tuoteomistajan kanssa.

Eräs mahdollinen tapa organisoitua on muo-dostaa organisaatio muistuttamaan arvoket-jua. Tällöin on mahdollista nostaa keskuste-luihin kysymys siitä, tarvitaanko eri tiimien tai organisaation struktuurien välisiä siirtoja vai ei. Yleinen filosofinen nyrkkisääntö tälle on, ettei työtä pitäisi koskaan siirtää tiimistä tai organisaatiosta toiseen vain kahden ihmi-sen välillä. Joissakin tapauksissa yhden tekijän työ tarvitsee seuraavassa vaiheessa useamman ihmisen työpanoksen edetäkseen. Tällaisessa murrospisteessä kannattaa aina huolehtia riittävästä talon sisäisestä kirjallisesta doku-mentaatiosta.

Esimerkki tällaisesta murrospisteestä on käyt-töliittymäkonseptin toteutus. Hyväksi käy-tännöksi on havaittu, että kehitettävän käyt-töliittymäkonseptin kaikki eri versiot doku-

mentoidaan reaaliajassa kussakin iteraatiossa samaan dokumenttiin. On myös hyvä, mikäli käyttöliittymiä suunnitteleva henkilö pystyy istumaan toteuttavan tiimin lähistöllä tai ai-nakin vierailemaan helposti tiimin luona kes-kustelemassa kunkin iteraation oleellisimmis-ta ideoista. Käyttöliittymäsuunnittelijan tulee kuitenkin pystyä säilyttämään riittävä yhteys myös oman käyttöliittymän konseptointitii-minsä kanssa, jotta koko konsepti pysyy yh-tenäisenä.

Kuinka paljon struktuuria organisaatio tarvit-see, riippuu jälleen kerran tehtävästä tuottees-ta. Jos tehtävänä on puhdas ohjelmistotuote ja sen tuotantoonvientikustannukset ovat mi-nimaaliset, organisaatio voi ääritapauksessa toimia pelkällä ulkoa tulevalla ohjauksella (crowdsourcing, jonka perusteella arvioidaan, mitä markkinat haluavat) ja sisäisellä toteut-tajien omista taustoista syntyvällä visiolla (ts. asiantuntijoiden käsitys siitä, mitä markkinat tarvitsevat). Tällaisessa organisaatiossa to-teuttajat voivat päättää itse, mihin haluavat sitoutua. He siis siirtyvät projektista toiseen omaan motivaatioonsa perustuen. Jokaisesta julkaisusta tuleva ulkoinen palaute mahdollis-taa virhearvioiden pikaisen korjauksen. Sa-malla varmistuu se, etteivät virheinvestoinnit voi muodostua kovin suuriksi ainakaan jo olemassa olevissa tuotteissa.

Toisinaan ohjelmisto on osa isompaa tuotetta, johon liittyy transaktiokustannus, kun tuote viedään asiakkaalle. Näin on esimerkiksi sil-loin, kun tuotteen toimitus vaatii fyysistä kokoamista, varastointia ja siirtoa asiakkaalle. Tällöin organisaatiolta vaaditaan enemmän struktuuria. Organisaation tehtävä ei olekaan vain yksittäisten toiminnallisuuksien toteut-taminen ja vieminen asiakkaalle, vaan organi-saation vastuulla on varmistaa, että tuote toi-mii kokonaisuutena jo ennen toimitusta. Täl-löin on varmistettava, että kullakin osatoi-minnallisuudella on tekijänsä.

Jos tällaisen tuotteesta vastaavan organisaati-on annetaan vapaasti organisoitua tiimeiksi, saattaa käydä niin, että kaikki huippuosaajat löytävät toisensa samasta tiimistä. Lopputu-loksena tiimien osaamisaste muistuttaa Gaus-sin käyrää. Hitain tiimi saa samassa ajassa huomattavasti vähemmän aikaiseksi kuin huipputiimi. Jos kaikilta tiimeiltä kuitenkin odotetaan panosta yhteiseen julkaisuun, koko organisaatio joutuu odottamaan, kunnes hi-

tain tiimi ennättää toimittaa oman tuotoksen-sa. Tällöin nopeimpien tiimien tekijät saatta-vat turhautua odotteluun ja parhaankin ryh-män motivaatio laskee. Integroidusta tuot-teesta vastaavan organisaation etuna on siis huolehtia, että asiantuntemus jakautuu orga-nisaatiossa tasaisesti. Yksilöiden muodosta-mat tiimien poikki kulkevat siteet vahvistavat tiimirajojen yli tapahtuvaa kommunikointia. Toinen keino epätahtisen valmistumisen rat-kaisemiseen on lisätä yleistä tietoisuutta koko organisaation pullonkauloista. eri tiimeistä voi sitten kanban-tyylisesti etsiytyä henkilöitä auttamaan pullonkaulan selvittämisessä. Par-haimmillaan tämä tapahtuu itseohjautuvasti ilman hierarkkista käskytystä.

Deming on kirjoittanut siitä, miksi työnteki-jöitä ei kannata palkata hyvästä suorituksesta henkilökohtaisin bonuksin (Lazko, 1995). Hyvä suoriutuminen johtuu ihmisen henkilö-kohtaisista ominaisuuksista. Esim. koulussa toisilla vain on parempi taipumus oppia soit-tamaan jotain instrumenttia kuin toisilla. Lah-jakkuus ja lahjakkuudet vaihtelevat. Olisi luonnotonta vaatia kaikilta oppilailta saman-tasoista suoritusta ja palkita säännöllisesti ne, jotka menestyvät parhaiten, ja rangaista sään-nöllisesti niitä, jotka menestyvät huonoiten. Tällainen huonommin suoriutuvaan yksilöön kohdistuva kritiikki ei tue kenenkään moti-vaatiota. Sen sijaan kun tiimiä tai projektia palkitaan ryhmänä, kaikki motivoituvat ta-voittelemaan parempaa suoritusta.

Esimerkiksi yksilöön suoraan kohdistuvasta kritiikistä sopii Microsoftinkin harjoittama stack ranking, jossa työntekijät niputetaan tietyin kriteerein eri luokkiin. Käyrän toisessa päässä olevien tekijöiden edellytetään paran-tavan suoritustaan ja toisessa päässä on ta-voitteet reilusti ylittävät tekijät. Tästä voi seurata tiimien välillä epätervettä kilpailua. Lisäksi voi syntyä vääristymiä. Jokin tiimi voi menettää tähtipisteet, jos naapuritiimissä niitä jo jaettu reilusti ja organisaatiolla on vain tietty kiintiö jaettavia pisteitä. Vaikutuksia motivaatioon asteikon eri kohdissa voi vain arvailla. Tällainen palkitsemisjärjestelmä saat-taa muokata tekemistä siihen suuntaan, että ihmiset pyrkivät markkinoimaan ja edistä-mään omia töitään unohtaen samalla yhteis-työn ja tiimikaverien auttamisen.

PÄÄTÖKSENTEKO JA HALLINTO

Ketterään malliin siirryttäessä päätöksenteko muuttuu rajusti. Suunnittelupäätökset, jotka perinteisesti on tehty vain projektin alussa, siirretään nyt tehtäväksi ja päivitettäväksi projektiin. Käytännössä päätökset teh-dään/päivitetään kerran sprintissä. Päätöksen-teko siirtyy suorittavalle portaalle, missä myös asiantuntemusta on eniten. Päätöksistä kes-kustellaan laajemmin, jolloin päätökset ank-kuroidaan organisaatioon hyvin tehokkaasti. Päätösten seuranta ei tapahdu raporttien kautta, vaan avointen mittareiden avulla. Vas-tuu siirtyy henkilöiltä ryhmätasolle.

Mitä suurempi organisaatio on, sitä suurem-maksi ongelmaksi tämä voi muodostua. Ko-kemusten mukaan harva organisaatio ottaa päätöksenteon muutokset huomioon kette-rässä transitiossa. Organisaatio koostuu edel-leen samoista henkilöistä, jotka keskustelevat ja jakavat tietoja entiseen tapaan ja entisiä kanavia käyttäen. Aiemmat hallinto- ja pää-töksentekostruktuurit jäävät siten helposti kummittelemaan taustalle. Pahimmassa tapa-uksessa rakenteet muuttuvat epäselviksi ja päätöksenteko epävarmaksi ja hitaaksi.

Skaalaaminen vaikuttaa päätöksentekoon pääosin kielteisesti. Pieni organisaatio pystyy päättämään ja toteuttamaan monia asioita nopeasti ja ketterästi. Esimerkiksi työkalun valinta ja käyttöönotto voi kestää vain muu-taman päivän tai jopa vain muutaman tunnin. Isossa organisaatiossa byrokratia lisääntyy. Vaihtoehtojen selvittämiseen, valinnan teke-miseen, ohjelmiston asentamiseen ja henkilö-kunnan koulutukseen voi helposti mennä vuosi. Monessa kansainvälisessä yhtiössä Sar-banes-Oxley lain vaatima jäljitettävyys asettaa vielä omat rajoitteensa.

JULKAISUSUUNNITTELU

Sinänsä tarpeelliset ja välttämättömät ohja-usmekanismit eivät ole yksinään riittäviä. Avuksi tarvitaan ylemmän tason julkaisu-suunnittelua (agile release train). Kun scrumia skaalataan, kaikki scrumin käytännöt löytyvät muodossa tai toisessa myös ylätasolta. Julkai-sutason suunnittelu vastaa sprintin suunnitte-lua. Aivan kuten sprintin suunnittelu tapah-tuu jokaisen sprintin alussa, tulisi julkaisuta-

son suunnittelun tapahtua juuri edellisen julkaisun valmistumisen jälkeen. Hyväksi koettu tapa on kaikille yhteinen demo- tai pilottijulkaisu ennen seuraavan julkaisun suunnittelun alkamista. Eräs onnistuneeksi koettu käytäntö on myös mainitun demon nauhoittaminen. Siitä voidaan sitten näyttää tiivistetty otos sidosryhmille, mukaan lukien yrityksen ylin johto ja asiakkaat. Joissain ta-pauksissa asiakkaille on jopa annettu demoja sellaisenaan kokeiltavaksi. Tämä tietysti vaatii sitä, että asiakas on syvällä sisällä yrityksen tavassa tehdä ohjelmistoja. Asiakkaan on ym-märrettävä, että demo ei välttämättä pidä sisällään koko tuotetta, vaan ainoastaan sen osan ja että seuraava vastaava julkaisu ilmes-tyy kuukauden tai kahden kuluttua. Aikatau-lu riippuu valitusta julkaisusuunnitelmasta.

Julkaisusuunnittelun tärkein anti on tuote-omistajien ja tiimin keskustelu itse rakennet-tavasta tuotteesta. Tällainen keskustelu näkyy suorana säästönä projektin kestossa. Kaiken-lainen häröily sisällön suhteen ja loputtomat sähköpostikeskustelut siitä, mitä itse asiassa ollaan rakentamassa, jäävät kokonaan pois.

Julkaisun oleellisena osana on suunnitella myös itse julkaisun testaus. Kuten sprintin testaus tulisi suunnitella samaan aikaan sprinttisuunnittelussa muun sisällön suunnit-telun kanssa, tulisi julkaisutason testauksesta sopia julkaisusuunnitelmaa suunniteltaessa. Tämä tuo myös tiettyä yhteismitallisuutta suunnitteluun ja asettaa vaatimuksia julkai-sun toteutukselle. Testitapauksista sovittaes-sa sovitaan myös testitapausten kriteerit sekä kustakin toiminnallisuudessa päävastuussa oleva suunnittelija. Mikäli itse julkaisun te-kemisen aikana tapahtuu muutoksia, kukin suunnittelija tietää julkaisusuunnittelussa käydyn keskustelun perusteella, keneen tulee ottaa yhteyttä. Tämä nopeuttaa mahdollisista muutoksista kommunikointia ja niihin rea-gointia.

Vastaavalla tavalla kuin sprintin retrospektii-vissä, myös julkaisun jälkeen on syytä pitää retrospektiivi eli katselmus siitä, miten tehdyt suunnitelmat ja toteutus onnistuivat. Retro-spektiivin tarkoitus on löytää parannettavaa sekä itse tehtävästä tuotteesta että siitä, kuinka on toimittu. Sovitut jatkotoimenpiteet toteutuvat parannuksina seuraavan julkaisun aikana. Näin pystytään toteuttamaan oppivan

organisaation periaatetta niin tiimin, projek-tin kuin organisaationkin tasolla.

OHEISTOIMINTA: ARKKITEHTUURI JA KÄYTTÖLIITTYMÄSUUNNITTELU

Oheistoiminta voidaan jakaa asiantuntijateh-täviin ja koordinointitehtäviin. Käyttöliitty-mäsuunnittelu on hyvä esimerkki asiantunti-jatehtävästä. Suunnittelija tarvitsee sellaista tietotaitoa, mitä ei organisaatiosta yleisesti löydy. Tällaisia osaamisalueita ovat mm. graa-finen suunnittelu ja käyttäjien käyttäytymisen ymmärtäminen. Näin ollen käyttöliittymä-suunnittelijan täytyy tehdä työt itse.

Järjestelmäarkkitehtuurin laatiminen sen si-jaan on koordinointitehtävä. Ohjelmistokehi-tysorganisaatiossa on teknisiä asiantuntijoita, jotka jatkuvasti tekevät matalan tason arkki-tehtuuripäätöksiä. He suunnittelevat rajapin-toja ja valitsevat tietorakenteita ja algoritmeja. Tässä haasteena ei ole tekninen tietämys, vaan koordinointi. Samoin projektijohtaminen on koordinointitehtävä.

Asiantuntija- ja koordinointitehtävien sekoit-taminen keskenään voi olla vaarallista. Käyt-töliittymäsuunnittelija tai graafikko toimii harvoin koordinaattorina. Sen sijaan on san-gen yleistä, että projektipäällikkö tai arkki-tehti luulee olevansa asiantuntija.

Jos koordinaattoreita on paljon, myös koor-dinaattorien toimintaa pitää koordinoida. Eräs hyväksi koettu toimintatapa monimutkaisen järjestelmän käyttöliittymän yhtenäisyyden varmistamiseksi on nimittää käyttöliittymä-konseptille yksi ylin vastuuhenkilö. Tämä vastuuhenkilö omistaa käyttöliittymäkonsep-tin ja tarvittaessa päättää muutoksista. Kaikki konseptiin tehtävät olennaiset muutokset kulkevat hyväksyttäväksi hänen työpöytänsä kautta. Tähän ei ole välttämätöntä laatia ko-vin muodollista prosessia. Tärkeämpää on, että vastuuhenkilö näkee muutokset ja toimii kaiken uuden designin hyväksyjänä.

Tarina: Tietojärjestelmällä pahempaan suuntaan

Eräässä isossa ohjelmistokehitysyksikössä rakennettiin monimutkaista tuotetta kymme-

nien tiimien voimin. Järjestelmäarkkitehdit muodostivat oman pienen tiiminsä. He halusi-vat kokea olevansa suuria asiantuntijoita, joten he omivat itselleen käytännössä kaikki tekniset päätökset, niin pienet kuin isotkin. Vähän ajan päästä kaikki arkkitehdit olivat täysin jumissa työtaakkansa kanssa eivätkä enää ehtineet vastata kohtuullisessa ajassa ohjelmoijien kysymyksiin. Järjestelmäarkki-tehdit pyysivät ohjelmoijia lähettämään muu-tospyynnöt sähköpostilla, jotta ne eivät kato-aisi. Tämäkään ei auttanut. Pyynnöt jäivät lojumaan yksittäisten arkkitehtien sähköpos-tilaatikoihin.

Ylikuormitusongelmaan keksittiin ratkaisuksi arkkitehtuurimuutospyyntöjen seurantajär-jestelmä. Kyseessä oli tietokantapohjainen webihäkkyrä, johon ohjelmoijat saivat syöttää muutosehdotuksia. Järjestelmän luvattiin tuovan monia hyötyjä. Arkkitehtien työtilanne tasoittuisi, eivätkä pyynnöt enää hukkuisi. Mikä parasta, yksittäisten tikettien etenemi-selle saataisiin lisää näkyvyyttä.

Aluksi ohjelmoijat syöttivät pyyntöjä järjes-telmään kiltisti ja ohjeiden mukaisesti. Yhden pyynnön kirjoittamiseen meni tosin paljon aikaa. Tarpeiden selittäminen kirjallisesti on aina vaikeaa. Lisäksi järjestelmä oli jokseenkin kankea ja tietokenttien opettelemiseen meni aikaa. Pyyntöjen tärkeyskriteereistä ei myös-kään ollut yhteistä näkemystä. Arkkitehtien mielestä ohjelmoijat laittoivat omille pyyn-nöilleen herkästi liian korkeita prioriteetteja.

Arkkitehdit ryhtyivät sulkemaan pyyntöjä tietokannassa ilman hyvää perustelua. Pyyn-nöt, joissa oli liian vähän tietoja, suljettiin siksi, että pyyntö ei ollut selkeä. Toisaalta ne pyynnöt, joissa oli liikaa tietoja tai jotka oli sekavasti kirjoitettu, suljettiin myös. Arkki-tehdeillä ei ollut aikaa paneutua kunnolla tällaisiin asioihin. Hyvien vastausten kirjoit-taminen on myös aikaa vievää puuhaa. Ohjel-moijien pitää voida luottaa siihen, että arkki-tehdit ovat oikeassa.

Ohjelmoijat hermostuivat ja ryhtyivät käyttä-mään kaikenlaisia ohituskeinoja tullakseen kuulluksi. Arkkitehdit hermostuivat, koska työtaakka vain kasvoi kasvamistaan.

Järjestelmä olikin eristänyt ohjelmoijat ja ark-kitehdit toisistaan. Sen myötä läpimenoajat olivat kasvaneet ja näkyvyys kadonnut koko-

naan. Kukaan ei ollut ymmärtänyt, että juu-riongelma oli arkkitehtien tarve osoittaa tar-peellisuutensa ja pitää järjestelmä kontrollis-saan.

KONTROLLISTA FASILITOINTIIN

Monissa ketterissä menetelmissä korostetaan, että tuotetta ei kannata ylisuunnitella etukä-teen. Näkemyksen mukaan tekninen arkki-tehtuuri ilmaantuu ajan myötä itsestään (ns. emergent design). Tämä vaatii sen, että ohjel-misto on yhteisessä omistuksessa. Jos koodaa-jia on niin paljon, että omistajuuden tunne hukkuu, tarvitaan erillinen järjestelmäarkki-tehti tai jopa arkkitehtuuriryhmä. Omistajuu-den tunne näyttäisi kokemuksen perusteella katoavan, mikäli ohjelmistoa koodaavien ryh-mäkoko kasvaa yli 20–25 henkilön.

Arkkitehdin tai arkkitehtuuriryhmän tehtävä ei ole ”luoda suurta arkkitehtuuria”. Heidän tehtävänsä on sen sijaan fasilitoida ja koordi-noida. Heidän on luotava ympäristö, jossa on hyvä keskustella ja päättää arkkitehtuurista yhdessä. Arkkitehdit pitävät myös huolta arkkitehtuuridokumentaatiosta ja päättävät arkkitehtuurin laatutasosta.

Yksi käytännön ratkaisu on arkkitehtuurin kauppatori. Tällainen tori on foorumi, johon eri käyttäjät voivat tulla arkkitehtuuriin liit-tyvien kysymyksensä ja tarpeidensa kanssa. Arkkitehdin tehtävä on silloin:

olla torilla, eli olla tavoitettavissa hel-posti ja nopeasti

varmistaa että arkkitehtuuripäätökset etenevät verkkaisesti (eli poistetaan turhat vaiheet ja odotukset lean-mallin mukaisesti)

ohjata ja fasilitoida arkkitehtuurikes-kustelua

kutsua kaikki sidosryhmät mukaan keskusteluun ja päätöksentekoon

varmistaa että myös eriävät mielipi-teet ja vaihtoehtoiset ratkaisut pääse-vät esille (vrt. set-based concurrent engineering ja real options -menetelmät)

valvoa että päätökset toteutetaan so-pimuksen mukaisesti

ylläpitää arkkitehtuuripäätöksissä riittävää laatutasoa

ylläpitää päätöksentekoon riittävä määrä dokumentaatiota, esim. järjes-telmäkuvaus

ylläpitää arkkitehtuurikysymyksiin liittyvää ohjeistusta.

Tämä konsepti soveltuu myös käyttöliittymä-suunnitteluun ja prosessikehitykseen.

ONNISTUNUT SKAALAAMINEN

Laajamittainen organisaation muutos ketterää kehitystä tukevaksi voidaan katsoa onnistu-neeksi, kun yritys on luonut kyvyn luoda uut-ta toiminnallisuutta huomattavasti nopeam-min, tehokkaammin ja lyhyemmissä sykleissä. Toisin sanoen yrityksen ketteryyden mittari on, kuinka usein yritys pystyy julkaisemaan hyvälaatuisia tuotteita ja reagoimaan markki-noilla havaittuihin tarpeisiin. Tällaisessa or-ganisaatiossa teknistä velkaa ei juurikaan ole, arkkitehtuuri on kunnossa ja asiantuntijat tukevat tiimien työskentelyä.

Yrityksen sisäinen kommunikaatio on vapaata ja mahdollisimman vähän arvolatautunutta. Yritys mittaa onnistumistaan asiakastyytyväi-syyden kautta. Asiakkailta kerätty palaute käsitellään sähköisesti, ja asiakastyytyväisyys toimii syötteenä yrityksen ohjaamiseksi. Tämä kaikki luo motivaatiota ja sitoutumista yri-tyksen tavoitteisiin.

Automaatiota käytetään ihmisten ehdoilla ja ihmisten avuksi. Tällöin pienellä porukalla ja vähällä vaivalla voidaan toteuttaa asioita, jot-ka ennen sitoivat valtaosan henkilöstöstä. Vapautuneet voimavarat ja asiantuntemus on kanavoitu luomaan uusia innovaatioita.

OPPIVA ORGANISAATIO: KOKO AJAN KETTERÄMMÄKSI

Ison organisaation ketteröittämistä voi tar-kastella myös oppivan organisaation teorioi-den kautta. Organisaatio oppii ketterästä ja ketteröitymisestä syklisesti. Seuraava oppi-miskierros rakentuu aina edellisen päälle.

Käytännössä parhaimpia tapoja organisaation ketteröittämiseen on aloittaa yhdestä tiimistä ja laajentaa siitä. Jopa yhden tiimin ketteröit-täminen vaatii usein ulkopuolista osaamista,

esim. ulkopuolista kokenutta Scrum Masteria tai tuoteomistajaa.

Tällainen lähestymistapa ei aina kuitenkaan ole mahdollinen. Kun osa tiimeistä alkaa nou-dattaa scrum-menetelmää ja alkaa tuottaa julkaisuja huomattavasti muita tiimejä nope-ammin, tällä on väistämättä välittömiä vaiku-tuksia kaikkiin organisaation tiimeihin. Tii-mien tuottamilla ohjelmistokomponenteilla on usein keskinäisiä riippuvuuksia. Riippu-vuuksista johtuen koodimuutoksia pitäisi tapahtua suurin piirtein yhtä aikaa. Ellei kai-kille toisistaan riippuvaisille tiimeille mahdol-listeta muutosta samaan aikaan, on riskinä että osa tiimeistä lähtee omille ketterille po-luilleen. On olemassa joukko tyypillisiä virhei-tä, jotka syntyvät ketterän kehityksen vää-rinymmärryksiä. Kaikkien tyypillisimpiä vir-heitä ovat:

1. kaikki tulevaisuuden suunnittelu lo-petetaan

2. kaikki dokumentaatio lopetetaan 3. aletaan elämään kuin pellossa ja kyhä-

tään ohjelmisto vain jotenkuten ka-saan.

Suuri muutos on aina suuri riski. Jos organi-saatiolla ei ole varaa kouluttaa kaikkia heti alusta pitäen uusiin toimintatapoihin, laaja-mittaisessa muutoksessa voi syntyä epäsel-vyyttä siitä, miten uusien tapojen mukaan tulisi toimia. Kuten kaikissa muutoksissa, myös ketterässä muutoksessa muutoksenhal-linta on syytä järjestää huolella. Muutoksen-hallinta on perinteisesti nähty organisaation johdon tehtäväksi. Tästä johtuen organisaati-on johdon on syytä hankkia ymmärrys siitä, mitä ketterä kehitys on, mitä se tarkoittaa kyseisessä organisaatiossa ja missä järjestyk-sessä ketterä muutos etenee. Tämän jälkeen johto voi kouluttaa muun organisaation. Tämä myös estää tehokkaasti muutokselle vastais-ten hankkeiden suunnittelun ja edistämisen.

Jokainen ihmisryhmä ja yksittäinen henkilö etenee oppimisessaan normaalia oppimispol-kua pitkin. Ensin opitaan noudattamalla uutta mallia kirjallisesti (following, shu). Kun on tehty aikansa ”kirja-ketterää”, ymmärretään, miksi käytännöt ovat muodostuneet sellaisik-si kuin ne ovat (detaching, ha). Lopulta oival-letaan, mikä ketteryydessä on oleellista (fluent, ri). Samanlainen kaava on löydettävis-

sä kaikessa oppimisessa, opetellaanpa sitten ketterää kehitystä tai aikidoa.

Itse oppiminen tapahtuu oppivan organisaati-on teorioiden mukaan ihmisten välillä. Kun yhdellä ihmisellä on joku ajatus, jonka hän pukee sanoiksi, mahdollistaa se muiden kom-mentoinnin omasta näkökulmastaan. Oppi-minen on lopputulos, jossa kummallekin kes-kustelijoista syntyy asiasta näkemys joka on syvempi ja laajempi kuin kummallakaan aikai-semmin oli.

Ei siis kannata pelätä välillä kiivaiksikin ylty-viä keskusteluja, kun organisaatio käy läpi ketterää uudistusta. Kun avaamme itsemme ja ajatusmaailmamme muiden tarjoamalle kritii-kille, mahdollistamme kaikenlaisen oppimisen palautteen avulla. Koska oppiminen tapahtuu ihmisten välillä, ovat jatkuvat organisaa-tiomuutokset erittäin vahingollisia oppimisen näkökulmasta. Kun ihmisten väliset sidokset rikkoutuvat, loppuu myös sidoksissa meneil-lään ollut oppiminen. Uusien oppimissuhtei-den luomiseen kuluu sama aika kuin ihmisillä kuluu toisiinsa tutustuessa – usein puoli vuot-ta ja joskus ylikin.

Organisaation kannalta on ongelmallista, jos organisaatiossa on poliittisia klikkejä ja tasku-ja, joilla on omia, ei-yhteisiä intressejä. Poliit-tisella tarkoitetaan tässä sitä, etteivät ihmiset kommunikoi aidosti sitä, mitä todella ajattele-vat. He vastaavat sen sijaan siten, mitä he olet-tavat heiltä odotettavan. Tällainen käytös (ja siten yrityksen sisäinen politiikka) on aitoa oppimista estävä ilmiö.

Klikkejä tai poliittista sitoutumista tiettyyn aatteeseen tai työkaluun esiintyy erityisesti silloin, kun joku ihminen on laittanut oman arvovaltansa kyseisen toimintatavan tai työ-kalun taakse. Organisaatioissa saattaa olla tällaisia vaiettuja virtahepoja. Ketterä toimin-tatapa paljastaa usein virtahevoista aiheutu-neet ongelmat. Jos organisaatiossa on lisäksi tapana ampua ikävien viestien tuojat, saattaa olla turvallisempaa valita ulkopuolinen kon-sultti kertomaan epämiellyttävä viesti. Kon-sultit ovat usein hyviä syntipukkeja, sillä he ovat vaihdettavissa eikä yritys ole niin sitou-tunut heihin kuin omaan henkilöstöönsä. Mo-nessa tapauksessa virtahevosta luopuminen saattaa vaatia myös henkilövaihdoksia.

Vastaavanlainen sitoutuminen työkaluihin ja toimintatapoihin voi olla nähtävissä myös yksittäisten kehittäjien tasolla. On kohtuu-tonta olettaa, että vaikkapa käsin tehtävästä integraatiosta vastaavat henkilöt olisivat ha-lukkaita tai kykeneviä automatisoimaan omat työtehtävänsä. Ensinnäkin uudet työkalut ja toimintatavat vaativat näiden syvällistä tun-temusta ja niiden opiskelu oman täyspäiväisen työn ohella voi olla mahdoton tehtävä. Toisek-si henkinen kynnys omien työmenetelmien poisoppimiseen voi olla korkea ja aiheuttaa stressiä. Tästä syystä on suositeltavaa, että muutokset toteuttaisi erillinen, päivittäisru-tiineista irti oleva pieni asiantuntijatiimi. Ko-kemuksen myötä tämä on ollut isoissa organi-saatioissa ainoa tapa saada merkittäviä muu-toksia aikaan suhteellisen lyhyessä ajassa.

Hyvään muutoksenhallintaan kuuluu tieten-kin myös ihmisistä ja heidän henkisestä hy-vinvoinnistaan huolehtiminen muutoksen aikana. Tämä tarkoittaa jatkuvaa säännöllistä kommunikointia muutoksesta, sen tavoitteis-ta ja nykytilasta. Työntekijät on uudelleen-koulutettava uusiin työtehtäviin, kun muutos on ajankohtainen. Fiksu yritys sijoittaa vapau-tuneet henkilöt tuottamaan uusia innovaatioi-ta yrityksen tarpeisiin. Geoffrey Moore puhuu neutralisoivasta innovaatiosta. Tällöin tuote-taan jo olemassa olevaan massatuotteeseen uusia ominaisuuksia, joita kilpailijatkin tuo-vat markkinoille. Radikaali innovaatio taas tarkoittaa, että yrityksen voimavaroja voidaan suunnata täysin uusiin tuotteisiin tai uusille tuotealueille. Mooren mukaan kansainvälinen kilpailu on kiristynyt niin paljon, että yrityk-set pelataan ulos markkinoilta, ellei heillä ole kykyä sijoittaa ketterän kehityksen vapaut-tamia voimavaroja tekemään radikaaleja inno-vaatioita. Toisaalta ketterät menetelmät ovat omimmillaan, kun pienissä tiimeissä toteute-taan uusia tuotteita. Laajamittainen ketterä kehitys on siis tapa tehostaa yrityksen toimin-

taa. Pysyäkseen kilpailukykyisenä, yritys tar-vitsee sekä neutralisoivaa että radikaalia inno-vaatiota.

Lähteet

F. P. Brooks. The Mythical Man-Month: Es-says on Software Engineering. Addison-Wesley, Reading, MA, 1975.

A. A. R. Cockburn. Characterizing people as non-linear, first-order components in software development. HaT Technical Report 1999.03, Humans and Technology, 1999. Presented at the 4th International Multi-Conference on Systems, Cybernetics and Informatics, Orlan-do, Florida.

R. I. M. Dunbar. Neocortex size as a con-straint on group size in primates. Journal of Human Evolution, 22(6): 469–493, June 1992.

V. Heikkilä, K. Rautiainen, and J. Vähäniitty, editors. Towards Agile Product and Portfolio Management. Aalto University, Espoo, 2010.

H. Kniberg. Lean from the trenches: An exam-ple of Kanban in a large software project. Downloadable booklet, June 26, 2011. URL http://www.crisp.se/henrik.kniberg/Lean-from-the-trenches.pdf.

W.J. Latzko. Four Days with Dr. Deming: A Strategy for Modern Methods of Manage-ment. Prentice Hall, 1995.

D. Leffingwell and D. Widrig. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Ad-dison Wesley, 2010.

G. Moore. Escape Velocity: Free Your Compa-ny’s Future from the Pull of the Past. Harper-Business, 2011.

KIITOKSET

Kirjan kirjoittamista ovat tukeneet:

Systeemityöyhdistys Sytyke ry

Sytyke ry yhdistää suomalaiset tietojärjestelmätyön ammattilaiset liiketoiminnasta teknisiin asi-antuntijoihin. Ajankohtaisia systeemityöteemoja, ajatusten vaihtoa ja oppimista alan ammattilais-ten kesken – hypetystä tervejärkisesti.

www.sytyke.org

Tietotekniikan liitto ry

Tietotekniikan liitto ry, TTL, on valtakunnallinen ja puolueeton tietotekniikka-alalla toimivien yhdistysten yhteistyöjärjestö, joka koostuu lähes 30 alueellisesta yhdistyksestä, teemayhdistyk-sestä tai opiskelijayhdistyksestä. Liittoyhteisön jäseninä on 15.000 alan ammattilaista ja lähes 500 tietotekniikkaa tuottavaa tai sitä käyttävää yritystä ja muuta organisaatiota. TTL:n tavoitteena on jäsenistön ammatillisen osaamisen ja arvostuksen kehittäminen.

www.ttlry.fi

Agile Finland ry

Agile Finland ry is a non-profit association of software professionals. The purpose of Agile Fin-land is to raise the public’s awareness of Agile Software Development, advance the use of Agile and increase it’s members’ Agile knowhow.

www.agile.fi

Ambientia oy

Ambientia on konsultointi-, suunnittelu- ja sovelluskehitysyritys, joka luo verkko- ja mobiiliso-velluksia asiakkaiden liiketoiminnan digitalisoimiseksi.

JÄLKISANAT

Kirja sisältää yksittäisten kirjoittajien omia kokemuksia ja mielipiteitä, jotka voivat olla keske-nään ristiriitaisia. Kaikki kirjoittajat eivät välttämättä ole samaa mieltä kaikista kirjassa esitet-tyistä mielipiteistä.

Kirjan aihepiiri on vaikea ja sisältää hienovaraisia piirteitä. Mikäli päätät soveltaa kirjan oppeja käytäntöön, suosittelemme, että otat yhteyttä johonkin henkilöön tai tahoon, joka voi tukea sinua tehtävässäsi.

Alalla käytetty ammattiterminologia on myös kirjavaa ja osittain ristiriitaista. Resurssien riittä-mättömyyden vuoksi termejä ei määritelty erikseen koko kirjaa varten. Toivomme lukijan sovel-tavan luovaa ymmärrystä.

TEKIJÄT

Kirjaa ovat tehneet yhdessä seuraavat henkilöt:

Antti Auer Laatupäällikkö, OP-Palvelut Oy Dipl.ins., Fil. tri, väitöskirja “State testing of embedded software”. Yli 30 vuotta kokemusta ohjelmistokehityksestä. antti.j.auer@gmail.com

Liisa Auer Lehtori, Oulun seudun ammattikorkeakoulu, FM FM, lehtori, tietojenkäsittelyn koulutusohjelma. 30 vuotta alan kokemusta. liisa.auer@gmail.com

Miikka Heinäsmäki Tomorrow’s Information Management Today Yli 30 vuotta kokemusta ohjelmoinnista, projektitoiminnasta, tuotekehityksestä ja IT-organisaatioiden johtamisesta niin asiakasyrityksissä, IT-palvelutoimittajana kuin johdon kon-sulttinakin. Silti aina avoimella mielellä tehdä asioita uudella tavalla. heinasmaki@yahoo.com

Jussi Hölttä Agile Finland, Elisa Oyj Coach. Reilu 5 vuotta taustaa ohjelmistokehityksestä ennen siirtymistä enemmän ihmisten paris-sa toimimiseen. Ensimmäisen kirjapyrähdyksen fasilitaattori. jussi.holtta@gmail.com, http://jussiholtta.tumblr.com, @jussiholtta

Eija Kalliala Systeemityöyhdistys Sytyke ry eija.kalliala@gmail.com, @eijakalliala Työskennellyt tietojärjestelmäprojekteissa, ohjannut ammattikorkeakouluopiskelijoiden verkko-palveluprojekteja ja ollut mukana ketterässä projektityössä käyttäjän edustajana. Tietokirjailija, 5 julkaistua kirjaa, joista 4 yhteiskirjoitettua ja 3 Sytyke-raportteja 1990-luvulta. Kirjoittanut lisäk-si lukuisia asiantuntija-artikkeleita. Sytyke-lehden päätoimittaja vuonna 2013.

Maarit Laanti Johtaja, Head Agile and Lean Coach, Nitor Delta, www.nitorcreations.com Dipl. ins, Fil. tri väitöskirja “Agile Methods in Large-Scale Product Development Organizations – Applicability and Model for Adoption” Oulun Yliopisto, 2013 Yli 20 vuotta kokemusta ohjelmistoteollisuudessa, yli 10 vuotta kokemusta projektin- ja organi-saatioiden johtamisesta, 5,5 vuotta kokemusta isojen organisaatioiden agile transformaatioista. Kirjan Ohjelmistoliiketoiminta (toim. Hyvänen, E, 2003) ja Less! Essays on Business Transforma-tion (toim. Mårtensson, H 2012) osakirjoittaja. Certified SAFe Program Consultant. maarit.laanti@iki.fi

Kati Laine F-Secure Oyj Senior Manager. 15 vuotta kokemusta ohjelmistokehityksestä ohjelmoijana, projektipäällikkönä, Scrum Masterina, tiimiesimiehenä, kompetenssiesimiehenä ja tuotekehitysyksikön vetäjänä. Vii-me vuodet keskittynyt tiimien ja prosessin kehittämiseen. lainekati@gmail.com

Lare Lekman larelekman.com Ketterän kehityksen kouluttaja ja valmentaja. Agilea, Scrumia ja Leania vuodesta 2003. lare.lekman@gmail.com

Paula Miinalainen Arbor Vitae - Finland Oy Ltd Riippumaton konsultti, Certified Scrum Product Owner (CSPO), yli 40 vuotta kokemusta ICT:n eri tehtävissä, yli 10 vuotta kokemusta projektien valvontatehtävistä ja samoin yli 10 vuotta ko-kemusta ketteristä menetelmistä. Paula.miinalainen@arborvitae.fi, www.arborvitaepalvelee.com

Heikki Naski Systeemityöyhdistys Sytyke ry, Soprano Digital, Codemate Oy Ohjelmistokehittäjä, 6 vuotta alan kokemusta. heikki.naski@gmail.com

Timo Piiparinen Systeemityöyhdistys Sytyke ry , Kymijoen Työterveys Oy Grafiikat. timo.piiparinen@sytyke.org

Hannu Puhakka Qality Systems Network Ltd Konsultti. 30 vuoden kokemus pienen ohjelmistoyrityksen vetämisestä ja kehittämisestä. Järjes-telmien määrittelyä, toteutuksen johtamista, yritystoiminnan prosessien kehitystä, ohjelmisto-ammattilaisten kasvatustyötä. hannu.puhakka@gmx.com

Maaret Pyhäjärvi testausasiantuntija, Granlund Oy | TestausOSY Päätoiminen testausasiantuntija pienessä tuotekehitysporukassa. Sivutoiminen kouluttaja testa-uksen saralla. Monessa kohden mukana tekemisen kappaleessa. maaret.pyhajarvi@iki.fi

Tuula Pääkkönen TestausOSY Innostuva tekijä, vikojen löytäjä. Yli 13 vuoden kokemus testiautomaatiosta, testaushallinnasta -

työkalujen kehittämisestä prosesseihin. tuula.paakkonen@iki.fi, @TuulaP

Jussi Rosti Toimitusjohtaja, FM, Aakkosto Oy Yli 8 vuoden kokemus ohjelmistokehityksestä, yli 10 vuoden kokemus käännösalalta (runsaasti mm. ICT-alaan ja prosessinkehitykseen liittyviä käännöksiä)

Silja Räisänen Yli 20 vuoden kokemus ICT:n eri tehtävissä, merkittävä panos ICT-toimintatapojen ja menetel-mien kehittämisessä. 2001 lähtien erityiskiinnostus ketterän kehittämisen malliin; viime vuodet kehittänyt mallia isolle organisaatioille ja toiminut valmentajana. silja.raisanen@gmail.com

Henri Sora

Director, Technology and Services, Ambientia Oy Noin 12 vuotta kokemusta ohjelmistoliiketoiminnassa ja ketterien ohjelmistokäsityöläisten joh-tamisen parissa Ambientialla. henri.sora@ambientia.fi ja @henrisora

Marko Taipale Senior Partner, Principal Consultant, Chairman of the Board, Gosei Oy Yli 15 vuoden kokemus ohjelmistokehityksestä, joista 8 vuotta ketterää/lean toimintatapaa hyö-dyntäen, perustanut mm. tuotekehitysyhtiön, toiminut lähes kaikissa ohjelmistokehitysorgani-saation tehtävissä. Toimii ohjelmistotuoteliiketoiminnan ja -kehityksen konsulttina kaikenko-koisille yrityksille sekä johdon neuvonantajana kasvuyrityksille. marko.taipale@gosei.fi, @markotaipale

Jukka Talvio Director, Engineering Productivity, F-Secure Corporation Yli 20 vuotta ohjelmistokehityskokemusta, joista suurimman osan pyrkinyt iteratiiviseen ja in-krementaaliseen suuntaan. Käyttää mielelleen evolutionaariseen malliin sisällytettyjä opetuksia ja erityisesti eXtreme Programming yhteisön menetelmiä. jukka.talvio@iki.fi, www.broa.biz

Ari Tanninen Ohjelmistoinsinööri, tradenomioppilas, tuotekehityspäällikkö. 14 vuoden kokemus ohjelmisto-kehityksestä joista puolet ketterästi. Laaja kokemus melkein kaikesta ohjelmistokehitykseen liittyvästä alihankinnasta uuteen tuotekehitykseen niin startupeissa kuin isoisssa yrityksissä. ari.tanninen@iki.fi, @aritanninen

Tarmo Toikkanen Systeemityöyhdistys Sytyke ry, Aalto-yliopisto Oppimispsykologian tutkija, kirjailija, Scrum Master, projektipäällikkö, yrittäjä. 12 vuotta koke-musta ketterien monikansallisten tiimien vetämisestä. Olen tämän kirjaidean isä ja kirjapyräh-dyksen organisoija. Kirjoitin myös muutaman tarinan kirjaan ja osaltani osallistuin sen sisällön, kohderyhmän ja tavoitteiden suunnitteluun. @ikitarmo.fi, @tarmotoikkanen

Towo Toivola Director, Quality of Operations, F-Secure Oyj Ohjelmistokehitysorganisaation toiminnan ymmärtämisen, johtamisen ja kehittämisen ammatti-lainen. Yli 15 vuotta kokemusta rohkeasta ohjelmistojen ja järjestelmien kehittämisestä. Ymmärrän syvällisesti ohjelmistojen laadun ja pidän tärkeänä ymmärtää miksi. towo@iki.fi, www.broa.biz

Kimmo Toro F-Secure Oyj

Ohjelmistokehittäjä, ketterä valmentaja. Yli 15-vuotta kokemusta ohjelmistokehityksestä. Viime vuosina olen keskittynyt tuotekehityksen toimintatapojen, menetelmien sekä työkalujen kehit-tämiseen. kto@iki.fi, @ktoro

Anne Valsta HAAGA-HELIA ammattikorkeakoulu FM, lehtori, tietojenkäsittelyn koulutusohjelma. Reilut 30 vuotta alan kokemusta. anne.valsta@haaga-helia.fi ja valstanne@gmail.com

Virve Väyrynen IT-tradenomi, ECQA Certified Innovation Manager Töissä ohjelmistokehityksen ja administraattorin tehtävissä yhdeksän vuotta, suurimman osan ajasta ketteriä ohjelmistokehitysmenetetelmiä käyttävissä yrityksissä. Kiinnostukseni; yrityksen kokonaisarkkitehtuurin tutkiminen, ketterä ohjelmistokehitys, testiautomaatio, semanttinen web. virve.vayrynen@gmail.com

Martin von Weissenberg Agile Finland ry, agile42 Oy Tietotekniikan DI, ketterä valmentaja, kouluttaja ja transitiojohtaja. Ohjelmistoteollisuudessa 1993 lähtien, ketteryyttä vuodesta 2004, valmennusta vuodesta 2007. Työn alla väitöskirja organi-saatiotason ketteryydestä. mvw@iki.fi, @mvonweis