Produktägare i agila distribuerade projekt

Julia Andreasson och Johana Söderström

Produktägare i agila distribuerade projekt

En studie som identifierar utmaningar och förändringar i

produktägarens arbetssätt

Product owner in agile distributed projects

A study identifying the challenges and changes for a product owner.

D-uppsats

Sammanfattning

It-företag arbetar ständigt i projektform med syfte att effektivisera sitt arbetssätt, utnyttja sina resurser, positionera sig i nya marknader, ge kunden ett bra resultat på kortast möjliga tid och till den längsta kostnaden. Faktorerna utgör ett behov till att distribuera sin verksamhet och därmed sina projekt. På så sätt möjliggörs nya vägar att vidga och uppnå effektivisering i hela företaget. När projekt distribueras, leder det till en stor påverkan i form av utmaningar för utvecklingsteamet men framför allt produktägaren och dennes arbetsuppgifter. Utgångspunkten för magisteruppsatsen är att studera produktägaren på grund av den ses som central i agila distribuerade projekt.

Syftet med magisteruppsatsen är att kunna identifiera olika utmaningar som produktägaren kan uppleva i agila distribuerade projekt. Uppsatsen syftar till att hitta faktorer som kan påverka produktägarens roll när individerna som utför utvecklingsarbete inte sitter tillsammans under utvecklingsperioden.

I undersökningen har ett kvalitativt angreppssätt tillämpats. Studien består av personliga intervjuer med personer som har produktägarroll i sina projekt samt forskare inom agila metoder. Utifrån intervjuerna och tillsammans med insamlad teori har utmaningar och faktorer som kan påverka produktägarens arbetssätt identifierats.

Produktägaren bemöter utmaningar som kommunikation, kulturella skillnader, tidsskillnader, ordning och struktur samt geografiskt avstånd, är de tydligaste resultaten som magisteruppsats har tagit fram. Utmaningarna är sammankopplade med varandra eftersom de ena leder till de andra. Projektdeltagarna sitter inte på samma plats, det leder till att faktorer som språk, förtroende och tillit, den informella och formella kommunikation, arbetssynkronisering, tidszoner, tid och resor kan minska produktiviteten och effektiviteten i projekt. Därför är det viktigt för produktägaren och hela utvecklingsteamet att kunna hitta lösningar, som kan underlätta utvecklingsarbetet i distribuerade projekt.

Det har även identifierats att produktägare har samma typ av uppgifter oberoende typ av projekt. Däremot utgör spridningen i projektet ändringar i hur arbetsuppgifter genomförs, med syfte att kunna tillhandahålla utvecklingsteamet bättre underlag för genomförande av utvecklingsarbetet.

Abstract

IT companies are constantly working on a project basis with a view to

streamlining their work methods, use of resources, position themselves in new markets, and provide the customer with a good result in the shortest possible time and at the least cost. Such factors constitute a need to distribute their business and thus their projects. In this way, made possible new ways to expand and achieve efficiency across the enterprise. When the project is distributed, it leads to a big impact in terms of challenges to the project team but above all the product owner and his or her duties. It is because of this role is considered as a key in agile distributed projects. One such effect is the starting point of this master's thesis. The purpose of this master's thesis in Project Management is to identify the various challenges that the product owner can experience in agile distributed projects. The thesis aims to find factors that can affect the product owner role in individuals who carry out development work can not sit together during the development period.

In this study, a qualitative approach has been applied. The study consists of personal interviews with people who have the product owner role in their projects and researchers in agile methods. Based on these interviews, along with the collected theory, the challenges and factors that may affect the product owner's approach identified.

The most obvious result that emerged from this investigation is that the product owner in addition to managing challenges such as communication, cultural

differences, time differences, order and structure as well as geographical distance, is the product owner and agile methods and concepts, two important challenges to deal with. The challenges are connected with each other because the one leads to the other. That project participants are not sitting in the same spot, leading to factors such as language, confidence and trust, informal and formal

communication, labor synchronization, time zones, time and travel may reduce the productivity and efficiency of project. Therefore it is important for the product owner and the whole project team over the team be able to find handling

solutions, which can facilitate the development of distributed projects. This study has also been able to identify that despite the proliferation of the project, the product owner's duties same as a non-distributed projects. In contrast, altered the way to perform tasks in order to provide the development team better basis for execution of development.

Förord

Vi vill börja med och tack alla våra respondenter för deras bidrag till

magisteruppsatsen. Utan deras bidrag hade utförandet av uppsatsen inte varit möjlig. Vi vill även fortsätta tacka vår handledare Per Strömgren som ställt upp för oss genom hela uppsatsperioden. Vi själva har haft utmaningar att hantera under skrivande processen och Per har alltid gett oss snabba svar och bra feedback som gjort att vi kunnat gå hela vägen in i mål.

Uppsatsen har skrivits tillsammans av båda författarna och har inte delats upp. Vi har under hela processen diskuterat fram olika tillvägagångssätt som lett till detta färdiga resultat.

Sist men inte minst vill vi tacka varandra för ett fantastiskt bra samarbete genom hela uppsatsen perioden. Det har varit många dagar som vi arbetat i skift med många tunga utmaningar att ta itu med. Vi är båda stolta över resultatet och hoppas att du som läsare ska tycka det också.

Innehållsförteckning 1 Inledning ... 1 1.1 Problembakgrund ... 1 1.2 Syfte ... 2 1.3 Målgrupp ... 2 1.4 Avgränsningar ... 3 2 Metod ... 4 2.1 Val av ämnet ... 4 2.2 Vetenskapligt angreppssätt... 4 2.3 Datainsamling ... 6

2.4 Kunskapsbidrag och dess generalisering ... 7

2.5 Trovärdighet ... 8

2.6 Forskningsetiska principer ... 9

2.7 Val av respondenter ... 9

3 Teori ... 11

3.1 Agila metoder ... 11

3.2 Fördelar och nackdelar med agila metoder ... 16

3.3 Scrum ... 18

3.4 Sammanfattning av agila metoder ... 26

3.5 Distribuerade projekt ... 26

3.6 Scrum i distribuerade projekt ... 28

3.7 Utmaningar med Scrum i distribuerade projekt ... 30

3.8 Sammanfattning av distribuerade projekt ... 36

3.9 Analysmodell ... 37

4 Empiri ... 41

4.1 Forskare inom agil projektledning ... 41

4.2 Sammanfattning forskare ... 44

4.3 Produktägare i distribuerade projekt ... 45

4.4 Sammanfattning respondenter ... 52

5 Analys ... 54

5.1 Kommunikation ... 55

5.2 Ordning och struktur ... 57

5.4 Tidsskillnader ... 59

5.5 Geografiskt avståndet ... 61

5.6 Utmaningar som författarna påträffat. ... 64

5.7 Sammanfattning av utmaningar i distribuerade projekt ... 65

5.8 Produktägarens arbetssätt ... 66

5.9 Sammanfattning av produktägarens arbetssätt ... 69

6 Slutsatser ... 70

6.1 Utmaningar identifierade i tidigare studier ... 70

6.2 Utmaningar identifierade av uppsatsens författare ... 72

6.3 Förändringar i produktägarens arbetssätt ... 73

7 Fortsatt forskning... 75

Bilagor ... 84

Figurförteckning Figur 1: Agila metoders ståndpunkter. Källa: Agile Manifesto (2011) ... 12

Figur 3: The Scrum framework. Källa: Sverringsdottir et al.. (2014) ... 18

Figur 4: Analysmodell Källa: Författarna ... 38

Figur 5: Analysmodell Källa: Författarna ... 54

1 Inledning

Kapitlet börjar med en presentation av problembakgrunden. Vidare

presenteras syftet med undersökningen. Därefter redovisas målgruppen som uppsatsen riktar sig till samt vilka avgränsningar som gjorts för

undersökningen.

1.1 Problembakgrund

Eftersom företag står inför ständiga förändringar och samtidigt strävar efter att hitta anpassningar efter dagens marknad, finns det ett behov av att tillämpa nya sätt att arbeta med syfte att leverera varor och tjänster och därmed tillfredsställa sina kunder. Behovet kring effektivisering och anpassning av sitt arbetssätt för att tillfredsställa kunden, är en faktor som företag idag dagligen arbetar med.

Projektarbetsform kan vara en lösning för företag där det strävas efter ett resultat med hänsyn till budget och tid (Larsson 1995). Med andra ord, en organisation utför flera projekt samtidigt för att effektivisera sina arbetsuppgifter genom att de sker samtidigt. För att resultatet ska bli så optimalt som möjligt sker

arbetsuppgifter i projekt parallellt, viket innebär att olika aktiviteter sker

