Införande av devops för SME: Utmaningar och framgångsfaktorer

Utmaningar och framgångsfaktorer

INTRODUCTION OF DEVOPS FOR SME

Challenges and success factors

Examensarbete inom informationsteknologi Grundnivå 30 Högskolepoäng

Vårtermin 2020 Malin Götlind

Handledare: Jesper Holgersson Examinator: Joeri van Laere

Sammanfattning

De agila metoderna har under många år varit mycket framgångsrika inom informationssystemutveckling men enligt Balaji och Sundararajan Murugaiyan (2012) finns det även nackdelar med metoderna. En av dessa nackdelar är en flaskhals som kan finnas mellan avdelningarna utveckling och drift på ett företag eftersom dessa avdelningar ofta inte är anpassade till varandra (Laudon & Laudon, 2018). För att hantera dessa nackdelar har element från både agila metoder, Lean utveckling samt ett starkt samarbete mellan utveckling och driftavdelning bildat DevOps som har som syfte att förbättra produktionsflödet inom Informationssystemutveckling. Enligt Hemon, Lyonnet, Rowe och Fitzgerald (2019) är det många företag som planerar ett organisationsskifte mot DevOps eller är mitt uppe i förändringen. Denna förändring har visat sig vara en svår process för företag att få till då det krävs mycket resurser, tid, sociala och organisatoriska förändringar och även förändring av produkten för en del företag (Dornenburg, 2018;

Ebert & Paasivaara, 2017; Sreenivasan & Kothandaraman, 2019; Ebert, Gallardo, Hernantes & Serrano, 2016). Detta gör att ämnes- och problemområdet är intressant att undersöka för att hjälpa till att skapa ett bättre utgångsläge för företag att ta sig an förändringen mot DevOps. Med hjälp av en kvalitativ fallstudie med semistrukturerade intervjuer som datainsamlingsmetod var syftet att undersöka frågeställningen: ”Vilka utmaningar och kritiska framgångsfaktorer finns för SME vid införande av DevOps med ramverket SAFe?”. För att hjälpa till att besvara frågeställningen skapades även två delfrågor: 1: ”Vilka systemutvecklingsområden är utmanande i en DevOps-kultur?” och 2:

”Hur upplever anställda som påverkas av övergången att gå över till en DevOps-kultur?”.

Den insamlade datan har sedan kodats enligt Gillham (2008) tiostegs-process för att hitta kategorier och teman.

Resultatet av denna studies frågor visade att främst tre utmanande områden finns vid ett införande av DevOps, vilka är (1) automatisering, (2) kulturen och nya samarbeten samt (3) om produkten är komplex och utvecklad under många års tid. Resultatet avseende anställdas upplevelser visade att tids- och resursbrist var mycket framträdande hos respondenterna då de inte anser att det finns tid för att arbeta med DevOps-främjande aktiviteter. Ett annat fynd som gjorts var att de sociala förändringarna stärker vi-känslan men kan samtidigt bidra till frustration och stress, samt att inställningen till DevOps är viktig då det krävs en villighet till förändring både från ledning och de anställda när det kommer till en stor organisatorisk förändring.

Framgångsfaktorerna som denna studie resulterat i handlar mycket om att vara förberedd, planera och låta förändringen ta den tid som behövs. Det framkom även att det är en framgångsfaktor att investera i och ta vara på interna resurser och deras vilja att arbeta med DevOps-främjande aktiviteter.

Nyckelord: DevOps, Automatisering, Tidsbrist vid införande av DevOps, Utmanande områden i ett DevOps införande, SAFe DevOps, Sociala förändringar, Produktion och produktutmaningar, Investering av tid

Förord

Till en början vill jag tacka min handledare Jesper Holgersson som under hela studiens gång har stöttat och hjälpt mig i rätt riktning, stort tack för ditt engagemang. Vidare vill jag tacka

samarbetsföretaget som med sina öppna armar tog emot mig och gav mig möjlighet att få tillgång till värdefull information till denna studie. Jag vill även tacka alla respondenter som tog sig tid att medverka i studien med fullt engagemang. Denna information har hjälpt mig besvara frågeställningen i denna studie och arbeta fram ett intressant resultat. Utan ovannämnda personer hade denna studie inte varit möjlig, stort tack.

INNEHÅLLSFÖRTECKNING

1 INLEDNING 1

2 BAKGRUNDSKAPITEL 2

2.1 Systemutvecklingsmetoder 2

2.2 Agila Manifestet 3

2.3 Agil systemutvecklingsmetod i praktiken 5

2.4 Lean-Agile 6

2.5 DevOps 7

2.5.1 Utmaningar med strategier för arbetsgrupper inom DevOps 9

2.6 Scaled Agile Framework 9

2.6.1 Inriktning 10

2.6.2 Inbyggd kvalitet 10

2.6.3 Transparens 10

2.6.4 Utförande av programmet 11

2.6.5 Framgångsfaktorer och utmaningar med SAFe 11

2.7 SAFe DevOps 12

2.7.1 Huvudaspekter 12

2.7.2 Kontinuerlig leveranspipeline 14

2.8 Sammanfattning av bakgrund 15

3 PROBLEMOMRÅDE 16

3.1 Problem/fråga 17

3.2 Avgränsningar 17

3.3 Förväntat resultat 17

4 METOD 19

4.1 Vald metod 19

4.2 Fallstudie 20

4.3 Insamling av kvalitativ data 20

4.4 Analysmetod av kvalitativ data 21

4.5 Forskningsetiska principer 22

4.5.1 Informationsskyddskravet 22

4.5.2 Samtyckeskravet 23

4.5.3 Konfidentialitetskravet 23

4.5.4 Nyttjandekravet 23

5 MATERIALPRESENTATION 24

5.1 Respondenter 24

5.2 Kvalitativ data från intervjuer 24

5.2.1 Respondenternas förklaring på DevOps 24

5.2.2 Erfarenheter från tidigare försök till DevOps 25

5.2.3 Nivån av DevOps idag 26

5.2.4 Sociala förändringar med DevOps 27

5.2.5 Inställning till DevOps 28

5.2.6 Problematik innan DevOps 28

5.2.7 Flaskhalsproblem och förbättringsarbete 29

5.2.8 Ramverket SAFe och DevOps 30

5.2.9 Utmanande områden inom Systemutveckling med DevOps 31

5.2.10 Nivå av automatisering 32

5.2.11 Skillnad mellan Utvecklare och drifts syn på DevOps 32

5.2.12 Tillräckligt med investering 33

5.2.13 Hjälpande konsulter 34

5.2.14 Förbättringsarbete 35

5.2.15 Ledningens engagemang 35

5.2.16 Svårast med DevOps 36

5.2.17 Vad anses lätt i införande av DevOps 37

5.2.18 DevOps för mindre bolag 37

6 ANALYS 39

6.1 Tidsbrist försvårar arbetet mot DevOps 39

6.1.1 Tidsbrist hos drift och utveckling 39

6.1.2 Investering av tid 40

6.2 Sociala förändringar med DevOps 41

6.2.1 Nya arbetsgrupper och kompetenser 41

6.2.2 Skuldbeläggning innan och efter försök till DevOps 42

6.2.3 Anställdas inställning till DevOps 43

6.3 Utmanande områden 44

6.3.1 Automatisering 44

6.3.2 Kultur 44

6.3.3 Komplex och gammal produkt 45

6.4 Sammanfattning av analys 47

7 RESULTAT 48

7.1 Delfråga 1: Vilka systemutvecklingsområden är utmanande i en DevOps-kultur? 48

7.2 Delfråga 2: Hur upplever anställda som påverkas av övergången att gå över till en DevOps-

kultur? 49

7.3 Huvudfråga: Vilka utmaningar och kritiska framgångsfaktorer finns för SME vid införande

av DevOps med ramverket SAFe? 51

7.3.1 Utmaningar med införande av DevOps 51

7.3.2 Framgångsfaktorer för införande av DevOps 52

8 DISKUSSION 53

8.1 Resultatet 53

8.2 Forskningsmetoden 54

8.3 Samhälleliga aspekter 55

