Atte Tuomisto KETTERÄÄN OHJELMISTOKEHITYKSEEN SIIRTYMISEN HAASTEET SUUREN ORGANISAATION NÄKÖKULMASTA

Atte Tuomisto KETTERÄÄN OHJELMISTOKEHITYKSEEN SIIRTYMISEN HAASTEET SUUREN ORGANISAATION NÄKÖKULMASTA JYVÄSKYLÄN YLIOPISTO 2017

TIIVISTELMÄ Tuomisto, Atte Ketterään ohjelmistokehitykseen siirtymisen haasteet suuren organisaation näkökulmasta Jyväskylä: Jyväskylän yliopisto, 2017, 23 s. Tietojärjestelmätiede, kandidaatin tutkielma Ohjaaja: Kollanus, Sami Ketterä ohjelmistokehitys ja ketterät menetelmät ovat kasvattaneet suosiotaan vuosi vuodelta ja niiden menestyksen johdosta myös suuremmat organisaatiot ovat kiinnostuneet niiden käyttöönotosta. Kuitenkin suuri organisaation koko saattaa vaikeuttaa muutosta ketterään ohjelmistokehitykseen, sillä ketterät menetelmät ovat suunniteltu pieniä projekteja ja organisaatioita ajatellen. Näin ollen se tuo organisaation muutokselle uusia haasteita. Tässä tutkielmassa käsitellään ketteryyttä ja sen merkitystä organisaatiolle sekä määritellään mitä suuren mittakaavan ketterällä ohjelmistokehityksellä tarkoitetaan. Tutkimuksessa haluttiin tutkia, mitä muutoksen haasteita organisaatiolla on siirryttäessä ketterään ohjelmistokehitykseen. Tutkielman tulokset osoittavat, että tyypillisimmät haasteet suuren organisaation muutoksessa ketterään ohjelmistokehitykseen olivat muutosvastaisuus, ketteryyden käyttöönoton vaikeus, riittämätön panostus, ketteryyden heikko sisällyttäminen kaikkiin organisaation osiin ja vaatimusmäärittelyyn liittyvät haasteet. Näiden lisäksi haasteina olivat myös yleinen kommunikoinnin ja koordinoinnin haasteet sekä läpinäkyvyyden ylläpitäminen muutoksessa. Asiasanat: ketteryys, ketterät menetelmät, suuri organisaatio, muutos, ohjelmistokehitys

ABSTRACT Tuomisto, Atte Challenges in large-scale agile transformations Jyväskylä: University of Jyväskylä, 2017, 23 p. Information Systems, Bachelor s thesis Supervisor: Kollanus, Sami Agile software development and agile methods have been gaining popularity through the recent years and because of their success also the larger organizations have been getting more interest in applying them into their organization. However, the size of the organization might make the transformation more challenging, because agile methods have been designed for small projects and organizations. Therefore, it brings new challenges to the organization's transformation. This research discusses about agile software development, its meaning for organization and define the criteria for large-scale agile and what kind of challenges large organization faces when it is transforming to large scale agile. For the research problem, it has been answered by searching articles with systematic search method. The results showed that the most typical challenges in large-scale agile transformation were change resistance, implement difficulties, not enough investment, implementing agile to other organization functions and challenges with requirements engineering. Also, there were challenges about communication, coordination and transparency. Keywords: large-scale agile, transformation, agile methods, software development

TAULUKOT Taulukko 1 Analyysiin valitut lähteet... 15

SISÄLLYS TIIVISTELMÄ ABSTRACT TAULUKOT 1 JOHDANTO... 6 2 KETTERÄ OHJELMISTOKEHITTÄMINEN... 8 2.1 Ohjelmistokehittäminen ja ketterä ohjelmistokehittäminen... 8 3 SUURI KETTERÄ KEHITTÄMINEN JA SIIHEN SIIRTYMINEN... 11 3.1 Suuri ketterä kehittäminen... 11 3.2 Suureen ketterään ohjelmistokehittämiseen siirtyminen... 12 4 HAASTEET SIIRRYTTÄESSÄ SUUREEN KETTERÄÄN OHJELMISTOKEHITTÄMISEEN... 14 4.1 Aineiston keräämisen metodit ja löydetyt havainnot... 14 4.2 Haasteet siirryttäessä suureen ketterään ohjelmistokehittämiseen.. 16 4.3 Vertaaminen aiempaan tutkimukseen... 17 5 YHTEENVETO JA POHDINTA... 19 LÄHTEET... 21

6 1 JOHDANTO Ketteryyden ja siihen liittyvien menetelmien alkaminen ohjelmistokehityksessä voidaan ajoittaa noin 1990-luvun loppuun ja 2000-luvun alkuun (Boehm, 2002; Dybå & Dingsøyr, 2008). Vuonna 2001 kirjoitetun Agile manifeston asetettuihin arvoihin ja periaatteisiin pohjautuvaa ajatusmaailmaa käytetään laajalti ohjelmistokehityksessä ja se on kasvattanut suosiotaan vuosi vuodelta (Dingsøyr ym., 2012; Campanelli & Parreiras, 2015). Ketteryyteen liittyvät menetelmät ovat tapa tehdä töitä projektinomaisesti noudattaen tiettyjä asetettuja arvoja ja toimintatapoja (Hamed & Abushama, 2013). Ketteryys on syntynyt vastareaktiona niin sanottujen perinteisten ohjelmistokehityksen malleihin ja niiden tapaan toimia suunnitelmallisesti ja prosessinomaisesti (Dybå & Dingsøyr, 2008). Ketteryydessä korostetaan nopeaa reagoimista muuttuviin ympäristöihin ja ihmiskeskeisyyteen (Nerur ym., 2005). Ketterässä ajatusmaailmassa hyväksytään se, ettei kaikkeen ei voida varautua etukäteen, vaan on pystyttävä mukautuvaan muuttuviin vaatimuksiin ja esiintyviin ongelmiin (Dybå & Dingsøyr, 2008; Campanelli & Parreiras, 2015). Hyvät kokemukset ketterien menetelmien toimivuudesta ja tehokkuudesta on saanut eri suuruiset organisaatiot kiinnostumaan näistä menetelmistä (Dingsøyr & Moe, 2013). Organisaation muuttaminen ketteräksi ja ketterien menetelmien käyttöönottaminen ei ole kuitenkaan helppoa, sillä se vaatii valtavasti panostusta, organisaation kulttuurin muovaamista ja ihmisten muutoksen hyväksymistä (Dybå & Dingsøyr, 2008). Lisäksi näihin menetelmiin siirtymisen haastavuus on liitoksissa myös organisaation kokoon, joka tuo muutokseen lisää haasteita mitä suurempi organisaatio on kyseessä (Kettunen & Laanti, 2008). Suurissa organisaatioissa lisävaikeutta muutokseen aiheuttaa erityisesti erityisempi tarve koordinoinnille ja monimutkaisempi organisaatiorakenne (Olszewska ym., 2016). Siitä huolimatta suurien organisaatioiden kiinnostus ketteryyttä kohtaan on jo viimeistään nyt herännyt ja ketterien menetelmien käyttäminen suuressa mittakaavassa on kasvattanut suosiotaan (VersionOne, 2016, Paasivaara ym., 2014). Vaikka aihealueeseen on kiinnostusta, tutkimus laahaa pahasti käytännön perässä. (Dikert ym. 2016). VersionOnen tekemän vuosittaisen kyselyn (2016)

