Hinder vid agila arbetssätt hos myndigheter

Hinder vid agila arbetssätt hos myndigheter

960206, 971016, 960907

HT20

Informatik med systemvetenskaplig inriktning, kandidat 15 hp Ämne: Informatik

Handelshögskolan vid Örebro universitet Handledare: Kai Wistrand Examinator: Anders Avdic

Sammanfattning

Agila metoder är idag utbredda inom näringslivet men även myndigheter har till viss mån försökt att anamma dessa. Myndigheter är komplexa och stora organisationer vilket försvårar arbetet med agila metoder. De präglas även ofta av byråkratiska strukturer som bygger på kontroll och ansvarsutkrävande, vilket hämmar genomförandet av agila metoder.

Studiens syfte är att identifiera hinder som uppstår vid utövningen av agila metoder och bidra med kunskap för hur myndigheter bör utöva samt skala upp agila metoder inom

organisationen. För att undersöka dessa hinder har insamlad empiri ställts emot relevant forskning inom styrning, storskalig systemutveckling samt studiens teoretiska ramverk SAFe. Studien bygger på en fallstudie utförd hos en svensk myndighet under vilken

semi-strukturerade intervjuer med 13 medarbetare har genomförts. Studien har undersökt visionen för arbetssätt, transparensen och beslutsfattandet hos myndigheten och kan utifrån

undersökningen fastställa att brister inom dessa områden skapar hinder för genomförandet av agila metoder. Det framgår att när olika avdelningar tillämpar olika arbetssätt för

gemensamma processer hindrar det samförstånd kring systemutvecklingen. Det är hinder som kan härledas till en avsaknad av en gemensam vision för arbetssätt inom myndigheten, en avsaknad av en tydlig strategi för hur samarbete mellan olika avdelningar ska uppnås och hur rätt kompetens ska säkerställas, i syfte att öka samförståndet. Studien har även kunnat

identifiera brister i kommunikation och en avsaknad av transparens vid informationsdelning samt en toppstyrning som inte främjar en självstyrande arbetsmiljö. Brister som hämmar framgången med agila metoder.

Centrala Begrepp

1. Agil uppskalning: Innebär att agil utveckling utförs av flera team på en större nivå. 2. Sprint: Ett kort tidsintervall under vilken ett systemutvecklingsteam arbetar med att

vissa utvalda krav.

3. Vision: En önskvärd framtida situation. Hur en organisation ska se ut i framtiden. Den ska vara inspirerande men behöver inte vara mätbar.

4. Mål: Utmanande men realistiska saker man vill uppnå inom en organisation. De ska vara mätbara och kan finnas för flera olika delar av en organisation.

5. Strategi: Varje uppsatt mål inom en organisation ska följas av en strategi. Strategin förklarar hur en organisation ska uppnå uppsatta mål, det vill säga vad som behöver göras.

6. Transparens: Synonym för klarhet, i fråga om information: öppenhet

7. Decentralisera: Makt-/ ansvarsförskjutning inom en organisation nedåt i hierarkin. 8. Scrum: Ett ramverk för agil systemutveckling.

9. Produktägare: En roll som innehas av en person från verksamheten som är väl insatt i det område som systemutvecklingen sker inom.

10. Kadens: En kontinuerlig leveranskedja som skapar ett rytmiskt mönster för systemutvecklingsprocessen.

11. Release: När systemet levereras. Kan bestå av mindre komponenter eller färdiga system

12. PSG: (Portfolio styrgrupp) En grupp individer som ansvarar för styrningen av en eller flera portföljer, som innefattar att identifiera, prioritera, styra och följa upp initiativ, program och projekt för att verksamheten ska nå sina strategiska mål.

1.0 Inledning 1 1.1 Problematisering 2 1.2 Syfte 2 1.3 Problemformulering 3 2.0 Relaterad forskning 3 2.1 Styrning 3

2.2 Large Scale Agile 4

3.0 Bakgrund till teoretiskt ramverk 5

3.1 Agila manifestet 5

3.2 Lean 7

3.3 Lean begreppet kopplat till systemutveckling 7

4.0 Teoretiskt Ramverk 8 4.1 SAFe Bakgrund 8 4.2 Core Values 8 4.3 SAFe principer 10 4.4 Teoretisk avgränsning 12 5.0 Metod 12 5.1 Fallstudie 13 5.2 Litteratursökning 13 5.3 Intervju 14 5.3.1 Intervjuguide 14 5.4 Analysmetod 15 5.4.1 Analys av intervjuer 16 5.5 Metodkritik 17 5.6 Etik 18 5.6.1 GDPR 18

6.0 Resultat & Analys 19

6.1 Gemensam vision för arbetssättet 19

6.1.2 Säkerhetsställa kompetens 20

6.3 Decentraliserat beslutsfattande 25

7.0 Diskussion 28

7.1 Gemensam vision för arbetssätt 28

7.2 Transparens 29

7.3 Decentraliserat beslutsfattande 30

8.0 Slutsats 32

9.0 Förslag på vidare studier 33

10.0 Källförteckning 34

1

1.0 Inledning

Historiskt sett har systemutvecklingsprojekt utförts med metoder som baserats på sekventiella vattenfallsmodeller. Dessa traditionella metoder har visat sig vara problematiska när förändringar uppstår under systemutvecklingsprojekt (Fitzgerald et al., 2002). Till skillnad från traditionella metoder har agila metoder en förmåga att bemöta problematiken med mer föränderliga systemutvecklingsprojekt (Berger, 2007). Agila systemutvecklingsmetoder grundar sig i det agila manifestet som lanserades 2001 av Beck et al. (2001). Syftet med agila metoder är att öka effektiviteten och flexibiliteten i systemutvecklingsprojekt för att bemöta förändringar på ett produktivt sätt. Detta genom att förespråka minskad dokumentation, specifikation, administration och andra improduktiva aktiviteter (Nuottila et al., 2016).

Agila metoder som från början var utformade till småskaliga organisationer med få team och ett få antal anställda är idag ett utbrett arbetssätt som även stora organisationer implementerar. I samband med marknadsförändringar har större organisationer insett att tidigare vattenfalls baserade processer inte är lämpliga för att genomföra snabba releaser och anpassningar till nya krav från marknaden. Detta behov av effektivitet och flexibilitet driver spridningen av agila systemutvecklingsmetoder som bättre svarar till att möta kundens förväntningar inom såväl stora som små organisationer (Paasivaraa et al., 2014).

En enkät genomförd av Project Management Institute under Project Management Event of the 2017 Pulse of The Profession påvisar att utvecklingen av tillämpning av agila tillvägagångssätt ökat drastiskt. Utifrån enkäten fastställdes att upp till 71% av alla organisationer tillämpar agila metoder i sina projekt (PMI, 2017).

Trots ökningen av agila metoder inom privat sektor har inte samma utveckling skett inom den offentliga sektorn. Något som även återspeglas i rådande forskning, där endast ett fåtal forskningsstudier berör agila metoders implementation hos myndigheter (Nuottila et al., 2016; Ghimire et al.,2020).

Dietel & Heine (2020) menar att under perioden 2011 till 2015 så misslyckades 24 procent av statliga IT projekt som genomfördes världen över. Cirka 55 procent av dessa projekt genomfördes inte inom fastställd tidsram, kostnad eller omfattning. Studier har påvisat att projekt som genomförs med ett agilt styrande har fyra gånger högre chans att nå framgång än projekt som genomförs med traditionell vattenfallsmodell (Dietel & Heine, 2020). Mergel (2016) har studerat de amerikanska myndigheterna och menar att historiskt har statliga systemutvecklingsprojekt genomförts utifrån vattenfallsmodellen. På senare tid har dock det agila arbetssättet börjat att influera även den statliga sektorn (Dietel & Heine, 2020).

2

1.1 Problematisering

Införandet av agila metoder inom den offentliga sektorn har varit problematiskt på grund av omfattande kontroll och regelverk gällande beslutfattande (Dietel & Heine, 2020). Generellt karaktäriseras myndigheter av byråkratiska strukturer som betonar att styrning ska ske konsekvent och kontrollerat genom förutbestämda regelverk. Utövning av kontroll vid beslutsfattande är något som i byråkratiska kulturer skapar normer där beslut eskaleras uppåt i hierarkin. Detta i sin tur begränsar individens möjligheter att ta egna beslut (Berger, 2007). Utöver de utmaningar som finns med de byråkratiska strukturer som präglar offentlig sektor uppstår det även utmaningar på grund av den storskaliga agila utvecklingen. Enligt Dingsøyr et al. (2014) är klassifikationen för storskalig agil utveckling att organisationer ska innefatta minst 50 utvecklare uppdelat på minst 5 agila team. Ett flertal statliga myndigheter i Sverige faller under denna definition där bl.a kronofogden, migrationsverket och pensionsmyndigheten som enligt egna uppgifter har mellan 200-300 anställda på respektive IT-avdelning (Kronofogden, 2020 ; Migrationsverket, 2020 ; Pensionsmyndigheten, 2020). Problematiken som storskalig agil utveckling medför grundar sig bland annat i den trögheten som orsakas av storleken på organisationen och dess systemutvecklingsprojekt (Paasivaara et al., 2018).