8.4 Vetenskapliga aspekter 55

8.5 Etiska aspekter 56

8.6 Objektivitet 57

8.7 Framtida forskning 57

REFERENSER 59

BILAGA 62

Bilaga A - Intervjuguide 62

1

1 Inledning

För ca 60 år sedan var inte mjukvaruutveckling något som följde tydliga metoder utan utvecklingsprocessen var ofta att koda först och sedan rätta till de problem som uppstått.

Detta passade tidens mindre systemlösningar, men med tiden blev systemen större eller behövde vidareutvecklas vilket blev svårare med taktiken att koda först och rätta till efter (Yao & Zhang, 2005). Sättet att utveckla förändrades enligt Yao och Zhang (2005) till att metoder utvecklades som medförde ett mer diciplinerat sätt att utveckla mjukvara. En metod kan ses som ett planenligt sätt, ett recept eller en vägledning för att lösa ett problem (Wiktorin, 2018). Traditionella metoder växte fram men även där visade det sig finnas problem med den snabba föränderliga utvecklingen vilket gjorde att mer flexibla agila metoder växte fram (Wiktorin, 2018).

De iterativa agila metoderna som grundar sig i det agila manifestet har visat sig vara mycket framgångsrika genom förmågan att hantera föränderliga krav och utveckla konkurrenskraftiga lösningar med hjälp av den täta kommunikationen med kunden. Men det finns även nackdelar med de agila metoderna enligt Balaji och Sundararajan Murugaiyan (2012) som är exempelvis att det kan vara svårt att bedöma tidsåtgång i större projekt och att dessa metoder kräver mer erfarna utvecklare. Utvecklingen av dessa metoder har även använt grundläggande principer från utvecklingsparadigm som Lean som först enligt Wang, Conboy & Cawley (2012) spårats till Toyotas utvecklingssystem på 1950-talet. Systemutveckling som har både Lean och Agila element nämns ofta som Lean-agile eller Leagile (Wang, Conboy & Cawley 2012). De agila metoderna strävar efter en tät kontakt mellan kunder och utvecklare för att skapa programvara med stark konkurrenskraft och snabba leveranser. Det har dock visat att det kan finnas en flaskhals mellan utvecklarna (eng. development, förkortas Dev) och driftarbetarna (eng operation, förkortas Ops) då dessa avdelningar oftast inte är anpassade till varandra vilket har lett till problematik när det kommer till prestanda (Laudon & Laudon, 2018). Ytterligare problematik som visats är enligt Hemon et al., (2019) att detta har påverkat tiden som det tar att leverera den färdiga programvaran till kunden. Ur denna problematik har DevOps-kulturen utvecklats, som innebär ett tätare samarbete mellan utvecklare och driftarbetare (Ebert et al., 2016).

Många företag är enligt Hemon et al. (2019) mitt uppe i, eller planerar ett organisationsskifte mot en DevOps-kultur, vilket inte alltid är en enkel process (Dornenburg, 2018; Ebert & Paasivaara, 2017; Sreenivasan & Kothandaraman, 2019).

Problematiken som berör detta organisationsskifte har studerats i tidigare studier som nämnts ovan, dessa berör dock stora globala bolag. Det som kommer att undersökas i denna studie är hur små till medelstora företag (SME) upplever organisationsskiftet mot en DevOps-kultur och om samma problematik upplevs även för SME som hos de globala bolagen. Med hjälp av en kvalitativ fallstudie är syftet att undersöka frågeställningen:

”Vilka utmaningar och kritiska framgångsfaktorer finns för SME vid införande av DevOps med ramverket SAFe?”.

2

2 Bakgrundskapitel

I kommande bakgrundskapitel beskrivs den bakgrundsinformation som anses viktig för de områden som kommer att behandlas i denna rapport. Detta med syftet att öka förståelsen för rapportens innehåll och problemområde.

Kapitlet kommer att beskriva sex olika begrepp som är en blandning av utvecklingsmetoder, kulturer inom systemutveckling, ett ramverk för att skala upp agil utveckling inom företag, samt en specifik del av det ramverket. För att tydliggöra hur dessa hänger samman har en modell skapats som kan ses i figur 4 i kapitel 2.8. Dessa sex begrepp kommer att förklaras närmare i egna delkapitel nedan.

2.1 Systemutvecklingsmetoder

Förr i tiden, runt år 1960, var mjukvaruutvecklingen något som skedde utan att en klar och tydlig plan fanns att följa. Utvecklarna kodade först och sedan ordnade de buggar och fel som uppstått under kodningen, detta baserat på kortsiktiga beslut som fungerade till en början (Yao & Zhang, 2005). Det här sättet att utveckla mjukvara skapade enligt Yao och Zhang (2005) problem när det kommer till att vidareutveckla systemen och att fixa de buggar som uppstod. Detta fortsatte i många år innan metoder introducerades som ändrade sättet att arbeta på (Yao & Zhang, 2005). En metod kan beskrivas som ett planenligt sätt, ett recept eller en vägledning för att utföra en uppgift som exempelvis arbeta med att lösa ett problem (Wiktorin, 2018). Metoderna innebar att mer disciplinerade processer följdes med syfte att utveckla mer förutsägbara system på ett mer effektivt sätt (Yao & Zhang, 2005). En metod hjälper till att dela in arbetet i olika steg och hjälper till att veta vilka arbetsuppgifter som används i de olika stegen (Wiktorin, 2018). Dessa olika steg kopplas sedan samman enligt Wiktorin (2018) till ett flöde av aktiviteter.

De olika metoderna som har växt fram kan oftast delas in i två olika led, traditionella och agila. De traditionella metoderna är sekvens och plandrivna, som startar processen med dokumentation och kravspecifikation som följs av en hög designutveckling vilket gör det svårare att ändra exempelvis krav efter att kravspecifikationen är klar (Yao & Zhang, 2005). Ett exempel på ett sådant flöde är vattenfallsmodellen som kan ses i figur 1.

Vattenfallsmodellen har sex olika steg som genomförs efter varandra, analys, design, utveckling, testning, implementering och underhåll. Dessa steg kan ses som ett vattenfall, när steg ett är utfört påbörjas steg två vilket gör att modellen är enkel att implementera (Balaji & Sundararajan Murugaiyan, 2012). Detta betyder att det även kan vara svårt att backa i modellen för att ändra saker två till tre steg bakåt om ett fel upptäcks i exempelvis testningen. Enligt Wiktorin (2018) kan detta göra att modellen ses som ett gammeldags sätt att utveckla system på men han menar att denna modell av systemutveckling har viktiga element som gör att det fortfarande finns intresse för modellen. En sekvensdriven metod som följer dessa steg levererar den klara mjukvaran direkt, vilket tar oss in på de mer iterativa metoderna som växte fram som en motreaktion till de plandrivna, sekvensiella arbetssätten (Wiktorin, 2018).

3 Figur 1 – Vattenfallsmodellen avritad från (Balaji & Sundararajan Murugaiyan, 2012) Enligt Yao och Zhang (2005) var det oberoende konsulter runt år 1975 som arbetade fram olika metoder som var mer iterativa vilket gjorde det lättare att anpassa förändringar under utvecklingens gång som svar på den problematik med förändringar som upplevts med tidigare traditionella metoder. Det iterativa arbetssättet levererar ofta mjukvaran i delleveranser vilket gör det lättare för anpassning (Balaji & Sundararajan Murugaiyan, 2012).

2.2 Agila Manifestet

För snart två decennier sedan kom det Agila manifestet som förändrade systemutvecklingsmetoder med sina bakomliggande principer (Dingsøyr, Nerur, Balijepally & Moe, 2012). Agila manifestet innebär ett annat sätt att arbeta med systemutveckling med andra värderingar än de traditionella utvecklingsmetoderna som exempelvis följer vattenfallsmodellen. Agila manifestet innebär att så länge det finns värde i det förstnämnda värdesätts det högre än det sistnämnda i dessa 4 punkter (Agilemanifesto, 2001):

• Individer och interaktioner framför processer och verktyg

• Fungerande programvara framför omfattande dokumentation