7 perusteella kuitenkin yli puolet vastanneista työskentelivät organisaatioissa, joissa työskentelee vähintään 100 henkilöä, jota voidaan pitää jo melko suurena organisaationa. Järjestetyssä XP2010 konferenssissa tehdyn kyselyn perusteella Freudenberg ja Sharp (2010) tekivät ammatinharjoittajien vastauksista kymmenen halutuinta tutkimuskohdetta. Näistä eniten ääniä sai ketteryys ja suuret projektit. Lisäksi mainintoja sai ketteryyden adoptoiminen organisaatioon. Tarve aihealueen tutkimukselle on siis perusteltua. Tämän tutkielman tarkoituksena on selvittää mitä tarkoitetaan suuren mittakaavan ketteryydellä, mitä siihen siirtyminen vaatii ja mitä haasteita muutosvaiheessa organisaatiolla saattaa esiintyä siirryttäessä ketterään ohjelmistokehittämiseen. Tutkimuksen tavoitteena on lisätä ymmärrystä siitä, mitä suuren organisaation on otettava huomioon silloin kun se on muuttamassa organisaatiotaan käyttämään ketterää lähestymistapaa ja ketteriä menetelmiä. Tämän perusteella kirjallisuuskatsauksen tutkimuskysymykseksi on asetettu seuraava kysymys: Mitä haasteita on raportoitu organisaation muuttuessa suuren mittakaavan ketterään ohjelmistokehittämiseen? Tutkielma koostuu johdannon lisäksi neljästä muusta luvusta. Luvussa 2 käsitellään ketterää ohjelmistokehittämistä ja sen tuomia hyötyjä sekä sen eroja traditionaaliseen ohjelmistokehittämisen. Luvussa 3 määritellään, mitä tarkoitetaan suurella ketterällä kehittämisellä ja käsitellään yleisesti suuren organisaation muutosta ketterien menetelmien käyttöön. Luvussa 4 esitetään tässä tutkielmassa tehdyn systemaattisen aineistonkeruun metodit ja raporttien analysoinnista löydetyt havainnot tämän tutkielman tutkimuskysymykseen ja verrataan löydöksiä aiempaan tutkimukseen. Luvussa 5 on tämän tutkielman yhteenveto ja johtopäätökset, jossa vedetään yhteen tämän tutkielman tärkeimmät kohdat, pohditaan löydöksien merkitystä ja nostetaan niistä tärkeimmät havainnot ja esitetään mahdollisia jatkotutkimuskohteita.

8 2 KETTERÄ OHJELMISTOKEHITTÄMINEN Tässä luvussa käsitellään ohjelmistokehitystä ja siihen kuuluvaa ketterää kehittämistä sekä kerrotaan lyhyesti traditionaalisen ja ketterän ohjelmistokehityksen eroista ja ketteryyden hyödyistä. Aluksi luvussa esitellään kaksi lähestymistapaa, joilla ohjelmistokehitystä tehdään, eli traditionaalista ohjelmistokehitystä ja ketterää kehittämistä. Tämän jälkeen näitä verrataan ja lopuksi esitetään lyhyesti mitä etuja ketteristä menetelmistä on verrattuna traditionaalisiin menetelmiin. Nämä asiat luovat ymmärrystä tutkielman aihealueelle, termistölle ja se antaa pohjaa tutkielman varsinaiseen tutkimusongelmaan. 2.1 Ohjelmistokehittäminen ja ketterä ohjelmistokehittäminen Ohjelmistoja on ehditty kehittämään jo muutamia vuosikymmeniä. Tässä ajassa niiden tekemiseen on kehitetty jo lukuisia tekniikoita ja menetelmiä, joiden avulla ohjelmistojen tekemisestä saadaan mahdollisimman tehokasta ja hyvää laatua tuottavaa (Hamed & Abushama, 2013). Yhteistä näille menetelmille kuitenkin on se, että ohjelmistoja tehdään projektinomaisesti tiimeissä (Hamed & Abushama, 2013). Näitä eri tapoja on monia, joista kaksi yleisintä on traditionaaliset menetelmät ja ketterät menetelmät (Dybå & Dingsøyr, 2008). Näihin lähestymistapoihin kuuluu lukuisia erilaisia kehitettyjä viitekehyksiä, jotka antavat raamit toiminnalle. Ne sisältävät esimerkiksi joukon tehtäviä ja vaiheita, joita projektin elinkaaren ajan tulisi projektissa toteuttaa. Näitä viitekehyksiä on esimerkiksi ketteriin malleihin kuuluvat suosituimmat Scrum ja Extreme programming, jotka on kehitetty alan harjoittajien toimesta (Dybå & Dingsøyr, 2008.) Koko tämän vuosituhannen ajan ketterät menetelmät ovat kasvattaneet suosiotaan ohjelmistokehityksen käytössä ja se on alkanut vakiinnuttaa asemaansa alalla (Dingsøyr ym., 2012). Ketteristä malleista ja ketteryydestä eli agilesta on ajan saatossa muodostunut varteenotettava ja suosittu vaihtoehto mainituille traditionaalisille tavoille (VersionOne, 2016).

9 Traditionaalisissa lähestymistavoissa tyypillistä on niiden perusteellinen tarvesuunnittelu kehityksen alussa, jonka mukaan projekti viedään läpi ja pyritään siihen, että siitä poikettaisiin mahdollisimman vähän (Highsmith & Cockburn, 2001). Kyseisessä lähestymistavassa tyypillisesti edetään vaihekokonaisuudesta toiseen ja vaiheissa erityisesti korostuu alkuvaiheen tarkka tarvemäärittely ja yleinen prosessikeskeinen luonne. Lisäksi kommunikaatio on usein virallista ja muodollista. Näissä organisaatioissa yleisesti on myös enemmän byrokratiaa (Nerur ym., 2005.) Tässä ajatusmaailmassa on kuitenkin vahvuutensa ja heikkoutensa. Traditionaalisissa lähestymistavoissa perusajatuksena on, että riittävän perusteellisella tarvemäärittelyllä ja suunnittelulla voidaan ennustaa projektin eteneminen ja näin ollen välttää kustannuksia. Tämä tarkoittaa myös sitä, että suunnitelmien muutoksiin projektin aikana suhtaudutaan negatiivisesti (Highsmith & Cockburn, 2001.) Tämänkaltainen ajattelu ei kuitenkaan vastaa muuttuvan maailman tarpeisiin vaan se tekee työskentelystä jäykkää ja vaikeaa (Highsmith & Cockburn, 2001). Koska traditionaalinen lähestymistapa ei sovi hyvin muutoksiin on ketterien mallien käytöstä pyritty löytämään vastaus tähän ongelmaan (Dybo & Dingøyr, 2008). Ketterät menetelmät pohjautuvat vuonna Basili & Turner (1975) kehittämään inkrementaaliseen kehitykseen ja vuonna Fowlerin ja Highsmithin (2001) esittämään Agile manifestoon. Tässä manifestissa määriteltiin arvot ja periaatteet ketterälle ohjelmistokehittämiselle ja ne ovat muodostuneet ketteryyden kulmakiviksi (Dikert ym., 2016; Fernandes & Almeida, 2010). Manifesti koostuu seuraavista neljästä perusarvosta: Yksilöitä ja kanssakäymistä enemmän kuin menetelmiä ja työkaluja Toimivaa ohjelmistoa enemmän kuin kattavaa dokumentaatiota Asiakasyhteistyötä enemmän kuin sopimusneuvotteluja Vastaamista muutokseen enemmän kuin pitäytymistä suunnitelmassa Ketteryys nähdään siis koko organisaation ajattelutavan ja toimintaperiaatteiden kokonaisuutena, jotka pohjautuvat yllä esitettyihin arvoihin (Misra ym., 2010). Ketteryyttä noudattavassa ajattelumaailmassa on hyväksytty se, että maailma on ennalta-arvaamaton ja suunnittelemattomia muutoksia esiintyy väistämättä. Tämän lisäksi ketteryydessä laitetaan toiminnan keskiöön ennemminkin ihmiset ja ihmisten luovuus kuin tekemiseen kuuluvat prosessit (Dybå, 2000; Nerur ym. 2005.) Tähän filosofiaan pohjautuvia ketterän ohjelmistokehityksen menetelmiä on monia. Näillä ketterillä menetelmillä on omat käytänteet ja tekniikat, jotka antavat raamit ohjelmistojen tekemiselle. Näissä viitekehyksissä ja ketteryydessä yleisesti perusideana on, että asioita tehdään lyhyissä iteraatioissa, eli tyypillisesti muutaman viikon mittaisissa kehityssykleissä, joissa pyritään saada aikaiseksi jokin pieni kokonaisuus projektista. Näitä iteraatioita tehdään tarvitta-