samtidigt. Därför är det mer angeläget för företag som ständigt arbetar i projekt att använda sig av agila projektledningsmetoder.

Metoderna tillhandahåller en stor flexibilitet och anpassning i komplexa projekt. Eftersom det handlar om att arbeta agilt, anser Sutherland och Schwabber (2011) att utvecklingsteamet i projekten ska vara fem till nio personer. Det för att underlätta projektets kommunikation, interaktion och förståelse mellan

individerna som planerar och genomför arbetsuppgifter. En ledande beståndsdel i agila metoder är att utvecklingsteamet ska befinna sig på samma plats. Sutherland och Schwabber (2011) menar att utvecklingsteamet ska kunna arbeta tätt

tillsammans och skapa en samhörighet mellan varandra och därmed uppnå bästa möjliga resultat.

Jacobsen och Thorsvik (2002) påpekar att stora förändringar har pågått i

arbetslivet för dagens företag de senaste åren. En av de förändringarna handlar om att arbetsuppgifterna som genomfördes i projektform, distribuerades.

Utvecklingsarbetet under projektets gång genomförs av individer som befinner sig spridda på olika ställen. Utvecklingsteamet gör användning av digitala verktyg för att kunna kommunicera och interagera med varandra. Spridningen kallas för distribuerade projekt som kan vara lokalt och globalt (Paasivaara et al. 2012). Enligt Walsman (2001)är distribuerat arbete något som blir allt mer vanligare idag.

processen. För att kunden ska kunna säga sitt och ha en aktiv deltagande under utvecklingsarbetet, utsätts en roll i projektet benämnd produktägare, på grund av att det är en central kommunikationsfaktorn mellan kundens behov och det som utvecklingsteamet utför.

Distribuerade projekt kan medföra problematik när det gäller involveringen av produktägaren i projekt, på grund av att deltagarna i utvecklingsteamet inte sitter tillsammans. Produktägaren är den personen i ett agilt projekt som ska fungera som mellanhand mellan kunden och utvecklingsteamet. Den ska också fungera som ansvarig för att formulera alla krav som hör till projektet. Produktägaren får nya utmaningar när projekten distribueras, vilket leder till förändring i dennes arbetssätt (Bass 2012). Det gäller att hitta och vara medveten om utmaningarna som kan uppstå. Det kan leda till bättre resultat i utvecklingsarbetet och därmed bättre kundtillfredsställelse. Det finns redan nu tydliga mönster och identifierade utmaningar som kan upplevas med agila distribuerade projekt. Eftersom

produktägaren spelar en viktig roll i hela utvecklingsarbetet, är det kritiskt att identifiera hur rollen kan påverkas och urskilja mer konkret vilka utmaningar som faktiskt uppstår.

1.2 Syfte

Syftet med magisteruppsatsen är att kunna identifiera olika utmaningar som produktägaren kan genomgå i agila distribuerade projekt. Uppsatsen syftar till att ge exempel på faktorer som kan påverka produktägarens roll när individerna som utför utvecklingsarbete inte kan sitta tillsammans under utvecklingsperioden. Syftet med undersökningen har möjliggjorts genom besvarande av följande forskningsfrågor:

 Ställs produktägaren inför några utmaningar när projekt distribueras? Uppsatsen berör också följande fråga.

 Förändras produktägarens arbete när projekt distribueras? 1.3 Målgrupp

Studie är ägnad till att underlätta för företag som idag använder agila arbetssätt och vill skapa distribuerade projekt. Undersökningen kan också användas som underlag vid beslut och därmed avgöra om företag väljer att distribuera sina projekt eller inte. Fokus ligger på produktägaren och dennes roll i projektet. Det kan också underlätta för personer med en produktägarbefattning i företaget. Det är menat att studien även kan underlätta för utvecklingsteamets medlemmar,

eftersom deltagarna kan dra lärdomar om hur deras roll i de distribuerade

1.4 Avgränsningar

Det finns flera faktorer som magisteruppsatsen inte kommer att beröra. Därför görs det fyra olika typer av avgränsningar i undersökningen. Den första

avgränsningen handlar om att enbart fokusera på produktägarens roll och hur den kan påverkas i ett agilt distribuerat projekt. Studien förhåller sig till att studera om produktägaren upplever några utmaningar när projekt distribueras.

Undersökningen avser även att kunna fastställa om produktägarens

arbetsuppgifter förändras när projektet består av människor på flera olika platser. Det grundas på att tidigare forskning har studerat hur projektresultatet påverkas i spridda projekt. Produktägarens roll är central för hela projektet och är en

grundpelare inte bara för utvecklingsteamet utan också för hela projektets fortsatta utveckling.

Den andra avgränsningen som magisteruppsats gör, är att bara fokusera på att hitta respondenter som tillhör branschen. Orsaken ligger i att det är inom IT-branschen som agila metoder används mest. På så sätt kan det studeras om människor som arbetar med mjukvaruutvecklingsprojekt har olika utmaningar att hantera i distribuerade projekt. Det är IT-företag som på senare år har distribuerat sina mjukvaruutvecklingsprojekt.

2 Metod

Kapitlet inleds med en beskrivning om varför ämnet som behandlas i

undersökningen valdes. Det finns också en redovisning av det vetenskapliga angreppssätt som tillämpas för att genomföra studien. Därefter beskrivs vilket undersökningsupplägg som valts samt hur datainsamlingen gått till. Vidare beskrivs innebörden av kunskapande och vilka kunskapsbidrag som

magisteruppsats förväntas ge samt hur det är tänkt att uppnå hög trovärdighet genom reliabilitet och validitet. Dessutom ges en beskrivning av vilka

forskningsetiska principer som magisteruppsatsen uppfyller samt att en introduktion till de respondenterna som deltagit i undersökningen ges.

2.1 Val av ämnet

Författarna till magisteruppsatsen har båda en IT bakgrund, det var därför de kändes naturligt att skriva en uppsats med fokus på agil projektledning. Dels för att den är som störst inom IT-branschen, men också för att båda vill fördjupa sig inom området. Svårigheten har varit att skala ner ämnet till agil projektledning för att hitta ett ämne som passade bäst. Diskussioner om olika tänkbara

frågeställningar och områden har förts mellan författarna och slutresultatet blev att fokusera på produktägarens roll i distribuerade projekt.

Företag väljer att distribuera sina projekt på senare tid och dessutom att tillämpa agila metoder till dess genomförande. Det utgör en utgångspunkt i

undersökningen. Produktägaren spelar en viktig roll i användningen av agila metoder. Rollen är också viktig inom Scrum för ett bättre resultat i projekt (Sutherland & Schwaber 2011). På grund av vikten som produktägaren spelar i agila projekt anses magisteruppsatsen vara en väg att upptäcka och studera vilka typer av utmaningar som rollen kan genomgå i agila distribuerade projekt.

Författarna av uppsatsen vill också fokusera på produktägaren och se om det sker någon förändring av dennes arbetsuppgifter.

2.2 Vetenskapligt angreppssätt

Genomförande av vetenskaplig forskning kan utföras utifrån två olika perspektiv kvalitativt och kvantitativt. Båda perspektiven har för syfte att analysera, behandla och utvärdera insamlade data och information. När forskaren tar sitt beslut om vilket perspektiv som ska appliceras i forskningen, ska denne utgå från vilket problemområde och vilket syfte undersökningen kommer att uppfylla. (Patel & Davidsson 2003; Olsson & Sörensen 2011).

utifrånperspektiv. Det betyder att relationen mellan de deltagande individerna och själva forskaren tenderar att ha ett visst avstånd.

I magisteruppsatsen tillämpas kvalitativa metoder för att kunna besvara studiens forskningsfråga. Grunden till valet ligger i att identifiera de utmaningar som produktägaren genomgår i distribuerade projekt, och därmed möjliggöra en medvetenhet i planeringen av arbetet. Undersökningen har ett specifikt syfte där det inte finns för avsikt att genomföra mätningar av den valda företeelsen. Det kvalitativa angreppssättet möjliggör för magisteruppsatsen att utföra tolkningar som leder till en analys och en bättre förståelse för vilka tänkbara utmaningar som en produktägare kan genomgå i distribuerade projekt. Därför finns en fördjupning av olika datainsamlingar som består av teori, empiri och en analys.

Kvalitativa metoder grundar sig i att tolka värdet i kunskapsinsamlingen. Därför anses det att metoden är mest lämplig för de valda forskningsområdet. Det på grund av att syftet är att ge exempel på de utmaningar som en produktägare upplever i agila distribuerade projekt. En sådan information framkommer bättre genom de upplevelser och erfarenheter som de deltagande personerna delar i genomförda intervjuer.

