Agil transformation för produktutveckling i mjukvarubranschen: Ett arbete om upplevda utmaningar och fördelar med agilt arbetssätt

Examensarbete Integrerad produktutveckling grundnivå, 15 hp, kurskod MF131x

Agil transformation för produktutveckling i mjukvarubranschen

Ett arbete om upplevda utmaningar och fördelar med agilt arbetssätt

Pauline Korssell Shervin Ghahestani Examinator

Sofia Ritzén

Handledare

Ingrid Kihlander och Gunilla Ölundh Sandström

Sammanfattning

Allt fler aktörer uppkommer på den redan konkurrenskraftiga marknaden vilket ställer höga krav på utveckling av nya innovativa produkter för företag inom mjukvarubranschen. Detta leder till att företag måste förändra sin struktur och sitt arbetssätt för att kunna anpassa sin produktutveckling efter kunderna och marknaden. Ett sätt för företag att kunna fortsätta vara konkurrenskraftiga och bemöta marknadens behov är att implementera agila arbetssätt.

Syftet med detta arbete är att bidra till ökad kunskap kring hur produktutvecklingsprocessen för en agil transformation från beslut till implementation kan ske i mjukvarubranschen. Arbetet har undersökt tre frågeställningar relaterade till agil transformation i mjukvarubranschen.

Inledningsvis genomfördes en litteraturstudie för att erhålla en ökad förståelse för produktutveckling i mjukvarubranschen och för det agila arbetssättet. Vidare utfördes en kvalitativ semistrukturerad intervjuundersökning med fyra respondenter från tre företag där samtliga arbetar med agila arbetssätt och produktutveckling inom mjukvarubranschen. Den kvalitativa studien undersökte vilka utmaningar och potentiella fördelar en agil transformation kan generera samt vad som kännetecknar en lyckad agil transformation. Utifrån resultatet av denna studie utformades ett antal kategorier som kan användas som riktlinjer för hur en organisation kan gå tillväga vid en agil transformation i mjukvarubranschen.

Studien visar att en agil transformation är en komplex och tidskrävande process. Utmaningar med agil transformation innefattar att ett agilt arbetssätt ofta blir beroende av en nyckelperson, det kräver en hög samverkan och ökad förståelse för varandras arbetsuppgifter samt ett anpassningsbart tankesätt som är mottagligt för förändring. Däremot genererar den agila transformationen fördelar så som en ökad produktivitet och användarnöjdhet, minskat antal defekter och en kortare ledtid hos samtliga företag.

För att lyckas med en agil transformation visar studien på att ett företags medarbetare bör vara mottagliga för förändring och att motivet till transformationen borde komma inifrån

organisationen. Sammanfattningsvis resulterade den agila transformationen i en förbättrad mjukvaruutveckling.

Nyckelord

Agilt tankesätt, agila arbetssätt, agil transformation, fördelar, mjukvaruutveckling, nyckelfaktorer, produktutvecklingsprocesser, Scrum, utmaningar.

Degree project in Integrated Product Development First cycle, 15 cr, course code MF131x

Agile transformation for product development in the software industry

A study about experienced challenges and advantages with agile working methodology

Pauline Korssell Shervin Ghahestani Examiner

Sofia Ritzén

Supervisor

Ingrid Kihlander and Gunilla Ölundh Sandström

Abstract

A large number of businesses are emerging on the already competitive market which places high demands on the development of new innovative products for companies in the software industry.

As a result, companies must change the structure of the organization and their methods. Due to this, they have to customize their product development in order to meet the requirements of the customers and the markets demand and maintain their competitiveness. One way for companies to stay competitive is by implementing agile working methodologies.

This study aims to contribute with knowledge and investigate the processes of an agile transformation from decision-making to implementation in the software industry. The study has examined three problem statements related to the agile transformation in the software industry.

Initially a literature review was performed to gain an insight into product development in the software industry and the agile working methodologies. Furthermore, a semi structured qualitative interview was conducted which involved four respondents from three companies that work with agile working methodologies and product development in the software industry. This qualitative study examined the challenges and possible opportunities that an agile transformation generates as well as the characteristics of a successful transformation. Based on the result of this study, several categories were chosen and treated as guidelines for how an organization in the software industry can approach the agile transformation and proceed with it successfully.

The results of the study demonstrate that an agile transformation is a complex and time-consuming process. The many challenges involving the agile transformation includes that the agile working methodology often becomes dependent of a single key person, it also requires collaboration, an increased understanding of each other’s work as well as an adaptable mindset that is receptive towards change. However, the agile transformation enables advantages amongst all the companies such as an increased productivity and user satisfaction, decreased number of defects as well as a reduced leadtime.

To succeed with an agile transformation, it is of importance that a company’s employees are receptive towards change and that the motive behind the transformation comes internally within

the organization. In conclusion, the agile transformation improved and strengthened the companies’ software development.

Keywords

Advantages, agile mindset, agile working methodologies, agile transformation, challenges, key factors, product development processes, Scrum, software development.

Förord

Denna rapport upprättades som en del av ett kandidatexamensarbete under vårterminen 2019 på Kungliga Tekniska högskolan inom Integrerad Produktutveckling, MF131x.

Vi vill tacka våra handledare Gunilla Ölundh Sandström och Ingrid Kihlander som genom föreläsningar, seminarier och handledning hjälpt oss skapa och utveckla detta kandidatexamensarbete. Vidare vill vi tacka samtliga företag och respondenter som möjliggjorde detta arbete genom att bidra med värdefull kunskap om ämnet. Slutligen vill vi rikta ett stort tack till våra kurskamrater för givande diskussioner och feedback under kursens gång.

Stockholm, juni 2019 Pauline Korssell Shervin Ghahestani

Innehållsförteckning

1. Inledning ... 1

1.1 Syfte ... 2

1.2 Frågeställningar ... 2

2. Teoretisk referensram ... 3

2.1 Agilt arbetssätt ... 3

2.2 Mjukvaruutveckling enligt SDLC ... 3

2.2.1 Mjukvaruutveckling med agilt arbetssätt ... 4

2.3 Scrum ... 4

2.3.1 Backlog ... 5

2.3.2 Sprintar ... 5

2.3.3 Scrum Team ... 5

2.4 Nulägesanalys för implementering av agilt arbetssätt ... 6

2.5 Fördelar och utmaningar med agilt arbetssätt... 6

2.6 Utvärdering av en agil transformation ... 7

3. Metod... 8

3.1 Kvalitativ metod ... 8

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

3.2.1 Datainsamling och analys av data ... 8

3.3 Val av företag och respondenter ... 9

3.4 Beskrivning av företag och respondenter ... 9

3.4.1 Företag A ... 9

3.4.2 Företag B ... 9

3.4.3 Företag C ...10

3.4.4 Vice VD ...10

3.4.5 Sektionschef ...10

3.4.6 Partner...10

3.4.7 Scrum Master ...10

3.5 Kvalitetsmått ... 11

4. Empiri ... 12

4.1 Företag A ... 12

4.2 Företag B ... 14

4.3 Företag C ... 16

5. Analys och diskussion... 18

6. Slutsats ... 23

6.1 Förslag på fortsatt arbete ... 24

Referenser ... 25

Bilaga 1. Intervjuguide ... 1

1. Inledning

Detta avsnitt behandlar studiens problematisering, syfte och frågeställningar.

Marknaden är under ständig utveckling där det dagligen uppkommer innovativa lösningar för nya produkter på den redan konkurrenskraftiga marknaden. Detta sätter press på marknadens befintliga aktörer i mjukvarubranschen. I sin tur medför detta krav på aktörerna att ständigt vidareutveckla redan etablerade tjänster och produkter för att kunna bibehålla sin konkurrenskraft (Schuh et al., 2015). För att möjliggöra detta och utveckla organisationens produktutveckling räcker det inte alltid att införa nya verktyg eller tekniker. Ibland kan arbetssättet behöva utvärderas mot andra etablerade processer och teorier för att eventuellt förändras (Estefan, 2007).