10 van monta, jotta kehitettävä projekti saadaan valmiiksi (Fernandes & Almeida, 2010; Hamed & Abushama, 2013.) Näistä menetelmistä suosituimmat ovat Scrum ja Extreme Programming (XP) (Hamed ja Abushama, 2013) ja ne käydään seuraavaksi läpi lyhyesti. Scrum on menetelmä, joka on keskittynyt ketterään kehittämiseen projektinhallinnan näkökulmasta (Schwaber and Beedle, 2002). Tällä viitekehyksellä on tukeva asema ohjelmistokehityksen alalla (Hamed & Abushama, 2013; VersionOne, 2016). Se sisältää projektin jatkuvaa monitorointia, tiimityöskentelyn korostamista, henkilökohtaisia tapaamisia ja tehokasta ajanhallintaa. Siihen kuuluu vahvasti myös asiakkaan kanssa käytävä kontakti ja retrospektiiviset tapaamiset, joissa pyritään ehkäisemään ja vastaamaan vastoinkäymiset ja muutokset (Schwaber and Beedle, 2002.) Extreme programming eli XP on toinen suosittu ketterän kehittämisen menetelmä. Se on kehitetty varsinkin pienille tiimeille ja se pyrkii auttamaan ohjelmistokehitysympäristöissä, jossa muutos on jatkuvaa ja vaatimukset epämääräisiä (Beck, 1999). Tässä menetelmässä korostetaan lyhyitä kehityssyklejä, joiden tarkoituksena on pystytä vastaamaan uusiin vaatimuksiin ja parantamaan työn tehokkuutta. XP sisältää monia eri käytänteitä, joihin kuuluu niin pariohjelmointia, jatkuvaa ohjelmistokoodin testausta ja yleistä yksinkertaisuutta (Beck, 1999.) Dybå ja Dingsøyr (2008) mukaan tutkimuksissa on osoitettu, että ketterän ohjelmistokehityksen hyötyjä on esimerkiksi vaikutus asiakkaiden välisen kanssakäymisen parantumisena, parempana virheiden ja ongelmien ratkomisena ja hallitsemisena, työntekijöiden nopeampana oppimisena esimerkiksi pariohjelmoinnilla, parempana tapahtumien ennakoimisena, työn tehokkaampana kohdistamisena ja arviointien parantumisena. Ketteryyden hyvästä soveltuvuudesta ohjelmistokehitykseen ja sen tuomista hyödyistä johtuen on ketterät menetelmät jatkuvassa suosiossa ja ne ovat herättäneet kaiken kokoisten organisaatioiden mielenkiinnon (Dikert ym. 2016).

11 3 SUURI KETTERÄ KEHITTÄMINEN JA SIIHEN SIIRTYMINEN Tämän luvun tarkoituksena on määritellä mitä tarkoitetaan suuren mittakaavan ketterällä kehittämisellä (large-scale agile), millä kriteereillä se määritellään ja mitä muutos vaatii suurelta organisaatiolta. Termin määrittely on tärkeää tutkimuksen kannalta ja kriteerien määrittely auttaa tämän tutkimuksen tutkimuskysymykseen vastaamista, antaen rajat sille, mitä organisaatiota kooltaan suurena. 3.1 Suuri ketterä kehittäminen Ketterää ohjelmistokehittämistä suuressa mittakaavassa ei ole tutkittu riittävästi ja sille ei ole vakiintunutta termiä. (Dikert ym., 2016). Myöskään sille millä kriteerillä suuruutta mitataan ei ole yhtenäistä tapaa (Dingsøyr & Moe, 2013). Tämänhetkinen lähin termi aiheelle on large-scale agile. Tälle termille ei ole vakiintunutta suomenkielistä vastinetta, joten tässä tutkielmassa käytetään termiä kuvaamaan suuren mittakaavan ketterää ohjelmistokehittämistä tai yleisesti suurta ketterää kehittämistä. Kuitenkaan siitä mitä termi merkitsee ja mitä se kokonaisuudessaan sisältää ei ole alan tutkimuksissa täyttä selkoa ja yhtenäisyyttä (Dingsøyr & Moe, 2013). Aihealue kuitenkin yleisesti käsittelee organisaation tai projektiin liittyvää suuruutta ketterässä ohjelmistokehittämisessä ja siitä johtuvia ja liittyviä havaintoja (Dikert ym., 2016; Dingøyr & Moe, 2013). Myöskään siitä, millä kriteerillä suuruutta tulisi mitata ei ole yhtenäistä sopimusta. Suuruutta voidaan mitata projektin esimerkiksi kustannusten, lähdekoodin rivien, tiimien lukumäärän, vaatimusmäärän tai ihmismäärän perusteella (Dingsøyr, Fægri & Itkonen, 2014). Dingsøyr, Fægri ja Itkonen (2014) artikkelissaan ovat pyrkineet esittämään luokittelun, jonka perusteella voitaisiin määritellä suuri mittakaava ketterissä projekteissa ja kriteerin, jonka perusteella määrittely tehdään. Kyseisessä raportissa ehdotetaan, että luokittelu tehtäisiin projektien tiimien määrän perusteella. Raportissa ehdotetaan, että pienen ja