Kunskapsgenerering

När en forskare bestämmer sig för att göra en studie syftar han eller hon till att kunna generera kunskap inom det valda forskningsområdet. Det leder till att samla in data och information, som är komponenter till det som kallas för empiri.

Avsikten är att ta fram en så bra bild av verkligheten som möjligt. Forskaren genererar därmed kunskap genom att hitta ett samband mellan teori och empiri. Enligt Patel och Davidsson (2003) kan det möjliggöras genom deduktion, induktion och abduktion.

Patel och Davidsson (2003) redovisar att genom användandet av deduktion i forskning, dras slutsatser av ett studerat fenomen utifrån teori. Resultatet som kommer från slutsatserna testas vidare empiriskt. Sättet att arbeta tillhandahåller en objektivitet i studien, författarna menar att forskarens uppfattningar påverkar mindre själva arbetet (ibid). Däremot, kan det också förekomma att tidigare studier kan påverka forskarens uppfattningar och därmed skapa situationer där ny intressant kunskap kan missas. Tillämpning av ett induktivt arbetssätt betyder att gå från enskilda iakttagelser till mer generella omdömen. Empiriska data används för att generera nya teorier (Patel & Davidsson 2003). Med andra ord, information samlas in för analys för att sedan dra en slutsats. Författarna redovisar att

abduktion är en processinriktad ansats som tillåter för nya iakttagelser under arbetets gång.

arbetssättet betyder att det har gjorts olika kompletteringar med relevant information i teorikapitlet under uppsatsprocessen. Det abduktiva arbetssättet förekommer eftersom slutsatserna som dras i magisteruppsatsen grundar sig från analysen.

2.3 Datainsamling

Genomförande av magisteruppsatsen har blivit möjligt genom insamling, analysering och bearbetning av primär och sekundärdata.

Primärdata samlar forskaren själv in genom intervjuer, observationer och enkäter (Andersen 2012). Författaren beskriver att i en personlig intervju har intervjuaren direktkontakt med respondenten, vilket ger större möjlighet till kommunikation och återkoppling. Undersökningen använder personliga intervjuer som

primärdata, på grund av att intervjuerna kan tillhandahålla möjligheten att få olika synvinklar av det valda studerade fenomenet. En annan anledning till att använda personliga intervjuer, grundades i att tidigare forskning har använt kvantitativa metoder där intervjuer har haft en tongivande effekt. Intervjuerna har skett med sammanlagt sex respondenter.

Varje intervju har spelats in för att senare kunnat komplettera egna anteckningar. På så vis har fokus varit på respondentens berättelse, utan risk för att missa viktig information. I första hand kontaktades en person på företaget via e-mail. En förfrågan skickades om det fanns personer på organisationen som hade kriterierna som uppfyllde undersökningens syfte samt deras vilja att kunna ställa upp på en intervju. När en bekräftelse om vilka personer som skulle ställa upp som

respondenter, kontaktades dem via telefon för att komma överens om hur intervjuprocessen skulle gå tillväga. Under samtalet förklarades faktorer som anonymitet, att samtalet skulle spelas in samt syftet med undersökningen. Primärdata som samlats in i undersökningen ligger till grund för empirikapitlet. Sekundärdata samlats in genom andra personer, institutioner och liknande i form av litteratur, dokument, register, tidningsartiklar och liknande (Andersen 2012). Sekundärdata samlades in främst genom vetenskapliga artiklar som behandlar relevant information inom det valda forskningsområdet. Det har också gjorts en användning av fallstudier och andra uppsatser som har hittats med hjälp av olika databaser. Teorikapitlet grundar sig på insamlad sekundärdata.

Källkritik

För att undersökningar ska ha en bättre validitet och mindre felaktigheter gällande information ska alla sekundära källor analyseras. Vilket innebär att det samlade materialet ska granskas genom ett kritiskt förhållningssätt. I processen ingår faktorer som när och var informationen publicerades, deras syfte och under vilka typer av omständigheter (Patel & Davidsson 2003). Även att undersöka vem författaren till informationen är, kan utgöra om fakta är bra eller inte.

Undersökningen har strävat efter att vara källkritisk genom verkställande av olika jämförelser mellan källor med liknande information om ämnet. Det utgör en högre sannolikhet till att informationen stämmer överens och därmed en högre

Bearbetning av primärdata

Eftersom intervjuerna som utförs enligt en kvalitativ metod, fungerar den som en grund för att påbörja analysarbetet. Den insamlade data måste passa in analysen, på grund av att det skapar bättre förutsättningar till att uppfylla och besvara syftet med undersökningen. Lantz (2013) redovisar att det går att få en bättre förståelse av den information som framkommer med intervjuer. Forskaren måste reducera informations mängd och enbart ta hänsyn till det som är relevant för

undersökningens syfte och frågeställning.

För att kunna säkerställa att bara relevant information framkommer i

undersökningen har de inspelade intervjuerna lyssnats igenom och transkriberats. Det betyder att bara data som inte kunde uppfylla syftet med magisteruppsatsen har lämnats kvar. En annan faktor som har tagits hänsyn till i presentationen av empirikapitlet, handlar om att informationen som ansågs inneha känslomässig karaktär valdes att inte ta med i undersökningen. När det empiriska kapitlet blev klart utfördes det en jämförelse med transkriberade data från intervjuerna. Det med syfte att kunna kontrollera att informationen har behållit sin ursprungliga innebörd. En sammanfattning av respondenternas tanker och idéer presenteras i slutet av det empiriska kapitlet.

2.4 Kunskapsbidrag och dess generalisering

För att kunna genomföra en forskningsstudie, finns det ett behov att kunna samla in material som kan stärka innehållet i studien. Materialet bestäms utifrån syftet med studien och vilket tillvägagångssätt som ska tillämpas (Patel & Davidsson 2003). En avgörande faktor i insamlandet, rör hur mycket kunskap forskaren har inom ämnet men också vilken typ av kunskap det är menat att generera med studien (Ibid). Det kan betyda att innan en kunskapsgenereringsprocess kan börja, bör forskaren ha en medvetenhet om att det finns olika typer av kunskap som en undersökning kan generera. Goldkuhl (2011) redovisar att det finns olika typer av kunskap: kategorisk kunskap, förklaringskunskap och vägledande kunskap. Forskningsfrågan i magisteruppsatsen har grundat sig i att ge exempel på olika faktorer som leder till ett förändrat tillstånd. Undersökningen tillhandahåller en kategorisk kunskap samt en förklarings kunskap. Den kategoriska handlar om att beskriva egenskaper hos en studerad företeelse, medan förklaringskunskap beskriver orsak-effektsamband, grunder eller förutsättningar för något (Patel & Davidsson 2003). Magisteruppsatsen framställer den kategoriska kunskapen genom beskrivning av olika begrepp distribuerade projekt, agil projektledning eller Scrum. Förklarings kunskap framkommer genom en redovisning av olika faktorer som ingår i de beskrivande begreppen.

En tongivande faktor som kan påverka kunskapsbidragets trovärdighet handlar om dess generaliserbarhet. Patel och Davidson (2003) redovisar att generaliseringen ses som en produkt som framkommer av en studie och hur ett visst fall har valts ut, men också om resultatet berör andra än deltagande i själva studien. Eftersom magisteruppsatsen innehåller slutsatser kan kunskapsbidraget vidarebefordras till dels de deltagande i själva undersökningen men också till andra.

Det finns en tydligare förståelse om exempel på utmaningarna som produktägaren upplever med spridda projekt. Eftersom produktägarna redan nu upptäckt

svårigheter, kan det hittas anpassningar i arbetssätten. Anpassningarna efter projektets situation kan ge ett mer balanserat utvecklingsarbete, på grund av det finns en vetskap om utmaningar som förekommer med distribuerade projekt. Kunskapsbidraget kan också underlätta för olika företag att välja att distribuera sina projekt. Det kan även förbereda individerna som ska arbeta i projektet genom en förståelse kring problem som kan uppstå, vilket gör att individerna kan planera sin arbetsbörda och inställning. Om individerna inte tidigare arbetat enligt de agila metoderna, tillhandahåller kunskapsbidraget en inblick hur arbetet fungerar och eventuellt förändras. Informationen som har samlats in till det empiriska kapitlet kommer från olika företag och forskare.

2.5 Trovärdighet

Goldkuhl (2011) redovisar att forskaren bör sträva efter att uppnå trovärdig kunskap vid kunskapsutveckling. Det betyder att läsaren inte ska ha några anledningar till att misstro undersökningens resultat. Därför är det viktigt att kunna hitta vägen till reliabilitet och validitet (Ibid)

