IT-styrning med hjälp av agila ramverk i stor skala

Handelshögskolan

vid Karlstads Universitet 651 88 Karlstad

Cristina Rudberg

IT-styrning med hjälp av agila ramverk i stor skala

Möjligheter och utmaningar

INFORMATIK ISGB09

Termin: VT-20 Handledare: Ala Sarah Alaqra

Henrik Andersson

Abstract

Syftet med denna studie är att identifiera och beskriva vilka möjligheter och utmaningar som organisationer, som arbetar med IT-styrning utifrån agila ramverk i stor skala, upplever. En tematisk innehållsanalys har genomförts av vetenskapliga artiklar för åren 2017 till 2020, och från artiklarna har koder genererats som grupperats i olika teman mot bakgrund av studiens frågeställning. Studien har genererat fyra olika teman för de utmaningar och möjligheter som organisationer, som arbetar med IT-styrning utifrån agila ramverk i stor skala, upplever:

 införandeaspekter och anpassning till organisationen

 leda och motivera medarbetare och team

 kvalitet och kontinuerlig förbättring

 utvecklingsaspekter

En slutsats som kan dras av detta är att det finns mest utmaningar för organisationerna gällande aspekterna som rör införandet och anpassningen till organisationen. Den andra slutsatsen som kan dras är att det finns många aspekter som beskrivits i denna studie som organisationer upplever som möjligheter vid införande och användande av agila ramverk i stor skala, speciellt kopplat till temat att leda och motivera medarbetare och team. Slutligen finns även några aspekter som organisationer upplever som utmaningar vid införande och användande av agila ramverk i stor skala. I absolut störst omfattning framkommer detta i tema ett som rör införandeaspekter och anpassning till organisationen.

Innehållsförteckning 

1 Inledning ... 5

1.1 Problembakgrund ... 5

1.2 Syfte ... 6

1.2.1 Undersökningsfrågor ... 6

1.3 Avgränsning ... 6

1.4 Uppsatsens disposition ... 7

2 Litteraturgenomgång ... 8

2.1 IT‐styrning och förvaltningsobjekt ... 8

2.2 IT‐styrning med agila metoder ... 8

2.3 IT‐styrning med agila metoder för stor skala ... 9

2.3.1 Scaled Agile Framework, SAFe... 10

2.3.2 Large-Scale Scrum, LeSS ... 11

2.3.3 Scrum of Scrums ... 12

3 Metod ... 14

3.1 Validitet och reliabilitet ... 14

3.2 Tillvägagångssätt ... 15

4. Resultat av datainsamling ... 17

4.1 Key Lessons for Tailoring Agile Methods for Large Scale Software Development (A1) ... 17

4.2 Implementing Large‐Scale Agile Frameworks: Challenges and Recommendations (A2) ... 18

4.3 Implementing Scaled‐Agile Frameworks at Non‐Digital Born Companies – A Multiple Case Study (A3) ... 20

4.4 Inter‐team Coordination in Large‐Scale Agile Development: A Case Study of Three Enabeling Mechanisms (A4) ... 20

4.5 Scaling Agile (A5) ... 21

4.6 Adopting SAFe to Scale Agile in a Globally Distrubuted Organization (A6) ... 21

4.7 Scaling Agile Software Development to Large and Globally Distributed Large‐scale Organizations (A7) ... 23

4.8 Scaling agile in large organizations: Practices, challenges, and success factors (A8) ... 23

4.9 Large‐scale agile transformation at Ericsson (A9) ... 24

4.10 Agile Development at Scale: The Next Frontier (A10) ... 25

4.11 Impacts on Team Performance in Large‐Scale Agile Software Development (A11) ... 25

5 Analys ... 26

5.1 Teman relaterade till de genererade koderna ... 26

5.1.1 Tema 1 - Införandeaspekter och anpassning till organisationen ... 26

5.1.2 Tema 2 – Leda och motivera medarbetare och team ... 28

5.1.3 Tema 3 – Kvalitet och kontinuerlig förbättring ... 29

5.1.4 Tema 4 – Utvecklingsaspekter ... 31

6 Diskussion och slutsatser ... 33

Källförteckning... 35

Elektroniska källor ... 36

1 Inledning

Informationsteknologi är idag centralt inom såväl privata som offentliga organisationer och många gånger en förutsättning för att kunna driva, underhålla och utveckla verksamheter. Detta har medfört att styrningen av IT har blivit en viktig del av organisationerna och bidragit till ett ökat fokus på frågan om IT-styrning. IT-styrning består i delarna ledarskap och de organisatoriska strukturer och processer som medverkar till att organisationens IT frågor och övriga frågor samspelar (Haes & Grembergen 2009:123). Frågan om IT-styrning kan därmed anses vara stor och övergripande och såväl omfatta personligt ledarskap som hur organisationens processer och styrning genomförs.

I flera olika organisationer finns exempel på att utvecklingen gått från att vara en teknisk fråga som är mycket avgränsad till att det finns ett mer holistiskt perspektiv på IT frågor som omfattar olika strukturer och roller inom organisationen. Detta medför därmed att frågan om IT-styrning växer och därmed även kan sägas omfatta relationen mellan ledarskap, IT och organisationens processer, det vill säga på vilket sätt som ledarskap i dessa frågor kan utveckla organisationens processer.

1.1 Problembakgrund

Mot bakgrund av att IT har blivit en sådan central del i många företag så att den påverkar hela företagets processer har också behovet av IT-styrning blivit mer aktuell att diskutera på ett mer övergripande sätt (Haes & Grembergen 2009:123). IT-styrning är ett område som, liksom frågan om IT-utveckling, förändras med tiden. Nya metoder och ramverk uppstår och arbetssätten utvecklas i nya riktningar. En förändring som skedde för flera år sedan var att många IT-projekt började drivas enligt agila metoder, snarare än genom den traditionella vattenfallsmetoden. Den grundläggande fördelen med att driva projekt agilt handlar om att kunna hantera förändringar eftersom dessa alltid sker i projekt (Gustavsson 2016:9). Agil är ett gemensamt namn för metoder som har arbetats fram och där vissa av metoderna bygger på lärdomar som dragits från projekt som lyckats trots stora svårigheter (Gustavsson 2016:11).

Även om de agila arbetssätten har utvecklats för IT-projekt, menar Gustavsson (2016:12), att de agila principerna är användbara inom flera olika typer av projekt och branscher, stora som små. Även om inte alla metoddelar alltid kan användas i alla projekt menar Gustavsson att det är möjligt att ta med det grundläggande agila synsättet överallt.

De agila metoderna är mycket avskalade ramverk bestående av både processbeskrivningar och rollbeskrivningar, eftersom en av de agila principerna är att fokusera på individer och interaktioner framför processer och verktyg (Gustavsson 2016:32). De agila metoderna fungerar mycket väl i små grupper och det agila synsättet förespråkar också att gruppen ska begränsas till storleken att alla kan se varandras ögon, eftersom stora grupper försvårar kommunikation och beslut (Gustavsson 2016:42). Många företag och organisationer har sett fördelarna med de agila metoderna och har kunnat nå större framgångar genom att gå över till ett agilt arbetssätt (Gustavsson 2016:9). Frågan som uppkommit för flera organisationer när de vuxit som organisation eller behövt se över sin IT-styrning för sin organisation, är på vilket sätt som organisationen kan behålla sitt agila arbetssätt men i en stor skala. Här menar Gustavsson (2016:189) att det går att driva stora agila projekt genom att behålla de agila värderingarna kring självstyrande små grupper och bryta ner stora projekt till små underprojekt. De avskalade processerna och ramarna som den agila metoderna innebär kan kompletteras och bland annat kan ytterligare mötesformer tillföras vid behov. Det är dock viktigt, menar Gustavsson, att ha en större medvetenhet om organisationskulturen i fallet med större agila projekt och det kan

även vara en stor utmaning att korrdinera flera projektgrupper (Gustavsson 2016:189f). Som stöd för att koordinera agila projekt i stor skala har ett antal ramverk presenterats på marknaden under 2010-talet. Dessa metoder, såsom Scaled Agile Framework - SAFe och Large-Scale Scrum - LeSS, har fokus på att koordinera flera projektgrupper och lyfter upp vikten av en gemensam leveransplan (Gustavsson 2016:190).