• Kundsamarbeten framför kontraktsförhandling

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

Agilemanifesto (2001) innehåller tolv principer som beskriver det agila tankesättet med de olika värderingarna som agila metoder generellt bygger på. Principerna handlar enligt Measey (2015) om att den högsta prioriteten ska vara att tillfredsställa kunden genom tidig och kontinuerlig leverans av programvara. Det bidrar till att kunden är mer involverad och får mer värde av produkten vid varje leverans. I och med att programvaran delas upp i mindre mer hanterbara delar ges en fördel att även kunna ändra krav under projektets gång för att skapa mer och starkare konkurrenskraft för kunden. Dessa täta leveranser ger även möjlighet att få återkoppling från kunden om det skulle vara något som inte är enligt krav eller inte fungerar som det var tänkt. Measey (2015) fortsätter med att nämna att ett nära samarbete mellan kunder, intressenter och arbetsgruppen är

4 viktigt i den dynamiska miljön som har prioriteringar och är det som skapar mervärde som ständigt ändras.

Principerna innefattar även att det är viktigt att bygga projekt kring motiverade individer (Agilemanifesto, 2001). Genom att ge individerna i arbetsgruppen tillit från överordnade menar Measey (2015) att det kommer synas i prestationen på arbetsplatsen. Han förtsätter med att det kan vara svårt att arbeta efter agila metoder om det saknas befogenheter för att utföra arbetet eller om det finns en skuldkultur på företaget. Det är även viktigt med kommunikation mellan ansikte och ansikte eftersom skriftlig kommunikation riskerar att misstolkas i och med att visuella signaler och kropsspråk inte finns med. (Measey, 2015).

En annan princip som finns med i manifestet är att det främsta måttet på framsteg är fungerande programvara (Agilemanifesto, 2001). Detta innebär enligt Measey (2015) att leverera fungerande programvara som skapar värde för kunden ofta och kontinuerligt.

För att kunna hålla den kontinuerliga leveransen utan att få utbränd personal eller stressrelaterade sjukdomar menar Measey (2015) att det är viktigt att arbeta i ett hållbart tempo som inte riskerar arbetsgruppens hälsa och programvarans kvalitet. Han menar att ett ohållbart tempo kan bidra till att personal slutar eller att programvaran tappar kvalitet som kan ge stora konsekvenser när det kommer till att stödja, underhålla och förbättra programvaran (Measey, 2015).

Något annat som hjälper till att bidra till kvalitet på programvaran är att hålla en god design från start. Measey (2015) menar att en programvara som inte håller god kvalitet från start kan få stora problem om de identifieras sent i leveranscykeln då det kan bli dyrt att åtgärda. Detta leder till att en holistisk vy över designen behövs från start och att rätt del av produkten utvecklas i rätt ordning, vilket bidrar till att riskerna för att behöva backa tillbaka och göra om delar av eller hela programvaran minskar (Measey, 2015).

En annan princip i agila manifestet är att minimera mängden arbete som inte görs. Med detta menas att fokus ska ligga på de krav som är ställda och inte sådana krav som kan tänkas komma senare då det kanske aldrig blir användbart om kravet inte kommer, vilket leder till onödigt arbete och dyrare driftkostnader för programvaran som leveraras till kunden (Measey, 2015).

Ytterligare en princip som finns i det agila manifestet handlar om hur självorganiserande arbetsgrupper behöver rätt arkitektur för att inte tappa motivationen. Detta är svårt att uppnå och bästa sättet kan vara att låta arbetsgruppen utgå från en hög plan av arkitektur och designprinciper och sedan själva anpassa den efter sin arbetsgrupp (Measey, 2015).

Den sista principen är att man med jämna mellanrum reflekterar inom arbetsgruppen över hur man kan bli mer effektiv och ändrar beteendet i arbetsgruppen därefter (Agilemanifesto, 2001). Denna reflektion kallas för retrospektiv och används för att hitta

5 processer och områden som fungerar bra och de områden som behöver förbättras (Measey, 2015).

2.3 Agil systemutvecklingsmetod i praktiken

Att vara agil betyder ”lättrörlig” vilket kan ses i de agila arbetssätten då förändringar är enkla att genomföra samt att det finns en flexibilitet att styra arbetet dit kunden vill. Detta kopplar tillbaka till de tolv agila principerna (Agilemanifesto, 2001).

Valacich och Schneider (2017) menar att agila systemutvecklingsmetoder använder en evolutionär systemutvecklingsstrategi där fokuset ligger på att utveckla små delar av en ny programvara med ständigt godkännande av kunden under projektets gång. Dessa delleveranser av programvaran skapar bättre förutsättningar för att lyckas än om en färdig programvara levereras i sin helhet efter ett långt projekt eftersom kunden och kundkraven kan ha ändrats under projektets gång. De delleveranser som sker under ett projekt skapas i kortare iterationer, ofta kallade sprints. En sprint liknas vid en spiral som börjar litet och som för varje varv bygger på produkten. Varje sprint innehåller aktiviteterna analys, design, implementering/testning samt ytterligare analys. Ett exempel på dessa steg kan ses i figur 2 där en sprint beskrivs. Efter att en sprint är genomförd sker en delleverans till kunden som då har möjlighet att ge återkoppling till utvecklarna om det är något som inte håller kraven eller förväntningarna som finns på den färdiga programvaran. Skulle det i ett sådant skede finnas problem kan utvecklarna gå tillbaka och försöka lösa problemet kostnadseffektivt och smidigare än vid traditionell utveckling eftersom det inte är hela färdiga programvaran som levereras utan delleveranser. Enligt Ambler och Holitza (2012) sker agila utvecklingsmetoder i iterationer som går runt små delar av programvaran istället för att följa ett linjärt flöde som traditionella metoder följer. Att gå tillbaka i en traditionell utveckling är däremot svårt (Ambler & Holitza, 2012). Agila metoder passar inte alla arbetsförhållanden enligt Valacich och Schneider (2017) utan det krävs att kraven på produkten är av dynamisk karaktär, är svåra att förutspå och att kunden är villig att vara involverad i projektet.

Det som saknades i tidigare traditionella metoder var en metod som omfamnar ändringar av krav även mot slutet och en metod som passar utveckling av programvara som har den karaktären att inte kunna sätta fasta färdigformulerade krav från början. Det är detta som de agila metoderna bidrar till (Valacich & Schneider, 2017).

Några av de populäraste utvecklingsmetoderna som har anammat de tolv principerna från agila manifestet är exempelvis Extreme programming (XP), Scrum, Feature-driven development (FDD) och Lean software development. Principerna som finns i det agila manifestet uppmuntrar till en praxis som omfamnar kravförändringar i alla faser av mjukvaruutvecklingen. Dessa principer ger en riktlinje för att utveckla högkvalitativ mjukvara med hjälp av någon agil metod som vuxit fram ur dem (Dingsøyr et al., 2012).

6 Figur 2 - Beskrivning av en sprint enligt beskrivning i Valacich och Schneider (2017)

Den största fördelen med agil systemutveckling är förmågan att hantera krav som förändras under utvecklingens gång (Balaji & Sundararajan Murugaiyan, 2012). Agil systemutveckling har även en fördel med att det inte sker antaganden eller chansningar mellan kunder och utvecklare då kommunikationen är tät och sker ofta ansikte mot ansikte. Men trots att den agila utvecklingsmetoden ger mycket fördelar finns det även nackdelar. Några av de nackdelar som finns är enligt Balaji och Sundararajan Murugaiyan (2012) att om projekt växer sig stora kan det vara svårt att bedöma tidsåtgång och hur stor ansträngning som krävs. Det är även en metod som kräver mer erfarna utvecklare då ett team med endast nya utvecklare kan ha svårt att ta de beslut som krävs (Balaji &

Sundararajan Murugaiyan, 2012).

2.4 Lean-Agile

Detta delkapitel har som syfte att skapa en förståelse för hur element tagna från agil och lean skapar Lean-Agile systemutveckling. Lean-Agile har element som används både inom DevOps som kommer att förklaras i 2.5 och ramverket SAFe som kommer att förklaras i 2.6.

