ms ritgerð verkefnastjórnun
TRANSCRIPT
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?