12 suuren mittakaavan ero olisi se, että jos tiimejä on enemmän kuin yksi, sitä pidettäisiin suuren mittakaavan ketteränä projektina ja jos tiimien määrä on enemmän kuin kymmenen olisi se todella suuren mittakaavan projekti (Dingsøyr ym., 2014). Raportissa sitä perustellaan sen olevan helposti hahmotettavissa. Williams ja Cockburnin (2003) mukaan ketteryyden arvot ja toimet soveltuvat parhaiten alle 50 henkilön organisaatioihin. Samaa on myös todettu muualla ja luokiteltu alle 50 henkilön organisaatiot tai projektit pieniksi (Koehnemann & Coats, 2009). Asiasta on kuitenkin monia mielipiteitä. Dingsøyrin ja Moen (2014) mukaan XP2014 konferenssissa järjestetyn kyselyn perusteella sen käsitys siitä mitä on suuren mittakaavan ketterä kehittäminen (large-scale agile development) vaihteli. Yleisesti se määriteltiin kuitenkin jonain suurena koko organisaation tasoisena asiana ja se määriteltiin käsittävän yli 50 henkilöä, jotka tekevät projekteja käyttäen jotain ketterää menetelmää. Dikert, Paasivaara ja Lassenius (2016) ovat omassa aihealueeseen liittyvässä tutkimuksessaan määritelleet rajan suurelle analysoituaan aihealueen tutkimuksia. Kyseisessä tutkimuksessa määriteltiin suuren mittakaavan ketterä kehitys siten, että organisaatiossa tulee olla 50 henkilöä ja sen täytyy sisältää vähintään kuusi erillistä tiimiä. Näistä kaikkien jäsenten ei tarvitse olla mukana ohjelmistokehityksessä, mutta niiden tulee olla mukana kehitettävän tuotteen elinkaaressa. Näiden havaintojen perusteella voidaan määrittää, että suuruutta määritellään organisaation henkilömäärän perusteella. Karkeana rajana suuren mittakaavan ketteränä ohjelmistokehityksenä voidaan pitää yli 50 henkilöistä organisaatiota. Lisäkriteerinä voidaan pitää myös samaa kriteeriä kuin Dikert ym. (2016) tutkimuksessa eli organisaation tulee sisältää vähintään kuusi erillistä tiimiä, joiden tulee olla mukana kehitettävän tuotteen elinkaaressa. 3.2 Suureen ketterään ohjelmistokehittämiseen siirtyminen Vaikka ketterät menetelmät ovat kasvattaneet suosiotaan niihin siirtyminen ei ole yksinkertaista tai helppoa. Etenkin suurten organisaation muutokset ketteryyteen koetaan haastaviksi (Tessem & Maurer, 2007; Dikert ym., 2016; Boehm, 2006; Dybå & Dingsøyr, 2008.) Kuitenkin niiden hyvien tulosten ja tehokkuuden johdosta niistä ovat kiinnostuneet myös suuret organisaatiot (Dingsøyr, Moe, 2014). Ketteryys ja ketterät menetelmät on kehitetty pieniä tiimejä ja organisaatioita ajatellen (Boehm & Turner, 2005). Näin ollen ne eivät sovellu kovin hyvin suurempiin organisaatioihin (Campanelli & Parreiras, 2015). Ketterät menetelmät eivät yleisesti sellaisinaan sovellu suureen mittakaavaan, vaan niihin on tehtävä räätälöintiä ja niiden käyttöönottoon on käytettävä erityistä huomiota ketteryyden aikaansaamiseksi (Campanelli & Parreiras, 2015). Yleisesti ottaen muutokset suuremmissa organisaatioissa vaativat tarkempaa koordinointia ja

13 organisaation koon johdosta sen osat kuten esimerkiksi markkinointi ja myyntiosastot tuovat omat lisävaikeutensa muutokseen (Dikert ym, 2016). Koska ketteryys on nähtävä enemmänkin organisaation ajattelutavan kokonaisena muutoksena ja toimintatapojen muuttamisena, tärkeintä ei ole se, mitä menetelmiä käytetään, vaan että ketteryys omaksutaan organisaation kulttuurin tasolla (Misra ym., 2010). Ketteryydessä ja siihen siirtymisessä on myös otettava huomioon se, ettei se pelkästään vaikuta vain organisaation ohjelmistokehitykseen vaan, että se vaikuttaa myös muihin organisaation osiin (Dikert ym, 2016). Näin ollen organisaation eri osastot ja niiden mahdolliset toiminnot tulisi sovittaa ketteryyteen sopiviksi, jotta kaikki osa-alueet noudattaisivat iteratiivista toimintaperiaatetta (Nerur ym. 2005). Ketteryys vaikuttaa siis organisaation rakenteeseen ja sen kulttuuriin sekä myös sen hallintoon. Samoin se vaikuttaa ihmisiin, niin tiimityöskentelyssä kuin myös asiakkaan kanssakäymisen korostamisena (Dikert ym., 2016). Lisäksi prosessit muuttuvat ominaisuus- ja ihmiskeskeisiksi, joissa asioita tehdään lyhyin, iteratiivisin syklein (Nerur ym. 2005). Yleisesti ero pienen ja suuren organisaation välillä on organisaation monimutkaisempi rakenne ja sen vaativan enemmän koordinointia (Lindvall ym. 2004). Tämän lisäksi suurissa organisaatioissa saattaa olla osia, joissa ei toimita ketterästi ja siitä syystä se vaikuttaa organisaation sisäistä toimintaa (Boehm & Turner, 2005). Näin ollen suuren organisaation muutos on yleisesti hankalampaa kuin pienen organisaation.

14 4 HAASTEET SIIRRYTTÄESSÄ SUUREEN KETTE- RÄÄN OHJELMISTOKEHITTÄMISEEN Tässä luvussa käsitellään tämän kirjallisuuskatsauksen tutkimuskysymystä ja siihen löytyneitä vastauksia, eli mitä haasteita on raportoitu muutoksen aikana, kun suuri organisaatio muuttaa toimintaansa käyttämään ketteryyttä ja ketteriä menetelmiä. Ensimmäisessä alaluvussa on esitetty tässä tutkielmassa tehty systemaattisen tiedonhaun menetelmät ja asetetut kriteerit sekä esitetty hausta löytyneet havainnot. Toisessa alaluvussa on esitelty tutkimuksen tulokset ja käyty ne aiheittain tarkemmin läpi. Lopuksi kolmannessa luvussa löydettyjä havaintoja on verrattu aikaisempaan tehtyyn tutkimukseen ja niistä on pyritty löytämään yhtäläisyyksiä ja poikkeuksia. 4.1 Aineiston keräämisen metodit ja löydetyt havainnot Tässä tutkimuksessa valittiin, että asetettuun tutkimuskysymykseen pyrittiin löytämään vastaus käyttäen systemaattista tiedonhakumenetelmää. Tutkimusta tehdessä määriteltiin hakutavat ja kriteerit, joiden perusteella raportteja etsittiin. Raporttien etsimiseen käytettiin hakukonetta, johon syötettiin ennalta määritellyt hakusanat. Hakukoneena käytettiin Google Scholar -hakukonetta ja siihen syötettiin yhteensä 7 eri hakusanaa. Näistä löydöksistä otokseen valittiin hakutulosten löytämät artikkelit, jotka sijaitsivat kolmella ensimmäisellä sivulla. Hakusanoiksi pyrittiin asettamaan muutama mahdollisimman laajakäsitteinen termi ja muutama tarkempi termi sekä valitsemaan myös sanojen synonyymejä, jotta hakutuloksista saataisiin mahdollisimman kattavia ja relevantteja. Hakusanoiksi asetettiin seuraavat termit: agile problems in large organizations, agile scaling challenges, agile transformation, agile transformation challenges, challenges in large agile, large agile software development challenges ja large scale agile challenges. Näillä hakusanoilla raportteja löytyi yhteensä 198 kappaletta. Samojen raporttien karsimisen jälkeen raportteja jäi 80 kappaletta. Tämän jälkeen löydetyt