Lean är inte unikt för systemutvecklingsområdet utan är inlånat från tillverkningsindustrin med målet att skapa ett högre flöde i tillverkningsprocessen (Wiktorin, 2018). Enligt Wang, Conboy & Cawley (2012) finns det spårat till Toyotas tillverkningssystem på 1950-talet. Lean betyder mager/smal vilket är en bra förklaring på vad Lean innebär i utvecklingssammanhang. Den kan ses som ett komplement till det agila arbetssättet (Wiktorin, 2018), eftersom Lean är ett utvecklingsparadigm som lägger fokuset på fem punkter:

• Skapande av kundvärde

• Optimera värdeflödet

• Stärka människor

• Kontinuerligt förbättras

• Eliminera onödigt arbete och spill (eng. waste).

7 Dessa fem punkter utgör de grundläggande principerna inom Lean utveckling (Ebert, Abrahamsson & Oza, 2012). Enligt Wang, Conboy & Cawley (2012) är det störst fokus på att både identifiera och eliminera onödigt arbete och spill från processerna för att kunna skapa ett stort kundvärde. Onödigt arbete och spill är enligt Wang, Conboy & Cawley (2012) saker som extra funktioner, väntetid, byten av uppgifter, extra processer, parallellt utförda arbetsuppgifter eller oanvänt material från en utvecklares egen kreativitet. Det skulle kunna vara en extra funktion som utvecklas utifrån en idé av en utvecklare men som sedan aldrig används i slutprodukten. Ebert, Abrahamsson & Oza (2012) menar att en vanlig agil utveckling ofta är bunden till team eller projekt där fokuset ligger på att göra förbättringar som att minska dokumentation och onödiga funktioner på kort sikt, men att det istället kan innebära negativa och högre kostnader för cykeltiden till slut. Inom Lean är strävan att bygga över detta gap som har uppstått. Inom Lean läggs fokus på att göra rätt från början och upptäcka och göra korrigeringar direkt och på det sättet undvika fel (Wiktorin, 2018). Det tankesättet som följs inom Lean när det kommer till mjukvaruutveckling klassar arbetet till tre olika kategorier:

Aktiviteter som lägger till värde, nödvändiga aktiviteter som inte ger något extra värde och aktiviteter som inte bidrar med något värde alls (Wang, Conboy & Cawley, 2012). I och med att programvaruutveckling är kreativt och en designorienterad disciplin menar Ebert, Abrahamsson & Oza (2012) att det kan vara svårt att tillämpa principer från olika områden, men att studier visar att alla drar nytta av starkare och mer motiverade arbetsgrupper.

En annan fördel med Lean är att produkter byggs snabbare och med bättre kvalitet när marknaden är förstådd och kravändringar hanteras på ett bra sätt. Inom Lean menar Wang, Conboy & Cawley (2012) att det finns fem ledande begrepp som är grunden till tankesättet bakom Lean. Det första är att värde definieras av kunden vilket är av största vikt. Det andra begreppet är värdeström som innebär att varje steg identifieras i processen och kategoriseras efter det värde som steget lägger till. Det tredje begreppet är flöde vilket står för vikten av att produktionsprocessen flyter kontinuerligt. Det fjärde är att processen ska vara dragande, vilket innebär att en kund beställer en produkt och inget byggs innan det behövs. Det sista begreppet är perfektion vilket innebär att det finns en strävan för perfektion i processen, vilket leder till att det kontinuerligt identifieras avfall som tas bort (Wang, Conboy & Cawley 2012).

2.5 DevOps

Kommande delkapitel ämnar förklara begreppet DevOps och vad det innebär i praktiken för att skapa en förståelse för ämnesområdet.

Genom att slå samman avdelningarna Development och Operation skapas ett organisationsskifte som benämns DevOps, vilket syftar till att öka samarbetet mellan avdelningarna för att skapa möjligheter som kan vara svåra att uppnå när avdelningarna är separerade. Dessa avdelningar hamnar oftast i ett läge som liknar två silos som endast kommunicerar med varandra genom tickets, exempelvis att utvecklarna skriver en ticket

8 om en ny version som sedan driften hanterar manuellt (Leite, Rocha, Kon, Milojicic &

Meirelles, 2019). Kommunikationen kan även ske enbart mellan teamledare och/eller chefer vilket kan vara negativt för utvecklingen eftersom det kan påverka effektiviteten av leveranser av ny programvara (Ebert et al., 2016; Hemon et al., 2019). Figur 3 ämnar ge en förklaring på hur den skadliga silostrukturen kan se ut jämfört med en DevOps- kultur. Genom samarbetet mellan avdelningar menar Ebert et al. (2016) att företag kan skapa mervärde snabbare, kontinuerligt och reducera problematik som kommer med brister i kommunikation mellan avdelningar som kan ske vid denna siloliknande uppdelning. Något som även påverkas positivt av detta arbetssätt är förmågan att lösa de problem som kan uppstå under projektens gång.

Figur 3 – Beskrivning av en silostruktur jämfört med DevOps

Det har visats att en flaskhals finns i de agila utvecklingsmetoderna mellan avdelningen operations (Ops) som sköter driften av själva programvaran och development (Dev) som utvecklar programvaran. Detta eftersom avdelningarna oftast inte är anpassade till varandra och problem som att utvecklarna inte vet eller tar hänsyn till kraven som driften har på programvaran gör att programvaran kanske inte fungerar som det är tänkt (Laudon & Laudon, 2018). Detta har visats påverka tiden det tar att leverera den färdiga programvaran till kunden (Hemon et al., 2019). Populariteten som DevOps har fått den senaste tiden menar Dornenburg (2018) kan bero på att cykeltiderna kan förkortas kraftigt när organisationer går mot en DevOps-kultur.

Det som DevOps bygger på är den agila metodens filosofi som påverkar vilka ledningsstilar som anammas, hur samarbeten utförs, kontroll, kompetensuppsättningar i arbetsgrupper, utbildning och rekrytering. DevOps främjar kulturen med tvärfunktionella arbetsgrupper där alla måste kunna förutspå nästa steg som kommer att utföras även från andra i arbetsgruppen och inte bara sina egna arbetsuppgifter. Att arbeta efter ett sådant sätt kräver att verksamheten fungerar på ett sådant vis som är förenligt med hur kod produceras, hur kod testas och hur ett leveranspaket planeras och byggs till kunden (Hemon et al., 2019). Enligt Ebert et al. (2016) krävs automatiserad utveckling, distribution och övervakning av infrastrukturen för att få detta att fungera på ett bra och effektivt sätt i organisationen.

9 Genom att ta sig an DevOps-kulturen minskar risken med att fastna i projekt som inte kommer att bli vinstgivande eller uppfylla kundens krav och förväntningar genom kontinuerlig leverans av små uppgraderingar. Bolag som Amazon och Google är enligt Ebert et al. (2016) de som varit drivande i denna utveckling och de har cykeltider på några minuter för att skicka ut nya uppdateringar. Kontinuerliga leveranser kan oftast appliceras på många olika typer av leveransmodeller men behöver ofta anpassas till organisationen och produkten. Något som är kritiskt för denna typ av kontinuerlig delleverans är enligt Bass (2017) att testning måste vara något som sker automatiskt.

Detta för att en mänsklig testprocess inte skulle hinna med i det höga flöde av uppdateringar som kan innebära att flera uppdateringar kommer per dag.

2.5.1 Utmaningar med strategier för arbetsgrupper inom DevOps

För att ta sig an DevOps-kulturen i en organisation finns tre strategier enligt Leite et al.

(2019) kring hur arbetsgruppernas uppsättning kan se ut. Det första som tas upp är samarbetande avdelningar, vilket innebär att det finns ett nära samarbete mellan avdelningarna. Denna typ av strategi kan göra att nya ansvarsområden inte blir tydliga inom organisationen och är oklara för de anställda som ingår i arbetsgruppen. Detta kan leda till friktion och frustration både mellan utvecklarna och driftarbetarna. Leite et al.