Förändring av arbetssätt medför en stor förändring för hela organisationen eftersom produktutveckling innefattar flertalet komplexa processer. Införande av ett nytt arbetssätt gör att arbetsprocesser fullständigt förändras vilket kan ha en inverkan på företagets strategier, tekniker och verktyg. När en organisation genomgår en förändring och implementerar en ny arbetsprocess påverkas samtliga medarbetare. Projektledare och utvecklare påverkas i stor utsträckning då de är vana att arbeta enligt traditionella metoder (Gandomani et al., 2013).

På senare tid har det agila arbetssättet snabbt vuxit fram och blivit mycket omdiskuterat. Det agila arbetssättet skiljer sig från traditionella produktutvecklingsmetoder då det är ett rörligare arbetssätt som inte följer de traditionella strukturerna (Mesquida et al., 2018). Därmed kan en övergång till ett agilt arbetssätt vara komplicerad och tidskrävande då det innebär att rutiner och mönster måste brytas (Gibbons, 2015). Detta resulterar i att många olika faktorer vägs in och det måste finnas välgrundade motiv till en transformation. I sin tur medför detta att företag som ställs inför samma utmaning i en förändring av arbetssätt kan behöva vidta olika åtgärder eftersom deras verksamhet och produktutvecklingsprocess kan skilja sig åt.

I stora organisationer kan den agila transformationen medföra svårigheter då organisationens struktur på basnivå även hos medarbetarna behöver bli mer samarbets- och ledarskapsinriktad. En stor utmaning är att projektledaren inte ensam fattar beslut i en agil verksamhet utan hela gruppen samarbetar och fattar beslut tillsammans (Nerur et al., 2005). Detta medför att projektledarens möjligheter till att påverka arbetet minskas och därför är tillit mellan individerna i en grupp en viktig del av ett agilt arbete. Ett agilt arbetssätt leder även till att individer i en grupp får större ansvar. Något som resulterat i att arbetsprocessen och ny kunskap dokumenteras bristfälligt vilket kan skapa besvär för ledningen och organisationen (Gandomani et al., 2013).

Ett problem med en agil transformation är att det finns en avsaknad i information kring processen för en agil transformation och hur en organisation kan gå tillväga (Cao et al., 2009). Det finns däremot mycket information om agila arbetssätt och varför dessa bör implementeras för att förbättra produktutvecklingen. Att byta arbetssätt samtidigt som en organisation växer kan vara svårt och därför är det viktigt att det finns riktlinjer och strukturer att följa för att lyckas med en agil transformation.

1.1 Syfte

Syftet med denna rapport är att undersöka upplevda utmaningar och möjligheter för företag i mjukvarubranschen vid en transformation till ett agilt arbetssätt i produktutvecklingen.

1.2 Frågeställningar

● Vilka utmaningar kan ett företag i mjukvarubranschen ställas inför vid införandet av en agil produktutvecklingsprocess?

● Vilka potentiella fördelar genererar denna agila transformation?

● Vad kännetecknar en lyckad agil transformation i mjukvarubranschen?

2. Teoretisk referensram

Detta avsnitt presenterar litteraturstudien för agila principer och processer för mjukvaruutveckling.

2.1 Agilt arbetssätt

Det agila arbetssättet har sin bakgrund inom mjukvaruutveckling och uppkom på grund av att det ofta inträffade händelser som förändrade förutsättningarna och omständigheterna för IT-projekt (Senabre, 2019). Detta resulterade i att det var svårt att stå fast vid en projektplan. 17 personer hade en vision om att förändra hela IT-branschen och utvecklade därför det agila arbetssättet. Således upprättades det agila manifestet som behandlar tolv principer och grundläggande värderingar kring detta arbetssätt (Gustavsson, 2014). Det agila manifestet resulterade även i följande fyra grundvärderingar enligt Björkholm och Brattberg (2010).

● Individer och interaktioner värderas över processer och verktyg.

● Fungerande programvara värderas över omfattande dokumentation.

● Kundsamarbete värderas över kontraktsförhandling.

● Anpassning till förändring värderas högre än att följa en plan.

2.2 Mjukvaruutveckling enligt SDLC

Utveckling av system inom mjukvarubranschen består av olika faser. Dessa faser innefattar olika processer för att utveckla mjukvara från en idé till en färdig produkt. Modellen SDLC är en förkortning för System Development Life-Cycle som kan användas för att beskriva de sex skedena för produktutvecklingsprocessen för mjukvara (Leau et al., 2012). Inom SDLC genomförs stegen för mjukvaruutveckling i en viss ordning där första skedet är planeringsfasen och därefter definieras specifikationer och krav för att kunna påbörja analysfasen. Efter att systemet designats, implementerats och testats avslutas cykeln med en underhållningsfas av det färdiga systemet (Ruparelia, 2010).

Mall (2014) beskriver att tydliga kriterier behöver definieras för respektive fas för att kunna påbörja en fas samt avgöra när den är fullständig. Detta är viktigt för att få en tydlig struktur i utvecklingsprocesserna (Mall, 2014). Livscykelmodellen är flexibel och kan även anpassas utefter ett företags storlek och till den nivå av komplexitet som mjukvaruutvecklingen innebär (Saleh, 2009). I figur 1 nedan beskrivs faserna i en SDLC-modell.

Figur 1. Sammanställning och modifiering av mjukvaruutvecklingens olika processer (Leau et al., 2012).

2.2.1 Mjukvaruutveckling med agilt arbetssätt

Det agila arbetssättet kan beskrivas som ett antal teorier och metoder med fokus på att förenkla och kontinuerligt förbättra utveckling av mjukvara genom prioritering av produkten (Fowler &

Highsmith, 2001). Ett agilt arbetssätt är rörligt vilket gör att processer i produktutvecklingen kontinuerligt måste anpassas mot förändringar (Nerur et al., 2005). Därmed har det agila arbetssättet med dess olika metoder blivit populärt att tillämpa för att effektivisera mjukvaruutveckling. Detta då en agil utvecklingsmetod för mjukvara bygger på att inkrementellt arbeta iterativt med testbaserade processer (Beck et al., 2001). Det inkrementella arbetssättet medför att olika utvecklingsfaser för mjukvara kan bedrivas parallellt för att utveckla delar av ett system som sedan integreras till en färdig produkt. Utveckling av prototyper påbörjas ofta i ett tidigt skede. Detta möjliggör att system kan dellevereras så användare och beställare kan testa prototyper och identifiera eventuella brister i systemet (Cockburn, 2002). Därmed utformas kravspecifikationer efter att testning genomförts. I sin tur kan produkten kontinuerligt utvärderas och förändras under hela utvecklingsprocessen för att förbättra produkten (Leau et al., 2012). Även en förändring i arbetssätt kan ske för att förbättra processerna för mjukvaruutvecklingen.

2.3 Scrum

Enligt en undersökning av VersionOne (2017) är Scrum den mest implementerade agila metoden för mjukvaruprojekt hos företag. Scrum utvecklades av Jeff Sutherland och Ken Schwaber vars syfte var att producera och underhålla komplexa system och produkter (Azanha et al., 2017). Som metod utmärks Scrum genom en flexibel leverans som är skräddarsydd mot kund (Schwaber, 1997). Arbetet i produktutveckling sker i tvärfunktionella små Scrum Team som har ett ökat samarbete både inom och mellan flera team (Yukl, 2011). Scrum utmärks genom att vara ett arbetssätt som innebär flexibilitet, produktivitet och anpassningsförmåga. Några av de viktigaste delarna av Scrum beskrivs nedan.

2.3.1 Backlog

Backlog är en lista på nödvändiga funktioner och krav som behövs för att utveckla en produkt (Shore & Warden, 2008). Vidare beskriver Shore och Warden (2008) att dessa rangordnas efter prioritet för att teamet ska veta hur de ska börja arbeta med utvecklingen av en produkt. Under produktutvecklingens gång kan listans innehåll och prioriteringar förändras. Nya önskemål kan tillkomma vilket gör arbetet med utvecklingen av en produkt flexibel och anpassningsbar (Sutherland, 2012).