15 artikkelit luettiin manuaalisesti ja ennalta-asetettujen kriteerien perusteella raporteista valikoitiin ne raportit, jotka täyttivät määritellyt kriteerit. Kriteereinä jotta raportti otettiin mukaan käsittelyyn, tuli sen täyttää aiemmassa luvussa asetetut rajaehdot sille, mitä pidetään suurena ketteränä ohjelmistoprojektina. Raporteissa esitetyissä organisaatioissa tuli olla yli 50 työntekijää ja vähintään 6 erillistä tiimiä sekä toiminnan sisältää ohjelmistokehitystä. Muutamia poikkeuksia otettiin myös mukaan analyysiin, joissa ei tarkkaan kerrottu organisaation kokoa, mutta artikkelista pystyi päättelemään organisaation suuren koon. Tämän tehdyn rajauksen jälkeen otoksesta valikoitui 17 artikkelia, jotka täyttivät nämä asetetut kriteerit. Näiden löydösten perusteella tässä tutkielmassa on esitetty havainnot näissä artikkeleissa raportoiduista muutoksen haasteista liittyen suuren mittakaavan ketteryyteen. Löydetyt haasteet on esitetty taulukossa 1. Näistä raporteista löydettyjä haasteita ja niistä tehtyjä yhtäläisyyksiä käsitellään seuraavassa alaluvussa. Taulukko 1 Analyysiin valitut lähteet # Tyyppi Viittaus Koko Menetelmä Esitetyt haasteet 1 Tapaustutkimus Bjarnason ym. 5000 Scrum IM, P, VM (2011) hlö 2 Tutkimus Xu (2009) - Agile/Scrum VM 3 Haastattelututkimus Sekitoleko ym. +50 hlö Agile/XP IM, P, VM (2014) 4 Haastattelututkimus Paasivaara & Lassenius 170 hlö Scrum MV, IM (2011) / 20t 5 Haastattelututkimus Paasivaara ym. 20 t & Scrum MV, IM (2012) 25 t 6 Haastattelututkimus Paasivaara ym. 400 hlö Agile/Scrum MV, IM (2013) 7 Grounded theory Gandomani ym. +50 hlö Agile MV, IM (2014) 8 Kokemusraportti Fry & Greene - Agile/Scrum MV, IM, P (2007) 9 Kokemusraportti Lindvall ym. (2004) - XP SKO 10 Kokemusraportti Beavers (2007) 10 t Scrum MV 11 Kokemusraportti Benefield (2008) 150 t Scrum MV, IM, P 12 Kokemusraportti Goodman & Elbaz - Scrum P, SKO, VM (2008) 13 Kokemusraportti Lehto & Rautiainen 150 hlö Agile IM, P (2009) 14 Kokemusraportti Maples (2009) 300 t Scrum MV, IM, P, VM 15 Kokemusraportti Hui (2013) 200 Agile P 400 hlö 16 Kokemusraportti Greening (2010) 25 t Scrum IM, SKO, VM 17 Kokemusraportti Ktata & Lévesque (2009) - Scrum IM, VM MV = muutosvastaisuus, IM = implementointi, P = panostus, SKO = sisällyttäminen kaikkiin osiin, VM = vaatimusmäärittely, hlö = henkilöä, t = tiimiä