(2019) menar att denna uppsättning av arbetsgrupp kan vara speciellt utmanande om automation av leverans inte är något som är prioriterat.

Den andra startegin som Leite et al. (2019) beskriver är tvärfunktionella arbetsgrupper som ansvarar både för utvecklingen av en produkt och driften av produkten. Detta innebär att minst en i varje arbetsgrupp måste ha drifterfarenheter. Detta skulle kunna innebära att det endast behövs flytta driftanställda ut i utvecklingsgrupperna, vilket inte alltid finns möjlighet till menar Leite et al. (2019). Detta eftersom det oftast i större organisationer finns en liten grupp av driftanställda som har hand om många utvecklingsgrupper, vilket innebär att kompetensen inte räcker till och mer erfarenhet krävs i organisationen. Detta kan leda till att vissa utvecklare behöver utbildas i drift av programvara men Leite et al. (2019) beskriver att det kan vara svårt eftersom utvecklarna redan är överväldigade med nya utmaningar de behöver lära sig. En annan utmaning i denna startegi är även att utvecklarna blir ansvariga för support.

Tredje strategin kallas DevOps-teams som innebär att vara en brygga mellan utvecklarna och driften. Det kan vara bättre accepterat när det är en temporär startegi för kulturförändring men risken finns att detta skapar en tredje silo när syftet är att ta bort den skadliga silokulturen (Leite et al., 2019).

2.6 Scaled Agile Framework

Delkapitlet syftar till att förklara hur ramverket tar in element från Agil och Lean-Agile för att skala upp agil utveckling till större projekt.

Det finns enligt Wiktorin (2018) många som varnar för att skala upp de agila arbetssättet för att exempelvis utveckla komplexa system eller genomföra storskaliga projekt,

10 samtidigt som många hävdar motsatsen för att skala agil utveckling. Ett exempel på att skala det agila arbetssättet är Scaled Agile Framework (SAFe) som är en fri tillgänglig kunskapsbas som ständigt utvecklas (Wiktorin, 2018).

Kunskapsbasen som SAFe är innehåller beprövade, integrerade mönster för att skala upp Lean-agile utveckling för hela företaget. SAFe går att anpassa till företaget för att skapa bättre affärsresultat vid en anpassad tillämpning. SAFe skapades av Dean Leffingwell för att hjälpa företag att komma runt de vanliga problemen som finns när skalning av agila metoder och arbetssätt behövs. SAFe är menat att hjälpa företag att komma runt de skalningsproblem som kan uppkomma vid denna förändring. SAFe använder tre områden, agil utveckling, Lean produktutveckling och flöde samt systemtänkande (Leffingwell, Yakyma, Knaster, Oren & Jemilo, 2016). SAFe har enligt Wiktorin (2018) fått en stor internationell spridning och uppmärksamhet och är ständigt under utveckling.

SAFe har fyra grundvärderingar, Inriktning, Inbyggd kvalitet, Transparens och Utförande av programmet. Nedan beskrivs dessa grundvärderingar mer detaljerat.

2.6.1 Inriktning

Den första grundvärderingen är inriktning som är viktig för att kunna hänga med när det kommer till exempelvis störande konkurrenskraft och hastiga förändringar. Inriktningen bör förlita sig på affärsmål och inte arbetsgruppens kombinerade åsikter. Något som även är viktigt inom denna grundvärdering är kadens och synkronisering som måste användas för att säkerställa att arbetsgruppen och projektet rör sig inom både tidsram och ekonomiska gränser. Det är även viktigt att arkitekturer och användarupplevelser hjälper till att säkerställa att lösningen är robust, skalbar och tekniskt sund (Scaled Agile, 2019c).

2.6.2 Inbyggd kvalitet

För att säkerställa att programvaran håller en hög kvalitet under hela utvecklingsprocessen säkerställs kvalitet i varje del genom hela projektets gång. Desto större system som utvecklas desto viktigare är det att kvalitén hänger med och inte planeras att läggas till på slutet eftersom det då lätt blir okontrollerbart. Det är även viktigt för att säkerställa att arbetsgruppen inte arbetar med ett overifierat och ogiltigt arbete som kan resultera i omarbetning av programvaran och påverka tiden som går åt till projektet negativt. Inom SAFe är den inbyggda kvalitén en viktig del och det är främst fem olika aspekter som kvalitetssäkras, flöde, arkitektur, designkvalitet, kodkvalitet, systemkvalitet och kvalitén vid släpp av nya produkter eller uppdateringar och uppgraderingar (Scaled Agile, 2019c).

2.6.3 Transparens

Lösningsdesign är svårt om det saknas transparens, eftersom fakta då blir otydligt och beslutsfattande kan tas på antaganden som är spekulativa och att det saknas data. Detta gör att transparens är viktigt och att det behöver finnas ett förtroende för att lyckas med det på företaget. Det är mycket svårt att lösa problem runt dolda fakta eller hemligheter.

Det som grundvärderingen transparens står för är att arbetsgruppen ska agera med

11 integritet och lita på varandra för att klara av arbetet även i svårare tider (Scaled Agile, 2019c).

2.6.4 Utförande av programmet

Arbetsgrupper inom organisationer behöver kontinuerligt kunna utföra och leverera värde, därför ligger ett stort fokus på arbetssystem och affärskvalitet för att kunna möjliggöra detta. Historiskt sett försökte enskilda agila teams att leverera mer betydande mängder lösningsvärden, pålitligt och effektivt vilket var svårt och skapade frustration för det agila teamet (Scaled Agile, 2019c).

2.6.5 Framgångsfaktorer och utmaningar med SAFe

SAFe har 10 oförändliga, underliggande Lean-Agile principer och ekonomiska koncept som utgör grunden för SAFe. Dessa principer handlar i stort om (1) att vara ekonomiskt inriktad, (2) applicera systemtänkande, (3) räkna med förändring, bevara alternativ, (4) att bygga stegvis med snabba integrerade inlärningscykler, (5) basera milstolpar på en objektiv utvärdering av arbetssystemen, (6) visualisera och begränsa det pågående arbetet, minska batchstorlekar och hantera kölängderna, (7) använda kadens, synkronisera med domänplanering, (8) låsa upp egen motivation för kunskapsarbetare, (9) decentralisera besluttagandet och till sist (10) organisera runt värde (Scaled Agile, 2019d).

För att lyckas med att anamma SAFe med dess grundvärderingar och principer har Ebert och Paasivaara (2017) identifierat sex stycken framgångsfaktorer i en studie om två globalt etablerade företag som har genomfört övergången till SAFe. Framgångsfaktorerna är:

1. Anpassa ramverket till sin organisation.

2. Investera i den första programplanerings-händelsen för att göra den framgångsrik 3. Anställ externa konsulter för att utbilda och coacha

4. Intern förändring behöver genomföras kontinuerligt/aktivt av agenter 5. Starkt ledarskapsstöd

6. Reagera snabbt på feedback för att kontinuerligt förbättra och flytta adoptionens smärtpunkter

Ebert och Paasivaara (2017) nämner även att de mest kritiska utmaningarna är att det finns motstånd för förändring, bristande kommunikation när det kommer till genomförandet av övergången, att det finns brister när det kommer till kontinuerlig förbättring och brist på utbildning och stöd under övergången.

12

2.7 SAFe DevOps

Följande delkapitel har som syfte att förklara viktiga delar inom SAFe DevOps för att ge en bild av vad som DevOps innebär enligt ramverket.

2.7.1 Huvudaspekter

Inom ramverket SAFe beskrivs DevOps med CALMR som står för de fem huvudaspekterna för att uppnå kulturen DevOps. De fem huvudaspekterna är kultur (eng. Culture), Automation (eng. Automation), Lean Flöde (eng. Lean Flow), Mätningar (eng.

Measurements) och Återhämtning (eng. Recovery) (CALMR), se figur 4. Målet med att skapa en DevOps-kultur i organisationen är enligt Scaled Agile (2019a) att öka distrubitionernas kvalitet och frekvens, öka säkerheten med att exprimentera och ta risker. Detta leder då till bättre innovationsmöjligheter, snabbare marknadsföringstider och förkortade ledtider för förbättringar, skapa bättre återhämtningsförmåga vid misslyckade produktsläpp och förbättrade tider för återhämtning.