2.3.2 Sprintar

Scrum Team arbetar cykliskt i så kallade tidsbestämda sprintar. Comstedt (2017) beskriver att sprintarna innebär en kort iteration där delar av ett system utvecklas under en tid om maximalt fyra veckor. I sprinten ingår planering, utveckling samt utvärdering och i slutet av sprinten levereras ett delsystem där målsättningen är att produktens funktion utvecklats i linje med backlogens prioriteringar (Comstedt, 2017). En ny sprint påbörjas efter en avslutad tills ett färdigt system erhålls. Efter varje avslutad sprint hålls ett möte för att utvärdera sprinten och se över förbättringsområden till nästkommande sprint (Ahmed & Mohammed, 2019).

2.3.3 Scrum Team

Ett Scrum Team består av en Scrum Master, en produktägare och ett utvecklingsteam (Sutherland, 2012). Dessa roller beskrivs nedan.

Scrum Master

Rollen som Scrum Master innebär att försäkra sig om att utvecklingsteamet arbetar i enlighet med de regelverk som finns och att facilitera teamet för att underlätta ett effektivt arbete (Schwaber &

Sutherland, 2017). Vidare ska Scrum Mastern vara drivande i införandet av Scrum i organisationen och bidra till att samtliga medarbetare får förståelse för Scrum för att kunna lära sig implementera det (Tonnquist, 2018).

Produktägare

Produktägaren har det fullständiga ansvaret för utveckling av produkten och har som uppgift att prioritera i backlogen. Därutöver ska produktägaren prioritera teamets arbetsuppgifter inför sprintar. (Tonnquist, 2018)

Utvecklingsteam

För att utvecklingsteamet ska prestera optimalt anser McDonald (2019) att det ska bestå av ett självorganiserat tvärfunktionellt team. Med detta menas att teamet själva kontinuerligt förändrar och omorganiserar sitt arbetssätt samt bestämmer vem som ska genomföra uppgifter samtidigt som de begränsas av bestämda regelverk (McDonald, 2019).

Individer i teamet är specialiserade inom ett område men besitter även förmågan att förstå varandras olika områden (Schwaber & Sutherland, 2017). Detta då det agila arbetssättet innebär att samtliga faser av produktutvecklingen är beroende av varandra (Verwijs, 2015).

Enligt Schwaber och Sutherland (2017) bör utvecklingsteam bestå av tre till nio personer utöver Scrum Mastern och produktägaren. Team med färre än tre personer har inte tillräckligt med

färdigheter för att leverera under sprintar och team med fler än nio personer kräver för mycket koordinering (Schwaber & Sutherland, 2017). En annan väletablerad teori kring den optimala storleken på Scrum Team är sju plus minus två personer (Mersino, 2017).

Sprintplanering

Sprintplanering sker på sprintens första dag och involverar hela Scrum Teamet. Under sprintplaneringen bestäms vad som ska levereras under sprinten samt hur teamet ska arbeta för att leverera detta. (Golfarelli et al., 2013)

2.4 Nulägesanalys för implementering av agilt arbetssätt

Inledningsvis rekommenderar Denning (2018) att en nulägesanalys av en organisation genomförs för att kunna implementera ett agilt arbetssätt. Detta utförs för att bestämma vilken nivå av agilitet som företaget behöver befinna sig på för att kunna ta sig an de utmaningar de står inför (Denning, 2018). Enligt Sharifi och Zhang (1999) behöver även en undersökning om hur agil verksamheten är i nuläget genomföras. Detta jämförs därefter mot den önskvärda nivån av agilitet för att kunna nå ett koncept för en agil transformation som kan förbättra och utveckla produktutvecklingsprocesser. Vidare vägs faktorer som företagsmiljö, arbetssätt, beslutsprocesser samt potentiella fördelar med en agil transformation in i analysen. Företag kan använda denna analys för beslutsfattande om de är i behov av en agil verksamhet. Resultatet av analysen kan enligt Sharifi och Zhang (1999) delas in i följande fyra kategorier.

● Företaget är inte i behov av att införa en agil verksamhet.

● Företaget har en tillräckligt agil verksamhet som kan besvara de nya förändringarna som verksamheten kan bemöta i framtiden.

● Företaget behöver vidta åtgärder för att införa en agil verksamhet, men det är inte brådskande.

● Företaget behöver snarast införa en stark agil verksamhet som kan bemöta den nya utvecklingen.

2.5 Fördelar och utmaningar med agilt arbetssätt

Agilitet tillämpas ofta för att en organisation måste effektivisera projekt eller delar av sin verksamhet för att bemöta utmaningar. Ett agilt arbetssätt har enligt Björkholm och Brattberg (2010) kunnat bevisats möjliggöra en förbättrad produktutveckling enligt följande parametrar.

● Lägre kostnad.

● Större flexibilitet.

● Färre defekter.

● Ökad produktivitet och snabba delleveranser av resultat.

Att arbeta i korta sprintiterationer medför en större överblick för arbetet vilket möjliggör att inför nästkommande sprint kunna tillsätta resurser och ändra planeringen om arbetets omständigheter snabbt förändrats (Comstedt, 2017). Däremot om produktägaren satt upp mål i sprinten som

överstiger teamets kapacitet kan det leda till en ohållbar arbetsbelastning som gör att produkten inte hinner färdigställas i tid (Verwijs, 2015).

Ett Scrum Team har enligt Schwaber och Sutherland (2017) bevisats kunna effektivisera produktivitet, flexibilitet och kreativitet samt lösa komplexa arbetsuppgifter. Det möjliggör även leverans av produkter på ett inkrementellt och iterativt sätt (Schwaber & Sutherland, 2017). Dock kan hinder uppstå om Scrum Team är personberoende. Om varje person i teamet besitter en viktig specifik kompetens och en av medlemmarna i teamet slutar leder det till att teamet inte kan leverera produkten (Verwijs, 2015).

2.6 Utvärdering av en agil transformation

Det finns olika sätt att utvärdera hur framgångsrikt ett agilt projekt varit. Enligt en undersökning utförd av VersionOne (2017) ansåg respondenterna att leverans inom uppsatt tidsram, skapat värde för företaget och en ökad kund- och användarnöjdhet var de främsta faktorerna för en lyckad agil transformation. Enligt Janse (2018) kan utfallet även mätas genom antalet defekter som kunder märker av, vad som levererats jämfört mot vad som planerats samt ledtid. Ledtid definieras som tiden från att projektet inleds tills produkten är levererad (Janse, 2018).

I undersökningen genomförd av VersionOne (2017) svarade respondenterna även att de främsta nyckelfaktorer som krävs för att en organisation ska lyckas med en agil transformation är följande.

● Intern agil coach.

● Verkställande företagsledare.

● Implementering av ett gemensamt verktyg som team kan utnyttja.

● Agila konsulter eller agila coacher.

3. Metod

Detta avsnitt presenterar studiens arbetssätt, teoretisk referensram, intervjuguide och en beskrivning av företag och respondenter. Vidare behandlas studiens kvalitetsmått.

3.1 Kvalitativ metod

Detta projekt ämnar samla in data genom att undersöka företags erfarenheter av agila arbetssätt och upplevelser av agila transformationer. En kvalitativ intervjuundersökning används för att undersöka och pröva teorier mot respondenternas egen uppfattning och tolkning av frågeställningarna (Bryman & Bell, 2017).

3.2 Tillvägagångssätt

I arbetets inledande del skapades en teoretisk referensram där en djupgående litteraturstudie genomfördes för att ta reda på nuvarande kunskapsläge angående agila arbetssätt i mjukvaruutveckling. Litteraturstudien genomfördes för att definiera begreppet agilt arbetssätt och tankesätt samt för att identifiera etablerade metoder för agilt arbetssätt. Potentiella utmaningar och fördelar undersöktes genom att granska tidigare studier inom området samt genom en kvalitativ intervjuundersökning. Litteraturstudien utfördes genom sökningar med nyckelord i databaserna Primo, Scopus samt Web of Science för att hitta relevanta forskningsartiklar.