16 4.2 Haasteet siirryttäessä suureen ketterään ohjelmistokehittämiseen Tässä tutkielmassa tehdyn aineistonkeruun ja sen analysoinnin perusteella haasteet muuttaessa suureen ketterään ohjelmistokehitykseen voidaan jakaa seuraaviin kokonaisuuksiin: Muutosvastaisuus, ketteryyden käyttöönoton vaikeus, riittämätön panostus, ketteryyden sisällyttäminen kaikkiin organisaation osiin ja vaatimusmäärittely. Tämän lisäksi on listattuna myös muita huomionarvoisia seikkoja. Tässä luvussa lähdeviittaukset on numeroitu ja niillä viitataan taulukossa 1 esitettyihin artikkeleihin. Jokaisen artikkelin numero on esitetty taulukon 1 vasemmassa laidassa ja lähdeviittaus sijaitsee taulukon viittaus - otsakkeen alla kullakin rivillä. Löydöksiä käydään seuraavaksi läpi tarkemmin. Muutosvastaisuus. Tutkituissa artikkeleissa valtaosassa esiintyi yleistä muutosvastarintaa ja erityisesti muutosvastarintaa esiintyi johdon ja hallinnon osa-alueille. Niissä pelättiin muutoksen heikentävän henkilöiden valtaa ja näin ollen vähentävän näiden kontrollia organisaatiossa (7, 11, 16). Muutosta ei myöskään nähty tarpeellisena, eikä osattu nähdä ketteryyden tuomia hyötyjä vaan siihen suhtauduttiin epäillen (16, 7, 11). Muutosvastarintaa ei kuitenkaan pidetty organisaatioissa ylitsepääsemättömänä haasteena vaan luonnollisena osana muutosta (6, 7). Ketteryyden käyttöönoton vaikeus. Ketteryys koettiin erittäin haastavana integroida omaan organisaatioon ja suureen kokoon (6, 10). Ketterissä menetelmissä esiintyi skaalautuvuusongelmia ja niihin ei osattu varautua eikä tehdä oikeita toimia asian korjaamiseksi (10, 17). Ketteryyden ja siihen liittyvän ajatusmaailman sekä menetelmien ymmärtäminen oli haastavaa. Ei myöskään pitäydytty ketteryydessä vaan siirryttiin ainakin osittain käyttämään vanhoja menetelmiä ketterien menetelmien sijasta (6, 10.) Organisaation muutoksen suuruus ja sen tuoma muutoksen monimutkaisuus oli monesti syynä muutoksen heikkoon aikaansaantiin. Riittämätön panostus. Monessa löydetyssä artikkelissa mainittiin, ettei organisaatiossa otettu muutosta tarpeeksi vakavasti ja siihen ei ymmärretä käyttää riittävästi resursseja (6, 12, 10, 8). Näihin resursseihin ja ongelmakohtiin liittyy henkilöstön kouluttaminen uuteen toimintatapaan ja riittävä ohjaus muutoksessa. Kun koulutusta ja ohjausta ei ollut tarpeeksi se vaikeutti ja hidasti huomattavasti muutosprosessia (6, 7, 8, 11, 14, 15.) Haasteena nähtiin myös, että liian vähäisellä panostuksella oli vaikutusta myös yhteisen vision löytämiseen organisaatossa ja näin ollen se aiheutti motivaatio-ongelmia (6, 17). Ketteryyden sisällyttäminen kaikkiin organisaation osiin. Organisaation koon ollessa suuri, toi se haasteita organisaation muuttamiseen ketteryyteen etenkin muissa organisaation osissa kuin ohjelmistokehityksessä (9, 12, 16). Suurien organisaatioiden toimintojen ollessa monimutkaisia, ei ketteryys ole helppoa omaksua ja muuttaa kaikkiin osa-alueisiin (9). Ei myöskään nähty sitä, että muidenkin osa-alueiden tulisi muuttua käyttämään ketteriä menetelmiä (12,

17 16). Nämä muut osiot eivät aina myöskään olleet halukkaita muutokseen tai niiden oli erittäin haasteellista muuttaa toimintatapojaan ketteriksi (12). Vaatimusmäärittely. Ketteriin menetelmiin siirtymisen mukana tuleva jatkuva vaatimusten määrittely asettaa omat haasteensa organisaatiolle. Suuressa organisaatiossa se tuottaa haasteita etenkin kommunikaation ja monimutkaisuuden kanssa (1, 2, 14, 16, 17). Kommunikointi muuttuvissa organisaatioissa saattaa kärsiä ja siten vaikeuttaa vaatimustenmäärittelyä ja näin ollen samalla haitata työn laatua (1, 12). Monesti koettiin, että jo valmiiksi monimutkainen osa toimintaa monimutkaistuu entisestään ja se vaikuttaa työn laatuun ja vain sekoittaa vaatimusmäärittelyn tekemistä (1, 14). Muita huomionarvoisia seikkoja. Lähteistä raportoitiin myös muita haasteita, jotka liittyvät läheisesti jo edellä mainittuihin haasteisiin. Haasteita toi myös koordinointi, joka koettiin haasteelliseksi suurissa organisaatioissa. Koordinointia pidettiin haastavana siitä syystä, että muutoksen aikana oli vaikeaa organisaation muutoksen kokonaiskuvaa ja ei tiedetä missä järjestyksessä ja missä vaiheissa muutosta tulisi suorittaa (4, 6). Lisäksi kommunikaation tärkeys ja organisaation läpinäkyvyys muutoksessa ovat myös olennaisia haasteita. Koettiin, että yrityksessä ei kerrota tarpeeksi muutoksesta ja syistä muutokseen (1, 3, 4). Suurissa organisaatioissa monesti työtä tehdään globaalisti eri tiimeissä. Näin ollen maantieteellinen sijainti aiheuttaa sekin haasteita organisaation muutoksessa ketteryyteen. Näissä esimerkiksi kommunikaatio- ja koordinointihaasteet korostuvat entisestään sekä eri kulttuurit luovat omat haasteensa (2, 6, 9). 4.3 Vertaaminen aiempaan tutkimukseen Löydetyn aineiston lisäksi tässä tutkimuksessa löydettyjen haasteiden vertailukohdaksi on valittu Dikert ym. (2016) tekemä systemaattinen kirjallisuuskatsaus. Kyseinen tutkimus ei esiintynyt tehdyssä systemaattisessa tiedonhaussa, mutta se löytyi yleisessä haussa kirjoitelmaa tehdessä. Tämä tutkimus on laajan lähdeaineistonsa ja sopivuutensa vuoksi otettu mukaan tämän tutkielman käsittelyyn, jotta siinä löydettyjä havaintoja voitaisiin verrata tämän tutkimuksen löydöksiin. Kyseisen kirjallisuuskatsauksen tutkimuskysymyksistä toinen on yhtäläinen tämän kirjallisuuskatsauksen tutkimuskysymykseen. Tämän lisäksi mainitussa tutkimuksessa pyrittiin myös löytämään mahdollisia menestystekijöitä muutoksessa. Kyseisen tutkimuksen löytämiä haasteita voidaan siis tarkastella ja verrata tämän kirjallisuuskatsauksen löytämiin havaintoihin. Kyseisessä tutkimuksessa analysoitiin 1875 artikkelia, joiden perusteella pyrittiin löytämään raportoidut siirtymisen haasteet ja menestystekijät suuren mittakaavan ketteryyteen. Lopulliseksi määräksi muodostui 52 tutkimusta, joista 47 oli konferenssitoimenpiteitä, 4 aikakausilehtijulkaisuja ja yksi tekninen reportaasi. Kyseisessä tutkimuksessa on kerätty lähdeaineistoa käyttäen eri hakukoneita kuin tässä kirjallisuuskatsauksessa ja niissä on käytetty hieman eri-

18 laisia hakusanoja. Kyseisessä tutkimuksessa myös todettiin, että artikkeleita etsiessä yksi haaste oli hyvien hakusanojen määritteleminen ja mahdollisten synonyymien takia jotkin tutkimukset saattoivat jäädä sen tästä syystä löytämättä. Näin ollen on mahdollista, että tässä tutkielmassa tehdyllä haulla käyttäen eri hakukonetta ja erilaisia hakusanoja saattaa löydetyistä artikkeleista löytyä jotain uutta tietoa. Havainnot Dikert ym. (2016) tutkimuksessa pääosin yhtäläisiä tässä kirjallisuuskatsauksessa tehdyn analyysin havaintoihin. Yleisin ilmoitettu haaste oli ketteryyden vaikea käyttöönotto ja toiseksi yleisin haaste oli haasteet liittyen ketteryyden sisällyttämiseen organisaation kaikkiin osiin. Samoin myös muutosvastaisuus, panostuksen puute ja vaatimusmäärittely olivat kyseisessä tutkimuksessa yleisiä ilmoitettuja haasteita. Kuitenkin siinä esitettiin myös hieman erilaisia ja tarkempia huomioita esiintyneistä haasteista. Näitä asioita olivat huomiot fyysisten työtilojen muuttamiseen liittyvät haasteet, työnteon itsenäistymiseen liittyvät haasteet, sekä ohjelmistojen testaukseen liittyvät ongelmat projekteissa. Lisäksi tutkimuksen löydöksissä korostettiin, että haasteita organisaatioille toi se, ettei aihealueesta ole kirjallisuutta, jotka auttaisivat esimerkiksi ketterien menetelmien skaalauksesta. Toinen korostettu haaste oli muiden organisaation toimintojen vastustus muutokseen. Kyseisestä tutkimuksesta löytyi muutamia poikkeuksia verrattuna tässä tutkielmassa esitettyihin havaintoihin. Kyseisessä tutkimuksessa kommunikaatioon ja läpinäkyvyyteen liittyviä seikkoja ei esitetty haasteina vaan muutoksen menestystekijöinä. Menestystekijät ja haasteet ovat kuitenkin lähellä toisiaan, joten varsinaisesta poikkeavuudesta ei kuitenkaan ole kyse. Näin ollen näitä tekijöitä voidaan yhtä lailla pitää niin menestystekijöinä kuin myös haasteina.

