MS ritgerð

Verkefnastjórnun

Uppskalað Agile í íslenskri hugbúnaðarþróun

„... og enginn er ómissandi, og það er bjútíið“

Sara Sturludóttir

Leiðbeinandi

Magnús Þór Torfason

Júní 2019

Uppskalað Agile í íslenskri hugbúnaðarþróun

„... og enginn er ómissandi, og það er bjútíið“

Sara Sturludóttir

Lokaverkefni til MS-gráðu í Verkefnastjórnun

Leiðbeinandi: Magnús Þór Torfason

Viðskiptafræðideild

Félagsvísindasvið Háskóla Íslands

Júní 2019

Uppskalað Agile í íslenskri hugbúnaðarþróun

„... og enginn er ómissandi, og það er bjútíið“

Ritgerð þessi er 30 eininga lokaverkefni til MS prófs við Viðskiptafræðideild, Félagsvísindasvið Háskóla Íslands.

© 2019 Sara Sturludóttir

Ritgerðina má ekki afrita nema með leyfi höfundar.

Prentun: Háskólaprent

Reykjavík, 2019

Formáli

Ritgerð þessi er meistaraprófsverkefni í verkefnastjórnun við Viðskiptafræðideild

Háskóla Íslands. Vinnsla ritgerðarinnar fór af stað haustið 2018 og telst hún til 30 (ECST)

eininga. Bestu þakkir kann ég leiðbeinanda mínum, Magnúsi Þór Torfasyni, fyrir

einstaklega góða leiðsögn og hvatningu við vinnslu verkefnisins. Ásamt honum vil ég

þakka öllum viðmælendum mínum og fyrirtækjum þeirra fyrir jákvætt viðhorf til

þátttöku og greiðan aðgang að upplýsingum. Einnig eiga sérstakar þakkir skyldar, móðir

mín, mágkona og vinkonur fyrir ómetanlegan stuðning og ekki síst fær Sölvi bróðir

þakkir fyrir aðstoð og ráðleggingar. Fyrir skilning og sveigjanleika vil ég þakka

samstarfsmönnum mínum og vinnuveitendum hjá Iceland Pelagic ehf. Að lokum vil ég

þakka mínum dásamlegu börnum, Aroni, Jennýju og Hrefnu fyrir að hafa sýnt einstaka

þolinmæði og staðið við bakið á mér í gegnum allt ferlið.

Útdráttur

Agile aðferðafræðin hefur verið mikið notuð í hugbúnaðarþróun í gegnum árin en hún

var upphaflega hugsuð fyrir lítil fyrirtæki sem starfa með eitt Agile teymi. Farið er að

nota aðferðafræðina í auknum mæli á stærri skala og því fylgir að aðlaga þarf aðferðina,

sem hentar vel fyrir eitt teymi, svo að hún henti fyrir mörg teymi. Við slíka uppskölun

virðist vera áskorun að halda í grundvallarkenningar Agile aðferðafræðinnar. Markmið

rannsóknarinnar var að skoða aðferðir uppskalaðs Agile hjá íslenskum

hugbúnaðarfyrirtækjum til þess að bæta við þekkingu á því sviði og fá yfirsýn yfir þá

upplifun og reynslu sem hugbúnaðarfyrirtæki og starfsmenn þeirra hafa af uppsköluðu

Agile. Framkvæmd var eigindleg rannsókn þar sem skoðuð voru fimm fyrirtæki og rætt

við 13 einstaklinga sem starfa hjá þeim.

Helstu niðurstöður rannsóknarinnar sýna að það reynir á að viðhalda góðri samvinnu

við viðskiptavini og endanotendur þegar Agile er skalað upp og teymum fjölgar. Þetta

hefur sýnt sig vera erfitt og oft vilja samskiptaleiðir lengjast í ferlinu. Þarna getur Agile

farið að snúast upp í andhverfu sína og verða að Waterfall ferli þar sem kröfur verkefna

koma tilbúnar inn til þróunar. Ekki er þó hægt að alhæfa um þessar niðurstöður og

frekari rannsókna er þörf á þessu efni.

Ekki er komin mikil reynsla á uppskölun Agile aðferða hér á landi og hafa fyrirtæki

verið að prófa sig áfram á þessu sviði. Uppskölun Agile gerist í mörgum tilfellum

meðfram uppvexti fyrirtækja og getur hraður vöxtur, og þar með hröð innleiðing

uppskalaðs Agile, haft þau áhrif að óvissa eykst. Við slíka uppskölun á Agile aðferðum

fara fyrirtæki að finna hjá sér þörf á að festa ferla, sem leiða má líkum að sé vegna þess

að þróun uppskalaðs Agile meðfram vextinum sé orðin of stefnulaus og vandamál tengd

vinnulagi og samskiptum leysast ekki nægilega hratt til að ná að viðhalda rekstri á

meðan

Ljóst er að það þykir árangursríkt að vera með ákveðna festu í hröðu uppskölunarferli

Agile aðferða en eftir því sem á líður og meiri þroski og reynsla kemst á starfið hefur það

sýnt sig skila árangri að losa um festuna og valdefla teymi. Slíkur ferill uppskalaðs Agile

hefur gefið góða raun og leitt til þess að auðveldara er að finna jafnvægi milli stjórnunar

og sjálfsstjórnunar teyma. Því fylgir aukin samvinna og sjálfsprottin samskipti sem ýta

undir starfsánægju og nýsköpun en stöðug nýsköpun er talin grundvöllur

samkeppnishæfis fyrirtækja í hugbúnaðarþróun á þeirri tækniöld sem nú er uppi.

Abstract

Agile methodology has been widely used in software development throughout the

years, originally designed for small companies operating a single Agile team. The

methodology is increasingly being used on a larger scale which means it needs to be

adapted to suit not only one team, but many. It seems to become a challenge to uphold

the basic Agile theories during this kind of scaling. The main goal of the research was to

observe the use of Agile at Scale methods in Icelandic software development as to

enhance knowledge in this field. Also, to gain insight into Agile at Scale based on the

experience of software development companies and their employees. Qualitative study

was designed where 13 employees of five companies, that participated, were

interviewed.

Main findings show that when scaling Agile and increasing the number of teams,

collaboration with customers and end users gets more difficult and ways of

communication tend to become complex. Agile methods can go astray and develop into

a Waterfall procedure, where project tasks arrive fully formulated into the development

phase. These findings cannot be generalized, and further research is needed to support

this. Experience of using Agile at Scale methods is still scarce and companies have been

adapting and evolving the method for their own use. The scaling of Agile happens in

many occasions alongside companies´ swift growth periods and rapid implementation

of Agile at Scale can result in increased uncertainty. This kind of implementation seems

to enhance the need to lean on fixed procedures. Lack of direction in the adaptation of

Agile at Scale can be the cause where problems related to work procedures and

communications are not being resolved quickly enough for the company to remain

operational.

It is evident that having some structure during rapid implementation of Agile at Scale

is successful but as the company gains more experience and maturity in its methods, it

has been shown to be successful to give more flexibility in the procedures and empower

the teams. Implementing Agile at Scale this way has worked well and supported the

right balance of control and self management of teams. Finding this balance can

increase cooperation and informal communication which leads to increased work

satisfaction and innovation. In this age of technology continuous innovation is

considered to be the foundation for sustainable competitive advantage in software

development.

7

Efnisyfirlit

Myndaskrá ............................................................................................................................. 9

Töfluskrá ................................................................................................................................ 9

1 Inngangur ...................................................................................................................... 10

2 Agile og Lean ................................................................................................................. 12

3 Uppskalað Agile ............................................................................................................. 15

3.1 Aðferðir uppskalaðs Agile ...................................................................................... 17

3.1.1 SAFe ................................................................................................................ 18

3.1.2 SoS .................................................................................................................. 19

3.1.3 LeSS................................................................................................................. 20

3.1.4 DAD ................................................................................................................. 20

3.1.5 Spotify Tribe ................................................................................................... 21

3.2 Fyrirtækjamenning og hlutverk stjórnenda ........................................................... 23

3.3 Rannsóknir á uppsköluðu Agile ............................................................................. 25

3.3.1 Áskoranir og árangursþættir .......................................................................... 27

3.3.2 Kostir við að nota uppskalað Agile ................................................................. 31

4 Aðferðir og gagnsöfnun ................................................................................................ 33

4.1 Rannsóknaraðferð ................................................................................................. 33

4.2 Takmarkanir ........................................................................................................... 36

4.3 Greining og meðferð gagna ................................................................................... 37

4.4 Réttmæti og áhættumat rannsóknar .................................................................... 38

5 Niðurstöður ................................................................................................................... 39

5.1 Uppsetning hjá stórum íslenskum hugbúnaðardeildum ....................................... 39

5.1.1 Aðferðir uppskalaðs Agile .............................................................................. 41

5.2 Innleiðingarferli ..................................................................................................... 43

5.2.1 Tilraunaaðferð og breytingar ......................................................................... 45

5.2.2 Ábyrgðir og hlutverk ....................................................................................... 46

5.3 Heildaryfirsýn ......................................................................................................... 48

5.3.1 Fastmótað ferli ............................................................................................... 49

5.3.2 Flóknar kröfur ................................................................................................. 53

5.3.3 Fjarlægð frá viðskiptavini ............................................................................... 55

5.3.4 Mælingar og áætlanir ..................................................................................... 56

5.4 Skipulag samskipta ................................................................................................ 60

8

5.4.1 Vinnurými ....................................................................................................... 62

5.5 Hlutverk Fyrirtækjamenningar í uppsköluðu Agile ................................................ 65

5.5.1 Dreifð teymi .................................................................................................... 70

5.6 Aðrar áskoranir og árangursþættir ........................................................................ 71

5.6.1 Áskoranir ........................................................................................................ 72

5.6.2 Árangursþættir ............................................................................................... 73

6 Umræður ....................................................................................................................... 77

6.1 Aðferðir uppskalaðs Agile í íslenskri hugbúnaðarþróun ....................................... 77

6.2 Ávinningar, árangursþættir og áskoranir .............................................................. 78

6.3 Markviss innleiðing Agile aðferðafræðinnar ......................................................... 84

7 Lokaorð ......................................................................................................................... 86

Heimildaskrá ........................................................................................................................ 87

Viðauki 1 .............................................................................................................................. 92

9

Myndaskrá

Mynd 1 LeSS aðferðin (The LeSS Company B.V. 2014-2019). .................................................. 20

Mynd 2 Uppsetning Spotify Tribe líkansins (Kniberg, 2014) .................................................... 22

Töfluskrá

Tafla 1 Meginmunur á hefðbundinni verkefnastjórnun og Agile verkefnastjórnun (Dybå og

Dingsøyr, 2008). .................................................................................................................. 12

Tafla 2 Dulnefni viðmælenda ásamt hlutverkum þeirra innan fyrirtækisins ........................... 34

Tafla 3 Munur á fyritækjum og Agile aðferðum þeirra ............................................................ 40

Tafla 4 Helstu áskoranir sem fyrirtækin takast á við með notkun á uppsköluðu Agile ........... 72

Tafla 5 Helstu árangursþættir í aðferðum uppskalaðs Agile sem viðmælendur nefna ........... 74

10

1 Inngangur

Með síauknum hraða samfélagsins er vaxandi krafa um aukna þjónustu og betri vörur fyrir

minni kostnað og á skemmri tíma. Þessari kröfu þurfa íslensk fyrirtæki að mæta eins og

erlend fyrirtæki. Við sívaxandi opnun heimsmarkaðar gegnum internetið hafa myndast nýir

markaðir og samkeppnisaðilum margra íslenskra fyrirtækja hefur fjölgað gífurlega. Til að

viðhalda áframhaldandi rekstargrundvelli og skila hagnaði í þessum aðstæðum þurfa

fyrirtæki að huga að stöðugri nýsköpun en einnig því að minnka sóun innan veggja

fyrirtækisins. Fyrirtæki þurfa því að bjóða vörur og þjónustu sem skila sem mestu virði til

viðskiptavina, samhliða því að lágmarka kostnað og stytta framleiðslutíma.

Agile verkefnastjórnunaraðferðin og Lean hugmyndafræðin hafa verið taldar auka virði

viðskiptavina með því að eyða óvissu á sem skemmstum tíma, með sem minnstum

tilkostnaði ásamt því að lágmarka sóun (Hines, Holwe og Rich, 2004). Samkvæmt rannsókn

Serrador og Pinto (2015) hefur Agile aðferðafræðin markvisst jákvæð áhrif á árangur flestra

verkefna með tilliti til skilvirkni og ánægju viðskiptavina og annarra haghafa.

Um allan heim eru stórfyrirtæki í hugbúnaðarframleiðslu farin að innleiða Agile aðferðir

ekki bara í lítil verkefni hjá sér heldur líka í stór verkefni sem framkvæmd eru af mörgum

teymum, eða uppskalað Agile (e. Agile at Scale). Þetta hefur kallað á nýjar aðferðir við að

vinna með Agile hugmyndafræðina og eins og með allar nýjar aðferðir og ný ókönnuð svæði

fylgja margir óvissuþættir og margar áskoranir. Íslensk hugbúnaðarfyrirtæki hafa líka verið

að vaxa með aukinni þróun og opnun markaða og hafa því líka þurft að stækka og skala upp

notkun á Agile aðferðum. Íslensk fyrirtæki eru þó fæst talin stór á alþjóðlegum mælikvarða

og í þessari rannsókn falla þau fyrirtæki sem voru skoðuð ekki undir skilgreiningu uppskalaðs

Agile eins og það hefur skilgreint samkvæmt fræðunum (Dikert o.fl., 2016). Fimm stórar

hugbúnaðardeildir íslenskra fyritækja voru skoðaðar í rannsókninni og virðast þær vera að

takast á við sömu áskoranir og upplifa svipaða hluti og fræðigreinar hafa sýnt fram á í

uppsköluðu Agile erlendis og verður því fallað um þeirra starfsemi sem uppskalað Agile.

Þrátt fyrir að það vanti upp á fræðigreinar sem styðja við notkun uppskalaðs Agile og

óljóst sé hvernig endaniðurstaða innleiðingar þess á að líta út hafa fyrirtæki í

hugbúnaðarþróun í auknum mæli tekið upp aðferðina. Árlega hefur verið gefin út skýrsla

sem nefnist State of Agile þar sem, eins og nafnið gefur til kynna, er farið yfir stöðu Agile hjá

fyrirtækjum víðs vegar í heiminum með því að leggja fyrir þau ákveðna könnun. Tólfta og

11

nýjasta útgáfa skýrslunnar (VersionOne Inc., 2018) sýndi niðurstöður rannsóknar þar sem

þátttakendur voru yfir 1.400 fyrirtæki og 60% þeirra með þúsund starfsmenn eða fleiri. Þar

kemur fram að 25% þátttakenda segja að öll teymi í þeirra fyrirtæki eða næstum öll, séu

Agile teymi. Það er aukning frá árinu 2017 en þá voru eingöngu 8% þátttakenda sem sögðu

öll sín teymi vera Agile.

Rannsakandi kynntist aðferðum Agile hugmyndafræðinnar í gegnum nám sitt í

Verkefnastjórnun og fékk áhuga á að rannsaka það nánar og skoða hvað væri að gerast í

Agile umhverfinu. Rannsakandi hefur ekki unnið með Agile aðferðafræðina í sínum störfum

og hefur því engra sérstakra hagsmuna að gæta í tengslum við hana. Með þessari rannsókn

er ætlað að bæta í upplýsingar um aðferðir uppskalaðs Agile, um áskoranir og árangursþætti

þess, með því að skoða stór íslensk hugbúnaðarfyrirtæki sem eru Agile á stórum skala.

Markmið rannsóknarinnar snýr að því að öðlast ákveðna yfirsýn yfir umhverfi uppskalaðs

Agile á Íslandi og leitast við að auka þannig þekkingu á því sviði.

Settar eru fram eftirfarandi rannsóknarspurningar:

R1) Nýta stöndug íslensk hugbúnaðarfyrirtæki sér hugmynda- og aðferðafræði Agile í

stærri verkefnum sem eru unnin af mörgum teymum þvert á deildir, eða svokallað

uppskalað Agile, og þá að hversu miklu leyti?

R2) Hvaða ávinning sjá þau við notkun á uppsköluðu Agile, hvaða þættir í því starfi hafa

stuðlað að árangri og hverjar eru helstu áskoranirnar sem þau hafa þurft að takast á

við?

R3) Hafa fyrirtæki markvisst innleitt Agile hugmynda- og aðferðafræði í fyrirtækið sem

heild?

12

2 Agile og Lean

Íslensk fyrirtæki, stór og smá, hafa í gegnum árin mörg hver innleitt Lean hugmyndafræðina í

starfsemi sína. Í rannsókninni er ætlunin að kanna hvort Agile aðferðir séu nú, eins og Lean

aðferðir, í vaxandi mæli að verða hluti af aðferðafræði stórra og stöndugra fyrirtækja en ekki

bara lítilla sprotafyrirtækja. Lean er eldri en Agile aðferðin en þessar aðferðir hafa marga

mjög svipaða eiginleika, en meginmarkmið Lean er að minnka sóun á vinnu við framleiðslu

og í starfsemi fyrirtækja (Arthur, 2007). Lean hugmyndafræðin hefur einnig verið skilgreind

sem stjórnunarleg aðferðafræði sem fyrirtæki vinna eftir til að auka ánægju og virði

viðskiptavina og minnka það sem ekki eykur virði fyrir þá (Hines o.fl., 2004). Til þess að ná

þessu fram þarf að eyða sóun og óvissu úr heildarferlinu en ekki bara afmörkuðum

framleiðsluferlum (Eðvald Möller og Snorri Fannar Guðlaugsson, 2013).

Agile er aðferðafræði verkefnastjórnunar sem byggir á Agile manifesto frá 2001 (Beck

o.fl., 2001) en þar er áhersla lögð á sífellda hönnun, sveiganlegt umfang og það að ákveða

lokaafurð eins seint og mögulegt er. Að eyða óvissuþáttum er mikilvægt og eins það að vera

í miklum samskiptum við endanotendur í gegnum allt ferlið. Forðast er það sem almennar

verkefnastjórnunaraðferðir byggja á, eins og til dæmis Waterfall aðferðin, að festa umfang

og sérstakar forskriftir í upphafi verkefnis (Serrador og Pinto, 2015). Meginmun á þáttum

Agile aðferðafræðinnar og hefðbundinna verkefnastjórnunaraðferða má sjá í töflu 1 (Dybå

og Dingsøyr, 2008).

Tafla 1 Meginmunur á hefðbundinni verkefnastjórnun og Agile verkefnastjórnun (Dybå og Dingsøyr, 2008).

13

Tvær algengustu aðferðirnar innan Agile eru Extreme Programming (XP) og Scrum

(Hamed og Abushama, 2013). Scrum aðferðin einblínir á verkefnastýringarþátt Agile

aðferðafræðinnar (Schwaber og Beedle, 2002), en hún mælir með tímastjórnun, samfelldri

eftirfylgni á árangri og að notandinn sé aðalatriði. XP aðferðin er samansafn aðgerða sem

styðja við stigvaxandi skilvirkni á þróun verkefnisins (Beck, 1999). Önnur aðferð, Scrumban,

hefur einnig verið að sækja í sig veðrið en hún er blanda af Scrum og Kanban aðferðunum.

Báðar eru þær Agile aðferðir þar sem Scrum aðferðin er frekar formföst en Kanban hefur

mun opnara og frjálsara form. Samt sem áður þarfnast Scrum, eins og Kanban, þess að teymi

séu að mestu leyti sjálfstýrð og að umhverfið einkennist af leiðtogamennsku fremur en

stjórnun (Mansor o.fl., 2011). Rannsóknir hafa sýnt að blanda af þessum tveimur aðferðum

dragi enn frekar úr sóun og minnki líkur á töfum verkefna (Alqudah og Razali, 2017).

Í nýjustu State of Agile skýrslu (VersionOne, Inc, 2018) kemur fram að Scrum sé nefnd

sem mest notaða Agile aðferðin af þátttakendum könnunarinnar (56%) á meðan XP, sem var

notuð af næstum fjórðungi þátttakenda í könuninni 2006, var nánast ekkert notuð meðal

þátttakenda árið 2018 (<1%). Aðrar aðferðir sem þátttakendur nefndu eru flestar

einhverskonar blendingar, eins og til dæmis Scrumban (8%) (VersionOne, Inc, 2018).

Agile aðferðafræðin getur verið vandmeðfarin og eru ýmsar áskoranir sem þarf að takast

á við. Sem dæmi er þegar kemur að því við notkun Agile aðferða að það þurfi að bregðast

við breytingum á aðstæðum í staðinn fyrir að fylgja áætlun, er það oft misskilið á þann hátt

að ekki eigi að vera nein áætlun. Án áætlunar veit teymi ekki hvernig á að forgangsraða

verkum og hvernig á að fjárfesta tíma og peningum á ábyrgan hátt í verkin. Vel gerður

kröfulisti (e. backlog) er í raun áætlun í Agile um forgangsatriði en einnig getur áætlun í raun

verið fólgin í stefnu fyrirtækins (McGregor og Doshi, 2018).

Agile vill fara af leið þegar fyrirtæki leitast við að ná frábærum árangri en verða of taktísk

með því að einblína um of á ferla og örstjórnun (e. micro managing), eða verða of aðlöguð

og forðast langtímamarkmið, tímalínur og þverfaglegt samráð milli deilda. Lykillinn að

árangri í Agile er að blanda þessum aðferðum saman (McGregor og Doshi, 2018).

Fyrirækjamenning er ekki síður mikilvæg þegar kemur að notkun Agile aðferða en hún þarf

að einkennast af leiðtogamennsku og samvinnu og rétt blanda sjálfsstjórnar og stjórnunar

þarf að nást, en það getur verið áskorun að raunverulega ná þeim aðstæðum að menningin

styðji við aðferðafræðina (Cavaleri og Obloj, 1993). Einnig vill það verða að fyrirtæki byggi

14

Agile upp eins og trúarbrögð sem ekki má efast um. Það er líklega ekki það umhverfi sem

Agile aðferðir ná bestum árangri í því samkvæmt einum af grunnkenningum Agile á áherslan

að vera á einstaklinga og samskipti umfram ferla og tól (Beck o.fl., 2001).Teymi ættu stöðugt

að vera að greina og ítra aðferðir sínar en dæmin sýna að mánaðarlegur fundur, þar sem

teymi greina aðferðir sínar og ákveða hvort það þurfi að breyta þeim til að ná fram betri

vöru, er vænlegur til árangurs. Þá hafa mörg fyrirtæki fallið í þá gryfju að innleiða Agile sem

röð aðgerða, en það hefur ekki sýnt sig vera leiðin til árangursríkrar innleiðingar. Með því að

halda hugmyndafræði Agile á lofti við innleiðinguna, sem í grunninn er hvatning og aðlöguð

frammistaða, er hægt að byggja upp fyrirtæki sem er raunverulega Agile (McGregor og

Doshi, 2018).

Agile aðferðir virðast virka og skila árangri en Serrador og Pinto (2015) rannsökuðu 1.002

verkefni með tilliti til áhrifa Agile aðferða á árangur þar sem horft var til skilvirkni og ánægju

hagaðila. Þeir komust að því að notkun á Agile aðferðum hefur marktæk jákvæð áhrif á slíkt

mat á árangri verkefna.

15

3 Uppskalað Agile

Mikilvægur hvati að Agile hugmyndafræðinni var í upphafi tengdur verkefnastjórnun í

hugbúnaðargeiranum. Mörg fyrirtæki fundu fyrir vandamálum tengdum verkefnastjórnun

(Long og Starr, 2008) ásamt stjórnun á mannauði og stjórnun áætlana (Chung og

Drummond, 2009) sem þau voru að leitast við að laga. Eldri hefðbundnar leiðir voru taldar

úreltar sökum mikillar yfirbyggingar sem kom fram í auknu skrifræði, óþarfa kostnaði vegna

ómarkvissra funda (O’Connor, 2011), ferlahliðum (e. process gates) (Chung og Drummond,

2009), breytingastjórnunarkostnaði (Vlaanderen o.fl., 2012) og óhófi í skráningu (Murphy og

Donnellan, 2009). Með rannsókninni í þessari ritgerð er ætlunin að skoða hvort þetta sé líka

raunin hjá stöndugum íslenskum fyrirtækjum, og þá hvaða ástæður liggja að baki þess að

þau hafa tekið upp uppskalað Agile.

Hugbúnaðarheimurinn í dag er mjög innstilltur á virði og í honum ríkir mikil samkeppni.

Fyrirtæki keppast við að vera sveigjanleg og með mikla aðlögunarhæfni til að geta brugðist

við stöðugum nýjungum og breyttum kröfum í viðskipta og tækniumhverfinu (Olszewska

o.fl., 2016). Sem afleiðing af þessu hefur hugmyndafræði Agile og Lean í þróun hugbúnaðar,

náð vinsældum meðal fyrirtækja af ýmsum stærðum og gerðum (Dingsøyr og Moe, 2013).

Samkvæmt skýrslu State of Agile (2018), völdu þátttakendur úr lista þau atriði sem þau

töldu sem kosti við það að nota Agile aðferðir. Þeir kostir sem voru oftast valdir voru: 1)

kosturinn við að geta stýrt breytingum á forgangsatriðum (71%), 2) skýrleiki verkefnis (66%)

og 3) meiri ávinningur fyrirtækisins í nýtingu á tækni (e. business/IT alignment) (65%). Einnig

röðuðu þáttakendur eftir mikilvægi ástæðum þess að þeir völdu Agile aðferðina, 75%

þátttakenda tiltók styttri afhendingatíma sem helstu ástæðu valsins, 64% völdu getuna til

þess að stýra breytingum á forgangsatriðum og 55% sögðu að aukin framleiðni teymis væri

helsta ástæða þess að þeir völdu Agile (VersionOne, Inc., 2018).

Þegar kannað var hvernig mælingar á árangri Agile á verkefnastigi færu fram sögðust

flestir svarendur mæla ánægju viðskiptavina (e. customer satisfaction) (46%) og skiluðu virði

til rekstrar (e. business value delivered) (43%), en einnig var hraði í gegnum spretti (e.

velocity) oft nefndur sem mæligildi (42%). Til að skoða framgang Agile verkefna í heild

nefndu þátttakendur aðallega afhendingar á réttum tíma, gæði vöru og ánægju

viðskiptavina sem helstu mæligildi (VersionOne, Inc., 2018).

16

Samkvæmt Olszewska o.fl. (2016) tekur tíma, fyrirhöfn og úrræði að breyta

vinnuaðferðum í stóru fyrirtæki og það þarf stöðugt að vera að meta valkosti og þarfir í

slíkum innleiðingum. Greining þeirra sýndi að allur vöruþróunarferillinn, það er:

þarfagreining, samþykktar hlið (e. gateway), forgangsröðun á kröfulista (e. backlog),

framleiðsla vöru og markaðssetning styttist verulega við það að breyta yfir í Agile og Lean

aðferðir.

Hraði samskeppnisumhverfisins sem við erum í hefur ýtt undir þau markmið fyrirtækja að

öðlast betri og hraðari aðlögunarhæfni og hafa þau því flykkst til að innleiða Agile

aðferðafræðina. Mörg hafa hins vegar hafa gert það á þann hátt að þau verða í raun minna

agile en áður. Þau fyrirtæki eru þá orðin Agile einungis að nafninu til þar sem sá ferill sem

þau hafa innleitt hefur endað með því að draga úr hvatningu til nýsköpunar og framleiðni

(McGregor og Doshi, 2018). Þetta gæti verið áskorun sem íslensk fyrirtæki, sem vinna með

uppskalað Agile, eru að glíma við þar sem erfitt getur verið að finna jafnvægi milli Agile og

hefðbundinna stjórnendaðaferða í stórum fyrirtækjum. Sem dæmi um þetta má nefna stórt

erlent fyrirtæki í tæknigeiranum sem lét framleiðsluteymi sitt eyða miklum tíma í að skrifa

upp nákvæmar kröfur verkefnis, svokallaðar „user stories“. Þessar nákvæmu kröfur voru

settar í röð þar sem þær biðu aðgerða næsta lausa sérfræðings og endaði þessi ferill á því að

verða lítill Waterfall verkefnaferill þar sem verk voru færð eftir röð ferla frá einni deild til

annarrar. En það er nákvæmlega þessi ferill sem Agile reynir að útrýma því slíkir ferlar hafa

sýnt sig draga úr lærdómi, aðlögun og framlagi starfsmanna (McGregor og Doshi, 2018). Í

rannsókn Dingsøyr o.fl. (2018) á norsku stórfyrirtæki var uppskalað Agile talið ganga vel að

hluta til vegna þess að gott jafnvægi var milli stjórnunar og sjálfstæði teyma.

Paasivaara (2017) gerði dæmisögurannsókn (e. case study) á fyrirtækinu Comptel þar sem

bornar voru saman tvær deildir í fyrirtæki sem báðar uppsköluðu Agile með sömu aðferð.

Hér er notast við skilgreiningu Dikerts o.fl. (2016) á uppsköluðu Agile sem ákveðnu

þróunarverkefni með fimmtíu eða fleiri starfsmönnum eða að minnsta kosti sex teymum.

Fyrri aðferðir deildanna, þar sem vörusérhæfðum Agile teymum var blandað saman við

verkefnastjórnun eftir Waterfall aðferðinni, sýndu sig vera bundnar ýmsum vandkvæðum.

Mikið var um að upp kæmu óvænt vandamál þegar leið nærri því að setja vörur á markað,

en sérstaklega voru tafir vegna talsverðrar dreifingar vöruþátta milli teyma. Á

verkefnaskráastigi einbeittu verkefnastjórar sér að sínum eigin Waterfall áætlunum þar sem

17

útseldar vörur til viðskiptavina voru alltaf samsettar úr nokkrum vörum. Samhæfingu og

samvinnu skorti innan þróunardeildar og verkefnastofu en einnig á milli deildanna.

Uppskölun á Agile átti að takast á við og eyða þessum vandamálum. Einnig vonaðist

fyrirtækið til að það myndi ná að bregðast hraðar við breytingum á markaði (Paasivaara,

2017)

Samkvæmt Leffingwell (2007) eru margar áskoranir fólgnar í því að skala upp Agile

aðferðir. Samræming milli margra Agile teyma er ein áskorun, og eins skortur á fyrirfram

ákveðnum ramma og erfiðleikar við greiningu á kröfum, en einnig er mikil áskorun fólgin í

dreifðum verkefnum þar sem stór fyrirtæki eru oft með dreifða staðsetningu, jafnvel í

mörgum löndum.

3.1 Aðferðir uppskalaðs Agile

Í gegnum árin hafa ýmsar aðferðir til notkunar á uppsköluðu Agile litið dagsins ljós:

Disciplined Agile Delivery (DAD), Large-Scale Scrum (LeSS), Scrum of Scrums (SoS) og Scaled

Agile Framework (SAFe). Allar þessar aðferðir eru afleiddar aðferðir úr grunn Scrum