3.2.1 Datainsamling och analys av data

Vid insamling av data och kunskapsfördjupning upprättades en semistrukturerad intervjuguide.

Detta valdes för att få en ökad förståelse för hur teorin om ett agilt arbetssätt kan tillämpas i praktiken. Semistrukturerade intervjuer användes för att kontrollera att intervjufrågor som ställts till respondenten relaterar till detta arbete så frågeställningar kan besvaras. Strukturen är även till för att ge utrymme för öppenhet och ge respondenten möjlighet att ställa frågor och bidra med tillägg till arbetet. Detta kan gå förlorat om intervjun är för ostrukturerad eller fullständigt strukturerad. Intervjun är uppdelad enligt kategorierna inledande frågor, generellt om produktutveckling, innan beslut om transformation samt vid beslut, förändring av arbetssätt, nytt arbetssätt och avslutande frågor. Intervjuguiden återfinns i Bilaga 1.

Intervjuerna var cirka en timme långa och genomfördes i ett enskilt rum på huvudkontoret i Stockholm för tre av respondenterna. Den fjärde intervjun skedde över telefon. Under intervjuerna som skedde på plats hos företagen intervjuade en person medan den andra hanterade ljudinspelningen och tog enklare anteckningar. Samtliga intervjuer transkriberades och nyckelord identifierades utifrån dessa samt från anteckningarna från intervjuerna.

Utifrån dessa nyckelord kategoriserades transkriptionerna enligt följande sex kategorier.

● Motiv till transformationen.

● Tankesätt, arbetssätt och metod.

● Potentiella utmaningar vid en agil transformation.

● Upplevda möjligheter vid en agil transformation.

● Nyckelfaktor för en lyckad agil transformation.

● Uppföljning av transformationen.

3.3 Val av företag och respondenter

Tre företag har valts för att få ett bredare perspektiv i frågorna och för att kunna jämföra hur agila transformationer har genomförts. De tre valda företagen är relevanta för detta arbete då de antingen genomfört en agil transformation eller arbetar med att hjälpa andra organisationer att implementera agila arbetssätt. Samtliga företag är verksamma inom mjukvarubranschen och ett av företagen bedriver egen utveckling av innovativa produkter. Denna bransch har valts för att det finns väletablerad forskning kring agila arbetssätt i mjukvarubranschen samtidigt som det finns mycket att bidra med till ämnet.

Vid val av företagsrespondenter var erfarenhet av agila arbetssätt och mjukvaruutveckling av stor betydelse. En person med ledande befattning samt en medlem i ett Scrum Team hos respektive företag har intervjuats. Dessa har en central roll i att skapa en förbindelse mellan individer som medverkar i en agil transformation. Både manliga och kvinnliga respondenter har intervjuats.

Företagen benämns vid företag A, företag B och företag C. Respondenterna benämns som Vice VD, Sektionschef, Partner och Scrum Master.

3.4 Beskrivning av företag och respondenter

Nedan följer en beskrivning av företag och respondenter som varit del av den kvalitativa intervjustudien.

3.4.1 Företag A

Ett svenskt företag som är verksamt i större delen av världen med huvudkontor i Stockholm.

Företaget har över 10 000 anställda och är världsledande i telekombranschen och erbjuder utveckling av hårdvara, mjukvara och tjänster för att hjälpa kunder att digitalisera sin verksamhet.

År 2010 genomgick en av produktutvecklingsavdelningarna som arbetar med mjukvara i Sverige en agil transformation.

3.4.2 Företag B

Ett svenskt IT-konsultföretag som arbetar med att hjälpa kunder att digitalisera sin verksamhet och implementera agila arbetssätt för att förbättra produktutveckling. Totalt finns företaget i sex

länder med huvudkontor i Stockholm. Företag B har över 1300 anställda, har arbetat agilt sedan det grundades och har en platt organisation.

3.4.3 Företag C

Ett svenskt företag som utvecklar onlinespel i casinobranschen. Företaget har flertalet kontor i Europa med huvudkontor i Stockholm. Företag C har över 1000 anställda och övergick år 2015 till att bli en produktorganisation där stora delar av företaget började arbeta agilt.

3.4.4 Vice VD

Respondenten är Vice VD över en produktutvecklingsavdelning med 1800 personer som arbetar med mjukvaruutveckling på företag A. Respondenten har arbetat på företaget i över 20 år och ledde den agila transformationen som produktutvecklingsavdelningen genomgick år 2010.

3.4.5 Sektionschef

Respondenten är Sektionschef över en mjukvaruutvecklingsenhet bestående av ett tvärfunktionellt team hos företag A. Respondenten har arbetat på företaget i över fem år med tidigare roller som utvecklare inom olika produktutvecklingsavdelningar.

3.4.6 Partner

Respondenten är Partner på företag B och arbetar som agil coach. Partnern har lång erfarenhet av produktutveckling och har arbetat med att hjälpa andra organisationer att implementera agila arbetssätt i över sex år. Respondenten har arbetat på företag B i över 12 år och började som utvecklare.

3.4.7 Scrum Master

Respondenten är Scrum Master och Agil Coach och har arbetat som konsult på företag B i över fyra år. Scrum Mastern har under två år haft ett uppdrag hos företag C som Agil Coach och förändrat deras organisation till en produktorganisation genom att implementera ett agilt arbetssätt.

Intervjun med Scrum Mastern fokuserade på uppdraget hos företag C.

I tabell 1 nedan presenteras en sammanställning av respektive respondents roll samt relevant information om intervjuerna.

Tabell 1. Sammanställning av respondenter.

Företag Respondent Respondentens roll Intervjuplats Intervjulängd

A Vice VD Vice VD för en

produktutvecklingsavdelning

Stockholm Huvudkontor

64 minuter

A Sektionschef Sektionschef för en mjukvaruutvecklingsenhet

Telefonintervju 33 minuter

B Partner Partner & Agil Coach Stockholm Huvudkontor

55 minuter

C Scrum Master Scrum Master & Agil Coach Stockholm Huvudkontor

43 minuter

3.5 Kvalitetsmått

Då studien endast genomförts på tre företag med fyra respondenter är resultatet begränsat.

Resultatet är baserat på respondenternas egen uppfattning i frågorna och blir därför endast en vägledning för att besvara frågeställningarna och inte ett direkt svar. Valda företag har lång erfarenhet av produktutveckling i mjukvarubranschen och agila arbetssätt. Företag A strävar efter att bli världsledande inom forskning och utveckling av produkter i Sverige. Företag B har som ambition att utveckla de mest optimala lösningarna för deras kunder och kombinerar expertis med erfarenhet. Företag C är ett ledande företag när det gäller spelutveckling i casinobranschen.

Företagens ambitioner kombinerat med respondenternas erfarenhet av mjukvaruutveckling och agilitet skapar därmed en stark reliabilitet och validitet för studien.

4. Empiri

Detta avsnitt redogör för insamlad data från intervjustudien. Resultatet presenteras för respektive företag enligt de tidigare nämnda sex kategorierna.

4.1 Företag A

4.1.1 Motiv till transformationen

Företagets forsknings- och utvecklingsavdelning har som ambition att vara världsledande inom sitt område i Sverige. Företag A förändrade därför sitt arbetssätt till agilt år 2010 då de ständigt hade försenade projekt samt erhöll en lägre output än input vid utgivning av produkter. Den grundläggande orsaken till att förändra arbetssättet var att effektivisera verksamheten, korta ned ledtider samt minska antalet defekter.

4.1.2 Tankesätt, arbetssätt och metod

För att utforma samlokaliserade agila long-lived teams ¹ från den befintliga arbetskraften använde Vice VD teori från böcker. En plan utformades för att genomföra en succesiv agil transformation.