19 5 YHTEENVETO JA POHDINTA Tässä kirjallisuuskatsauksessa tutkittiin mitä haasteita saattaa liittyä siihen, kun suuri organisaatio on muuttamassa ohjelmistokehitystään ketteräksi ohjelmistokehitykseksi. Tutkimuksessa myös pyrittiin määrittelemään, millä kriteereillä suuruutta määritellään. Tutkielman tutkimuskysymykseksi oli asetettu, että mitä haasteita on raportoitu organisaation muuttuessa suuren mittakaavan ketterään ohjelmistokehittämiseen. Tutkimusmenetelmänä käytettiin kirjallisuuskatsausta ja tutkimuksen tutkimuskysymykseen vastaaminen suoritettiin noudattaen systemaattista lähteiden keräämistä ja analysointia. Tutkimuksen lähdeaineisto koostuu pääosin alan tieteellisistä artikkeleista ja muutamista kokemusraporteista. Tutkimuksen keskeiset tulokset voidaan jakaa viiteen eri haasteiden asiakokonaisuuteen. Nämä kokonaisuudet ovat muutosvastaisuus, ketteryyden käyttöönoton vaikeus, riittämätön panostus, ketteryyden sisällyttäminen kaikkiin organisaation osiin ja vaatimusmäärittely. Muutosvastaisuuteen liittyvissä haasteissa muutosvastaisuutta koettiin etenkin johdon ja hallinnon osa-alueilla, sillä pelättiin muutoksen vähentävän näiden valtaa ja kontrollia. Ketteryyden käyttöönottoon liittyviä haasteita oli ketterien menetelmien skaalausongelmat, vanhoihin tapoihin palattiin takaisin ja ettei ketteryyttä ymmärretty oikein. Panostuksen riittämättömyyteen liittyviä haasteita oli, ettei ymmärretty käyttää resursseja riittävästi esimerkiksi koulutukseen, ohjaukseen ja yhteiseen vision luomiseen. Ketteryyden sisällyttäminen muihin organisaation osiin koettiin myös haasteelliseksi. Haasteita tähän toi se, ettei ketteryyttä osattu soveltaa myös organisaation muuhun toimintaa tai sitä ei ylipäätään ymmärretty laajentaa myös näihin organisaation osiin. Viimeisenä kohtana on vaatimusmäärittelyyn liittyvät haasteet, jotka organisaation koon kasvaessa ja ketteryyteen muututtaessa koki haasteita sen tullessa monimutkaisemmaksi ja vaativammaksi kuin ennen. Tämän lisäksi tutkimuksessa löydettiin muita huomionarvoisia seikkoja, jotka liittyvät läheisesti myös yllämainittuihin osioihin. Näitä olivat kommunikaatioon liittyvät haasteet, muutoksen läpinäkyvyyden korostuminen, eri maantieteellisten sijaintien tuomat haasteet ja kirjallisuuden puuttuminen aihe-

20 alueesta. Löydetyistä havainnoista on kuitenkin huomattava, että montaa esitettyä muutoksen haastetta esiintyy koosta huolimatta. On silloin siis pohdittava, mitkä näistä muutoksen haasteista mahdollisesti ovat juuri koosta johtuvia haasteita. Seuraavaksi on pyritty esittämään ne haasteet, jotka mahdollisesti ovat koosta johtuvia haasteita. Ensimmäisenä on muutosvastaisuus, jota esiintyy väistämättä muutoksessa. Kuitenkin muutosvastaisuus saattaa olla korostunutta suuremmissa organisaatioissa johdon ja hallinnon osalta, sillä yleisesti ottaen byrokratiaa on enemmän. Johdon saattaa olla vaikeaa nähdä ketteryyden tuomia hyötyjä ja sitä voidaan pitää liian haastavana muutoksena. Voidaan myös pelätä, että se saattaa heikentää johdon asemaa. Toinen koosta riippuva haaste on ketterien menetelmien skaalaushaasteet ja aihealueen heikko kirjallisuus. Koska menetelmiin ei ole toistaiseksi kehitetty riittävästi ohjeita siihen, miten niitä tulisi skaalata ja kirjallisuutta on niukalti aihealueesta, saattaa tämä aiheuttaa haasteita. Kolmantena haasteena on ketteryyden sisällyttäminen muihin osiin kuin ohjelmistokehitykseen. Jos koko organisaatio halutaan ketteräksi, tuo silloin haasteita ne organisaation osat, joissa ei jostain syystä pystytä ketteryyteen. Oletettavasti suuresta koosta johtuen, näitä osioita on enemmän ja ne voivat olla toiminnaltaan monimutkaisempia ja haasteet kasvavat. Neljäntenä on vaatimusmäärittely, joka etenkin projektien kasvaessa muuttuu haastavammaksi. Silloin nykyisillä menetelmillä saattaa olla hankalaa seurata kaikkia projektin vaatimuksia. Lisäksi oletettavasti projektien kasvaessa tiimien ja asianomistajien väliset vaatimusmäärittelyt saattavat heikentyä ja monimutkaistua. Viidentenä voidaan pitää kommunikaatio- ja läpinäkyvyyshaasteita, jotka saattavat korostua organisaation ja projektien kasvaessa. Suuresta koosta johtuen on tärkeää kommunikoida muutoksesta ja suuressa organisaatiossa haasteena on, että kommunikaatiota on riittävästi ja se on tarpeeksi informatiivista, jotta se on läpinäkyvää. Tämä asia saattaa korostua suuressa organisaatiossa enemmän kuin pienessä. Kuudentena voidaan pitää koordinointihaasteita, joiden merkitys oletettavasti kasvaa suurissa organisaatioissa ja projekteissa. Suurten organisaatioiden ja projektien rakenteet ovat monimutkaisemmat ja näin ollen on oletettavaa, että ne tuovat lisähaasteita muutokseen. Aihealue tarvitsee kuitenkin vielä jatkotutkimusta, jotta sen haasteista voidaan olla varmoja. Jatkotutkimusaiheina on yleisesti tapaustutkimukset aihealueeseen liittyen, sillä aihealueesta on erittäin niukasti tutkimusta. Tutkimusta tarvitaan erityisesti myös siitä, millä tavoin ketteriä menetelmiä voidaan skaalata ja mitä eri viitekehyksiä niihin on kehitetty ja miten ne soveltuvat käyttöön. Lisäksi tutkimusta tulisi tehdä myös siitä, mitä haasteita suurissa projekteissa ja organisaatioissa silloin on, kun ne ovat jo muuttaneet toimintansa ketteriksi ja harjoittavat niitä toiminnassaan. Lisäksi suuri ketterä ohjelmistokehitys hajautetuissa organisaatioissa ja projekteissa kaipaa lisää tutkimusta.