I kommande stycken förklaras de fem huvudaspekterna inom SAFe DevOps i detalj med fördelar och syfte.

Figur 4 – De fem huvudaspekterna CALMR med inspiration från Scaled Agile (2019a) 1. En kultur med delat ansvar:

Det som menas med en kultur med delat ansvar är att principer, praxis och värderingar från Lean-Agile används. DevOps bygger på förmågan att kontinuerligt samarbeta mellan de agila team och IT-driftavdelningen i organisationen. Detta samarbete leder till att lösningar utvecklas och levereras snabbt samt mer kontinuerligt. Det delade ansvaret innebär även en risktolerans som står för att fel kan uppstå men en snabb återhämtning krävs för att skapa ett belönande risktagande. Genom detta delade ansvar skapas även självständighet som inte hindrar avdelningar i sin utveckling och bidrar även med en

13 kunskapsdelning där praxis och verktyg bidrar till lärande. En stor del inom DevOps är automatisering vilket ger fördelar som snabbhet, konsekventa och repeterbara processer (Scaled Agile, 2019a).

2. Automation av kontinuerlig leveranspipeline:

Manuella processer kan vara tidskrävande, sänka produktivitet och innebära säkerhetsrisker. Detta gör att automatisering inte enbart handlar om att göra processer snabbare utan även förbättra tillförlitligheten för dessa processer och göra dem rutinmässiga. Automatisering ger även möjlighet att skapa repeterbara miljöer som underlättar att dokumentera, förstå, förbättra, granska och säkra. Automatisering skapar även snabba svar på efterfrågan från marknaden och kundåterkoppling. Det som vanligtvis automatiseras är kommunikation, sammanställning av kod och testning (Scaled Agile, 2019a).

3. Lean flöde påskyndar leveranser:

Ett ständigt flöde möjliggör för nya funktioner att snabbt nå marknaden vilket ger organisationen en kortare tid från idé till vinst. I SAFe görs detta i tre steg. Det första steget är att visualisera och begränsa det pågående arbetet. Det innebär att alla intressenter kan ta del av det pågående arbetet samtidigt som teamen kan hitta flaskhalsar under arbetets gång och motverka dem med att balansera upp arbetet mot de resurser som finns. Det andra steget är att reducera storleken på arbetet. Små arbeten bidrar till snabbare och mindre varierade släpp av produkten som i sin tur även bidrar till snabbare inlärning. Det tredje steget för att skapa ett mer ständigt flöde är att se över kötiderna som finns och försöka att reducera dem (Scaled Agile, 2019a).

4. Mätning av allt:

I SAFe DevOps miljö görs ändringar ofta vilket bidrar till en mindre komplicerad problemlösning eftersom det innebär att en annan avdelning eller grupp inte behöver felsöka och lösa problematiken som finns. Genom att automatiskt samla in data från lösningarnas både affärsmässiga och tekniska prestanda kan beslut fattas på fakta istället för på intuition. SAFe DevOps mål är att samla in mätbar data från affärs-, applikations-, infrastruktur- och klientlager och logga på ett sätt som möjliggör analyser (Scaled Agile, 2019a).

5. Återhämtning möjliggör lågriskreleaser:

För att stödja en kontinuerlig leverans av produkter eller uppdateringar och konceptet release on demand behöver systemet vara designat på ett sådant sätt att det lätt går att återhämta sig efter ett misslyckat släpp eller annan åtgärd. SAFe DevOps förespråkar även att ha en ”stop-the-line mentalitet” vilket innebär att om ett problem uppstår samlas alla för att lösa problemet och ta lärdom av det samt införa en förbättring för att förhindra att problemet händer igen. SAFe DevOps förespråkar även övning och planering av misslyckade produktsläpp eller uppdateringar då det är nästan garanterat att inträffa

14 någon gång för stora IT-applikationer. Detta ger en god återhämtningsförmåga när misslyckandet väl inträffar. För att skapa ytterligare återhämtningsförmåga vid andra fel som kan uppstå, som exempelvis serverhaveri eller andra misstag som görs behöver det utvecklas sätt för att snabbt åtgärda felen och fortsätta framåt men även att gå tillbaka till tidigare stadie om det skulle krävas. För att lyckas med att skapa denna återhämtningskraft hos organisationerna krävs ofta förbättrad arkitektur, infrastruktur och andra ickefunktionella överväganden för att stödja driftberedskap och lösningar i produktionen (Scaled Agile, 2019a).

2.7.2 Kontinuerlig leveranspipeline

Continuous exploration (CE), continuous integration (CI), continuous deployment (CD) och Release on demand (RoD) är fyra begrepp som är centrala för SAFe DevOps när Dev och Ops får ett närmare samarbete och arbetet sker via den automatiska kontinuerliga leveranspipelinen (eng. Continuous Delivery Pipeline). Dessa fyra begrepp utgör tillsammans leveranspipelinen.

CE har ett fokus på att skapa anpassning för det som ska byggas. Med marknadsproblemen och kundbehoven i fokus skapas den design som krävs för att tillgodose det behov som finns. Detta sker vanligtvis med en idé eller en marknadsundersökning som sedan resulterar i en ny funktion eller produkt (Scaled Agile, 2019b). CI har fokuset på att ta funktioner från backlog och implementera dem med hjälp av förbättring av funktioner via user stories eller användaråterkoppling på en pappersprototyp (Scaled Agile, 2019b). CD fokuserar på att ta ändringar från testmiljö till produktion där de släpps vid rätt tidpunkt. Detta ger möjlighet att återgå eller fixa till problem vid behov (Scaled Agile, 2019b). CD är en systemutvecklingsstrategi som innebär att arbetsgrupperna kontinuerligt utvecklar mjukvara i korta tidscykler där programvaran när som helst går att släppa (Chen, 2016). Denna strategi innebär en del utmaningar, speciellt i början av införandet då det krävs en stor kraftansträngning för att implementera CD (Chen, 2017). Några av utmaningarna som Chen (2017) nämner är först att det kan vara svårt att få med alla intressenter i denna stora kraftansträngning då de har fullt upp med deras dagliga arbete, egna mål och prioriteringar. CD berör många olika arbetsområden inom organisationer. För att nämna några kan det vara automatisering av kodbygge, testningsprocessen och produktleveransaktiviteter, arkitektaktiviteter, mjukvaruutvecklingsprinciper, organisationsstruktur och kultur. Eftersom det är svårt att implementera CD menar (Chen, 2017) att om fel del av organisationen väljs som första implementeringsområde kan det vara svårt att få med intressenter och visa värdet och effektiviteten som CD kan ge. RoD betyder att det går att göra värdet för kunden tillgängligt direkt, eller baserat på marknads- och kundbehov. Genom feedback från kunden kan sedan nästa steg planeras (Scaled Agile, 2019b).

15

2.8 Sammanfattning av bakgrund

Delkapitlets syfte är att ge en sammanfattning kring ämnesområdet med de begrepp som tagits upp och knyta samman dem för att öka förståelsen för studiens berörda ämnen.

Agila utvecklingsmetoder har varit ett populärt arbetssätt i snart två decennier när det kommer till systemutveckling. Agila metoder har som mål att skapa en nära länk mellan utvecklarna och kunderna för att skapa programvara med stark konkurrenskraft på marknaden och strävar efter snabb leverans. För att förbättra flödet i den agila systemutvecklingen togs vissa delar från Lean in som ett komplement (Wiktorin, 2018).

Denna kombination kallas Lean-Agile. Lean-Agila syftar till att exempelvis minska onödigt arbete och optimera värdeflödet i utvecklingen (Wang, Conboy & Cawley 2012). Detta är något som även Scaled Agile har plockat upp i sitt ramverk SAFe som har som syfte att skala upp agil systemutveckling men hjälp av både agila utvecklingsmetoder som Scrum och element från Lean-Agile (Wiktorin, 2018; Scaled Agile, 2019c).