Planen innefattade att bilda 100 tvärfunktionella utvecklingsteam inom loppet av två år där ett testteam inledningsvis upprättades. Testteamet bestod av 12 personer och när testteamet uppnådde förväntningarna ökades antalet till 25 team. Enligt Vice VD nåddes point of no return vid 25 team och då var det möjligt att antingen fullfölja den agila transformationen eller återgå till det tidigare arbetssättet.

Transformationen fullföljdes till 100 tvärfunktionella team bestående av systemingenjörer, mjukvaruingenjörer och testare som arbetade inkrementellt tillsammans för att utforma produkter.

I beslutsstadiet av transformationen upprättades följande fyra målsättningar som skulle nås inom fem år.

● Halverad ledtid.

● Tio gånger bättre kvalité.

● Fyra gånger högre effektivitet.

● Medarbetare ska vara minst lika nöjda eller mer med det nya arbetssättet.

4.1.3 Potentiella utmaningar vid en agil transformation

Enligt Vice VD är en vanlig missuppfattning att agilitet endast är ett arbetssätt med teori för metoder och verktyg. Agilitet handlar inte endast om dessa, utan även det agila tankesättet är av stor betydelse.

”Agile is a mindset” - Vice VD

1 Long-lived teams är en term som enligt Larman och Vodde (2010) innebär att ett team arbetar tillsammans i all evighet vilket gör att de utvecklar stabilitet och ett optimalt arbetssätt.

Sektionschefen tillämpade Scrum Team enligt teori med sju plus minus två personer. Detta medförde kompetensbrist inom de nya teamen. Till följd av detta behövde medarbetarna utveckla kunskaper inom fler områden vilket var tidskrävande och till en början medförde det en produktivitetsdipp.

När testteamet besatt fullständig kompetens och började kompilera kod hade endast två personer på produktutvecklingsavdelningen tillstånd att kompilera kod. Dessa personer tillhörde inte testteamet vilket var ett hinder för teamets kontinuerliga testning. Tidigare genomfördes kompilering endast en gång i månaden och en testning kunde ta upp till 17 timmar varav den fallerade hälften av gångerna. Det agila arbetssättet innebar därmed att det behövdes en person i testteamet som kunde kompilera kod.

Fyra organisationer uppmärksammade den lyckade agila transformation och önskade att Vice VD skulle leda deras agila transformation. Ledningen inom dessa organisationer beslutade på egen hand om att genomföra en agil transformation vilket medförde att agilitet projicerades på människor som inte var mottagliga för det. Detta medförde att endast en av fyra organisationer lyckades genomföra en transformation.

4.1.4 Upplevda möjligheter vid en agil transformation

Enligt Sektionschefen möjliggjorde det agila arbetssättet kontinuerliga testningar av system vilket synliggjorde brister med det föregående arbetssättet.

”Agilt löser inga problem, men gör dem helt synliga” - Sektionschef

Signifikanta förbättringar och möjligheter med det agila arbetssättet upplevdes, enligt Sektionschefen. Numera levereras nya system till kund varannan vecka istället för en gång per år.

För mindre förändringar och defekter i befintliga system erhölls en 50 gånger snabbare omloppstid och en stor förändring som tidigare tog flera år dellevereras istället varje månad. Även problemet med den tidskrävande kompileringsprocessen optimerades från 17 timmar till tio minuter.

Utöver detta utvecklades medarbetarna kompetensmässigt för att täcka de kunskapsområden som de nya teamen förväntades besitta. Detta ledde i sin tur till en ökad effektivitet och produktivitet i mjukvaruutvecklingens olika processer.

4.1.5 Nyckelfaktor för en lyckad agil transformation

Vice VD ansåg att antalet personer i ett Scrum Team var av stor betydelse. Att följa teorin med sju plus minus två personer ledde till att risken med ineffektivitet, försvårad kommunikation och minskad delaktighet som stora team kan medföra minimerades.

Två externa agila konsulter hjälpte till i initieringsfasen av transformationen. Även en coach från en systerorganisation som genomfört en liknande transformation hjälpte till att vägleda transformationen på produktutvecklingsavdelningen. Organisationscoacher från systerorganisationen hjälpte till att se över avdelningens format och eventuella förändringar som behövde genomföras. Detta för att anpassa mjukvaruutvecklingens olika processer till ett agilt arbetssätt.

Det som differentierar en framgångsrik transformation är att motivationen och engagemanget kommer inifrån, enligt Vice VD. Vidare beskriver Sektionschefen att en viktig faktor för att lyckas med en agil transformation är att en organisation själv inser att det krävs en förändring. Detta eftersom det signalerar att företaget ständigt vill förbättra sin verksamhet och dess resultat.

Sektionschefen poängterar därför vikten av att samtliga som påverkas av en förändring i arbetssätt måste vara mottagliga för det. Vidare måste företag inse att ett agilt arbetssätt bygger på att det alltid finns förbättringsmöjligheter och därmed är en agil transformation en pågående process.

4.1.6 Uppföljning av transformationen

Efter transformationen utfördes en medarbetarundersökning samt en uppföljning av målsättningarna. Resultatet av detta presenteras nedan.

● Minskad ledtid med en tredjedel.

● Defekter minskade med 85 % per månad.

● Fem till åtta gånger högre effektivitet än tidigare.

● 91 % av medarbetarna var minst lika nöjda eller mer nöjda med det nya arbetssättet än det tidigare.

Majoriteten av målen nåddes på utsatt tid och enligt Vice VD medförde den agila transformationen förbättringar inom flera områden för mjukvaruutvecklingen.

4.2 Företag B

4.2.1 Motiv till transformationen

Motivet bakom en agil transformation är ofta avgörande för utfallet. För att en transformation till ett agilt arbetssätt ska vara möjligt bör det finnas en medvetenhet och delaktighet inom organisationen kring transformationen, enligt Partnern. Detta på grund av att agilitet handlar om att få vara självbestämmande och att en omställning till ett agilt arbetssätt påverkar produktledet lika mycket som managementledet och därför måste alla acceptera förändringen.

4.2.2 Tankesätt, arbetssätt och metod

Ett agilt arbetssätt är mer rörligt och enligt Partnern kräver detta att samtliga parter engagerar sig kontinuerligt i avstämningar och processer som påverkar mjukvaruutveckling. Det finns olika modeller och metoder för agila arbetssätt att tillämpa för utvecklingsprocesser men det är även viktigt med det agila tankesättet.

Partnern anser att en organisation kan behöva ta hjälp av en extern agil coach för att förstå det agila tankesättet och vilket arbetssätt som är lämpligt för deras mjukvaruutveckling. När ledningen tar beslutet om en agil transformation beror det ofta på att de anser att teamen underpresterar och att en agil transformation kommer effektivisera teamen. Partnern förklarar att även ledningen ofta är en del av problemet. Därför är det viktigt att ta hjälp av en extern agil coach som kan göra en objektiv bedömning av organisationens behov och presentera resultatet på ett neutralt sätt.

Primärt ligger fokus på att utgå från organisationens behov när agilitet ska implementeras. Teori tillämpas endast genom praktiskt lärande för att organisationen inte ska låsa sig vid specifika agila hjälpmedel. Inledningsvis genomförs en nulägesanalys för att förstå vilka problem som finns och därefter prioriteras dessa för att förbättra organisationens processer för mjukvaruutveckling.

4.2.3 Potentiella utmaningar vid en agil transformation

Mjukvaruutveckling innefattar många olika processer och därför kan det vara tidskrävande att genomföra en agil transformation, enligt Partnern. I initierings- och realiseringsfasen uppstår ofta problem mellan utvecklingsteam, ledning och produktägare. Detta beror på att produktägare, intressenter och utvecklingsteam har olika agendor och brist på förståelse av varandras arbetsuppgifter. Produktledet har ibland svårt att förstå att agilitet handlar om att även de behöver bli mer integrerade i den iterativa processen. Detta beror på att agilt arbetssätt kräver kontinuerlig samverkan av samtliga parter som är involverade i utvecklingen av en produkt. Om inte samtliga parter är integrerade kommer det medföra en större produktivitetsdipp än nödvändigt. Partnern förklarar att en förändring i arbetssätt medför en produktivitetsdipp då det tar tid innan resultat börjar synas när många processer måste anpassas till ett nytt arbetssätt.