Med reliabilitet menas det sättet hur forskaren gör olika mätningar för data bearbetning. Det är menat att en undersökning ska inneha så pålitlig data som möjligt för att leda till testning av frågeställningar i forskningsprocessen (Holme & Solvang 1997). I magisteruppsatsen har det sekundära data som relateras till ämnet i form av vetenskapliga artiklar, uppsatser och fallstudier kritiskt studerats. Det genom att enbart använda liknande relevans för det valda forsknings område. En sådan process har genomförts med syfte att öka trovärdigheten i

undersökningen.

En annan åtgärd för att säkerställa en hög trovärdighet som möjligt, handlande om att ställa olika författare mot varandra och därmed ge utrymme till mer pålitlig data och öka reliabiliteten i magisteruppsatsen. När det gäller primärdata, tillämpades det en användning av en pilotintervju innan olika respondenter intervjuades. Det kunde möjliggöra en vetskap om att frågorna som

intervjuguiden innehåller. Intervjuerna som används som empiriskt data i undersökningen har spelats in. Det har gett möjligheten att kunna lyssna om den insamlade informationen och därmed säkerställa att den är korrekt uppfattad. Det gör att pålitligt data kan erhållas.

2.6 Forskningsetiska principer

Vetenskapsrådet (2002) har kommit fram till fyra etiska principer som de rekommenderar att beakta vid forskning. De krav som tagits fram är informationskravet, samtyckeskravet, konfidentialitetskravet samt nyttjandekravet.

1. Informationskravet innebär att forskaren ska upplysa de berörda deltagarna om vad syftet med undersökningen är, samt vilka villkor och uppgifter som gäller för dem. I undersökningen har de krav säkerställts genom att beskriva studiens syfte samt en förklaring till att deras deltagande är frivilligt möjligheten att välja vara anonyma och att de kan avbryta sitt deltagande när som helst. Samma information utgavs innan själva intervjuerna ägde rum (ibid).

2. Det andra kravet från Verksamhetsrådet (2002) är samtyckeskravet. Det innebär att de berörda deltagarna har full rättighet att bestämma över sitt deltagande. Det kunde säkerställas genom att fråga om deras godkännande att intervjuerna spelades in. Respondenterna blev informerade om att frågorna som kunde kännas som känsliga, behövdes inte besvaras om de inte ville.

3. Det tredje kravet är konfidentialitetskravet vilket innebär att uppgifterna om deltagarna kan vara konfidentiella. Alla respondenter tillfrågades om deras vilja att vara anonym eller inte. Samtliga godkände att använda deras namn som referens i undersökningen.

4. Det sista kravet nyttjandekravet handlar om att materialet som samlats in från respondenterna endast får användas till undersökningens syfte. Eftersom informationen som samlades in genom intervjuerna har används enbart för att fylla undersökningens syfte har kravet kunnat uppfyllas. 2.7 Val av respondenter

Magisteruppsats behandlar utmaningar en produktägare kan genomgå i

distribuerade agila projekt. Därför valdes det att fokusera på att hitta respondenter som hade en liknade typ av roll. Eftersom det är vanligt inom IT-branschen att arbeta med agil projektledning, och att det är inom mjukvaruutveckling som projekt distribueras för det mesta, utfördes intervjuer med olika respondenter som tillhör IT-branschen. Valet av respondenterna grundar sig i att det har funnits bättre förutsättningar till att uppfylla syftet med undersökningen. De personerna innehar olika kunskaper och erfarenheter om ämnet, vilket passade till

undersökningens forskningsfrågan.

Det empiriska kapitlet innehåller data som insamlades från fyra olika respondenter som har rollen som produktägare i agila distribuerade projekt. Det handlar om företag som har kontor på olika orter i Sverige men också utomlands. Företagen tillhandahåller IT-tjänster och systemutveckling. Respondenterna tillhör Ninetech, Redpill Linpro, Tieto och Altran. Projekten som de beskriver har olika natur, komplexitet och förutsättningar. Däremot har samtliga den gemensamma

nämnaren att alla projekt har genomförts genom tillämpning eller anpassningar av agila metoder. Deras utvecklingsteam har befunnit sig spridda när

Ett sätt som användes för att knyta ihop säcken och därmed stärka trovärdigheten ännu mer i det empiriska kapitlet handlar om två utförda intervjuer till.

Respondenterna tillhör inget företag inom IT-branschen utan en doktor och en lärare vid Karlstad Universitet inom agil projektledning. Tomas Gustavsson och Tomas Jansson har bidragit med sitt forskningsperspektiv för att få en mer öppen synvinkel om de utmaningarna som en produktägare kan genomgå i agila

3 Teori

Det tredje kapitlet är ett teoretiskt kapitel i vilket en introduktion och innebörden av agil projektledning ges. Eftersom Scrum är den agila metod som

magisteruppsatsen fokuserar mest på presenterar kapitlet en redogörelse om hur metoden fungerar. Vidare introduceras vad distribuerade projekt står för något och hur arbetssättet tillämpar sig. Kapitlet avslutas med en presentation av en analysmodell som kommer ligga till grund för analyskapitlet.

3.1 Agila metoder

Ett företag står oftast inför nya behov att effektivisera arbetssätt med syfte att erbjuda sina kunder bästa möjliga produkter och tjänster. Det leder till att hitta och tillämpa en användning av olika strukturer på nya sätt eller hitta helt nya arbetssätt att arbeta (Edvardsson et al. 2011). Företag genomför olika typer av projekt som innehåller komplexa arbetsaktiviteter för att nå ett resultat. Komplexiteten har kunnat minskas genom att använda sig av nya sätt att arbeta som finns inom agil projektledning.

Det är inom mjukvaruutveckling som agil projektledning är mest vanlig. Agila metoder innebär att utvecklingsteamet utgår från ett sekventiellt sätt att utföra arbetet till ett mer parallellt arbetssätt. Avison och Fitzgerald (2006) kallar det för evolutionär systemutveckling där det byggs en inkrementell och iterativ

utveckling, något som Gulliksen och Göransson (2002) håller med om. Med andra ord så sker arbetsaktiviteter successivt. Med inkrementell menar författarna att

utvecklingsarbetet börjar med de viktigaste funktionerna och sedan lägger till mindre centrala funktioner i tur och ordning. Åt andra hållet, med iterativ systemutveckling menas att det snabbt byggs ett körbart system som sedan ersätts med förbättrade versioner ”iterationer” tills systemet fungerar som det ska.

En av de största fördelarna som tillämpningen av agila metoder medför handlar om att de ger utrymme för en bättre anpassning vilket leder till förändrade

situationer (Kosh 2005). Författaren menar att metoderna genom anpassningen de tillhandahåller, möjliggör för utvecklingsteamet att inte förlora balans och fokus på grund av att det finns en väg mot rätt riktning. Fokus med agila metoder ligger inte i att göra en leverans av ett helt komplett system, utan att leverera delar av resultatet under utvecklingsarbetet. Det kan utgöra en identifiering av nödvändiga förändringar och hitta åtgärder och lösningar som kan leda till bättre resultat (Gould et al. 1997).

En aspekt som särskiljer de agila metoderna från de traditionella handlar om en erkännande av utvecklingsteamet som en framgångsfaktor för att kunna utföra projektarbetet. Aspekt har paras ihop med en intensiv effektivitet och

Figur 1: Agila metoders ståndpunkter. Källa: Agile Manifesto (2011)

Punkterna till högre har en högre värdering så länge det finns en värdering i punkterna till höger. Värderingarna innebär att inom agila metoder är det viktigt att följa processer och verktyg. Däremot är det mer gynnsamt att under projektets gång, lägga fokus på individerna som utför utvecklingsarbete och hur dem bäst kan interagera med varandra (Agile Manifesto 2011). Den andra ståndpunkten vill poängtera att det är viktigt med att dokumentera hur arbetsprocesser och

aktiviteter utförs under projektets gång.

Det är mer fördelaktigt att kunna utveckla ett system som är användbart för sina användare. Agile Manifesto (2011) hänvisar att kunden är en viktig faktor under hela utvecklingsprocessen. Det måste finnas riktlinjer mellan kunden och övriga parter som ligger till grund om hur arbetet ska gå tillväga. Det föredras att kunden istället ska fungera som en aktiv aktör i utvecklingsarbete. Den sista ståndpunkten innebär att utvecklingsteamet ska följa planer som kan möjliggöra en bättre bild över hela projektet men att det ska finnas utrymme att kunna bearbeta

förändringar som förekommer under arbetsgång (ibid).

