En fallstudie om processen, utmaningar och framgångsfaktorer under ett agilt införande inom stora IT-organisationer

48 

Full text

(1)

Örebro Universitet

Handelshögskolan - Informatik Uppsatsarbete, 15 HP

Handledare: Tanja Mäki-Runsas Examinand: Kai Wistrand HT18

En fallstudie om processen, utmaningar

och framgångsfaktorer under ett agilt

införande inom stora IT-organisationer

Ida Holme 940214 Erik Lind 940606

(2)

Sammanfattning

Vi är i ett skede där stora IT-organisationer börjar se fördelar med ett agilt arbetssätt. Fördelar i form av snabbare leveranser, ökad flexibilitet och ökad kvalitet på mjukvara. Hur kan då ett agilt införande se ut inom en stor IT-organisation? Vilka utmaningar uppkommer och vilka är framgångsfaktorerna? Studien undersökte processen av ett agilt införande på Ericssons organisations för mjukvaruutveckling. Denna fallstudie baserades på intervjuer med personer med olika roller inom Ericsson. Studien kom fram till att införandet av agilitet inom en stor IT-organisation förslagsvis har ett experimentellt tillvägagångssätt, där även anpassning har spelat en stor roll. Studien kunde identifiera flertalet utmaningar och framgångsfaktorer, bland annat utmaningar som uppkommit vid en distribuerad miljö samt framgångar genom frihet och vikten av agila coacher.

Nyckelord: Agilt införande, Agilt i stor skala, Utmaningar, Framgångsfaktorer, Process, Stor

(3)

Innehållsförteckning

1. Introduktion 1 1.1 Bakgrund 1 1.2 Syfte 3 1.3 Avgränsning 4 2. Tidigare forskning 5

2.1 Agilt i stor skala 5

2.1.1 Anledningar till ett agilt införande 5

2.1.2 Processen 5 2.1.3 Utmaningar 6 2.1.4 Framgångsfaktorer 7 3. Metod 9 3.1 Fallstudie 9 3.2 Urval 9 3.3 Datainsamling 10 3.3.1 Intervjuer 10 3.3.2 Litteratursökning 11 3.4 Analysmetod 14 3.5 Etik 15 3.6 Metodkritik 15

4. Resultat och Analys 17

4.1 Anledningar till det agila införandet 17

4.2 Processen 18 4.3 Utmaningar 24 4.4 Framgångsfaktorer 29 5. Diskussion 33 6. Slutsats 36 7. Källförteckning 38 8. Bilagor 41

8.1 Intervjuguide med Systemansvarig 41

(4)

Centrala begrepp

Dynamic systems development method (DSDM): Iterativ och inkrementell agil

systemutvecklingsmetod med fokus på skapandet av prototyper.

eXtreme programming (XP): Agil systemutvecklingsmetod med ett fokus på

programmering.

IT-organisation: I denna studie definieras IT-organisation som en organisation som bedriver

mjukvaruutveckling.

Kanban: Agil systemutvecklingsmetod med fokus på att visualisering, kontinuerlig leverans

och effektivisering.

Lean: En ideologi som går ut på att maximera kundnyttan och samtidigt minimera slöseri av

resurser genom olika typer av effektiviseringar och rationaliseringar.

Retrospektiv: Ett möte inom Scrum för att reflektera och analysera vad som gått bra och vad

som fungerat mindre bra.

Scrum: Ett iterativt och inkrementellt ramverk för agil systemutveckling.

Sprint: Ett agilt projekt delas in i sprintar som är x antal dagar långa. Inleds med en

planeringssession (Sprint planning) och avslutas med en granskning av de utlovade ändringarna (Sprint review).

Tvärfunktionella team: Ett agilt team där huvudtanken är själva sammansättningen av

teamets medlemmar. Idén är att personer med olika kunskaper och styrkor sätts ihop, där de tillsammans bildar ett team som ska kunna lösa alla typer av uppgifter.

User stories: En kort beskrivning i vardagligt språk av vad en användare vill uppnå, för att

(5)

1. Introduktion

1.1 Bakgrund

Fler och fler organisationer väljer individer och interaktioner framför processer och verktyg, fungerande programvara framför omfattande dokumentation, kundsamarbete framför

kontraktsförhandling och anpassning till förändring framför att följa en plan. Dessa värderingar kommer från det agila manifestet som revolutionerat systemutvecklingen (Mohammad, 2014).

I systemutvecklingens tidiga ålder, tidigt 60-tal, fanns det inga programmeringsstandarder eller kända metoder, vilket ledde till komplexa system som var svåra att förstå (Fitzgerald, Russo & Stolterman, 2002). Behovet av informationssystem ökade dessutom i form av att fler användningsområden tillkom och det krävdes även att fler personer var inblandade i

utvecklingen av ett enskilt system. Det fanns inte heller några pålitliga tekniker för hur informationssystem skulle utvecklas eller metoder för att estimera utvecklingstiden av ett informationssystem. Detta ledde till den så kallade software crisis, där mjukvaruproblem dominerade IT-branschen. Ett av de vanligaste problemen var att projekt överskred både tidsram och budget (Fitzgerald, Russo & Stolterman, 2002). Från detta problematiska utvecklande kom vattenfallsmodellen 1970 som resulterade i fyra faser: planering, analys, design och implementation (Fitzgerald, Russo & Stolterman, 2002). Senare kom det strukturerade, iterativa och inkrementella tillvägagångssättet som vidareutveckling av vattenfallsmodellen och dess faser (Leffingwell, 2011).

Under början på 90-talet skapades nya metoder som en motreaktion på de traditionella metoder som ansågs vara alltför dokumentdrivna och motsträviga (Beck et al., 2001c). Några av dessa metoder var Scrum och Dynamic Systems Development Methodology (DSDM) som lyckades leverera framgångsrika projekt (Highsmith, 2002). Vilket var en början till de agila praktikerna som finns idag. År 2001 samlades 17 representanter från olika metoder såsom Scrum, eXtreme programming (XP) och DSDM i en stuga i Utah. Under detta möte skapades det välkända “Agile Manifesto”, som består av fyra värderingar och 12 stycken principer, som är grunden till det agila tänkandet (Beck et al., 2001a; Beck et al., 2001b). Det är dessa värderingar och principer som skiljer det agila metoderna från de mer traditionella (Cohen,

(6)

Lindvall & Costa, 2003). Idag har manifestet fortfarande samma värderingar och principer och användandet av det agila arbetssättet ökar. En rapport från 2007 av VersionOne visade att 84% av de tillfrågade hade, i någon slags utsträckning, infört agila metoder i sin

IT-organisation. Medan deras rapport från 2010 visar att siffran är uppe på 90% och 2018 är det endast 2% som inte infört agila metoder alls i sin IT-organisation. Men det är fortfarande endast 25% av de tillfrågade vars hela IT-organisation är agila (VersionOne, 2018). När en ny metod implementeras följer användarna den ofta till punkt och pricka för att så småningom bli vana användare. När användarna förstått innebörden av metoden kan de börja anpassa metoden efter sitt team eller sin IT-organisation. Även om samma värderingar och principer kvarstår så syns det att agila metodikens framväxt att det har tillkommit nya, mer anpassade metoder. I VersionOne’s rapport från 2007 undersöks vilka agila metoder som används och metoder som nämns är XP, Scrum-XP hybrid samt DSDM. Samma rapport, fast från 2018, visade däremot även metoder som Kanban, Scrumban, Lean, FDD med fler. Genomgående i VersionOne’s rapporter (2007; 2010; 2018) framgår det att Scrum alltid har varit den mest använda agila metoden och att de skäl som väger tyngst, när en

IT-organisation ska göra ett agilt införande, har varit detsamma. Två faktorer som toppar listorna är förbättrad förmåga att ändra prioritering och snabbare leveranser, vilket även det agila arbetssättet har visat sig ge.

Till en början var agilitet främst anpassat efter mindre IT-organisationer, men i mitten av 00-talet började ledare experimentera med att applicera agila metoder på stora IT-organisationer. Genom det experimentella testandet framkom goda resultat som var uppmuntrande för fortsatt utforskande (Leffingwell, 2007). Sedan dess har utvecklingen gått framåt och fler stora IT-organisation har valt att införa ett agilt arbetssätt, exempelvis Ericsson och Nokia (Paasivaara et al., 2018).