”Det kommer bli sämre innan det blir bättre” - Partner

En organisation som inte är medveten om detta börjar i många fall suboptimera för att erhålla ett snabbt positivt resultat. Detta påverkar backlogen då fler uppgifter påbörjas än vad som hinner avslutas vilket inte skapar något värde och endast blir en kortsiktig lösning.

Agilt arbetssätt kräver även att en organisation klarar av att vara självgående och därför uppstår det problem när transformationen associeras med en agil coach eller en specifik metod. Om nyckelpersoner försvinner eller metoden ändras kan det resultera i att den agila strukturen fallerar.

4.2.4 Upplevda möjligheter vid en agil transformation

Organisationer som har ett gemensamt motiv bakom den agila transformationen upplever en förbättrad samverkan. Detta leder till effektivare team eftersom alla är involverade i varandras arbete och kan således arbeta med utveckling av relevanta processer för produkten. I sin tur förklarar Partnern att det även kan leda till förbättringar för organisationens produktutveckling vilket kan ge minskad ledtid, färre defekter och ökad produktivitet.

4.2.5 Nyckelfaktorer för en lyckad agil transformation

Enligt Partnern har många människor svårt att hantera förändringar och därför är det viktigt att bygga upp tillit i ett utvecklingsteam så medlemmarna får äga sin egen förändringsprocess redan från initieringsfasen. En agil transformation måste ske successivt från en plats där agilitet är accepterat så det kan förankras och organiskt växa vidare inom organisationen.

Partnern inleder en förändring som ett experiment och anser att det är en viktig faktor för en lyckad agil transformation. Experimentet utvärderas och om utfallet inte blev som önskat är det alltid möjligt att återgå till det ursprungliga arbetssättet eftersom det endast var ett test. Detta leder till att flera agila arbetssätt kan prövas för att hitta det optimala arbetssättet för en organisations

mjukvaruutveckling. Detta och att produktledet har kontroll över backlogen för att undvika suboptimering är viktiga faktorer för en agil transformation, enligt Partnern.

4.2.6 Uppföljning av transformationen

Utfallet av en agil transformation kan utvärderas med olika metoder och verktyg. Partnern anser att endast två parametrar är viktiga att utvärdera och om dessa två uppfylls kommer andra viktiga faktorer för att förbättra produktutvecklingen falla på plats. Det som mäts är hur glada människor känner sig på jobbet och hur produktiva de känner sig i slutet av arbetsdagen. Detta utvärderingssätt skapar mer värde för organisationen jämfört mot att utvärdera med poängsystem, enligt Partnern.

4.3 Företag C

4.3.1 Motiv till transformationen

Företaget hade en hög ekonomisk tillväxt och expanderade på ett sätt som inte var hanterbart.

Företag C ville övergå från en projektorganisation till en produktdriven organisation med produktteam. Därför tog de hjälp av Scrum Mastern för att implementera ett agilt arbetssätt.

4.3.2 Tankesätt, arbetssätt och metod

Scrum Mastern inleder ett uppdrag med att skapa en förståelse för organisationens nuvarande situation. Därefter anpassas arbetssätt efter kundens behov och förändringar genomförs successivt.

Företag C hade ett stort team som utvecklade en produkt som Scrum Mastern delade upp i två Scrum Team för att följa teorin med sju plus minus två personer. Ett agilt arbetssätt implementerades inom båda utvecklingsteam som bestod av grafiker, art director, produktägare, utvecklare och testare. För att förbättra mjukvaruutvecklingen började teamen arbeta i sprintar om två veckor med organiserade sprintplaneringar. Regelbundna möten med produktägaren sattes även upp för att utvärdera defekter och kunna förebygga dessa i nästa sprint.

Nya roller definierades enligt agila principer där tvärfunktionella utvecklingsteam infördes. Därefter anammades konceptet även successivt av ledningen och rollen projektledare övergick till produktägare. Detta ledde till att hela organisationen började arbeta i sprintar och hade gemensamma uppföljningsmöten.

4.3.3 Potentiella utmaningar vid en agil transformation

En agil coach besitter inte alltid tillräcklig kunskap om processer i mjukvaruutvecklingen. Därför kan det enligt Scrum Mastern ta tid att bygga upp tillit och få tillåtelse att genomföra större förändringar i processer för att utveckla ett system. Företag C hade flertalet pågående projekt vilket ledde till att omställningen till en produktstyrd organisation var tidskrävande.

Vid omställning till produktteam upplevde Scrum Mastern att grafiker och utvecklare hade svårt att kommunicera med varandra på grund av deras skillnad i arbetssätt och för att de besatt olika tekniska kompetenser. Utvecklare arbetar med att bygga upp spelet från grunden med funktioner medan grafiker endast är intresserade av de funktioner som ger det visuella spelet. För att utveckla bättre spel behövde teamet få en ökad förståelse för varandras utvecklingsprocesser.

4.3.4 Upplevda möjligheter vid en agil transformation

Scrum Mastern menar att företag som arbetar agilt ofta får ett stort förtroende för sina utvecklingsteam. Detta beror på att ett agilt arbetssätt kräver kontinuerliga uppföljnings- och avstämningsmöten vilket skapar en stor samverkan. Företag C upplevde att medarbetarna erhöll en ökad förståelse för varandras arbetsuppgifter då exempelvis utvecklarna kunde lära grafikerna att pröva sina visioner i en testmiljö. Genom att arbeta agilt minskade ledtider vilket förbättrade mjukvaruutvecklingen och kvalitén på spelet.

4.3.5 Nyckelfaktorer för en lyckad agil transformation

En agil transformation får inte vara beroende av en person som varit drivande under hela transformationens gång, enligt Scrum Mastern. Detta då det finns risk att den agila transformationen inte blir bestående om denna person försvinner. Istället är det viktigt att det agila arbetssättet sprids inom organisationen, likt när det anammades av ledningen.

”En agil transformation får inte vara personberonde” – Scrum Master

Agilitet innefattar ett kontinuerligt arbete med ett ständigt utvecklingsfokus och en organisation bör därför ha en vilja att förbättra sin produktutveckling för att lyckas.

4.3.6 Uppföljning av transformationen

Resultatet av den agila transformationen utvärderade Scrum Mastern med team health checks samt mätningar av cykel- och ledtid. Team health checks utfördes genom att team besvarade enkäter om ett antal övergripande parametrar som berörde deras arbete och välmående. En uppfattning om teamens behov synliggjordes så att resurser kunde tillsättas för att uppnå en optimal mjukvaruutveckling.

5. Analys och diskussion

I detta avsnitt analyseras och jämförs resultatet från intervjuundersökningen med litteraturstudien. Vidare diskuteras resultatet av analysen.

5.1 Utmaningar med agil transformation 5.1.1 Olika motiv med agil transformation

Företag B och C uttryckte att förändring måste komma inifrån en organisation eftersom många människor har svårt för förändring. Enligt teori innebär en agil transformation mer rörliga processer för mjukvaruutveckling vilket kräver att mönster och rutiner måste brytas (Gandomani et al., 2013; Nerur et al., 2005). På grund av att arbetsuppgifter förändras med en agil transformation uttryckte samtliga företag att berörda personer behöver bli mer mottagliga för förändring.

Vice VD ansåg att detta var en av anledningarna till att endast en av de fyra agila transformationerna som respondenten genomförde hos andra organisationer lyckades. Motivet i de andra transformationerna var även att ledningen ville få produktivare team utan att ta hänsyn till vad transformationen skulle innebära för organisationen som helhet. En reflektion om varför transformationerna misslyckades är att uppdragen om förändring av arbetssätt kan ha varit på beslut av ledningen utan att medarbetare delade samma vilja. Hos företag A kom motivet däremot från medarbetarna som insåg de möjligheter ett agilt arbetssätt skulle innebära för mjukvaruutvecklingsprocesserna.