I syfte att bemöta problematiken med uppskalning av agila metoder har ett flertal olika ramverk tagits fram. Paasivaara et al. (2018) pekar ut Scaled Agile Framework (SAFe) och Large-Scale Scrum (LeSS) som exempel på dessa typer av ramverk.

Bland framtagna ramverk för uppskalning av agila metoder har Scaled Agile Framework utifrån genomförda undersökningar det högsta antalet tillämpningar inom organisationer (Paasivaara et al., 2018). I syfte att undersöka hinder kring uppskalning av agila metoder samt dess tillämpning inom systemutveckling hos svenska myndigheter har ramverket SAFe bedömts vara lämpligt och det vi kommer att använda i denna studie. Trots att tillämpningen av dessa ramverk ökat har enbart ett fåtal studier undersökt hur en agil uppskalning bör gå till inom större organisationer (Paasivaara et al., 2018). Enligt Ghimire et al., (2020) behöver ytterligare studier undersöka faktorer bakom framgångar likväl som misslyckande med agila metoder inom offentlig sektor för att utöka förståelsen inom ämnet. Även Nuottila et al. (2016) föreslår fler undersökningar inom offentlig sektor för att reda ut problematiken med bl.a dokumentation, utbildning, erfarenhet och engagemang, kommunikation med intressenter samt roller inom agila organisationer. Detta för att se vilka praktiska förutsättningar som är nödvändiga för agila metoder inom offentlig sektor.

1.2 Syfte

Syftet med studien är att beskriva vilka hinder som kan finnas hos myndigheter inom offentlig sektor vid genomförande av systemutvecklingsprojekt med agila metoder. Studien ska bidra med kunskap kring hinder som kan uppstå hos myndigheter vid genomförande av agila metoder och arbetssätt. Vår ambition är att studiens slutsatser skall ge stöd till myndigheter som väljer

3

att införa eller transformera sin organisation mot agila metoder samt ge åtgärder till att bemöta hinder i genomförande av agila metoder.

1.3 Problemformulering

Vilka faktorer hindrar genomförande agila metoder inom myndigheter?

För att kunna besvara ovanstående huvudfråga utgår studien från en underfråga: - Hur arbetar myndigheten idag i förhållande till ramverket SAFe?

2.0 Relaterad forskning

I detta avsnitt presenteras forskning inom områden som för denna studie är relevanta. Dessa områden berör ett helhetsperspektiv över organisationer i förhållande till uppskalning av agila metoder. Syfte är att ge en bild av hur organisationer är strukturerade för att tydliggöra var i organisationen hinder kan uppstå och bör angripas.

2.1 Styrning

Organisationsstyrning innefattar gränserna för beslutagande inom organisationen. Detta genom att definiera vilka processer som ska användas, vilka mål som ska finnas samt definiera kontroll och ägandeskap för olika uppgifter. Syftet med detta är att förhindra konflikter mellan organisationens mål i förhållande till processer och resurser. Konflikter som annars kan skapa inkonsekventa handlingar med negativa effekter på lönsamheten (Müller, 2009). Styrning förhåller sig inte enbart till breda organisatoriska ramar utan innefattar även mindre delar inom organisationen, till exempel projekt (Müller, 2009). Projektstyrning kräver mer samarbete, flexibilitet och organisering för att anpassa projekten till förändring (Lappi & Aaltonen 2017). Denna form av styrning har även en central roll i att säkerställa att projekt realiserar affärsmässiga målbilder i förhållande till den övergripande strategin (Musawir et al., 2019). Implementation av projektstyrning kan ske genom kartläggning av riktlinjer för projekts roller, processer, policys och ansvarsområden (Müller, 2009).

Portfolios är den högsta nivå där organisationens strategi definieras efter förväntning på avkastning eller politiska direktiv. Förändring och inkorporering av nya incitament planeras och verkställs på denna nivå inom organisationer (Moran, 2015). Projektstyrning verkställs inom Project Portfolio Management (PPM) som ansvarar för styrningen av projekt och hanteringen för dess beroenden mellan varandra. Beroenden mellan projekt kan innefatta gemensamma mål, beställare eller resurser. I kontrast till projektledning som handlar om att

4

genomföra projekt på rätt sätt så syftar PPM till att säkerställa att rätt projekt genomförs (Dingsøyr et al., 2014).

Större organisationer måste ofta själva forma sin egna agila struktur eftersom agila metodologier ger få råd för hur agila team ska samverka med övriga organisatoriska delar (Paasivaara et al,. 2018). Generellt är organisationsstruktur och projektstyrning ofta bakomliggande faktorer till att konflikter uppstår med agila systemutvecklingsprojekt inom offentlig sektor (Lappi & Aaltonen, 2017). Traditionella portfolios innehåller projekt som är isolerade från varandra, något som behöver förändras för att anamma agila metoder. Detta för att det inom agila systemutvecklingsprojekt kan tillkomma nya krav som kan påverka andra projekt inom portfolion på grund av den iterativa utvecklingsprocessen (Dingsøyr et al., 2014). Styrning som leder till att projekt får fixerade och detaljspecifika projektplaner har även påvisats hämma värdeskapandet. Detta då osäkerheter som finns inom systemutvecklingsprojekt inte tas i beaktning. Följaktligen har det efterfrågats mer flexibla projektprocesser med samarbete och interaktion i fokus som drar nytta av förändring och möjliggör för beställare att delta aktivt under värdeskapandet.Projektstyrning för agila projekt bör beakta de självstyrande aspekterna inom agila metoder i syfte att skapa flexibilitet och samarbete inom projekt. För att uppnå detta är det nödvändigt med transparens för projekten. Likväl misslyckas ofta myndigheter med att uppnå den transparens som krävs för att främja självstyre på grund av den offentliga sektorns styrning (Lappi & Aaltonen, 2017).

2.2 Large Scale Agile

Organisationer har olika anledningar till varför man vill implementera agila metoder. Paasivaara et al. (2018) hävdar att en anledning är att byråkratiska organisationer ibland har svårigheter med processer och styrning som föreligger projekt. Byråkratiska strukturer ses ofta som problematiska på grund av kostnader som icke värdeskapande aktiviteter, överflödig dokumentation och icke-produktiva möten medför. Effekten av detta blir långsamma flöden med långa cykler vilket medför fördröjningar av såväl produkter som feedback (Paasivaara et al., 2018). Moe et al. (2020) menar att organisationer strävar efter att skala upp agila metoder inom organisationen för uppnå en mer dynamisk interaktion mellan olika enheter. I korrelation menar Luna et al. (2019) att beslutstagande och time-to-market påverkas positivt av en agil omställning. En organisation kan således bli mer konkurrenskraftig genom att anamma agila metoder (Luna et al., 2019).

I små organisationer finns det ett fåtal team som utgörs av ett mindre antal individer vilket är en gynnsamt för agila metoder. Inom större organisationer däremot har agila metoder visat sig vara mer utmanande på grund av komplexiteten som storleken medför. Detta för att samordning och kommunikation mellan utvecklingsteam och övriga organisationen försvåras (Paasivaara et al., 2018). Vidare menar Leffingwell (2007) att uppskalning av agila metoder medför flera svårigheter såsom koordinering mellan flera agila team, avsaknad av initial arkitekturell design, avsaknad av kravanalyser och utmaningar inom spridda systemutvecklingsprojekt i samband med geografiskt spridda organisationer. Paasivaara et. al. (2018) hävdar även att förändringsprocesser för organisationer inte heller är problemfria. Hinder som kan uppstå under

5

en förändring innefattar integreringen av ett agilt arbetssätt inom verksamheten, motstånd till förändring samt förändring av kravtekniker.

Oavsett dessa utmaningar har flera stora organisationer valt att anamma de agila metoderna trots att det finns väldigt lite forskning om hur man ska använda agila metoder i större systemutvecklingsprojekt (Leffingwell, 2007). I större organisationer menar Wright (2014) att systemutvecklingsprojekt med agila utvecklingsteam fungerar som bäst när teamen har fått sätta sin egen prägel på arbetet genom en egen agil kultur. För att få storskaliga agila organisation att fungera behöver utvecklingsteam, förutom ett visst självstyre, ha nära samarbeten och kontakt med personer från övriga delar av organisationen (Dingsøyr et al., 2014).