Den agila manifest bygger också på olika principer som agila metoderna följer. Principerna kan redovisas som följande:

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

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

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

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

 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.

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

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

 Agila metoder verkar för uthållighet. Sponsorer, utvecklare och användare ska kunna hålla jämn utvecklings takt under obegränsad tid.

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

 Med jämna mellanrum reflekterar utvecklingsteamet över hur det kan bli mer effektivt och justerar sitt beteende därefter. (Agile Manifesto 2001) Tänkesättet som innefattas i agila metoder tillämpas på olika sätt i projekt. Kosh (2005) redovisar att projekt med agilt tänkesätt innehåller egenskaper som iterativ, självorganiserade, inkrementell och framåtsträvande. Bohem och Turner (2003) redovisar samtidigt att en annan generell egenskap som alla agila metoder innehar. Det handlar om att kunden deltar under hela utvecklingsprocessen som en aktiv aktör genom korta interaktioner. Kundens deltagande rör uppgifter som upprätta, prioritera och verifiera krav. Bland de metoderna som ingår i ett agilt tänkesätt redovisas att ramverket Scrum är en bland de vanligaste som tillämpas i

mjukvaruutveckling. Scrum förklaras i ett eget avsnitt senare i kapitlet. Det finns också andra metoder som beskrivs enligt följande:

Feature Driven Development (FDD)

Metoden är avsedd för användning i projekt med stora team. Det är en

objektorienterad teknik som präglas i FDD och tillhandahåller riktlinjer om vilka uppgifter som bör göras och vilka roller som bör utföra dem (Macdonald 2015) Fokusering av metoden ligger på kommunikationen mellan individerna i projektet och sättet de planerar, genomför och analyserar sina arbetsuppgifter. Metoden väljer också att blanda in intressenter utanför utvecklingsteamet, även kunden och användare för att på så sätt klara av att arbeta i stora utvecklingsteam (Jansson 2015).

Adaptive Software Development (ASD)

Adaptive Software development (ASD) är en designprincip som använder sig av ett snabbare sätt skapa och utveckla programvarusystem. Det är en designprincip för att skapa mjukvarusystem. Dess tillämpning fokuserar mer på själva

programmeringsspråket istället för planering av programmet. Det på grund av att utvecklarna redan har en grundtanke om hur arbetet går till (McGee 2013).

Dynamic System Delevopment Method

DSDMs grundtanke ligger i att utföra en kontinuerlig brukarmedverkan. I dess användning förekommer iterativa prototyper som utförs under hela

utvecklingsprocessen. Processen är lyhörd för krav förändringar men säkerställer en formell kvalité i ledningssystemet (Norfolk 2011).

Xtreme Programming

Metoden är uppbyggt på olika värderingar för mjukvaruutveckling. Värderingarna är enkelhet, kommunikation, återkoppling, mod och respekt. Det finns ett tjugotal tekniker som ska uppfylla värderingarna. Principerna handlar om hur arbetet ska fungera och tillämpas (Jansson 2015). Hela projektets team är involverad under hela utvecklingsprocessen. Genom en ständig återkoppling och användning av enkla metoder kan utvecklingsteamet enkelt och snabbt uppskatta hur arbetet går. Det innebär därmed möjligheter att kunna göra anpassningar till precis den

Lean Software Development

Principen utvecklades av Toyota och förekommer från Lean Manufakturing. Tanken bakom metoden är att det ska fungera som ett mått som hänger ihop med begreppet “precis i tid”. Metoden används för att synliggöra utvecklingsarbetet under hela processen och därmed kunna göra observationer om hur slutförande av en pågående aktivitet utförs under tiden (Waters 2010)

Kanban

Den agila modellen Kanban har sitt ursprung i Lean och fokuserar på hur utvecklingsteamet ska effektivisera arbetsflödet av uppgifter. Här väljer

deltagarna att fokusera på att behoven ska styra arbetsprocessen inte kapaciteten. Det gäller att hantera flera arbetsuppgifter samtidigt och hur dem ska analyserar, testas och kodas. Att göra klar en av de pågående aktiviteterna innan nästa påbörjas är något som är väldigt viktigt i Kanban (Jansson 2015).

Scrum

Amerikanerna Jeff Sutherland och Ken Schwaber grundade Scrum 1995. Det är en metod som fokuserar på om vad som kommer att utvecklas under

utvecklingsperioden. Schwaber anser att Scrum inte är en metod i sig, utan ett ramverk som tillämpar arbetssätt som går på att uppfylla mål och prioriterade krav (Schwaber 2009). I ramverket finns det tre olika roller som utmärker sig bland de andra agila metoder, dem är scrummastern, utvecklingsteamet och produktägaren. En scrummaster ska fungera som en coach och vägledare för utvecklingsteamet. En produktägare har en länkande funktion mellan utvecklingsteamet och kunden. Dessutom har rollen ett ansvar för beslutsfattande om vad som ska göras i form av en produktbacklogg som förklaras noggrant i ett senare kapitel. Den sista rollen är utvecklingsteamet som utför de arbetsuppgifterna som finns i utvecklingsarbetet. Arbetssätt i agila metoder

Det iterativa och inkrementella tillvägagångssättet som tillämpas med metoderna, syftar till att leverera en testad, fungerande och användbar del av

Figur 2: Inkrementell modell för mjukvaruutveckling. Källa Pressman (2001)

Kundens roll i Agila metoder

Agila metoder präglas av ett iterativt och inkrementellt tillvägagångssätt i vilket är det menat att leverera en del av testad och fungerande mjukvaran för kunden. Syftet med varje inkrement är att kunden ska ha en aktiv roll och kunna följa hela utvecklingsprocessen. Tanken bakom det aktiva deltagande ligger i att funktioner och krav ska specificeras och prioriteras i varje sprint (Pressman 2001). Kunden avgör vad som ingår i varje sprint, genom en bedömning av vad som anses viktigast att utföra under utvecklingsarbetet. Merkel och Wendel (2013) anser att kundens roll är en bidragande faktor för värdeskapande i de strategiska

affärsaktiviteterna för kundens organisation.

Korkala och Abrahamsson (2007) hänvisar att om det saknas en väldefinierad kundroll, en ansvarig, krav och ineffektiv kommunikation, orsakas stora konsekvenser för del leveranser i varje sprint. För att projektet ska få bättre resultat, spelar kunden även en stor roll gällande återkoppling. Därför finns en uppmaning om att denne ofta ser över arbetet. Kunden bör regelbundet hålla sig uppdaterad på status och hur projekten framskrider. Kundens deltagande medför möjligheter att kunna hitta aspekter som mjukvaran saknar i form av funktionalitet eller annat som inte ingår i dennes förväntningar (Ansari & Dodda 2010). Enligt författarna går återkoppling på att förmedla aspekter som upptäcks med

mjukvaran omedelbart.

Kommunikation i agila metoder

missuppfattningar, vilket kan äventyra utvecklingsarbete och därmed minska chanser att leverera en fungerande mjukvara. Agila metoder syftar till att kommunikationen ska underlätta för alla sina deltagande att skapa en kreativ dialog där information ska förmedlas, upptäcka problem i tid och minska ledtider som förekommer när utvecklingsteamet kör fast (Juhlin 2009).

Alla agila metoder har en stark betoning i att interaktionen mellan de deltagande individerna kan vara möjligt genom personlig kommunikation. Därför är det viktig att alla i utvecklingsteamet ska kunna prata samma språk (Bass 2012). Godar och Ferris (2004) anser också att språket är förutsättning för förståelse och skapande inom och utanför utvecklingsteamet.

När kommunikationen innehåller en stor kvalité underlättas också för projektdeltagarna att utveckla och styra goda relationer som medför positiva effekter i resultat (Hagberg & Ljung 2000). Kommunikationen är också en

avgörande faktorn mellan kunden och utvecklingsarbetet. Goda förutsättningar för utveckling av kommunikations förmågor bör finnas, som kan leda till en så hög interaktion som möjlig mellan kunden och utvecklingsteamet. En öppen

kommunikation anses vara en förebyggande faktor för missuppfattningar emellan medarbetarna (Singh 2012).

3.2 Fördelar och nackdelar med agila metoder

När projekt tillämpar agila metoder har de upptäcks ett flertal generella fördelar och nackdelar som är bra för företag att känna till och värdera innan de tillämpar agila metoder. Nedan presenteras ett urval av dem.

Fördelar

Kunden