Företag A:s utvärdering av deras agila transformation visade att 9 % av företaget inte var nöjda med byte av arbetssätt trots att transformationen accepterats inom företaget. En reflektion kring detta visar att det finns flertalet faktorer så som att transformationens utfall inte bemötte förväntningarna, missnöje med förändring av arbetsroll eller att medarbetare har ett för konservativt tankesätt. Att en agil transformation är accepterad inom ett företag är viktigt men det kräver även ett flexibelt tankesätt.

5.1.2 Agilt är en pågående process

Enligt Fowler & Highsmith (2001) framgår det att agila arbetssätt har fokus på att förenkla och kontinuerligt förbättra mjukvara. Brist på förståelse för att en agil transformation är en pågående förbättringsprocess ansåg Partnern och Vice VD vara ett problem för många företag. Det verkar som att förståelsen för detta är en viktig del i att lyckas med en agil transformation.

5.1.3 Agilt är kompetensberoende

Företag A och C uttryckte problematik med att medlemmar i Scrum Team är specialiserade inom ett specifikt område vilket medför att produktutvecklingen blir lidande om en person i teamet inte längre kan fullfölja sin arbetsuppgift. Enligt Verwijs (2015) är Scrum Team personberoende och ett problem samtliga respondenter anser med det agila arbetssättet är att den agila strukturen kan fallera om en nyckelperson som varit drivande i transformationen slutar.

Genom att analysera detta kan företagens problematik förhindras genom att medlemmar i ett Scrum Team utbildas inom fler områden utöver sina specifika arbetsuppgifter. Lönsamheten för detta beror dock på flertalet faktorer. Om företag bedriver ett kort och mindre komplext projekt kan det vara mer lönsamt att ta in en kompetent person från ett annat team eller en extern person.

Däremot om projektet pågår under flera år och innebär utveckling av ett komplext system kan det istället vara lönsamt att investera i att utbilda team så flera personer besitter kunskap inom ett flertal områden. Om en person slutar kan teamet då fortfarande säkerställa att systemet kan färdigställas och levereras.

5.1.4 Mjukvaruprocesser är komplexa och kräver samverkan

Företag C ansåg att implementering av Scrum Team i en agil transformation ofta innebär svårigheter i kommunikation samt brist på förståelse av varandras arbetsuppgifter.

Mjukvaruprocesser är komplexa, tidskrävande, omfattande och kräver mer samverkan mellan samtliga personer i ett team. Partnern uttryckte att denna omställning i många fall även innebär en produktivitetdipp som kan medföra en försämrad backlog till en början. I sin tur leder den tidskrävande omställningsprocessen då i många fall till att företag börjar suboptimera för att öka backlogens värde.

5.2 Potentiella fördelar med agil transformation 5.2.1 Agilt förbättrar produktutveckling

Enligt Björkholm och Brattberg (2010) genererar en agil transformation en större flexibilitet, färre defekter, en förbättring i teamens produktivitet och möjlighet att delleverera system till kund.

Samtliga företag upplevde dessa fördelar vilket ledde till flertalet förbättringar i mjukvaruutvecklingen. Hos företag A gav det agila arbetssättet färre defekter, snabbare omloppstid och en optimerad kompileringsprocess, där de två sistnämnda skiljer sig mot teorin. Företag B upplevde att ett gemensamt motiv bakom transformationen gav en ökad samverkan då samtliga medarbetare arbetar mer integrerat i utvecklingsprocesserna av ett system.

5.2.2 Agila principer medför en ökad samverkan

Företag C införde agila principer i form av tvärfunktionella utvecklingsteam samt genom att ledningen även tillämpade ett agilt arbetssätt genom att ersätta en projektledare med en produktägare. Hela företaget anammade detta och genom att arbeta i sprintar med gemensamma uppföljningsmöten erhöll medarbetarna en ökad förståelse för varandras arbetsuppgifter. Företag B ansåg även att detta resulterar i att ledningen får ett större förtroende för teamen. En analys av att hela företaget anammade ett agilt arbetssätt visar att sannolikheten för att den agila transformationen blir bestående ökar. Detta beror dels på att ledningen ofta är en del av problemet, som Partnern nämnde.

McDonald (2019) beskriver att självorganiserade och tvärfunktionella utvecklingsteam presterar optimalt. Företag A och C tillämpade detta och ansåg att det möjliggjorde ett mer samverkat arbete för team vilket resulterade i optimering och förbättringar av de olika processerna i mjukvaruutvecklingen. I sin tur medförde detta att system kunde utvecklas på ett så optimalt sätt som möjligt vilket förbättrade produkter.

5.2.3 En agil transformation synliggör brister

Det agila arbetssättet för mjukvaruutveckling innebär att arbeta inkrementellt, utveckla prototyper samt testa delar av system kontinuerligt. Detta möjliggör att delleveranser till användare kan ske för att ge dem möjlighet att testa prototyper och framföra synpunkter (Beck et al., 2001; Cockburn 2002). När företag A genomförde den agila transformationen upptäckte de brister med det föregående arbetssättet. Dessa brister har existerat men inte upptäckts på grund av att delleveranser inte varit möjliga. Det agila arbetssättet medförde en ökad synlighet av problem som även kunde lösas snabbare då företag A arbetade inkrementellt vilket resulterade i en ökad användarnöjdhet enligt Sektionschefen.

5.3 Kännetecken för en lyckad agil transformation 5.3.1 Tydligt motiv till agil transformation

Samtliga företag ansåg att en agil transformation bör ha ett tydligt motiv, ske successivt och komma inifrån organisationen. Detta för att som Nerur et al., (2005) beskriver kräver förändring tillit vilket är en process som sker stegvis med tiden. För att bygga tillit ansåg respondenterna att motivet bakom transformationen behöver vara tydligt så berörda parter förstår varför denna förändring är nödvändig och kan acceptera det. Att motivet kommer inifrån och är en vilja att förbättra organisationens produktutveckling är enligt samtliga företag en betydande faktor för att den agila transformationen ska lyckas.

5.3.2 Anpassat tillvägagångssätt utefter organisationen

En nulägesanalys kan användas för att bestämma vilken nivå av agilitet en organisation är i behov av för att kunna bemöta de utmaningar de står inför (Sharifi & Zhang, 1999). Företag B och C använde sig av en nulägesanalys för att kunna anpassa transformation utefter organisationens produktutveckling och finna ett optimalt agilt arbetssätt. Båda företagen använde även nulägesanalysen för att förstå motivet bakom transformationen och målet med den. Istället för en nulägesanalys insåg företag A behovet av ett nytt arbetssätt och satte upp en tidplan för fem år framåt med konkreta mål. Samtliga företag ansåg att en agil transformation är flexibel och att en form av analys av nuläget är användbart.

5.3.3 Agila konsulter och coacher

Enligt undersökningen genomförd av VersionOne (2017) är agila konsulter och coacher en nyckelfaktor för en framgångsrik agil transformation. Företag A och C anammade detta. Företag A tog hjälp av två externa agila konsulter, organisationscoacher samt en coach som vägledde Vice VD genom hela processen. Företag B ansåg även att en extern agil coach är nödvändig för att få en objektiv bild av företaget inför den agila transformationen.

En reflektion av VersionOnes undersökning (2017) och företagens respons är att även interna agila coacher kan vara en nyckelfaktor. Att använda kompetens som finns inom företaget bör nyttjas då personen har god kännedom om företaget och dess struktur. En annan aspekt av detta är att det finns risk för att personen kan bli partisk och detaljinriktad. Därför kan det vara lämpligt att kombinera en intern agil coach med en extern part som kan se det övergripande, se över organisationens bästa och presentera resultat på ett neutralt sätt.

5.3.4 Implementering av ett gemensamt verktyg