rammanum (e. Scrum framework) en þær eru settar fram sem leið til að stýra eða koma

böndum yfir stór verkefni þar sem þarf að samræma vinnu milli margra teyma.

Streymisveitan Spotify bjó til sína eigin uppsköluðu Agile aðferð sem þeir kalla Spotify Tribe

en sú aðferð varð til hjá þeim þegar fyrirtækið stækkaði hratt og þeir þurftu að ná böndum

yfir það (medium.com; Kniberg, 2014). Spotify hefur gefið aðferðina út, ef svo má segja, til

nokunar fyrir alla sem vilja, en hún er aðgengileg á netinu (Kniberg, 2014) og hefur verið

notuð í einhverjum mæli. Í rannsókninni hér er reynt að kanna hvort íslensk fyrirtæki þekki

eða noti þessar eða aðrar aðferðir uppskalaðs Agile og hvort þau hafi innleitt þær markvisst

hjá sér.

The Scaled Agile Framework (SAFe) aðferðin er mest nefnd af þátttakendum í State of

Agile skýrslunni 2018, eða nærri 1/3 (29%) segja að SAFe aðferðin sé sú sem þeir fylgja að

mestu. Scrum of Scrums (SoS) er næst algengasta aðferðin sem þátttakendur nefna að þeir

noti (19%) en innanhúss tilbúnar aðferðir koma þar næst á eftir (10%). Mesta aukning milli

ára var á notkun á DAD aðferðinni en um 5% þátttakenda sögðust nota hana 2018 miðað við

1% árið 2017 (VersionOne Inc., 2018).

Núverandi Agile aðferðir bjóða ekki upp á góða útlistun á því hvernig fyrirtæki, sem

vinnur með uppskalað Agile, eigi að líta út, og þessar aðferðir uppskalaðs Agile sem eru allar

18

frekar nýlegar hafa að stærstum hluta ekki verið sannaðar með nægilega mörgum

rannsóknum. Það þykir því ljóst að það er þörf á því að hvert fyrirtæki aðlagi að sér þá Agile

aðferð sem hentar út frá samhengi fyrirtækis, markaðsumhverfis og vöru (Paasivaara o.fl.,

2018) Þessi þörf hefur einnig verið staðfest af fleiri fyrirtækjum sem hafa innleitt uppskalað

Agile, en árangursrík aðlögun á Agile aðferðum var nefnd sem einn af aðal árangursþáttum

þessara innleiðinga samkvæmt skipulagðri yfirferð fræðilegra rannsókna (Dikert o.fl., 2016).

3.1.1 SAFe

SAFe aðferðin (The Scaled Agile Framework) er sögð vera forskrift að því að nota uppskalað

Agile í stórum fyrirtækjum (Leffingwell, 2007, nú til í útgáfu 4.6 í Leffingwell o.fl., 2018).

Skilgreiningin á henni er mjög nákvæm og inniheldur að einhverju leyti niðurneglda

fundaáætlun. Skipulag aðferðarinnar er mikið að sniðum og hún felur í sér og gerir ráð fyrir

ákveðnu skipuriti stjórnenda þar sem mörg hlutverk eru skilgreind ásamt ábyrgðarþáttum

(Scaled Agile Inc., 2018, Leffingwell o.fl., 2018).

SAFe aðferðin samanstendur af ákveðnum stigum, teymisstigi, verkefnastigi og

verkefnaskráastigi en einnig valkvæðu virðiskeðjustigi. Á teymisstiginu notast aðferðin við

Scrum eða XP aðferð en eins er hægt að nota Kanban (Scaled Agile Inc., 2018; Leffingwell

o.fl., 2018 ).

Á verkefnastiginu eru ákveðin hlutverk skilgreind, eins og Agile afhendingalestin (e. Agile

release train, ART) sem er hliðstæðan við spetti á teymisstiginu en ART lestin hefur hægari

framgang. Fleiri hlutverk á verkefnastigi eru sem dæmi: kerfisteymi, vörustjóri,

kerfishönnuður, lestarstjóri (e. release train engineer RTE) og afhendingastjórnunarteymi

(Paasivaara, 2017). Á verkefnaskráastigi er svo ákveðið skipulag sem heldur utan um

skilgreiningu á stórum þróunarverkefnum (Paasivaara, 2017) en uppskalaðar Agile aðferðir,

vegna breytilega eðlis síns, koma með nýjar áskoranir inn í verkefnaskráastýringu sem kallar

á nýtt verklag á því sviði (Stettina og Horz, 2015). Virðiskeðjustigið, sem valkvætt er að nota í

SAFe aðferðinni, styður við þróun stórra og flókinna lausna sem þurfa að notast við margar

samhæfðar Agile lestir (ART) (Paasivaara, 2017).

Í undirbúningi að innleiðingu SAFe aðferðarinnar leggur SAFe 4.6 handbókin til að notast

sé við SAFe 1-2-3 ferlið sem nær yfir þrjú atriði þjálfunar og uppsetningar: 1) þjálfun

framkvæmdaraðila og Agile breytingastjóra, 2) þjálfun allra yfirmanna, stjórnenda og

19

leiðtoga og 3) þjálfun teyma og uppsetning ART lestar (Scaled Agile Inc., 2018, Leffingwell

o.fl., 2018).

Í dæmisögurannsókninni þar sem Paasivaara (2017) skoðaði uppskalað Agile í tveimur

deildum kom í ljós að deildirnar innleiddu báðar SAFe aðferð en á örlítið mismunandi hátt. Í

báðum deildunum var farið af stað með SAFe aðferðina ofan frá eða „top down“ en það

voru vöruþróunarstjórar fyritækisins sem fundu fyrir þörf á breytingu. Í ljós kom að í báðum

deildum jukust samskipti og samvinna gríðarlega við innleiðingu SAFe aðferðarinnar. Stærstu

breytingarnar sáust hjá verkefnastjórum en hugarfar þeirra hafði breyst frá því að vera

miðað að langtímaáætlunum og mismunandi viðskiptaeiningum í það að hugsa út frá

skammtímaáætlunum og forgangsraða út frá vörum og þjónustu (e. business line level)

Í þessu dæmi var farið af stað með innleiðinguna hálfu ári fyrr í annarri deildinni, en hún

gekk bersýnilega betur hjá þeirri deild sem byrjaði seinna. Skýringar á þessu eru bæði Agile

tengdar þar sem seinni innleiðingin lærði af reynslu þeirrar fyrri, og líka tengdar almennri

breytingastjórnun (Paasivaara, 2017). Rannsókn á innleiðingu deildanna sýndi að mikilvægar

leiðir að góðum árangri SAFe aðferðarinnar væru að fjárfesta í þjálfun, fá fólkið með sér,

finna breytingastjóra og að vera sífellt að bæta og aðlaga SAFe aðferðina (Paasivaara, 2017).

Bornar saman við uppskalað Agile hjá öðrum fyrirtækjum eru þessar leiðir til árangurs

ofarlega á lista mikilvægustu árangursþátta sem fram komu í skipulögðu yfirliti yfir

fræðilegar rannsóknir á uppsköluðu Agile (Dikert o.fl., 2016). Þannig má gera ráð fyrir að

þessir árangursþættir séu ekki eingöngu tengdir SAFe aðferðinni heldur einnig öðrum

aðferðum sem uppskalað Agile er unnið út frá (Paasivaara, 2017).

3.1.2 SoS

Scrum of Scrums (SoS) er aðallega samþættingaraðferð þvert á teymi þar sem

aðalmarkmiðið er að tryggja gæði Scrum aðferðafræðinnar (Sutherland, 2001). Hún er

yfirleitt notuð af þeim sem nota Scrum og eru með mörg teymi þar sem samræmingar er

þörf. Aðferðin byggir á því að þegar daglegur fundur (e. daily Scrum) er búinn fer einn fulltrúi

úr hverju teymi á annan daglegan fund þar sem farið er yfir hvað teymin þurfa frá öðrum

teymum. Þetta virkar vel upp að því marki að ekki séu fleiri á þessum seinni daglega fundi en

eru í Agile teymi eða að minnsta kosti ekki fleiri en tíu manns (Duncan, 2018). Í ýmsum

rannsóknum er stuðst við SoS aðferðina sem fullgilda aðferð notaða við uppskalað Agile

(Ebert og Paasivaara, 2017).

20

3.1.3 LeSS

Borin saman við SAFe aðferðina hefur Large-Scale Scrum (LeSS) ekki eins nákvæma lýsingu á

aðgerðum (Larman og Vodde, 2010). LeSS aðferðin, sem sýnd er á mynd 1, vinnur með

Scrum aðferðina og virkar fyrir verkefni sem unnin eru af tveimur til átta teymum. LeSS

reynir að vera eins agile og hægt er, hún leggur áherslu á hugarfar, gildi og meginreglur án

þess að innleiða of margra ferla og hlutverk (Larman og Vodde, 2010). Aðferðin byggir á

sjálfum teymunum og á að leitast við að þau séu sjálfstýrð, þverfagleg, vinna á sama stað og

vera föst til lengri tíma (The LeSS Company B.V. 2014-2019). LeSS aðferðin er frekar nýleg og

hefur því ekki fengið eins mikinn framtaksstuðning (e. enterprise support) og SAFe aðferðin.

Mynd 1 LeSS aðferðin (The LeSS Company B.V. 2014-2019).

3.1.4 DAD

Disciplined Agile Delivery (DAD) aðferðin er miðuð út frá fólki fremur en ferlum, út frá þeirri

kenningu að árangur flestra hugbúnaðarverkefna felist í einstaklingum og hvernig þeir vinna

saman. DAD er lærdóms- og markmiðadrifinn blendingur af ýmsum Agile aðferðum

hugbúnaðarþróunar og er byggð upp sem ákveðinn lífsferill (e. lifecycle) sem á að auka

skýrleika verkefna og draga þannig úr áhættu. Aðferðin er frábrugðin öðrum Agile aðferðum

sem fela í sér miklar forskriftir og reglur, eins og Scrum. DAD hjálpar til við að aðlaga ferla

svo hægt sé á skilvirkan hátt að takast á við þær aðstæður sem upp koma hverju sinni, með

útlistunum á því hvað virkar, hvað virkar ekki og hvers vegna (Ambler og Lines, 2012).

21

3.1.5 Spotify Tribe

Spotify Tribe aðferðin var eins og áður sagði þróuð út af gríðarlega hröðum vexti Spotify á

stuttum tíma. Upphaflega notaði Spotify Scrum aðferðina en í vextinum þurftu þeir að finna

leiðir til að láta Agile virka fyrir sig á stórum skala. Líkanið byggist upp á svokölluðum

ættbálkum (e. tribes) og innan þeirra eru nokkur lið (e. squads). Liðin samsvara teymum sem

samanstanda af sex til tólf manns og innan hvers ættbálks ættu helst ekki að vera fleiri en

hundrað manns (medium.com, 2018). Liðin eru í vinnu sinni sjálfráð, skipuleggja sig sjálf og

stýra sér sjálf, og mega nota hvaða Agile aðferðir sem er, eins og Kanban, Scrum, XP eða

blöndu af þessu. Til þess að gera liðunum kleift að gefa út oft og auðveldlega fylgja þau

minnstu mögulegu lausna aðferðinni (e. minimum viable product technique) (Kniberg, 2014).

Ýmis hlutverk eru skilgreind innan Spotify Tribe aðferðarinnar, til dæmis Agile þjálfari (e.

Agile coach) sem á að hjálpa til við að bæta vinnuaðferðir (e. way of working), vörueigandi

(e. product owner) sem á að sjá um að skilgreina sýn liðanna og yfir arkitekt (e. chief

architect) en hann sér um að skilgreina hönnun, leggja línurnar og samræma vinnu sem snýr

að útliti og uppsetningu. Í Spotify líkaninu eru líka fleiri hópar skilgreindir, eins og Trio,

Chapters og Guilds (mynd 2) en Guilds eru til dæmis nokkurs konar faghópar sem hittast

reglulega óformlega og ræða sitt fag og sameiginlega áhugamál (medium.com, 2018).

22

Mynd 2 Uppsetning Spotify Tribe líkansins (Kniberg, 2014)

Nú nýlega kom ný aðferð frá einum af upphafsmönnum Scrum, Ken Schwaber, sem nefnd

er The Nexus Guide en hún á að vera opin og öllum aðgengileg (Duncan, 2018). Ekki verður

fjallað nánar um hana hér þar sem hún er svo ný og því lítið notuð.

Samkvæmt nýjustu skýrslu State of Agile 2018 er DAD aðferðin að sækja í sig veðrið í

notkun þar sem aukning á skráðri notkun hennar milli áranna 2017 og 2018 nam fjórum

prósentustigum, eða fór úr 1% í 5% (VersionOne Inc., 2018). Í skýrslunni kemur einnig fram

að innanhúss Agile þjálfarar (53%), samræmdir starfshættir og ferli fyrir öll teymi (43%) og

innleiðing á algengri aðferð eða kerfi fyrir öll teymi (41%) eru þeir þættir sem þátttakendur

nefndu mest að væru þeir hjálplegustu við notkun á uppsköluðu Agile. Næst á eftir þessum

þáttum nefndu þátttakendur aðra hjálplega þætti eins og stuðning stjórnenda og mikilvægi

þess að fá inn Agile ráðgjafa eða þjálfara (VersionOne Inc., 2018)

Fræðigreinar og sönnuð módel hafa þó greinilega skort á þessu sviði uppskalaðs Agile en

eins hefur skort útlistanir á því hvernig lokaafurð innleiðingar þess á að vera (Paasivaara,

2017). Enn eru til fáar sjálfstæðar raunprófanir (e. emperical research) sem sýna hvort

þessar aðferðir og aðgerðir, sem notaðar eru í uppsköluðu Agile, virka í raun og veru, hvaða

áskoranir fylgja uppskölun og hvernig á að takast á við þær (Paasivaara, 2017). Teymi í

uppsköluðu Agile hafa hins vegar verið ágætlega skilgreind, þau geta annað hvort verið

23

hlutamiðuð (e. component teams) eða þáttamiðuð (e. feature teams). Hlutamiðuð teymi

þróa ákveðinn hluta úr vöru sem getur ekki staðið sjálfstæður á meðan þáttamiðuð teymi

þróa ákveðinn þátt alla leið þannig að viðskiptavinur geti notað hann beint (Smite, o.fl.,

2017).

3.2 Fyrirtækjamenning og hlutverk stjórnenda

Agile aðferðafræðin var ekki hugsuð sem tæki eða tól til að vinna að einstöku verkefni

heldur meira sem heildræn hugmyndafræði við verkefnastýringu. Mikilvægt er því við

innleiðingu á Agile að gera sér grein fyrir því að hugmyndafræðin verður að ná inn í

menningu fyrirtæksins til að hún festist í sessi og skili tilætluðum árangri (Misra o.fl., 2010).

Áhugavert er að vita hvort íslensk fyrirtæki sem vinna eftir Agile hugmyndafræðinni hafi

hugað að þessu atriði og unnið með Agile í tengingu við menningu á einhvern hátt.

Agile aðferðir hafa áhrif út um allt, einnig á stjórnunar og viðskiptaeiningar fyrirtækja og

er það lykiláskorun stjórnenda að breyta hugsunarhætti sínum og flytja sig úr föstum

líkönum áætlana og yfir í ítrunar- og eiginleikamiðuð líkön (Nerur o.fl., 2005). Áherslum á

langtímaáætlanir þarf að skipta út fyrir styttri verkefnamiðaðar áætlanir (Misra o.fl., 2010),

því samkvæmt Agile hugmyndafræðinni er eingöngu gagnlegt að skipuleggja og áætla

nánustu framtíð (Cohn og Ford, 2003). Það getur auðvitað verið erfitt að vera ekki með

langtímaáætlun sérstaklega í ljósi þess að viðskiptasambönd og samningar eru oft gerðir til

langtíma. Til að greiða fyrir innleiðingu Agile aðferðafræðinnar og þar með styttri áætlunum

er því mikilvægt að kynna breytingar vel fyrir haghöfum (e. stakeholders) og endurskoða

samingagerð í samvinnu við þá. (Boehm og Turner, 2005).

Paasivaara o.fl. (2018) skoðuðu innleiðingu stækkaðs Agile hjá Ericsson, en þeir áttuðu sig

á þörf fyrirtækisins á að verða meira agile og settu innleiðingu uppskalaðs Agile í forgang í

stefnumörkun sinni. Það reyndist vera orðið mjög krefjandi að skipuleggja og samræma

vinnuferla, sumir þættir í vörunum þeirra voru háðir mörgum öðrum þáttum og voru þeir

sérfræðingar sem á þurfti að halda ekki alltaf til taks. Ferlið var því ekki mjög skilvirkt,

þróunarferill var langur og teymin áttu erfitt með að klára verk innan ákveðins tímaramma.

Teymismeðlimir kvörtuðu undan því að vinna í slíku umhverfi væri stressandi og óskipulögð.

Sá öri vöxtur sem fyrirtækið hafði farið í gegnum, úr tuttugu manns í yfir hundrað var líklega

það sem orskakaði þessi vandamál og gerði það að verkum að breytinga var þröf.

(Paasivaara o.fl., 2018).

24

Við innleiðinguna á stækkuðu Agile notaði Ericsson svokallaða tilraunaaðferð, þar sem

viljandi er einblínt á einn þátt eða framfarir á hverjum tímapunkti, en Ericsson byggði það á

fyrri reynslu sinni við innleiðingu Agile í minni deildir. Stjórnendur höfðu lært að það er

ómögulegt að skipuleggja innleiðinguna nákvæmlega og framkvæma með Waterfall

hugarfari. Þannig var hvert skref skipulagt út frá þeirri þörf sem myndaðist hverju sinni

(Paasivaara o.fl., 2018).

Það vill gerast að þegar stjórnendur fara af stað við að skala upp Agile aðferðir innan

fyrirtækis að það sé gert eftir innleiðingarferlum hefðbundinnar verkefnastjórnunar eða eftir

svokallaðri „top down“ aðferð. Rannsóknir hafa sýnt að betri leið við innleiðinguna er að

yfirmenn hegði sér samkvæmt Agile hugmyndafræðinni. Þeir myndi Agile teymi og horfi á

starfsmennina eins og viðskiptavini með mismunandi þarfir og þarf innleiðingin því að taka

stöðugum breytingum eftir því hvað eykur virði og árangur starfmannanna (Rigby o.fl.,

2018).

Samkvæmt nýjustu skýrslu State of Agile (VersionOne, Inc., 2018) var fyrirtækjamenning

yfirgnæfandi mest nefndi þátturinn sem mikilvægur þáttur í innleiðingu og uppskölun á

Agile. Þær þrjár áskoranir sem voru nefndar af þátttakendum sem helstu áskoranir við

innleiðingu og uppskölun á Agile voru fyrirtækjamenning sem er ekki hliðholl Agile

hugmyndafræðinni (53%), almenn breytingatregða og mótþrói (46%) og ekki nægur

stuðningur og skuldbinding stjórnenda (42%) (VersionOne Inc., 2018).

Gott dæmi um hvernig á að láta fyritækjamenningu styðja við stefnu og markmið er

fyrirtækið Intuit en það er hugbúnaðarfyrirtæki sem hefur þá stefnu og markmið að vera

með flottan og vel hannaðan hugbúnað útlitslega. Inuit notast því við „design thinking“

aðferðina þar sem allar deildir innan fyrirækisins þurfa að huga að hönnun og fagurfræði,

líka fjármáladeild og mannauðsdeild. En með því að breyta fyrirtækjamenningu sinni í þessa

átt náðu Inuit að verða stærstir í sinni vöru á markaði (Smith, 2015). „Það er nauðsynlegt að

allir starfsmenn átti sig á því að hönnun vörunnar og upplifun notandans kemur okkur öllum

við, ekki bara hönnuðunum og framleiðslustjórunum. Í dag erum við neytenda- og

hönnunardrifið tæknifyrirtæki í fremstu röð.“ [mín þýðing] (Smith, 2015). Einnig er

áhugavert dæmi um breytingu á fyrirtækjamenningu í stórfyrirtæki nefnt í rannsókn

Dingsøyr o.fl. (2018) á stóru norsku hugbúnaðarfyrirtæki sem skalaði upp Agile í stórt

25

verkefni. Þar sást greinileg breyting á því hvernig menningin færðist með Agile

innleiðingunni yfir í menningu sem einkenndist af trausti og samvinnu (Dingsøyr o.fl., 2018).

3.3 Rannsóknir á uppsköluðu Agile

Agile sem hugbúnaðarþróunaraðferð heldur áfram að vaxa í vinsældum og er sífellt innleidd

af fleiri og fleiri fyrirtækjum. Þrátt fyrir þetta er enn talsverð vöntun á raungögnum til

staðfestingar á þeim kostum og göllum og áhrifum sem umbreyting yfir í uppskalað Agile

hefur í fyrirtækjum. Sérstaklega þar sem umbreytingakostnaður getur verið gríðarlegur og

áhætta er fólgin í breytingum á vinnurútínu og tryggingu gæða við breytingu vöruþróunar

(Olszewska o.fl., 2016). Það eru því ýmsar áskoranir sem fylgja uppskölun á Agile sem finna

þarf góðar lausnir við og einnig draga fram þá árangursþætti uppskölunar Agile sem teljast

mikilvægastir (Leffingwell, 2007). Með frekari rannsóknum hérlendis og erlendis verður

hægt að varpa betra ljósi á þessa þætti.

Í nýlegri fræðilegri yfirferð rannsókna á kerfisbundinn hátt afhjúpaðist skorturinn á

kerfisbundnum rannsóknum á aðferðum uppskalaðs Agile í stórfyrirtækjum í

hugbúnaðarþróun (Dikert o.fl., 2016). Stór fyrirtæki framkvæma stór verkefni í stórum

rannsóknar- og þróunardeildum sem kallar á ákveðna uppskölun á Agile aðferðum

(Paasivaara o.fl., 2018). Þrátt fyrir áskoranir eins og samræmingu milli teyma, skort á

fyrirfram ákveðnum ramma og flóknum kröfulistum hafa stórfyrirtæki valið að innleiða Agile

aðferðir (Leffingwell, 2007). Þau gera það jafnvel þótt rannsóknir á því hvernig best sé að

skala upp Agile aðferðir fyrir stór verkefni (Hossain o.fl., 2009), og hvernig á að stýra

árangursríkri uppskölun Agile í stór fyrirtækjum, skorti að mestu (Dikert o.fl., 2016).

Agile aðferðir voru upphaflega þróaðar fyrir lítil fyrirtæki og þótt fyrri sögur um árangur

séu margar hefur uppskölun á Agile reynst krefjandi (Dybå og Dingsøyr, 2009). Áskoranir við

uppskölun Agile aðferða eru að einhverjum hluta komnar til vegna tregðu tengdri stærð

fyrirtækisins, sem hægir á breytingaferlinu (Livermore, 2008b). Ásamt þessu þarf að takast á

við áskoranir um að tengja og samþætta Agile aðferðir við það ferli og skipulag sem fyrir er

(Boehm og Turner, 2005).

Agile aðferðir veita litla leiðsögn um hvernig mörg Agile teymi eiga að tengjast og eiga

samskipti við umhverfið í heild. Vegna þessa hafa stærri fyrirtæki þurft að sníða Agile

aðferðir til þannig að þær henti þeirra þörfum. Afleiðing þessa er að gera þarf sérstaklega

26

ráð fyrir skipulagðri samskiptaáætlun sem gæti í raun virkað sem mótvægi við Agile og

dregið úr snerpu og liðleika (Lindvall o.fl., 2004).

Stór verkefni eru yfirleitt flókin, bæði fyrir fyrirtækið sem heild og einnig tæknilega.

Haghafar eru fjölmargir, margir taka þátt og koma að verkefninu, kröfur eru margar og ef um

forritunarverkefni er að ræða eru oft margar línur til að kóða. Oft er samhengi verka mjög

flókið og einnig er flókið samhengi þess hvernig teymin reiða sig hvert á annað. Þau verkefni

sem nota uppskalað Agile eiga á hættu að það vanti upp á samræmingu og þau glími við

vandamál tengd upplýsingaflæði og samskiptum (Xu, 2009).

Carlile (2002) sá að stór verkefni væru líklegri til að vera mjög þverfagleg og ná þvert yfir

deildir sem gerir það að verkum að öll þekkingarmiðlun til haghafa verður erfið. Ambler

(2008) sýndi fram á það sama, að vegna þess hversu flókin stór verkefni eru og koma á borð

margra deilda og aðila, þá eru haghafar líka yfirleitt mun fleiri en í minni verkefnum. Það er

því ekki bara verkefnið sjálft sem er flókið vegna þess hversu stórt það er, heldur verður allt í

kringum það flókið eins og samskipti við fjölbreytta flóru haghafa þess (Pikkarainen o.fl.,

2008).

Ákveðið vandamál við að nota Agile við stærri verkefni er hvernig er best að standa að

samþættingu milli teyma. Uppskalað Agile getur einnig þýtt að það sé meira mál að tengjast

öðrum deildum innan fyrirtæksins eins og mannauðsdeild, sölu og markaðsdeild og

vörustjórnunardeild. Auk þessa er aukin hætta á, í uppsköluðu Agile, að notendur og aðrir

haghafar fjarlægist teymin. En eins og áður kom fram hafa fyrirtæki, þrátt fyrir þessi þekktu

vandamál tengd uppsköluðu Agile, verið að færa sig í þá átt að innleiða Agile aðferðina í

stækkaðri mynd (Paasivaara o.fl., 2013, 2014; Dingsøyr and Moe, 2013). Það að skala upp

Agile til að nota við stórt verkefni felur í sér að Agile aðferðin þarf að snerta margar víddir

(Eklund o.fl., 2014).

Rannsókn Dingsøyr o.fl. (2018) styður fyrri rannsóknir um að samhæfingarhæfni

einstaklingsins sé meginþáttur í því að ná samþættingu teyma í stærri verkefnum. Í því

verkefni sem rannsóknin tók til kom í ljós hversu mikilvægu hlutverki opið vinnurými gegndi,

en það hvatti til samræmingar á skilvirkan hátt. Einnig varð ljóst mikilvægi þess að eftir því

sem tíminn leið að það yrði að vera þróun og breyting á samræmingarferlinu, sem ýtir undir

það að aðferðir séu endurskoðaðar og þeim breytt eftir því sem verkefnið þróast yfir líftíma

27

sinn. Þetta er í raun í samræmi við almennar Agile aðferðir þar sem horft er til baka og farið

yfir hvað gekk vel og hvað gekk illa, eða svokallað „retreospective“ (Dingsøyr o.fl., 2018).

3.3.1 Áskoranir og árangursþættir

Kalenda o.fl. (2018) rýndu ferla, áskoranir og árangurríka þætti við notkun uppskalaðs Agile

með því að gera fræðilegt yfirlit rannsókna, ásamt því að skoða og greina krítíska þætti í

uppskölun á Agile hjá stóru hugbúnaðarfyrirtæki. Þau komust að því að fyrirtækjamenning,

fyrri notkun á Agile ásamt reynslu af Lean, stuðningur stjórnenda og gildi samstöðu (e. value

unification) voru lykilþættir árangurs í ferlinu. Dikert o.fl. (2016) könnuðu einnig áskoranir og

árangursríka þætti við notkun á uppsköluðu Agile með því að gera skipulagt fræðilegt yfirlit

rannsókna. Þar kom í ljós að mest nefndu árangursþættirnir voru: 1) val og aðlögun á Agile

aðferð (50%), 2-3) stuðningur stjórnenda (40%) og hugarfar (40%) og 4) æfing og þjálfun

(38%). Ef farið var ítarlegar í árangursþættina og þeir greindir frekar var oftast nefnt til þess

að árangur næðist væri mikilvægt að tryggja stuðning stjórnenda (29%), þjálfa teymi því þau

læra betur með því að gera (29%), aðlaga Agile aðferðina varlega (26%) og að byrja með

prufuverkefni til að fá fram samþykki innan fyrirtækisins.

Flokkun verkefna er líka mikilvæg þegar nota á uppskalað Agile innan fyrirtækja. Carl

Liebert, yfirmaður framleiðslu (e. chief operating officer) hjá stórfyrirtækinu USAA í

Bandaríkjunum, er með yfir 500 Agile teymi og er flokkun verkefna þar mjög aðgengileg fyrir

alla innan fyrirtækisins. Hann segir að ef flokkun verkefna sé ekki vel unnin eigi fyrirtæki það

meðal annars á hættu að vera með ranga samsetningu af starfsmönnum (Rigby o.fl., 2018).

Þær áskoranir sem Kalenda o.fl. (2018) greindu sem þær erfiðustu í uppskölunarferlinu

reyndust vera breytingatregða, of hratt innleiðingarferli, áhyggjur af gæðatryggingu og

innleiðing í þær viðskiptaeiningar sem ekki notuðu Agile fyrir. Við uppskölun á Agile innan

fyrirtækis er mikilvægt að fylgja ekki fyrirfram ákveðinni áætlun, heldur er betra að sníða

ferilinn eftir þörfum en halda í kjarnagildi og undirstöðuatriði Agile aðferðafræðinnar

(Kalenda o.fl., 2018). Það sama kemur fram hjá Rigby o.fl. (2018) en þar segir að innleiðingin

þurfi að taka stöðugum breytingum eftir því hvað eykur virði og árangur starfmanna.

Dikert o.fl. (2016) könnuðu einnig áskoranir við uppskölun á Agile í sínu skipulagða

fræðilega yfirliti og sýndu niðurstöður þeirra mest nefndu áskoranirnar vera: 1) Erfitt að

innleiða Agile (nefnt í 48% tilfella), mest var í því samhengi nefndur skortur á leiðbeiningum

og stuðningi frá fræðilegu efni (21%), 2) Innleiðing í ferla sem ekki eru vöruþróunarferlar

28

(43%), 3-4) Breytingatregða (38%), mest nefnd tregða annarra deilda til að breytast (31%),

og áskoranir vegna fjölda krafna og flókinna (38%) .

Erfiðara virðist að skala upp Agile en almennt hefur verið talið, en fyrirtæki kvarta undan

því að finna ekki nægan stuðning og leiðsögn frá fræðilegu efni. Því stærri sem fyrirtækin eru

þurfa þeim mun fleiri deildir utan þróunardeilda að taka þátt. Deildir eins og áður voru

nefndar, sölu og markaðsdeildir, mannauðsdeildir og þjónustudeildir þurfa að tengjast inn í

þróunarferlið á öllum stigum (Dikert o.fl., 2016). Markmið rannsóknarinnar hér er einmitt að

hluta til að kanna hvort íslensk fyrirtæki finni fyrir slíkum stærðaráhrifum. Ef ekki er gert ráð

fyrir þessum tengingum við aðrar deildir og þær samræmdar í ferlinu getur það skapað

miklar takmarkanir í uppsköluninni og verður til þess að ekki er hægt að nýta sér alla þætti

og möguleika sem Agile aðferðafræðin býður upp á (Dikert o.fl., 2016)