Kundens ständiga involvering är något som ses som en stor fördel vid tillämpning av agila metoder (Inayat et al. 2011). Kunden ges en stor flexibilitet i projekten, vilket ger dem möjlighet att under hela projektets livstid påverka och komma med invändningar direkt till utvecklingsteamet. Ändringar i kraven blir därmed en möjlighet för kunden, vilket leder projektet mot en ny riktlinje och mål

(Paasivaara & Lassenius 2006). Det görs även genom sprintgranskning som sker i slutet i varje sprint. Den största fördelen blir därmed kontinuerlig feedback mellan alla parter som är involverade i projektet, vilket ger en trygghet och säkerställer att projektet är på väg mot rätt håll (Inayat et al. 2011).

Korta iterationer

Alla agila projekt består av korta interaktioner, så kallade sprintar. Att dela upp projektet i mindre hanterliga bitar och skapa delmål ses som en fördel både hos de utanför projektet men också för de som arbetar i det. På så sätt blir det enkelt att se hur långt projektet kommit och för medarbetarna att planera sina

Kommunikation

Konstant kommunikation är något som de agila metoderna har som grundtanke. Det gäller mellan alla parter i projektet. Konstant kommunikation ses som en av de största förmånerna i metoder (Paasivaara & Lassenius 2012). Även att skapa förståelse på projekten ska tillämpa kommunikationen är gällande, för att få den så effektiv som möjligt. Deltagarna i projektet kan därmed dra nytta av alla parter i projektet. En fungerande kommunikation lägger grunden för att kundens

involvering ska fungera (Ester et al. 2013)

Självorganiserade team

Utvecklingsteamets självständighet är nästa fördel med agila metoder. Personerna som ingår i utvecklingsteamet utför uppgifter som de tagit på sig under sprinten och blir oberoende av varandra. Samtliga har medvetenhet om vad som krävs och strävar efter att kunna uppfylla förväntningar (Bass 2012). Genom sprintavslut och dagliga-stå-uppmöten ges medlemmarna i utvecklingsteamet också

möjligheten att lära av sina misstag och ta hjälp av varandra för att lösa sina problem. De blir medvetna om varandras uppgifter, vilket ger dem en stor fördel när de tillsammans ska leverera projektresultatet (Paasivaara & Lassenius 2006). Sprintavsluten betraktas som leverans av genomförda arbetsuppgifter där det finns utrymme för att få återkoppling, medan dagliga-stå-upp möten är tillfällen för utvecklingsteamet att uppdatera samtliga om hur arbetet går (Schwaber & Sutherland 2011).

Nackdelar

Tillämpningen av olika arbetssätt kan innebära att projekt stöter på problem. Agila metoder är inte ett undantag. Även om metodiken tillhandahåller olika fördelar, finns det också några faktorer att beakta med deras användning. Följande nackdelar har kunnat identifieras:

Kunden

Eftersom kunden involveras under hela utvecklingsarbetet, kan detta medföra svårigheter att kunna hantera nya ständiga krav på grund av en ökning i utvecklingstiden. Den stora risken som förändringar medför, handlar om att projektet kan dra ut på tiden och därmed förseningar i leveranserna (Vinderos 2013). Författaren menar också att en annan medföljande effekt är när kunden kommer med nya funktioner under projektets gång. Svårigheten är att bedöma och planera tidsåtgång för den färdiga produkten. Det kan kräva tid att bestämma vilka typer av funktioner ska prioriteras och förädlas. Projektledarens och kundens åsikter kan också kollidera med varandra. Gustavsson (2007) hävdar att även i agila metoder måste projektledaren fatta beslut. Oenighet kan förekomma mellan rollerna som kan leda till fördröjningar i beslutsfattande.

Roller

Generellt inom agila metoder finns det inte specifika roller, utan hela

ligger i att det kan medför problem när programmerare exempelvis testar och granskar sin egen kod. Det ses som ett problem i agila metoder.

Kravspecifikation

Att det inte finns en detaljerad kravspecifikation från början i projekt, kan leda till att det blir svårare att ha en övergripande bild av hela projektet. En sådan saknad kan leda enligt Gustavsson (2007) att det kan vara svårare att tillämpa agila metoder i andra typer av branscher där det inte går att dela utvecklingsarbetet i delleveranser utan en grov planering behövs från projektets start. Gustavsson (2007) påpekar också andra tillfällen där de agila metoderna kan uppfattas som ineffektiva. När det finns fasta kontrakt som innebär fasta deadlines med

fastställda leveranser och offentliga upphandlingar. På grund av att agila metoder strävar efter flexibilitet och anpassning för förändring, är det svårare att kunna tillämpa dem när det saknas förutsättningar med fasta bestämmelser i ett projekt.

3.3 Scrum

Scrum är en av metoderna som ingår i agil projektledning och utvecklades i slutet av 1980 talet och början av 1990 talet. Schwaber (2008) som är en av de två personer som ligger bakom Scrum anser att det inte handlar om en metod utan ett ramverk. En traditionell systemutveckling utgår ifrån att arbeta med krav som fördefinierads och som samtidigt fungerar som ett slutligt mål. Scrumramverket arbetar med mål genom att uppfylla prioriterade krav (Schwaber 2009). Det finns olika faktorer som kännetecknar Scrum. En av dem anses vara en hög grad av flexibilitet som präglas i hela utvecklingsprocessen. Det finns redan fastställda förutsättningar för att arbetet som utförs av utvecklingsteamet ska fungera som en enhet. En sådan enhet strävar efter att uppnå gemensamma mål. Enligt Takeuchi och Nonaka (1986) utgör det en viktig aspekt inom Scrum.

Det finns möjlighet att tillämpa Scrum under projektets gång på grund av att det innehåller en stor grad av enkelhet i sin förståelse och uppföljning. Bland andra faktorer som kännetecknar Scrum, ingår att det finns en betoning i att

kontinuerligt kontrollera och granska programvara (Takeuchi & Nonaka 1986). Hur utvecklingsarbetet utförs med Scrum tillämpning, visualiseras genom figur 3.

Att använda Scrum under utvecklingsarbete innebär en tillämpning av ett iterativt och inkrementellt tillvägagångssätt. Det tillhandahåller en kontinuerlig anpassning och inspektering av arbetsuppgifter under hela projektets gång. Arbetet är utfört av tvärfunktionella team, som innebär att utvecklingsteamet innehåller bara den kompetens som behövs för att utföra uppgiften (Schwaber 2009).

Utvecklingsteamet har för syfte att uppfylla krav som anges av kunden. Scrum använder tre viktiga roller som utmärker sig under utvecklingsperioden, Produktägaren, scrummastern och utvecklingsteamet (Schwaber & Sutherland 2011). Rollerna beskrivs i ett senare avsnitt för bättre förståelse av deras

betydelse. Författarna redovisar också att kraven som utvecklingsteamet uppfyller förmedlas genom en omfattande kommunikation mellan själva kunden och rollen som benämns för produktägaren.

Scrums grundare anser även att ramverket är utformat för att öka hastigheten på utvecklingen. Inom ramverket finns möjligheter som att anpassa individuella och organisationens mål, skapa en kultur som drivs av prestanda samt att stödja och skapa aktieägarvärde. Scrum tillhandahåller andra faciliteter som att uppnå en stabil och konsekvent kommunikation av prestanda på alla nivåer och sist men inte minst att öka individens utveckling och livskvalitet. Faktorerna utgör skillnaden mellan Scrum och andra agila metoder, där fokus ligger på hur projektet planeras och organiseras (Sutherland et al. 2007)

Roller i Scrum

Ett sätt som Scrum använder sig för att uppnå en bättre tillämpning, är

indelningen av alla deltagarna i olika roller. Rollerna rör aspekter kring ledning men också övervakning av projekt. Schwaber (2004) påpekar att rollindelning är nödvändigt för att processerna i Scrum ska fungera effektivt. Individerna som deltar i utvecklingsteamet har olika bakgrund och med en nödvändig kunskap som gör möjligt att kunna genomföra projektet. Därmed behöver inte

utvecklingsteamet att förlita arbetet till andra insatser (Schwaber 2004). Nedan beskriv utförligt de tre rollerna i Scrum.

Scrummaster

Det finns en betoning av de olika arbetsuppgifter som en scrummaster har och vilket ansvar denne har under projektarbetet. Beskrivelser av uppgifterna varierar, men de gemensamma faktorerna som tidigare studier redovisar, handlar om att scrummaster bär ansvaret för att se till att Scrum processen tillämpas och en vägledande person för utvecklingsteamet (Schwaber & Sutherland 2011). Skillnaden mellan en vanlig projektledare och scrummastern ligger i att

utvecklingsteamet, ser rollen efter att företagets politik inte påverkar produktiviteten i utvecklingsprocess (Schwaber & Beedle 2002).