3.0 Bakgrund till teoretiskt ramverk

I detta avsnitt presenteras agila principer samt Lean. Dessa kan ses som en bakgrunden för studiens teoretiska ramverk och presenteras för att konkretisera kontexten till det.

3.1 Agila manifestet

Det agila konceptet framträdde under sent 90-tal med syftet att adressera problematiken med rådande systemutveckling metoder baserade på sekventiella vattenfallsmodeller. Brister med traditionella metoder blev mer påtagliga i samband med framväxten av ny teknologi och en mer föränderlig marknad (Dingsøyr et al., 2014).

Det agila manifestet innehåller 4 grundvärderingar samt 12 principer som tillsammans beskriver det agila perspektivet.

Individer och interaktioner - framför processer och verktyg Fungerande programvara - framför omfattande dokumentation Kundsamarbete - framför kontraktsförhandling

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

“Det vill säga, medan det finns värde i punkterna till höger, värdesätter vi punkterna till

vänster mer” (Agila manifestet, 2020).

De tolv principerna är följande:

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.

6

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 uthållighet. Sponsorer, utvecklare och användare skall 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 och 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.

(Agila manifestet, 2020).

Att definiera agila metoder är dock problematiskt då uppfattningen från utövare färgas både från angivna principer i manifestet och karaktärsdrag från praktiska erfarenheter. Generellt kan agilt förklaras som ett paradigm kring lösningsfokuserad utveckling som genomsyras av följande element; (1) Berättigande; (2) Värdedriven; (3) Samarbete; (4) Anpassning (Moran, 2014).

Berättigande: Att etablera humanistiska värden som respekt, tillit och mod kräver att teamen

integreras och stöds av en miljö där självorganisering och självstyre uppmuntras. Där den traditionella rollen för ledning ersätts med tjänsteledarskap (Moran, 2014). Tjänsteledarskap innebär att ledaren strävar efter att följare ska bli friare, klokare och mer autonoma (Holtzhausen, 2018).

Värdedriven: Innebär att utvecklingen utgår från affärsnyttan. Detta är något som sker genom

att framsteg mäts genom input från intressenter och de som behöver lösningen på fungerande system snarare än via statusrapporter. Således krävs en regelbunden interaktion mellan utvecklare och intressenter med fokus på lean samt inkrementell leverans av fungerande systemkomponenter (Moran, 2014).

Samarbete: Samarbetande team med bred arbetsförmåga, liknande erfarenheter och kunskaper

är något som den agila disciplin framhåller som viktigt för att uppnå samförstånd kring lösningar. Samarbetet inom denna ram förespråkar att kommunikation sker genom direkta möten (Moran, 2014).

7

förståelse att förändring och eftersökta effekter föregås av risker. En anpassningsbar planeringen innebär att planen uppdateras när nödvändig information blir tillgänglig under utvecklingsprocessen. Detta förutsätter effektiv återkoppling av feedback och retrospektiv (SCRUM) som guidar processen och utvecklingen. Detta kräver ett iterativ och decentraliserat tillvägagångssätt så att utvecklingen kan anpassas utifrån förändringar i vad organisationen behöver (Moran, 2014)

3.2 Lean

Lean har sin härkomst inom bilindustrin, där praktiker och principer tillämpande av Toyota via sitt produktionssystem, Toyota Production System (TPS), kom att forma det som benämns som “lean production”. Ett begrepp som i samband med en 5-årig studie över skillnader mellan biltillverkare i USA och Japan framfördes inom The Machine That changed the world av Womack och Jones (Liker & Ross, 2017). En av de centrala aspekterna inom lean är att eliminera “waste” slöseri. Betydelsen av “waste” innefattar allt som skapar avvikelser från perfekta processer. Något som förtydligas via konceptet “one-piece flow” som illustrerar ett sammanhängande flöde där varje värdeskapande steg i processen utförs perfekt utan några avvikelser (Womack et al., 1990).

Vidare utvecklade Womack & Jones (2003) “Lean Thinking” som introducerade ett nytt sätt att se på hela organisationen. Tankesättet syftar till att möjliggöra för organisationer att specificera värde, organisera värdefulla aktiviteter utefter lämpligaste sekvens, att genomföra aktiviteter utan avvikelser när de efterfrågas och ständigt effektivisera värdeskapande aktiviteter. Inom “Lean Thinking” återges fem vägledande lean koncept:

- Värde: Definieras utifrån kunden, och det är av högsta vikt att erhålla en klar uppfattning om vad det är.

- Värdeström: En karta som innehåller varje steg i processen och där varje steg kategoriseras utifrån det värde det tillför.

- Flöde: Det är viktigt att produktionsprocessen har ett kontinuerligt flöde.

- Dragande: Säkerställa att inget produceras innan en kund efterfrågar produkten.

- Perfektion: Uppnås genom att kontinuerligt identifiera och ta bort slöseri från processen. Med utgångspunkt från tidigare framgångar inom bilindustrin har lean fått momentum även inom systemutveckling vilket kan illustreras via flera verk såsom Software Agility: Best

practises for Large Enterprises Leffingwell (2007), Agile Software Requirements: Lean

Requirements Practices for Teams, Programs, and the Enterprise Leffingwell (2011),

Principles of Product Development Flow Reinertsen (2009) och Lean Software Development: A Tutorial Poppendieck & Cusumano (2012).

3.3 Lean begreppet kopplat till systemutveckling

Det fundamentala principerna för Lean är att öka flexibiliteten, minimera “waste”, fokusera på att skapa värde för kunden, produkten och organisationen. Detta genom att arbeta iterativt under

8

korta processförlopp. Dessa principer återfinns även i agila systemutvecklingsmetoder exempelvis XP och Scrum som kännetecknas av ett iterativt och inkrementellt tillvägagångssätt. Även tillvägagångssättet “dragande” för att inte överproducera återfinns i Scrum (Poppendieck & Cusumano 2012).

Trots stora likheter mellan disciplinerna skiljer de sig i avseende på den organisatoriska anpassningen. Skillnaden är att agila systemutvecklingsmetoder förklarar hur systemutvecklingen ska ske utan att se till den anpassning som krävs för att de agila metoderna ska kunna verka inom hela organisationen (Poppendieck & Cusumano, 2012; Smits, 2007). Lean förklarar hur IT ska sammankopplas till organisationen för att producera värde snarare än att redogöra för hur en utvecklingsprocess ska gå till. I stora drag bör Lean ses som principer för att öka värde och kvalitet inom utvecklingsprocesser. Principerna skapar förutsättningar för att multifunktionella processflöden där design, utveckling, implementation och utvärdering sammanbinds med ett gemensamt syfte av att upptäcka och leverera värde. I korrelation till detta används begreppet “lean development” som ämnar till att implementera agila strukturer inom organisationer. Detta för att göra organisationer mer stabila, motståndskraftiga och mottagliga till förändring (Poppendieck & Cusumano, 2012).

4.0 Teoretiskt Ramverk

I detta avsnitt presenteras teorin som denna studie kommer att utgå ifrån. Teorin kommer att ge det perspektiv utifrån vilket insamlad data analyseras.

4.1 SAFe Bakgrund