Det är därmed intressant, när den agila metoden skalas upp till att omfatta flera projekt och/eller hela organisationer, att undersöka vilka aspekter som organisationer som vill använda dessa metoder anser som fördelar och utmaningar. Det kan framstå i teorin som att det enkom finns fördelar med att skala upp den agila metoden till ett större perspektiv och få med de fördelar med metoderna, i en större skala. Samtidigt finns det beskrivet flera utmaningar med att arbeta med den agila metoden i stor skala, såsom exempelvis avsaknad av flexibilitet och utmaningar med samordning. För att övervinna dessa problem har flera organisationer arbetat enligt några av de metoder och ramverk som finns på marknad avseende IT-styrning med agil utveckling i stor skala, såsom SAFe, Scrum at Scale eller LeSS. För dessa ramverk finns fördefinierade arbetsmetoder. Dock finns det begränsade empiriska studier som kan belysa dess faktiska resultat vid användning såsom dess effektivitet, användning och utmaningar (Conboy & Carroll 2019:1). Det har inte heller genomförts så många studier över på vilket sätt som organisationer och medarbetare påverkas av införande av agila arbetssätt (Gustavsson 2018:421). Möjligen som en konsekvens av att metoden inte har använts under så många år ännu. Denna studie vill därför undersöka frågan om hur organisationer upplever hur det är att arbeta med agila ramverk för IT-styrning i stor skala, för att skapa större kunskap kring hur dessa ramverk har införts i organisationer och vilka möjligheter liksom utmaningar som de kan innebära.

1.2 Syfte

Syftet med denna undersökning är att identifiera och beskriva vilka möjligheter och utmaningar som organisationer, som arbetar med IT-styrning utifrån agila ramverk i stor skala, upplever.

Fokus för studien är hela den process som blir aktuell för en organisation som vill börja arbeta med ett agilt ramverk i stor skala, såväl förberedelser som införande och användande.

1.2.1 Undersökningsfrågor

För att tydliggöra syftet har två undersökningsfrågor ställts upp som ska besvaras i studien:

U1 Vilka aspekter upplever organisationer som möjligheter vid införande och användande av agila metoder i stor skala i för IT-styrning?

U2 Vilka aspekter upplever organisationer som utmaningar vid införande och användande av agila ramverk i stor skala?

1.3 Avgränsning

I studien avses hela processen med införande och användande, vilket innebär att såväl frågor som hur organisationen förbereder en agil transformation till att den faktiskt genomförs och att organisationen arbetar agilt i stor skala, avses att undersökas. En avgränsning har gjorts genom att frågorna belyses mot bakgrund av åren 2017 till 2020. Anledningen till att den avgränsningen gjorts är att intresset i denna studie ligger i att hitta aspekter som påverkar införande och användande av agila metoder i stor skala med fokus på tiden i den absoluta

inte fanns tillräckligt många studier och artiklar skrivna under 2019-2020 inom området för studien för att basera studien på dessa år, och beslutet togs därför att utöka antalet undersökta år till att omfatta åren 2017-2020.

1.4 Uppsatsens disposition

Uppsatsen kommer att ta sin utgångspunkt i en litteraturgenomgång med syfte att beröra centrala begrepp och viktiga aspekter gällande IT-styrning och de agila metoderna. Därefter kommer metoden för studiens genomförande att diskuteras i kapitel tre, och på vilket sätt som undersökningen uppfyller kraven på validitet och reliabilitet. En genomgång görs av tematisk innehållsanalys och hur metoden tillämpas i denna undersökning. I kapitel fyra presenteras resultatet av datainsamlingen. Efter detta avsnitt presenteras analysen i kapitel fem, vilken är baserad på forskningsartiklar som kodats i enlighet med metoden. De koder som genererats från undersökningsmaterialet analyseras och grupperas i olika teman mot bakgrund av studiens syfte och frågeställningar. Slutligen, i kapitel sex, presenteras studiens resultat och slutsatser och de frågeställningar som ställts upp besvaras.

2 Litteraturgenomgång

I litteraturgenomgången diskuteras begreppen IT-styrning och förvaltningsobjekt liksom den agila metoden. Tre agila ramverk för stor skala presenteras för att ge en kort orientering inom området. Litteraturgenomgången kan inte ses som heltäckande inom området men syftar till att ge en inblick i frågorna.

2.1 IT-styrning och förvaltningsobjekt

IT-styrning har gradvis förändrats från en teknisk anpassning till att frågan omfattar hur teknologi och IT-resurser ska bidra till att uppfylla organisationens mål. Det har skett en ökad nivå av likriktning mellan frågor som rör IT och frågor som rör organisationens utveckling.

Idag ses IT-styrning som en del av den generella styrningen av organisationen, som en utveckling av det faktum att IT levererar fördelar för organisationerna (Rusu & Viscusi 2017:6).

IT-styrning kan förklaras som en specificering av de rättigheter och ramverk som bidrar till den önskvärda effekten av IT. Inom ramen för IT styrning ska strukturer för beslutsfattande, processer och övrig styrning och kontroll av IT frågorna arbetas fram. Frågorna behöver också arbeta i de relationer och med de roller som finns i organisationen i sin helhet. Tillsammans kan detta bidra till ett bättre nyttjande av IT-infrastrukturen samt mer effektivitet. Frågorna behöver hanteras i ett långsiktigt perspektiv och i relation och i samverkan med de övergripande principerna för organisationen. IT-styrning är relaterad till organisatorisk effektivitet och handlar om att möta de krav som såväl lagstiftare som övriga aktörer ställer på organisationen (Rusu & Viscusi 2017:6f).

Nordström och Welander (2002:10) menar på liknande sätt att förvaltningsobjektet, systemet som ska förvaltas, ibland kan innebära en snäv syn på vad det är som ska förvaltas och styras.

Det kan uppstå en snäv syn på förvaltning och styrning som innebär en tro om att det enbart är IT-stödet eller de maskinella delarna som sak förvaltas. Vid detta synsätt glöms verksamheten och dess affärer bort och detta kan leda till att IT-stödet inte stödjer verksamheten i tillräckligt god utsträckning. Nordström och Welander (2002:14) landar istället i en definition när det gäller att förvalta system som innebär definitionen om att det omfattar ”Arbetet med att förändra och styra objekt där IT-stöd ingår som delar”. Inom detta område kan förvaltningsstyrning, ändringshantering och användarstöd ingå.

2.2 IT-styrning med agila metoder

Det agila manifestet som arbetades fram under 2001 skulle visa sig leda till otroliga förändringar av mjukvaruutvecklingsmetoderna. Manifestet banade väg för en mycket stor våg av bland annat nya mjukvaruutvecklingsmetoder, verktyg och tekniker (Dingsoyr et al.

2012:1213). De agila metoderna utvecklades både som en motreaktion mot den traditionella projektledningen och mot bakgrund av de värderingar som fanns i Lean (Gustavsson 2016:24).

Den traditionella projektledningens metoder med bland annat Gantt-schemat, utvecklades i början av 1900-talet. Den traditionella projektledningen skulle koordinera mycket stor mängd personer, aktiviteter, material och kapital, det var stora projekt med stora resurser. Syftet med många av de projekt som drivs idag dock, är inte detsamma. Istället pekar utvecklingen generellt på att projekten blir fler och fler men att dess storlek är mindre sett till antal projektdeltagare.

Behoven av att utveckla andra metoder för att leda och arbeta med projekt har därför ökat, och det var mot bakgrund av en önskan om större flexibilitet som de agila metoderna formades (Gustavsson 2016:25f).

De agila principerna beskrivs på ett kort sätt i det agila manifestet som togs fram under ett möte i Utah i februari 2001. De enades om fyra punkter som skulle vägleda agil utveckling:

 Individer och interaktioner framför processer och verktyg.

 Användbart projektresultat framför omfattande dokumentation.

 Kundsamarbete framför kontraktsförhandling.

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

Det finns ett värde i det som står till höger, men den agila metoden värdesätter delarna till vänster högre. På detta sätt finns också en möjlighet för projektledarna att göra prioriteringar i arbetet, eftersom det tydliggörs att aktiviteterna på den vänstra sidan är prioriterade. På detta sätt är det också möjligt för en projektledare att prioritera exempelvis att innehållet i dokumentationen är korrekt och hjälper projektets arbete snarare än att allt är helt korrekt stavat i alla stycken i dokumentet (Gustavsson 2016:32).

För att tydliggöra det agila manifestet formulerades tolv principer för att illustrera hur värderingarna kunde efterlevas. Eftersom principerna arbetades fram av metodutvecklare inom IT kretsade principerna till en början kring begreppen programvara och utvecklare. Dessa kan dock ersättas med begreppen projektresultat och projektdeltagare för att även använda de agila principerna inom andra områden (Gustavsson 2016 36f). De tolv principerna är:

1) Vår högsta prioritet är att tillfredsställa kunden genom tidig och kontinuerlig leverans av värdefull programvara

2) Välkomna förändrade krav, även sent under utvecklingen. Agila metoder utnyttjar förändring till kundens konkurrensfördel.

3) Leverera fungerande programvara ofta, med ett par veckors till ett par månaders mellanrum, ju oftare desto bättre.