Idag finns forskning som visar att agila arbetssättet även kan ha goda effekter på stora IT-organisationer (VersionOne, 2018). Medan annan forskning tyder på att agila metoder inte alltid är det bästa alternativet för stora projekt. Ett agilt införande på en stor IT-organisation är inte bara att införa nya metoder utan också värderingar, policys, processer, tankesätt och kultur (Dyba & Dingsoyr, 2009; Fuller, 2016). Förutom att det agila arbetssättet utgår från mindre team och mindre organisation så finns det fler anledningar till att stora

(7)

att stora organisationer har fler hierarkiska nivåer, fler genomarbetade policys samt är mer globalt spridda (Jacobsen & Thorsvik, 2008).

Studiens område har begränsat med tidigare forskning att tillgå, vilket tidigare studier

indikerar och tyder på en kunskapslucka (Paasivaara, Behm, Lassenius, & Hallikainen, 2018; Dikert, Paasivaara, & Lassenius, 2016; Dingsøyr, Moe, Fægri, & Seim, 2018). Dessa studier uppmuntrar även till framtida forskning inom agilt införande på stora IT-organisationer (Paasivaara, Behm, Lassenius, & Hallikainen, 2018; Dikert, Paasivaara, & Lassenius, 2016; Dingsøyr, Moe, Fægri, & Seim, 2018). Dessutom fokuserar den forskning som finns främst på utmaningar som en stor IT-organisation möter vid ett agilt införande. Denna fallstudie kommer därför att, utöver utmaningar, även fokusera på processen och framgångsfaktorer i syfte att skapa beskrivande- och vägledande kunskap om agilt införande i stora

IT-organisationer.

1.2 Syfte

Studiens syfte är att skapa beskrivande- och vägledande kunskap om agilt införande i stora IT-organisationer, samt fylla den kunskapslucka som identifierats av tidigare forskning. Målgruppen för denna studie är stora IT-organisationer som har viljan att påbörja ett agilt införanden.

Forskningsfrågor:

● Hur kan en stor IT-organisation gå tillväga vid ett agilt införande?

● Vilka utmaningar kan en stor IT-organisation stå inför vid ett agilt införande? ● Vilka framgångsfaktorer kan en stor IT-organisation ha under ett agilt införande? En stor IT-organisation definieras i denna studie som en organisation med fler än 1 000 anställda och bedriver mjukvaruutveckling. Antal anställda baseras på VersionOne’s studie från 2018 som avgränsar IT-organisationer i fyra grupper: mindre än 100 personer, 101–1 000 personer, 1 001–5 000 personer samt över 5 000 personer (VersionOne, 2018). Vilket gör att över 1 000 personer kan tolkas som en stor IT-organisation.

Definitionen av ett agilt införande, i den här studien, är processen som en IT-organisation genomför genom att införa de agila manifestets fyra värderingar och 12 principer (Beck et al., 2001a; Beck et al., 2001b).

(8)

1.3 Avgränsning

Informatik, som innefattar människan och IT i samverkan, är ett komplext ämne som ständigt utvecklas i takt med att världen digitaliseras. Systemutvecklingen är en stor del inom

informatiken och agil metodik är i sin tur en stor del inom systemutvecklingen. Som tidigare nämnts har stora organisationer börjat se fördelar med agilitet men de har ingen enkel väg dit. Denna studie har avgränsat sig till ett agilt införande inom en stor IT-organisation. Vilket avgränsar studiens problemområde och baseras på att ju större organisation, desto svårare blir ett agilt införande (Jacobsen & Thorsvik, 2008).

Studien har fått tillgå två intervjuer inom ett företag vars bransch är telekommunikation med ungefär 100 000 anställda (Ericsson, 2017). Respondenterna har olika roller varav ena har varit både mjukvaruutvecklare, Scrum Master och Team Leader, medan den andra är en högre uppsatt ledare som hade ett stort inflytande på IT-organisationens agila införande. En Scrum Master är en del av det agila teamet, fungerar som en coach och ser till så att teamet är produktivt medan en Team Leader agerar som chef över teamet. Genom respondenternas roller avgränsar studien sig till ett agilt införande inom en avdelning för mjukvaruutveckling med 15 000 anställda placerade runt om i världen.

(9)

2. Tidigare forskning

2.1 Agilt i stor skala

Den generella forskningen om agil metodik baseras främst på mindre organisationer och det beror delvis på att det agila arbetssättet har varit komplext att införa i större organisationer. Orsaken till detta är att agila metoder utvecklades med mindre organisationer i åtanke (Dybå & Dingsøyr, 2008). Det är först på senare tid som stora organisationer har lyckats införa agilitet och därav finns mindre forskning att tillgå.

2.1.1 Anledningar till ett agilt införande

Det är den agila metodikens goda resultat som gör att fler IT-organisationer väljer att bli agila. Tidigare forskning visar på skäl till varför IT-organisationer väljer att bli agila samt vilka resultat de ser efter att ha blivit agila. VersionOne’s 12th upplaga (2018) visar att 75% blir agila på grund av att de vill ha en snabbare mjukvaruleverans, 64% säger möjligheten att ändra prioritering och 55% svarar att öka produktiviteten. Även 49% svarar bättre anpassning och 46% ökad mjukvarukvalitet.

Vid en övergång från ett traditionellt arbetssätt till ett agilt visar tidigare forskningsresultat i form av ökad kundnöjdhet, kvalitet och bättre moral bland anställda (Cockburn & Highsmith, 2001). Andra positiva resultat är ökad synligheten över projekt, bättre affärs-anpassning och snabbare leveranser som dels beror på en ökad produktivitet bland utvecklare. Snabbare leveranser har varit en av de främsta anledningarna till att IT-organisationer har valt att övergå från ett traditionellt arbetssätt till ett agilt. Där förhoppningarna har varit att på så vis bli mer konkurrenskraftiga (Paasivaara et al., 2018). I vissa fall kan IT-organisationer även se en minskad kostnad för projekt (VersionOne, 2018).

2.1.2 Processen

Få studier syftar till att beskriva processen som en stor IT-organisation genomgår vid ett agilt införande. Utifrån den här studiens litteraturundersökning hittas ingen annan process som ger möjligheten att jämföra studiens resultat med. Därför presenteras ingen tidigare forskning i detta avsnitt. Detta visar även på den kunskapslucka som finns om agilt införande på stora IT-organisationer.

(10)

2.1.3 Utmaningar

Idag har den agila metodiken fått en stor spridning världen över, men att införa det agila inom en större IT-organisation kommer med flera utmaningar (Kalenda, Hyna & Rossi, 2018). I en litteraturstudie har Kalenda, Hyna och Rossi (2018) skapat en sammanställning av elva utmaningar som en stor IT-organisation ställs inför vid ett agilt införande. Utmaningar som motstånd till förändring, distribuerad miljö, kvalitetssäkring, integration med icke-agila delar av IT-organisationen, brist på engagemang och lagarbete, ökad press och arbetsbelastning, brist på kunskap, coaching och utbildning, kravhantering, mätning av framsteg och en aggressiv tidsplan av införandet (Kalenda, Hyna & Rossi, 2018). Dessa utmaningar styrks vidare av en fallstudie som genomförts på Ericsson skriven av Paasivaara et al. (2018). I denna fallstudie har forskarna identifierat samma utmaningar men även utmaningar i form av: så kallade “cross-site teams”, brist på ett gemensamt agilt ramverk och utmaningar vid

kravhantering (Paasivaara et al., 2018).

Nedan beskrivs tre vanligt förekommande utmaningar vid införande av agilitet inom stora IT-organisationer som är motstånd till förändring, distribuerad miljö och kravhantering

(Paasivaara et al., 2018; Javdani Gandomani & Ziaei Nafchi, 2016; Fitzgerald, Stol, O'Sullivan & O'Brien, 2013; Dikert et al., 2016).

Motstånd till förändring

Utmaningar i form av en ovilja till förändring har visats i flera olika roller inom en IT-organisation, både bland utvecklare och ledare. En ovilja bland ledare har visat sig vara den största utmaningen och att det krävs för ett lyckat införande (Kalenda, et al., 2018). Många gånger har viljan att leverera nya funktionaliteter varit större än viljan att göra en

organisationsförändring (Paasivaara et al., 2018).