Utvecklingsteamet

Judy och Krummins-Beens (2008) beskriver utvecklingsteamet som

yrkesmänniskor som arbetar ständigt för att leverera ett funktionellt, potentiellt användbart och realiserbart inkrement av en klar produkt i slutet av varje sprint. Individerna som ingår i utvecklingsteamet innehar befogenheter att själva bestämma hur arbetet ska organiseras och styras (Schwaber 2004). Därför anser Schwaber och Sutherland (2011) att utvecklingsteamet är självständigt och har mycket beslutsfattande om hur utvecklingsarbetet ska genomföras. De

befogenheter fastställs av själva organisationen med syfte att skapa förutsättningar till en resulterande energi som leder till effektivitet inom utvecklingsteamet. Produktinkrementet som utvecklas i varje sprint ansvarar utvecklingsteamet det är bara utvecklingsteamet som bidrar till det med sina arbetsinsatser och ingen annan utanför projektet.

Det finns några beskrivande egenskaper som Pichler (2010) har tagit fram som utmärker utvecklingsteamet. Den första är den nämnda självorganisationen i utvecklingsteamet som innebär att kunna garantera bättre effektivitet och

produktivitet under utvecklingsarbete. Det rekommenderas att utvecklingsteamet ska bestå av minst tre och högst nio deltagare. Författaren menar att om

utvecklingsteamet har mer än nio personer, krävs det en stor grad av koordination. Däremot om det finns mindre än tre personer kan det inte garanteras en bra

interaktion mellan varandra och därmed en minskad produktivitet. En annan egenskap för utvecklingsteamet, handlar om att skapa och utveckla

produktinkrement och att individerna innehar de kunskaperna som behövs. Därför sägs det att utvecklingsteamet bör vara tvärfunktionellt.

Det finns ingen betydelse av vilket typ av arbete deltagarna i utvecklingsteamet utför i sina uppgifter, alla är utvecklare. Det innebär att det inte finns individuella titlar. För att kunna göra det ännu tydligare finns det två viktiga regler som bör följas under utvecklingsarbete. Den första är att Scrum inte erkänner några del team inom utvecklingsteamet, vilket innebär att det inte får finnas team inuti utvecklingsteamet. Den andra regeln är att enskilda medlemmar i teamet kan ha specialkompetens och fokusera mer på vissa områden. Men ansvaret för att genomföra hela uppgiften ligger på hela utvecklingsteamet (Schwaber & Sutherland 2011).

Produktägaren

Rollen innefattar olika typer av ansvar under projektets gång. När företag

bestämmer sig för att tillämpa Scrum, tas det mycket hänsyn till att kunden arbetar som aktiv deltagare under hela utvecklingsprocessen. Produktägaren kan fungera som kundens representant, en länk mellan kunden och själva projektets

utvecklingsteam. Produktägaren bär ansvaret för att maximera värdet av

projektet. Med andra ord produktägaren bär ensam ansvaret att bestämma vad som ska göras under utvecklingsarbetet.

Schwaber och Sutherland (2011) hänvisar att produktbackloggen är

produktägarens ansvar. Användningsfall är ett lättare sätt att kunna framställa produktbackloggen, på grund av att det handlar om beskrivelser från aktörernas synvinkel. Beskrivelserna är krav som sedan utgör en samling aktiviteter som ger ett konkret, och påtagligt resultat. Det gäller att användningsfallen ska beskrivas så tydligt som möjligt och på ett lättförståeligt sätt. Användningsfallen ska

prioriteras först för att sedan bearbetas. Produktbackloggen ska vara synlig för alla medlemmar och kunden i projektet och ska visa vad utvecklingsteamet ska arbeta med härnäst.

Författarna poängterar också att produktägaren handlar om enbart en person. Kunden själv kan vara produktägare eller utse någon annan som representerar organisationen. Organisationers styrelse ska respektera alla beslut som intas av produktägaren. Det skapar förutsättningar för framgång med produktbackloggen. Utvecklingsteamet ska genomföra utvecklingsarbete utifrån de krav som finns i produktbackloggen och inte något annat. En annan fördel med att produktägaren själv bär befogenheterna ovan, ligger i att det är lättare att kunna styra projektets riktlinjer genom bättre krav prioritering. Det leder till en balans mellan kraven, fatta ta beslut och därmed bättre resultat (Sverrisdottir et al. 2014).

Det finns olika jämförelser mellan produktägaren och traditionella roller som produktchef eller projektledare. En mer traditionell projektledare tar hand om hela projektet, medan produktbackloggen fungerar som ryggraden i produktägarens aktiviteter för ett bättre samarbete med scrummaster, utvecklingsteamet och projektets intressenter. Sverrisdottir et al. (2004) redovisar att det finns ett behov av ett nära samarbete mellan produktägaren och utvecklingsteamet, på grund av att den ena ska förmedla krav och ändringar i produktbacklogget och den andra ska utföra utvecklingsarbetet.

Produktägarens egenskaper

Pichler (2010) menar att produktägarens roll bör inneha några väsentliga

egenskaper för att lyckas med sitt arbete. Kommunikations förmåga och vara bra i förhandlingar. Dessutom måste rollen inneha tillräckligt med auktoritet och stöd från företagsledningen att leda utvecklingen i projektet. Det kan leda till bättre samordning över intressenternas önskemål. Det nämns också att det ska finnas en stor tillgänglighet från produktägarens sida men också förmågan att förmedla visionen med projektet.

Schwaber (2004) anser att visionen kring produktägaren ska reflektera varför projektet ska genomföras men den speglar också det önskade sluttillståndet. För att lyckas bättre med förmedlingen, bör produktägaren vara konkret i

beskrivningen av gemensamma mål att uppfylla under utvecklingsarbete.

om teknik, marknad och affärsprocesser (Softhouse 2012). Kunskaperna är användbara för att få en bättre prestanda i de tre nyckelområden som

produktägaren berör; det första nyckelområdet är grundläggande förståelse för kundens behov, den andra är god kommunikation med samtliga intressenter, och den tredje är att produktägaren ska ha grundläggande kunskap om hur

programvara utvecklas och levereras (Pichler 2007).

Artefakter i Scrum

Scrum strävar efter att garantera en hög grad av tydlighet och därmed

tillhandahålla inspektion och anpassning under hela utvecklingsarbetet. Därför anser Schwaber och Sutherland (2011) att aspekterna kan nås genom tre olika artefakter. Produktbackloggen, sprintbackloggen och inkrementen är artefakterna som bidrar till tydligheten i ramverket.

Inkrement

Schwaber och Sutherland (2011) beskriver inkrementet som alla färdiga

aktiviteter från produktbackloggen som utvecklingsteamet har lyckats att utföra under varje sprint. Alla aktiviteter ska uppfylla funktionalitet i mjukvaran som ska vara användbar för produktägaren. Inkrementet är en delleverans som utförs efter att testning och dokumentation genomförts efter varje sprint. Att Scrum levererar ett kontinuerligt produktinkrement syftar till att tillhandahålla värde till kunden. Strävan finns också kring att kunden ska kunna ge återkoppling på det som levereras. Pitchler (2010) hävdar att återkopplingen för varje inkrement möjliggör tidsbesparing, eftersom utvecklingsteamet inte behöver implementera onödig eller felaktig funktionalitet i programvaran.

Dagligt Stå-upp-möte

Mötet kan jämföras som en slags lägesrapport som ska ta upp 15 minuter varje dag. Det är ett sätt att hålla utvecklingsteamet uppdaterad om hur arbetet går framåt. Pope-ruak (2012) redovisar att tre viktiga frågor ställs under träffen: vad gjorde du igår? vad kommer du göra idag? samt har du stött på några hinder? Det strävas efter att få svar bara på de frågorna även om det finns andra relevanta detaljer. Mötet ingår i utvecklingsteamets rutiner vilket innebär att det bör ske kontinuerligt, helst varje dag. Sprintarna innehåller interaktioner på 24 timmar. Det medför att varje interaktion som påbörjas, inleds med ett stå-upp möte (Schwaber 2009). Alla som deltar i utvecklingsteamet ska redovisa hur det går med arbetet. Det betyder att allas närvaro är viktigt för att skaffa en gemensam bild av progress samt att ta vara på information som kommer från kollegorna.

Produktbacklogg

Det är produktägaren som ansvar för upprätthållande av produktbackloggen. Inom traditionell projektledning framställs en kravspecifikation med allt som projektet är menat att leverera. I Scrum kan produktbackloggen jämföras med en sådan specifikation. Backloggen innehåller en lista av allt är mjukvara behöver för att bli användbar. Det fungerar också artefakten som underlag för beslutsfattande