4) Verksamhetskunniga och utvecklare måste arbeta tillsammans dagligen under hela projektet.

5) Bygg projekt kring motiverade individer. Ge dem den miljö och det stöd de behöver, och lita på att de får jobbet gjort.

6) Kommunikation ansikte mot ansikte är det bästa och effektivaste sättet att förmedla information, både till och inom utvecklingsteamet.

7) Fungerande programvara är främsta måttet på framsteg.

8) Agila metoder verkar för hållbarhet. Sponsorer, utvecklare och användare ska kunna hålla jämn utvecklingstakt under obegränsad tid.

9) Kontinuerlig uppmärksamhet på förstklassig teknik och bra design stärker anpassningsförmågan.

10) Enkelhet – konsten att maximera mängden arbete som inte görs – är grundläggande.

11) Bäst arkitektur, krav oh design växer fram med självorganiserande team.

12) Med jämna mellanrum reflekterar teamet över hur det kan bli mer effektivt och justerar sitt beteende därefter (Gustavsson 2016 36f).

2.3 IT-styrning med agila metoder för stor skala

Termen ”large-scale agile development” eller agila ramverk i stor skala, har förknippats med olika ramverk. Generellt refererar termen till utveckling i stora team och/eller i stora projekt som involverar många team som använder de agila metoderna i organisationer (Turetken et al.2017:3). Ramverken baseras på ett antal regler som anger hur en organisation bör organiseras för att återspegla de värden som finns förknippade med det agila synsättet. Dessa värden baserar

sig på utvecklarens kunskaper, en pragmatisk inställning och arbetssätt, många och regelbundna iterationer och regelbunden kommunikation. Dessa metoder har använts i den agila utvecklingen såsom exempelvis Scrum, men när de skalas upp till ett ramverk i stor skala har de använts utan att ha ett svar på hur de ska användas för att kunna koordinera större grupper av utvecklare. Schuch et al. (2020:4337) menar att det agila ramverket i stor skala är kodade förklarande modeller över en process och struktur för de organisationer som vill utvecklas mot ett snabbare arbetssätt och leveranser, samtidigt som de vill kunna vara lyhörd gentemot kraven från marknaden. I synnerhet kan detta vara aktuellt i en tillväxtfas med fler deltagare i arbetet och större svårigheter att kommunicera.

Agil utveckling i stor skala kan användas i organisationer som styrmedel menar Ebert och Paasivaara (2017:99f). De menar att ramverket kan användas för att organisationen ska kunna utvecklas från enstaka IT-system till en integrerad IT-styrning med hög kvalitet som är pålitlig och tillgänglig. Författarna framhåller dock, i likhet med flera andra, att det finns få självständiga studier som visar hur ramverken fungerar i praktiken. De undersöker och jämför fem olika agila ramverk för stor skala, Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS), Scrum of Scrums (SoS), Disciplined Agile Delivery (DaD) och Lean Scalable Agility for Engineering (LeanSAFE). De olika ramverken har olika styrkor och svagheter. SAFe menar många har styrkor i att ramverket definierar olika roller, vilket inte varit så tydligt i tidigare ramverk. Nackdelen är dock att det innebär att ramverket blir tungt, det vill säga förlorar mycket av sin agila flexibilitet, och att SAFe är för komplex som metod. Ebert och Paasivaara menar att SAFe med sin byråkrati i vissa fall kan likställas med en utvecklad vattenfallsmetod. Andra agila ramverk såsom LeSS och LeanSAFE har väsentligt mindre definitioner vilket ger organisationerna mer frihet men även ansvar i att själva sätta sina egna roller och anpassning.

Det finns flera olika ramverk som inkluderar agil metod i stor skala. Utöver de ramverk som beskrivits ovan finns även bland andra Nexus och Recipes for Agile Governance in the Enterprise (RAGE) (Mucambe et.al 2020:3110). Ramverken är olika varandra när det kommer till terminologi och den nivå över detaljer som metodiken omfattar (Schuch et al. 2020:4337).

Nedan följer en beskrivning av ramverken SAFe, LeSS och Scrum of Scrum för att ge en bild av några av de vanligt förekommande agila ramverk som finns på marknaden för agil styrning i stor skala.

2.3.1 Scaled Agile Framework, SAFe

Scaled Agile Framework, SAFe, är ett av de mest använda ramverket för att arbeta med agila metoder i stor skala. SAFe är ett ramverk som menar att de kan erbjuda lösningen för att arbeta agilt på en organisatorisk nivå. Ramverket innehåller nivåer för olika team, program, stora utvecklingar och portfölj (Paasivaara 2017:36). Nedan i figur 1 finns en översiktlig bild över ramverket SAFe som visar de olika nivåerna som beskrivs ovan samt innehållet i respektive nivå.

Figur 1, Full SAFe. Källa: The SAFe Company B.v, (SAFe 2020), licensed under CC BY-ND.

På teamnivån arbetar agila team som använder Scrum, Kanban och Extreme Programming (XP) som metoder för utvecklingen. Användarberättelser (s.k. User stories), som är korta enkla beskrivningar om vad som vill uppnås och som beskrivs av den som vill få arbetet utfört, används i kombination med sprintplanering och dagliga stå-upp-möten. För varje iteration används tillbakablickar, som metod för att lära, och definitionen av när arbetet är klart (s.k.

definition of done). På programnivå arbetar utvecklare och andra intressenter med att utveckla systemet och optimera förutsättningarna för att nå det önskade resultatet som ställts upp. Det finns specifika roller i detta ramverk som stödjer arbetet såsom produktägare och Release Train Engineer (RTE), vars uppgift är att bidra med stöd och riktlinjer för arbetet. Det finns också en nivå för stora utvecklingar (s.k. Large Solution) som kräver engagemang i flera olika utvecklingssteg. Denna nivå har som uppgift att koordinera intressenter och releaser med syftet att fånga upp krav som kan sammanställas i övergripande lösningar och planeringar. Dessa lösningar skulle inte annars kunna fångas upp. Slutligen finns den högsta nivå, Portföljnivån.

Denna nivå kombinerar Programnivån med företagets strategi och investeringar med värdekedjor (Mucambe et al. 2020:3111f). Slutligen finns även en kompletterande värdeströms- koordinering som tillför vägledning i att hantera beroenden och hur möjligheter kan hittas i portföljerna (Leffingwell et al. 2018:639).

2.3.2 Large-Scale Scrum, LeSS

Large Scale Scrum, LeSS, är ett ramverk som kombinerar team som arbetar med Scrum och som arbetar tillsammans med en produkt och med ett gemensamt mål. Teamen arbetar med att färdigställa delar som tillsammans ger en färdig produkt i slutet av arbetet. Ramverket uppmuntrar teamen att ta ansvar och att ta ett ägarskap i frågorna och även arbeta transparent (Mucambe et al. 2020:3113).

Det finns två olika typer av LeSS: Basic LeSS avsett för två till åtta team och LeSS Huge för över åtta team. En Scrum-master kan leda mellan ett och tre team och dennes uppgift är att stödja teamen i hur de kan arbeta bäst med ramverket. Varje produktägare har en produktlogg som respektive team arbetar med. I detta ramverk är den första agila principen starkt vägledande: individer och interaktioner framför processer och verktyg. Arbetet i teamet står i centrum under en sprint, det vill säga möten och interaktioner. För varje sprint görs korrigeringar i produktloggen för att kunna möjliggöra att det finns uppgifter klara inför kommande sprinter (Mucambe et al. 2020:3113f). Nedan, i figur två illustreras hur ramverket LeSS är uppbyggt.

Figur 2, LeSS Framework. Källa: The LeSS Company B.v, (Less 2020), licensed under CC BY-ND.

2.3.3 Scrum of Scrums

Ramverket Scrum of Scrums kan skala upp Scrum till större grupper, över tolv personer, genom att dela upp grupperna i flera agila team om mellan fem till tio personer. Varje team har en ambassadör som ingår i en annan grupp och där rapporterar teamets arbete och utvecklingen som teamet genererar, såsom uppgifter som blir klara och problem som hindrar teamet. Denna process möjliggör ett utbyte mellan de olika teamen och medger att kunskap delas mellan teamen. Detta möjliggör också att andra utanför teamen kan hjälpa till och lösa problem som uppstår för ett team (Mucambe et al. 2020:3114). Nedan i figur tre finns en bild över ramverket och dess olika nivåer.

Figur 3, Scrum of Scrums organisering. Källa: Författaren och Agilest, (2020).