Javdani Gandomani och Ziaei Nafchi (2016) visar på att tidigare vanor är svåra att bryta och därav kan ett agilt införande bli en utmaning. Rädsla var en mänsklig faktor som spelade in, där rädslan innebar en oro över att förlora sin roll eller sitt arbete inom IT-organisationen. En annan faktor som ledare visat, var oviljan att släppa på sin maktposition och låta anställda bli mer fria. Denna ovilja mot förändring har visat sig vara enormt frustrerande och tidskrävande (Javdani Gandomani & Ziaei Nafchi, 2016).

(11)

Distribuerad miljö

Det finns mycket som tyder på att en IT-organisation som är spridd runt om i världen stöter på problem med ett agilt införande. Vid ett agilt arbetssätt krävs det konstant kommunikation och en god laganda. Med spridda arbetsplatser blir det svårare att bibehålla dessa nära

relationer. Delning av information blir svårare, där det finns stor chans att information från möten och diskussioner inte når andra platser (Javdani Gandomani & Ziaei Nafchi, 2016). I vissa fall har Cross-site teams, vars medlemmar är utspridda på olika platser, förekommit då behovet av att fylla vissa kompetenser inte varit möjligt med ett lokaliserat team. Detta har då inte varit optimalt för samarbetet inom teamet, där en brist på laganda och kommunikation har lett till ett minskat förtroende till varandra (Paasivaara et al., 2018).

Kravhantering

Inom stora IT-organisationer är det vanligt att även mjukvaruprojekten är stora. Med stora projekt medföljer utmaningar när det kommer till kravhantering. Tidigare forskning har kommit fram till fyra vanliga utmaningar när det kommer till kravhantering: avsaknaden av högnivåkrav, skapandet och estimeringen av user stories, ett gap mellan lång- och

korttidsplanering samt nedbrytning av krav (Dikert et al., 2016).

Dikert et al. (2016) menar på att utvecklare vanligen finner det svårt att bryta ner högnivåkrav till mindre krav som är möjliga att göra en estimering på. Paasivaara et al. (2018) menar även på att själva nedbrytningen av krav inte var tillräcklig, vilket skapade problem med att rymma ett krav inom en sprint. Ett ytterligare problem gällande kravhantering är att en produkt backlog, som är en lista av prioriterade user stories, vanligtvis endast innehåller user stories som är planerade inom de två nästkommande delleveranser. Detta ledde till att planeringen kändes kortsiktig, men har också kunnat visa på positiva effekter genom en ökad flexibilitet till marknadsförändringar (Fitzgerald, Stol, O'Sullivan & O'Brien, 2013).

2.1.4 Framgångsfaktorer

Tidigare forskning fokuserar i majoritet på utmaningar som stora IT-organisationer stöter på vid ett agilt införande. Men några få lägger även vikt vid framgångsfaktorer, alltså faktorer som visats sig ha god inverkan på det agila införandet. Många framgångsfaktorer har visat sig vara lösningar på vanligt förekommande utmaningar.

(12)

En framgångsfaktor som tas upp i ett par studier (Amro Mohammad, 2014; Dikert et al., 2016) är att hålla intressenterna engagerade under hela införandet. Detta genom att exempelvis börja införandet med att engagera personer som är agila supportrar (Amro Mohammad, 2014) eller genom att förstå ledares viktiga roll i införandet (Denning, 2016; Dikert et al., 2016). En tuff utmaning som tidigare nämnts är ledare med motstånd till förändring och en framgångsfaktor som visar sig är att hålla ledarna engagerade under hela processen. Som en agil ledare är kommunikation en viktig aspekt och studier visar på framgångsfaktorer när ledarna kommunicerar rakt och tydligt, visar att förändringen inte är förhandlingsbar (Amro Mohammad, 2014; Dikert et al., 2016) samt är tydliga med

anledningen och nyttan av att införa ett agilt arbetssätt (Dikert et al., 2016).

En ytterligare framgångsfaktor som Denning tar upp (2016) är om en IT-organisation ser agilitet som ett tankesätt och inte endast som metoder som ska följas. Alltså att

IT-organisationen ska vara agila och inte bara använda agila metoder. Medan en annan studie pekar på företagskulturen, tidigare agil erfarenhet och ledningsstöd (Kalenda, Hyna & Rossi, 2018). Två studier talar även om att anpassa det agila arbetssättet är en viktig faktor för att lyckas (Dikert, 2016; Kalenda, Hyna & Rossi, 2018). Slutsatsen av Kalenda, Hyna & Rossis (2018) studie var att införande av agilitet inom stora organisationer inte måste följa ett

specifikt schema. De menar på att skräddarsy införandet efter behoven, men samtidigt behålla den agila metodikens kärnvärderingar och principer.

(13)

3. Metod

3.1 Fallstudie

En fallstudie baseras på ett specifikt fall som exempelvis en specifik avdelning, ett specifikt system eller ett specifikt beslut. Fallet studeras djupgående och samlar in data genom intervjuer, observationer, dokumentanalys och/eller frågeformulär för att få en detaljerad insikt i processen. Fördelen med fallstudier är möjlighet att dyka in i komplexa situationer och ger ofta data som är mer applicerbar eftersom att den ligger nära personers erfarenheter, istället för att visa på ett flertal siffror (Oates, 2006).

För att kunna besvara våra forskningsfrågor behövs en djupgående analys och datainsamling med hjälp av intervjuer för att tolka den komplexa situation som ett agilt införande på en stor IT-organisation medför. 2009 började Ericsson sitt agila införande, vilket förhållandevis var tidigt för en stor IT-organisation (Paasivaara, 2017). När de startade sitt införande fanns inget självklart ramverk att tillgå för att underlätta processen. Trots detta tycks Ericsson ha

genomfört ett lyckat införande, vilket ger en bra grund till studiens syfte. Instansen som studien fokuserar på kallas extrem instans och baseras på att fallet som studeras inte hör till normen, utan är ett fall av kontrast (Oates, 2006).

3.2 Urval

Populationen består av Ericssons organisation för mjukvaruutveckling som är ungefär 15 000 anställda. Respondenterna är två nyckelpersoner inom det agila införandet och kompletterar varandra genom sina roller. Ena respondenten hade en ledande roll över det agila införandet och den andra har haft olika roller såsom mjukvaruutvecklare, Scrum Master och Team Leader, vilket ger en bild av införandet från två olika perspektiv. När respondenterna senare citeras eller refereras till har de kommit att kallas Systemansvarig och Mjukvaruutvecklare vilket baseras på deras roller som de hade vid intervjutillfällena. Systemansvarig är den första respondenten som hade en ledande roll över det agila införandet medan Mjukvaruutvecklare är den andra respondenten vars roller har varit mjukvaruutvecklare, Scrum Master och Team Leader.

Urvalet har utförts enligt snöbollsmetoden. I snöbollsmetoden börjar urvalsprocessen med att välja ut en person, vanligtvis en informant med stor kunskap om ämnesområdet, för att få mer

(14)

information om ämnet och sedan kunna välja nya personer att tala med, därav namnet snöbollsmetoden (Jacobsen, 2017). Valet av första person att intervjua blev ingen informant, utan en respondent, då respondenten hade ett stort inflytande under själva införandeprocessen hos Ericsson. Denna intervju bidrog till en god informationsgrund om Ericssons process, vilket gjorde det möjligt att välja lämplig person för fortsatt intervju. Ett slumpmässigt urval har exkluderats då studien kommer att fokusera på ett få antal djupa intervjuer, då det annars finns en stor risk att urvalet blir skevt (Jacobsen, 2017).

Snöbollsmetoden har kombinerats med ett informationskriterium samt bredd- och

variationskriterium. Informationskriteriet har inneburit att respondenten ska ha varit en del av införandet av agilitet hos Ericsson. Bredd- och varitationskriteriet tillkom efter den första intervjun, kriteriet har inneburit att populationen har delats upp i roller. Rollerna har baserats på deras befattningar inom Ericsson under tiden för det agila införandet.

3.3 Datainsamling

Studien syftar till att undersöka och utvärdera ett fall som tidigare skett, vilket tar bort möjligheten att samla in data genom observation. Eftersom fokus ligger på att samla

djupgående data om fallet så kommer datainsamlingen ske genom intervjuer (Oates, 2006).

3.3.1 Intervjuer