Ytterligare en nyckelfaktor enligt VersionOnes undersökning (2017) är att implementera ett gemensamt verktyg som team kan utnyttja. Partnern införde förändringar som experiment för team, vilket gav möjligheten att testa och återgå till det föregående arbetssättet om resultatet inte blev som önskat. En analys av detta visar att experiment möjliggör att team tillsammans kan testa sig fram till det optimala arbetssättet för utvecklingen av en produkt.

Företag A ansåg att implementering av ett testteam innan beslut om förändring av arbetssätt var ett praktiskt verktyg för transformationen. Detta för att säkerställa att det agila arbetssättet skulle gynna deras produktutveckling. Även användandet av point of no return ansåg företag A vara en nyckelfaktor. En reflektion kring detta är att det även kan vara ett verktyg som team senare skulle kunna tillämpa i deras arbete för att optimera produktutvecklingen.

5.3.5 Applicering av Scrum

Comstedt (2017) anser att utvecklingen av en produkt ska utföras i olika delar genom att teamet arbetar i sprintar om maximalt fyra veckor med en sprintplanering på sprintens första dag. Vidare beskriver Ahmed och Mohammed (2019) att efter en avslutad sprint hålls ett möte för att analysera vilka förbättringar som kan genomföras. Företag C implementerade detta arbetssätt och införde en medvetenhet kring de agila principerna bland de två utvecklingsteamen. Likt teorin arbetade de i tvärfunktionella självorganiserade team som hade organiserade sprintplaneringar. En analys av detta visar på att ett arbete i sprintar med kontinuerliga möten med produktägaren möjliggör för att eventuella defekter och problem som uppstår kan förebyggas kontinuerligt och på så sätt generera bättre processer i mjukvaruutvecklingen.

5.3.6 Storlek på team

Schwaber och Sutherland (2017) anser att tre till nio personer utgör ett idealt utvecklingsteam. Likt Mersino (2017) tillämpade samtliga företag ett Scrum Team på sju plus minus två personer.

Företag A bedömde att storleken på Scrum Team var väsentlig i utvecklingen av en produkt och även företag C som därför delade upp det stora teamet i två Scrum Team med sju plus minus två personer. Genom att analysera detta anses tre personer inte besitta tillräckligt med kompetens för att utgöra ett komplett utvecklingsteam som kan utveckla en produkt. Nio personer kan även anses försvåra kommunikationen och för att undvika att undergrupper bildas inom teamet bör det bestå av ett udda antal personer. Regelbundna möten med kontinuerliga uppföljningar och tydliga kommunikationsflöden kan vara lösningar på kommunikationsproblemet.

5.3.7 Uppföljning av agil transformation

Det finns olika sätt att följa upp den agila transformationen för säkerställning att mål har uppnåtts och att det var rätt beslut att genomföra transformationen. Enligt undersökningen utförd av VersionOne (2017) anses tre utvärderingsparametrar viktiga för att säkerställa att mål har uppnåtts och att det var rätt beslut att genomföra transformationen. Dessa tre är skapat företagsvärde, leverans inom bestämd tid samt en ökad kund- och användarnöjdhet. Däremot anser Janse (2018) att antal defekter i det levererade systemet, ledtid och planerat jämfört med levererat resultatet är tre andra viktiga utvärderingsparametrar.

Företagen använde utvärderingsparametrar från Janse (2018) och VersionOne (2017) för att utvärdera resultatet av transformationen. Företag A uppmätte resultatet av transformationen med ledtid, antal defekter, effektivitet samt medarbetarnöjdhet. Företag B mätte enbart två parametrar som ansågs skapa mervärde för företaget, dessa var den glädje som arbetet ger människor samt hur produktiva de varit i slutet av arbetsdagen. Företag C mätte resultatet med team health checks samt med cykel- och ledtid. Cykeltid definieras som den tid det tar från att en process börjar utvecklas tills det skapar värde (Yorke, 2017). Samtliga företag ansåg att en utvärdering av den agila transformationen är en nyckelfaktor för att säkerställa ett lyckat utfall.

6. Slutsats

Detta avsnitt presenterar studiens slutsats samt förslag på fortsatt arbete inom detta område.

Studiens resultat visar på att en agil transformation för processer i mjukvaruutveckling är komplexa och tidskrävande. Vid en agil transformation påverkas hela organisationen och inte bara en enskild avdelning eller grupp individer. Därför behöver en agil transformation vara accepterad inom hela organisationen och en viktig del för att möjliggöra detta är att berörda parter är mottagliga för ett mer förändringsbenäget arbetssätt.

Det finns risk för att den agila transformationen och det agila arbetssättet blir personberoende. Om transformationen associeras med en nyckelperson som varit drivande genom processen kan det leda till att den inte blir bestående då strukturen fallerar om personen försvinner. Samtidigt innebär ett agilt arbetssätt att samtliga processer i produktutvecklingen beror av varandra. Om en person inte fullföljer sitt arbete kan utvecklingen av produkten därmed bli lidande.

Vidare innebär ett agilt arbetssätt många fördelar och däribland resonerade samtliga företag att en agil transformation medför kortare ledtider, minskat antal defekter, nöjdare medarbetare, ökad produktivitet och mer kompetenta Scrum Team. Dock medför en agil transformation ett mer rörligt och flexibelt arbete vilket gör att agilitet inte passar ett konservativt tankesätt. Samtliga företag ansåg att det är viktigt att förstå att agilt är mer av ett tankesätt än ett arbetssätt. Tankesättet bygger på kommunikation, anpassning till förändring samt tillit och företagens förståelse för detta resulterade i lyckade agila transformationer.

Fortsättningsvis innebär ett agilt arbetssätt en ökad samverkan och kommunikation i teamen men även inom företaget. På så sätt blev insikten och medvetenheten kring arbetsuppgifter större vilket resulterade i en mer integrerad organisation för samtliga företag. Därmed ökade produktiviteten och problemlösningshastigheten vilket resulterade i en ökad användarnöjdhet av produkter.

Att Scrum Teamen bestod av sju plus minus 2 personer var av stor betydelse då det ökade produktiviteten samtidigt som det bidrog till ett mer samverkat arbete. I transformationen tog företagen hjälp av externa agila coacher och konsulter samt implementerade ett gemensamt verktyg för att hjälpa teamen.

Företag B och C använde sig av en nulägesanalys för att kunna implementera ett agilt arbetssätt anpassat till företaget. Det anpassade arbetssättet synliggjorde problem med tidigare arbetsformer och medförde att team kunde arbeta inkrementellt och delleverera system så defekter och problem kunde lösas kontinuerligt.

Företagens uppfattning kring en lyckad agil transformation grundade sig i ett antal nyckelfaktorer.

Ett tydligt motiv till transformationen samt att företaget själv vill förändras anses viktigt då agilitet är svårt att projicera på ett företag som inte är mottagligt för det. Vidare är det viktigt att sätta upp tydliga målsättningar med transformationen i planeringsskedet. Detta för att kunna genomföra en utvärdering av transformationens utfall för att säkerställa att målen uppnåtts och att mjukvaruutvecklingen förbättrats.

6.1 Förslag på fortsatt arbete

Idag finns det många undersökningar kring agila arbetssätt samt potentiella fördelar och utmaningar med en agil transformation. Dock finns det mindre dokumentation kring hur en organisation kan gå tillväga för att implementera ett agilt arbetssätt. Bidraget från detta arbete är en vägledning för organisationer som vill genomföra en agil transformation. Detta arbete begränsas av att endast stora företag i Sverige med fler än 1000 anställda deltagit i intervjuundersökningen.

Att undersöka om en agil transformation har liknande utmaningar och potentiella fördelar i mindre organisationer, för andra branscher och i organisationer lokaliserade utanför Sverige är därför relevant. I ett fortsatt arbete skulle det även vara av intresse att undersöka på ett mer ingående sätt hur mjukvaruutvecklingsprocesser förändras eller påverkas med ett agilt arbetssätt. Även fler aspekter som om en agil transformation är lönsam ur ett ekonomiskt perspektiv skulle vara intressant att undersöka i ett fortsatt arbete.