Produktbackloggen tas fram genom att kunden specificerar vilken typ av produkt det är som organisationen behöver. Efteråt presenteras de i en prioriterad lista som scrummaster och utvecklingsteamet tar del av. Produktägaren bygger

produktbackloggen på olika typer av användningsfall om hur produkten ska fungera. Schwaber och Sutherland (2011) menar att användningsfall är ett effektivt redskap för att enklare förklara vad utvecklingsteamet ska utföra under utvecklingsprocessen. Det är ett sätt att kunna ha en övergripande bild av hela projektets livscykel. Det är inte enbart krav som bygger produktbackloggen, utan det olika egenskaper, funktioner och förbättringar att utföra för mjukvaran. En annan aspekt som utmärker backloggen handlar om att den utgår från ett värde, risk, prioritet och behov.

Sprintbacklogg

Produktbackloggen fungerar som utgångspunkt för att kunna framställa

sprintbackloggen. Det handlar om en förteckning över uppgifter, tidsestimering och uppgiftsansvariga individer (Schwaber 2009). Det utgör en plan för alla kommande arbetsuppgifter som ska utföras under en sprint, där det levereras inkrement. En sprint är iterationer som sker under utvecklingsperioden. Längden till varje sprint är normalt fyra veckor men det kan variera beroende på varje enskilt projekt. I varje sprintplanering måste det finnas en anpassning till vad som utvecklingsteamet kan hantera under en sprint. Schwaber och Sutherland (2011) anser att det handlar om en prognos som utvecklingsteamet förutsäger om vilken typ av funktionalitet ska ingå i varje inkrement, samt vilka arbetsuppgifter uppfyller den bestämda funktionaliteten. I själva verket är det utvecklingsteamet som bestämmer vad som ska ingå i varje sprintbacklogg och utgöra förändringar i den.

Sprintplaneringsmöte

Det är ett tidsbegränsat åtta timmars möte som utdelas i två segment på fyra timmar. Alla samtliga roller i projektet deltar i sprintplaneringen. Det finns också möjlighet för andra intressenter att kunna närvara i mötet. Däremot får deras deltagande bara har ett informativt syfte (Blankenship et al. 2011). Författarna redovisar också att inför planeringen har produktbackloggen aktualiseras och prioriteras av produktägaren i samråd med själva kunden och scrummastern. Eftersom mötet är indelat i två segment, används det första segmenten för att föra aktiviteter från produktbackloggen till den kommande sprintbackloggen.

Abrahamsson et al. (2002) hänvisar att under sprintplaneringsmötet väljs uppgifter ut som utvecklingsteamet kommer att implementera under sprinten. Det finns några faktorer att beakta för planering. De bestämda aktiviteterna som ska ingå i sprinten framställs genom en öppen dialog mellan produktägaren och

utvecklingsteamet. Schwaber (2009) redovisar att utvecklingsteamet ska prioritera vad som kan utföras under en sprint där det ska garanteras en inkrementell

Den andra delen av planerings mötet är ägnat till utvecklingsteamet. Syftet är att kunna föra en intern diskussion om arbetsuppgifterna som ingår i sprinten för att sedan delegera vem som gör vad. Resultatet av segmentet är sprintbackloggen. Schwaber (2009) hänvisar till att under den här delen av möte sker ett ombytes mandat. Utvecklingsteamet bestämmer hur arbetsuppgifter kommer att utlösas.

Sprintgranskningsmöte

Efter att varje sprint avslutas ska ett fyra timmars sprintgranskningsmöte äga rum. Mötet inleds med en timme demopresentation som utvecklingsteamet förbereder. Presentationen ska redovisa de inkrementen av produkten för produktägaren samt andra intressenter och kunden(Schwaber 2009). Däremot hänvisar författaren att “klar funktionalitet” kan innebära olika från projekt till projekt. Det gäller att komma överens med produktägaren vilken typ av nivå den klara funktionalitet ska innehålla. Syftet med överenskommelsen ligger i att på så sätt ge kunden en mer realistisk uppfattning om den nuvarande produkten (Törnkvist & Kjellberg 2013). Under den andra delen av mötet görs det en avstämning om aktiviteterna som fördes från produktbackloggen har utförs och stämmer överens med

sprintbackloggen. Det leder till att få en överblick och kunna jämföra aktiviteterna med det som presenteras i demonstrationen. Mötet avser också att ta fram ifall arbetsuppgifterna som utfördes blev enligt planeringen samt eventuella problem som förekom under sprinten (Schwaber 2009). Författaren hävdar att

granskningsmötet också ger utrymme till återkoppling från intressenter och produktägaren i form av frågor och kommentarer. En sådan återkoppling är utgångspunkten för hur den kommande sprinten ska utformas i form av prioriterade arbetsuppgifter från produktbackloggen.

Sprintretrospektiv

Inom Scrum är återkoppling viktigt för varje interaktion som genomförs under utvecklingsarbetet. Därför är mötet ägnat till att göra en utvärdering om hur det gick under varje sprint. Alla rollerna i projektet deltar i retrospektivet och kommer fram med nya idéer och synpunkter om hur kommande interaktioner kan

förbättras (Schwaber 2009). Derby och Larssen (2007) redovisar att förbättringar kan gälla förhållanden, människor, verktyg eller processer i varje sprint. På så sätt kan diskussionen fungera som ett underlag för eventuella anpassningar i

kommande sprintar beroende på sammanhang. Det rekommenderas att

sprintretrospektiv ska vara i högst tre timmar för bättre diskussion och reflektion. En annan typ av rekommendation som Derby och Larssen (2007) uppger, handlar om att följa fem enkla steg under momentet. Stegen går ut på att skapa stämning för diskussion, datainsamling, insikt skapelse, beslut om vad som ska göras och avsluta retrospektivet.

aktiviteter som utfördes från backloggarna vilket avser olika upplevelser eller känslor från deltagarna i utvecklingsteamet de mjuka värdena.

Derby och Larsen (2007) redovisar också att datainsamlingen är möjligt genom att utvecklingsteamet svarar på sex enkla frågor:

1. Var det något speciellt du uppmärksammade? 2. Vad förvånade dig?

3. Vilka utmaningar mötte du på under sprinten?

4. Vilka erfarenheter samt insikter tar du med dig från sprinten? 5. Vad berättar de om det aktuella projektet?

6. Nämn en sak som du skulle vilja göra annorlunda?

När alla deltagarna har svarat på frågorna kan det göras en sammanställning som bidrar till att skapa en gemensam bild för eventuella problem och hur dem kan påverka kommande arbetet. Att skapa en sådan bild av situationen skapar möjligheten till förändringar som kan tillämpas i kommande sprint samt en förståelse om andras förhållanden (Schwaber 2009). För att sprintretrospektiv ska kunna avslutas är det viktigt att samtliga ska komma överens om vilka åtgärder som ska vidtas samt hur dem ska uppföljas och dokumenteras. Däremot anser Shore (2008) att för att få bättre effekt med åtgärderna ska utvecklingsteamet avgränsa sig till bara implementera för den kommande sprinten.

Fördelar och nackdelar med Scrum

Tillämpningen av agila metoder varierar från metod till metod. Däremot delar de samma fördelar i deras användning gällande kommunikation, kundinvolvering, iterationer och självorganiserade team. Förutom de delade fördelarna med andra agila metoder erbjuder Scrum andra typer av förmåner under utvecklingsarbetet. Sverrisdottir et al. (2014) presenterar olika fördelar med Scrum, den första är att Scrum använder en bättre prestanda och ett mer bekvämt sätt att arbeta med sprintarna. Förutsättningarna finns på grund av att sprintarna är korta perioder. Utvecklingsteamet kan gå igenom prioriterade krav och hinna med förändringar som uppstår under arbetsgång. Den andra fördelen som tas upp är att Scrum medför stor grad av tillgänglighet när de gäller statusuppdateringar. Något som metoden fokuserar mycket på är avstämningen med kunden, så kallade

sprintdemo vilket ger dem en fördel kring kontinuerlig uppdatering av projektet. Att ha en gemensam bild av vilka uppgifter som ska utföras under varje sprint är också en fördel. Genom att sprintarna är iterationer med tidsbegränsning, kan arbetsuppgifterna uppskattas exakt. Det ger en fördel för både kunden och medarbetarna. Genom dagliga stå-upp-möten och övrig kommunikation mellan medlemmarna i utvecklingsteamet kan problem identifiering ske tidigt vilket leder till att olika åtgärder kan tillämpas utan att utvecklingsarbetet äventyras och därmed ett kortare utvecklingsarbete.