När det kommer till intervjuer finns det tre olika typer: strukturerade, semistrukturerade och ostrukturerade intervjuer. I en strukturerad intervju används standardiserade och identiska frågor till varje intervju, där intervjuaren ofta har förbestämda svar. Semistrukturerade

intervjuer har fortfarande en struktur i form att intervjuaren har ett antal förutbestämda frågor som den vill ha svar på. Men däremot finns det utrymme för följdfrågor, justeringar i

befintliga frågor och respondenten får möjligheten att prata mer fritt kring ämnet. Vid ostrukturerade intervjuer har intervjuaren mindre kontroll över flödet. Intervjuaren startar oftast med att introducera ett ämne som respondenten får prata fritt kring, där intervjuaren avbryter så lite som möjligt (Oates, 2006).

Semistrukturerad intervju var den typ av intervju som var bäst lämpad för denna studie. Dels för att en semistrukturerad intervju tillåter den intervjuade att prata mer fritt från dess tankar men också att denna intervjutyp är mer passande för djupgående intervjuer (Oates, 2006). Vidare är intervjutypen även lämplig då valet av urval baserades på snöbollsmetoden samt att

(15)

respondenten på första intervjun besatt en stor mängd information om införandet av agilitet på Ericsson, både övergripande och djupgående. Därav blev det viktigt att låta respondenten både tala fritt, samtidigt som intervjun bestod av ett antal frågor som skulle besvaras. En ostrukturerad intervju hade möjligtvis kunnat anses lämplig, men eftersom att särskild data var viktigt att få fram uteslöts ostrukturerade intervjuer, då det inte hade varit möjligt att garantera täckande data.

Första intervjun hölls face-to-face på Ericssons kontor och intervjun genomfördes inom den planerade tidsramen på en och en halv timme. Vilket baserades på respondentens bakgrund om IT-organisationens agila införande samt för att samla en stor mängd information inför nästkommande intervjuer. Frågorna som ställdes, se bilagor ”Intervjuguide Systemansvarig” och ”Intervjuguide Mjukvaruutvecklare” på s.45–48, var välplanerade och syftade till att besvara forskningsfrågorna. För att intervjun inte skulle ta längre tid än planerat skedde det bortfall av vissa frågor under intervjun. Frågorna som föll bort hade antingen redan hunnit besvarats genom de tidigare frågorna eller var sedan innan lägre prioriterade för att se att de viktigaste frågorna hanns med.

Andra intervjun hölls via ett digitalt videosamtal på grund av långa distanser. Denna gång skapades frågor för att matcha en timmes intervju och anpassades utifrån respondentens olika roller under införandet, för att kunna samla data från olika perspektiv.

Båda intervjuerna hade samma upplägg och startade med en presentation om studien följt av information om inspelning. Vidare ställdes frågor som respondenten dagen innan fått ta del av via mejl, för att få tid till att förbereda sig. Ibland förekom följdfrågor samt tillfällen där frågorna behövdes förtydligas för respondenterna. För att få ut så mycket som möjligt av intervjuerna spelades de in och transkriberades.

3.3.2 Litteratursökning

Till denna studie har en litteratursökning utförts med hjälp av sökdatabaserna Google Scholar, Primo och Scopus. Sökningarna i databaserna har utförts med hjälp av ett antal relevanta nyckelord till ämnet. Nyckelorden har sedan slagits samman i olika

sökkombinationer. Sorteringsfunktionen “Peer-reviewed” har använts vid sökningar i databasen Primo för att endast få med tidigare granskad litteratur. Vid sökningar i databasen Scopus har sökningarna sorterats enligt antal citeringar, högst antal överst, där endast de

(16)

första 20 har granskats. Ett undantag gäller för den andra sökningen i Scopus med sökordet “Agile”, där utökades antal granskade artiklar till 40, på grund av den större mängden sökträffar. Vid sökning i Google Scholar har inget speciellt kriterium använts. Andra sökningen i Google Scholar, med sökorden “Scaling Agile” ledde till ett bredare och större sökresultat med 1 220 sökträffar. För att öka chansen till att finna relevant litteratur

sorterades sökresultatet efter relevans, där endast de första tio träffarna granskades.

Vid en första granskning av sökresultatet bestående av artiklar, rapporter, konferensrapporter, böcker och avhandlingar har lämplig litteratur valts ut baserat på dess titel. Lämplig titel har inneburit att titeln har en koppling till forskningsfrågorna. Av det första urvalet har en ytterligare granskning gjorts genom att läsa sammanfattning av respektive litteratur för att få en bättre förståelse. Genom en bättre förståelse av innehållet har det varit möjligt att avgöra om materialet är bidragande till studien. För att avgöra om materialet är bidragande har tre kriterier enligt Oates (2006) efterföljts: ämnet är relevant till studien, forskningen repeterar inte enbart vad andra kommit fram till samt att resultatet av forskningen har bidragit till ny kunskap. Nedan följer tabeller med sökord, antal sökträffar, granskat material samt urval. Tabell 1, Tabell 2 och Tabell 3 visar resultatet av litteratursökningen i respektive sökdatabas. Kolumn ett står för vilken sökdatabas sökningen gjordes i, samt ordningen sökningen