Scrum of Scrums omfattar möten en gång om dagen efter det att sub-teamen (scrum teams) har haft deras dagliga möte. På mötet för Scrum of Scrums ska viktiga frågor från sub-teamen ställas, och hinder ska undanröjas från teamen. Om det behövs ska frågorna eskaleras till nästa nivå som är företagsnivån. Scrum of Scrums ska även samverka med företagsnivån i arbetet.

Scrum of Scrums har en viktig uppgift i att följa upp att både företagsnivån och teamnivån samverkar och är överens om arbetet och de övergripande frågorna. För att arbetet ska kunna ske effektivt är deltagarnas kunskap och erfarenhet viktigt för de som arbetar med Scrum of Scrums, både tekniskt men även i att vara duktig på att kommunicera och svara på frågor (Mucambe et al. 2020:3114f).

Sammanfattningsvis har detta kapitel i studien redogjort för tre olika agila ramverk i stor skala för att ge en bild över hur den agila metoden kan fungera i stor skala, även om de i första hand var tänkta för de mindre teamen. Ramverken är komplicerade och det är svårt att ge en bra sammanfattning av dessa i kort form. Det faktum att de är komplexa, är även en av kritiken som framförs mot de agila metoderna i stor skala, vilket kommer att diskuteras senare i studien.

3 Metod

Här diskuteras metodvalet och hur studien har genomförts, liksom frågor om validitet och reliabilitet. En redogörelse för den valda metoden, som är tematisk innehållsanalys, görs också.

3.1 Validitet och reliabilitet

För kvaliteten i en studie är det centralt med graden av säkerhet i den insamlade informationen (Patel & Davidson 2011:101). Patel och Davidson menar att studien dels måste ha en hög grad av validitet vilket innebär att forskaren undersöker det var tänkt att hen skulle undersöka. Det andra är att forskningen måste genomföras på ett tillförlitligt sätt. Med detta avses att studien har en hög reliabilitet. Dessa två begrepp, menar Patel och Davidson, står i relation till varandra, eftersom det inte anses vara möjligt att fokusera bara på det ena begreppet. De menar att

”fullständig reliabilitet är en förutsättning för fullständig validitet” (Patel & Davidson 2011:102).

Patel och Davidson beskriver validitet genom att beskriva att det i studien måste finnas en korrelation mellan vad forskaren säger att hen ska undersöka och vad hen sedan faktiskt undersöker. Det är inte alltid lätt att uppnå denna korrelation i studier eftersom studierna kan handla om subjektiva och abstrakta fenomen, i synnerhet om det är människor som undersöks där det inte finns absoluta sanningar eller måttangivelser eller tal på alla delar i undersökningen.

För att säkerställa en god validitet hos ett instrument presenterar författarna två tillvägagångssätt: innehållsvaliditet och den samtidiga validiteten (Patel & Davidson 2011:102). Innehållsvaliditeteten kan uppnås genom en logisk analys av innehållet i instrumentet genom att koppla denna till den teori som studien tar avstamp från. Det kan möjliggöras genom att i litteraturstudier hitta begrepp som kan översättas till variabler. Dessa variabler kan därefter ligga som grund för exempelvis de frågor som kan ställas i intervjuer.

Instrumentet används därefter för att genomföra mätningen (Patel & Davidson 2011:103).

I denna undersökning har den kvalitativa metoden användts och en tematisk innehållsanalys av dokument genomförts. Den kvalitativt inriktade forskningen handlar om ”mjuka” data såsom exempelvis att analysera genomförda intervjuer eller genomföra tolkande analyser (Patel &

Davidson 2011:13f). De studier som antar ett kvalitativt anslag anses kunna bidra med en djupare kunskap än den mer fragmentiserade kunskap som den kvantitativa metoden kan bidra med (Patel & Davidson 2011:119).

Braun och Clarke menar att den kvalitativa metoden är mångfacetterad och komplex och menar att den tematiska analysen kan användas som en grund för den kvalitativa analysen. En fördel som den tematiska analysen har är dess flexibilitet. En andra fördel, menar författarna, är att den tematiska analysen trots att den ger en grundläggande frihet i det teoretiska valet möjliggör data och därmed ett resultat som är rikt på detaljer och komplext. Författarna menar dock att det är viktigt att upprätthålla en god balans mellan den flexibla metoden och samtidigt ha ramar som kan utgöra en motvikt till de nackdelar som finns med den kvalitativa metoden. Med den tematiska metoden vill författarna möjliggöra en bra och sund utgångpunkt för den tematiska analysen som kan fungera som en bas för framtida forskning (Braun & Clarke 2006:78).

Ett tema samlar något som är viktigt i det data som undersöks i relation till syftet och undersökningsfrågan för undersökningen (Braun & Clarke 2006:82). Eftersom undersökningen är en kvalitativ undersökning finns det inte på förhand givna uppsättningar av teman, utan dessa behöver kategoriseras mot bakgrund av teorin och i aktuellt data. Braun och Clarke illustrerar

och mindre i en annan. Flexibiliteten i metoden kommer möjliggöra att forskaren bestämmer olika teman, men grundläggande är också att det sker på ett konsekvent och transparent sätt (Braun & Clarke 2006:82f). Metoden har sex steg:

1) Initial, övergripande analys av data: För att få en god överblick över det data som är aktuellt för studien bör det läsas flera gånger för att få initiala idéer om hur det kan struktureras.

2) Generera initiala koder: Intressanta delar av data eller egenskaper som upptäcks kan börja kodas genom att en genomgång av data och en gruppering av informationen.

3) Sök efter teman: Sammanställ informationen till möjliga teman och för samman information till respektive tema.

4) Översyn av teman: Se över om teman fungerar i relation till den initiala kodningen samt materialet i sin helhet. Här kan en sammanställd karta över analysen arbetas fram.

5) Teman definieras och namnges: Analysen möjliggör en kontinuerlig översyn och tydligare definiering av temana och i detta steg kan de även namnges.

6) Rapporten skrivs: Här produceras rapporten och den sista analysen görs. Det är bra att kunna illustrera olika delar med exempel ur data och relatera till forskningsfrågan och teorin vid rapportskrivningen. (Braun & Clarke 2006:87)

Braun och Clarke tar upp frågor som kan vara fallgropar i den tematiska analysen, det första är att det inte genomförs en analys av materialet, utan bara en kategorisering. Det andra är att använda forskningsfrågorna som teman som grund för data (Braun & Clarke 2006:94f). Dessa fallgropar menar jag har en grund i frågan om validitet och har därför behandlats i analysen genom att en transparent och grundlig analys gjorts av det insamlade datat, liksom att de teman som valts har gjort det utifrån en analys av all data. Undersökningsfrågorna som jag valt passar väl för en tematik dokumentanalys eftersom det möjliggör att hitta teman i materialet som kan ge mer svar på frågan om IT-styrning genom agila metoder och dess fördelar och nackdelar.

Det är dock viktigt att metoden följs och genomförs på ett sådant transparent sätt som möjligt för att säkerställa en god validitet i undersökningen.

Reliabiliteten handlar om hur tillförlitligt instrumentet är som används i forskningen, och hur väl instrumentet kan motstå slumpinflytanden. Patel och Davidson menar att en individs beskrivning kan utgöra ett observerat värde. De menar att resultatet vi erhåller i en studie, det observerade värdet, innehåller både individens sanna värde och ett felvärde. Felvärdet beror på att instrumentet har briser när det gäller reliabiliteten. Dessa brister kan uppkomma från många omgivande faktorer som forskaren inte kan ha kontroll över såsom att värdarna innehåller ett konstant felvärde som inte upptäckts, eller vara känsligt för slumpmässiga variationer. När ett instrument har hög grad av reliabilitet innebär det att felvärdet har minskat och instrumentet visar ett resultat som är närmare individens sanna värde (Patel & Davidson 2011:103f).

Avseende reliabiliteten när det gäller insamlingen av materialet till denna undersökning finns flera fallgropar att ta hänsyn till enligt Braun och Clarke. Det är viktigt att de teman som väljs kan stå självständigt i analysen och inte blandas med varandra. Det är också viktig att det data som samlas in stämmer överens med de analytiska slutsatser som dras. Slutligen är det viktigt att teorin och de analytiska slutsatserna stämmer överens (Braun & Clarke 2006:94f).

3.2 Tillvägagångssätt

Inledningsvis genomfördes en preliminär litteraturgenomgång för att få mer kunskap inom området och möjliggöra en avgränsning av undersökningsområdet. Med denna bas valdes studiens syfte och frågeställningar.