Paasivaara o.fl. (2018) gerðu rannsókn á uppsköluðu Agile hjá Ericsson í nýju rannsóknar-

og þróunarverkefni sem staðfesti margar af þessum áskorunum og árangursþáttum sem

Dikert o.fl. (2016) greindu. Í fyrsta lagi er breytingatregða en hún er algengt vandamál í

innleiðingu á uppsköluðu Agile og í raun allri almennri innleiðingu nýrra ferla (Dikerts o.fl.

2016). Ericsson upplifði breytingatregðu hjá stjórnendum þar sem ekki allir höfðu viljann til

að skipta yfir í uppskalað Agile (Paasivaara o.fl. 2018). Önnur áskorun, skortur á fjárfestingu

og skuldbindingu í innleiðingunni, felur í sér skort á æfingu og þjálfun, of mikið vinnuálag, að

haldið sé í gamla hluti og vinnurými ekki breytt (Dikerts o.fl. 2016). Paasivaara o.fl. (2018)

sáu einmitt að þjálfun í upphafi uppskölunarinnar var ábótavant sem gerði teymum erfitt

fyrir að samhæfa sig.

Þriðja áskorunin samkvæmt flokkun Dikerts o.fl. (2016) er að erfitt sé að innleiða Agile

hugmyndafræðina yfir höfuð. Það sem gerir innleiðinguna erfiða er meðal annars að hugtök

Agile eru misskilin, skortur er á leiðbeiningum og sönnuðum líkönum úr fræðilegri umfjöllun,

að Agile er ekki aðlagað nógu vel að aðstæðum fyrirtækisins, snúið er aftur til fyrri aðferða

og jafnvel getur óhóflegur áhugi skemmt fyrir þar sem keyrt er áfram í blindi. Í sinni

uppskölun átti Ericsson erfitt með að finna gott jafnvægi á milli stjórnunar og sjálfstæðis,

teymum var gefið mikið frelsi og ekki var lögð áhersla á notkun á neinni sérstakri aðferð

innan Agile hugmyndafræðinnar. Eftir á að hyggja hefði Ericsson átt að byggja á einni aðferð,

eins og til dæmis Scrum, fyrir öll teymin og aðlaga hana að fyrirtækinu. Það hefði auðveldað

teymismeðlimum að fara á milli teyma og öll samskipti hefðu orðið auðveldari (Paasivaara

29

o.fl., 2018). Í fyrrnefndri athugun Dingsøyr o.fl. (2018) á norsku stórfyrirtæki þótti uppskalað

Agile ganga vel en það var einmitt að hluta til sagt því að þakka að fyrirtækið fann gott

jafnvægi milli stjórnunar og sjálfstæðis teyma en einnig samræmingu milli teyma. Það

auðveldaði hins vegar og hjálpaði til að Scrum aðferðin var notuð sem grunnur.

Fjórða áskorunin sem Dikert o.fl. (2016) nefna er tengd þessu en það er áskorunin við

samhæfingu í fjölteyma umhverfi. Þar er verið að glíma við atriði eins og erfiðleika við tengsl

milli teyma, sjálfstæði teyma og dreifða staðsetningu. Í uppsköluðu Agile umhverfi þurfa

teymi að vera sjálfstæð en þrátt fyrir það þurfa teymismeðlimir að hafa aðgang að skilvirku

þekkingarmiðlunarneti og vinna náið með sérfræðingum utan teymisins (Moe o.fl., 2014;

Smite o.fl., 2017). Dingsøyr o.fl. (2018) framkvæmdu dæmisögurannsókn hjá stóru norsku

fyrirtæki í hugbúnaðargeiranum þar sem notað var uppskalað Agile í bland við hefðbundnar

aðferðir til að stýra mjög stóru verkefni þar sem um 175 manns komu að. Vildu þeir kanna

hvernig Agile aðferðir gætu verið aðlagaðar að svo stóru verkefni með tilliti til ýmissa þátta,

eins og aðkomu viðskiptavina og samræmingu milli teyma. Aðkoma viðskiptavina og önnur

samræming í svona stóru þróunarverkefni getur verið krefjandi þar sem haghafar eru margir

og geta þeir haft mismunandi sýn og forgangsatriði (Barney og Wohlin, 2009).

Í rannsókn Dingsøyr o.fl. (2018) tókst norska fyrirtækið á við þessar áskoranir á

árangursríkan hátt með því að vera með marga vörueigendur (e. product owners) og fulltrúa

viðskiptavina í fullri vinnu í verkefninu. Þeir báru ábyrgð á því að greina þarfir með því að

skilgreina og forgangsraða atriðum á kröfulistanum. Þessir aðilar voru staðsettir á sama stað

og teymin til að tryggja aðgang teymanna að þeim. Niðurstöður rannsóknarinnar eru í

samræmi við Barney og Wohlin (2009) um að opið og skýrt samtal og góð samskipti og

upplýsingaflæði milli teyma sé nauðsynlegt til að samstilla mismunandi hópa haghafa. Í

verkefninu voru teymin með í útlistun heildarlausnarinnar sem reyndist mikilvægt fyrir

árangur verkefnisins því það tryggði samræmi milli teymanna og setti ákveðna

lokaafurðarábyrgð á þau (Dingsøyr o.fl., 2018).

Tengt þessu er fimmta áskorunin um notkun á mismunandi aðferðum í fjölteyma

umhverfi. Tvö meginatriðin hér er annars vegar mismunandi túlkun teyma á Agile og hins

vegar vandamál sem koma upp þegar verið er að nota bæði nýju aðferðafræðina og gömlu á

sama tíma (Dikert o.fl., 2016). Paasivaara o.fl. (2018) sáu að þrátt fyrir að uppskölun á Agile

hefði farið fram í mörgum deildum voru stoðdeildir og annað utanumhald hjá Ericsson enn

30

fast í Waterfall ferlum. Til dæmis voru verkefnastýring og stýring vörulosunar framkvæmdar

á hefðbundinn hátt en þetta var að miklu leyti vegna þess að það vantaði breytt hugarfar. Á

sömu nótum fundu Dikert o.fl. (2016) áskoranir tengdar skipuriti og ákveðnum

fyrirtækjaramma eins og að oft vanti að hlutverk millistjórenda í Agile séu skýrari,

stjórnendur séu fastir í Waterfall ferlum, haldið sé áfram með gamaldags skrifræði og innri

deildaskiptingu (Dikert o.fl., 2016).

Eins voru samkvæmt flokkun Dikerts o.fl. (2016) nefndar áskoranir við auknar og flóknari

kröfur verkefnis og gæðaprófanir. Erfitt getur reynst að skilgreina þær fjöldamörgu kröfur

sem stór verkefni fela í sér og þar með einnig erfitt að skilgreina hvað þarf að gæðaprófa. Í

rannsókn Dingsøyr o.fl. (2018) þótti hjálpa til með samskipti og miðlun upplýsinga að teymin

væru í opnu vinnurými, en þessi fyrirhögun þótti einnig auka skilning á verkefninu og með

því draga úr þörf á þeirri nákvæmni í kröfulýsingum sem farið var af stað með í upphafi.

Þekkingarmiðlun í Agile umhverfi er miðuð út frá miðlun leyndrar þekkingar, eins og með

fundum, en sú miðlun verður flóknari og erfiðari þegar komið er í stór verkefni og

þátttakendum og haghöfum fjölgar (Dingsøyr o.fl., 2018).

Að lokum drógu Dikert o.fl. (2016) fram, með sínu skipulagða fræðilega yfirliti yfir

rannsóknir, mikilvægi áskorana sem snúa að því að innlima aðgerðir og deildir sem ekki

tengjast vöruþróun í Agile uppsköluninni. Helstu áskoranir tengar þessu eru tregða annara

deilda til að taka þátt, aðlögun fyrirtæksins í heild að nýjum vöruafhendingaraðferðum og

hraða en einnig það að hvatningakerfi og umbunakerfi fyrirtækisins sé ekki miðað út frá

teymisvinnu.

Í skoðun sinni á uppskölun á Agile hjá Ericsson drógu Paasivaara o.fl. (2018) saman þau

atriði sem þeim fannst mikilvægast að hafa í huga við innleiðingarferlið. Þessi atriði settu

þau fram sem fjórar lærðar lexíur við uppskölun á Agile aðferðafræðinni:

Lexía 1: Hafa í huga að tileinka sér Agile hugarfar og nota tilraunaaðferð við

innleiðinguna. Hugarfarið sem Ericsson tileinkaði sér var að það er gott að prófa og í lagi þótt

það takist ekki þar sem það er eina leiðin til að læra. Þetta samræmist Agile

hugmyndafræðinni og Paasivaara o.fl. (2018) telja þetta mikilvægan árangursþátt í

uppskölun Agile, en fræðileg yfirferð Dikert o.fl. (2016) styður þetta þar sem nokkur

fyrirtæki tóku fram að aðlögun Agile aðferðar væri í raun þróunarferill.

31

Lexía 2: Betra er að skala upp Agile í skrefum, en sú aðferð er góð í flóknu og stækkuðu

umhverfi þar sem innleiðingin fer fram meðfram öðru starfi (Paasivaara o.fl., 2018). Í

fræðunum finnast rök með bæði innleiðingu í skrefum og allsherjar innleiðingu en innleiðing

í skrefum er algengari. Oft byrjar hún með því að farið er af stað með tilraunaverkefni (e.

pilot) en það hefur verið nefndur sem einn af árangursþáttum í uppskölun Agile (Dikert o.fl.,

2016).

Lexía 3: Erfitt er að ætla öllum teymum að geta farið í öll verk því þau geta verið mjög

sérhæfð og flókin og því gott að halda í ákveðna sérhæfingu teyma (Paasivaara o.fl., 2018).

Lexía 4: Mikilvægi þess að fyrirtækið hafi ákveðna stefnu og Agile aðferð sem grunn í

upphafi. Ef þetta er ekki til staðar er hætta á að þjálfun verði ábótavant og teymin verði

stefnulaus og ráðvillt. Í sumum teymum getur verið fólk með mikla Agile þekkingu en í

öðrum ekki, einnig kemur fólk saman í teymi úr deildum með mismunandi menningu og ef

ekki er til staðar einhver stefna í upphafi getur samvinna og samhæfing orðið erfið

(Paasivaara o.fl., 2018). Að leyfa teymum að skipuleggja sig sjálf er einn að árangursþáttum

uppskölunar á Agile (Dikert o.fl., 2016). Á hinn bóginn var það líka nefnt sem árangarsþáttur

að samræma uppskölunina með því að nota eina Agile aðferð (Dikert o.fl., 2016).

Eins og áður hefur komið fram var fyrirtækjamenning yfirgnæfandi mest nefnd sem

mikilvægur þáttur í innleiðingu og uppskölun á Agile samkvæmt nýjustu skýrslu State of

Agile (VersionOne, Inc., 2018). Það er í samræmi við niðurstöður Kalenda o.fl. (2018) í

yfirferð á fræðilegum rannsóknum um uppskölun á Agile. Þær þrjár áskoranir sem voru

nefndar af þátttakendum sem þær helstu við innleiðingu og uppskölun á Agile samkvæmt

skýrslunni voru; fyrirtækjamenning sem er ekki hliðholl Agile hugmyndafræðinni (53%),

almenn breytingatregða og mótþrói (46%) og ekki nægur stuðningur og skuldbinding

stjórnenda (42%) (VersionOne Inc., 2018). Þessar niðurstöður skýrslunnar eru ekki bara í

samræmi við Kalenda o.fl. (2018) heldur líka Dikert o.fl. (2016) eins og fjallað hefur verið um.

3.3.2 Kostir við að nota uppskalað Agile

Frekari kostir uppskalaðs Agile eiga eftir að koma í ljós með tímanum og betri rannsóknum.

Spurningin um hvers vegna fyrirtæki í hinum ýmsu geirum eru farin að nýta sér

hugmyndafræði Agile og aðlaga að sínu starfi er áhugaverð. Aðferðafræðin er að miklu leyti

byggð á tilraunaaðferð og því hlýtur sú aðferð að vera útgangspuntkur í

framtíðarrannsóknum á uppsköluðu Agile. Flestir gera sér grein fyrir mikilvægi þess að í

32

staðinn fyrir að byggja upp Agile eins og trúarbrögð sem ekki má efast um ættu teymi að

vera stöðugt að greina og ítra aðferðir sínar í samræmi við grunnkenningar Agile. Reglulegur

fundur, þar sem teymi greina aðferðir sínar og ákveða hvort það þurfi að breyta þeim til að

ná fram betri vöru, er vænlegur til ná betri árangri (McGregor og Doshi, 2018).

Lal og Clear (2018) könnuðu hvernig stórt alþjóðlegt hugbúnaðarfyrirtæki staðsett í

Ástralíu þróaði getu sína með því að færa sig, á yfir 10 ára tímabili, yfir í uppskalað Agile með

DAD aðferðinni í þremur skrefum. Þeir töldu rök fyrirtækisins fyrir því að færa sig yfir í

uppskalað Agile hafa verið kröfur um sneggri afhendingu vöru á markað, kröfur um betri

gæði varanna ásamt kröfum um að sinna alþjóðlegum viðskiptavinum sínum betur. Þessi

breyting sýndi sig ekki bara í bættum þróunarferlum og framleiðslugetu innan fyrirtækisins

heldur einnig í bættri getu og hæfni fyrirtækisins í hlutum eins og hvernig það var betur

undirbúið og gat brugðist betur við ytri pressu eða í raun bættri heildaraðlögunarhæfni

fyrirtæksins (Lal og Clear, 2018).

Þörf er á frekari og ítarlegri dæmisögurannsóknum á uppskölun Agile eða innleiðingu

Agile í stór fyrirtæki, sem og aðlögun Agile aðferða að stórum verkefnum. Einnig er þörf á að

færa betri rök og sannanir fyrir notkun þeirra uppskölunaraðferða og líkana sem til eru.

33

4 Aðferðir og gagnsöfnun

4.1 Rannsóknaraðferð

Framkvæmd var eigindleg rannsókn sem snerist um að fá ákveðna innsýn inn í uppskalað

Agile starf íslenskra hugbúnaðarfyrirtækja, skoða hvaða áskorunum þau hafa verið að lenda í

og greina til hvers megi rekja þessar áskoranir. Eins var leitast eftir að greina árangursþætti

og ávinning uppskalaðs Agile starfs og fá sýn á hvort þeir séu almennir eða hvort megi tengja

þá við bakgrunn eða aðstæður fyrritækjanna.

Erfitt er að staðhæfa um niðurstöður eigindlegra rannsókna og er markmiðið fremur það

að gera ákveðið efni skýrara með mörgum lýsingum mismunandi aðila sem tengjast því.

Niðurstöður eigindlegra rannsókna byggja á þeim gögnum sem safnast og eru túlkaðar af

rannsakanda á ákveðinn hátt. Þannig notar rannsakandi sína eigin reynslu og þekkingu til að

meta þær upplýsingar sem hann hefur, út frá aðstæðum, og eru niðurstöður því fremur

ályktanir en staðhæfingar (Merriam, 2009).

Í rannsókninni var unnið út frá grundaðri kenningu og notast við opna kóðun við úrvinnslu

rannsóknagagna. Með aðferðum grundaðrar kenningar er gögnum safnað kerfisbundið en

eftir sveigjanlegum leiðbeiningum og eigindlegar upplýsingar greindar og þannig byggðar

upp kenningar út frá sjálfum gögnunum.

Gagnaöflunin fór fram í formi hálf opinna viðtala þar sem notast var við fyrirfram

ákveðinn viðtalsramma og honum fylgt að mestu leyti, en þó reyndi rannsakandi að spyrja

nánar um áhugaverð atriði sem fram komu. Reynt var að forðast það að hafa áhrif á svör

viðmælenda beint eða óbeint og var viðmælendum leyft að ræða það sem þeir vildu.

Rannsakandi reyndi að vera opinn fyrir nýjum sjónarhornum sem komu, svo lengi sem þau

töldust gagnast markmiðum rannsóknarinnar (Merriam, 2009). Rannsakandi reyndi einnig

að vera hlutlaus við túlkun á öllum gögnum.

Við val á fyrirtækjum í rannsóknina var reynt að finna fyrirtæki sem væru búin að nota

Agile aðferðir í einhver ár og væru nógu stór til að vera með stóra þróunardeild. Aðallega var

horft til hugbúnaðarfyrirtækja þar sem þau hafa mest verið að nota Agile aðferðir og því

líklegast að þau hafi þurft að skala aðferðafræðina upp eftir því sem þau stækkuðu.

Rannsakandi fékk ábendingar um fyrirtæki úr ýmsum áttum og komst í samband við mörg,

bæði í gegnum starfmenn þeirra sem rannsakandi þekkti og í gegnum víðara tengslanet

hans. Valin voru fimm fyrirtæki sem talin voru uppfylla skilyrði rannsóknarinnar um að vera

34

með 50 eða fleiri starfsmenn í teymisvinnu í sex eða fleiri teymum. Öll fyrirtækin eru íslensk

stórfyrirtæki með stórar hugbúnaðarþróunardeildir, fjögur fyrirtækjanna starfa með

viðskiptavinum bæði á Íslandi og erlendis og hafa einnig starfsmenn eða teymi staðsett á

Íslandi og erlendis. Fimmta fyrirtækið starfar eingöngu á íslenskum markaði og er með öll sín

teymi hérlendis.

Viðmælendurnir voru 13 talsins en leitast var við að taka viðtöl við þrjá aðila hjá hverju

fyrirtæki fyrir sig og reynt var að velja þá þannig að sem best heildarsýn fengist á

viðfangsefnið. Í beiðnum um viðtöl til tengiliða var tekið fram að æskilegast væri að fá viðtöl

við aðila sem hefði ákveðna yfirsýn yfir hugbúnaðarþróunarstarfið, aðila sem væri leiðtogi í

teymi eða verkefnastjóri og síðan meðlim úr teymi. Notast var við svokallaða

snjóboltaaðferð (Merriam, 2009) við öflun viðmælenda sem lýsir sér þannig að fyrst náðist

samband við einn viðmælenda sem stakk upp á öðrum viðmælendum innan fyrirtækisins.

Tvö af fyrirtækjunum óskuðu eftir því að nafnleyndar yrði gætt í rannsókninni og var því

unnið með niðurstöður allra fyrirtækjanna á þann hátt, bæði fyrirtækjunum og

viðmælendum voru gefin dulnefni sem á engan hátt tengjast þeim. Í töflu 2 má sjá hvernig

dreifing á viðmælendum varð í raun, ásamt dulnefnum þeirra og dulnefnum fyrirtækjanna.

Hjá einu af fyrirtækjunum náðist eingöngu að tala við einn viðmælanda sökum anna hjá

fyrirtækinu en ákveðið var að hafa það viðtal með þrátt fyrir takmörkun á heildarsýn.

Tafla 2 Dulnefni viðmælenda ásamt hlutverkum þeirra innan fyrirtækisins

Hlutverk Hlutverk

Alpha Zeta Axel Sviðsstjóri Daði Yfirmaður þróunardeildar

Dagur Yfirmaður verkefnastofu Ari Verkefnastjóri á verkefnaskráasviði

Birkir Verkefnastjóri teymis Þóra Verkefnastjóri í þróunardeild

Beta Delta Andri Yfirmaður þróunardeildar Aron Yfirmaður þróunardeildar

Fanney Vörueigandi (e. product owner) Danni Agile þjálfari

Dóri Teymismeðlimur Elsa Vörueigandi (e. product owner)

Sigma Finnur Yfirmaður þróunardeildar

Útbúinn var viðtalsrammi með hálfopnum spurningum fyrir viðtölin og var hann settur

upp sem tenging við fræðilegt efni til að geta sem best svarað rannsóknarspurningunum, en

uppsettan viðtalsramma má sjá í viðauka 1. Viðtalsrammanum var skipt upp í þrjá hluta,

fyrst voru spurningar almennt um fyrirtækið og uppsetningu þess, því það er gott að hafa

35

yfirsýn yfir það þegar kemur að því að fjalla um áskoranir og árangur á sviði samskipta í

uppsköluðu Agile. í öðrum hluta komu spurningar um menningu og gildi fyrirtæksins sem

líka tengjast inn á marga mikilvæga þætti við notkun á uppsköluðu Agile. Einnig miðaðist ein

af rannsóknarspurningnum að því að komast að því hvort markvisst hafi verið unnið að því

að skapa menningu sem styður Agile. Að lokum var í þriðja hlutanum farið í spurningar um

sjálfa Agile aðferðafræðina og uppskölun á henni. Þá var sérstaklega spurt um árangursþætti

og áskoranir og byrjað viljandi á áskorununum til að viðmælandinn væri ekki farinn að hugsa

sérstaklega um árangursþætti áður en hann svaraði spurninum um áskoranir, því það gæti

dregið úr viljanum til að svara því.

Spurningar um áskoranir voru settar upp mjög opnar í byrjun til að koma ekki

hugmyndum inn hjá viðmælendum. Síðan var spurt hvernig brugðist hafi verið við þessum

áskorunum og að lokum spurt sérstaklega um þá þætti sem hafa komið fram í rannsóknum

en voru ekki nefndir af viðmælanda. Vert er að hafa í huga að þessi aðferð, með að minnast

á þá þætti sem ekki komu fram, gæti mögulega hafa litað svör viðmælenda en rannsakanda

þótti áhugavert að hafa þessa þætti með og þá sérstaklega til að fá skoðanir viðmælenda á

þeim. Sami háttur var hafður á varðandi spurningar um árangursþætti, að byrjað var á

opinni spurningu um þá en flestum viðmælendum þótti spurningin of stór eða skildu hana

ekki nógu vel til að geta svarað. Rannsakandi hafði því þann háttinn á að gefa dæmi um

atriði sem gæti bæði verið árangursþáttur eða áskorun en það var þáttur sem sneri að opnu

vinnurými. Rannsakandi gætti þess að vera alltaf með sama dæmi til lita ekki niðurstöður um

of. Í framhaldi af þessu var spurt hvort viðmælandi gæti nefnt aðra árangursþætti. Að lokum

voru nefndir þeir þættir sem komið hafa fram í rannsóknum en komu ekki fram í viðtalinu og

spurt hvort hugsað hafi verið sérstaklega út í þá og þá hvers vegna ekki hafi verið valið að

nota þá ef sú var raunin. Með þessu var ætlunin að fá fram hvort einhverjir að þeim

árangursþáttum sem nefndir hafa verið í fyrri rannsóknum eigi ekki við hjá þessum

fyrirtækjum eða hafi ekki reynst vel.

Öll fóru viðtölin fram í fundarherbergi á vinnustað viðmælanda að einu undanskyldu sem

var tekið á kaffihúsi og voru þau á bilinu 40-60 mínútur að lengd, utan eins sem var 74

mínútur.

36

4.2 Takmarkanir

Takmörkun felst í því að rannsakandi hafði kynnt sér vel Agile aðferðir og áskoranir og

árangursþætti uppskölunar áður en hann tók viðtöl við viðmælendur og hafði sínar skoðanir

á efninu. Rannsakandi undirbjó sig því til þess að svara og bregðast við svörum viðmælenda

eins í gegnum öll viðtölin hvort sem rannsakandi var sammála viðmælanda eða ekki og tókst

það heilt yfir ágætlega.

Í rannsókninni felst ákveðin takmörkun í að ekki reynist unnt að alhæfa um niðurstöður

þar sem einungis fimm íslensk hugbúnaðarfyrirtæki voru skoðuð og ekki hægt að yfirfæra

þeirra niðurstöður á öll íslensk hugbúnaðarfyritæki. Markmiðið er því mun fremur að auka

skilning á aðferðum og árangri þeirra fyrirtækja sem tóku þátt í rannsókninni. Til að reyna að

ná sem bestri heildarmynd á starfi hugbúnaðardeildanna bað rannsakandi um að fá að ræða

við aðila með yfirsýn yfir þróunardeild, verkefnastjóra í teymi eða Agile þjálfara og síðan

teymismeðlim til að fá mismunandi sjónarhorn á Agile starfið. En þar felst takmörkun því að

innan eins fyrirtækisins var einungis rætt við einn einstakling í stað þriggja og það er ekki víst

að þessi aðili hafi getað gefið þá réttu heildarmynd sem leitað var eftir og var tekið tillit til

þess í úrvinnslu niðurstaðna. Ásamt þessu má nefna að eingöngu hjá einu fyrirtæki fékkst

viðtal við teymismeðlim en rannsakandi telur að þrátt fyrir að markmiðið hafi ekki náðst, um

það að tala alls staðar við teymismeðlim, hafi það ekki skekkt heildarmyndina.

Takmörkun gæti verið fólgin í því að notuð var snjóboltaaðferð til að finna viðmælendur

innan fyrirtækjanna. Takmörkunin væri þá fólgin í því að fyrsti tengiliður inn í fyrirtækin var

yfirleitt yfirmaður sem benti svo í framhaldi á undirmenn sem hægt væri að taka viðtal við. Í

þessu ferli gætu bæði undirmenn og yfirmenn gætt orða sinna af vitneskju um að

samstarfsmenn þeirra myndu sjá ummæli þeirra og skoðanir. Rannsakandi gerði ráðstafanir

til að koma í veg fyrir þetta með því að tjá viðmælendum að nafnleyndar yrði gætt og

fyrirtækin ásamt viðmælendunum kæmu öll fram undir dulnefnum í niðurstöðum

rannsóknarinnar.

Valið á fyrirtækjum getur eins flokkast sem takmörkun en það eru ekki mjög mörg

fyrirtæki á Íslandi með nógu stórar hugbúnaðarþróunardeildir til að passa inn í rannsóknina.

Rannsakandi þurfti að nýta sér sitt tengslanet til að komast í samband við þau fyrirtæki sem

komu til greina en nokkur svöruðu ekki eða höfðu ekki áhuga á að taka þátt. Þar sem

rannsakandi þurfti að nýta sér tengslanet sitt til að nálgast viðmælendur gerði hann

37

ráðstafanir til þess að tala ekki við þá einstaklinga sem tengdu hann inn í fyrirtækið eða hann

þekkti persónulega til að ná að viðhalda hlutleysi.

4.3 Greining og meðferð gagna

Framkvæmd voru viðtöl sem voru hljóðrituð og afrituð við fyrsta tækifæri yfir í textaskjal.

Notast var við opna kóðun til að vinna úr viðtölunum og við greiningu gagna. Merriam

(2009) skilgreinir kóðun sem kerfisbundna uppröðun efnis svo auðveldara sé að greina

mismunandi inntak úr gögnum. Kóðun getur verið á ýmsan hátt, með orðum, frösum,

tölustöfum, bókstöfum, litum eða samblandi af þessum flokkum. Í þessari rannsókn var

ákveðið við úrvinnslu gagna að notast við litakóða. Ákveðin þemu og undirflokkar voru

skilgreind út frá opnu kóðuninni og í kjölfarið voru viðtölin litakóðuð til að auðvelda frekari

vinnslu. Öll voru viðtölin nothæf við úrvinnslu rannsóknarinnar að mati rannsakanda og út úr

kóðuninni komu nokkur þemu sem þóttu falla best að niðurstöðum viðtalanna.

Yfirþemun voru fimm og eru þau skýrt útlistuð í upptalningu hér að neðan. Fyrsta þemað

sneri að uppsetningu Agile hjá íslenskum hugbúnaðardeildum og undirflokkurinn aðferðir

uppskalaðs Agile var greindur. Viðmælendur lýstu uppsetningu fyrirtækja sinna og hvernig

notast var við aðferðir uppskalaðs Agile í samhengi við þá uppsetningu og þótti rannsakanda

þetta vera mikilvægur þáttur til að svara einni af rannsóknarspurningunum. Einnig lagði

þetta grunninn fyrir ályktanir í samhengi við aðra þætti. Annað þema var innleiðingarferli, en

það kom í ljós að það vóg þungt í aðferðum uppskalaðs Agile hvernig staðið hafði verið að

innleiðingu þess. Undirflokkarnir sem voru greindir við þetta þema voru tilraunaaðferð og

ábyrgðir og hlutverk, en þeir tengdust helstu áskorunum og árangursþáttum sem greindir

voru í tengslum við innleiðingu. Þriðja þemað var heildaryfirsýn en hún reyndist vera

mikilvægur þáttur í Agile starfi fyrirtækjanna, undirflokkar tengdir heildaryfirsýn voru

fastmótað ferli, flóknar kröfur, fjarlægð frá viðskiptavini og mælingar og áætlanir. Þessir

undirflokkar þóttu best lýsandi fyrir þá þætti sem ýta undir eða draga úr heildaryfirsýn.

Fjórða þemað var skipulag samskipta en í fjölteyma umhverfi er þessi þáttur áberandi þar

sem fram kom að fyritækin voru leitandi við að finna gott skipulag samskipta í Agile á svo

stórum skala. Undirflokkur þar var vinnurými en rannsakandi nefndi það sérstaklega þegar

hann spurði um árangursþætti til að skilgreina spurninguna betur. Fimmta þemað var svo

hlutverk fyrirtækjamenningar í uppsköluðu Agile en bæði var leitast við að finna hvort

fyrirtækjamenning hefði áhrif á starfsemi uppskalaðs Agile og einnig hvort Agile

38

hugmyndafræði hefði náð inn í heildarmenningu fyrirtækjanna. Undirflokkur sem kom fram

þar sneri að dreifðum teymum en reynt var að sjá hvort slík teymi hefðu mikil áhrif á

menningu fyrirtækjanna. Samandregin uppsetning þemanna er því eftirfarandi:

Uppsetning Agile hjá íslenskum hugbúnaðardeildum

o Aðferðir uppskalaðs Agile

Innleiðingarferli

o Tilraunaaðferð

o Ábyrgðir og hlutverk

Heildaryfirsýn

o Fastmótað ferli

o Flóknar kröfur

o Fjarlægð frá viðskiptavini

o Mælingar og áætlanir

Skipulag samskipta

o Vinnurými

Hlutverk fyrirtækjamenningar í uppsköluðu Agile

o Dreifð teymi

4.4 Réttmæti og áhættumat rannsóknar

Í eigindlegum rannsóknum þarf að tryggja áreiðanleika og réttmæti en til þess er

nauðsynlegt að sjá til þess að rannsóknin sé framkvæmd eftir siðfræðilegum gildum og

háttvísi. Rannsóknaraðferð þarf að vera skýr, skilningur á viðfangsefni góður og niðurstöður

settar fram á markvissan hátt (Merriam, 2009). Reynt var að tryggja áreiðanleika í þessari

rannsókn með því fara í gegnum fjölda fræðilegra heimilda og afla upplýsinga þaðan til að

rannsakandi væri sem best upplýstur um efnið. Einnig var stuðst við myndbönd og

skýringamyndir af netinu til að rannsakandi næði dýpri þekkingu á efninu. Rannsóknaraðferð

og áætlun var skipulögð í upphafi og henni fylgt út ferlið.

39

5 Niðurstöður