SAFe är ett ramverk som återger riktlinjer för hur organisationer kan ta till sig agila metoder över hela organisationen. Dean Leffingwell återger i sina böcker “Agile Software Requirements” och “Scaling Software Agility” delar av detta ramverk som utgår från flera olika agila metoder såsom Lean, Kanban, Scrum och XP. Deras gemensamma principer i kombination med arbetssätt ligger till grund för ramverket och dess processer. SAFe är designat för att öka organisationers agilitet och innehåller verktyg för att på ett regelbundet och effektivt sätt producera värde inom organisationer (Scale Agile INC

4.2 Core Values

SAFe är byggt på fyra grundstenar Lean development, Agile development, System thinking och DevOps. Utifrån dessa grundstenar har fyra kärnvärderingar vuxit fram (Scale Agile INC).

9 Alignment

Visionen för företaget är en beskrivning och tanke om hur organisationen ska se ut i framtiden. Den ska spegla hur beställare och intressenters behov samt hur man ska kunna bemöta dessa (Scale Agile INC).

Strategien är en långsiktig planering som sätts av ledningsgruppen efter kriteriet: “detta är något som är värt att göra”. Den långsiktiga planeringen hjälper de agila teamen att vara bättre informerade om hur de bör agera kring funktioner, både långsiktigt och kortsiktigt. Strategin ska dock inte möjliggöra toppstyrning och en kontrollerande miljö utan istället att få organisationen att gå samma riktning och sträva mot gemensamma mål (Scale Agile INC). Built in Quality

Varje del och inkrement av det som produceras ska återspegla de krav på kvalite som finns. Att producera med kvalite är en nödvändig förutsättning för Lean och flödet, utan det så är det högst troligt att det kommer produceras stora leveranser som inte är ordentligt testade eller godkända. Kvalite är inte något som man kan bygga in senare utan kvalitetstänket ska var med under hela processen (Scale Agile INC).

Transparency

Att arbeta lösningsorienterat kan vara svårt. Saker blir fel och misstag sker, för att kunna åtgärda dessa samt ta välgrundade beslut krävs en öppenhet. Ifall det saknas information vid beslutsfattande är sannolikheten större att man tar fel beslut och baserar dem på spekulationer. För att uppnå en öppenhet krävs tillit, något som infinner sig när organisationens enheter kan lita på att alla enheter agerar med integritet. Vad som möjliggör tillit och således en öppenhet inom organisationen är transparens (Scale Agile INC). Program execution

Historiskt sett är det vanligt att företag börjar sin agila transformation med individuella agila team. Ofta leder detta dock till en frustration för att man inte kan uppnå den leverans av värde, pålitlighet och effektivitet som önskas (Scale Agile INC).

För att motverka det använder SAFe Agile Release Trains (ART). Programmen drivs framåt av ART. Dessa består av flera synkroniserade agila team som under en begränsad tidsperiod (60-120 dagar) arbetar tillsammans för att skapa värde. Funktionerna (som är hämtade från Epics) läggs in som program och prioriteras i en gemensam backlog. Dessa delas sedan in i user stories och prioriteras i systemutvecklingsteamens backlog. De olika teamen får på detta vis olika ansvarsområden. Leffingwell (2011) benämner detta fenomen som “uber-sprint” då det i flera avseenden påminner om en stor sprint. Det är deras gemensamma levererade värde som synkroniseras och levereras tillsammans för att uppnå programmets

10

funktioner. När ett program är avslutat tar man ett nytt ur den gemensamma backloggen. Mycket likt en sprint där man istället påbörjar en ny User story efter att en tidigare avklarats (Scale Agile INC).

4.3 SAFe principer

Safe är byggt på 10 fundamentala principer som har tagits fram utifrån agila metoder och principer, Lean produktion och observation av framgångsrika företag (Scale Agile INC). #1 Take an economic view

För att kunna leverera maximalt värde på kortast möjliga tid kräver det att man har förståelse för ekonomin. Ekonomifaktorn måste tas med i alla beslut från portfolio- till team-nivå. Alla värdeströmmar måste arbeta inom det utrymme som ges i budgeten men organisationen måste också ha ett ekonomiskt ramverk som stödjer decentraliserad kontroll (Scale Agile INC). #2 Apply system thinking

Det är av högsta vikt att utvecklingsteam förstår kontexten för systemen de utvecklar. System är komplexa och består ofta av flera komponenter och avdelningar. Att optimera en komponent bidrar inte alltid till förbättring av systemets helhet. Organisationen måste även skapa den miljö som krävs för att samarbetet mellan olika enheter kan ske dynamiskt (Scale Agile INC). #3 Assume variability; Preserve options

Vid vattenfalls metoder väljs ett design- och funktions-alternativ tidigt i utvecklingsprocessen. Ifall det sedan tillkommer förändringar och det visar sig att man tagit fel beslut tar det lång tid korrigera dessa. Ett bättre alternativ är att behålla flera olika alternativ under utvecklingsperioden. Ifall det uppstår förändringar i önskemål är dessa lättare att bemöta för att man från början av utvecklingsprocessen definierat olika alternativa lösningar för systemet. Detta ska slutligen resultera i ett alternativ som ger optimerad ekonomisk vinning (Scale Agile INC).

#4 Build with fast, integrated learning cycles

Utveckling av inkrementella delar i korta iterationer möjliggör snabb feedback från beställaren och minskar risken. Kommande inkrement bygger på de tidigare. På grund av att systemet alltid kör så kan vissa inkrement fungera som prototyper för testning, godkännande och vissa blir mindre genomförbara produkter. Andra inkrement bidrar med nya och värdefulla funktioner. Den snabba feedbacken man får hjälper till att bestämma och navigera utvecklingsprocessen (Scale Agile INC).

11

#5 Base milestone on objective evolution of working systems

Projektägare, utvecklare och beställare har tillsammans ett ansvar för att säkerhetsställa att investeringar i nya lösningar är bidragande till ekonomisk vinning. Här bygger man vidare på princip #4 med att arbeta i iterationer och leverera i inkrement. Istället för att investeringarna ska ge en stor big bang effekt i slutet så ska de snabbt generera värde. Detta möjliggör att man kan utvärdera och styra från faktorer som ekonomiska, tekniska och upplevd nytta. Detta gör det enklare går att säkerhetsställa att fortsatt investering kommer resultera i förväntad avkastning (Scale Agile INC).

#6 Visualise WIP, reduce batch sizes and queue lengths

Det är viktigt att man inte har mer arbete än vad systemet klarar av igång. Det leder till svåra prioriteringar, ökade väntetider på ny funktionalitet, överberbelastar arbetare och minskar produktionen. Fenomenet kan liknas vid en bilkö. Det är viktigt att allt aktuellt arbete är visuellt för alla intressenter. Detta kan göras via en kanban board. Att minimera batcherna kan liknas med att leverera i inkrement. Ifall inkrementen är större så blir också kostnaden för att hålla kvar dem innan leverans större. För att korta ner väntetiden så kan man även korta ner köerna. Ifall köerna är långa och fasta så är det svårt att prioritera om ifall det kommer något som ger högre värde (Scale Agile INC).

#7 Apply cadence, synchronize with cross-domain planning

Kadens bidrar med en säkrare förutsägbarhet samt en rytm för utvecklingen. Synkroniseringen bidrar med flera faktorer som förståelse, lösningar och integrering. Att implementera en kadens ihop med synkronisering och en planering som sträcker sig över flera komponenter hjälper till att att skapa de mekanismer som behövs för att effektivisera de osäkra faktorerna inom utvecklingen (Scale Agile INC).

#8 Unlock the intrinstic motivation of knowledge workers

Lean-agila ledare förstår att anställda inte bara motiveras av lön utan också av syfte, tillit och frihet att kunna lösa problem. Ett faktum är att anställda ofta kan mer om det tekniska arbetet än ledarna. Det är därför ineffektivt att inte låta de anställda ta dessa beslut. Ledarna ska istället bidra med att klargöra syftet, se till att arbetet går i rätt riktning tillsammans med strategin och hålla arbetarnas motivation uppe (Scale Agile INC).

#9 Decentralised decision making

När en organisation effektiviseras krävs det också att beslutsfattandet effektiviseras. Det är inte praktiskt att ett besluts ska gå upp och ner i beslutsordningen. Fördröjningar vid beslut leder till långsam respons samt att beslutet minskar i validitet på grund av att omständigheterna kan

12

förändras under väntetiden. Teamen måste därför ges möjlighet med att fatta beslut och kunna agera snabbt. Denna risk är liten på grund av att med snabb feedback kan även dåliga beslut korrigeras snabbt (Leffingwell, 2011). Det finns dock beslut som behöver tas centralt, sådana kan vara strategiska, globala eller av stor ekonomisk omfattning. På grund av att det finns olika typer av behov vid olika typer av beslut behövs ett ramverk för hur beslut ska fattas (Scale Agile INC).

#10 Organize around value

Flera företag idag är organiserade kring gamla principer. Den digitala revolutionen har lett till att förutsättningarna idag är annorlunda. Det är kritiskt hur fort företaget kan bemöta kraven från en kund genom innovativa lösningar. Detta kräver samarbete mellan alla funktionella avdelningar, minimering av onödigt arbete och väntetid samt minskad kontroll från övre leden. Agilitet kräver att företag organiserar sig kring värdeskapande och att leverera snabbare. När marknaden och kundens krav förändras måste organisationen snabbt och utan hinder kunna omorganisera sig till det nya värdeflödet (Scale Agile INC).

4.4 Teoretisk avgränsning

På grund av SAFe ramverkets omfattning har vi valt att avgränsa oss till användning av ett begränsat antal core values och principer. Motivering till detta beslut ligger i att bättre och mer utförligt kunna besvara frågeställningen som studien undersöker. Core values som studien utgår ifrån är Alignment och Transparency, de principer som studien kommer utgå ifrån är #2, #6, #7, #8 och #9.

5.0 Metod

I detta avsnitt presenteras forskningsmetoden för denna studie. Studien har genomförts med ett deduktivt tillvägagångssätt, det vill säga att en teori ligger till grund för urvalet av empiri.

Denna studie har bedrivits genom en fallstudie i syfte av att undersöka agila metoder på en myndighet. För detta valdes en metodsats med utgångspunkt i kvalitativ metod. Detta eftersom kvalitativa metoder enligt Oates (2006) lämpar sig bra för fallstudier. En ytterligare motivering var att bakomliggande forskning för denna studie påvisade att fler fallstudier av detta slag var önskvärt.

För att samla empiri för studien gjordes en litteraturundersökning samt ett antal intervjuer med personer från en myndighet. Enligt Oates (2006) är intervjuer en bra metod att använda vid ansamling av detaljerad information och då man utforskar ett område där det kan finns känslig information. Således bedömdes valet tydligt motiverat eftersom detta även var fallet för denna studie. Eftersom teorin från början var bestämd valdes en deduktiv strategi för analys av

13

insamlad data, vilket innebär att man utgår från en teori vid insamling och analysering av data (Oates, 2006).

5.1 Fallstudie

Vid starten av studien togs det ett beslut om att det skulle genomföras en fallstudie för att samla in data. Ett par olika verksamheter kontaktades och valet föll tillslut på en myndighet som visade god samarbetsvilja till att genomföra undersökningen. Samtidigt som det fanns en önskan att hos myndigheten komma underfund med befintligt gnissel som de inom sina processer identifierat.

Den valda myndigheten har påbörjat sin agila förändringsresa inom IT-avdelningen och har idag inte fattat något beslut om att implementera arbetssättet inom övriga delar av organisationen. Det har resulterat i att IT-avdelningen och verksamheten arbetar med olika metoder för gemensamt arbete under exempelvis systemutvecklingsprojekt. Detta är något som myndigheten bedömde kunde orsaka “gnissel” bl.a. mellan verksamheten och IT-avdelningen. Respondenterna valdes ut tillsammans med vår handledare hos myndigheten med motivering att de på något sätt har inblick i det agila arbetet. Ett av kriterierna var att de skulle komma från olika delar av myndigheten på grund av att det ansågs av stor vikt att data som samlades in kunde delge flera olika perspektiv. Således valdes 13 olika personer ut som respondenter fördelat på fem olika avdelningar. Avdelningarna valdes på grund av att de ansågs vara centrala för att kunna ge en korrekt bild av hur det agila arbetet ser ut. Avdelningarna som valdes inkluderade IT (Systemutvecklingsprojekt och förvaltning), Portfolio, Styrgrupp, Process och Metodutveckling (PMU) samt Produktion (verksamheten).

Rollerna för respondenterna inom dessa avdelningar innefattade följande: enhetschefer, produktägare, förvaltningsledare, projektledare, verksamhetsutvecklare, avdelningschefer, processägare, systemutvecklare och scrum master.

5.2 Litteratursökning

Ett inledande kriterium vid litteratursökningen var att artiklarna skulle vara peer-reviewed eftersom detta ger mer lämpligt och kvalitativt innehållet (Bryman & Bell, 2017). Litteratursökningen grundar sig i komponenterna databassökning, nyckelord, granskning av rubriker och abstrakt. Databaserna som använts är följande: ACM Digital Library, IEEE Xplore, Emeral insight, Sage Journals, SpringerLink och Science Direct.

I sökandet efter vetenskapliga artiklar gjordes blocksökningar för att få mer distinkta resultat. Dessa utformades av sökord baserade på studiens syfte och frågeställning. För att bredda urvalet ytterligare gjordes även sökningar på synonymer och relaterade termer till de ursprungliga orden. Något som Oates (2006) menar är ett bra sätt att maximera antalet sökträffar. De söktermer som användes i databaserna samt resultat för sökningar redovisas i bilaga 1.

14

Ett ytterligare kriterium som ställdes på använda artiklar var att källan och abstrakten skulle innehålla de nyckelord som valts ut. Detta för att de sökta termerna skulle vara centrala i artiklarnas innehåll.

5.3 Intervju

Samtliga intervjuer utfördes semistrukturerade. Denna form uppfattades som mest lämpad för situationen på grund av att studien krävde viss kontroll från intervjuaren och då fokus låg på vissa specifika frågor. Eftersom respondenterna som deltog kom från flera olika avdelningar inom myndigheten var det även högst relevant att justera och förändra frågorna. Oates (2006) menar att semistrukturerade intervjuer är att föredra när man vill undersöka något mer djupgående och då man behöver styra frågorna utefter vad respondenterna säger.

5.3.1 Intervjuguide

De personer inom myndigheten som ställde upp på att intervjuas fick en vecka i förväg ett frågeformulär med de teman och frågor som skulle tas upp (bilaga 2). Tanken med detta var att förbereda personerna och ge dessa möjlighet att fundera och reflektera. Frågorna för intervjun utformades överskådligt då respondenterna kom från olika avdelningar inom myndigheten. Intervjuerna inleddes med en bakgrundsfråga om respondentens roll i myndigheten. Hjerm et al. (2014) menar att bakgrundsfrågor är viktiga för att “värma upp” respondenten. Övriga frågor var utformade och placerade i en strukturerad ordning utifrån utvalda teman.

För att tydliggöra koppling mellan intervjufrågorna och utvalda teman från teorin gjordes en tabell (se Tabell 1 under avsnitt 5.4). Tabellen illustrerar operationaliseringen av utvalda teman till de frågor som användes under intervjuerna.

För att intervjuerna skulle ge oss tydlig och tillräcklig data användes en teknik som Oates (2006) kallar för nudging. Detta används ifall det behövs ett tydligare svar på en fråga eller ifall respondenten behöver en knuff för att svara mer djupgående. Det finns olika typer av nudging och för denna studie användes:

Prompts: Syftar till att respondenten ska utveckla sitt svar. Antingen kan detta göras genom att repetera frågan eller genom tystnad och låta respondenten fylla tystnaden.

Probes: Syftar till att respondenten ska gå in mer i detalj på vad den pratar om. Vanligt att man ber respondenten ge exempel eller fråga efter detaljer.

Checks: Dubbelkollar att intervjuaren har förstått respondenten korrekt. (Oates, 2006).

Utöver nudging användes även följdfrågor med förhoppningen att komma djupare i förståelsen av data. Ett exempel på följdfråga kan vara orsaksfaktorer som respondenter tror ligger bakom ett visst fenomen.

15

5.4 Analysmetod

Analysen för denna studie genomfördes med teoristyrd tematisk analys där förutbestämda teman framtagna ur det teoretiska ramverket styrde nedbrytningen och identifieringen av relevant empiri. Som förutsättning för denna analysmetod sammanställdes genomförda intervjuer i dokument där centrala delar för varje intervju skrevs ner. Således gjordes ingen ordagrann transkribering av inspelade intervjuer. Motiveringen till detta beslut var att en transkriberingsprocess ansågs bli onödigt detaljerad och tidskrävande. Hjerm et al. (2014) menar att återskapandet av detaljerad data till text ofta leder till att kontext- och miljöfaktorer försvinner. Samtidigt finns det även en risk att man låser sig kring icke väsentliga element.

Tabell 1. Tabellen visar de teman som studien har utgått ifrån, beskrivning av temat, koppling till de teoretiska ramverket samt vilka frågor som har använts för att undersöka temat.

Tema Motivering Teoretisk koppling Intervjufrågor Gemensam vision för

arbetssättet Innefattar huruvida myndigheten har en gemensam vision för arbetssättet. Det undersöks även hur myndigheten säkerhetsställt kompetens, på grund av att det är en viktig faktor för att den gemensamma visionen ska förstås. 3.2 Core value: Alignment, 3.3 #2 Apply system thinking.

Anser du att myndigheten säkerställer att det finns agil kompetens i verksamheten. På vilket sätt får utbildas ni?

Anser du att ni arbetar agilt i er organisation? - På vilket sätt? eller Varför gör ni inte

det?

Hur ofta reflekteras det över arbetssätten i relation systemutvecklingsprojekt? Bra/dåligt? Feedback?

Har det skett några förändringar inom

organisationen och/ eller inom organisatoriska processer på grund av introduktionen av agilt arbete?

Transparens och

kommunikation Under detta tema undersöks tillgången till information i organisationen samt kommunikationen mellan IT och verksamhet. 3.2 Core value: Transparency 3.3 #2 Apply system thinking. 3.3 #7 Apply cadence, synchronize with cross-domain planning 3.3 #6 Visualize and limit WIP, reduce batch sizes, and manage queue lengths

Har ni en tydlig kommunikationsplan för projekt?

Hur går dialogen mellan utvecklings teamen och verksamheten till?

Hur tas intressenternas och beställarens krav mot? Har ni ett speciellt arbetssätt för det? Hur återkopplas kraven (uppföljning)? Hur sker överlämningen av resultatet? Är rollen som beställare tydligt definierad?

- Följer den upp kvalite? Kostnad?Tidsram?

16

Hur ser dokumentation ut inom systemutvecklingsprojekt?

Anser du att system från IT möter de förväntade kraven från beställare?

- Vilka brister finns i de system som levererats av IT-avdelningen? - Vad kan dessa brister beror på? - Hur tar ni reda på beställarens

synpunkter av leveransen?

Hur mäter ni framsteg inom systemutvecklingen? - Vilka kriterier har ni för att sätta upp

mål?

- Upplevd nytta/effekt eller tid samt kostnad?

Decentraliserat

beslutsfattande Detta tema undersöker hur de som arbetar på lägre nivåer kan ta beslut på eget initiativ. Vilka möjligheter de har samt ifall det finns en tillit till medarbetarna på högre nivåer. 3.2 Core values, Alignment, Transparency, 3.3 #9 Decentralised decision making, #8 Unlock the intrinstic motivation of knowledge workers

Hur tar de agila teamen ansvar för problem som uppstår utan att lyfta frågan till ytterst ansvariga?

- Har de möjlighet att ta beslut? - Vilka rutiner finns?

Har ni en tydlig beslutsordningen vid

utvecklingsprojekt samt förvaltnings arbeten? - Hur ser den ut?

Vilka begränsningar finns för utvecklings teamen vid beslutsfattande?

Hur hanteras konflikter som kan uppstå mellan olika intressenter inom organisationen?

5.4.1 Analys av intervjuer

Intervjudokumenten som skapades analyserades genom en teoristyrd tematisk analys. Denna process påbörjades med att identifiera segment av data i dokumenten som vi uppfattade som relevanta för de teman som tagits fram. Syftet med denna process var att sortera insamlad empiri till respektive tema. Ansamlingen av relevant data nådde slutligen en viss mättnad. Hjerm et al. (2014) beskriver begreppet mättnad som det stadiet då man inte längre kan urskilja ny relevant data ur empirin. Den ovan förklarade processen kallar Hjerm et al. (2014) för begreppsdriven eller tematisk kodning och innebär alltså att man i stora drag är medveten om vad det är man söker, vilket i vårt fall var data som svarade till studiens teman. Tematisk kodning kan även innebära att man bortser från viss data som inte är relevant (Hjerm et al., 2014), vilket även var fallet i denna studie om data inte kunde sorteras under utvalda teman.

17

Tabell 2. Tabellen visar hur analysmetoden har genomförts i kronologisk ordning.

1. Teori Studiens teoretiska ramverk är SAFe.

2. Teman Gemensam vision för arbetsätt, Transparens & Kommunikation och Decentraliserat beslutsfattande.

3. Intervjufrågor Operationalisering av utvalda teman till intervjufrågor, (Bilaga 2), (Tabell avsnitt 5.4).

4. Empiri Videoinspelningar av intervjuer samt intervju dokumentation. 5. Segment Sammanställning av empirisk data som är relevant i förhållande

till utvalda teman.

6. Analys Segment av empirisk data analyserades utifrån utvalda teman som utgår ifrån teorin.

Figur 1. Flödeskarta över studiens analysmetod (Egen bild.)

5.5 Metodkritik

Inom den kvalitativa forskningen utpekas ibland forskarnas förförståelse och kulturella kompetens som faktorer som kan påverka hur forskningen utformas (Hjerm et al., 2014). Det är därav viktigt att objektivitet och kritisk reflektion genomsyrar analysen. Till detta påpekar Oates (2006) att den kvalitativa forskningen ofta bemöts kritiskt då det ställs höga krav på forskare kring just dessa objektivitet och kritisk förmåga. Denna problematik har i studien arbetats med genom att data har analyserats av minst två personer åt gången. Detta för att komplettera varandra och hålla analysen på en objektiv nivå.

Kritik mot fallstudier belyser bland annat att de resultat som uppstår ofta bara går att koppla till ett specifikt fall av en företeelse. Oates (2006) menar därför att det är viktigt att ge en bred

18

förståelse och generalisering kring det specifika fallet och vilken kunskapsutveckling studien ska åstadkomma. Emellertid hävdar Oates (2006) att slutssatser som görs trots allt ofta är applicerbara inom flera områden. För att möta denna tvetydighet har studien förklarat några av de egenheter inom det studerade fallet, såsom att det rör sig om en svensk myndighet som infört agila metoder på IT-avdelningen. Vi anser därav att denna studiens slutsatser skulle kunna vara relevanta och bidra med kunskap vid liknande fallstudier.

Hjerm et al. (2014) menar att även om intervjuerna följer en struktur kommer varje intervju bli unik. Det är därav viktigt att personen som håller i intervjun kan anpassa sig utefter situation och improvisera. Då respondenterna för denna studie kom från flera olika avdelningar inom myndigheten var detta något som togs i beaktning. Eftersom vissa av frågorna var mer eller mindre relevanta beroende på vem personen var.

En annan aspekt som bör tas i beaktning vid intervjuer är enligt Oates (2006) kontinuitet och objektivitet vilket kan påverkas både av kontexten och av forskaren. Denna problematik hanterades genom en tydlig presentation av vår roll som objektiva undersökare samt att avgränsa intervjuerna till de teman som de var tänkta att utgå ifrån.

5.6 Etik

På grund av rådande pandemi och för att alla inblandade skulle känna sig trygga genomfördes intervjuerna via Skype. Hjerm et al. (2014) menar att osäkerheter kring syftet med forskningens kan ha negativ inverkan på deltagande respondenter. Detta är något som i studien genomgående har arbetats mot. Inför intervjuerna fick samtliga respondenter en inbjudan med bifogat frågeformulär för att de skulle förstå kontexten för intervjun. Under intervjuerna presenterades återigen syftet och bakgrunden till studien. Det framgick att inga värderingar av rådande läge på myndigheten skulle göras och ett neutralt tonläge eftersträvades. Den data som insamlats gjordes också i största möjliga mån anonym för att respondenterna skulle känna sig trygga med att tala fritt kring ämnet. Samt för att följa de rekommendationer som finns från Örebro Universitet gällande GDPR (Örebro Universitet, 2020) Intervjuerna spelas in för att kunna analyseras i efterhand.

5.6.1 GDPR

Alla personuppgifter som samlats in under studien behandlar GDPR (Dataskyddsförordningen) i enlighet med Örebro Universitets Dataskyddspolicy (Örebro, universitet, 2020). Inga uppgifter angående respondenterna såsom personnummer, adress, telefonnummer, email eller namn sparades. Under studiens aktiva tid sparas intervjuerna i form av ljudfilsformat men det är anonymiserade på ett sätt så inga personuppgifter kopplade till respondenten kan identifieras.

19

6.0 Resultat & Analys

Detta kapitel kommer ta upp samt analysera det resultat som studien har samlat in genom intervjuer. Resultaten utgår ifrån de tre huvudteman (Gemensam vision för arbetssättet, Transparens, Decentraliserat beslutsfattande) som har tagits ut vid den tematiska analysen. Under dessa kommer de kategorier som identifierats i empirin och kopplats till respektive huvudtema att presenteras. Resultaten kommer presenteras med en inledande sammanfattning för att sedan underbyggas med utdrag från respondenternas svar.

Respondenterna kommer att benämnas med “R + en siffra” de tilldelats (Ex R:1). Siffran har tilldelats utan någon korrelation till intervjuordningen. Ifall Intervjuaren benämns kommer den att benämnas som I. Intervjufrågorna som presenteras ställdes inte på samma sätt till alla respondenter men det huvudsakliga syftet med frågan har tagits in varje gång.

6.1 Gemensam vision för arbetssättet

En stor majoritet av respondenterna anser inte att myndigheten arbetar agilt. 11 av 13 respondenter tycker inte att myndigheten arbetar agilt. Flera av respondenterna uttryckte att IT-avdelningen är agil, åtminstone till viss eller stor del. Två av respondenterna gav inget tydligt svar på denna fråga. I frågan gällande respondenternas uppfattning kring om myndigheten är agil eller inte framgick det att även att IT-avdelningen har förstått konceptet av agilt arbete bättre och att det egentligen endast har anammats inom IT-avdelningen, dock inte fullt ut.

Inget som har implementerats brett utan verksamheten har fått anpassa sig efter att IT har arbetat agilt.

(R:12)

Till de respondenter som besvarade frågan med att endast IT-avdelningen arbetar agilt ställdes en följdfråga om de hade någon personlig uppfattning varför inte verksamheten arbetar på detta sätt.

Man har inte sagt att man ska arbeta agilt på verksamheten, man har inte kunskap om vad agilt innebär och man har inte heller gjort de organisatoriska förändringar som man behöver göra för att arbeta agilt.

(R:8) Har med historiken att göra, mycket tradition och man har arbetat på ett visst sätt under en lång tid. Att tänka på de här med att arbeta agilt har man inte lyckats ta till sig. Man ser inte nyttan med det. Att det stör och att det är något nytt.

20

Respondenternas svar indikerar på att bristande kunskap resulterat i ett tillstånd där verksamheten inte förstår incitamentet bakom att arbeta med agila metoder. Respondent 8 nämner även att de inte har fått förutsättningar i form av de organisatoriska förändringar som krävs för att kunna arbeta agilt. SAFe hävdar att det krävs organisatoriska förändringar för att kunna ge möjligheten till att arbeta agilt. Det framgår i SAFe att användning av ett Lean-agilt arbetssätt utan att anpassa den traditionella styrningen är en vanlig fallgrop (Scaled Agile INC, 2019).

Utifrån uppfattningen om att det inte finns organisatoriska förutsättningar för agilt arbete på hela myndigheten ställdes en följdfråga. Frågan ställdes för att att klargöra respondenternas åsikter om interaktionen mellan IT-avdelningen och verksamheten.

Nu är det så att ni jobbar med timmar och vi jobbar med något helt annat. Då blir det lätt att raljera över att ni är lite gammaldags och ni räknar i pingviner man är lite nedlåtande från båda hållen. Man möts liksom inte där. Det finns ingen förståelse för att man vet inte.

(R:13)

Flera respondenter uttryckte även att de tycker att det blir en form av krock mellan IT-avdelningen och verksamheten samt att parterna kan ha svårt att förstå varandra. Enligt SAFe framgår det att en förbättring av endast en avdelning inte leder till att värde genereras. Istället krävs det att hela organisationen tillsammans genomgår och förstår förändringen (Scaled Agile INC, 2019).

Ur empirin kan vi utläsa att det inte finns någon tydlig gemensam vision för vilket arbetssätt myndigheten ska ha. Myndigheten har inte uttalat ett mål eller en strategi för att arbeta med agila metoder. IT-avdelningen har infört agila metoder på egen hand utan verksamheten vilket har lett till att verksamheten snarare har anpassat sitt arbete till IT-avdelningen än att själva transformeras mot det agila. Detta kan ligga till grund för den bristande förståelsen mellan IT-avdelningen och verksamheten som identifierats. Enligt SAFe är det viktigt att ha en tydlig gemensam vision för att organisationen ska förstå syftet med förändringar, skapa motivation till fortsatt förändring och ger det stöd organisationen behöver för att samarbeta. Ifall det finns en tydlig vision underlättar de för anställda att förstå hur de ska agera samt koordinera sina handlingar utefter mål och strategi för förändringen (Scaled Agile INC, 2019).

6.1.2 Säkerhetsställa kompetens

Det blir tydligt av svaren att respondenterna inte anser att myndigheten har säkerhetsställt att det finns agil kompetens inom organisationen. 8 av 13 anser inte att myndigheten har säkerhetsställt att det finns agil kompetens inom organisationen. 4 respondenter gav otydliga svar medan 1 respondent var positiv och menade att de fått en bra utbildningen men syftade då enbart till IT-avdelningen. Verksamheten hade inte fått ta del av utbildning i samma grad.

21

Det har varit en jättelång inkörningsperiod och jättesvårt att förstå hur det agila arbetssättet ska fungera. Ni har ju en fråga senare som handlar om utbildning och det har vi ju inte haft överhuvudtaget och de rollerna som finns inom det agila har varit en läroprocess och den är väl fortfarande inte helt tydlig skulle jag säga. Väldigt olika inom avdelningen hur de har anpassat sig till de agila sättet att arbeta.

(R:12)

Som följdfråga fick respondenterna svara på om de ansåg att verksamheten borde ha utbildats agilt.

Skulle ha gjort det direkt när vi införde. Pratat mer öppet om vad det innebär att arbeta i ett agilt arbetssätt då skulle man kunna undvikit en del friktion. Vi på verksamhetssidan var inte riktigt med på noterna utan trodde att vi skulle kunna arbeta som precis som tidigare med krav och sådär.

(R:12)

Den agila metoden infördes på IT-avdelningen utan att verksamheten var med på förändringen som gjordes. Den agila kunskapen som återfinns inom verksamheten har inte utbildats utan varit mer av en löpande läroprocess menar respondent 12. Friktionen mellan IT-avdelningen och verksamheten skulle kunnat bli mindre ifall man vid införandet talat mer öppet och förklarat vad det innebär att arbeta agilt. Det framgår även i SAFe att ifall inte alla inom organisationen förstår förändringen ökar motståndet till denna vilket skapar förvirring bland medarbetarna (Scaled Agile INC, 2019).

Saknas förutsättningar men saknas framförallt kunskap om hur, som är en förutsättning, i kunskap ligger förståelsen för vad agilt är, varför man ska arbeta så och hur man gör det rent praktiskt.

(R:8) Nej det skulle jag inte säga. Känns som de tror att det är något som bara finns på IT, det finns en enorm utvecklingspotential inte bara för systemutvecklingsarbetet men också för alla andra avdelningar. [...] Vi har till exempel inga agila coacher som är anställda hos oss, finns ett fåtal som har gått scrummasterutbildningar och produktägarutbildningar (R:8)

Respondent 8 menar att verksamheten saknar de kunskapsmässiga förutsättningarna för att arbeta agilt. Respondenten trycker även på att myndigheten inte har säkerhetsställt att den agila kunskapen finns inom myndigheten genom agila coacher eller utbildningar. SAFe förespråkar att utbildningen ska göras genom att utbilda “förändringsagenter” som sedan vidare kan sprida sin kunskap till ledare, team och andra intressenter som är nödvändiga för att genomföra förändringen (Scaled Agile INC, 2019)

22

Inte riktigt, vi på IT har jobbat med att skapa förutsättningar för oss själva. Har även försökt hjälpa till för att skapa förutsättningar med att erbjuda utbildningar för PO och olika roller från verksamhetssidan så att man är medveten om att det kräver ett samspel men det har inte riktigt nått hela vägen fram.

(R:7)

R7 nämner att IT avdelningen har gjort försök till att erbjuda utbildningar till verksamheten för att belysa att det krävs ett samspel mellan de olika avdelningarna. Detta var dock flera år sedan och har enligt respondenten själv “nog glömts bort”.

Ur intervjuerna kan det utläsas att det har förekommit vissa mindre utbildningar framförallt riktat till Scrummaster och Produktägare men inget som sträcker sig bredare över myndigheten. På verksamhetssidan har det varit en läroprocess för att anpassa sig till den agila IT-avdelningen. Det har inte förekommit några breda försök till att säkerhetsställa att det finns agil kompetens och förståelse. De försök som har gjorts till att utbilda verksamhetssidan har varit små och bundna till personliga initiativ. Dessa har också gjorts för länge sedan och i empirin kan det utläsas att de inte har gett något större värde. Enligt SAFe är det vid införandet av ett nytt arbetssätt av stor vikt att alla förstår syftet och anledningen till varför man gör förändringen. Ifall inte alla förstår dessa faktorer är risken till att motståndet mot förändring ökar. Detta är ett hinder som återkommande lyfts fram när vi talat med olika respondenter, framförallt på verksamhetssidan. Utbildningen är också en viktig faktor till att kunna skapa det kraftfulla block av personer som tillsammans driver förändringen framåt (Scaled Agile INC, 2019).

6.2 Transparens

Intervjuerna fastställde att det inom myndigheten finns olika uppfattningar om hur transparent myndigheten är. Det framgick att framförallt ett systemutvecklingsprojekt och en avdelning har lyckats bättre och är mer transparenta än andra inom myndigheten.

Respondenterna tillfrågades hur dialogen går till samt hur man delar information mellan varandra.

Naturligtvis med rättigheter. Jag tycker inte att allt ska vara öppet och alla ska se allt, men här är det verkligen på en otroligt detaljerad nivå till exempel på en otroligt avsmalnande nivå. Till exempel på rapportering till PSG där har vi statusrapporter vi skriver i word, bara det, sen sammanställer vi det och skriver in det i detta verktyget pluss att gör vi det i excel. och den här excelfil läggs på en area för att vi ska veta vad vi har lämnat ifrån oss. Sen filtreras den ett varv och hamnar på nästa yta, där man på nästa nivå kommer överens om att det är detta vi kan rapportera in till PSG sen flyttar man över den till ytterligare en yta med ytterligare behörighetsstruktur så att PSG kan få tag på den. Så

23

de finns liksom filter på filter. Och detta var ett exempel. Transparensen blir noll i det här.

(R:13)

Respondent 13 menar att det finns en grundlagd misstro, att transparensen är obefintlig och att det finns flera exempel som tyder på detta. I SAFe poängteras vikten av att det finns transparens, som annars kan orsaka sämre beslut och mindre tillit inom organisationen.

Jag tycker att man i styrgruppen varit väldigt utlämnad till det projektledaren väljer att förmedla och det tycker jag blir en trång kanal eller vad man ska säga, att allting kanaliseras via projektledaren och sen ut så till styrgruppen. Jag tror inte man får tillräcklig överblick för att fatta beslut i många fall som styrgrupp.

(R:9)

Respondenternas svar indikerar på att transparensen inom myndigheten är bristande. Inom systemutvecklingsprojekt ansvarar projektledaren för att förmedla information till styrgruppen. Detta skapar ett starkt beroende till projektledaren utan att styrgruppen har en bredare insyn i projektet. Det har även framgått exempel på processer där information behöver lämnas till olika ytor istället för att den är fritt tillgängligt för flera olika nivåer, något som tyder på bristande transparens.

SAFe förespråkar att transparens ska finnas mellan olika delar av organisationen. Detta innebär att nya initiativ, pågående arbete och beslut eller prioriteringar som genomförs av team, styrgrupper och portfolios är tillgängliga för anställda. I förhållande till exemplena gällande statusrapporter av pågående arbete kan det alltså konstateras brister i transparensen gentemot vad som förespråkas av SAFe. Genom att synliggöra information inom organisationen kan positiva effekter uppnås. Exempelvis ökar chansen att det som teamens producerar ligger i linje med strategin. Detta är något som i mer detalj framgår under princip #6 “Visualize and limit WIP, reduce batch sizes, and manage queue lengths” där en hög transparens är en förutsättning för att förebygga flaskhalsar under systemutvecklingen och främja ett kontinuerligt flöde (Scaled Agile INC 2019).

6.2.1 Kommunikation mellan IT och verksamhet

Under intervjuerna ställdes frågor kring kommunikationen mellan IT-avdelningen och verksamhet men även kring kommunikationen mellan olika systemutvecklingsprojekt och team. Resultatet visade att en stor majoritet tycker att kommunikationen mellan IT-avdelningen och verksamheten behöver förbättras. Två respondenter hävdade dock att de tycker kommunikationen fungerar väldigt bra inom de systemutvecklingsprojekt som de arbetar inom men att det inte var lika väl fungerande i andra systemutvecklingsprojekt inom myndigheten. Dessa två respondenter hänvisar till samma systemutvecklingsprojekt.

Att få till den där kommunikationen från det som görs i utvecklingen till de som ska använda det. Det där är ju en bra sak att jobba med och jag

24

är inte säker att vi lyckas alla gånger för överraskningar ska ju inte uppstå när man börjar rulla ut för implementering, helst ska man ju ha demat innan.

(R:4)

Respondent 4 nämner att kommunikationen är oerhört viktig för att systemutvecklingen ska fungera och för att man ska nå önskvärt resultat. Respondenten menar dock att kommunikationen är bristfällig vilket leder till att det ibland i verksamheten uppstår överraskningar i slutskedet av systemutvecklingsprojekt. Ett exempel på “överraskningar” är funktioner i systemet som inte fungerar på det sätt som verksamheten hade tänkt sig.

Sen är det väldigt mycket silos och det finns inget uttalat hur man ska prata mellan olika projekt eller mellan olika team utan det är upp till någon att ta tag i om man ser att det är massa beroende.

(R:1)

Respondent 1 berättar att systemutvecklingsprojekt ofta är isolerade från varandra och att det inte finns ett uttalat sätt för hur teamen ska samarbeta eller kommunicera med varandra. Respondenten nämner även att det har gjorts initiativ där man har satt ihop vissa möten och försökt få det att fungera men det beror mer på enskilda personers initiativ.

Kommunikationen mellan olika systemutvecklingsprojekt samt mellan teamen har till följd av organisatoriska “silon” orsakat obefintlig eller otillräcklig koordinering mellan team och systemutvecklingsprojekt. Denna problematik kan enligt SAFe förklaras genom en avsaknad av en gemensam kadens över leveranser inom systemutvecklingsprojekt. Kadens kan ses som ett bestämt tidsintervall för leveranser som genomförs under utvecklingen, likt “sprintar”. Genom att flera team synkroniserar sitt arbete i en gemensam kadens kan det från feedback på leveranser ges en tydlig överblick över projektets pågående riktning. Möjliga problem som orsakas av beroenden mellan team och dess leveranser kan då uppmärksammas och hanteras tidigare i utvecklingsprocessen.

Den är A och O skulle jag säga. Den har inte varit speciellt bra. Man måste förstå att det är två komplexa världar, IT världen är jättekomplex och svår att förstå för en ämnes person och tvärtom också, ämnes världen är jättesvår för en IT person att förstå.

(R:2) Vi behöver bli bättre på IT-avdelning att ta reda på vad de vill åstadkomma.

(R:5) Vi underskattar hur mycket verktygen kan bidra med en förändring och hur mycket som faktiskt krävs i själva verksamheten, vi underskattar de verksamhetsmässiga förändringarna. Så kanske det är dåligt interaktion

25

mellan dem, man kanske inte har förmedlat kraven på ett bra sätt. Verksamheten kanske inte alltid har förstått exakt vad man har tänkt att göra där heller. Det är ganska sent man kommer på att, nu måste vi jobba på ett annats sätt om vi ska kunna få det här system att funka. Det kanske inte bara beror på system utan det kanske beror på saker runt omkring som man måste förhålla sig till [...] Det finns en övertro på hur rätt man kan räkna.

(R:10)

Respondent 10 menar att den förändring i verksamheten som krävs underskattas och att man inte alltid förstår hur det är tänkt att systemen ska användas. Därmed tar det tid innan systemen kan användas fullt ut i produktion. Ofta beror detta på andra faktorer som man måste förhålla sig till, vilka ofta upptäcks längs vägen. Till denna kontext förespråkar SAFe att utvecklingsteam måste förstå grunden av vad det är för system som ska utvecklas. SAFe framhåller vikten av utvecklares förståelse kring begränsningarna av system, syftet med dessa samt hur integrering ska ske. För detta krävs det att intressenter och framtida användare ses som partners under processen, samtidigt som båda parter litar på varandra och att samförstånd mellan dessa finns. Även respondenterna 5 och 2 påpekar avsaknaden av förståelse och informationsdelningen mellan systemutvecklingsteam och verksamhet.

Vidare menar respondent 10 att detta bidrar till att systemutvecklingsprojekten tenderar att öka i omfattning och kostnad, vilket i sin tur gör att folk blir missnöjda. En bakomliggande orsak enligt respondent 10 är att de räknar fel. Man underskattar hur mycket utvecklingen kostar. Ofta finns en dålig uppfattning av vad slutmålet ska uppnå och inte heller en tydlig struktur med det agila arbetet i förhållande till processen som helhet. Ofta spenderas för mycket tid under de första sprintarna. Konsekvenserna som respondent 10 pekar ut går även de att härleda till SAFe och avsaknaden av förståelse. I SAFe framgår det att risken att utvecklingen fastnar vid specifika komponenter minskar om teamen har en bredare förståelse för systemets slutliga mål och syfte. Risken finns att team arbetar för djupgående med ett fåtal komponenter för att göra dessa så bra som möjligt och därmed lägger mindre fokus på systemet i helhet.

6.3 Decentraliserat beslutsfattande

I intervjuerna fick respondenterna svara på hur beslutsfattande tas och hur beslutsfattandet ser ut samt vilka mandat teamen har att fatta beslut. I denna kontext framkom flera olika svar, vissa svarade att de på teamnivå har stora möjligheter att själva ta beslut kring olika tekniska aspekter samtidigt som verksamheten lyssnade på teamens förslag (R7 nämner att det finns olika varianter på hur det ser ut). En övervägande andel svarade dock att det inom myndigheten är detaljstyrt från högre nivåer.

På myndigheten med nya strategin så är det top-down och det är toppstyrt och det finns skulle jag säga liksom små förutsättningar att lyckas på nåt sätt. [...] Vilket är väldigt oagilt. [...]Det är ju liksom styrning väldigt hårt i den här och uppifrån och ned och sen kanske man