Därefter gjordes en sökning i Karlstads Universitets biblioteksdatabas (Karlstad universitet) på sökordet ”large development projects” för åren 2017-2020. Avgränsningen har skett genom att undersökningen koncentreras till åren 2017 till maj 2020. Denna avgränsning har gjorts med hänsyn till undersökningsfrågan då intresset för undersökningen finns i att undersöka och belysa den utveckling som skett inom frågan om IT-styrning de senare åren. Denna sökning genererade över 34 000 sökresultat. Från detta sökresultat gjordes en genomläsning av rubrikerna och abstract för de första 100 sökträffarna. En bedömning gjordes att de sökträffar som var av intresse för studien kunde återfinnas bland de första 50 sökresultaten. Det bedömdes därför inte som intressant att läsa igenom fler än de 100 första sökträffarna. Artiklar som inte finns tillgängliga digitalt via bibliotekets e-tjänst har exkluderats. Resultatet av vilka sökträffar som togs med i uppsatsen på basis av dess relevans för uppsatsen utifrån uppsatsens syfte och frågeställningar.

För att ytterligare specificera sökningen gjordes en sökning på sökorden large- scale agile framework för åren 2017-2020 i samma databas. Sökningen resulterade i 106 sökträffar och dessa gicks igenom med fokus på att hitta akademiska artiklar från tidskrifter i första hand. Det fanns dock flera intressanta rapporter och andra underlag som även dessa togs med i urvalet.

Ett urval skedde därefter av artiklarna som sökningen resulterat i, med hänsyn till att artiklarna skulle behandla undersökningsfrågorna och i enlighet med metoden för undersökningen.

Bedömningen av vilka artiklar som skulle tas med i undersökning skedde genom att artiklarna gicks igenom på rubriknivå och abstractnivå och därefter valdes ut eller valdes bort med hänsyn till uppsatsens syfte och frågeställningar.

De artiklar som hade valts ut gicks därefter igenom och en preliminär kodning genomfördes.

Kodningen genomfördes genom att lyfta ut de koder i materialet som ansågs vara mest intressanta mot bakgrund av studiens syfte och frågeställningar. De koder som hittades skrevs ner och alla artiklar lästes på samma sätt. Alla koder fick också ett (+) eller (–) för att illustrera om det var en aspekt som ansågs vara en möjlighet eller en utmaning. I det fall som liknande innehåll återfanns noterades det som samma kod men i de fall där koderna var snarlika men inte lika skapades en ny kod för att i så stor utsträckning som möjligt vara transparent med det underlag som låg till grund för studien. Efter att artiklarna lästs igenom och koder hade skapats, grupperades koderna samman i olika teman. De koder som hörde ihop fördes samman till ett gemensamt tema som skulle spegla innehållet. Efter detta lästes artiklarna igenom igen och koderna och teman sågs över och en sammanställning gjordes såväl av artiklarna som av koderna och teman i rapporten där också koderna och teman diskuterades och analyserades.

Syftet med att arbeta systematiskt och transparent med den sökning som genomförts och kodningen samt att generera teman är att försöka öka reliabiliteten i studien. Urvalet av koderna i artiklarna har skett mot bakgrund av syftet med studien och dess undersökningsfrågor. Trots detta kan det inte säkerställas fullt ut att det urval som gjorts skulle bli exakt lika om en annan person hade gjort urvalet på grundval av samma material då instrumentet innebär en tolkning av innehållet av studiens syfte och det data som samlats in. Genom att genomföra den preliminära litteraturgenomgången innan studiens syfte och frågeställningar togs fram har försök gjorts att stärka innehållsvaliditeten. På detta sätt var ambitionen att skapa en god överblick över det teoretiska fältet som en grund för genomförandet av studien.

4. Resultat av datainsamling

Genom det strukturerade urvalet som gjordes av materialet mot bakgrund av undersökningsfrågorna, har elva artiklar valts ut. Dessa artiklar har kodats i enlighet med det som har funnits som varit mest relevant för att svara på undersökningsfrågorna. Nedan presenteras artiklarna och den kodning som gjorts i kursiv stil.

4.1 Key Lessons for Tailoring Agile Methods for Large Scale Software Development (A1)

Dingsoyr et al. (2019) har studerat flera stora utvecklingsprogram i Norge och har dragit flera slutsatser av möjligheterna med att blanda agila metoder med traditionell projektledning.

Artikeln de skrivit drar slutsatser vilka de finner som viktiga för andra stora utvecklingsprojekt som vill kombinera Scrum med traditionell projektledning (Dingsoyr et al. 2019:37). De menar att även om det finns flera goda lärdomar att dra från ramverk såsom Scaled Agile Framework och Large-Scale Scrum, är det möjligt att från deras råd också hitta vägar för att kombinera agila och traditionella metodiker i stor skala (Dingsoyr 2019:40).

Den första slutsatsen de drar är vikten av produktbackloggen och dess omgivande process. I denna gjordes avvägningar över behov och förslag till lösningar och arbetet skedde tillsammans i det som kallades processen för backloggen. Här skedde också en avvägning av vilken detaljnivå som var viktig, där ledningen arbetade efter att hitta den detaljnivå som var precis nödvändig för att få flyt i planeringen (Dingsoyr et al. 2019:37).

Den andra slutsatsen är vikten av en gemensam backlogg. I början av projektet fanns olika ägare till olika backloggar vilket skapade problem såsom att det var svårt att flytta delar från en backlogg till en annan och det var svårt att göra prioriteringar mellan de olika backloggarna för att säkerställa att projektet i sin helhet kunde fungera bra. Lösningen, att organisera en gemensam backlogg innebar att flera aktörer kunde arbeta parallellt och att det fanns en gemensam prioritering. Det innebar även en ökad effektivisering och en bättre överblick över de beroenden som fanns mellan olika delar (Dingsoyr et al. 2019:38).

Den tredje slutsatsen är vikten av att ha en löpande lösningsbeskrivning. Här användes user stories för att beskriva arbetet (Dingsoyr et al. 2019:3). User story är en kort beskrivning över ett behov som en part har gällande funktionalitet i en mjukvarulösning (Dingsoyr et al. 2019:8).

Behovsanalysen och lösningsbeskrivningarna sammanfogades också för att skapa förutsättning för en mer effektivt utnyttjande av resurser eftersom då bara user stories som skulle införas var de som beskrevs (Dingsoyr et al. 2019:38).

Den fjärde slutsatsen är att det är bra om teamen själva kunde besluta om vilken detaljnivå som arbetet skulle beskrivas på, eftersom olika team hade behov av olika nivåer av detaljer (Dingsoyr et al. 2019:38).

Den femte slutsatsen är att det är en fördel att införa extra roller vid starten av projektet som kunde underlätta koordineringen mellan de olika teamen. Detta ledde i sin tur till högre kvalitet i utvecklingen liksom engagemang och möjlighet till ett effektivare utbyte av kunskap (Dingsoyr et al. 2019:38).

Den sjätte slutsatsen är att i likhet med fördelen av att införa extra roller, finns en fördel i att införa extra arenor för att säkerställa den effektiva koordineringen mellan teamen när

utvecklingen skalas upp. Här rekommenderas en matris för att säkerställa att viktiga frågor blir adresserade och även för att minska eventuella överlämningar då frågor behöver lösas utanför utvecklingsteamen (Dingsoyr et al. 2019:38).

Den sjunde slutsatsen är att det är bra att ha ett projekt för att genomföra testningen med tillhörande resurser. Detta projekt kunde då definiera hur det skulle definieras när projektet var klara och på team nivå var en person ansvarig för att säkerställa att testningen genomfördes (Dingsoyr et al. 2019:39).

Den åttonde slutsatsen var en godkännandeprocess och förbättrad process för lanseringar. Den tilltänka lanseringsprodukten kunde gå igenom en godkännande process inför att den överfördes till acceptanstestningen. Fördelen med den extra processen var att det då kunde säkerställas icke funktionella egenskaper såsom produktens robusthet och prestanda (Dingsoyr et al. 2019:39).

Den nionde slutsatsen handlade om vikten av att lära sig av sina tidigare erfarenheter, att genomföra förbättringar genom tillbakablickar. Alla deltagare skulle efter varje iteration lämna in sina lärdomar till en gemensam wiki. Lärdomarna lästes av ledningen som också ledde till förändringar och förbättringar (Dingsoyr et al. 2019:39f).

Slutligen gavs tio minuter efter varje iteration för demonstrationer med syfte att skapa en lärande arena, förbättring skedde genom demonstrationer. Till demonstrationerna bjöds alla in, och detta skapade viktiga möjligheter för kommunikation mellan teamen. Demonstrationerna kostade mycket att genomföra men var en mycket viktig arena för att dra lärdomar (Dingsoyr et al. 2019:40).

4.2 Implementing Large-Scale Agile Frameworks: Challenges and Recommendations (A2)