Með rannsókninni var ætlunin að kanna hvort stórar hugbúnaðardeildir í íslenskum

fyrirtækjum noti eða hafi kynnt sér aðferðir uppskalaðs Agile. Einnig hvaða þættir í þeim

aðferðum sem þau notast við hafa skilað þeim árangri og hvaða áskoranir þau hafa glímt við

í tengslum við slíka uppskölun. Umgjörð Agile aðferðafræðinnar var í raun upphaflega

hönnuð með eitt teymi í huga og því hafa fyrirtæki sem hafa stækkað úr einu teymi þurft að

búa sér til ákveðinn ramma til að halda utan um fleiri teymi í Agile starfi. Þær aðferðir

uppskalaðs Agile sem fjallað var um hér að ofan virðast ekki hafa náð mikilli útbreiðslu hér á

landi en þau fyrirtæki sem fjallað er um í rannsókninni hafa þróað sínar eigin aðferðir til að

halda utan um starfsemi í fjölteyma umhverfi. Tvö fyrirtækjanna hafa þó byggt sína aðferð í

grunninn á þeirri aðferð sem Spotify þróaði hjá sér til að takast á við uppskalað Agile.

Einnig verður fjallað um það hvort fyrirtækin hafi innleitt eða kynnt Agile hugmyndafærði

í fyritækið í heild og skoðað hvernig það tengist menningu og bakgrunni þess.

5.1 Uppsetning hjá stórum íslenskum hugbúnaðardeildum

Við skoðun á uppsetningu og aðferðafræði fyrirtækjanna kom í ljós að þau hafa öll skipt

starfsemi sinni niður á sérstök svið eða ættbálka sem miðast út frá ákveðnum vörum. Teymi

þeirra eru ýmist hluta- eða þáttamiðuð á þann hátt að þau þróa annað hvort tiltekinn þátt

eða vöruhluta sem passar inn í allar þær vörur sem tilheyra sama sviði eða ættbálki. Með

þessari uppsetningu fyrirtækjanna virðist myndast einskonar sjálfsprottin samstaða

starfsfólks innan sviða eða ættbálka, þrátt fyrir að tilgangurinn með uppsetningunni sé hjá

flestum að ná samvinnu þvert á vörurnar.

Fyrirtækin í rannsókninni skipta þróunarhluta sínum í tvær til fjórar vörur eða lausnir sem

unnar eru af tveimur til fimm teymum hver. Miðað við þetta falla þessar stóru íslensku

hugbúnaðarþróunardeildir ekki undir skilgreiningu uppskalaðs Agile eins og Dikert o.fl.

(2016) skilgreindu hana þannig að unnið sé í sama verkefni með að minnsta kosti sex teymi

eða 50 manns. Ef fleiri en eitt teymi er hins vegar farið að vinna að sömu vöru kemur í ljós að

það þarf að huga að samræmingu og samvinnu og öllu því sem í raun fylgir uppsköluðu

Agile. Það kom líka fram að þrátt fyrir þessa vörumiðuðu skiptingu fyrirtækjanna er

nauðsynlegt að huga að samræmingu og heildarsýn til að átta sig á þeim skörunum sem

verða milli varanna.

40

Mun á uppsetningu fyrirtækjanna fimm má sjá hér í töflu 3 en þar sést hvernig fyrirtækið

Alpha sker sig úr hópnum þar sem viðskiptavinir Agile teyma þeirra eru aðallega

endanotendur og er það mjög þjónustumiðað fyrirtæki. Hin fyrirtækin eru mun

vörumiðaðari og þróa flest grunnhugbúnað sem hentar fjöldanum sem er svo í einhverjum

tilfellum þróaður áfram af samstarfsaðilum. Andri hjá Beta lýsir þessu vel: „Þannig að við

þurfum að halda fókus á að við þurfum að búa til vöru sem hentar flestum.“

Tafla 3 Munur á fyritækjum og Agile aðferðum þeirra

Alpha Beta Delta Zeta Sigma

Tekjufókus Þjónustu-

miðað Vörumiðað Vörumiðað Vörumiðað Blandað

Teymisfjöldi 15-20 13 8 13 4

Helstu viðskiptavinir

Agile teyma Endanotendur

Samstarfs-aðilar

Blandað Innanhúss Blandað

Uppskalað Agile grunnur

Eigin aðferð Eigin aðferð Spotify Spotify Eigin aðferð

Hluta eða þáttamiðuð

teymi Þáttamiðuð Blandað Blandað Blandað Þáttamiðuð

Föst aðferð eða sjálfstýrð

teymi Sjálfstýrð Föst Sjálfstýrð Föst Sjálfstýrð

Fundaáætlun Já Já Já Já Já

Vöxtur Miðlungs Hraður Hraður Hraður Hægur

Bakgrunnur Samsett Samsett Sjálfstætt Dótturfélag Klofningur

Agile grunnur Nei Nei Nei Nei Já

Ákveðin líkindi eru samt með Alpha og Beta að því leyti að þau eru bæði samsett úr

mörgum litlum fyrirtækjum. Delta byrjaði sem lítið fyrirtæki og hefur vaxið hratt núna á

undanförnum árum og hefur Agile starf stækkað með þeim vexti, sama má segja um Zeta og

Sigma en þau voru fyrst hluti af öðru fyrirtæki og urðu svo sjálfstæð. Daði yfirmaður

hugbúnaðarþróunar hjá Zeta lýsir vaxtarferlinum:

41

Við erum svona pínulítið eins og barn sem var sett í heimavistarskóla, vorum

svona lítil og sæt inni í (móðurfélaginu) og hlýddum bara því sem það sagði svo

þegar við komum hingað þá erum við farin að móta okkar eigin skoðanir, okkar

eigin vinnubrögð, okkar eigin persónuleika sem fyrirtæki og svo komum við heim

eftir kannski tvö, þrjú ár og ég er ekkert viss um að (móðurfélagið) þekki okkur

sem sömu lítlu deildina sem fór að heiman. (Daði)

Teymin eru alls ekki föst hjá fyritækjunum þrátt fyrir að þau leitist við að reyna að halda

þeim þannig því föst teymi ýta undir traust og samvinnu, en aftur á móti getur

þekkingarmiðlun orðið meiri ef teymi eru ekki föst. Birkir hjá fyrirtækinu Alpha segir frá flæði

fólks á milli teyma: „Ef það er kannski orðið minna af verkefnum einhvers staðar að þá

kannski þarf að færa á milli.“ Fyrirtækið Alpha vinnur mestmegnis með útselda tíma en

einnig með útboðsverkefni og er því mikilvægt fyrir það að nýta tíma starfsfólks vel. Hin

fyrirtækin eru ekki bundin þessu en þurfa þó að sjálfsögðu að huga að nýtingu tíma

starfsfólks og er því oft hreyfing á teymunum. Dóri kemur inn á þetta þegar hann lýsir

daglegri uppsetningu síns teymis í fyrirtækinu Beta á þennan hátt:

Við sitjum öll þétt þannig að við erum til dæmis með þrjá og þrjá sem að snúa

baki í hvern annan þannig að það er auðvelt að snúa sér við en svo erum við

reyndar orðin það mörg að þetta eru orðin tvö sett. (Dóri)

Fyrirtækið Sigma skilgreinir sig enn sem sprotafyrirtæki þrátt fyrir að vera orðið stórt og

margra ára gamalt, en það er vegna þess að það er ekki búið að finna fjölina sína eins og

Finnur, yfirmaður hugbúnaðarþróunar þar, orðar það. Fyrirtækið er því talsvert oft að breyta

áherslum og skipulagi og ítra aðferðir hjá sér en það er eina fyrirtækið sem hóf sína

starfsemi sem Agile teymi.

5.1.1 Aðferðir uppskalaðs Agile

Það kom í ljós í viðtölunum að nokkrir viðmælendanna þekktu sumar af þessum aðferðum

uppskalaðs Agile eins og SAFe, SoS og Spotify módelið. Öll fyrirtækin virtust vera að nota

einhverja þætti úr þessum aðferðum en hafa í raun þróað sína eigin aðferð sem hentar

þeirra aðstæðum og uppsetningu. Það að aðlaga aðferðir að starfsemi sinni hefur einmitt

verið nefndur sem einn af aðalárangursþáttum þess að taka upp uppskalaða Agile starfsemi í

skipulagðri yfirferð fræðilegra rannsókna (Dikert o.fl., 2016). Starfmenn sem rætt var við hjá

fyrirtækjunum voru mjög vel meðvitaðir um þá hlið Agile að vera sveigjanlegur og sífellt að

42

endurskoða aðferðir, ferla og vinnulag. Mörg voru fyrirtækin í endurskipulagningu eða

nýbúin að fara í gegnum slíkt ferli vegna stækkunar eða hagræðingar. Það kom í ljós ákveðin

tenging milli þess að fyrirtæki hafi stækkað hratt og þess að festa starfsemina í meiri ferla og

fá meiri formfestu í teymin til að ná utan um þá heildaryfirsýn sem þarf að hafa, sérstaklega í

þessu fjölteyma umhverfi.

Sigma, sem skilgreinir sig sem sprota, fór nýlega í gegnum endurskipulagningu og segir

Finnur:

Fyrirtækið fór í svona naflaskoðun... og þar voru aðilar héðan og ekki þá bara

einhverjir yfirmenn heldur fólkið sem er actually að vinna í verkefnunum... til að

einfalda samskiptalínur og hvernig væri hægt að, já endurskipuleggja svolítið

hvernig við vinnum. (Finnur)

Fyrirtækið Zeta hefur á undanförnu ári stækkað þróunardeild sína gríðarlega og hefur

fundið fyrir ákveðnum vaxtaverkjum samhliða þeirri stækkun. Mikil endurskipulagning hefur

átt sér stað þar og settur hefur verið upp sérstakur stuðningur við verkefnastjórnun og

einnig Agile stuðningur, eða eins og segir Daði frá því: „…guide-a teymunum svolítið í

þessum vinnubrögðum sem við viljum halda.“ Þar var einnig farið í umbótaverkefni á

þróunarferlinum í samvinnu við teymin og en þar kom fram að mest væri kallið að einfalda.

Delta er í stórri uppstokkun og eru meðal annars með aðstoð Agile ráðgjafastofu að setja

upp ný teymi. Í því fyrirtæki er góður stuðningur við Agile, þar er Agile þjálfari sem styður við

þróunarteymin og vel er haldið utan um „Scrum Master-a“ og vörueigendur, eða eins og

Aron segir: „Svo hef ég verið leiða þetta network af Scrum Masterum og leggja línur með

samræmd vinnubrögð.“ Fyrirtækið gefur teymum sínum frjálsar hendur með val á aðferðum

í teymisvinnunni, en fylgja þarf ákveðnum fundaramma sem er í takt við Scrum aðferðina.

Vörueigendum hjá Delta hefur verið gefið frelsi til skipuleggja sjálf sína samræmingu sem

þeir hafa gert í formi sjálfsprottinna funda.

Að leyfa teymum að skipuleggja sig sjálf er einn að árangursþáttum uppskölunar á Agile

(Dikert o.fl., 2016). Þennan háttinn hafa Alpha, Delta og Sigma haft á hjá sér og verið

sammála um að eigi þátt í árangri Agile starfs. Möguleg ástæða aukins sjálfstæðis teyma

þessara fyrirtækja er að þau eru að einhverju leyti í sambandi við endanotendur en mis

mikið þó. Einnig má tengja val fyrirtækjanna á sjálfsstjórn teyma við það að vöxtur þeirra

hefur ekki verið of hraður, að Delta undanskildu, þar sem ástæðan gæti legið fremur í

43

samkeppnissjónarmiðum. Hjá Alpha er Agile tilkomið að mestu leyti frá einum starfsmanni

upp úr ákveðinni grasrót sem er líkleg til að styðja sjálfstjórn teyma. Sigma var upprunalega

eitt Agile teymi og hefur vaxið hægt og því auðveldara fyrir það að gefa teymum sínum

sjálfsstjórn. Delta er fyrirtæki sem er í mikilli samkeppni og þarf að ná fram samvinnu og

nýsköpun í sínu starfi, þess vegna er líklegt að það velji, eins og hin tvö, að valdefla sín teymi

með sjálfsstjórn.

Hjá Delta segir Aron þetta: „Það er þetta sjálfstæði og sjálfskipulagning, að hún ýtir undir

meiri ánægju í starfi.“ Elsu, sem hefur hlutverkið vörueigandi, finnst þetta hjálpa: „Það eru

sumir sem vilja bara vera í Scrum, þá geta þeir bara, fá þeir að vera í Scrum, þá er það ekkert

vandamál og mér finnst það alveg bara mjög mjög mikilvægt“. Hún heldur áfram: „Það er

enginn fastur í einhverju fari þannig að ef eitthvað er ekki að virka að þá bara prófum við

eitthvað annað.“ Hjá Alpha eru teymin einnig sjálfskipulögð og hafa margir í teymunum

unnið lengi saman og hafa þróað með sér hvernig þau vilja gera hlutina, Axel segir frá þessu:

„Teymin sjá um að sinka sig sjálf og deildarstjóranir þá þetta er orðið svona slípað, þú veist,

búið að vera í mörg ár eða þannig, og þau sitja á sama gólfi“. Hjá Sigma sjá teymin um að

skipuleggja sig í kringum þær grunnreglur sem eru til staðar og þau hafa sjálf búið sér

verklagsregur (e. standard operating procedures) sem þau vinna eftir.

5.2 Innleiðingarferli

Vegna þess hversu hratt hluti fyrirtækjanna hefur vaxið á undanförnum misserum hafa þau í

raun þurft að innleiða uppskalað Agile mjög hratt og fundið fyrir hinum ýmsu vaxtarverkjum

samhliða því. Við það að þurfa að innleiða uppskalað Agile hratt hafa fyrirtækin þurft að vera

mjög agile, eða lipur, og fylgja einu af grunnhugtökum Agile sem er að einbeita sér að því að

bregðast við fremur en að fylgja áætlunum. Öll hafa fyrirtækin verið að bregðast við

breytingunum í innleiðingarferlinu þegar þær gerast og ekki farið af stað með of mikla

áætlun. Aftur á móti má segja að eftir því sem lengra líður á innleiðinguna hafi fyrirtækin

fundið þörf fyrir að festa ákveðna hluti í ferla til að ná heildaryfirsýn. Þetta getur valdið því

að erfiðara verður að halda í öll grunnatriði Agile hugmyndafræðinnar. Beta og Sigma eru

komin á þann stað í dag að þau ekki föst í of miklum ferlum. Það hefur dregið úr vexti Beta

og það náð ákveðnum þroska í sínu Agile starfi. Vaxtarferill Sigma var aftur á móti frekar

hægur og því hefur verið auðveldara að viðhalda yfirsýn í þeirra starfi. Alpha, Zeta og Delta

44

eru stödd í miðjum breytingarfasa þar sem þau eru að reyna að ná þessari heildaryfirsýn

sem þau vilja hafa.

Það kemur fram að í svona hröðum vexti komi margir nýir inn í einu og þurfi því að reyna

að miðla þekkingu til þeirra um kerfin og vöruna fljótt og vel. Til þess að það takist er

teymisvinna og samvinna mjög mikilvæg og hafa fyrirtækin leyst þetta með ýmsum hætti.

Hjá Zeta fara reyndir starfsmenn á milli teyma eftir þörfum og hjá Alpha eru þessir aðilar

jafnvel með reglulega 15 mínútna viðtalstíma.

Andri hjá Beta segir að á sínum tíma hafi það að uppskala Agile aðferðir hratt tekið á en

að fyrirtækið sé að ná ákveðnu jafnvægi núna. Hann segir einmitt ákveðna takmörkun fólgna

í því að skala upp Agile á þennan hátt: „Það fylgir því að þegar þú ert að stækka að þú þarft

svolítið að fara að formfesta hlutina, þú getur ekki verið alveg eins agile.“ Þrátt fyrir að Beta

hafi verið að vinna samkvæmt Agile áður var það á mun minni skala og þar með óþarfi að

vera með mikið af ferlum. Andri segir tilganginn með ferlunum í kringum uppskölunina hafa

verið samvinna, hann segir: „Í rauninni, mitt mission var að reyna að fá alla til þess að vinna

saman og reyna bara að búa til einhvern vegin skipulag þar sem að við fengjum sem mest út

úr því að að vinna saman.“

Elsa og Aron hjá Delta tala um ýmsar áskoranir sem þau hafa þurft að takast á við í sínum

hraða vexti en meðal þeirra er að margir nýir séu á sama tíma og ábyrgðir skolast til, en

einnig að með stærri uppsetningu hafi boðleiðir lengst. Elsa er á báðum áttum varðandi

þessa tilhögun og segir:

Búið að lengja boðleiðir með því að setja upp tribe-in, fara bara langar leiðir og

tekur langan tíma að vinna úr hlutum, samt er þetta svo fyndið, svo er ég samt

ótrúlega ánægð með tribe hugmyndina. (Elsa)

Vaxtaverkir Zeta, sem byrjaði sem lítil deild inni í ferladrifnu móðurfélagi, hafa verið

margþættir en hugbúnaðarþróunardeild þess hefur stækkað gríðarlega ört á einu ári. Daði

nefnir nokkra þætti, eins og að verkefnastjórnun á verkefnaskráasviði hafi ekki vaxið eins

hratt eða ekki nóg til að halda í við þróunardeildina. Það vantar upp á sýnileika og miðlun

milli teyma, á því hvað fólk er að gera inni í teymunum og það vantar að dreifa þekkingu á

skipulagðan hátt. Daði orðar það á þennan hátt þegar hann greinir frá því hvernig þau reyna

að takast á við þess áskorun:

45

Við erum kannski svolítið að reyna að vinna í því að gera þekkinguna skalanlegri,

hvort sem það er með skjölun eða með video eða eins og ég segi með tech talk-

um sem eru vikulega, þau eru alltaf tekin upp. (Daði)

Þekking á vörunum og ferlunum er þarna komin á hendur fárra og telur Ari að

teymisvinna sé ákveðin lausn á því: „Það eru líka verkefni sem eru þess eðlis í dag að þau eru

stór, þau eru flókin, þau eru ný, það er nýtt fólk, þú þarft bara meiri teymisvinnu“.

Þarna kemur fram mikilvægi samvinnu í að vinna hraðar og betur og þykir nauðsynlegt

að traust ríki til að ná fram góðri samvinnu. Samskipti verða að sama skapi auðveldari sem

leiðir af sér betri þekkingu og betri vöru.

5.2.1 Tilraunaaðferð og breytingar

Tilraunaaðferð og breytingar eru áhersluþættir í Agile hugmyndafræðinni en hvatt er til þess

að stöðugt sé verið að ítra aðferðir og prófa sig áfram með hvað virkar og hvað virkar ekki.

Þetta er frekar auðvelt að gera þegar einungis er um að ræða eitt teymi sem hagar vinnu

eftir sinni hentisemi. Þegar komið er í uppskalað Agile með mörgum teymum er þetta orðið

erfiðara. Samkvæmt niðurstöðum Rigby o.fl. (2018) skilar það árangri ef innleiðing

uppskalaðs Agile tekur stöðugum breytingum eftir því hvað eykur virði og árangur

starfmanna. Þarna kemur fram spurningin um hvort teymin eigi að ítra sínar aðferðir sjálf

eða hvort betra sé að öll teymin sem heild ítri þær aðferðir sem lagðar hafa verið fyrir þau.

Þetta hafa fyrirtækin verið að takast á við á mismunandi hátt, Zeta ákvað að fara leiðina þar

sem öll teymin sem heild ítra aðferðir sínar en Delta, Alpha og Sigma hafa aftur á móti meira

lagt ábyrgðina í hendur teymanna en þau eru sjálfstýrð hjá þeim. Beta byrjaði með sjálfstýrð

teymi en hefur fært sig í fasta aðferð fyrir teymin sem þó ítra sínar aðferðir sjálf, sem ber í

raun vitni um það jafnvægi sem Beta hefur náð í sínu uppskalaða Agile.

Til að takast á við hraða uppskölun á Agile á sínum tíma segir Andri teymin hjá Beta hafa

fært sig sjálf í að vinna Scrum eftir bókinni: „Lásum bara official Scrum guide og svo bara

gerum þetta svona og sjáum hvað gerist“. Aðferðin virkaði vel fyrir teymið og smitaði út frá

sér til hinna teymanna. Hér hefur Beta notast við tilraunaaðferð í þróun á sinni aðferð og

verklagi við uppskalað Agile í gegnum árin en það er í takt við það sem Paasivaara o.fl.

(2018) komust að, við innleiðingu uppskalaðs Agile hjá Ericsson, að virkaði vel. Andri segir

einnig: „Ég held að við höfum svolítið bara lært af reynslunni og svona fundið bara hvað

46

virkaði“ og Fanney sem er vörueigandi segir: „Þetta er allt lifandi, þetta er allt dýnamískt og

við erum alltaf að reyna að bæta okkur.“ Fanney bætir við:

Umhverfið okkar er að þróast, við erum að þróast, við verðum kannski aðeins

straumlínulagaðri og stundum prófar maður alveg þrjá hluti þú veist maður veit

alveg að maður mátar sex pör af skóm áður en maður finnur þá sem manni líkar

við, við erum alltaf að máta. (Fanney)

Andri lýsir á léttu nótunum hversu vant fólk er orðið breytingum: „...og á tímabili var bara

kvartað yfir því eða ekki kvartað, talað um, eru engar breytingar í þessum mánuði?“

Innleiðing Alpha á nýjum verkefnastjórnunarferli má segja að sé einnig eftir ákveðinni

tilraunaaðferð því þessi nýi ferill hefur fyrst verið tekinn upp í einni deild sem nokkurs konar

prufuverkefni áður en hann verður svo yfirfærður á allar deildir. Erfitt er að segja hvort það

muni skila árangri þar sem enn er að verið að vinna með hann í þessari einu deild.

Breytingar virðast vera daglegt brauð í uppsköluðu Agile, hættan við þetta er að fólk missi

fókus og áhuga ef sífellt er verið að hringla með vinnuferla, sérstaklega fyrir allan hópinn.

Mikilvægt er því að starfsfólk sé haft með í því að ítra aðferðir og að með samvinnu séu

fundnar betri leiðir að hlutunum.

Endurskipulagning kemur mikið fram hjá öllum fyrirtækjunum og er það í takt við Agile

hugmyndafræðina um að vera sífellt að skoða og þróa aðferðir sínar og gera betur en síðast.

Þetta kemur fram í því að mikið er um breytingar og getur það auðveldlega þróast út í það

að stöðugleiki verði ekki nægur og þá komi jafnvel fram ákveðið óöryggi, ásamt því að

hlutverk og ábyrgðir geta orðið óljósar.

5.2.2 Ábyrgðir og hlutverk

Eitt af því sem breytingar og endurskipulagning hafa í för með sér eru breytt hlutverk og

breyttar ábyrgðir en Dikert o.fl (2016) settu einmitt fram að oft vantar að hlutverk

millistjórenda í uppsköluðu Agile séu skýrari. Í samræmi við þetta er ákveðið óöryggi sem

hefur skapast vegna óljósra ábyrgða og skörunar á hlutverkum, sérstaklega hjá þeim

fyrirtækjum sem hafa innleitt uppskalað Agile sem hraðast, eins og hjá Zeta og Delta en

einnig hjá hinum að einhverju marki. Styst er síðan Zeta og Delta fóru í gegnum hraðan vöxt

og má tengja óöryggi við það en líka að á sama tíma var aðferð Spotify innleidd hjá þeim að

hluta. Samkvæmt Spotify líkaninu eru settir upp vörumiðaðir ættbálkar sem eiga að vera

47

þvert á deildir en slík hugsun er öðruvísi en sú deildarskipta hugsun sem vaninn er að vinna

út frá. Vegna þessa má segja að fyrirtækin hafi verið að glíma við óskýrar línur og

aðgreiningar á hlutverkum á verkefnasskráastigi eða á því stigi sem er fyrir ofan teymin og

sér um samræmingu verkefna. Ekki er minnst á þetta vandamál hjá Alpha en það sker sig úr

að því leyti að þar er unnið með hefðbundnar deildir. Það má segja að línur þar um ábyrgðir

og hlutverk séu skýrari því þær fylgja þessum hefðbundnu fyrirtækjahlutverkum. Sigma og

Beta hafa starfað lengur í uppsköluðu Agile og því komin meiri reynsla og þekking á hvar

ábyrgðir liggja og hvaða hlutverki hver gegnir. Þau eru þó alltaf að ítra sínar aðferðir og

hlutverk þar með því að breytast, en þetta veldur alltaf einhverri óvissu og óöryggi.

Ari hjá Zeta nefnir að hann sé að fara ásamt öðrum á verkefnaskráasviði í vinnustofu til

að skerpa á þessum þáttum, hann segir: „Vegna þess að það dálítið óljóst núna, við erum

bara í verkefnum og það eru dálítið margir kokkar í eldhúsinu.“ Eins og áður sagði glíma fleiri

fyritæki við þessa áskorun og segir Aron hjá Delta hlutverk og ábyrgðir á verkefnasskráasviði

vera óljósar: „Það er ákveðið tómarúm sem enginn er að stíga inn í“ segir hann. Elsa,

vörueigandi hjá Delta segir líka að vegna þess hversu miklar breytingar hafi orðið undanfarið

hafi komið upp sú staða að hutverk og ábyrgðir séu á reiki. Hún segir þetta hafa haft áhrif á

menninguna og að það sé ákveðið gap milli ættbálkanna, hún lýsir þessu svona: „Mér finnst

það er alveg mjög eitrað epli þegar það kemur upp og mér finnst þetta meira vera sko, þú

veist battle á milli tribe-a, en innan tribe-sins eru allir boðnir og búnir að hjálpast að.“

Hjá Beta skarast hlutverk og ábyrgðir einnig að einhverju leyti en þar keyra öll teymi

Scrum aðferðina þar sem ákveðnum hlutverkum hefur verið breytt. Svokallaðir „Scrum

Matster-ar“ hafa verið teknir út og sinna vörueigendur að einhverju leyti þeirra hlutverki.

Fanney sem er vörueigandi og Dóri teymismeðlimur eru sammála um að þó að starfið gangi

vel, vanti þetta hlutverk, Dóri segir sína skoðun:

Mér finnst það kannski svona hlutur sem vantar en það erfitt að koma því inn hjá

stjórnendum af hverju, í mínum huga eiga þeir að draga teymin í áfram, ég óttast

það að við þróumst hægar með að vera ekki með Scrum Master. (Dóri)

Fanney segir: „Við erum meðvituð um þetta og leysum þetta bara ... það er ekki teymisins

að reka erindi út um allar trissur“

48

5.3 Heildaryfirsýn

Rauði þráðurinn hjá viðmælendunum má segja að hafi verið heildaryfirsýn og hvernig þau

flest eru að reyna að ná henni. Sérstaklega kom það fram hjá þeim sem eru hærra uppi í

skipuritinu hversu erfitt það getur verið að hafa góða yfirsýn. Það má segja að yfirsýn sé

mikilvæg í hugbúnaðarþróun því það getur verið erfitt að átta sig á þeirri virðissköpun sem á

sér stað en slíkt starf er kostnaðarsamt og hættan við að tapa yfirsýn er að kostnaður við

starfið verði meiri en það virði sem það skapar.

Ýmislegt í aðferðum fyrirtækjanna er að hjálpa þeim við að öðlast yfirsýn en flestir nefna

að það ferli sem þau hafi búið sér til ýti undir fókus og betri heildaryfirsýn. Hjá þeim

fyrirtækjum sem eru styttra á veg komin í noktun á uppsköluðu Agile, eins og Alpha, eða eru

enn að ná tökum á sínum hraða vexti, eins og Delta og Zeta, kom fram ákveðinn skortur á

yfirsýn. Þessi fyrirtæki eru að ganga í gegnum breytingar og endurskipulagningar en það er

ljóst að á slíkum tímum er heildaryfirsýn nauðsynleg en erfitt að ná.

Alpha tekst á við talvert gap milli sviða og leitast eftir því að ná yfirsýn yfir öll sín kerfi.

Dagur, yfirmaður verkefnastofu nefnir þetta: „…helst að geta verið með einhvern sem við

köllum lykilráðgjafa sem er svona með more or less ráðgjöfina í öllum kerfunum en það er

oft erfitt, við erum ekki með marga ráðgjafa sem hafa þess breidd.“ Hjá Delta kemur fram

þessi skortur á yfirsýn og segir Aron þeirra stærstu áskoranir snúa að vinnuskipulagi og

skýrleika á næsta stigi fyrir ofan teymin, þ.e. verkefni sem eru unnin þvert á teymi og í

samvinnu við aðrar deildir. Hann segir að það vanti að hugsa ferlið alla leið, eða eins og hann

orðar það: „from concept to cash.“

Birkir, deildarstjóri og leiðtogi teymis, hjá Alpha segir mikinn mun eftir að teymið hans fór

að vinna í Scrum, hann segir bæði yfirsýn og fókus orðinn mun betri: „Já líka bara svona til

að halda fókus... ef þú skoðaðir sprettborðið þá var bara ómögulegt að sjá í hverju fólk var

að vinna.“ Þetta flæðir upp skipuritið því að á stjórnendastigi segir Axel, sviðsstjóri: „Það

sem mér finnst, að það er fyrir mig að hafa yfirsýnina, sem mér finnst svona og líka svona

svolítið meiri fókus.“

Sú umgjörð sem uppskalað Agile veitir fyrir stöðugar úrbætur, til þess að geta verið sífellt

að bæta sig og gera betur, kemur fram að aðstoði við það ná betri yfirsýn. Ari, verkefnastjóri

á verkefnaskráasviði Zeta er hrifinn af hugmyndafræðinni sjálfri og hvernig hún býður upp á

að brjóta hlutina niður í smærri einingar, hann lýsir þessu:

49

En það er gott að vita að einn af kostum Agile er að ef að hlutirnir eru svolítið

óljósir að þá er gott að geta bútað þá niður og tekið svona syttri skref og svo ítrað

eftir því sem maður lærir og hentar að því leiti en það væri verra ef þetta væri

bara svona já, haldiði bara áfram að vinna þetta gerir þó alla vega það að verkum

að á tveggja vikna fresti að þá svona tekin svona, þá líta menn upp og taka

aðeins stöðuna þetta er cirka það sem við ætlum að gera næst og svo verify-um

við eftir á hvað gekk vel og hvað gekk ekki vel. (Ari)

Aðferðafræðin og yfirsýnin spila saman sem ákveðið samhengi en það kemur fram hjá

Axel, sviðsstjóra hjá Alpha, þegar hann segir segir:

Maður sér það mjög fljótt að verkefni eða við erum ekki að ná á deadline og þá er

hægt að bregðast við í staðin fyrir að þetta sé einhver svaka pottur sem, svo

kemur bara í ljós viku fyrir, að það þarf að vinna myrkrana á milli til að klára.

(Axel)

Þessi lýsing tengist í raun því sem Ari hjá Zeta talar um og Finnur hjá Sigma líka, um