utfördes enligt, där nummer ett (#1) är först. Kolumn två innehåller sökordet eller sökorden och kolumn tre visar antalet träffar från dem. Kolumn fyra beskriver de träffar som granskats, där träffarna syftar till akademisk litteratur. I kolumn fem presenteras resultatet av den första granskningen, Urval 1. Kolumn sex presenterar resultatet av den andra granskningen och därmed antalet artiklar som valdes att inkluderas i studien.

Tabell 1 - Resultat av litteratursökning i Primo

Primo Sökord Antal träffar

Granskade Urval 1 Urval 2

#1 "Agile Adoption" 128 128 19 3 #2 “Large Scale Agile” 67 67 13 1

(17)

#3 "Scaling Agile"

68 68 6 1

#4 #1 AND #3 18 18 1 0

Tabell 2 - Resultat av litteratursökning i Scopus

Scopus Sökord Antal träffar

Granskade Urval 1 Urval 2

#1 “Agile Adoption” 153 20 10 1 #2 Agile 26 179 40 3 1 #3 “Scaling Agile” 69 20 5 2 #4 “Agile Adoption” AND Challenges 31 20 7 2

Tabell 3 - Resultat av litteratursökning i Google Scholar

Google Scholar

Sökord Antal träffar

Granskade Urval 1 Urval 2

#1 “Agile Adoption” AND “Scaling Agile” 273 273 31 2 #2 “Scaling 1 220 10 1 0

(18)

Agile” #3 "Large Scale Agile" AND challenges AND "Agile Adoption" 185 185 9 1

3.4 Analysmetod

Studien har samlat in data som analyserats genom tematisk analys, vilket gynnar studier som inte lutar sig mot en teori eller har en tydlig bakgrund, precis som denna (Braun & Clarke, 2006). Tematisk analys används för att identifiera och analysera data genom att finna mönster och sedan presentera data i teman (Bryman, 2018). Metoden passar för datamaterial som är baserade på semistrukturerade intervjuer och ger ofta resultat som förhållandevis är enkla att förmedla till allmänheten.

Forskningsfrågorna är relativt generella inom ämnesvalet för att kunna ge en bild av hela processen och därför kommer även beskrivningen av data vara mer generell än specifik, vilket är en bra förutsättning för en tematisk analys. Analysen är dels induktiv, vilket betyder att den styrs av den data som samlats in, men också teoretisk på så sätt att analysen samtidigt utgår ifrån forskningsfrågorna. Detta för att inte hamna utanför studiens ämnesområde men samtidigt använda den teoretiska analysens flexibilitet för att inte begränsas.

Fallstudier utan observationer har kritiken att det är svårt att få dem objektiva (Oates, 2006). Därför fokuserar studien på ett semantiskt tillvägagångssätt och ett realistiskt synsätt som inte har någon bakomliggande tanke som kan styra data, utan kommer enkelt förklarat att

presentera det data som visar sig.

Ett tillvägagångssätt för en tematisk dataanalys kan utgå ifrån sex styrande principer (Bryman, 2018):

1 – Bekanta sig med materialet 2 – Hitta initiala koder

(19)

4 – Granska, definiera och namnge teman och eventuella delteman 5 – Undersök kopplingar och samband

6 – Säkerställ relevans för framtagna teman och data

För att följa dessa steg började analysen med att de transkriberade intervjuerna lästes igenom ett par gånger för att hitta meningsbärande delar, repetitioner, likheter, skillnader och saknade data. Tolkningar av dessa uttryck diskuterades och kodades för att senare delas in i teman som identifieras och definieras utifrån vad som är relevant till våra forskningsfrågor. Därefter undersöktes materialet för att hitta kopplingar och samband. Till sist granskades alla teman och dess data för att säkerställa att de är betydelsefulla för vår studie. Temana presenteras i avsnittet för Resultat och Analys som mindre rubriker i form av text i fetstil.

3.5 Etik

Det var av stor vikt att respondenterna kände sig respekterade och betydelsefulla (Oates, 2006). Därför anpassades dag, tid och plats efter deras önskemål bortsett från en digital-intervju som gav respondenten en ännu mer flexibel plats. Vid kontakt med respondenterna användes mejl för att ge dem flexibiliteten genom att läsa och svara när det passar dem bäst. Oates talar även om (2006) vikten av att informera respondenterna om tidsuppskattning för intervjun, vilket togs till hänsyn genom att intervjuerna hade en avsatt tid och frågor kunde bortprioriteras om det blev ont om tid.

För att ge ett professionellt intryck var intervjuerna väl förberedda med intervjuguider, val av kläder och tidspassning. Innan intervjuerna informerades respondenterna om syfte och upplägg för intervjun, vilket uppfyller Brymans informationskrav (2018) för etiska aspekter i kvalitativa analyser. Vidare visades även intresse för ämnet och tacksamhet för respondentens tid. Även Brymans samtyckeskrav (2018) uppfylls då respondenterna informerats om att de själva bestämmer över sin medverkan och hur personliga uppgifter behandlas. Vilket var utifrån Örebro Universitets riktlinjer för lagring av data (Dryselius et al., 2018).

3.6 Metodkritik

Eftersom ett historiskt fall studeras och datainsamlingen främst skedde genom intervjuer så är det svårt att styrka att den data som samlades in är objektiv. Dessutom har datainsamlingen ingen möjlighet att komma från observationer utan svaren är endast från respondenternas

(20)

minne. Hade studien inkluderat fler fall så hade den kunnat varit mer övertygande (Oates, 2006). Vid tematisk dataanalys av data kan informationen bli för splittrad eftersom informationen delas upp i olika teman (Bryman, 2018).

Vid användandet av snöbollsmetoden i detta fall finns det en risk för att den person som valdes ut efter den första intervjun är vald av en speciell anledning som kan utgöra en orättvis bild av verkligheten. Det som menas är att personen som blivit vald kan ha valts på grund av att den hade en positiv bild över det agila införandet, och de personer som hade en sämre erfarenhet uteslutits. Dessutom blev det dels upp till respondenterna att finna fler

respondenter, vilket kan dra ut på tiden. I detta fall ledde det till att endast två intervjuer hann inkluderas, som i sin tur ledde till problematik med att dra generella slutsatser.

Då intervjuerna både hölls och besvarades på engelska, vilket varken var intervjuernas eller respondenternas modersmål, kan det ha påverkat båda parters formulering och förståelse för varandra.

(21)

4. Resultat och Analys

Här presenteras den data som samlats in och analyserats. Resultatet presenteras i form av olika teman som framkommit av den tematiska analysen och kännetecknas som mindre rubriker i form av fetstil. Först presenteras anledningarna till att IT-organisationen valde att bli agila för att ge en bild av varför denna IT-organisation blev agila. Vidare beskrivs processen, dess utmaningar och framgångsfaktorer.

4.1 Anledningar till det agila införandet

Sedan långt tillbaka använde IT-organisationen sig av plandriven metod och arbetade oftast bara med en kund och ett projekt i taget. Men allteftersom IT-organisationen fick fler och större kunder med fler och större projekt, som dessutom var globalt utspridda, så började de vid 2000–2001 känna att metoden snarare stjälpte än hjälpte dem. Processerna gick inte att uppdatera snabbt nog och behovet att ha en lång detaljerad dokumentation var inte längre lika nödvändig när bland annat internet och mejl fanns för att utbyta information. Vid denna tid kom metoden XP som IT-organisationen valde att testa, dock parallellt med samma gamla traditionella process i bakgrunden. Så missnöjdheten höll i sig och vid 2005 började de klura ut hur de skulle kunna förbättra situationen.

“We are getting bigger, bigger and bigger and in the year 2000 - 2001 we felt that our processes were limiting us rather than helping us, because the internet was there, email were there, exchanging information was going super fast, and all of a sudden we couldn't update the processes fast enough because the processes were very detailed, it took a lot of time to update them.”

- Systemansvarig

Efter några år såg IT-organisationen fortfarande ingen större förändring, trots flera intensiva försök till förbättring. Nu låg problemen i att processerna inte gick att uppdatera snabbt nog, vilket främst berodde på den detaljerade planen. Att ändra något i processen tog vanligtvis tre månader och involverande ett stort nätverk av människor. När detta hände, vilket det ofta gjorde, så ledde det till försenade leveranser från sex till åtta månader. Dessutom skedde optimistiska planeringar av leveranstiden och långa kravlistor som innefattade mer än vad de kunde åstadkomma. Relaterat till detta så var processerna väldigt långa och den finansiella aspekten, avkastning på investeringar, började ses som ett problem. De var inte heller helt

(22)

nöjda med kvaliteten på mjukvaran, inte helt missnöjda men ville se en förbättring. Utifrån detta definierade IT-organisationen 2008 tre saker som de skulle fokusera på att förbättra: snabbare leveranser, mer kostnadseffektiva processer och bättre mjukvarukvalitet.

“ROI, the financial aspect, we had to work longer, manage longer and so on. The quality, it was okay. Not so that it was embarrassingly low, but we felt we are not getting better, although we have been trying 4-5 years very intensively. It was these three things but it was not like “Oh let’s go agile!” it was more like “How do we solve these problems?”.”

- Systemansvarig

4.2 Processen

Det började med en öppnare organisation, där alla anställda som önskade var inbjudna att delta i IT-organisationens ledares möten. Sedan skapades även tvärfunktionella arbetsgrupper bland ledarteamet som senare de anställda frivilligt fick ansluta till. Grupperna bestod av bland annat ledare, systemansvariga, utvecklare, testare och produktägare, i syfte att få ledarna närmare hetluften. 140 anställda valde att ansluta till dessa arbetsgrupper där de började med att skapa nya projektbeskrivningar.

Systemansvarig menade att IT-organisationens ledare var tydliga med att de anställda fick testa och experimentera sig fram. När ett av IT-organisationens kontor fick höra om Scrum och agilitet, fick de gå en utbildning inom Scrum och det agila arbetssättet för att sedan testa och utvärdera resultatet. Resultatet var enligt provgruppen uppmuntrande och ledde till att IT-organisationens ledare fick upp ögonen för det agila.

“And we have also been saying: “If you want to try something out, experiment with it. It’s okay”.”

- Systemansvarig

“In one of our sites, they said “we heard about this scrum and agile, we would like to try it out”, so they got some training, and tried it out and come back from the

experiment and said that this is fantastic.” - Systemansvarig

(23)

Förberedelse av ett agilt införande

När IT-organisationen hade valt att satsa på det agila och påbörja ett införande började de med ett års förberedelser. Denna förberedelseperiod bestod av cirka nio månaders diskussion om det agila, vad det agila innebär och vad som kommer att krävas av IT-organisationen vid ett införande. Det resterande tre månaderna bestod av omorganisering och rekrytering.

“You can’t just flip the switch and then bang everything is agile.” - Systemansvarig

Efter denna förberedelseperiod krävdes det planering i form av en inlärningsplan samt kommunikationsplan för att få med hela IT-organisationen i processen. Utöver detta krävdes även en lång period av agil utbildning, som varade i cirka ett år. Sedan krävdes det riktig erfarenhet och coaching för att få ett bättre grepp om det agila.

Val av metod

Systemansvarig menade på att Scrum var den metod som valdes som utgångspunkt. Detta då Scrum gav tillräckligt mycket ramverk för att få en förståelse om det agila. De olika teamen inom IT-organisationen tilläts dock att välja fritt bland metoder efter deras behov.

Exempelvis fungerade Kanban bättre för förvaltningsteamen som hade hand om

problemrapporter. Även parprogrammering som levde kvar från IT-organisationens tidigare användning av XP används i vissa fall inom IT-organisationen.

“Kanban worked extremely well for the maintenance teams.” - Systemansvarig

Inlärning av agililtet

En första start var att anlita ett företag med mycket kunskap om det agila som kunde hjälpa IT-organisationen med rätt kunskap och utbildning. Utbildningen började med att ledarna inom IT-organisationen gick igenom en agil grundutbildning för att skapa en gemensam uppfattning. Utbildningen genomfördes sedan av den resterande delen av IT-organisationen.

“The whole leadership team went through an agile basecamp you could say, we had two days of side training and doing exercises and learning a bit about agility, the

(24)

mindset behind and so on. And that helps a lot to understand the thinking behind agility.”

- Systemansvarig

Efter denna första period av utbildning hjälpte coacherna till att upprätthålla och vägleda de anställda inom IT-organisationen. Ytterligare utbildning sattes även in som fokuserade på hur agila de anställda var. Denna utbildning fokuserade på ett antal principer och hur mycket de anställda följde dem.

Teamens uppbyggnad

Olika kompositioner för ett team har prövats och enligt Systemansvarig hade

IT-organisationen ett experiment gällande virtuella funktionsteam. Tanken var att experter från deras befintliga komponentteam valdes ut och tillsammans bildade ett virtuellt team avsatt för en speciell funktion. Dessa teammedlemmar behövde då inte vara lokaliserade på samma kontor och därav namnet virtuellt. Resultatet blev att medlemmarna i de virtuella teamen arbetade enskilt med sina uppgifter och inte tillsammans som ett lag.

“The thing is a team also needs a sort of social glue, there needs to be trust, there needs to be coherence of the team.”

- Systemansvarig

Systemansvarig menade på att efter detta experiment kom de fram till att samlokaliserade team var den bästa lösningen, där ett team vanligtvis består av sju plus/minus två

medlemmar. De valde även att göra dessa team tvärfunktionella, istället för den tidigare strukturen där utvecklare tillhörde ett departement, testare ett annat departement och så vidare. Med tvärfunktionella team suddades denna avgränsning ut och ett team bestod av alla kompetenser från de olika områdena.

Egna agila coacher

Eftersom att IT-organisationen inte hade någon tidigare erfarenhet av agilitet så ville de ta hjälp av agila coacher under införandet. De kontaktade ett konsultföretag som tyvärr inte hade tillräckligt med coacher för en så pass stor IT-organisationen och därpå såg de till att utveckla sina egna agila coacher och coaching-nätverk. Syftet med dessa coacher var att de

(25)

skulle lära sig att verkligen förstå agilitet för att sedan kunna coacha övriga medarbetare under processen gång.

“We build our own coaches, we build a coaching network so we assembled people in one place where there were trained to become agile coaches, who really understood what agility is about.“

- Systemansvarig

När det inte längre behövdes agila coacher blev de agila coacherna istället vanliga teammedlemmar, fast med en extra skicklighet.

“One thing I've seen is that we reduce the number of coaches and people who have been coaches are now becoming normal team members again with an extra skill so they can help”

- Systemansvarig

Agilt tankesätt

Respondenterna menar på att det inte räcker med att införa agila metoder för att bli agila. Utan att ett agilt tankesätt från de agila värderingar också måste implementeras.

“And I think the agile mindset also have been transported relatively well for a company at this size definitely.”

- Systemansvarig

“You can use the Scrum framework as a project or process framework and you are not getting, becoming agile at all. The mindset needs to be there.”

- Systemansvarig

Definition av att arbeta agilt

Enligt Systemansvarig arbetar IT-organisationen agilt och följer de agila manifestets värderingar någorlunda tillräckligt. För att säkerställa att principerna följs har

IT-organisationen utgått från det agila manifestets principer men skapat sina egna principer som är applicerbara på deras IT-organisation. Till principerna har IT-organisationen skapat ett

(26)

bedömningsverktyg som kan utvärdera medarbetarna och ge återkoppling om vilka principer de följer och vilka principer som de behöver bli bättre på.

“It is a self-assessment for organizations where they can look at how much do we adhere to these Product development principles and that is actually a pretty powerful tool. People can go through a list of questions and assess themselves and see if they are “red” or “green”, a traffic light scheme on that one and on the areas that you not are got you can go and work on that one.”

- Systemansvarig

Systemansvarig nämner också retrospektiv som en faktor för att se till att de följer de agila värderingar och principer. Att kontinuerligt försöka förbättra saker.

“Improvement is the most important thing. Because you need to continuously learn and improve stuff. I can say that Ericsson’s Product development principles, we have just made a retrospective from it and created a new version so we are continuously updating stuff and try to make it better and better.”.

- Systemansvarig

Mjukvaruutvecklare tycker däremot att IT-organisationen fortfarande håller på att införa agilitet. Att det fortfarande finns personer i IT-organisationen som inte tycker att det agila arbetssättet är bättre än det traditionella och att alla inte arbetar agilt.

“For me, Ericsson is a very big company and I can only talk about for what I have seen. For Ericsson, they have worked with an old fashioned way for a very long time and we have a lot of people who still insist that agile is not better than old fashioned."

- Mjukvaruutvecklare

“I can not say everyone understands how agile should work, not even all the managers”

- Mjukvaruutvecklare

De försöker fortfarande följa alla principer, men Mjukvaruutvecklare menar på att det är svårt att följa de alla.

(27)

“I feel if a team can really do more than three of them, it is a very mature team. You can not always follow all of this agile manifesto and if you look from a team

perspective, we still are trying to do this manifesto in practice, because it’s too hard to follow everything.”

- Mjukvaruutvecklare

Resultat av ett agilt införande

Tidigare nämndes tre fokusområden som IT-organisationen vill förbättra innan sitt agila införande. Dessa fokusområden var snabbare leveranser, mer kostnadseffektiva processer och bättre mjukvarukvalitet. Resultatet som visade sig var 50% mindre fel vid leverans av

mjukvara till kund, effektivare processer som krävde färre personer samt att leveranser som levererades i tid.

“By having cross-functional teams they got 50% fewer faults in on the customer effect from that one, just by co-locating people into one team with different domain competencies. Ehm this was by far more than we ever expected.”

- Systemansvarig

“Actually I think the agile transformation made it possible, our efficiency went up so much that you could work with fewer people on the same thing.”

- Systemansvarig

“We really are working on is this deliver working software frequently, we have invested a lot, and that is from a company point of view a productivity question.”

- Systemansvarig

“Previous projects always had 6-18-month delays because we find out late that is a super big problem and ehm I always say the amount of better prices is the same today. So it’s not like all of the sudden all of the problems have gone the amount of problem is the same but we are distributing them. We don’t see them only at the end, we see them coming very early, and then you have, I always say now we have micro-bad

(28)

surprise every week instead of having a super big bang surprise at the end. And the micro bad surprise every week that is so much mini thing that you can manage it.”

- Systemansvarig

4.3 Utmaningar

Vid ett agilt införande kommer som tidigare nämnts oftast ett antal utmaningar, speciellt när det kommer till större IT-organisationer (Kalenda, Hyna & Rossi, 2018). Vid detta införande var det inget undantag, utan utmaningar visades i former av brist på kunskap, nedbrytning av krav, motstånd till förändring, distribuerad IT-organisation, tolkning av agila värderingar, avsaknad av riktlinjer, större ansvar på teamnivå, balansen mellan inlärning och leverans samt bieffekter av förändringar.

Brist på kunskap

Ett agilt kunnande är viktigt vid ett införande, speciellt när det kommer till en

IT-organisations ledare. En utmaning som uppstod bland Ericssons ledare var att förståelsen av det agila inte kändes tillräcklig.

“From a leadership perspective, one of the bigger challenges I think is that you have half understood this whole thing with agile and you need to lead your organization through it and that’s again where you need some advice.”

- Systemansvarig

En brist på kunskap kunde även skapa problem bland utvecklare, där en brist på förståelse av agila termer bland utvecklare var ett problem. Ett annat problem som kunde identifieras var bristen av kunskap vad gäller olika moment inom vissa agila metoder. Ett exempel på detta var ett vanligt missförstånd över syftet med ett Daily Scrum Meeting.

“A stand-up meeting is only about the progress, what you have done and what you will do, but still in a stand up meeting people will talk in details”

- Mjukvaruutvecklare

Nedbrytning av krav vid stora och komplexa projekt

Utmaningar gällande kravhantering har främst handlat om nedbrytning av krav, där en tillräcklig nedbrytningen visat sig problematisk. Vissa krav kunde inte brytas ner tillräckligt

(29)

små för att få plats inom en sprint. Detta kan även styrkas av tidigare forskning där både Dikert et al. (2016) och Paasivaara et al. (2018) har kunnat identifiera problematiken vid nedbrytning av större eller komplicerade krav.

“Our systems are pretty complex and a requirement sometimes takes us several sprints.”

- Systemansvarig

Grundorsaken har främst varit att IT-organisationens projekt varit komplexa och därav de komplexa kraven. Denna utmaning har mildrats över tid när IT-organisationen blivit bättre på att hantera nedbrytningen av krav. Enligt Mjukvaruutvecklare hanteras nedbrytning av krav genom att kraven först bryts ner till User Stories, som sedan bryts ner till Tasks, för att vidare brytas ner till Sub-tasks. Denna nedbrytning var nödvändig enligt Mjukvaruutvecklare, då dessa Sub-tasks var tillräckligt små för att kunna implementeras inom en sprint.

Motstånd till förändring

Motstånd till förändring har främst kunnat ses genom den traditionella ledaren. Den

systemansvariga menade på att ledaren i en traditionell organisation har vuxit fram på grund av styrka och beslutsamhet, denna ledare vet redan allt och behöver inte någon annans råd. Vidare menar Systemansvarig på att när denna typ av ledare utsatts för det agila tänket har det skapats problem i form av motstånd.

“Because leaders in traditional organizations they are growing up because they are strong and determined and they make decisions and they don't need advice because they know it all already and then if you end up in a situation where they now you take advice from this person over here. That’s a challenge for these, that's why leadership recruitment is so important. Leaders need to have an attitude of learning and

understanding that you are not a master in everything.” - Systemansvarig

Därav har IT-organisationen värdesatt ledare med en attityd att vilja lära sig och förstå att du som person inte kan veta allt. Det har även visats motstridigheter gentemot viljan att låtas coachas. Motstridigheter bland ledare har även hittats av Kalenda et al. (2018), där denna utmaningen har visats vara bland det större.

(30)

Vid yngre personer har IT-organisationen sätt motsatsen. Systemansvarig menar på att yngre personer generellt varit mer mottagliga för denna typ av förändring. Denna skillnad kunde främst ses genom IT-organisationens kontor i Kina, där medelåldern bland de anställda var betydligt lägre.

“For young people, it is easier to accept new things.” - Mjukvaruutvecklare

Distribuerad organisation

Vid testandet av virtuella team upplevde IT-organisationen utmaningar med den sociala aspekten. Likt andra studier (Javdani Gandomani & Ziaei Nafchi, 2016; Paasivaara et al., 2018) blir det tydligt att samarbetet eller själva lagandan tar stryk när det gäller distribuerade team. Kommunikationen blev väsentligt sämre inom teamet och det är vanligt att

medlemmarna arbetar enskilt med sina uppgifter och att de inte har någon kommunikation alls med de övriga medlemmarna. Detta koncept var dock inget som IT-organisationen valde att fortsätta med, utan valde istället att gå över till lokaliserade team. Det är dock vanligt att det uppstår fall där funktioner är så pass stora att det behövs mer än ett team. Det andra teamet kan då mycket väl befinna sig på en annan plats och samma situation uppstår som ovan.

“For us in our early tryout it didn’t worked so well because the social glue was not coming up and those teams were not coming the high performing team that we were after. So for us the conclusion was more like co-located the best thing you can do.”

- Systemansvarig

Mjukvaruutvecklare menar på att IT-organisationen idag sköter denna process bättre med bland annat bättre tekniska möjligheter i form av videosamtal. Det har till exempel haft Daily Scrum Meetings med över 100 människor över videolänk, där resultaten varit positiva.

Tolkning av agila värderingar

Systemansvarig menar att vanlig fälla att hamna i är att endast följa de agila värderingarna på vänster sida, som är markerade nedan.

(31)

“Individer och interaktioner framför processer och verktyg” - (Beck et al., 2001a, första värderingen)

“Fungerande programvara framför omfattande dokumentation”

- (Beck et al., 2001a, andra värderingen)

“Kundsamarbete framför kontraktsförhandling”

- (Beck et al., 2001a, tredje värderingen)

“Anpassning till förändring framför att följa en plan”

- (Beck et al., 2001a, fjärde värderingen)

Detta var något systemansvarig menade att IT-organisationen upplevde när det kom till dokumentation. Dokumentationen blev lidande och valde att fokusera allt för mycket på fungerande programvara samt kommunikation (individer och interaktioner).

“This over that means the things on the right side doesn't matter, only focus on the left side. That is of course wrong, so you need to watch out that you don't go too far in one direction”

- Systemansvarig

Avsaknad av riktlinjer

Frihet var en av framgångsfaktorerna vid det agila införandet men kunde även skapa utmaningar för utvecklare och deras team.

“Teams get a lot of empowerment and freedom and some of the teams are not used to it. If you previously had detailed instructions all the time and all of the sudden the instructions are gone, then it’s confusing for people in the beginning”

- Mjukvaruutvecklare

Friheten eller avsaknaden av instruktioner kunde skapa förvirring bland utvecklare som inte var vana vid att ta egna initiativ, vilket kunde leda till en sämre effektivitet. För att dämpa denna utmaning var coacherna till en stor hjälp, där de kunde vägleda utvecklarna.

(32)

Större ansvar på teamnivå

Vid det agila införandet kom även ett större ansvar att läggas på teamet. Allt från kravhantering till leveransfrågor. Innan det agila införandet fick utvecklarna färdiga funktioner som skulle implementeras, funktioner som kravanalytiker hade brutit fram från krav. Vid det agila införandet skulle denna hantering av krav skötas av teamet, vilket var en stor omställning. Nu skulle teamet på cirka sju personer förstå och kunna sköta mycket mer än bara själva implementeringen.

“In this small group, we needed to handle a lot of things that didn't belong to the team before, like delivery things. Before we had a special group of people to handle that, but now it's up to the team to handle it”

- Mjukvaruutvecklare

Detta var enligt Mjukvaruutvecklare väldigt bra enligt ett teoretiskt perspektiv, med tvärfunktionella team som skulle kunna klara allt. I verkligheten var det ofta annorlunda.

“We are human, we can’t know everything.” - Mjukvaruutvecklare

Balansen mellan inlärning och leverans

Enligt Systemansvarig uppstod det ett problem mellan leveransen av funktionalitet och inlärningen av det agila vid starten av det agila införandet. Detta var främst ett problem för ledaren, där ledaren behövde avväga inlärningen hos de anställda kontra leveransen av funktionalitet till kund. Här finns det ett liknande problem som studien av Paasivaara et al. (2018) tog upp, där ledarens vilja att leverera nya funktionaliteter varit större än viljan att göra en förändring inom IT-organisationen.

“They should be self-organized and they should make their own learnings, but at the same time you know there is customer delivery. The customers are asking for

something and I’m not ready to jeopardize the company's reputation just because the teams haven’t learned something yet. “

(33)

Bieffekter av förändringar

Många förändringar kommer med oväntade bieffekter och Systemansvarig menar på att de alltid behövde vara uppmärksamma på dessa. En konsekvens som uppstod av det agila införandet var att även ledarteamet behövde anpassa sig utefter förändringen, detta till det negativa. Till skillnad från utvecklings teamen, passade inte det agila arbetssättet in lika bra inom ledarteamet. Detta då det agila arbetssättet inte är lika lämpat för en grupp som är spridda runt om i världen och där de inte arbetar tillsammans med en uppgift.

“Dispersed over the planet scrum is not suitable and where people are not really working together on something”

- Systemansvarig

Däremot kunde bieffekterna även vara positiva. En positiv bieffekt de såg av att ha tvärfunktionella team var att felen efter leverans minskade med 50%.

“You need to take care of all the wanted effects, the unwanted positive side effects.” - Systemansvarig

“By having cross functional teams the, we got 50% less faults in on the customer effect from that one, just by co-locating people into one team with different domain competencies. Ehm this was by far more than we ever expected.”

- Systemansvarig

4.4 Framgångsfaktorer

Trots utmaningar har IT-organisationens införande innefattat framgångsfaktorer som gynnat deras agila införande. Framgångsfaktorerna som identifieras är anpassa agiliteten, rätt ledare, involvera så många som möjligt redan tidigt i processen, kontinuerlig retrospektiv och frihet.

Anpassa agiliteten

Som tidigare nämnts i detta avsnitt har IT-organisationen utvecklat sina egna principer. Principerna kallas för “Ericsson Product Development Principles” och är utvecklade från det agila manifestet med lärdomar från Lean för att passa kontexten av denna IT-organisation. De har sex principer med två-fyra del principer samt ett bedömningsverktyg. Att även anpassa

(34)

metoderna är väldigt viktigt för att kunna nyttja agilitetens kärna, vilket även Dikert et al. (2016) tyder på.

“When after five years of doing scrum and still do it like the first day, then you have not learned anything. You have not adapted it to your needs and to your local

environment, you are not a learning organization and you missed one of the key essence of agility.”

- Systemansvarig

Systemansvarig menar också på att du behöver ha en god förståelse för metoden, innan du kan anpassa den. Till en början bör metoden följas till punkt och pricka. Sett till shuhari-modellen, ett koncept som beskriver olika stadier av lärande att behärska, är det inte förrän du är behärskare av metoden som du kan anpassa den på rätt sätt. Systemansvarig nämner dock att det är möjligt att anpassa metoden med rätt vägledning från agila coacher.

Som tidigare nämnt fick alla medarbetare, innan de blev agila, friheten att själva testa på olika metoder. När de sedan blev agila fick de fortfarande ha friheten att testa på och välja vilka agila metoder som passar dem bäst för även här anpassa det agila arbetssättet. Vilket lett till att alla team inom IT-organisationen arbetar agilt på sitt sätt.

“The thing is, people should try things out. It’s like a toolbox, in any situation you look into your toolbox and then ask yourself “in this particular task is a screwdriver or a hammer the best?”.”

- Systemansvarig

“I have worked in five different team and everyone has a different style of Scrum.” - Mjukvaruutvecklare

Rätt ledare

Systemansvarig tyder på att ledare är en viktig komponent precis som både Denning (2016) och Dikert (2016) kommit fram till. Ett agilt ledarskap reflekteras av det agila synsättet såsom samarbete och flexibilitet. Systemansvarig nämner att det handlar om att först och främst rekrytera rätt ledare och syftar till ledare som har rätt attityd och vill lära sig. Ledare

(35)

som vill ha tips från andra, till skillnad från traditionella ledare som beskrivs av

Systemansvarig som beslutsamma, självcentrerade och har en uppfattning av att de vet allt. “Because leaders in traditional organizations they are growing up because they are strong and determined. They make decisions and they don't need advice because they know it all already. Then if you end up in a situation where hey now you take advice from this person over here, that’s a challenge for these, that's why leadership

recruitment is so important. Leaders need to have an attitude of learning and understanding that you are not a master in everything.”

- Systemansvarig

Vidare menar Systemansvarig på att det är viktigt att börja med ledarna så att de kan agera så som de kommunicerar och vara bollplank för övriga medarbetare under processens gång.

“My mantra is start with the leaders. The leaders are system most system relevant, and if the leaders are not on board, if they can't walk the talk, then it won't be successful.”

- Systemansvarig

Involvera så många som möjligt redan tidigt i processen

Även om IT-organisationen rekommenderar att börja med ledarna så behövs övriga

medarbetare engageras tidigt i processen. För om du som ledare utbildas i nio månader blir det svårt att transformera alla de månaders kunskap i efterhand. Ledarorganisationen på 2000 personer involverade bland annat alla produktägare i diskussionen om hur de skulle bli agila.

“We invited them from first day in the discussion and that was one of the success

factors, also your key stakeholders you need to have very close and involved. If they are not participating in the change it would be very hard, because the moment you go on a journey and this seven work streams that was three quarter of a year. Three quarter of a year you learn lot and if you are not helping your partners to be a part of that journey. Then you have advanced 9 months into your thinking and it’s very hard to transfer this knowledge to this people, so you need to include them from the start. “

(36)

Kontinuerlig retrospektiv

Retrospektiv är väldigt viktigt för att lyckas, det nämns flera gånger av Systemansvarig och säger att det kanske är det viktigare inom det agila och ett agilt införande.

“But agile is so much about retrospective” - Systemansvarig

“I think retrospective is still the most important thing.” - Systemansvarig

“No the thing is you do something, it has effects and side-effects. Yeah and what you are doing all the time and that's why retrospective is so important”

- Systemansvarig

Frihet

Som tidigare nämnt hade IT-organisationen gett alla medarbetare en stor frihet att testa sig fram på olika vis, vilket enligt Systemansvarig visade sig ha varit en framgångsfaktor. Det var genom denna frihet som en avdelning testade på det agila arbetssättet och det är genom friheten som medarbetarna fick möjlighet att anpassa de agila metoderna.

Genom det agila införandet fick teamen även mer ansvar och medarbetarna fick även friheten att misslyckas. De menade på att misslyckanden är bra och att det är när de misslyckades som de lärde sig.

“They should be self organize and they should make their own learnings, but at the same time you know there is customer delivery. The customers are asking for

something and I’m not ready to jeopardize the company's reputation just because the teams haven’t learned something jet.”

- Systemansvarig

“When you fail you learn something, if you don’t fail you haven’t had that learning. Ehm, and when you are missing that learning it hit you at some point on the time. So actually failing is not bad, it’s actually good, you just need to fail safe.”

(37)

5. Diskussion

När en IT-organisation bestämmer sig för att bli agila, ligger grunden ofta i att de delar som de vill förbättra i sina processer matchar resultatet som ett agilt införande visar (VersionOne, 2018). IT-organisationen som denna studie har studerat hade inte riktigt samma väg till agilitet. De hade delar som de var missnöjda med i deras processer och kom fram till att fokusera på tre saker som de ville förbättra (snabbare leveranser, mer kostnadseffektiva processer och bättre kvalitet). IT-organisationen reflekterade inte över att ett agilt införande som en lösning, trots att de testat många olika alternativ som försök till en lösning.

De delar som IT-organisationen hade en önskan att förbättra matchade resultaten som ett agilt införande generellt sett ger. IT-organisationen var missnöjda med att deras processer blev sena och önskade sig snabbare leveranser. Tidigare forskning från 2007 visar att både ökad produktivitet och snabbare leveranser är resultat på att agilt införande. En till vanlig

anledning till att gå över till ett agilt arbetssätt, som tidigare forskning visar, är möjligheten till att ändra prioritering (Dikert, 2018). Detta är något som varken Systemansvarig eller Mjukvaruutvecklare nämner som ett problem men pratar däremot om förändring av krav som ett gott resultat av ett agilt införande. Förändring av krav kan däremot tolkas som att det bland annat innefattar möjligheten av omprioritering. Vidare önskade IT-organisation också att få processerna mer kostnadseffektiva samt bättre mjukvarukvalitet, vilket även detta visade sig i forskning från 2007 (VersionOne, 2007). Forskning från 2007 eller tidigare såg rikta sig inte till stora organisationer, vilket ger en förståelse för att studieobjektets IT-organisationen inte tänkte på agilitet som en potentiell lösning då de började sin diskussion om att bli agila 2008.

För att kunna besvara syftet för denna studie behövs en diskussion om IT-organisationen som studeras arbetar agilt med definitionen att processen för IT-organisationens

mjukvaruutveckling vägleds av det agila manifestets värderingar och principer.

Systemansvarig och Mjukvaruutvecklare har olika åsikter om till vilken grad principerna följs men båda är tydliga i att de strävar efter att följa dess värderingar och principer.

Systemansvarig beskriver det som att IT-organisationens medarbetare följer de flesta

principer men har några få principer att arbeta på medan Mjukvaruutvecklare uttrycker att om ett team tillsammans följer fler än tre principer så är det ett rutinerat team. Det är dock svårt att avgöra om respondenterna syftar till de 12 agila manifestets principer eller

Figur

Updating...

Referenser

Updating...

Relaterade ämnen :