DevOps har som syfte att genom en sammanslagning av avdelningarna Development och Operations få bort oönskad silosstruktur mellan avdelningarna och minska cykeltiden för delleveranser (Ebert et al., 2016; Hemon et al., 2019). DevOps bygger på de agila metodernas filosofi (Hemon et al., 2019), med viktiga delar för att få ner cykeltider, exempelvis med delar som automatisk testning (Bass, 2017). Inom ramverket SAFe finns en del som innehåller och beskriver DevOps utifrån deras fem huvudaspekter, CALMR (Scaled Agile, 2019a). DevOps-delen inom SAFe har grunderna från agila systemutvecklingsmetoder och Lean-Agile samt grunderna från DevOps-kulturen för att skapa kontinuerliga delleveranser (Hemon et al., 2019; Scaled Agile, 2019a). Detta kan ses i figur 5 där pilarna mellan begreppsrutorna ämnar beskriva vilka begrepp som går in i varandra där de lånat olika värderingar, principer och arbetssätt.

Figur 5 – Överblick på hur de olika begreppen relaterar till varandra

16

3 Problemområde

I detta kapitel kommer problematiken kring att uppnå DevOps-kultur diskuteras. Kapitlet kommer även ta upp anledningar som finns för mer forskning kring ämnet och vilken frågeställning som ska besvaras i studien.

Många företag står inför ett skifte från de vanliga agila metoderna som exempelvis Scrum och XP för att leda sitt företag mot en mer DevOps-kultur (Hemon et al., 2019). Tidigare forskning visar hur större bolag har problem när det kommer till att gå över till en DevOps-kultur, detta även om ramverk som SAFe används (Ebert & Paasivaara, 2017;

Sreenivasan & Kothandaraman, 2019). Det finns även forskning som visar hur stora bolag som Amazon och Google klarar att få ner cykeltider för uppdateringar av programvara till några minuter med DevOps-kultur (Ebert et al., 2016), men hur ser det ut hos mindre företag med endast ett eller några få agila team och som inte har resurser som kan jämföras med de stora ledande globala bolagen?

Det kan vara svårt för små till medelstora företag (SME) att ta till sig utmaningar och framgångsfaktorer som framkommit från studier gjorda på globala bolag (Ebert &

Paasivaara, 2017). Dessa framgångsfaktorer är exempelvis att anställa externa konsulter för att utbilda och coacha, vilket inte alltid är möjligt för SME eftersom det är för resurskrävande. Detta visar att det finns behov av att studera vilka framgångsfaktorer som även fungerar för SME men även hitta andra framgångsfaktorer som är bättre lämpade för SME. I den studie som kommer att presenteras i denna rapport definieras små till medelstora företag (SME) som företag med färre än 250 anställda enligt Europeiska kommissionen (2003) definition.

Övergångar till DevOps har visat att viss problematik kan uppstå inom stora företag.

Enligt Dornenburg (2018) handlar det om den nya sammansättningen i arbetsgrupperna där utvecklarna och driftarbetarna ska samarbeta istället för att jobba på två olika håll.

Det nya samarbetet har ökat frustrationsnivån mellan grupperna och en krock mellan gruppernas prioriteringar har setts. Detta kan bero på olika mål och prioriteringar som har funnits i grupperna när de arbetade mer åtskiljt. Utvecklarna har fått lära sig att leverera programvara inom den budget som är satt och inom tidsramen. Detta ofta på bekostnad av minskad underhållsförmåga och stabilitet av programvaran då det ej är utvecklarnas ansvar efter att programvaran är klar och de vet att de antagligen inte blir ansvariga för det senare. Driftavdelningen har däremot som prioritet att skapa kostnadseffektiv drift av programvaran och stabilitet. Eftersom det ofta krockar mellan dessa prioriteringar har det enligt Dornenburg (2018) ökat oron inför att programvara ska släppas vilket har lett till långa komplicerade formella processer som har påverkar cykeltiden negativt (Dornenburg, 2018). Problemen som Dornenburg (2018) beskriver kanske även är utbrett inom mindre företag som försöker att gå över till DevOps-kulturen, vilket är intressant att studera.

Ytterligare utmaningar som har visats i forskning är att det är en problematisk övergång när det kommer till saker som att olika arbetsgrupper inte har samma standarder för att

17 uppskatta arbete som ska utföras. Detta innebär att arbetslagens uppskattningsreferens varierar mycket vilket har resulterat i att det inte fanns något gemensamt mått på exempelvis produktivitet, storlek och ansträngning (Sreenivasan & Kothandaraman, 2019). Detta exemplet påverkade företagets största kund negativt enligt Sreenivasan och Kothandaraman (2019) då det som avgjorde kostnaden för kunden var uppskattningarna av storleken och ansträngningen.

3.1 Problem/fråga

Syftet med denna studie är att undersöka hur ett SME upplever övergången från standard agil till att gå mot en DevOps-kultur och vilka utmaningar som gör denna övergång problematisk för många företag även de med mindre resurser. Studien har även som syfte att identifiera framgångsfaktorer för att skapa en bra utgångspunkt för en övergång till DevOps-kultur. Studien kommer att fokuseras på att besvara följande frågeställning:

Vilka utmaningar och kritiska framgångsfaktorer finns för SME vid införande av DevOps med ramverket SAFe?

De nedanstående delfrågorna kommer hjälpa till att besvara frågeställningen i denna studie. Delfrågornas syfte är att rama in de område som huvudfrågan fokuserar på för att kunna besvara den bättre. Delfrågorna är följande:

1: Vilka systemutvecklingsområden är utmanande i en DevOps-kultur?

2: Hur upplever anställda som påverkas av övergången att gå över till en DevOps-kultur?

För att kunna fastställa utmaningar och framgångsfaktorer i denna studie behöver utmanande områden inom DevOps-kulturen undersökas och hittas, vilket delfråga 1 bidrar med. För att undersöka framgångsfaktorer för ett införande av DevOps-kultur behövs upplevelser och erfarenheter från personer som upplevt ett införande eller ett försök till införande, vilket delfråga 2 bidrar med.

3.2 Avgränsningar

Denna studie kommer inte att behandla andra utvecklingsmetoder som inte tillhör Lean- agile eller DevOps. Studien kommer inte att undersöka andra ramverk än SAFe som hjälpmedel för att skala upp agil utvecklingsmetod då omfattningen på studien skulle bli för stor. Studien kommer även att avgränsas till att inte studera tekniska verktyg för att hjälpa till med att anamma DevOps, exempel på verktyg som inte kommer att undersökas är Chef, Docker, Puppet eller Vargant. Studien avgränsas även till att endast rikta in sig på SME och inte undersöka företag med mer än 250 anställda. Studien kommer heller inte undersöka företag utanför Sverige.

3.3 Förväntat resultat

Studiens syfte är att hitta de utmaningar och framgångsfaktorer som företag kan tänkas stöta på vid en övergång från standard agil utveckling där utvecklingsavdelning och driftavdelning är separata till att anamma en DevOps-kultur. Genom att undersöka hur

18 övergången upplevs hos de anställda och hitta inom vilka områden det är svårt att anamma DevOps-kultur förväntas resultatet av studien att hitta de områdena som kräver mer arbete för att få DevOps-kulturen att fungera även på mindre företag. Av detta förväntas vissa framgångsfaktorer kunna utformas för att kunna hjälpa mindre företag att anamma DevOps-kultur på ett framgångsrikt sätt.

19

4 Metod

I detta kapitel kommer den valda forskningsmetoden att redogöras tillsammans med hur studien har genomförts, samt hur den insamlade datan har analyserats.

4.1 Vald metod