þennan þátt Agile sem snýr að því að brjóta hlutina eða verkefni niður í litla búta og vinna

með það nánast eins og sérstakt verkefni. Þetta gerir stærri fyrirtækjum kleift að hafa betri

yfirsýn yfir stór verkefni ef vel er haldið á spöðunum varðandi utanumhald teyma.

5.3.1 Fastmótað ferli

Eitt af því sem nefnt var oft af viðmælendum var það að Agile aðferðafræðin býður upp að

unnið sé eftir ákveðnum ramma og að það sé að hjálpa til að við að ná þessari heildaryfirsýn.

Það er misjafnt hversu mikinn og stífan ramma fyrirtækin velja sér en hægt er að segja að

þau sem hafa byggst upp úr mörgum fyrirtækjum, Beta og Alpha, hafa valið sér frekar fast

ferli. Þau sem hafa byrjað lítil og stækkað, Delta og Sigma, hafa ekki farið í eins mikla

formfestu og virðast vilja halda í ákveðna nýsköpun.

Fastmótað ferli er sú leið sem Zeta hefur valið að fara og einnig Alpha til að ná þessari

heildaryfirsýn, Zeta er dótturfyrirtæki ferladrifins fyrirtækis svo það er kannski augljósasti

kosturinn fyrir það. Alpha sem er búið til úr mörgum litlum fyrirtækjum hefur skort ákveðna

samræmingu til að ná heildaryfirsýn og leitar því núna í fastmótaðara ferli. Þetta er svipuð

leið og Beta fór með sitt uppskalaða Agile í upphafi. Delta hefur byggt upp ákveðið ferli en

hefur lagt meiri áherslu á samvinnu og hraða í þróun og nýsköpun sinni en það er í samræmi

við kenningar McGregor og Doshi (2018) sem sáu að formfesta skipulags geti endað á að

50

draga úr nýsköpun og framleiðni. Það má segja að þetta sé fín lína sem þarf að þræða með

fasta ferla og sjálfsstjórnun sem er í samræmi við það sem og Dikert o.fl. (2016) fundu um

samræmingu á hefðbundnum rekstri og uppsköluðu Agile og hættunni á að verða í raun

minna agile en áður.

Zeta hefur eins og segir farið þá leið að vera með fasta ferla til að ná böndum yfir þann

hraða vöxt sem hefur átt sér stað og til að ná yfirsýn. Þessi aðferð við að festa hlutina í ferla

er að miklu leyti komin frá móðurfélagi Zeta og má segja að sé í grunninn ferladrifið

fyrirtæki. Ari fer talsvert út í vangaveltur um þetta fastmótaða ferli og segir

vöruþróunarferlið vera í raun Waterfall ferli, hann segir: „Í rauninni þá er þetta ferli svolítið

svona ef maður fylgir því alla vega formlega þá er þetta Waterfall.“ Hann bætir við:

En á móti kemur að þegar búið er að fara í gegnum svona stíft ferli og negla niður

requirements þá er þetta bara Waterfall og þá er þetta bara, þá er mér eiginlega

alveg sama hvað engineering gerir þá bara, hér er það sem þarf að delivera, hér

er tíminn, eru einhverjar spurningar bara láttu mig vita þegar þið eruð búin og ef

það eru einhverjar spurnigar á leiðinni láttu mig vita. (Ari)

Paasivaara o.fl. (2018) sáu þetta sama hjá Ericsson, áskoranir tengdar því að stjórnendur

væru fastir í Waterfall ferlum. Ari segir að kröfur frá móðurfélaginu séu alls ekki óeðliegar

þar sem að um stórt fyrirtækis sé að ræða, hans sýn á það er þessi: „Mér sýnist við þurfa að

passa inn í dálítið skýran ramma með, hvað eruð þið að gera, hvað kostar það og hvar eru

þið, ekkert óeðlilegt við það.“ Áhugavert er út frá þessum hugleiðingum hvernig þeir sem

tilheyra hugbúnaðarþróun sama fyrirtækis upplifa ferlið sem hefðbundið Agile ferli.

Daði hjá Zeta nefnir að þessi skýri rammi hafi stuðlað að árangri í þeirra starfi, en hann

lýsir því svona: „Það séu skýr markmið, skýrt hvernig fólk á að vinna og menn þurfa ekkert að

velta því fyrir sér og ekki vera að eyða rosa miklum tíma í hverju teymi að móta sinn feril.“

Þarna er Zeta klárlega að takast á við og leysa það með ferlum að mikið hefur fjölgað hjá

þeim á stuttum tíma og margir eru nýir, til að ná fram samræmingu vinnubragða og halda

starfinu gangandi í þróunardeild sinni. Þeir starfsmenn Zeta sem talað var við virðast

meðvitaðir um þetta og átta sig á að þeir séu að bregðast við aðstæðum, og eru að þreifa

fyrir sér með þetta jafnvægi Agile og hefðbundinna stjórnendaaðferða. Daði segir um þetta:

...þetta er svona upplýst einræði nánast í ferlum í bili, bara á meðan við erum að

ná tökum á því að mennta alla og allir skilji vöruna og allir fái confidence í því sem

51

þeir eru að gera... þegar við erum farin að skilja þennan ramma og hvað við

þurfum að hafa fast til að geta efficently reportað út á við að þá getum við gefið

flex innan teymanna. (Daði)

Samræmast þessar þreifingar niðurstöðum í rannsókn Dingsøyr o.fl. (2018) þar sem gott

jafnvægi milli stjórnunar og sjálfstæðis teyma þótti stuðla að árangri.

Hjá Delta er teymum gefin sjálfstjórn með val á aðferðafræði en hlutverk og fundir eru í

föstum ferlum sem eru reglulega í endurskoðun. Aron talar um mikilvægi vörueigenda í

þessu samhengi: „Gagnvart hagsmunaaðilunum þá er mjög þægilegt að hafa einhvern einn

til að leita til sem að representar teymið“ og Danni er sammála og segir: „Það endar bara í

núningi og leiðindum og eitthvað af því að þú veist, um leið og Product Ownerinn er ekki

hluti af teyminu, þannig að mér finnst algörlega lykilatriði að hafa þetta hlutverk.“ Aron telur

þennan ramma skapa meiri starfsánægju: „Ég held að fólki líði bara betur þegar það er

einhver svona regla á hlutunum“ segir hann.

Danni, Agile þjálfari hjá Delta talar um að Agile ramminn sé mikilvægur og finnst

stuðningur við teymin vera lykilatriði, hann segir: „Strúktúr, þarna ertu komin með strúktúr,

það er Product Owner sem er að halda utanum hlutina og þú veist, þú hefur Scrum

Masterinn í það og einhvern Agile coach sem er að support-a teymið ef það er eitthvað.“

Aron, yfirmaður hugbúnaðarþróunar hjá Delta leggur áherslu á þessa samvinnu í

uppsköluðu Agile, hann segir: „Samhengi og samvinna milli teyma og horfa á hvernig við

skilum virði og komumst hratt með, getum framkvæmt hugmyndir hratt og komist hratt á

markað hérna og unnið öll saman, sama í hvaða deild við erum.“ Þarna er hraði í fyrirrúmi

hjá Aroni sem kemur inn á hraða í samhengi við samkeppni á markaði, en hann segir

samvinnu nauðsynlega til að ná þessum hraða hjá Delta og hefur hún augljóslega verið

veigamikil ástæða upptöku Agile aðferða þar, hann segir: „Samvinna, það er skýrt af því að

það er þannig að verkefnin okkar eru þannig, það þarf að leysa þau, það getur ekki bara

einhver einn leyst þau.“ Svör Arons hjá Delta má tengja við þann kost sem valinn var af 55%

þátttakenda í nýjustu State of Agile skýrslunni (VersionOne Inc., 2018) um aukna framleiðni

teymis,

Hjá Zeta eru menn líka með hugann við hraða og kostnað sem má tengja beint við

samkeppnissjónarmið. Þar er tilfinningin sú að hugbúnaðarþróun sé dýr og því nauðsynlegt

52

að vera á tánum. Daði yfirmaður hjá Zeta skynjar hlutverk sitt í þessu starfi þannig að hann

sé að greiða leiðina fyrir góðri og skilvirkri hugbúnaðarþróun, Daði orðar það svona:

Eina markmið mitt er bara að reyna að fjarlægja hindranir úr því hvernig

developer-ar geta unnið og þessir ferlar eru ekki mér til gamans þótt ég hafi mjög

gaman af þeim en þeir eru fyrst og fremst til þess að fjarlægja óþarfa obstacles úr

veginum hjá developer-um til að þeir þurfi ekki að hætta þróa hálfan daginn til

þess að sitja á einhverjum fundum. (Daði)

Hann heldur áfram: „...búa til svona griðarstað fyrir forritara þú veist þannig að þeir fái

bara að vinna í friði það bara skiptir svo ógeðslega miklu máli.“ Ari, verkefnastjóri á

verkefnasskráasviði, vill meina að í þessu fastmótaða ferli sem hefur verið sett þar upp sé

samt ákveðinn sveigjanleiki sem sé fólginn í þessum stöðugu úrbótum og það sé af hinu

góða, hann segir: „Ég tel að sé að skila mestum árangri núna er bara að menn séu ekki að

festa sig ekki of í ferlinu.“

Alpha er að sama skapi í því ferli að setja upp hjá sér fastmótaðan verkefnaferil til að ná

betri yfirsýn og samræmingu á vinnubrögðum. Alpha setti upp vinnustofur með

starfsmönnum til að sjá hvar hægt væri að gera betur í starfseminni. Dagur kemur inn á

þetta þegar hann talar um ástæður þess að þau séu að fara í þetta formfasta ferli

Það kom líka mjög sterkt út úr vinnustofunum að þeim fannst óþægilegt að vera

að vinna á móti sitthvorum verkefnastjórunum, það var alltaf ferlið og sitthvort

vinnulagið það var ekkert svona staðlað vinnulag, það var mikið ákall eftir því.

(Dagur)

Líkt og fjallað er um hjá fyrirtækjunum hér að framan nefna viðmælendur Beta og Sigma

það að vera með ákveðinn ramma eða fyrirfram ákveðnar aðferðir fyrir teymin að vinna eftir

sem árangursþátt í sínu starfi. Þetta er í samræmi við þær lærðu lexíur sem Paasivaara o.fl.

(2018) lögðu fram við rannsókn hjá Ericsson.

Hjá Beta vinna öll teymi í Scrum og eru Andri, Fanney og Dóri hjá Beta öll sammála um

ágæti þess, Andri segir: „Við þurfum að hafa eitthvað svona samræmi til þess að við vitum til

dæmis hvað þitt teymi er að gera versus mitt og að við getum talað saman“ og Fanney er á

svipuðum nótum: „Mér finnst teymin flest, vinna sem ein heild“ og segir kostinn við þetta

vera að auðveldara sé að halda einbeitingu. Hún bætir við: „þú ert ekki að þvælast út um

allar koppagrundir á hverjum degi og það sem að er sem að dregur úr afköstum.“ Dóri er

53

ekki eins ánægður en hann segir þegar hann er spurður hvernig gangi að vinna eftir Scrum:

„það er svona upp og ofan sko en ég myndi ekki vilja snúa við eða hætta að nota það.“ Andri

segir sögupunkta Scrum vera stóran árangursþátt: „Ég held að það svona það hafi verið

stærsta jákvæða breytingin þegar við fórum yfir í þetta rigdit Scrum að við fórum að mæla

punkta, hjálpar mikið til við forgangsröðun.“

Það er því greinilegt að fastmótað ferli skilar sér í árangri í uppsköluðu Agile en það má

ekki vera of fast til þess að það þurrki ekki út allt frumkvæði og sjálfstæði. Fyrirtækin eru öll

frekar meðvituð um þetta en eru þó stödd á mismunandi stað í þroskastigi uppskalaðs Agile

ef svo má segja. Það, í bland við þann ólíka bakgrunn sem þau hafa, gerir það að verkum að

þau eru með mismunandi nálganir á því að fastmóta ferla. Talsverð kúnst er að ná þessu

jafnvægi, sem allir eru að leitast við að ná, milli stjórnunar og sjálfstæði teyma sem

endurspeglast í skipulagi ferla og vinnulagi.

5.3.2 Flóknar kröfur

Fyrirtækin vinna flest með stórar og flóknar hugbúnaðarlausnirnar og þeim fylgja margar og

flóknar kröfur sem oft er erfitt að forgangsraða. Öll nefna fyrirtækin að aðferðir uppskalaðs

Agile hjálpi til við að forgangsraða verkefnum, verkum niður á teymi og alveg niður í

forgangsröðun á kröfulista teyma. Þessi þáttur, auðveldari forgangsröðun, var einmitt einn

að þeim kostum sem oftast var valinn í nýjustu skýrslu State of Agile (VersionOne Inc., 2018).

Einnig hafa McGregor og Doshi (2018) talað um mikilvægi áætlana í þessu samhengi, en án

áætlanna vita teymi ekki hvernig á að forgangsraða í takt við stefnu fyrirtæksins.

Aftur á móti má líka segja að vegna þess hversu flóknar kröfur eru í þessum stóru

hugbúnaðarverkefnum sé forgangsröðun ákveðin áskorun þó að Agile ramminn hjálpi með

hana. Sú áskorun sem flest fyrirtækin eru að glíma við varðandi þetta er að

grunnforgangsröðunin fari ekki að færast niður í teymin, heldur fari fram á

verkefnaskráastigi og fari þaðan niður í teymin. Alpha sker sig aðeins úr þarna en það er

mjög þjónustumiðað fyrirtæki í beinu sambandi við endanotendur á meðan hin eru meira

vörumiðuð. Alpha tekur því sína forgangsröðun að miklu leyti beint frá viðskiptavininum á

meðan vörumiðuðu fyrirtækin eru með ákveðna milliliði eða innahúss viðskiptavini og því

kannski fleiri möguleika í boði við uppsetningu vörunnar, og þar með forgangsröðun orðin

erfiðari. Þetta samræmist niðurstöðum Leffingwell (2007) um að ein af helstu áskorunum

54

uppskalaðs Agile séu erfiðleikar við greiningar á kröfum. Hjá Delta er fólk að eiga við málefni

tengd forgangsröðun og breyttum áherslum og segir Danni:

Ef hugbúnaðargeirinn væri auðveldur þá myndi hver sem er gera þetta, þetta er

bara mjög erfitt viðfangsefni og mjög breytilegt, það er mjög auðvelt að breyta

og það breytist mikið og fólk veit ekkert alltaf hvað það vill fyrr en það fær það.

(Danni)

Axel hjá Alpha talar um hvernig það að notast við aðferðir uppskalaðs Agile hjálpi til við

forgangsröðun verkefna. Hann, sem er sviðsstjóri eins tekjusviðsins, segir Agile vinnubrögð

styðja við að verið að sé að vinna eftir réttri forgangsröð miðað við stefnu og sýn

fyritækisins. Hann útskýrir þetta:

Við erum kannski með verkefnapott sem er með alveg gríðarlega mikið af málum

og ef starfsmaðurinn er sjálfur að velja úr, úr hérna alveg, hann er ekki endilega

að taka hérna það sem ég myndi vilja taka eða skilurðu og hann hefur kannski

ekki endilega sýn á það að velja rétta málið stjórnunarlega séð finnst mér það

mesta value-ið þarna. (Axel)

Daði hjá Zeta talar einnig um forgangsröðun og segir að umgjörðin þurfi að geta raðað

verkefnum vel inn til forritaranna. Hann talar um hvernig móðurfélagið sé í mikilli nýsköpun

og margar hugmyndir á lofti:

… eru í bullandi innovaton og þurfa okkar stuðning að hérna og vilja fá okkur í að

gera allskonar hluti að það verður að svona raða því mjög skipulega og rökrétt

inn í framleiðsluferlið sko og developer-ar eiga ekki að heyra það noice. (Daði)

Finnur hjá Sigma segir þetta vera talsverða áskorun hjá þeim, bæði sé tæknin orðin gömul

og farin að úreldast og erfitt sé að uppfæra hana en líka það að hugbúnaðarlausnin sé svo

fjölþætt og geti þjónað ýmsum tilgangi:

Það eru mjög margir moving parts og þegar þú ert bara að setja það saman og

prófa það að þá getur það tekið rosalega langan tíma þannig að já við erum

svolítið að reyna núna að brjóta það upp og vinna með smærri einingar sem við

getum komið út óháð öðrum. (Finnur)

Hjá Beta kemur Dóri, teymismeðlimur inn á kerfið sjálft: „þetta er líka mjög stórt og flókið

kerfi og það þarf að að hugsa um svo marga hluti aðra heldur en akkúrat það sem þú ert að

gera.“ Fanney sem er vörueigandi, sér um að sögur séu einfaldar og skiljanlegar til vinnslu og

55

segir það oft vera erfitt: „þetta er rosa challenge oft að choppa það niður í

framkvæmanlegar einingar og það er bara flókið“.

5.3.3 Fjarlægð frá viðskiptavini

Nálægð og samvinna með viðskiptavinum er ein af grunnkenningum Agile aðferðafræðinnar

en þetta virðist tapast að talsverðu leyti í uppsköluðu Agile. Öll eru fyrirtækin að rekast á

hversu mikil fjarlægð frá endanotanda er orðin í uppsetningunni og það er að valda þeim

ákveðnum vandkvæðum og dregur jafnvel úr því hversu agile starfsemin er. Alpha stendur

fyrir utan þetta því þeir eru mest að vinna við þjónustu beint til viðskiptavina og

endanotenda.

Ekki er hægt að segja að þessi fjarlægð frá viðskiptavininum tengist uppruna eða

bakgrunni fyrirtækjanna því Sigma hefur einnig glímt við þetta vandamál þrátt fyrir að hafa

byrjað sem Agile teymi. Sigma hefur reyndar nýlega endurskipulagt starfsemi sína og þar var

þessi þáttur tekinn til endurskoðunar og samskiptalínur til viðskiptavinarins voru styttar.

Dóri sem er forritari hjá Beta, fangar þessa fjarlægð vel þegar hann segir: „Maður er alveg

búinn að vera að skrifa eitthvað vöruhúsakerfi og maður hefur aldrei komið í vöruhús“ og

bætir við: „Svo fer maður á svona ráðstefnu og talar við einhverja gaura og þeir spyrja, af

hverju gerið þið þetta svona? Bara, er það ekki fínt?“ Aðrir nefna þetta líka, Aron hjá Delta

segir vandamálið við það að vera langt frá viðskiptavininum, vera þetta: „…kemur upp

áherslumunur og internal focus og tilgangurinn er bara að smíða eitthvað en ekki að gera

viðskiptavininn ánægðan eða sækja á nýja markaði“.

Hjá Sigma glíma menn við svipað vandamál, Finni finnst að þeir hafa verið með of langar

samskiptalínur til viðskiptavinarins en í nýafstöðnum breytingum hjá þeim hafa þeir verið að

laga vinnulag og meðal annars það sem snýr að þessum þætti. Hann lýsir þessu svona:

„Ég myndi segja að við höfum feilað á því að vera í of litlum samskiptum, of langar

samskiptalínur við kúnnana og hérna og þá er bara fullt af dóti sem verður svona lost in

translation“.

Hugbúnaðarlausn Zeta er byggð ofan á ákveðna lausn móðurfélagsins sem er bæði flókin

og tekur langan tíma að læra á. Viðskiptavinir þróunardeildar hjá Zeta eru í raun

verkefnastjórar á verkefnaskráasviði eða eins og Ari, sem starfar sem slíkur, segir: „Ég er í

rauninni kúnninn þeirra og í rauninni eru það þeir sem deliver-a til mín, ég sem project

manager á í rauninni að sjá til þess að hvað product management biður um gerist.“ Fjarlægð

56

frá endanotenda er því mikil og Ari nefnir einmitt þetta: „Það er í raun og veru talsverð

fjarlægð frá endanotandanum í forritarann, já það er náttúrulega ókostur hérna“

Það má segja að við þessa fjarlægð frá viðskiptavini tapist margir eiginleikar þess að vera

agile. Þetta samræmist því að í uppsköluðu Agile hefur verið greind aukin hætta á að

notendur og aðrir haghafar fjarlægist teymin. En þó hafa fyrirtæki, þrátt fyrir þekkt

vandamál eins og þessi tengd uppsköluðu Agile, verið að færa sig í þá átt að innleiða Agile

aðferðina í stækkaðri mynd (Paasivaara et al., 2013, 2014; Dingsøyr and Moe, 2013).

5.3.4 Mælingar og áætlanir

Mælingar af ýmsum toga eru framkvæmdar í mörgum fyrirtækjum til að meta árangur,

keppst er við að ná góðum árangri og gott þykir að geta sýnt árangurinn á blaði eða í tölum.

Niðurstöður úr viðtölunum stemma að ákveðnu leyti við niðurstöður nýjustu State of Agile

skýrslunar (VersionOne, Inc, 2018). Í skýrslunni kemur fram að þátttakendur mæli helst

hvort afhendingar náist á réttum tíma og ánægju viðskiptavina en einnig hraða í sprettum og

skiluðu virði til rekstrar. Suma af þessum þáttum er verið að reyna að mæla hjá

fyrirtækjunum fimm. Þessar mælingar á Agile verkefnum sem slíkar hafa verið áskorun, en

fyrirækin halda áfram og gefast ekki upp á að reyna að ítra sínar mæliaðferðir og finna nýjar

og betri mælingar. Sérstakar áherslur á mælingar og kröfur um áætlanir frá yfirstjórn má

segja að komi fram hjá þeim fyrirtækjum sem ekki byrjuðu með Agile aðferð í grunninn.

Daði, yfirmaður hugbúnaðarþróunar hjá Zeta, hefur mikla trú á að mælingar sem verið er

að byrja á eða stefna að, muni gefa nákvæmari áætlanir um afhendingar sem dæmi, sem er

ákveðin krafa frá yfirstjórn og móðurfélagi þess. Ari, verkefnastjóri á verkefnaskráasviði Zeta

hefur hins vegar efasemdir um að þessar mælingar dugi til, hann veltir fyrir sér hvort ekki

væri betra að hugbúnaðarþróun og verkefnaskáarsvið myndu vinna meira saman að því að

finna réttu mælingarnar. Hjá fyrirtækjunum Beta og Zeta koma fram vangaveltur um hvort

mælingar séu yfirhöfuð góðar í slíku starfi eða að þær þurfi að minnsta kosti að byggja á vel

ígrunduðum grunni til að gefa rétta mynd. Andri, yfirmaður í hugbúnaðarþróun hefur í raun

ekki fundið enn neina mælingu sem honum finnst henta til gefa rétta mynd sem hægt sé að

skila upp til yfirstjórnar. Niðurstöður mælinga geta sýnt að allt sé á góðri leið og verið sé að

ná að vinna allt á góðum tíma en spurningin er hvort verið sé að vinna réttu vinnuna.

Mikil vinna er gangi í Alpha, eins og hjá Zeta, við að þróa nákvæmar tímamælingar til

áætlanagerðar en einnig tengist það þeim grunni Alpha hversu þjónustumiðað það er og

57

byggir tekjur sínar að miklu leyti á útseldum tímum. Hjá Delta og Sigma hefur stefnan verið

að reyna að samræma mælingar og áætlanir innan fyrirtækjanna og farin hefur verið sú leið

að taka upp markmiðasetningakerfi sem leggur áherslu á mælingar en það nær yfir allt

fyrirtækið og veitir þannig í leiðinni betri heildaryfirsýn.

Hjá Zeta er eins og segir mikil áhersla lögð á mælingar og Daði yfirmaður

hugbúnaðarþróunar hefur sett upp upplýsingaskýrslu (e. power BI report) sem er nánast

lifandi skjal. Þar koma fram öll árangurslínurit (e. burndown charts) teymanna sem segja til

um hversu mikið er búið af hverjum spretti og hver hraði (e. velocity) þeirra er. Daði vonast

til að þess að þessi aðferð geti bætt allar áætlanir hjá þeim en það hefur verið áskorun að

áætla tíma verkefna, Daði segir:

Við erum svolítið að reyna að gera þetta með aðeins vísindalegri hætti en að vera

með svona gut feel á því sem er eftir, eitthvað svoleiðis, við erum að reyna að ná

gögnunum af þeim gæðum að þetta forcast standist sko eins og við erum að

leggja það upp og svona bætum okkar estimation. Við erum að skrá tíma líka á

allar sögur, þú veist, þannig að við getum verið svona að sjá hlutfallið á milli

tímaskráningar versus estimation. (Daði)

Tilganginn segir hann vera þennan:

Að fólk skilji hvað raunverulega kostar að biðja um feature og við setjum bara

verðmiða á það og það er svona pínu svona end goal að við sjáum bara dollara

upphæðirnar þegar fólk vill bæta við feature, það er alltaf svolítið reality

check fyrir svona óskipulagða hugbúnaðarþróun þegar að fólk fær peningana upp

á borðið. (Daði)

Ari talar um að þessar mælingar í hugbúnaðarþróun séu ekki að skila sér nógu vel yfir á

verkefnaskráasviðið, þau séu á réttri leið en það vanti herslumuninn sem hann vill meina að

næðist með aðeins betri samvinnu. Hann segir: „Það eru til ákveðnir mælikvarðar sem verið

er að nota og þeir eru svolítið skilgreindir innan engineeering... við þurfum kannski að taka

skrefinu lengra og þú veist spurja hvað er það sem ég þarf að gera fyrir þig.“ Hann útskýrir

þetta aðeins betur:

Við erum komin með flott report þar sem hægt er að summerizea þetta miklu

betur saman... við áætlum að það séu 50 dagar eftir en ég sé ekki hvort þeir eru

58

þá búnir að eyða 150 dögum eða og það er erfitt að, sem sagt, auðvitað viljum

við sjá það, þá sjáum við hvort að estimate-in eru að virka. (Ari)

Andri yfirmaður í hugbúnaðarþróun hjá Beta talar einnig um að mælingar geti villt fyrir og

jafnvel farið að stýra ferlinu, hann segir frá ákveðnu dæmi um þetta: „Í denn þá var fyrirtæki

sem ákvað að mæla afköst forritara með hversu margar línur þeir forrituðu, telja línur og

daginn eftir þá voru allir farnir að skipta öllum skipunum niður í tíu línur sem voru kannski

tvær línur áður.“ Honum finnst erfitt að finna góðar mælingar og hann bætir við: „Þó ég hafi

enga mælikvarða sem ég er sáttur við að nota að það er ekki þar með sagt að við séum ekki

alltaf að reyna að gera meira, betur og hraðar.“ Segja má að þessi hugsun sé í anda Agile

hugmyndafræðinnar. Andri segir það að hafa litlar sem engar mælingar geti verið erfitt

þegar sýna á fram á árangur til yfirstjórnar og fjármáladeildar, hann lýsir þessu:

..að þau eru vön þú veist, skilurðu, ég vil bara sjá tölur, skilurðu, sýndu mér hvað

þið eruð búin að bæta ykkur í prósentum og ég bara já! það er ekkert svo auðvelt,

þannig að þetta er allt, allt öðruvísi heimur hvað það varðar. (Andri)

Þarna koma fram, eins og leitast var eftir að kanna, áskoranir og áhrif uppskölunar Agile

hjá stórum fyrirtækjum og hvernig sé oft erfitt að aðlaga Agile starfið að öðrum deildum

fyrirtækisins. Hjá Beta er ánægja viðskiptavina mæld og einnig ánægja starfsmanna, Andri

vitnar í fleyg orð þegar hann segir að þessar mælingar segi allt sem segja þarf: „Það var ein

hérna ágæt kona sem ég þekki sem að sagði: Eru starfsmennirnir þínir ánægðir, eru

kúnnarnir ánægðir, eru eigendurnir ánægðir, hvað er þá vandamálið.“

Fleiri hafa verið í vandræðum með mælingar, Axel hjá Alpha segir: „...hins vegar höfum

við verið í sem sagt hérna svolitlum vandræðum með, hvað á ég að segja, hugbúnaðarmegin,

með þessi production tösk, okkur hefur langað að fá einhver svona KPI á þau.“ Hjá Alpha

stendur til að prófa sig áfram með ýmsar mælingar, þær sem nefndar voru að væru á döfinni

voru mælingar á ánægju viðskiptavina strax eftir að verkefni lýkur og mælingar á því hversu

oft verk koma aftur til baka í lagfæringu frá viðskiptavini. Þar er mikil áhersla á áæltlanagerð

og afhendingardagsetningar og mikið horft á það, eins og hjá Zeta, að geta spáð réttilega

fyrir um tímalengdir verkefna, en eins og áður sagði er tekjustreymi Alpha mikið til útseldir

tímar. Þarna eru að rekast á hefðbundinn rekstur og Agile hugmyndafræðin og hættan er að

verða í raun minna agile eða lipur vegna krafna um mælingar og árangurstölur. Þetta

samræmist því sem Nerur o.fl. (2005) greindu sem lykiláskorun stjórnenda, að breyta

59

hugsunarhætti sínum og flytja sig úr föstum líkönum áætlana og yfir í ítrunar- og

eiginleikamiðuð líkön.

Í tengslum við mælingar eru prófanir sem komu fram sem ákveðinn árangursþáttur hjá

Alpha og Zeta, en Daði hjá Zeta tala um hvernig prótotýpufasi, þar sem unnið er með

einfaldustu gerð lausnarinnar (e. minimum viable product) í samvinnu við valinn

viðskiptavin, minnkar áhættu. Hann segir tilganginn vera þennan: „...að fjarlægja risk úr

veginum, eitthvað sem gæti potentially orðið risk ef við höldum áfram.“ Dagur hjá Alpha

kemur inn á hvernig prófanir innanhúss, sem gerðar eru áður en farið er í viðtökuprófanir

með kúnna, hafi skilað árangri, um þetta segir hann: „Þær hafa verið lykilþáttur í að ekki

hefur verið að keyra eins mikið fram úr áætlunum“

Hjá Delta og Sigma er verið að vinna með OKR markmiðasetningaraðferð og segja

viðmælendur hana vera að skila árangri í þeirra starfi. Samkvæmt aðferðinni eru markmið

sett upp og síðan þeir lykilþættir sem þarf að klára til að ná markmiðinu. Þetta er frekar nýtt

í báðum fyrirtækjum og fólk er að læra inn á þetta. Danni hjá Delta telur að þetta geti verið

gott verkfæri til þess að auka yfirsýn, hann segir: „Maður sér það fyrir sér sem mjög gott tól í

því að segja til dæmis, já, fyrirtækið ætlar sér eitthvað, þú veist, tribe-inn ætlar sér eitthvað

og svo teymin ætla sér eitthvað.“ Aroni hjá Delta finnst aðferðin árangursrík: „…sem hefur

bæði sem hefur svolítiðið neytt okkur til að vinna meira saman... og svo er bara að aukast

aðeins traustið á milli á milli fólks.“ Tengt þessu nefnir Elsa hjá Delta að betri skipulagning

verkefna á verkefnaskráastigi hafi skilað árangri, hún segir: „Síðan var farið að taka aðeins