Conboy och Carroll (2019:1) identifierar i sin artikel, nio olika utmaningar med införandet av agila ramverk i stor skala såsom exempelvis SAFe, Scrum-at-Scale och LeSS. De baserar sina slutsatser på 13 agila transformationer över 15 år och menar att dessa utmaningar är bra för organisationernas att uppmärksamma inför ett agilt arbete i stor skala.

Den första utmaningen som identifieras är det faktum att ramverken, såsom exempelvis SAFe, erbjuder en bra grundläggande genomgång av ramverket, men att om ramverken används utanför dess tänkta kontext blir det svårt att få vägledning för hur ramverket kan tillämpas.

Flera utvecklare har pratat om missförstånd som uppstått mot bakgrund av detta, och att det kan leda till inkonsekvens gällande hur ramverket används i respektive fall. Vissa menar att det används abstrakta termer utan en grundläggande förklaring vilket gör det svårt att undersöka möjligheterna att applicera vissa delar. Detta kan bli en stor nackdel eftersom en otydlighet i hur det nya ramverket ska införas och appliceras kan leda till att medarbetarna i organisationen fortsätter att arbeta på det gamla sättet (Conboy & Carroll 2019:3).

Den andra utmaningen består i att det finns många olika ramverk och urvalet av vilket som ska användas kan vara svårt att göra för organisationen. Det saknas utvärderingsmatriser eller modeller för att jämföra de olika ramverken på ett bra sätt för att hitta det bästa ramverket för den egna organisationen. Detta kan leda till att ramverken väljs ad hoc och på ett slumpmässigt sätt, och ibland kan valet inte spåras till ett beslut (Conboy & Carroll 2019:3f).

Den tredje utmaningen består i hur väl medarbetarna och organisationen är redo för att göra en förändring mot ett nytt arbetssätt och ramverk, och en utmaning är om organisationen är omogen att göra förändringen. Vidare kan medarbetare vara positiva till förändringar generellt utan att vara villiga att vilja arbeta efter det utvalda ramverket. Här finns erfarenheter av att införande av ramverk lett till passivitet hos medarbetare och passivitet och fortsätter att arbeta efter tidigare modeller (Conboy & Carroll 2019:4).

Det kan även vara en balansgång mellan att sammanföra ett ramverk som ska fungera för många organisationer med den egna organisationens förutsättningar. De ramverken som finns har en fördefinierad struktur, rutiner och verktyg som passar för att arbeta enligt ramverket.

Organisationerna som ska införa ramverket kan däremot stå inför förutsättningar att de behöver anpassa sin verksamhet kontinuerligt exempelvis i enlighet med lagkrav som ställs på verksamheten. Vid en agil metod kan anpassningar göras kontinuerligt men de större agila ramverken såsom SAFe är mer dominanta vilket innebär att mindre anpassningar kan leda till stora störningar i organisationen som helhet (Conboy & Carroll 2019:4).

Den femte utmaningen handlar om oklara roller vid implementeringen. Författarna menar att det vanliga är att olika införandeprojekt drivs som nedifrån och upp eller tvärtom, men sällan som en mix av dessa två sätt. I mindre agila projekt är det vanligt att projekten drivs nedifrån och upp, men det är mer oklart vid stora agila ramverk såsom SAFe. Eftersom det är oklart hur projekten drivs skapas en oklarhet och osäkerhet kring vilken roll som ledningen tar, hur mycket och på vilket sätt som de är engagerade. Detta förstärks av det faktum att det är svårt att hitta erfarna coacher inom SAFe som kan stödja processen (Conboy & Carroll 2019:4f).

Den sjätte utmaningen handlar om att det finns en utmaning i att hitta indikatorer vid utvärderingen som mäter rätt sak. Många vittnar om att det snarare utvärderas hur väl som ramverket efterlevs i organisationen snarare än vilket värde som ramverket ger organisationen.

Några vittnar om att det handlade om att uppnå resultat i hur många team som deltog i processen snarare än det resultat som arbetet levererade (Conboy & Carroll 2019:5). Det kan i sin tur bero på att det kan vara svårt att hitta rätt indikatorer att mäta eftersom det kräver hög förståelse från ledningen att ta fram rätt indikatorer.

Den sjunde utmaningen består i avsaknaden av empiriskt underlag för att använda ramverken i verkligheten. Det saknas i flera fall underlag över hur medarbetarna ska applicera ramverket till sin verklighet och kontext och där det inte finns någon vägledning i ramverket (Conboy &

Carroll 2019:5).

Den åttonde utmaningen baseras i balansgången att vid införandet av metoden samtidigt behålla utvecklarnas självständiga roll. Många utvecklare är vana vid att kunna styra många av förutsättningarna för sitt arbete, och generellt blir det svårare att behålla självständighet i takt med att projekt skalas upp (Conboy & Carroll 2019:5f).

Slutligen pekar författarna på utmaningen av att anpassa den egna kundprocessen med ramverket. Många organisationer arbetar idag med en kundorienterad process där kunderna är aktiva i olika delar av organisationen. Dessa agila ramverk har fördefinierade processer och modeller som inte alltid anses vara lätta att kombinera med att vara ett företag som lyssnar till kunderna och som är lättrörliga och anpassningsbara. Detta medför att för vissa av företagen behövs antingen ramverket helt väljas bort eller anpassas vilket är mycket tidskrävande (Conboy & Carroll 2019:6).

4.3 Implementing Scaled-Agile Frameworks at Non-Digital Born Companies – A Multiple Case Study (A3)

Schuch et al. (2020:4336) har i sin artikel tittat på vilken införandemetod som används vid införandet av ett agilt ramverk, såsom i stor skala. De olika metoder som undersöks är om införandet sker nedifrån och upp eller uppifrån och ner. Vidare undersöks vilka konsekvenser dessa olika val av införandemetoder får för verksamheten. Sex olika företag undersöks i olika storlek och med olika typer av verksamhet. Resultaten visar att företagen antingen följer en uppifrån och ner införandemetod eller en nedifrån och upp metod. När införandet sker uppifrån och ned definieras produktstrukturen först i ledningen innan den förs ner i organisationen.

Motsatsen är för de företag som följer nedifrån och upp metoden som börjar arbetet med att starta upp agila team och därefter bygger på med andra strukturer. Vidare argumenterar författarna för att det finns en relation mellan den införandemetod som valts och det mål som företaget har. Fallstudierna visar att de företag som hade som yttersta mål att reducera organisationens komplexitet och öka kundcentreringen, valde en uppifrån och ner införandemetod. Företagen som hade som mål att öka takten för leveranser och minska tiden för att få ut produkterna till marknaden valde en nedifrån och upp metod (Schuch et al 2020:4342).

4.4 Inter-team Coordination in Large-Scale Agile Development: A Case Study of Three Enabeling Mechanisms (A4)

Bjornson et al. (2018:216) konstaterar att en central fråga vid användandet av agila metoder i stora utvecklingsprojekt blir vad som krävs för att effektivt koordinera teamen. Författarna studerar tre olika mekanismer för koordinering: Delade mentala modeller, kommunikation och förtroende.

Den första faktorn, att teamet delar mental föreställning över uppdraget innebär att teamet förstår arbetsprocessen och dess uppgifter. Här konstateras att det enligt författarna finns en skillnad mellan förutsättningarna för att kunna uppnå detta mellan de olika ramverken då Scrum är lättast att förstå med färre roller och arbetspaket. När ramverket byggdes på med ytterligare roller och uppgifter blev dock bilden mer komplex och författarna konstaterar att detta riskerar att minska möjligheten för teamet att dela samma bild över uppdraget. Författarna konstaterar också att SAFe är mer komplex som ramverk och kräver därmed mer insatser för att kunna delas som en mental modell (Bjornson et al. 2018:225f).

Den andra faktorn handlar om återkommande kommunikation. Den agila metoden har lett till kortare ”feedback-loopar”. ”Closed-loop kommunikation” genomförs genom återkommande och nära återkopplingar och koordinering mellan teamen genom planering och demonstrationer, eller förändringar och förbättringar av produktbackloggen. Slutligen genomförs även regelbundna genomgångar och diskussioner av resultaten med de olika aktörerna (Bjornson et al. 2018:226).

Slutligen är det viktigt att det finns förtroende, dels från ledningen till teamet, men även mellan teamen vilket innebär att teamen ska skyddas från distraktioner utifrån, under en iteration.

Eftersom agila metoder grundar sig i tanken om transparens bidrar de till att utveckla förtroende.

Förtroende kan även ökas genom, personlig närvaro, gemensamma arbetsytor och aktiviteter, liksom öppen och informell kommunikation. Här påpekas även att det finns en relation mellan storleken på team och förtroende vilket kan förklara enligt författarna varför den agila metoden generellt passar bättre i mindre organisationer jämfört med större. Något som troligen ökar