Den forskningsmetod som har valts för att besvara frågeställningen i denna studie var den kvalitativa metoden. Den kvalitativa metoden valdes på grund av frågeställningens karaktär då det behövs berättelser, upplevelser och åsikter för att besvara frågeställningen som är ”Vilka utmaningar och kritiska framgångsfaktorer finns för SME vid införande av DevOps med ramverket SAFe?”. En fråga av denna karaktär kan inte besvaras med siffror och statistik som den kvantitativa metoden oftast består av (Saldaña, 2011). Studien var tänkt att ha en viss del kvantitativ undersökning i form av en enkät som skickades ut till samarbetsföretagets anställda som en förstudie att formulera intervjufrågor på. Enligt Saldaña (2011) kan en blandning av kvalitativ och kvantitativ forskningsmetod hjälpa till att stärka fynden eller visa kompletterande fynd eller till och med resultat som är motstridiga. Desvärre var deltagandet på denna enkät så lågt att inget trovärdigt resultat gick att få fram. Av den anledningen valdes enkäten att strykas ur studien. Figur 6 visar hur studien har genomförts i olika steg för att visa ordningen av de olika stegen. Första steget var att skapa teman som intervjuerna ska fokusera på och formulera frågor utifrån dem. Andra steget var att hålla en pilotintervju för att testa frågorna. Denna hölls en vecka innan resterande intervjuer var inbokade för att ha möjlighet att gå igenom frågorna igen. Tredje steget var att genomföra intervjuer på samarbetsföretaget. Fjärde steget som var att sammanställa den data som samlats in via intervjuerna genom transkribering för att sedan koda informationen och skapa bra grund för att utföra femte steget som är analys. Hur kodningen och analysen har genomförts förklaras närmare i delkapitel 4.5. Sedan kommer resultatet att presenteras i steg sex.

Datan som samlats in av respondenterna har förvarats på den lösenordskyddade molntjänsten OneDrive för att säkerställa att datan inte försvinner om exempelvis datorn skulle sluta fungera eller bli stulen. Datan som samlats in innefattar ljudfiler på intervjuer, transkriberingar av intervjuer samt det material som har skapats när datan analyseras med hjälp av kodning. Den sammanställda informationen har sedan analyserats och jämförts med det som tidigare har hittats i litteraturen. Vid detta skede har ytterligare information från litteraturen sökts fram eftersom behov fanns för att bemöta de ämnen och upplevelser som respondenterna nämnt under intervjuerna. Efter intervjuerna har även ytterligare frågor ställs till respondenterna vid de tillfällen nya begrepp eller oklarheter från intervjuerna har påträffats. All data som har skapats och samlats in i denna studie kommer att raderas när studien är slutförd och betyg har erhållits, metodens alla steg kan ses i figur 6.

20 Figur 6 – Valda metodens olika steg för genomförande av studien

4.2 Fallstudie

Denna studie kommer att utföras genom en fallstudie som kommer att studera en förändringsprocess på ett företag. Fallstudier använder ofta intervjuer för att samla in data men även en multi-metoddesign av både kvalitativa och kvantitativa data är vanlig (Symon & Cassell, 2012). Fallstudien kommer att utföras på ett samarbetsföretag som är med i studien för att hjälpa till att besvara frågeställningen genom att dela med sig av de erfarenheter och utmaningar som upplevts på samarbetsföretaget med koppling till DevOps. Samarbetsföretaget är beläget i södra Sverige och utvecklar ett system som används i Sveriges kommuner. Samarbetsföretaget har ca 70 anställda och är mitt uppe i organisationsskiftet mot en DevOps-kultur. För att bevara samarbetsföretagets anonymitet kommer inte ytterligare informations att ges om verksamheten.

4.3 Insamling av kvalitativ data

Insamling av kvalitativ data har utförts via semistrukturerade intervjuer på samarbetsföretaget. Första intervjun var inbokad lite tidigare än de övriga intervjuerna för att vara en pilotintervju där frågorna testades. Efter den första intervjun gick forskaren igenom svaren och frågorna och la till ett par frågor i intervjuguiden som framkommit under pilotintervjun. Till en början hölls intervjuerna på plats på samarbetsföretaget men på grund av yttre omständigheter fick tre intervjuer ske över telefon och en per mejl. Samma frågor användes i telefon- och mejlintervjun. Intervjuerna som genomfördes höll en semistrukturerad form, vilket innebär att en intervjuguide användes med färdigställda frågor men att det samtidigt fanns öppna frågor för att inleda en djupare diskussion med respondenterna (Patton, 2015). Semistrukturerade intervjuer valdes eftersom de är mer flexibla än en enkät då det går att följa upp ett svar som en respondent ger och saker som känslor och motiv kan fångas upp (Bell, 2007). Intervjuerna utfördes på samarbetsföretaget där alla respondenter är anställda och arbetar i systemutvecklingsmiljö, drift, release eller med någon form av koppling till DevOps- kultur. Intervjuer tar lång tid att genomföra enligt Bell (2007), vilket ledde till att en tidsplan för intervjuerna skapades där intervjuerna hölls under tre veckors tid för att transkribering och kodning inte skulle skapa tidsbrist. För att skapa bra intervjumaterial följdes en guide med intervjuförberedelser från Bell (2007) med att exempelvis teman

21 valdes ut som sedan utgjorde grunden till intervjufrågorna. Strukturen på de intervjuerna som hölls på företaget har varit semistrukturerade med både lite strukturerade frågor och med mer öppna frågor för att skapa en diskussion mellan forskaren och respondenten.

Denna struktur ger möjlighet att hitta mer nyanserade svar (Bell, 2007). Intervjufrågorna har designats för att undvika att vara ledande eller ha en värdering i formuleringen, exempelvis ”Vad tycker du om det krångliga arbetssättet?” då forskaren redan har lagt in värderingen att arbetssättet är krångligt. En intervjuguide har följts vid varje intervjutillfälle där alla frågor har ställts i samma ordning för att underlätta arbetet med transkribering och kodning efter intervjuerna. Inför varje intervju har studiens syfte presenterats för respondenten samt studiens frågeställning. Sedan har de fyra forskningsetiska principerna presenterats och respondenten har än en gång fått frågan om medverkan fortfarande var okej. Detta har gett respondenten tillfälle att tacka nej till att medverka innan intervjun har startat vilket är att föredra enligt Bell (2007). För att underlätta transkribering efter intervjun genomförts har frågan om det går bra att spela in intervjun ställts till respondenten, detta har gått bra för samtliga intervjuer. Ytterligare en anledning till att intervjuerna spelades in var att på ett bättre sätt kunna säkerställa att informationen är sanningsenlig och underlätta att använda citat, vilket kan vara svårt om endast anteckningar används under intervjun (Patton, 2015). Intervjuguide som har använts i studien kan ses i bilaga A.

Efter att en intervju genomförts startade transkriberingen direkt. Intervjuerna spelades in vilket underlättade processen att transkribera. Hela intervjun skrevs först ner ordagrant för att sedan ta bort upprepningar och andra liknande saker som talspråket medför som inte ger något värde till analysen. Efter att transkriberingen var klar påbörjades arbetet med kodning, denna process beskrivs i kommande delkapitel 4.4.

4.4 Analysmetod av kvalitativ data

För att analysera den insamlade och transkriberade datan har kodning tillämpats.

Kodning innebär enligt Gillham (2008) att identifiera substantiella uttalanden, vilket innebär att ta bort överflöd som inte bidrar med något utan bara är utfyllnad i texten och sedan markera det som anses viktigt. Detta är ingen linjär process utan något som sker upprepade gånger och revideras. Denna process kan ses som ganska ostrukturerad till en början eftersom många olika kategorier skapas och ingen struktur kan till en början identifieras. När alla substantiella uttalanden var markerade gicks transkriptionerna återigen igenom för att börja forma kategorier. Till en början är de olika kategorierna enligt Gillham (2008) ostabila, men när alla transkriptioner var kategoriserade framkom det mer tydligare och gemensamma kategorier. Kategorierna hölls deskriptiva och inte för snäva eller abstrakta, exempelvis har en huvudkategori skapats för tidsbrist, med två underkategorier som representerar tidsbristen för driftavdelningen och utveckling av ny automatisering och en kategori som representerar bristen från ledningens håll att ge tid för DevOps-främjande aktiviteter. Gillham (2008) beskriver analysprocessen i tio steg som har utgjort grunden till hur arbetet med analysen har genomförts. Detta för att denna tiostegsprocess ansågs hjälpa till att hantera den mängd information som samlats in och