fastari tökum og við vorum farið setja svona highlevel roadmap og svona jafnvel bara hvaða

verkefnum við sæjum fyrir okkur að við yrðum að vinna í á hvaða tímabilum.“

Finnur hjá Sigma segir að þetta auki yfirsýn og auðveldi forgangsröðun: „Þetta er í

rauninni forgangsröðunnar hólfið okkar, ef það kemur einhver inn og biður okkur um að

gera eitthvað og ef það stemmir ekki við þetta að þá þú veist, segjum við nei.“

Fyrirtækin hafa öll fært sig úr langtímaáætlunum yfir í þriggja til sex mánaða áætlanir sem

styðja við uppskalað Agile og það síbreytilega umhverfi sem þau starfa í, en það er líkt því og

kom fram í rannsókn Paasivaara (2017) að við innleiðingu uppskalaðs Agile höfðu áherslur

færst úr langtímaáætlunum í skammtímaáætlanir. Aftur á móti hefur verið erfitt að ná fram

ákveðinni undirstöðu og stöðugleika í mælingum sem áætlanir eru byggðar á vegna mikilla

breytinga í umhverfinu og einnig vegna breyttra aðferða innanhúss.

60

5.4 Skipulag samskipta

Misjafnt er hvernig fyrirtækin skipuleggja samskipti og upplýsingaflæði milli teymanna, sum

eru ekki með mikinn fókus á samræmingu á þessu og virðast að einhverju leyti gera ráð fyrir

að teymin sjái um þetta sjálf. Önnur leggja mikið upp úr sérstökum fundum til samræmingar

eða leggja línur í notkun á ákveðnum samskiptatólum, eins og Teams frá Microsoft eða

Facebook Workplace. Í flestum tilfellum er ábyrgð á þessu á herðum þess sem er í forsvari

fyrir teymið hvort sem hann nefnist vörueigandi, „Scrum Master“ eða verkefnastjóri. Það er

augljóst að samskipti og samskiptamáti skipta miklu máli í uppsköluðu Agile en það er

ákveðin mótsögn fólgin í því sem kemur fram í viðtölunum, en þar kemur fram að flestum

finnist þæginlegt að hafa fyrirfram ákveðnar leiðir til að koma skilaboðum á milli til að ekkert

tapist í ferlinu og upplýsingar flæði auðveldlega. Á hinn bóginn þykir líka gott að geta prófað

sig áfram og finna nýjar og betri leiðir til samskipta, en fólki líkar vel að hafa sjálfstjórn og að

geta valið sín samskiptatól sjálf.

Öll fyrirtækin nefna það að hafa staðið frammi fyrir áskorunum tengdum upplýsingaflæði

og samskiptum, en það má tengja við áskorun sem snýr að erfiðleikum við tengsl milli

teyma, sem fram kom í rannsókn hjá Dikert o.fl. (2016). Zeta, Beta og Sigma hafa farið þær

leiðir að vera með frekar föst form samskipta bæði í fundum og einnig hvað varðar kerfi og

tól sem notuð eru til þessa. Beta og Sigma hafa fikrað sig áfram með tilraunaaðferð í þessa

átt en þau eiga það sameiginlegt að hafa náð ákveðnu jafnvægi í sínu starfi í uppsköluðu

Agile. Delta og Alpha virðast bæði vera að fara þessa leið en eru komin styttra á veg. Þau eru

að fikra sig áfram með samskiptaleiðir, hafa fasta fundi en leyfa samræmingu og

samskiptum meira að gerast að sjálfu sér og má tengja það við að þau séu þannig að vissu

leyti að valdefla starfsmenn og teymi til að sjá um þennan þátt sjálf. Zeta, sem hefur tekið út

hvað hraðastan vöxt, virðist ekki tilbúið í þessa valdeflingu og er með mikið af samræmdum

vinnubrögðum og tólum til samskipta.

Valdeflingin og þróun samskipta hjá Delta kemur fram hjá Elsu, sem er vörueigandi, en

henni finnst vanta að fólk deili meira því sem það er að fást við. Hún kallar eftir meiri

samskiptum og segir:

..alltaf að vera bara opin umræða bara eða láttu allt alveg eins og þú myndir

segja bara yfir tölvuskjáinn, æ ég ætla að fara að gera þetta núna, skrifaðu það

61

bara í staðin fyrir að segja það við þessa þrjá sem eru við hliðina á þér, skrifaðu

það bara og þá vita það allir. (Elsa)

Danni hjá Delta segir að auka þurfi upplýsingaflæði milli ættbálka, hann fjallar svona um

verkhluta sem unnir voru saman af tveimur teymum: „Ástæðan fyrir því að það var talað við

hann var af því að hann var labba framhjá fundarherberginu...ef hann hefði ekki verið að

labba framhjá þá veit ég ekkert hvað hefði gerst.“

Helsta áskorun Alpha í þessum efnum er að fyrirtækið var myndað úr mörgum litlum

fyrirtækjum sem hafa að einhverju leyti myndað ákveðin svið eða deildir innan fyrirtæksins.

Alpha hefur því verið að kljást við að ná fram heildarhugsun yfir fyrirtækið og að fólk fari að

miðla upplýsingum og deila þekkingu, ekki bara milli deilda heldur milli sviða. Axel,

sviðsstjóri, kemst svona að orði þegar hann lýsir erfiðleikum varðandi þessa samræmingu:

„Hvar ég á að byrja, við erum með hrikalega mörg kerfi maður.” Einnig kemur mannlegi

þátturinn þarna inn hjá Alpha, en Dagur, yfirmaður á verkefnaskráasviði, nefnir þetta:

Kemur í ljós að hann var búinn að vera að vinna á móti kúnnanum alveg helling

án þess að verkefnastjórinn vissi af því þú veist hann bara þekkti hann og jafnvel

búinn að gera einhverja sérbreytingu fyrir hann, þessu stýrir þú ekkert. (Dagur)

Daði hjá Zeta nefnir að þrátt fyrir fasta ferla vanti samræmingu milli sviða eða ættbálka

en líka að það vanti að auka sýnileika og upplýsingaflæði milli teyma sem hann vill meina að

hægt sé bæta með því að leggja áherslu á sýningar úr sprettum (e. sprint demo). Hann orðar

það svona:

Leyfa fólki aðeins að monta sig á því sem það er að gera og á sama hátt að auka

skilning hjá öðrum gagnvart verkefnunum og auka aðdáun á milli hópa að þessi

hafi gert hitt og þetta og menn vita ekkert hvaða frábæru hluti er verið að gera

hérna. (Daði)

Ari hjá Zeta tekur í sama streng og segir að auka mætti sýningar úr sprettum til að fólk

hefði meiri tengingu og eitthvað að sýna eftir sprettina. Finnur hjá Sigma er sammála því

hversu mikilvægur sýningaþátturinn er og hafa þeir stigið skref í þessa átt. Hans sýn er

svipuð sýn Daða, en þetta segir Finnur: „Við viljum líka bara kannski sýna okkur sjálfum og

líka öðrum í fyrirtækinu hvað við erum að gera kúl hluti.”

Ari sem er eins og áður sagði verkefnastjóri á verkefnaskráasviði nefnir að upplýsingar um

verkefnin, sem séu í gangi, séu of dreifðar og erfitt sé að nálgast heildaryfirsýn yfir verkefni á

62

einum stað, hann segir þetta: „...safna saman þannig að þú vitir bæði hvar hlutirnir eru og

hvernig integration-ið á milli virkar og það er ekki komið. “

Finnur hjá Sigma segir að fyrir endurskipulagningu hafi teymin verið meira hlutamiðuð og

talsvert háð hvert öðru, hann segir að þátt fyrir að fyrirtækið sé ekki stærra en það er hafi

þetta náð að vera vandamál vegna skorts á upplýsingaflæði, hann segir:

Það er stundum komin í gang einhver vinna inni í einhverju teymi í einhverja

ákveðna tæknilega átt sem þarf svo að vinda til baka því það var ekki alveg verið

að passa að hafa samskipti við aðra sem þetta myndi hafa áhrif á. (Finnur)

Þarna er ákveðinn samhljómur við niðurstöður Xu (2009) um að þau verkefni sem noti

uppskalað Agile glími við vandamál tengd upplýsingaflæði og samskiptum. Nú eru teymi

Sigma orðin meira þáttamiðuð til að ná að leysa þennan flöskuháls samskipta.

Fanney hjá Beta rammar þetta kannski best inn með þessum orðum: „En þú kannski veist

ekki að þú þurfir upplýsingarnar og það er erfiðið.“

5.4.1 Vinnurými

Hluti af samskiptum fara fram á óformlegan hátt og hafa opin vinnurými verið mikið notuð

til að ýta undir slík samskipti í hugbúnaðarþróunarstarfi sem og í annars konar

skrifstofustörfum. Í teymisvinnu, Agile og uppsköluðu Agile, kom þessi uppsetning fram sem

ákveðinn árangursþáttur í rannsókn Dingsøyr o.fl. (2018). Þar kom fram hvernig opið

vinnurými hvatti á skilvirkan hátt til samræmingar teyma og jók skilning á kröfum

heildarverkefnisins. Skoðanir viðmælenda á þessari tilhögun að starfa með mörg teymi í

opnu vinnurými voru mjög misjafnar en öll fyrirtækin, fyrir utan Sigma, hafa sett starfsemi

sína þannig upp. Það virðist vera mjög persónubundið hvort fólk sé ánægt með þá

uppsetningu.

Margir viðmælenda telja það að setja mörg teymi í sama rými vera talsverða áskorun og

að betra væri að hvert teymi hefði sitt herbergi þar sem bæði væri hægt að vinna saman að

hlutunum og fá næði. Þessi hugmynd um teymisherbergi hefur örlitla skírskotun í það að

vinna eftir Agile aðferðafræðinni með eitt teymi og ná þannig upp stemningu og góðri

samvinnu hjá teyminu. Það sem þeir viðmælendur sem voru hrifnir af því að hafa teymin

saman í rými sjá við þá uppsetningu er sú dýnamík, samræming og samvinna milli teyma

sem myndast sjálfkrafa og að þess vegna sé mögulegt að sleppa við að gera sérstaka áætlun

63

um slíka samræmingu. Áhyggjur komu fram hjá þeim sem voru jákvæðir gagnvart opnum

rýmum um að þessi samvinna og flæði upplýsinga myndi tapast við að setja teymin, hvert

fyrir sig, í lokað rými.

Það má í raun greina mynstur í því hverjir eru á móti slíkri fjölteyma vinnu í opnu rými og

hverjir eru fylgjandi. Þeir sem vilja ná góðu flæði verkefna inn í og út úr þróunardeild eru

meira fylgjandi, en þeir sem eru á móti eru að einhverju leyti með meiri áherslu á teymin

sjálf og framleiðni þeirra. Teymismeðlimir, vörueigendur og þeir sem skila upplýsingum um

afrakstur til yfirstjórna eru því meira á móti en þeir sem vinna sérstaklega með samræmingu

verkefna. Einnig mátti sjá mun á svörum milli fyrirtækja en hjá einu fyrirtækinu voru allir

viðmælendur frekar neikvæðir gagnvart opnu vinnurými en þar má sem dæmi nefna að eitt

teymið vill vinna við ákveðnar aðstæður sem önnur teymi í kring eru ekki sátt við. Teymið

var því fært út í horn þar sem það er örlítið afskekktara.

Það getur auðvitað hafa litað svörin hvar staðsetning viðmælenda er í rýmunum og

hvernig þau eru uppsett. Elsa, vörueigandi hjá Delta, kemur inn á þetta: „Gamla sætið mitt

var hérna við stóra fundarherbergið sem er hérna, og það var hægt að ganga inn í það báðu

megin og þetta var bara eins og lestarstöð og það var engin einbeiting.“ Hún hefur núna

færst með teyminu sínu á annan stað þar sem þau eru aðeins út af fyrir sig en hún lýsir nýju

aðstöðunni svona: „Þá getum við alveg staðið upp og spjallað aðeins án þess að hafa

áhyggjur að vera að trufla hina, mér finnst það mjög mikilvægt því það er alveg stór hluti að

kemistrían í teymunum og hópunum sé góð.“ Aron og Danni eru líka hjá Delta en þeir eru

ekki miklir aðdáendur opins vinnurýmis. Danni heldur að uppsetningin hafi verið ætluð til að

auka samskipti en hann segir: „Og jú jú það gerist alveg, það gerist að maður talar alveg yfir

nokkrar raðir og eitthvað en mjög sjaldan, ég held að ég hafi gert það tvisvar.“ Aron segir

fyrirkomulagið í raun draga úr samvinnu því að fólk vilji ekki trufla aðra með samtölum.

Hjá Zeta og Beta eru blendnar tilfinningar, Daði hjá Zeta er algjörlega á móti því að hafa

mörg teymi saman og finnst það ekki stuðla að aukinni framleiðni. Hann segir:

Það sem skiptir máli fyrir forritara er að fá að vera í friði að ná löngum törnum

þar sem enginn er að trufla og þar sem að menn geta einbeitt sér og svona verið í

sínu context-i það er vegna þess að hraðinn á forrituninni fer bara exponentially

upp bara eftir hálftíma, klukkutíma bara við sama verkefni. (Daði)

64

Hann nefnir líka að honum finnist teymin þurfa meiri frið í sínum ramma til að vinna

saman. Daði er yfirmaður hugbúnaðarþróunar og ber því í raun heildarábyrgð á starfsemi

deildarinnar. Það er því líklegt að hann einbeiti sér mikið að framleiðni teyma og þurfi að

skila árangursskýrslum upp til yfirstjórnar. Ari verkefnastjóri á verkefnasafnasviði er hrifinn

af uppsetningu opna vinnurýmisins og honum finnst meiri líkur á að fólki taki þátt í

óformlegri umræðu sem ýti undir samvinnu teyma og milli deilda, sem þó, að hans mati,

gæti verið meiri á þessum tímapunkti. Ari lýsir þessu svona:

Þessu er stillt upp ágætlega hérna... en það hefur verið gott samstarf og

hérna samvinna á milli , það er hugsað fyrir flæðinu en eins og ég segi líka vegna

þess að það eru svo miklar breytingar að menn eru samt svolítið svona hver í sínu

horni. (Ari)

Hjá Alpha eru menn almennt ánægðir með vinnuaðstöðuna og Birkir sem er leiðtogi

tveggja teyma segist hafa almennt góða reynslu af opnu vinnurými. Axel sviðstjóri hjá Alpha

segir opnu vinnurýmin hafa virkað vel: „Það náttúrulega miklu meiri dýnamík og skilurðu

samskipti og miklu meiri samskipti og hérna á móti kemur að það er náttúrulega meira

ónæði.“ Hann lýsir því að teymin sitji saman á eyjum og samvinna innan teymis sé auðveld

þrátt fyrir að það myndist ákveðið ónæði þegar margar teymiseyjur eru í sama rými.

Andri, yfirmaður hjá Beta segir fyrirtækið reyna að taka tillit til þess að fólk hafi

mismunandi skoðanir á því að vinna í slíku umhverfi þar sem teymin eru oft mörg saman og

ýmis annar umgangur er. Til stuðnings þessu má taka fram að teymi Fanneyjar vinnur í

sérstöku teymisherbergi núna, en Fanney, sem er vörueigandi, hefur mjög sterkar skoðanir á

þessu máli. Hún segir:

Mér finnst þetta bara svona straightforward að setja mörg teymi í sama rými er

náttlega bara banalt, en bara þú veist, það á að banna þetta…það á að vera í

rými en það á líka að vera lokað rými sem enginn annar hefur áhrif á hvorki

kaffivél eða playstation eða what ever. (Fanney)

Hún segir, eins og Daði hjá Zeta, þetta hafa mikil neikvæð áhrif á framleiðni teyma og hún

segist ekki þreytast á að ræða þetta og heldur því áfram: „…að áreitið og óþægindin sem að

hljótast af þessu og minnkuð framlegð er rosaleg, þetta eru ævintýralegar tölur, það er bara

þannig.“ Dóri, teymismeðlimur, tekur ekki eins djúpt í árina og Fanney og finnst þetta hafa

65

vanist, hann segir þegar hann er spurður um hvað honum finnist um að vinna í rými þar sem

umgangur er mikill:

Það er kannski svona það eina sem ég gæti sett út á alla vega persónulega...

annars er eiginlega orðinn staðalbúnaður hérna það eru allir með svona

headphone, soundcancel og maður setur þetta bara á sig, ekki til að hlusta á

tónlist heldur til að þurrka bara út, vera bara í sínum heimi. (Dóri)

Dóri er ekki sá eini sem nefnir hljóðeinangrandi heyrnatól en allir viðmælendur nefna að

sín teymi noti slíkan búnað, hjá Sigma líka þar sem teymin vinna í teymisherbergjum. Finnur

segir að teymisherbergin virki vel: „Þú ert með teymið hérna í opnu rými og þeir sem eru að

vinna saman eru svolítið að náttúrulega alltaf í stöðugum samskiptum og það er mjög

skemmtilegt, já en það eru samt ekki allir ofan í öllum.“

Það er ljóst að uppsetning teymisherbergja er mörgum ofarlega í huga og margir nefna

slíkt fyrirkomulag. Það eru þó líka greinilega skiptar skoðanir á því hvort óformleg samskipti,

dýnamík og flæði milli teyma hverfi með því að setja teymin öll hvort í sitt herbergið. Þeir

sem töluðu gegn teymisherbergjum virtust hafa áhyggur af því að sú sjálfstýrða samræming

sem á sér stað við að hafa teymin í sama rými, hverfi. Þeir viðmælendur sem nefndu

teymisherbergi voru þeir sem virtust hafa kynnt sér uppsetningar á Agile hjá stærri

fyrirtækjum í fræðunum, hjá erlendum fyrirtækjum eins og Spotify eða gegnum tengslanet

sitt í hugbúnaðarþróunargeiranum. Daði segir til dæmis: „…og það er bara af því að þetta er

bara svo lítið commutity af hugbúnaðarfyrirtækjum maður veit alveg hvað, hvernig hinir og

þessir eru að vinna.“

5.5 Hlutverk Fyrirtækjamenningar í uppsköluðu Agile

Eitt af þemunum sem upp kom í viðtölunum er menning eða fyrirtækjamenning, en það

hefur verið talið mjög mikilvægt að beina ahyglinni að fyrirtækjamenningu við notkun Agile

aðferða. Cavaleri og Obloj (1993) segja það vera áskorun að ná því fram að menningin styðji

við aðferðafræðina. Þannig mætti segja að þegar farið er að vinna með mörg teymi í

uppsköluðu Agile sé mikilvægt að átta sig á því hvernig heildstæð fyrirtækjamenning hefur

áhrif á samræmingu vinnubragða hjá teymum. Í fjölteyma umhverfi má draga samvinnu og

samræmingu fram sem lykilþætti í því að ná árangri. Hvernig best er að ná fram þessari

fyrirtækjamenningu, sem einkennist meðal annars af sjálfsprottinni og að hluta til sjálfstýrðri

samvinnu, virtist vefjast fyrir sumum fyrirtækjunum. Það má tengja það við niðurstöður Xu

66

(2009) þar sem kom fram að þau verkefni sem nota uppskalað Agile eiga á hættu að það

vanti upp á samræmingu og upplýsingaflæði.

Fyrirtækin Delta og Alpha virðast vera í leit að þessari fyrirtækjamenningu sem styður við

aðferðir þeirra á uppsköluðu Agile og snúa að sjálfsprottinni samvinnu, en þar eru teymin

sjálfstýrð. Það má segja að Zeta sé að sama skapi í leit að því að ná fram menningu sem

styður við uppskalað Agile en þarf að vinna í kringum ferladrifið móðurfélag og menningu

þess. Fyrirtækjamenning Beta og Sigma virðist styðja vel við starf þeirra í uppsköluðu Agile

sem má rekja til þess að þau eru komin lengra í sinni vegferð og hafa fundið jafnvægi í þeirri

aðferð sem hentar þeim.

Beta er það fyrirtæki sem hægt er að segja að hafi náð bestum árangri af fyrirtækjunum í

sínu starfi í uppsköluðu Agile. Fyrirtækið, sem var byggt upp úr mörgum litlum fyrirtækjum,

byrjaði smátt í Agile, óx svo hratt á sínum tíma en hefur eins og áður segir fundið ákveðið

jafnvægi. Eitt af því sem einkennir þetta fyrirtæki er það hvernig það nær að valdefla

starfsmenn sína á sama tíma og það viðheldur ákveðnum strúktúr í sínum ferlum. Það má

segja að valdefling og frelsi sé ríkt í menningu þess og styður slík menning vel við uppskalað

Agile, en grunnur þessarar menningar tengist eða liggur meðal annars í áhuga og þekkingu

sumra starfsmanna á Agile hugmyndafræðinni og í þeirri tilraunaaðferð sem notuð var við

innleiðinguna.

Rannsakandi leitaðist líka við að kanna hvort Agile hugmyndafræðin hafi verið innleidd

eða kynnt fyrirtækinu í heild og fann ákveðinn hljómgrunn í því einmitt hjá Beta og fleirum,

en þó ekki á markvissan hátt. Það má að einhverju leyti halda því fram að ákveðin grasrót

hafi myndast á Íslandi í kringum Agile aðferðafræðina og í raun kannski Agile í stærri mynd.

Þannig hafa Agile aðferðir smitast út úr hugbúnaðarþróun hjá einhverjum fyrirtækjanna og

yfir í aðrar deildir, oft vegna smitandi áhuga þeirra sem vinna í þessu umhverfi. Það eru ekki

mörg stór hugbúnaðarþróunarfyrirtæki hér á landi og má segja að Agile tengslanetið sé þétt,

Daði lýsir þessu:

Það sem sagt það er rosa samgangur á milli okkar sem stýrum svona

hugbúnaðardeildum og maður þekkir ansi marga sem eru komnir á þú veist eða

standa í þessu og hérna og svo er alltaf þegar við hittumst á ráðstefnu að þá

erum við alltaf að shear-a hvernig gengur og hvað hefur breyst og hvernig leysir

67

þú þetta og eitthvað svona og þetta er svo skemmtilegt við íslenska markaðinn að

hann er svo pínulítill. (Daði)

Þegar viðmælendur voru spurðir um menningu í sínum fyrirtækjum kom í ljós að þeir gera

sér grein fyrir mikilvægi hennar í þessu samhengi og eru fyrirtækin með ýmsum ráðum

markvisst að vinna með hana. Grasrótarstemningin kemur áfram fram hjá Daða sem hefur

unnið lengi í hugbúnaðargeiranum. Hann segir að mikilvægt sé að aðrir skilji hvers vegna

unnið sé eftir Agile aðferðafræðinni, hann kemur inn á þetta: „Svolítið að breiða út kúltúrinn

okkar yfir í önnur teymi, að allir skilji hvernig við vinnum á svona day to day basis.“ Andri hjá

Beta segir aðrar deildir innanhúss hafa tekið upp aðferðir þeirra: „Við erum með stóra

consulting deild sem að nýtir sér Scrum líka að hluta til.“ Hann segir líka:

Ég hef alveg séð aðrar deildir taka upp Kanban og jafnvel verið að keyra

spretti og eitthvað svoleiðis og gera þetta meira svona visual og svoleiðis, þannig

að hérna þegar að Scrum Masterarnir voru sem flestir þá jafnvel vorum við að fá

gesti úr örðum deildum og sýna þeim bara svona, svona getum við gert þetta og

svona hvetja þau áfram en við vorum ekki, hvað á ég að segja, að fara út fyrir

development og boða fagnaðarerindið. (Andri)

Grasrótarkenning kemur kannski sterkast fram hjá Alpha en þar var mikið um

teymisvinnu en hvorki mikið unnið eftir Agile hugmyndafræðinni né aðferðum. Sterkur Agile

vinkill kom svo inn í starf þeirra í gegnum starfsmann sem hóf þar störf og fór að miðla

reynslu sinni um ágæti Agile aðferða. Dagur segir frá þessu: „Þessi Agile sterki vinkill kemur

svolítið frá einum aðila sem kom hérna inn og var búinn að vera að vinna alveg full Agile þar

sem hún var, þannig að hún kom með svona pínu þunga að fara aðeins meira inn í það.“

Aðferðafræðin hefur smitast þar líka út í aðrar deildir en hluti fjármáladeildar Alpha er farinn

að vinna í sprettum.

Axel sviðsstjóri hjá Alpha, sem er þjónustumiðað fyrirtæki, segir að verið sé að vinna með

þann þátt í dag að starfsmenn upplifi fyrirtækið sem eina heild, sérstaklega gagnvart

viðskiptavinum, en Alpha er byggt upp úr mörgum minni fyrirtækjum. Axel segir í þessu

samhengi: „Hópurinn kemur bara saman inn og vinnur áfram saman eftir einhverja

sameiningu sko þannig að hann heldur kannski svolítið í sína menningu.“ Bæði Axel og Birkir

segja menningu fyrirtækisins vera rótgróna og í raun að teymin vilji hafa sína hentisemi á

68

hlutunum og því hefur það að ná samvinnu milli teyma verið áskorun. Birkir lýsir þessu

svona:

Þetta er mjög svona rótgróin deild... partur af þessum starfsmönnum koma

þaðan og eru með, ég held að það séu flestir með 20-35 ára reynslu þarna inni

þannig að þetta er mjög svona náinn hópur sem að, það þekkjast eiginlega allir

bara mjög vel og síðan erum við með við svona einn til þrjá svona nýrri

starfsmenn sem við erum að reyna koma bara svolítið inn í svona þeirra kúltúr.

(Birkir)

Axel segir að menningin sé að verða einsleitari hjá Alpha og honum finnst ákveðið

umbreytingarferli vera hafið, hann segir þetta: „Þetta er soldið rótgróið sko hérna, það er

svona aðeins verið að rífa þetta áfram og svona umbreytingar aðeins.“

Hjá Delta, fyrirtæki sem byrjaði smátt og var ekki í Agile í upphafi, er að vissu leyti það

sama uppi á teningnum. Bæði eru margir starfsmenn búnir að vinna lengi og eru fastir í sínu,

eða eins og Danni kemst að orði: „Það er rosalega svona forritara þenkjandi menning“ og

hann bætir við:

Teymisvinna er ekkert endilega efst á blaði, það er svolítið svona, stundum hefur

maður á tilfinningunni að ok, við þurfum að vera Agile af því að það er einhver

Agile coach og ég þarf að hlýða honum stundum... gamlir forritarar sem segja

bara, ég geri þetta og þú gerir þetta, forritað svolítið hver í sínu horni. Svolítið

svona finnst mér ríkjandi menningin, stór challenge að breyta því. (Danni)

Aron, einnig hjá Delta, finnur líka fyrir því að menn séu fastir í gömlum hlutum og segir:

„Það er þessi gamla hugsun, eitthvað, you only get one chance at first impression, það er

annar stór flöskuháls, í að koma vöru á markað hjá okkur.“ Aron talar líka um að menningin

sé lituð af stækkun fyrirtækisins og erlendum samstarfsaðilum en hann hefur þetta að segja

um menninguna: „Mér finnst hún vera í rosalegu millibilsástandi.“ Hann vill meina að hingað

til hafi ein íslensk menning ráðið ríkjum en nú hafi erlendu teymin bæst við, „...og það er

mikið mix af menningarkimum“ eins og hann orðar það.

Eins og hjá Alpha segir Aron Delta vera að vinna að því að fólki finnist það vera hluti af

heild. Fyrirtækið átti sig á að samfara hröðum vexti þurfi að vinna í að huga vel að samstöðu,

hann segir: „Þetta er svolítið allt upp í loft núna og og þarf svolítið markvissa vinnu til þess

að koma þessu á þennan stað sem að við viljum hafa þetta.“ Þessi sýn Arons, sem er

69

yfirmaður hugbúnaðarþróunar, er í takt við það sem Misra o.fl. (2010) settu fram um að

mikilvægt sé við innleiðingu á uppsköluðuð Agile að gera sér grein fyrir því að

hugmyndafræðin verður að ná inn í menningu fyrirtæksins til að hún festist í sessi og skili

tilætluðum árangri.

Um þetta virðast viðmælendur hjá Zeta vera meðvitaðir en eru samt í ákveðinni klemmu

við að aðlaga þá Agile menningu sem þau vilja ná fram að þeirri fastmótuðu menningu sem

einkennir móðurfélagið. Daði, yfirmaður hugbúnaðarþróunar, tjáir sig um þetta:

Rosalega áhugavert að mörgu leiti sko...ferlarnir eru allir mótaðir... hér er

hugbúnaðarfólk sem er vant að vinna hjá hugbúnaðarfyrirtækjum þannig

að kúltúrinn hann er svona, hann langar ógeðslega að vera svona agile og

software og startup feelingur en þessi kúltúr ber ofboðslega virðingu fyrir

kúltúrlegacy-inu hjá (móðurfélaginu) þannig að þetta eru svona tveir heimar sem

eru að spila svolítið saman og spila það ágætlega. (Daði)

Daði segir líka að allir séu mjög meðvitaðir um að þessi menning, sem styður Agile

umhverfið, náist ekki á einum degi. Þau viti hvert þau langi til að komast, eða eins og hann

segir: „Okkur langar að komast þangað, við erum með augun á targetinu en við svona

respect-um það sem er í gangi og vöruna sem við erum með og færum okkur bara hægt og

rólega í átt að því sem við viljum vera.“ Einkennisorð hugbúnaðarþróunar Zeta eru

heiðarleiki og gagnsæi en slík hugsun ýtir undir traustmyndun og með þeim sýnileika er

þróunardeild að byggja upp grunninn fyrir þá menningu sem hentar best Agile starfi.

Einkenni menningar hjá Beta, sem viðmælendur lýsa, virðast styðja vel við aðferðir

uppskalaðs Agile og lýsa því jafnvægi sem fyrirtækið hefur náð í sínum aðferðum en Andri

kemur inn á hvernig unnið hefur verið markvisst að því. Traust og valdefling koma þarna

fram sem þeir lykilþættir sem stuðlað hafa að árangri í þeirra vinnu við það nota uppskalað

Agile. Agile aðferðafræðin leggur einmitt meðal annars áherslu á fólk umfram ferla og það

að bregðast við breytingum umfram áætlanir (Beck o.fl., 2001). Traustið kemur fram hjá

Andra, yfirmanni hugbúnaðarþróunar:

Við höfum lagt mikla áherslu á traust, við viljum að, þú veist, í öllum teymunum sé

traust þannig að þú getir bara talað um hvað sem er skilurðu og við erum alltaf

með þessa retro fundi, það er fundur, þú veist, sem er aldrei gefinn afsláttur af,

að mínu mati mikilvægasti fundurinn. (Andri)

70

Hann lýsir því einnig hvernig valdefling starfsmanna fer fram:

Það er mjög svona ríkt í kúltúrnum hérna það er, empowerment er eitt af

gildunum okkar og við viljum að þú bara, þú veist, ef þú ert með einhverja

hugmynd að þú bara taktu bara af skarið skilurðu, gerðu það bara! (Andri)