21 LÄHTEET Basili, V. R., & Turner, A. J. (1975). Iterative enhancement: A practical technique for software development. IEEE Transactions on Software Engineering, SE- 1(4), 390-396. Beavers, P. A. (2007). Managing a Large "Agile" Software Engineering Organization. Teoksessa Agile Conference (AGILE), 2007 (s. 296-303). IEEE. Beck, K. (1999). Embracing change with extreme programming. Computer, 32(10), 70-77. Benefield, G. (2008). Rolling out agile in a large enterprise. Teoksessa Hawaii International Conference on System Sciences, Proceedings of the 41st Annual (s. 461-461). IEEE. Bjarnason, E., Wnuk, K., & Regnell, B. (2011). A case study on benefits and sideeffects of agile practices in large-scale requirements engineering. Teoksessa Proceedings of the 1st Workshop on Agile Requirements Engineering (s. 3). ACM. Boehm, B. (2002). Get ready for agile methods, with care. Computer, 35(1), 64-69. Boehm, B. (2006). Some future trends and implications for systems and software engineering processes. Systems Engineering, 9(1), 1-19. Boehm, B., & Turner, R. (2005). Management challenges to implementing agile processes in traditional development organizations. IEEE Software, 22(5), 30-39. Campanelli, A. S., & Parreiras, F. S. (2015). Agile methods tailoring A systematic literature review. The Journal of Systems and Software, (110), 85-100. Chandra Misra, S., Kumar, V., & Kumar, U. (2010). Identifying some critical changes required in adopting agile practices in traditional software development projects. International Journal of Quality & Reliability Management, 27(4), 451-474. Dingsøyr, T., Fægri, T. E., & Itkonen, J. (2014). What is large in large-scale? A taxonomy of scale for agile software development. Teoksessa Jedlitschka, A., Kuvaja, P., Kuhrmann, M., Männistö, T., Münch J. & Raatikainen, M. (toim.), International Conference on Product-Focused Software Process Improvement (s. 273-276). Springer International Publishing. Dingsøyr, T., & Moe, N. B. (2013). Research challenges in large-scale agile software development. ACM SIGSOFT Software Engineering Notes, 38(5), 38-39. Dingsøyr, T., & Moe, N. B. (2014). Towards principles of large-scale agile development. Teoksessa Dingsøyr, T., Moe, N., Tonelli, R., Counsell, S., Gencel, C., Petersen, K. (toim.), International Conference on Agile Software Development (s. 1-8). Springer International Publishing.

22 Dingsøyr, T., Sridhar, S., Balijepally, V. G., & Moe, N. B. (2012). A decade of agile methodologies: Towards explaining agile software development. The Journal of Systems & Software, 85(6), 1213-1221. Dybå, T. (2000). Improvisation in small software organizations. IEEE Software, 17(5), 82-87. Dybå, T., & Dingsøyr, T. (2008). Empirical studies of agile software development: A systematic review. Information and Software Technology, 50(9), 833-859. Fernandes, J. M., & Almeida, M. (2010). Classification and comparison of agile methods. Quality of Information and Communications Technology. 391-396. Fowler, M., & Highsmith, J. (2001). The agile manifesto. Software Development, 9(8), 28-35. Freudenberg, S., & Sharp, H. (2010). The top 10 burning research questions from practitioners. IEEE Software, 27(5), 8-9. Fry, C., & Greene, S. (2007). Large Scale Agile Transformation in an On- Demand World. Teoksessa Agile Conference (AGILE), 2007 (s. 136-142). IEEE. Gandomani, T. J., Zulzalil, H., Ghani, A. A., Sultan, A. B. M., & Sharif, K. Y. (2014). How human aspects impress Agile software development transition and adoption. International Journal of Software Engineering and Its Applications, 8(1), 129-148. Goodman, D., & Elbaz, M. (2008). "It's Not the Pants, it's the People in the Pants" Learnings from the Gap Agile Transformation What Worked, How We Did it, and What Still Puzzles Us. Teoksessa Agile, 2008. AGILE'08. Conference (s. 112-115). IEEE. Greening, D. R. (2010). Enterprise Scrum: Scaling Scrum to the executive level. Teoksessa System Sciences (HICSS), 2010 43rd Hawaii International Conference (s. 1-10). IEEE. Hamed, A. M. M., & Abushama, H. (2013). Popular agile approaches in software development: Review and analysis. Teoksessa Computing, Electrical and Electronics Engineering (ICCEEE), 2013 International Conference (s. 160-166). IEEE. Hui, A. (2013). Lean change: Enabling agile transformation through lean startup, kotter and kanban: An experience report. Teoksessa Agile Conference (AGILE), 2013 (s. 169-174). IEEE. Kettunen, P., & Laanti, M. (2008). Combining agile software projects and largescale organizational agility. Software Process: Improvement and Practice, 13(2), 183-193. Kim Dikert, Maria Paasivaara, & Casper Lassenius. (2016). Challenges and success factors for large-scale agile transformations: A systematic literature review. The Journal of Systems and Software, 119, 87-108. Koehnemann, H., & Coats, M. (2009). Experiences applying agile practices to large systems. Teoksessa Agile Conference, 2009. AGILE'09 (s. 295-300). IEEE. Ktata, O., & Lévesque, G. (2009). Agile development: Issues and avenues requiring a substantial enhancement of the business perspective in large

23 projects. Teoksessa Proceedings of the 2nd Canadian conference on computer science and software engineering (s. 59-66). ACM. Laurie Williams, & Alistair Cockburn. (2003). Agile software development: It's about feedback and change. Computer 36 (6), 39-43. Lehto, I., & Rautiainen, K. (2009). Software development governance challenges of a middle-sized company in agile transition. Teoksessa Proceedings of the 2009 ICSE Workshop on Software Development Governance (s. 36-39). IEEE Computer Society. Lindvall, M., Muthig, D., Dagnino, A., Wallin, C., Stupperich, M., Kiefer, D.,... & Kahkonen, T. (2004). Agile software development in large organizations. Computer, 37(12), 26-34. Maples, C. (2009). Enterprise agile transformation: The two-year wall. Teoksessa Agile Conference, 2009. AGILE'09 (s. 90-95). IEEE. Nerur, S., Mahapatra, R., & Mangalaraj, G. (2005). Challenges of migrating to agile methodologies. Communications of the ACM, 48(5), 72-78. Olszewska (née Pląska), M., Heidenberg, J., Weijola, M., Mikkonen, K., & Porres, I. (2016). Quantitatively measuring a large-scale agile transformation. The Journal of Systems & Software, 117, 258-273. Paasivaara, M., Behm, B., Lassenius, C., & Hallikainen, M. (2014). Towards rapid releases in large-scale xaas development at ericsson: A case study. Teoksessa 2014 IEEE 9th International Conference on Global Software Engineering (s. 16-25). IEEE. Paasivaara, M., & Lassenius, C. (2011). Scaling scrum in a large distributed project. Teoksessa 2011 International Symposium on Empirical Software Engineering and Measurement (s. 363-367). IEEE. Paasivaara, M., Lassenius, C., & Heikkilä, V. T. (2012). Inter-team coordination in large-scale globally distributed scrum: Do Scrum-of-Scrums really work?. Teoksessa Proceedings of the 2012 ACM-IEEE International Symposium on Empirical Software Engineering and Measurement (s. 235-238). IEEE. Paasivaara, M., Lassenius, C., Heikkilä, V. T., Dikert, K., & Engblom, C. (2013). Integrating global sites into the lean and agile transformation at Ericsson. Teoksessa 2013 IEEE 8th International Conference on Global Software Engineering (s. 134-143). IEEE. Sekitoleko, N., Evbota, F., Knauss, E., Sandberg, A., Chaudron, M., & Olsson, H. H. (2014). Technical dependency challenges in large-scale agile software development. Teoksessa International Conference on Agile Software Development (s. 46-61). Springer International Publishing. Tessem, B., & Maurer, F. (2007, June). Job satisfaction and motivation in a large agile team. Teoksessa Concas G., Damiani E., Scotto M., Succi G. (toim.), International Conference on Extreme Programming and Agile Processes in Software Engineering (s. 54-61). Springer Berlin Heidelberg. VersionOne (2016). The 10th annual State of Agile survey. Haettu 18.1.2017 osoitteesta http://stateofagile.versionone.com/ Xu, P. (2009). Coordination in large agile projects. The Review of Business Information Systems, 13(4), 29.