förtroendet är de förbättring genom tillbakablick som används i ramverken. Samtidigt är det en utmaning med förtroende i stora agila ramverk, och det är svårt att utveckla med de förutsättningarna (Bjornson et al. 2018:226f).

4.5 Scaling Agile (A5)

Ebert och Paasivaara beskriver sju olika lärdomar de dragit genom genomförandet av att implementera ett agilt ramverk i stor skala i två organisationer. Den första lärdomen är att försöka gå från de klassiska ansvarsområdena i organisationen till mindre och mer gränsöverskridande team. Det andra är att utnyttja fler möjligheter till lärande och uppföljning genom att säkerställa täta uppföljningar mellan hårdvarutvecklare, mjukvaruutvecklare och underhåll/service. Den tredje lärdomen är att ge mandat till de team som är utspridda över organisationen, för att de ska kunna driva processerna framåt. Här är dokumentation centralt.

Den fjärde lärdomen är att möjliggöra en ständig integration av systemen. Den femte lärdomen är att underlätta och möjliggöra för automatisering och innovativa lösningar. Den sjätte lärdomen är att säkerställa relevant kunskap för kritiska system och slutligen att säkerställa möjligheten att återanvända olika lösningar för att bättre kunna följa med i omvärldens snabba förändringstakt gällande komponenter och miljöer (Ebert & Paasivaara 2017:102).

Ebert och Paasivaara (2017:102) identifierar två huvudfrågor som är viktiga för organisationerna vid en implementering av ett agilt ramverk i stor skala. Den första huvudfrågan är att det tar mycket energi att anpassa ramverket till den egna konkreta verksamheten, den egna miljön och kulturen. Det finns inga genvägar i att implementera delar av ramverket, det måste implementeras hos medarbetarna för att kunna spridas till hela organisationens kultur.

Den andra huvudfrågan författarna identifierar är att agila ramverk kräver mer omfattande insatser för att uppnå förändring. Snarare än att ändra på några processer inom en organisation kräver dessa ramverk att hela organisationen kan anpassa sig till processer, roller och verktyg.

Hela organisationen behöver anpassa sig, inte bara några av teamen som verkar i organisationen (Ebert och Paasivaara 2017:102).

4.6 Adopting SAFe to Scale Agile in a Globally Distrubuted Organization (A6)

Paasivaara konstaterar i sin fallstudie (2017) att det finns litet empiriskt underlag för hur införandet av agila ramverk i stor skala kan ske. I hennes fallstudie jämför hon hur ett företag införde SAFe i två av företagets processer. Jämförelsen av dessa två införandeprocesser belyste att det fanns faktorer som påverkade ett framgångsrikt införande. Slutsatsen som Paasivaara kan dra är nöjdheten hos medarbetarna sjönk efter införandet av det nya agila ramverket och flera angav införandet av SAFe som anledningen till deras minskade nöjdhet. Tvärtom tyckte de som arbetade i företagets process nummer två att det fungerade bra med SAFe, 70% svarade att de tyckte SAFe var bra (Paasivaara 2017:39). I Paasivaras artikel listas de framgångsfaktorer som ledde fram till det lyckade införandet i företagets process nummer två.

Den första viktiga framgångsfaktorn var att investera i utbildning och träning i ramverket tidigt i införandeprocessen och inte enbart inför att problem uppstått. I företagets ena process utbildades medarbetarna först efter några månader efter införandet när problem hade uppstått.

Avsaknaden av utbildning var något som togs upp av de som intervjuades på det företaget. I företagets andra process investerades i träning för alla ledare från alla involverade siter, vilket upplevdes som verkligt nyttigt (Paasivaara 2017:38).

Den andra framgångsfaktorn var att engagera medarbetarna i processen istället för att genomföra ett införande genom en topp-styrd modell. I företagets första process initierades förändringen från ledningen och varken produktägarna eller teamen var involverade. Detta ledde till motstånd mot förändringen, något som förstärktes av avsaknad av kunskap om SAFe som skulle införas i kombination med svag kommunikation. I företagets andra process hade ledningen förväntat sig ett starkt motstånd mot införandet av SAFe, men de möttes inte av ett starkt motstånd. Anledningarna antas vara god kommunikation och träning tidigt i ramverket, och även att de problem som uppkom kunde lösas på en gång vilket ökade medarbetarnas nöjdhet. Slutligen upplevade inte teamen en stor förändring i jämförelse med tidigare arbetssätt (Paasivaara 2017:38f).

Den tredje framgångsfaktorn var att ha interna och externa förändringsledare som kunde leda övergången på heltid. I företagets första process hade teamet endast tillgång till detta på ett geografiskt långt avstånd och på deltid, medan de i företagets andra process hade tillgång till en förändringsledare på heltid som också var fysiskt närvarande (Paasivaara 2017:39).

Den fjärde framgångsfaktorn var att ta hjälp av externa coacher vid införandet. I företagets första process fanns ingen hjälp av externa coacher i början av processen, vilket framkom som en förbättringsåtgärd i interjuver. I företagets andra process togs en extern coach in för att stödja processen genom att arrangera utbildning och workshops för flera olika roller på företaget (Paasivaara 2017:39).

Release Train Engineers (RTE) är ledaren och coachen för en av utvecklingsprocesserna kallad Agile Release Train (ART). RTE har som uppgift att underlätta för den processen och för teamen som arbetar med processen (Scaled Agile Framework 2020a). I företagets första process som studerades av Paasivaara (2017:39) fanns hjälp av en RTE på halvtid, vilket innebar att det saknades tid för systematisk ledning och kontinuerliga förbättringar. I företagets andra process som studerades fanns en RTE på full tid vilket nämndes som en viktig framgångsfaktor då hon kunde arbeta såväl med koordinering som ledarskap och förbättringar.

Det första planeringsmötet, som inom ramverket SAFe kallas Program Increment (Scaled Agile Framework 2020b) som genomfördes inom företagets första process som studerades av Paasivaara (2017:39) resulterade i att deltagarna upplevde stor osäkerhet och något av ett kaos.

Det var ett dåligt förberett möte där deltagarna inte visste vad som förväntades av dem. I företagets andra process som studerades var däremot mötet väl förberett och möjliggjorde även för deltagarna att förbereda sig väl. Deltagarna tyckte att mötet gick bra och var även positiva till ramverket som helhet generellt sätt.

I företagets första process som studerades av Paasivaara (2017:39) konstaterades när det gäller att göra löpande förbättringar att de förbättringsåtgärder som lyftes inte ledde till några åtgärder. I företagets andra process var dock ett fokus att de förbättringsförslag som lyftes resulterade i planer och ansvariga personer som skulle införa förändringar. Detta sätt att arbeta på skapade en stor nöjdhet hos medarbetarna eftersom många insåg när de stötte på problem att det gick att förbättra dessa.

4.7 Scaling Agile Software Development to Large and Globally Distributed Large-scale Organizations (A7)

Putta (2018:136) konstaterar i sin artikel att många organisationer under senare tid arbetat enligt modellen att de vill utnyttja fördelarna med den agila metoden i en större skala. Putta menar vidare att det förekommit olika definitioner av vad som avses med stora agila projekt. Stora agila projekt menar författaren karakteriseras av antalet team, dess storlek, komplexitet, antal rader kod, projektets tid och kostnad. Författaren menar vidare att det kan handla om distribuerade team över geografiska platser. ”Scaling” menas att det agila används av flera olika team eller av andra organisatoriska enheter såsom exempelvis marknadsavdelningen eller HR- avdelningen. Författaren konstaterar att tillgängliga studier inom området är få och vill med sin forskning bidra till att stänga den klyfta mellan akademisk litteratur och praktiker.

De preliminära resultat som författaren presenterar i artikeln är att bakgrunden till att flera organisationer vill använda de agila ramverken är att det finns en väl beprövad struktur kring metoden, att det finns en efterfrågan på marknaden och att det möjliggör att driva projekten i större skala med fler personer. Fördelarna med införandet av ramverken är kvalitet, transparens, samarbete, produktivitet och samstämmighet. Utmaningarna är motstånd till förändringar, att gå längre från det agila, kontroverser med ramverket, utmaningar specifikt relaterade till olika delar av ramverket såsom exempelvis problem med ”Agile Release Train”. Utöver det tar även författarna upp intressanta steg mot en transformation såsom att ett steg är en kulturell förändring, utbildning, övning och workshops i ramverket, att teamen behöver formeras och transformeras samt att vattenfallsmetoderna och de avdelningar som inte arbetar med utveckling behöver integreras till det agila arbetssättet (Putta 2018:138).

4.8 Scaling agile in large organizations: Practices, challenges, and success factors (A8) Kalenda et al. (2018:1) konserterar att det innebär många utmaningar att arbeta med agila ramverk i stor skala och diskuterar i sin artikel vilka kritiska framgångsfaktorer som finns i det arbetet genom att undersöka såväl vetenskaplig litteratur såsom företag. Kelenda et al.