Fanney lýsir sinni upplifun af þessari valdeflingu: „Bara þú veist að viðurkenna það, við

gerðum mistök með að velja þetta, hættum þessu bara, hendum þessu, gerum þetta

öðruvísi, þetta virkar ekki og það er bara þannig.“ Fanney segir líka:

Við gerum grín, við þú veist bendum og einhvern veginn að koma því, þeirri

tilfinningu inn að það er allt í lagi að gera mistök, þau koma í ljós löngu áður en

productið fer út úr húsi af því að við erum að review-a fyrir hvort annað og prófa

strax og jafnóðum og það, þessi þankagangur held ég að hafi hjálpað okkur að

mynda heildarteymi. (Fanney)

Dóri teymismeðlimur hjá Beta kemur inn á samvinnu: „Þú getur labbað eiginlega bara

hvert sem er og spurt og það er alltaf tekið á móti manni og þú veist og manni hjálpað og

fólk sem er að byrja hérna sko það talar mikið um þetta.“ Fanney dregur saman ávinninginn

við þessa samvinnu og traust:

Allir hjálpast að og kenna hvorir öðrum. Hann tekur það sem er efst á listanum og

svo bara finnur hann út úr því að draga þá inn sem að kunna betur og hann lærir

á meðan og smátt og smátt geta allir tekið bara efsta í sögulistanum og bara

klárað það og enginn er ómissandi og það er beauty-ið. (Fanney)

Menning Sigma einkennist einnig af trausti sem lýsir sér í ákveðinni vinastemmingu.

Finnur segir menninguna hjá þeim hafa byggst rólega upp með tímanum, fyrirtækið hafi ekki

stækkað hratt og fólk hafi kallað vini sína mikið inn sem það hafði unnið með annars staðar.

Finnur segir þetta um menninguna: „Ég myndi segja að hún væri rosalega góð... ansi góð

svona vinastemming myndi ég segja.“ Hann segir líka: „Það er svona no blame svona

atmosphere myndi ég segja“ sem er menning sem styður bæði við uppskalað Agile og einnig

við stöðu fyrirtækisins sem sprotafyrirtæki.

5.5.1 Dreifð teymi

Sum fyrirtækjanna eru með starfmenn erlendis og því eru dreifð teymi partur af

þróunardeildum þeirra. Dreifðu teymin tengjast inn í fyrirtækjamenninguna og setja sinn

71

svip á hana eins og önnur innanhúss teymi. Fram kemur hjá Leffingwell (2007) áskorunin að

vinna með dreifða staðsetningu og á svipuðum nótum eru Dikert o.fl. (2016) þar sem

nefndar eru áskoranir tengdar samhæfingu í fjölteyma umhverfi. Beta, Zeta, Delta og Sigma

eru öll með dreifð teymi og segja það vera ákveðna áskorun en það gangi samt vel í flestum

tilfellum. Mikilvægur þáttur í því að þetta gangi vel séu samskipti og að teymið hittist

reglulega. Þarna spilar inn í hlutverk teymisleiðtoga í að viðhalda einingu í teyminu. Þarna

koma fram ýmsar áskoranir, eins og erfiðleikar vegna tímamismunar, tungumálaerfiðleikar,

misskilningur og menningarmunur en einnig hefur það verið bundið vandkvæðum að ná því

að teymið upplifi sig sem eina heild. Fanney hjá Beta segir að það vanti þessi óformlegu

samskipti: „Það er ekki farið í kaffivélina saman, það er þetta social sem vantar”

Andri hjá Beta segir að fólk sem sé ekki á staðnum geti gleymst: „...þeir eiga það til að

gleyma hinum... þannig að þannig að hinum finnast þeir alltaf vera að missa af. “ Daði hjá

Zeta er á svipuðum nótum:

...þá höfum við reynt að búa til þessi crosscountry teymi þannig að séu að það séu

tveir úti og tveir hérna heima, það kostar alveg helling af veseni, en það er samt,

hefur lagað þessa tilfinningu að mönnum finnist þeir vera við versus them. (Daði)

Daði segir Zeta vera í nokkrum löndum og því fylgi ákveðið flækjustig, en þrátt fyrir það

segir hann: „En það gengur bara samt ótrúlega vel að hérna að sinka alla saman. “

Það má segja kannski að á þessari tækniöld hafi heimurinn minnkað, samskipti hafi

almennt aukist milli landa og þar með skilningur orðinn meiri á mismunandi menningu og

siðum annarra.

5.6 Aðrar áskoranir og árangursþættir

Þegar spurt var hvaða áskorunum fyrirtækin hafi staðið frammi fyrir við notkun á Agile í

svona stórri umgjörð og hvaða þættir hafi stuðlað að árangri í starfinu kom ýmislegt fram. Í

töflu 4 má sjá yfirlit yfir þær áskoranir sem viðmælendur nefndu og í töflu 5 yfirlit yfir þá

árangursþætti sem komu fram í viðtölunum. Ákveðið var að hafa Sigma ekki með í

samanburðartöflunni þar sem eingöngu var rætt við einn aðila, en það var tekið með í

niðurstöðunum engu að síður.

72

5.6.1 Áskoranir

Helstu áskoranir sem fyrirtækin eru takast á við með notun á uppsköluðu Agile sem

viðmælendur nefndu má sjá í töflu 4. Þær áskoranir sem þegar hefur verið fjallað um eru:

hratt innleiðingarferli, tíðar breytingar, óljósar ábyrgðir og hlutverk, skortur á heildaryfirsýn,

flóknar og margar kröfur, fjarlægð frá viðskiptavini, erfitt að finna mælingar og gera

áætlanir, áskoranir við skipulag samskipta, vinnurými og að fyrirtækjamenning styðji við

uppskalað Agile ásamt dreifðum teymum.

Tafla 4 Helstu áskoranir sem fyrirtækin takast á við með notkun á uppsköluðu Agile

Áskoranir Alpha Beta Zeta Delta

Upplýsingamiðlun og samskipti X X X X

Mælingar og áætlanir X X X X

Hratt innleiðingarferli X X X

Flóknar og margar kröfur X X X

Fjarlægð frá viðskiptavini X X X

Vinnurými X X X

Fyrirtækjamenning X X X

Skortur á heildaryfirsýn X X X

Dreifð teymi X X X

Tíðar breytingar X X

Ábyrgðir og hlutverk X X

Margir haghafar X X

Skilningur annarra deilda X X

Áskorun sem nokkrir viðmælenda nefndu var tengd haghöfum en í stórum

þróunarverkefnum geta verið margir haghafar með mismunandi sýn og forgangsatriði

(Barney and Wohlin, 2009). Axel hjá Alpha segir til dæmis að innanhúss liggi hagsmunir oft

ekki saman og þá komi upp ágreiningur varðandi forgang, hann lýsir þessari áskorun svona:

„Það er náttúrulega sitthvor yfirmaðurinn þannig að það er ekki eitt authority sem segir

bara, svona verður þetta, þú þarft þá að fara upp tréð.“ Þarna má velta fyrir sér hvort að

slíkur ágreiningur komi upp hjá Alpha vegna þess að fyrirtækið sé byggt upp úr mörgum

litlum fyrirtækjum og er enn að eiga við ákveðna aðgreiningu vegna þess. Slíkur ágreiningur

kemur ekki fram hjá Beta sem er einnig byggt upp af litlum fyritækjum, en þar er uppskalað

Agile orðið talsvert þroskaðara en hjá Alpha. Danni hjá Delta segir einnig mismunandi

hagsmuni valda því að oft sé erfitt að forgangsraða og Finnur hjá Sigma er sammála: „...að

forgangsraða það hefur nú, það kannski... já hefur verið rosalega erfitt.“ Þessar áskoranir við

73

marga og ólíka haghafa með mismunandi kröfur hafa einnig verið nefndar í rannsóknum

Pikkarainen o.fl. (2008) og Ambler (2008).

Einnig hafa samræming og tengingar inn í aðrar deildir oft reynst erfiðar og sérstaklega þá

í þeim fyrirtækjum sem ekki byggja á Agile frá grunni eða eru samsett úr mörgum, eins og til

dæmis Beta. Heildarmyndin kemur þarna inn í og þurfa þróunardeildir að geta stigið til baka

og horft á heildarmyndina í samræmi og gefið sér tíma til að kynna og útskýra hvers vegna

þeirra ferli er ólíkt hefðbundnum ferlum annarra deilda. Hjá Beta hefur Andri, yfirmaður í

hugbúnaðardeild, fundið fyrir ákveðnum þrýstingi frá ráðgjafadeild innanhúss sem hann

segir að, ásamt viðskiptavinum, ætlist stundum til að þróunardeildin geri bara meira og

hraðar. Hann segist stundum nota myndlíkingu til að auka skilning á því að þetta sé ekki

hægt: „Þú ert með teymi sem getur bara þróað ákveðið mikið, það er alveg sama hvað þú

treður mikið af pappír í prentarann, hann prentar ekkert hraðar, þannig að þú þarft að velja

hvað þú ætlar að setja í gegnum prentarann.“ Einnig nefnir hann það að stundum vilji

sölumenn fá eitthvað gert strax og átti sig ekki á stóru myndinni, hann segir í því samhengi:

Þeim finnst við vera bara einhverjir þverhausar sem erum alltaf að segja nei en

dilemman sem við erum að fást við, er að við þurfum að hugsa um alla

viðskiptavinina en þú ert bara að hugsa um þennan eina sem þú ert að sinna

núna. (Andri)

5.6.2 Árangursþættir

Helstu árangursþættir í aðferðum fyrirtækjanna á uppsköluðu Agile sem viðmælendur

nefndu má sjá í töflu 5. Þeir árangursættir sem þegar hefur verið fjallað um eru: aðlögun á

aðferð við uppskalað Agile, tilraunaaðferð innleiðingar, fastmótað ferli, markmiðasetningar

og prófanir, ákveðnir samskiptaferlar og tól, fyrirtækjamenning sem styður uppskalað Agile

og sjálfstæði teyma.

74

Tafla 5 Helstu árangursþættir í aðferðum uppskalaðs Agile sem viðmælendur nefna

Árangursþættir Alpha Beta Zeta Delta

Aðlögun á Agile aðferð X X X X

Hugarfar X X X

Æfing og kynningar X X X

Fastmótað ferli X X X

Stuðningur stjórnenda X X

Prófanir X X

Regluleg útgáfa X X

Agile á verkefnasafnastigi (e. roadmap planning) X X

Tilraunaaðferð innleiðingar X X

Fyrirtækjamenning X

Ákveðnir samskiptaferlar og tól X

Spennandi verkefni X

Sjálfstæði teyma X

OKR markmiðasetning X

Þeir þættir sem einnig komu fram sem árangursþættir og ekki var fjallað um að hér að

framan voru meðal annars val og aðlögun á Agile aðferð, sem hefur verið nefndur sem

árangursþáttur hjá mörgum samkvæmt skipulagðri yfirferð fræðilegra rannsókna (Dikert

o.fl., 2016). Fyrirtækin hafa, eins og kom fram áðan, ekki tekið upp aðferðir uppskalaðs Agile

sem fjallað hefur verið um í rannsókninni en flest hafa þau tekið þessar aðferðir, meðvitað

eða ómeðvitað, og aðlagað að sinni starfsemi. Þegar fyrirtækin voru spurð um árangursþætti

nefndi enginn sérstaklega þetta atriði en flestir nefndu að sá rammi sem þau aðlöguðu að

sér væri árangursþáttur og má segja að það sé val og aðlögun á uppsköluðu Agile.

Hugarfar er árangursþáttur sem kemur fram í lærðum lexíum Paasivaara o.fl. (2018) hjá

Ericsson og tala nokkrir viðmælenda um að þetta sé mikilvægur þáttur. Dagur hjá Alpha

nefnir sem dæmi að með Agile hugarfarinu náist ákveðin samkennd, hann segir:

„Verkefnastjórinn er ekki bara einhver framkvæmdarstjóri, þannig að hópurinn verður svona

samábyrgur fyrir þessu..“. Sigma vinnur ekki eftir ákveðinni aðferð en hefur nokkrar

grunnreglur og einkennist þeirra hugarfar af því að vera eins agile og hægt er, Finnur lýsir

þessu þannig:

Við erum ekki endilega Scrum eða ekkert endilega að hengja okkur á eitthvað

ákveðið en það er meira með því að vera stöðugt að rýna það sem við erum að

gera og endurbæta... það er bara svona kjarninn í því að vera agile. (Finnur)

75

Daði segir það að hafa einkennisorð þróunardeildar Zeta heiðarleika og gagnsæi ýta undir

hugarfar sem einkennist af samvinnu og trausti, hann segir: „Þannig að það er hluti af því

bara að búa til traust.“ Traust er mikilvægt í teymisvinnu og til að ná fram þessum

heiðarleika og gagnsæi þarf fólk að þekkjast og mynda tengsl.

Ýmis þjálfun og kynningar styðja við uppskalað Agile og hafa skilað sér í aukinni

tengslamyndun og samvinnu sem stuðlar að góðum árangri. Zeta er sem dæmi með sérstaka

þekkingarfundi að minnsta kosti einu sinni í viku þar sem fólk segir frá hinum ýmsu

áhugamálum sínum, Daði segir frá: „Það var fyrirlestur hérna í síðustu viku um hvernig á að

rækta blóm innanhúss, garðyrkju… þetta er bara þú veist, myndar tengsl að share-a þessum

hlutum og læra að skilja náungann aðeins betur.“

Sigma er eins og Zeta, með föstudagsskóla þar sem starfsmenn segja frá áhugamálum og

önnur utanaðkomandi fræðsla er líka í boði. Sigma hefur einnig byggt upp áhugahópa utan

um ákveðna tækni sem þeir eru að vinna með, eða eins og Finnur kemst að orði:

„…samræma þá vinnu því það er í raun sú vinna sem að snertir alla hópa og hérna, já þannig

að við erum gerum svolítið af því að sinka okkur þannig saman.“ og hann bætir við: „Fyrst og

fremst hérna það að deila þekkingu og hérna já og líka bara skemmtilegt.“

Elsa, vörueigandi hjá Delta, segir að fræðsla í kringum innleiðingu OKR

markmiðasetningarinnar hafi verið af hinu góða fyrir Agile starfið og henni finnst hafa aukið

á skilning og þekkingu annarra, hún segir: „Það var til dæmis Agile námskeið sem var boðið

upp á fyrir þá sem voru ekki endilega að vinna í Agile.“

Stuðningur stjórnenda er mikilvægur til að árangur náist í uppsköluðu Agile samkvæmt

Kalenda o.fl. (2018) en hann var nefndur af nokkrum viðmlendum sem árangursþáttur þeirra

starfi og sérstaklega þá það frelsi sem þróunardeildum er gefið til að vera Agile. Axel hjá

Alpha kemur inn á þetta og segir stjórnendur veita frelsi: „Það er reynt að hafa ferlana

þannig að þeir, þú veist, styðji við aðferðafræðina, en mönnum ekki ýtt þangað.“ Birkir hjá

Alpha tekur í sama streng og segir fyrirtækið hafa brugðist við þörfum með uppfærslum á

fundarherbergjum sem styðja við aðferðafræðina en hann lýsir sinni upplifun á þessu svona:

„Rosalega margir að vinna eftir þessu þannig að hérna það hefur alveg sannað sig og það

treysta allir stjórnendur á þetta.“

Annar árangursþáttur sem kom fram í viðtölunum er ramminn sem fylgir því að hafa

reglulegar útgáfur. Reglulegar útgáfur eru hluti af mörgum Agile aðferðum og þær hafa

76

komið í staðinn fyrir stórar og viðamiklar útgáfur sem voru lengi í þróun áður en þær voru

gefnar út. Dagur hjá Alpha nefnir að nýtt útgáfustýringarkerfi sjái til þess að alltaf sé verið að

vinna með nýjustu útgáfu og Birkir dregur fram mikilvægi þessa nýja kerfis við samræmingu

þegar hann segir: „Þegar við erum að gera til dæmis útgáfur sem er svona það sem hefur

áhrif á kerfi sem hafa þegar verið gangsett þá fer út sjálfvirkur póstur til þeirra um að það sé

að fara út útgáfa.“ Danna hjá Delta finnst hugmyndin sjálf um reglulegar útgáfur ýta undir

skipulag, hann segir:

Svo við séum ekki bara að þróa eitthvað og af hverju erum við að gera þetta bara

til að gera eitthvað nýtt og svo er einhverntíman sett út og þetta er bara svona

algjört skipulagsleysi. (Danni)

Finnur hjá Sigma talar um að þau hafi stundum átt í vandræðum með að gefa út, hlutirnir

hafi legið of lengi í þróun án þess að vera gefnir út. Hann segir því mikinn kost vera fólginn í

reglulegri útgáfu: „Já skapa value fyrr og fá hérna feedback eins hratt og hægt er, þú veist,

allt annað það gjörsamlega drepur mann.“ Hann nefnir ítranir í þessu samhengi og segir:

Það að ítra hratt og gefa hlutina út bara jafnóðum og þeir eru tilbúnir og bara

brjóta, bara beisik svona verkfræði, bara brjóta hlutina niður og en samt þannig

að þú sért alltaf hérna í þeirri aðstöðu að geta gefið hugbúnaðinn út. (Finnur)

Þarna er samhljómur við það sem þátttakendur nýjustu skýrslu State of Agile (VersionOne

Inc., 2018) nefndu sem helstu ástæðu þess að þeir völdu Agile aðferðina, en það var styttri

afhendingartími.

Að lokum má nefna að það kom fram sem árangursþáttur að varan sé spennandi og

starfið byggist á nýþróun og nýsköpun. Hugbúnaðarþróun hefur lengi verið mikið tengd

nýsköpun og er það miklvægur þáttur í starfi fyrirtækja í dag, ný þekking myndast og nýjar

lausnir sem viðhalda samkeppnisstöðu og þroska fyrirtækja.

77

6 Umræður

Megintilgangur rannsóknarinnar var að kanna hvort, og þá hvernig, íslensk

hugbúnaðarfyrirtæki noti aðferðir uppskalaðs Agile í sínu starfi og hvernig það gengur að

vinna eftir Agile á svo stórum skala. Rannsóknarspurningar sem voru hafðar til hliðsjónar

voru settar fram í þremur liðum og eru eftirfarandi:

R1) Nýta stöndug íslensk hugbúnaðarfyrirtæki sér hugmynda- og aðferðafræði Agile í

stærri verkefnum sem eru unnin af mörgum teymum þvert á deildir, eða

svokallað uppskalað Agile, og þá að hversu miklu leyti?

R2) Hvaða ávinning sjá þau við notkun á uppsköluðu Agile, hvaða þættir í því starfi

hafa stuðlað að árangri og hverjar eru helstu áskoranirnar sem þau hafa þurft að

takast á við?

R3) Hafa fyrirtæki markvisst innleitt Agile hugmynda- og aðferðafræði í fyrirtækið

sem heild?

Skoðuð voru fimm fyrirtæki sem öll starfa við hugbúnaðarþróun, vinna eftir Agile

aðferðafræði og eru með mörg teymi. Tekin voru viðtöl við 13 viðmælendur sem allir starfa

hjá þessum fyrirtækjum og var leitast við að ná að teikna upp heildarmynd af þróunarferlinu.

Rætt var við teymismeðlimi og teymisleiðtoga sem gáfu mynd af upplifun teymanna í

gegnum ferlið. Einnig var rætt við yfirmenn hugbúnaðarþróunardeilda sem gáfu innsýn í

heildarferlið og hvernig það tengist heildarstarfsemi fyrirtækisins. Eins var rætt við

verkefnastjóra á verkefnaskráasviði sem gáfu aðeins öðruvísi mynd af hlutunum og í raun að

sumu leyti sýn þess sem horfir á ferilinn utan frá. Nafnleyndar var óskað og fyrirtækjunum

voru gefin nöfn sem á engan hátt tengjast þeim.

6.1 Aðferðir uppskalaðs Agile í íslenskri hugbúnaðarþróun

Þegar kannað var hvort þessi stöndugu íslensku hugbúnaðarfyrirtæki væru að nýta sér

aðferðir uppskalaðs Agile kom í ljós að þau gera það greinilega, þau fyrirtæki sem voru

skoðuð eru öll að þróa stórar hugbúnaðarlausnir eftir Agile aðferðum og nota öll til þess sína

eigin aðferð sem annað hvort byggir á aðferð sem til var fyrir eða er þróuð frá grunni

innanhúss. Fyrirtækin falla ekki undir skilgreiningu Dikerts o.fl. (2016) um uppskalað Agile en

nota Agile í stækkaðri mynd þar sem má greina mikil líkindi við uppskalað Agile. Þess vegna

hefur rannsakandi ákveðið að tala um starfsemi þeirra sem uppskalað Agile og skilgreina það

78

sem sameiginlegt starf tveggja eða fleiri Agile teyma við vinnu á ákveðinni vöru eða kerfi.

Tvö fyrirtækjanna hafa tekið upp aðferðir Spotify Tribe líkansins að hluta til og aðlagað þær

að sínum þörfum. Eitt fyrirtækjanna sýnir samhljóm með LeSS aðferðinni en hin fyrirtækin

hafa ekki byggt á tilteknum grunni við innleiðingu uppskalaðs Agile þó þar sé unnið á

svipuðum nótum og í öðrum aðferðum, með fundaáætlanir og í sprettum.

Fyrirtækin fimm eiga það sameiginlegt að vera öll í hugbúnaðarþróun og er það þeirra

kjarnastarfsemi. Það eru ákveðin líkindi í uppbyggingu þeirra og einnig má segja að líkindi

séu í meginmarkmiðum þeirra um að framleiða gæða hugbúnað sem hentar

viðskiptavininum á sem skemmstum tíma og á sem hagkvæmastan hátt. Þrátt fyrir þennan

samhljóm nota fyrirtækin ólíka nálgun við vinnu í uppsköluðu Agile í fjölteyma umhverfi en

þau hafa öll innleitt uppskalað Agile eftir mjög agile leiðum eða með ákveðinni

tilraunaaðferð og prófað sig áfram í sínum aðferðum. Þessi aðferð hefur leitt fyrirtækin í að

vinna á mismunandi hátt eða þann hátt sem þeim þykir best henta sinni starfsemi og þeim

kröfum sem henni fylgja. Þarna er hægt að segja að fyrirtækin séu að reyna að nýta sér alla

kosti Agile hugmyndafræðinnar sem getur verið áskorun við þessar aðstæður og

tilhneigingin vill verða að fara að stýra uppsköluðu Agile að vissu leyti með aðferðum

hefðbundinnar verkefnastjórnunar. En mikilvægt er í slíku ferli, það sem McGregor og Doshi

(2018) sögðu um að með því að halda sjálfri hugmyndafræðinni á lofti, sem í grunninn er

hvatning og aðlöguð frammistaða, við innleiðingu uppskalaðs Agile sé hægt að byggja upp

fyrirtæki sem er raunverulega Agile.

6.2 Ávinningar, árangursþættir og áskoranir

Ástæður þess að fyrirtækin hafa valið að nota uppskalað Agile eru margvíslegar enda margir

kostir við það að nota hugmyndafræðina við hugbúnaðarþróun. Aukin samvinna var ástæða

sem mikið var nefnd og þar koma fram ákveðin samlegðaráhrif sem verða til þegar fólk og

teymi fara að vinna saman. Þannig verður til ný þekking og miðlun upplýsinga verður betri

sem að lokum skilar sér í betri vörum og styttri tíma á markað. Til þess að ná fram þessari

auknu samvinnu er nauðsynlegt að traust sé til staðar og að sú menning sem er ríkjandi

styðji við myndun þess, ef þetta næst verða öll samskipti og upplýsingamiðlun auðveldari. En

það er einmitt þetta samspil sem verður flóknara eftir því sem teymum fjölgar, þrátt fyrir að

traust sé til staðar og vilji til samvinnu og samskipta, getur miðlun þekkingar orðið erfið.

Snúið getur verið að sjá til þess að allir hafi þær upplýsingar sem þeir þurfa og samræming

79

náist án þess að eyða þurfi dýrmætum tíma í óþarfa fundi. Samskipti er einn af mikilvægustu

þáttum Agile og má segja að skipulag samskipta sé ákveðin kjarnaáskorun í uppsköluðu Agile

sem takast þarf á við og þá sérstaklega það að samræma verkefni og koma á nægum

samskiptum milli teyma án þess að fara í of mikla örstjórnun. Jafnvægi samskipta og

upplýsingamiðlunar getur verið snúið og passa þarf að falla ekki í þá gryfju að fara að deila of

miklum óþarfa upplýsingum, en slíkt getur gert það að verkum að fólk hættir að meðtaka

þær. Þetta er í samræmi við það sem Dingsøyr o.fl. (2018) settu fram um hvernig

þekkingarmiðlun í Agile umhverfi er miðuð út frá miðlun leyndrar þekkingar eins og með

fundum, en sú miðlun verður flóknari og erfiðari þegar komið er í stór verkefni og

þátttakendum og haghöfum fjölgar.

Mikilvægi samvinnu og samskipta er einnig viðeigandi í stærra samhengi og þegar

fyrirtæki fer í gegnum mjög hraðan vöxt er það eitt og sér ákveðin áskorun, en fyrir þau sem

vinna eftir Agile aðferðum verður hraði vöxturinn til þess að á sama tíma verður uppskölun á

Agile aðferðum einnig mjög hröð. Nokkur fyrirtækjanna í rannsókninni höfðu einmitt tekið

út mjög hratt vaxtarferli Agile aðferða samhliða hröðum vexti fyrirtæksins. Það er mikilvægt

að átta sig á því að við slíka uppskölun þarf að reyna fylgja hugmyndafræði Agile og vera ekki

með of skipulagt innleiðingarferli heldur bregðast við aðstæðum þegar þær koma upp. Þetta

getur valdið því að óstöðugleiki og óvissa eykst á þeim tíma sem innleiðingin á sér stað en

skilar sér í því að sú aðferð sem á endanum verður til þegar hægir á vexti er sú aðferð sem

ætti að henta best aðstæðum. Það getur reynst erfitt að innleiða uppskalað Agile eftir

þessum leiðum því að á sama tíma þarf að halda rekstri gangandi, en þarna kemur fram

mikilvægi þess að ná ákveðnu jafnvægi sjálfstýringar og skipulagningar. Segja má að þetta sé

í samræmi við Dingsøyr o.fl. (2018) sem sýndu fram á að góður árangur uppskalaðs Agile

væri að hluta tileinkaður góðu jafnvægi milli stjórnunar og sjálfstæðis teyma. Til þess að geta

haldið starfsemi gangandi á tímum mikils uppvaxtar í Agile starfi þarf að skipuleggja vel

samvinnu og samskipti til þess að þekking, sem er á höndum fárra, útdeilist til þeirra sem

nýir eru á sem skilvirkastan hátt. Þetta er í samræmi við það sem Paasivaara o.fl. (2018)

greindu hjá Ericsson, að þegar fólk kemur saman í teymi úr deildum eða annars staðar frá og

ef ekki er til staðar ákveðin stefna í upphafi getur samvinna og samhæfing orðið erfið. Þarna

virðist myndast sú þörf sem fyrirtækin hafa fundið fyrir, að festa vinnulag og samskipti í

ákveðna ferla. Það getur gert það að verkum að ef ekki er hugað að grunngildum Agile (Beck

80

o.fl., 2001) á meðan, verði ferlarnir og fyrirtækið minna agile en áður. Þetta má tengja við

það sem Dikert o.fl. (2016) fundu út í fræðilegri yfirferð um samræmingu á hefðbundnum

rekstri og uppsköluðu Agile og hættunni á því að verða minna agile en áður við

samræminguna.

Fastir ferlar voru nefndir sem árangursþáttur uppskalaðs Agile hjá mörgum

viðmælendum en misjafnt var hversu mikinn og stífan ramma fyrirtækin settu upp með

slíkum ferlum. Þau fyrirtæki sem hafa tekið út hraðan eða meðalhraðan vöxt hafa búið sér til

frekar fastan ramma sem leiða má líkum að sé vegna þess að þróun uppskalaðs Agile

meðfram vextinum hafi orðið of stefnulaus og vandamál tengd vinnulagi og samskiptum hafi

ekki verið að leysast nægilega hratt til að ná að viðhalda rekstri á meðan.

Þessi formfesta til að viðhalda samræmingu og skipulagi getur gert það að verkum að

frumkvæði minnkar og dregið getur úr hvatningu til sköpunar. Þetta eru þættir sem

mikilvægt er að ýta undir í lifandi samkeppnisumhverfi til að viðhalda stöðu á markaði og má

því segja að það þurfi að meta vel þann markað sem keppt er á og hversu nauðsynlegt er að

halda í nýsköpun og sjálfsprottna samvinnu í innleiðingarferli uppskalaðs Agile. Þetta er í

samræmi við það sem McGregor og Doshi (2018) sögðu um hvernig formfesta skipulags geti

endað á að draga úr nýsköpun.

Tilraunaaðferð við uppskölun Agile og sjálfstæði teyma ýtir undir þætti nýsköpunar og

frumkvæðis en þessar aðferðir hafa verið taldar skila árangri í uppsköluðu Agile starfi.

Tilraunaaðferð kemur sterkt fram í rannsókninni að skili árangri við innleiðingu og notast

fyrirtækin öll við hana að einhverju leyti, sum meira en önnur. Þetta er í takt við eina af

lærðum lexíum Paasivaara o.fl. (2018) þar sem tilraunaaðferð skilaði árangri við uppskölun á

Agile hjá Ericsson. Fram hefur komið að sjálfstýring teyma auki sjálfstæði, sköpun og

sjálfsprottna þekkingarmiðlun og er það talið árangursþáttur í uppsköluðu Agile að gefa

teymum sjálfsstjórn. Þegar uppskölun gerist hratt eins og raunin varð hjá mörgum

fyrirtækjanna hefur það sýnt sig að sjálfsstjórn teyma sé að einhverju leyti ótímabær þar

sem mikið er af nýjum aðilum og erfitt fyrir þá að koma með innlegg í sjálfstýringu því það

vantar upp á þekkingu þeirra á vörum og aðstæðum. Það hefur því borið árangur að festa

aðferðir teyma á meðan fyrirtækið tekur út vöxt en þetta passar við athugun Dingsøyr o.fl.

(2018) á norsku stórfyrirtæki. Þar hafði uppskalað Agile gengið vel og það þótti auðvelda og

hjálpa til að Scrum aðferðin var notuð sem grunnur.

81

Eitt af grunngildum Agile snýr að stöðugum endurbótum (Beck o.fl., 2001) og þessi

áhersla getur valdið því að umhverfið er sífellt á hreyfingu og leitandi að ákveðnu jafnvægi

milli þess að viðhalda stöðugleika og því að gera alltaf betur. Í hröðum vexti, eins og hjá

nokkrum fyrirtækjanna sem voru til skoðunar, er tilhneiging til þess að festa vinnuferlið í

stífan ramma og því getur verið áskorun að halda áfram stöðugum endurbótum. Til að

festast ekki í stífum ramma og formföstu ferli sem erfitt er að ítra er nauðsynlegt að gera sér

grein fyrir þessari takmörkun á uppsköluðu Agile sem felst í stífum ramma og fylgjast með

hvenær þekking starfsmanna er orðin næg til að hægt sé að gefa teymum meira svigrúm og

sjálfstýringu til að geta nýtt kosti Agile hugmyndafræðinnar til fulls.

Annað sem rannsóknin sýndi fram á að þarf að varast við uppskölun á Agile aðferðum er

það að þróunarferillinn verði í raun Waterfall ferill þar sem kröfur verkefnis eru skilgreindar

á verkefnaskráasviði og þaðan skilað inn til þróunardeildar sem skilar verkefninu tilbúnu til

baka. Þannig getur þróunardeild verið að vinna í samræmi við Agile aðferðafræði en

heildarferillinn er fastur í Waterfall ferli. Agile starf miðast að því að komast hjá slíkum

ferlum því þeir hafa sýnt sig mynda flöskuhálsa ásamt því að draga úr lærdómi, aðlögun og

framlagi starfsmanna (Serrador og Pinto, 2015). Það er einmitt hætta á að þetta gerist þegar

stjórnendur og önnur svið eru föst í Waterfall ferlum en fram kom í rannsókn Paasivaara

(2017) að slíkt var vandamál áður en farið var í uppskölun á Agile og var vonast til að þessi

þáttur myndi leysast við uppskölunina.

Við slíkar aðstæður má draga þær ályktanir að þrátt fyrir að verið sé að vinna með mörg

teymi í Agile starfi er innleiðingu uppskalaðs Agile ekki algjörlega lokið fyrr en

heildarþróunarferlið er orðið Agile. Til þess að þetta takist þarf að gera ráð fyrir og ýta undir

samvinnu milli deilda og samvinnu við viðskiptavini. Rannsakanda þótti áhugavert hvernig

mismunandi sýn viðmælenda á þessu, hjá einu fyrirtækjanna, kom fram þar sem

verkefnastjóri á verkefnaskráasviði lýsti þróunarferlinu sem Waterfall en hin sem tilheyrðu

þróunardeild lýstu ferlinu sem klassísku Agile ferli.

Viðmælendur þeirra fyrirtækja sem voru til skoðunar í rannsókninni virtust flestir mjög

vel að sér í Agile fræðum og meðvitaðir um grunngildi Agile og því fannst rannsakanda

áhugavert hversu lítil áhersla er í raun lögð á samskipti og samvinnu við viðskiptavini, þá

sérstaklega endanotendur, í gegnum þróunarferlið. Áskoranir sem uppskalað Agile er að

glíma við varðandi samvinnu við viðskiptavini eru þær að oft þróast

82

hugbúnaðarþróunarferlið út í það að hafa milliliði á milli teyma og endanotenda. Þannig fara

samskiptaleiðir að lengjast en það eykur hættuna á að eitthvað tapist eða skekkist á leiðinni.

Ástæður sem geta legið að baki þessari tilhneigingu til að nota milliliði eru til dæmis að verið

sé að reyna að skýla forriturum og teymum fyrir áreiti til þess að halda uppi framleiðni.

Þarna er samhljómur við svör þátttakenda í nýjustu skýrslu State of Agile (VersionOne Inc.,

2018) þar sem 55% sögðu aukna framleiðni teymis vera ástæðu þess að velja uppskalað

Agile.

Velta má fyrir sér hvort þessi áhersla á aukna framleiðni á kostnað samvinnu við

viðskiptavini skili sér í meira virði. Eru flóknar kröfur þessara stóru hugbúnaðarlausna að

skila sér rétt inn í teymin til vinnslu til að geta skilað sér til baka í auknu virði fyrir

viðskiptavininn og fyrirtækið? Fyritæki hafa einmitt, þrátt fyrir þetta þekkta vandamál um

aukna fjarlægð frá haghöfum og endanotendum, verið að færa sig í þá átt að innleiða

aðferðir uppskalaðs Agile (Paasivaara o.fl., 2013, 2014; Dingsøyr og Moe, 2013). Dingsøyr

o.fl., (2018) komu með hugmynd að lausn á þessu hjá norsku stórfyrirtæki þar sem fulltrúar

viðskiptavina voru staðsettir á sama stað og teymin til að tryggja aðgang teymanna að þeim.

Starfi sem er samkvæmt uppsköluðu Agile fylgir eins og áður sagði þáttur stöðugra

úrbóta, það snýr að því að teymi fara yfir sínar aðferðir og ítra þær og farið er reglulega yfir

ferla og þeir ítraðir. Þessi áhersla á að endurskoða aðferðir og reyna að gera alltaf betur er

einn af grunnþáttum þess að vera agile (Beck o.fl., 2001). Á svona stórum skala geta tíðar

breytingar á ferlum og skipulagi valdið því að hlutir fara að skolast til og verða óljósir en fram

kom hjá hluta viðmælenda að hlutverk og ábyrgðir væru ekki nógu skýrar en einnig má segja

að þetta sé fylgifiskur hjá fyrirtækjum í hröðum vexti. Það kom því rannskanda mjög á óvart

hversu jákvæðir viðmælendur voru í garð breytinga, breytingatregða kemur fram sem ein af

helstu áskorunum við það að skala upp Agile aðferðir í nýjustu skýrslu State of Agile

(VersionOne, Inc, 2018), í yfirferð Kalenda o.fl. (2018), hjá Dikert o.fl. (2016) í sínu skipulagða

fræðilega yfirliti og einnig hjá Paasivaara o.fl. (2018) en Ericsson upplifði breytingatregðu hjá

stjórnendum við að fara í uppskalað Agile.

Fyrirtækin í rannsókninni voru öll að fara gegnum eða voru nýbúin að fara í gegnum

endurskipulagningu sem hlýtur að gefa til kynna að endurskipulagning sé frekar algeng í

starfi uppskalaðs Agile. Ástæðurnar geta verið ýmsar, hraður vöxtur eins og fram hefur

komið, hagræðing, nýjar áherslur, breytt samkeppnisumhverfi eða hvað sem er, og virðast

83

því breytingar vera orðnar að eðlilegu ástandi. Viðmælendur voru eins og sagði, jákvæðir í

garð breytinga og gáfu til kynna að sama ætti við um aðra starfsmenn þó að oft væri einn og

einn sem væri neikvæður. Þessa almennu jákvæðni í garð breytinga má mögulega að

einhverju leyti þakka þeirri valdeflingu sem á sér stað í Agile starfi. Sjálfstýring teyma gæti til

dæmis verið ástæða sem liggur þessu að baki. Þannig fá teymin að ákveða sjálf hvað virkar

fyrir þau og hvað ekki og með því skilja þau tilganginn með breytingunni.

Ákveðinn strúktúr eða rammi við breytingarnar gæti einnig verið þáttur sem skilaði sér í

þessari jákvæðni en fram kom hjá einu fyrirtækjanna sem hafði stífan ramma að vel væri

tekið í breytingar hjá þeim. Athuga skal þó að í þessu tilfelli getur verið að þessum fasta

ramma fylgi ekki endilega sífelldar breytingar. Það getur einnig verið ákveðin takmörkun

sem spilar inn í þegar mikið er um nýtt starfsfólk að eðlilegt sé að það sé viðbúið miklum

breytingum í sínu nýja starfi. Mögulega eru þó fyrirtækin að vinna Agile starfið vel og

breytingatillögur og úrbætur fá að koma frá starfsfólkinu fremur en að ofan og með því

finnist starfsfólki það eiga hlut í breytingunni sem skilar sér í aukinni jákvæðni gagnvart

henni. Með þessu er ekki verið að segja að allir viðmælendur hafi verið ánægðir og jákvæðir

gagnvart öllu í sínum ferlum heldur verið að draga fram það jákvæða hugarfar sem

endurspeglast í þeirri skoðun viðmælenda að breytingar séu af hinu góða.

Einn þáttur sem skoðaður var í rannsókninni var vinnurými í fjölteyma umhverfi. Mjög

mismunandi skoðanir komu þar fram um ágæti þess að vera með mörg teymi í sama

vinnurými. Þeir viðmælendur sem mest þurftu að hafa yfirsýn og samræmingu í sínu starfi

voru ánægðastir með slíka uppsetningu en þeir sem horfðu meira á framleiðni og

einbeitingu niðri á teymisstiginu voru hvað óánægðastir með uppsetninguna. Slík uppsetning

með mörg teymi í sama vinnurými hefur verið talin auka samvinnu og samræmingu og þá

með áherslu á óformleg samskipti. Það er í samræmi við rannsókn Dingsøyr o.fl. (2018) en

þar kom fram hvernig opið vinnurými í uppsköluðu Agile hvatti á skilvirkan hátt til

samræmingar teyma. Það kom ekki skýrt fram í rannsókninni hvort þetta væri raunin því

skoðanir viðmælenda voru misjafnar innan sama fyrirtækis og því ekki hægt að segja til um

hvort vinnurými ýti undir samræmingu teyma. Rannsakandi hnaut aðeins um þá tilhögun að

staðalbúnaður í slíku rými séu hljóðeinangrandi heyrnatól því það hlýtur að vera örlítil

mótsögn fólgin í því að vinna í opnu vinnurými til að auka samvinnu en vera samt á ákveðinn

hátt einangraður frá umheiminum.

84

Það fyrirtæki sem hægt er að segja að hafi náð bestum árangri af fyrirtækjunum fimm í

sínu starfi í uppsköluðu Agile er byggt upp úr mörgum minni fyrirtækjum og tók út hraðan

vöxt á sínum tíma en hefur fundið ákveðið jafnvægi milli stjórnunar og sjálfstæði teyma í

sínum aðferðum. Segja má að valdefling og frelsi einkenni heildarmenningu þess og styður

slík menning vel við uppskalað Agile. Áhersla er lögð á valdeflingu starfsmanna sem virðist

nást á sama tíma og ákveðnum strúktúr er viðhaldið í teymisvinnunni og í þróunarferlinum.

Valdefling kemur þarna fram sem árangursþáttur í uppsköluðu Agile. Leiða má líkum að

því að við að færa valdeflinguna lengra og út fyrir teymin muni það ýta undir og hvetja til

sjálfsprottinnar samvinnu og samræmingar í aðferðum uppskalaðs Agile. Þessa áherslu má

tengja við samkeppnissjónarmið en markaður hugbúnaðar einkennist af mikilli samkeppni,

hröðum breytingum og stöðugri nýsköpun. Það má því kannski draga ályktanir, þó ekki sé

hægt að fullyrða, um að valdefling starsfmanna á öllum stigum uppskalaðs Agile skili sér í

aukinni framleiðni, meiri nýsköpun og betri samkeppnisstöðu.

6.3 Markviss innleiðing Agile aðferðafræðinnar

Leitast var við að kanna hvort Agile hugmyndafræði hefði verið markvisst innleidd í

fyrirtækin sem heild og þannig náð fótfestu í menningu þeirra og stjórnun. Í ljós kom að

ekkert markvisst starf hefur verið í neinu þessara fyrirtækja til að innleiða Agile sem einhvers

konar heildaraðferðafræði fyrir fyrirtækið. Aftur á móti höfðu einstaka deildir fyrirtækjanna

utan hugbúnaðarþróunar tekið upp aðferðafærði Agile og voru að vinna í sprettum, bæði

Scrum og Kanban. Þetta er líklega meira tengt kenningu um að ákveðin grasrót hafi myndast

hér á landi í kringum Agile og aðferðafræðin smitist út frá fólki sem vinnur af ástríðu í sínu

Agile starfi.

Til að uppskalað Agile sé árangursríkt er mikilvægt að fyrirtækjamenning sé þannig að

hún styðji við Agile hugmyndafræðina, en þetta kom fram hjá Misra (2010) en Cavaleri og

Obloj (1993) segja það vera áskorun að ná því fram að menningin styðji við aðferðafræðina.

Sú heildstæða fyrirtækjamenning sem gott væri að ná fram í fjölteyma umhverfi er talin

einkennast af trausti, samvinnu og því að deila þekkingu frjálslega. Að ná fram þessari

fyrirtækjamenningu virtist ekki vera einfalt og bæði við hraðan vöxt og við samruna margra

fyrirtækja getur menning orðið sundurleit. Skort á þeirri tegund menningar sem ýtir undir

þekkingarmiðlun má tengja við niðurstöður Xu (2009) um að þau verkefni sem nota

uppskalað Agile geti vantað samræmingu og upplýsingaflæði. Það getur reynst talsverð

85

áskorun að reyna að stýra menningunni í þá átt að hún styðji við starf uppskalaðs Agile og

gæti markviss innleiðing Agile hugmyndafræðinnar í fyrirtæki sem heild hjálpað til við að ná

fram slíkri menningu.

86

7 Lokaorð

Lítið sem ekkert er til af rannsóknum um uppskalað Agile starf á Íslandi en slíkt starf hefur

farið ört vaxandi á undanförnum árum. Agile aðferðafræðin hefur verið mikið notuð meðal

sprotafyrirtækja og lítilla hugbúnaðarfyrirtækja en aðferðafræðin var upphaflega þróuð fyrir

slík fyrirtæki. Meðfram fjórðu iðnbyltingunni og þeim tækninýjungum sem henni fylgja hefur

hugbúnaðarþróun dreift sér inn í hin ýmsu fyrirtæki. Hugbúnaðarþróunardeildir eru farnar

að stækka og fleiri og fleiri eru farnar að nýta sér Agile aðferðafræðina á stærri skala en hún

var upphaflega hugsuð fyrir. Þetta veldur ákveðnum vandkvæðum sem fyrirtæki eru að

takast á við og leysa á þann hátt sem hentar þeim best.

Vaxandi vinsældir uppskalaðs Agile eru til vitnis um ágæti Agile aðferða í

hugbúnaðarþróun því þrátt fyrir vitneskju um margvíslegar áskoranir við innleiðingu

uppskalaðs Agile halda fyrirtæki áfram að innleiða það. Helstu kostir uppskalaðs Agile eru

meðal annars aukin samvinna sem leiðir til nýrrar þekkingar og þess að komast fyrr á

markað. Stór verkefni eru brotin niður í minni og viðráðanlegri einingar og geta þannig fyrr

lagt sitt af mörkum í virðissköpun fyrirtækja. Einn árangursþáttur uppskalaðs Agile virðist

vera valdefling, en hún ýtir undir sjálfsprottna samvinnu sem nauðsynleg þykir í árangursríku

starfi í uppsköluðu Agile, en þetta samspil skilar sér í aukinni framleiðni og nýsköpun. Helsta

áskorun þess að starfa með uppskalað Agile er að að finna jafnvægi sjálfstæðis og stjórnunar

til að missa ekki tökin á þróuninni og heildaryfirsýninni við slíka valdeflingu. Stöðug

nýsköpun og lágmörkun sóunar er grundvöllur þess að viðhalda samkeppnisstöðu samhliða

hröðum breytingum og tækninýjungum á markaði.

Líkur benda til þess að uppskalað Agile eigi eftir að ryðja sér til rúms ennfrekar og jafnvel

dreifast út fyrir svið hugbúnaðarþróunar. Þær fyrirfram ákveðnu aðferðir sem ætlaðar eru til

starfa í uppsköluðu Agile eru ekki endilega líklegar til að ná almennri fótfestu en þó

mögulegt að þær verði notaðar sem grunnur til að byggja á. Fyrirtæki eru í grunninn ólík og

erfitt að ætla að setja þau öll undir sama hatt og því grundvallaratriði að þær aðferðir sem

þau nota séu aðlagaðar að þeirri starfsemi og því samhengi sem þau starfa í.

Frekari rannsókna er þörf á þessu sviði til að draga betur fram árangursþætti Agile

aðferða á svo stórum skala og hvernig slíkt starf skilar sér í auknu virði fyrir fyrirtæki. Einnig

væri áhugavert að skoða upplifun annarra deilda á Agile starfi hugbúnaðarþróunar og

hvernig hægt væri að þróa aðferðir áfram í meiri samvinnu við þær.

87

Heimildaskrá

Alqudah, M. og Razali, R. (2017). A comparison of scrum and Kanban for identifying their selection factors, Electrical Engineering and Informatics (ICEEI), 6th International Conference, 1–6. doi: 10.1109/ICEEI.2017.8312434

Ambler S. W. (2008). Agile Software Development at Scale. Í B. Meyer, J. R. Nawrocki og B. Walter (ritstjórar), Balancing Agility and Formalism in Software Engineering. CEE-SET 2007. Lecture Notes in Computer Science, 5082, bls. 1-12. Berlin og Heidelberg: Springer. https://doi.org/10.1007/978-3-540-85279-7_1

Ambler, S. W. og Lines, M. (2012). Disciplined Agile delivery: A practitioner‘s guide to Agile software delivery in the enterprise. Upper Saddle River: IBM press.

Arthur, J. (2007). Lean Six Sigma demystified: A self teaching guide. New York: McGrawHill.

Barney, S. og Wohlin, C. (2009). Software product quality: ensuring a common goal. Í Q. Wang, V. Garousi, R. Madachy og D. Pfahl (ritstjórar), Trustworthy software development processes. ICSP 2009. Lecture notes in computer science (bls. 5543). Berlin og Heidelberg: Springer.

Beck, K. (1999). Embracing change with extreme programming, Computer 32(10), 70–77.

Beck, K. o.fl. (2001). Manifesto for Agile Software Development. Agile Alliance. Sótt 16. febrúar 2019 af http://Agilemanifesto.org/

Boehm, B. og Turner. R. (2005) Management challenges to implementing Agile processes in traditional development organizations. IEEE Software, 22(5) 30–39.

Carlile, P. R. (2002). A pragmatic view of knowledge and boundaries: Boundary objects in new product development. Organization science 13(4), 442–455.

Cavaleri, S. og Obloj, K. (1993) Management Systems: A Global Perspective. Belmont: Wadsworth Publishing Company.

Chung M. W. og Drummond B. (2009). Agile at yahoo! from the trenches. Agile Conference, 2009. AGILE ’09, 113–118.

Cohn, M. og Ford, D. (2003). Introducing an Agile process to an organization, software development. Computer 36(6), 74–78.

Dikert, K., Paasivaara, M. og Lassenius, C. (2016). Challenges and success factors for large-scale Agile transformations: A systematic literature review. Journal of Systems and Software, 119, 87–108.

Dingsøyr, T. og Moe, N. B. (2013). Research challenges in large-scale Agile software development. SIGSOFT Software Engineering Notes 38(5), 38–39.

88

Dingsøyr, T., Moe, N.B., Fægri, T.E. og Seim, E.A. (2018). Exploring software development at the very large-scale: a revelatory case study and research agenda for Agile method adaptation, Empirical Software Engineering, 23(1), 490-520.

Duncan, S., (2018). Nexus Framework for Scaling Scrum. Software Quality Professional. 21(1), 51–52.

Dybå, T. og Dingsøyr, T. (2008). Empirical studies of Agile software development: a systematic review, Information and Software Technology, 50(9-10), 833–859. doi:10.1016/j.infsof.2008.01.006

Dybå, T. og Dingsøyr, T. (2009). What do we know about Agile software development, IEEE Software, 26(5), 6–9.

Ebert C. og Paasivaara M. (2017). Scaling Agile, IEEE Software, 34, 98–103.

Eðvald Möller og Snorri Fannar Guðlaugsson.(2013). Straumlínustjórnun. Í Ingjaldur Hannibalsson (ritstjóri), Rannsóknir í félagsvísindum XIV. Reykjavík: Háskólaútgáfan.

Eklund, U., Olsson, H., og Strøm, N. J. (2014). Industrial challenges of scaling Agile in mass-produced embedded systems. Í T. Dingsøyr, N. B. Moe, R. Tonelli, S. Counsell, C. Gencel, and K. Petersen (ritstjórar). Agile Methods: LargeScale Development, Refactoring, Testing, and Estimation 199, 30–42, Heidelberg: Springer.

Hamed, A. og Abushama, H. (2013). Popular Agile approaches in software development: review and analysis. Computing, Electrical and Electronics Engineering (ICCEEE), 2013 International Conference, 160–166. doi:10.1109/ICCEEE.2013. 6633925.

Hines, P., Holwe, M. og Rich, N. (2004). Learning to evolve: A review of contemporary lean thinking. International Journal of Operations & Production Management, 24(9/10), 994–1011.

Hossain E., Babar M. A. og Paik H. (2009). Using scrum in global software development: a systematic literature review. Proceedings of the 2009 Fourth IEEE International Conference on Global Software Engineering, IEEE Computer Society, Washington, DC, USA, 9, 175–184

Kalenda, M., Hyna, P. og Rossi, B. (2018). Scaling Agile in large organizations: Practices, challenges, and success factors. Journal of Software-Evolution and Process, 30(10). doi:10.1002/smr.1954

Kniberg, H. (2014, mars). Spotify engineering culture (part 1). Sótt 2. mars 2019 af https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/

Kniberg, H. (2014, mars). Spotify engineering culture (part 2). Sótt 2. apríl 2019 af https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/

89

Lal R. og Clear T. (2018) Enhancing product and service capability through scaling agility in a global software vendor environment, Proceedings of the 13th Conference on Global Software Engineering, Gothenburg, Sweden

Larman C. og Vodde B. (2010). Practices for scaling lean & Agile development: large, multisite, and offshore product development with largescale scrum. Boston: Pearson Education.

Leffingwell, D. (2007). Scaling Software Agility: Best Practices for Large Enterprises The Agile Software Development Series. Boston: Pearson Education.

Leffingwell, D.,Yakyma A., Knaster R., Jemilo D. og Oren I. (2018, maí). SAFe R 4.5 Reference Guide: Scaled Agile Framework R for Lean Software and Systems Engineering. Boston: Addison-Wesley Professional

Lindvall, M., Muthig, D., Dagnino, A., Wallin, C., Stupperich, M., Kiefer, D., May, J. og Kahkonen, T., (2004) Agile software development in large organizations. Computer, 37(12), 26–34.

Livermore J. A. (2008b). Factors that significantly impact the implementation of an Agile software development methodology. Journal of Software, 3(4), 31–36.

Long K. og Starr D. (2008). Agile supports improved culture and quality for healthwise. Agile, 2008. AGILE ‘08 Conference, 160–165.

Mansor, Z., Yahya, S. og Arshad, N.H. (2011). Towards the Development of Success Determinants Charter for Agile Development Methodology. Internantional Journal of Information Technology and Engineering, 2(1), 1–7.

McGregor, L. og Doshi, N. (2018) Why Agile goes awry and how to fix it Harvard Business Review. Sótt 4. mars 2019 af https://hbr.org/2018/10/why-Agile-goes-awry-and-how-to-fix-it

Medium.com (2018). Exploring key elements of spotify‘s Agile scaling model. Sótt 2. Apríl 2019 af https://medium.com/@media_75624/exploring-key-elements-of-spotifys-Agile-scaling-model-471d2a23d7ea

Merriam, S. B. (2009). Qualitative research. A guide to design and implementation (2. útgáfa). San Francisco: Jossey-Bass.

Misra, S. C., Kumar, V. og Kumar, U. (2010). Identifying some critical changes required in adopting Agile practices in traditional software development projects. International Journal of Quality and Reliabilty Managing, 27(4), 451–474.

Moe, N. B., Smite, D., Hanssen, G. K. og Barney, H. (2014). From offshore outsourcing to insourcing and partnerships: four failed outsourcing attempts. Empirical Software Engineering, 19(5), 1225–1258. doi:10.1007/s10664-013-9272-x

90

Murphy P. og Donnellan B. (2009). Lesson learnt from an Agile implementation project. Í P. Abrahamsson, M. Marchesi og F. Maurer (ristjórar), Agile Processes in Software Engineering and Extreme Programming. XP 2009. Lecture Notes in Business Information Processing, 31, 136–141. Doi: https://doi.org/10.1007/978-3-642-01853-4_17

Nerur, S., Mahapatra, R. og Mangalaraj, G., (2005). Challenges of migrating to Agile methodologies. Communication of the ACM, 48(5), 72–78.

O’Connor C. (2011). Anatomy and physiology of an Agile transition. Agile, 2011. AGILE ‘11 Conference, 302–306.

Olszewska M., Heidenberg J., Weijola M., Mikkonen K. og Porres I. (2016). Quantitatively Measuring a Large-scale Agile Transformation. Journal of systems and software 117, 258–273.

Paasivaara, M. (2017). Adopting SAFe to Scale Agile in a Globally Distributed Organization, Proc. IEEE 12th International Conference of Global Software Engineering, 36–40.

Paasivaara, M., Lassenius, C., Heikkila, V., Dikert, K. og Engblom, C. (2013). Integrating global sites into the lean and Agile transformation at ericsson. Global Software Engineering (ICGSE), 2013 IEEE 8th International Conference, 134–143. doi:10.1109/ICGSE.2013.25.

Paasivaara, M., Behm, B., Lassenius, C. og Hallikainen, M. (2014). Towards rapid releases in large-scale xaas development at ericsson: A case study. Global Software Engineering (ICGSE), 2014 IEEE 9th International Conference, 16–25. doi:10.1109/ICGSE.2014.22

Paasivaara, M., Behm, B., Lassenius, C. og Hallikainen, M. (2018). Large-scale Agile transformation at Ericsson: A case study. Empirical Software Engineering, 23(5), 2550–2596.

Pikkarainen, M., Haikara, J., Salo, O., Abrahamsson, P. og Still, J. (2008). The impact of Agile practices on communication in software development. Empirical Software Engineering, 13(3), 303–337.

Rigby, D. K., Sutherland, J. og Noble, A. (2018) Agile at Scale. Harvard Business Review, maí júní tölublað, 88–96.

Scaled Agile Inc. (2018, nóvember). SAFe 4.6 Introduction A Scaled Agile, Inc. White Paper. Overview of the Scaled Agile Framework for Lean Software and Systems Engineering tech. rep.Scaled Agile. Sótt 19. mars 2019 af https://www.scaledAgile.com/resources/safe-whitepaper/

Schwaber, K. og Beedle, M. (2002). Agile software development with scrum (Series in Agile software development). Boston: Pearson Education.

Serrador, P. og Pinto, K. (2015). Does Agile work? — A quantitative analysis of Agile project success. International Journal of Project Management 33, 1040–1051.

91

Smite, D., Moe, N. B., Sablis, A. og Wohlin, C. (2017). Software teams and their knowledge networks in large-scale software development. Information and Software Techology, 86, 71–86.

Smith, B. (2015) Intuit’s CEO on Building a Design-Driven Company, Harvard Business Review. Sótt 13. febrúar 2019 af https://hbr.org/2015/01/intuits-ceo-on-building-a-design-driven-company

Stettina, C. J. og Horz, J. (2015). Agile portfolio management: An empirical perspective on the practice in use. International Journal of Project Management, 33(1), 140–152. doi:10.1016/j.ijproman.2014.03.008

Sutherland, J. (2001). Agile can scale: Inventing and reinventing scrum in five companies. Cutter IT journal, 14(12), 5–11.

The LeSS Company B.V. (2014-2019). The LeSS Framework. Sótt 15. apríl 2019 af https://less.works/less/framework/index.html

VersionOne, Inc, 12th annual state of Agile development survey, (2018). Sótt 9. mars 2019 af https://resources.collab.net/featured-content/12th-annual-state-of-Agile-report

Vlaanderen, K., Van Stijn, P., Brinkkemper, S. og Van De Weerd, I. (2012). Growing into agility: process implementation paths for scrum. Product-focused software process improvement, proceedings, LNCS, 7343, 116–130.

Xu, P. (2009). Coordination in large Agile projects. The Review of Business Information Systems, 13(4), 29.

92

Viðauki 1

1. hluti: Almennt um fyrirtækið

Geturðu sagt aðeins frá uppsetningu fyrirtækisins?

Hvenær tóku þið upp Agile aðferðir?

Hvernig er skipulagi teymanna háttað?

2. hluti: Menning

Hvernig myndirðu lýsa menningu fyrirtæksins?

Hvernig hefur Agile vinnan haft áhrif á menningu fyrirtæksins í heild?

Hver eru helstu gildi fyrirtæksins?

Hvaða gildi myndir þú segja að væru mest áberandi?

3. hluti: Uppskölun Agile

Hvernig er unnið með Agile aðferðir í fyrirtækinu?

Hvaða aðferðafræði er notuð?

Hvernig er tenging og samþætting Agile aðferða við það ferli og skipulag sem fyrir er?

Hvernig hefur starf Agile í fyrirtækinu breyst með tíma?

Hvernig fór innleiðing fram?

Hverskonar þjálfun fór fram?

Hver er ykkar reynsla af notkun á Agile í stórum verkefnum?

Hversu mörg teymi hafa verið notuð í sama verkefnið?

Hvað eru þið yfirleitt að vinna með mörg teymi í einu verkefni?

Hvaða aðferðir hafið þið verið að nota í slíkum verkefnum?

Að hvaða leiti myndirðu segja að þau væru unnin öðruvísi en smærri verkefni unnin af einu teymi?

Hver var aðkoma stjórnenda eða yfirstjórnar að upptöku á Agile?

Hvernig hafa stjórnendur tekið þátt í Agile starfi?

Hvernig fer utanumhald stærri verkefna fram?

Hvernig samræmið þið verk teymanna?

93

Hvernig myndirðu lýsa samvinnu við viðskiptavini?

Hvernig eru áætlanir settar fram og unnið með þær?

Hverjar eru helstu áskoranirnar sem þið hafið þurft að takast á við?

Hvernig hafið þið brugðist við þessum áskorunum?

Hafið þið fundið fyrir þessum atriðum (ef þau hafa ekki verið nefnd)?

o Margir haghafar og mismunandi kröfur

o Samskipti og upplýsingaflæði

o Samræming aðferða og hæði teymanna hvort að öðru

o Breytingatregða

o Fyrirtækjamenning og samskipti við aðrar deildir

o Stuðningur yfirstjórnar

o Vantar leiðbeiningar frá fræðilegu efni

Hvað telur þú að hafi leitt til þess að verkefni hafi gengið vel (árangursþættir)?

Sem dæmi vinnurými

Hvernig heldur þú að þessir þættir hafi stuðlað að árangri?

Hafið þig hugsað um að nota (ef ekki nefnd ) og þá hvers vegna ekki?

o Pilot

o Sjálfsskipulagning teyma

o Notkun á einni aðferð

o Aðlögun aðferðar að þörf fyritæksins.

o Samræming með fundum

o Þjálfun

o Breytingastjórar

Hvernig eru þið að mæla árangur þessara stóru Agile verkefna?

Hvað eru þið að mæla? (ef ekki nefnt)

o Afhendingartíma

o Ánægju viðskiptvina

o Gæði vöru

Hvernig hafið þið mælt ánægju viðskiptavina?

Hvernig hefur það haft áhrif á Agile verkefnin eða vinnuna?

Hverjir myndirðu segja að væru helstu kostir við notkun á uppsköluðu Agile?