konstaterar att det finns flera faktorer som är framgångsfaktorer avseende att arbeta med agila ramverk i stor skala. En framgångsfaktor är om det finns tidigare erfarenheter av att arbeta med Lean eller agila metoder (Kalenda et al. 2018:3), då detta ger ett gott kunskapsunderlag för att arbeta vidare med ramverket. En annan framgångsfaktor var ett tydligt stöd från ledningen, såsom att resurser tillgängliggörs, men även att ledningen stöttar och hjälper medarbetarna växa snarare än övervakar dem. Slutligen är en framgångsfaktor om det finns en gemensam syn inom företaget och medarbetarna delar samma värdegrund. Detta kunde säkerställas i författarnas exempel av införandet av ”Agila och Lean manifestet” för att underlätta för företaget att anamma samma värden.

Utmaningar som identifierades var för det första motstånd till förändringen. Även om flera hade arbetat agilt fanns det medarbetare som inte uppskattade de förändrade arbetssätten. I detta låg även att de utvecklingsteam som tidigare haft helt egna möjligheter att styra sitt arbete nu var tvungna att arbeta efter det nya ramverket, vilket många inte ville göra. Ytterligare en utmaning var en för snabb process till att övergå till det nya ramverket. Om omställningen gjorts långsammare eller i flera steg hade troligen motståndet mot förändringen blivit mindre. Den tredje utmaningen var att säkerställa kvaliteten då företaget i början av processen med en ny plattform gav utvecklarna full frihet över utvecklingsprocessen vilket innebar att delar i

ledningen av utvecklingsprocesserna inte fungerade fullt ut. Slutligen fanns en utmaning med att integrera den icke-agila delen av verksamheten. Stora delar av organistsonen arbetade enligt icke-agila metoder vilket innebar att i en övergångsperiod behövde medarbetare i olika processer med olika metoder (Kalenda et al. 2018:3).

4.9 Large-scale agile transformation at Ericsson (A9)

Paasivaara et. al (2018:2550) har genomfört en fallstudie över Ericsson och presenterar fyra slutsatser för agila transformationer i stor skala. Den första slutsatsen som presenteras är att det bör övervägas att använda en agil och experimentell inställning i organisationen inför en transformation. Författarna menar att en framgångsrik metod som användes var att det i organisationen uppmuntrades att medarbetarna skulle försöka sig fram och att det var bra att försöka och ok att misslyckas eftersom det är det enda sättet att lära sig. Det fanns en öppen attityd i organisationen och en vilja att lära och ändra om något inte fungerade. Denna lärdom menar författarna är användbar i många kontexter liksom i både stora agila transformationer som små agila projekt (Paasivaara 2018:2585f).

Den andra lärdomen som drogs var att det är bra att använda en gradvis genomförande av en agil tranformation i stor skala. Det är också bra att koncentrera sig kring en stor fråga i taget för att behålla fokus på de viktigaste frågorna gällande förändringen. Det är en stor förändring att genomföra en agil transformation och i den fallorganisation som författarna studerade valdes att genomföra den steg för steg för att kunna fokusera på en förändring i taget. En ”big bang”

transformation anses troligen inte ha fungerat i detta fall eftersom organisationen förväntades fortsätta att leverera till dina kunder även under tiden som transformationen genomfördes. På detta sätt blev det lättare att anamma det nya ramverket eftersom det inte heller var möjligt att planera allt i förväg (Paasivaara 2018:2586f).

Den tredje lärdomen är att inte alla kan arbeta med allt i en produktbacklogg i stora agila projekt, istället kan det vara nödvändigt med en viss specialisering av teamen. I början av transformationen fanns målet att alla agila övergripande team skulle kunna arbeta med alla frågor i den gemensamma backloggen. Det upptäcktes dock senare inte vara en bra lösning på grund av den komplexa produkten samt en obalans i kompetenserna (Paasivaara 2018:2587f).

Slutligen drogs en fjärde lärdom från arbetet, att avsaknad av ett gemensamt agilt ramverk vid starten av transformeringen, avsaknad av gemensam övning och utbildning i organisationen och avsaknaden av tillräcklig och enhetlig coachning kan leda till avsaknad av gemensam inriktning för arbetet med införandet. I införandet gavs mycket ansvar till respektive team, men på ett sätt som innebar att de olika teamen valde att arbeta på olika sätt. Avsaknad av coacher ledde till att ingen utmanade teamen i att resonera i hur de skulle arbeta agilt på bästa sätt.

Sammansättningen av teamen innebar också att flera medarbetare inte arbetat ihop sedan tidigare utan kom från olika kulturer och vanor, och ingen av medarbetarna kände sig bekväm med att säga att de skulle använda just deras arbetssätt i det nya teamet. Författarna konstaterar att även om det är viktigt med en hög grad av självbestämmande för teamen i det agila arbetssättet, är även en gemensam inriktning för arbetet viktigt såväl som gemensam övning och utbildning för att säkerställa en likriktighet i organisationen (Paasivaara 2018:2588f).

Fallstudien bekräftar denna balansgång som mycket viktig.

4.10 Agile Development at Scale: The Next Frontier (A10)

Dingsoyr et al. (2019:31f) skriver om hur de agila metoderna utvecklas mot att användas i stor skala. Vidare diskuteras varför det finns ett stort fokus kring de agila metoderna i stor skala nu.

Författarna menar att det finns tre anledningar till detta. Den första anledningen är att det finns ett globalt fokus på digitalisering vilket har gett mjukvaruutveckling generellt ett uppsving eftersom förståelsen av dess betydelse ökar i samhället. Den andra anledningen som identifierats är att tidiga studier som genomförts visar utmaningar med flera olika områden med de agila metoderna i stor skala, såsom att koordinera team och dess arbete. Författarna pekar på behovet av fler studier i frågan i takt med att flera nya ramverk kommer på marknaden i hur arbetet agilt i stor skala kan bedrivas. Slutligen har företagsledningar fått en ökad insikt av vikten av mjukvara, vilket leder till ett ökat fokus på utvecklingsmetoder för att säkerställa företagets möjlighet att vara konkurrenskraftiga. Författarna menar att insatserna blir högre i takt med att ramverken används i större skala. Författarna pekar även på risken i att titta för mycket på ett ramverk och försöka följa det, snarare än att fundera på vilka frågor som man vill lösa i organisationen. Att introducera ett agilt ramverk i stor skala är en mycket stor fråga och ska därför mötas med respekt menar författarna (Dingsoyr et al. 2019:37).

4.11 Impacts on Team Performance in Large-Scale Agile Software Development (A11)

Den agila metoden i stor skala används av fler organisationer konstaterar Gustavsson (2018:421) och innebär behovet av nya metoder för att koordinera teamen. Många organisationer väljer att implementera agila ramverk i stor skala, men författaren konstaterar vidare att det inte finns så många studier på området. Vidare diskuteras utmaningen som finns mellan att lämna ansvar och makt till varje team och samtidigt kunna uppnå en god styrning mot gemensamma mål. Studien avser att ge mer kunskap i området om koordinering av team och effektivitet inom det agila ramverket i stor skala.

Två faktorer undersöks i artikeln för att diskutera teamets prestation. Den första faktorn som diskuteras är koordinering mellan olika team. Författaren menar att det finns två krafter som skapar ett behov av koordinering mellan teamen i ett projekt med flera team, den första kraften är uppgifter som är beroende av varandra och det andra är förändringar som sker under utvecklingsprocessen. Att uppgifterna är beroende av varandra skapar ett behov av input och samordning. Den andra kraften innebär att utvecklingsprojekt är svårplanerade och karakteriseras av förändringar, vilket ofta påverkar flera team. Detta kan bara bemötas genom information mellan de olika teamen. Den första hypotesen är att koordinering mellan olika team är positivt associerad med teamets prestation (Gustavsson 2018:423). Den andra faktorn som undersöks är den psykologiska säkerheten vilket omfattar att våga be om hjälp, erkänna fel och be om feedback. Medarbetare i team kan vara avvaktande inför att göra detta, även om det skulle vara positivt för organisationen som helhet. Författarnas andra hypotes är att psykologisk säkerhet är positivt associerad med teamets prestation (Gustavsson 2018:423). Författarens undersökning visade att det fanns lite stöd för den första hypotesen, att koordinering i agila projekt i stor skala (där SAFe blivit infört) ledde till bättre prestation av teamet. Däremot fanns det stöd för att ju starkare den individuella säkerheten är, desto bättre prestation från teamet i agila projekt i stor skala (Gustavsson 2018:428f).