Scrum-processens påverkan på den inre projekteffektiviteten

Transkript

1 Almir Hodzic Scrum-processens påverkan på den inre projekteffektiviteten En fallstudie av ett nationellt distribuerat Scrumteam The Scrum process impact on the internal project efficiency The case study of a nationally distributed Scrum team Informatik C-uppsats Termin: VT - 17 Handledare: Odd Fredriksson Examinator: John Sören Pettersson

2 Sammanfattning I en allt mer digitaliserad värld där systemutveckling sker i snabbare iterationer, uppstår ökade behov som behöver mötas av IT-konsultbolag i systemutvecklingsprojekt. Agila systemutvecklingsmetoder uppstod vid behov av lättrörliga systemutvecklingsmetoder. En av de mest tillämpade metoderna är Scrum, som är anpassad för små, samlokaliserade projekt. Den agila utvecklingsmetoden Scrum är en erkänd metodik inom systemutveckling som möjliggör noggrann utvärdering, testning och iteration inom utvecklingsprojekt. Populariteten av Scrum-metoden har ökat och det har medfört att organisationer med olika typer av strukturer blivit intresserade av att tillämpa Scrum-metoden på nationell och internationell nivå, vilket utmanar Scrum-metodens gränser och teorier. Meningen med Scrum-metoden var ursprungligen att effektivisera systemutvecklingsprojekt på lokal nivå. Distribueringen av Scrum-metoden utmanar därför gränserna och påverkar Scrum-metodens projekteffektivitet. Syftet med denna kandidatuppsats i Informatik är att identifiera, beskriva och förklara förhållanden i en nationellt distribuerad Scrum-process som påverkar den inre projekteffektiviteten. Fallstudiemetoden brukades för denna uppsats, vilken har baserats på ett observationstillfälle hos fallföretaget samt intervjuer med fyra olika rollinnehavare inom fallföretaget. De viktigaste slutsatserna från denna uppsats visar att det finns ett antal förhållanden som påverkar det nationellt distribuerade teamets projekteffektivitet. Valet av releasecykelns struktur påverkar den inre projekteffektiviten, liksom valet av ett mer linjärt team. Fokus på specialkompetens och isolering gentemot kommunikation och samarbete kan påverka hur ett nationellt distribuerat team arbetar över kontorsgränserna. Det visar sig att förhållandena som uppstår ursprungligen har sin grund i hur teamets medlemmar enskilt uppfattar situationerna och att ett team med delade åsikter kan skapa liknande situationer. Slutligen kan synkroniseringen mellan det nationellt distribuerade teamets kontor ha en påverkan på förhållandena. Nyckelord: Svenska: Agila metoder, Scrum, Inre projekteffektivitet, Utvecklingsteam, Nationell distribuering, Sprint English: Agile methods, Scrum, Inner project efficiency, Development team, National distribution, Sprint

3 Förord Först av allt vill jag tacka alla som ställt upp på intervjuerna och observationen för bidraget till uppsatsen. Utan er hade det inte blivit något arbete. Ett stort tack till min handledare Odd Fredriksson som ställt upp genom hela uppsatsperioden med konstruktiv kritik, värdefulla råd, tips och intressanta diskussioner både vad gäller metod- och ämnesområdet. Tack till handledargruppen, och opponenterna, som kommit med tips och råd under uppsatsens gång. Tack till min familj som inte bara stått ut med min frånvaro utan även uppmuntrat mig under arbetets gång. Avslutningsvis vill jag tacka alla referenser som jag har använt som informationskällor och för mitt lärande.

4 Innehållsförteckning 1. Inledning Problembakgrund Syfte Målgrupp Avgränsning Etiska övervägningar Teori Agila metoder Agil utveckling Nationell och internationell distribuering - outsourcing av agila metoder Scrum Scrumteamet Produktägare Utvecklingsteamet Scrum master Scrums aktiviteter Sprint Releasecykler Dagliga möten Sprintgranskning, Sprintåterblick & Sprintplanering Scrums artefakter Produktbacklog Sprintbacklog Produktinkrement Scrums tre pelare Inre projekteffektivitet inom agila metoder Analysmodell Inre projekteffektivitet Team A - Team B och påverkanspilar Produktbacklog Sprintplanering Sprintbacklog Sprint och dagligt möte Produktinkrement Sprintgranskning Sprintåterblick Metodredogörelse Metodansats: Fallstudie Fallstudiens nackdelar Fallstudiens fördelar Val av fallföretag Fallföretagets arbetssätt Tillvägagångssätt Intervjuer Intervjuernas fördelar Intervjuernas nackdelar Urval Introduktion av uppsatsens fyra respondenter Intervjuguider Observation Observationens fördelar Observationens nackdelar Validitet, reliabilitet och generaliserbarhet... 27

5 4. Analys Inre projekteffektivitet Produktbacklog Sprintplanering Sprintbacklog Sprint och Dagligt möte Produktinkrement, sprintgranskning och sprintåterblick Team A och Team B Fallföretagets arbetssätt Fallföretagets nationellt distribuerade team Scrum-processens påverkan på den inre projekteffektiviteten Synkronisering av utvecklingsteamet Användningen av releasecykeln Linjära utvecklingsteam och fokus på specialkompetens Slutsatser Förslag på fortsatta studier Källförteckning Bilagor Bilaga 1 Intervjuguide Bilaga 2 Sammanställning av intervjuer Bilaga 3 Sammanställning av observationsanteckningar Bilaga 4 Terminologi Figurförteckning Figur 1: Traditionell vattenfallsmetod Källa: Modifierad utifrån Nyman (2010:1)... 4 Figur 2: Sprintcykel: Visualisering av sprint-cykeln Källa: Modifierad utifrån Deemer et al. (2009:3 10 Figur 3: Scrums process Källa: Modifierad utifrån Björkholm och Brattberg (2010:13) Figur 4: Releasecykler Källa: Modifierad utifrån Sutherland (2005:1) Figur 5: Analysmodell över förhållanden i en distribuerad Scrum-process som påverkar den inre projekteffektiviteten Källa: Modifierad utifrån Schwaber och Sutherland (2011:16) Figur 6: Releasecykelperiod - samma färg relaterar till samma releasecykel Källa: Fallföretag Figur 7: Analysmodell över förhållanden i en distribuerad Scrum-process som påverkar den inre projekteffektiviteten med analysområden inlagt Källa: Modifierad utifrån Schwaber och Sutherland (2011:16) Tabellförteckning Tabell 1: En sammanställning av utförda intervjuer Källa: Författare... 24

6 1. Inledning I detta kapitel presenteras bakgrunden till arbetet och hur det hela skildrades, följt av själva syftet. Kapitlet avslutas med en målgruppsindelning samt avgränsningar som gjorts genom arbetets gång, följt av etiska överväganden inom arbetet. 1.1 Problembakgrund I dagsläget finns det ett stort antal metoder för utveckling och anpassning av IT-system (Computer Sweden 2009). Vilka tekniker, verktyg och metoder som används inom projekten beror på vilken typ av system som utvecklas (Andersen 1994). Organisationer kan använda sig av olika systemutvecklingsstrategier beroende på organisationens struktur och vilka drivkrafter som styr de metoder som används (Andersen 1994). Engwall et al. (2005) menar att det existerar studier som visar att det finns skillnader i formella metoder jämfört med de observerade handlingarna, främst att metoder inte används i den utsträckning som menat. Metoder kan också användas för att visa framgångar utåt snarare än att bidraga med ett gemensamt sätt att utföra en teknisk uppgift på (Engwall et al. 2005). Den agila utvecklingen har sitt fokus på människorna i verksamheter samt projekt, där den absoluta tyngdpunkten ligger främst på koordination, samarbete och kommunikation mellan alla anställda internt inom verksamheten eller inom det specifika projektet men också mellan eventuella externa kunder (Cockburn 2002). Agila metoder kan skilja sig åt men grundstenarna existerar fortfarande inom alla, och de är att alla metoder är iterativa, inkrementella, består av självorganiserande projektgrupper och att de har lätt för att anpassa sig för eventuella förändringar (Lindvall et al. 2002). Agile Sweden nämner att en ständig övervakning av omvärldens behov krävs inom organisationen för att det som produceras kan ha någon möjlighet att leva vidare efter produktion. Detta har varit aktuellt under en lång tid inom företag men det har blivit en allt större press på företagen eftersom programvaran som utvecklas kräver en hög standard för säkerhet samtidigt som takten i vilket programvaran utvecklas blir allt snabbare. För att hantera alla faktorer krävs en konstant kommunikation mellan alla involverade parter, från ständig kommunikation systemutvecklare sinsemellan, till kommunikation mellan kunden, projektledaren och utvecklaren (AgileSweden 2002). För att möta kraven på en allt snabbare och mer flexibel utveckling av marknaden, övergår många organisationer från en mer traditionell vattenfallsmodell till modernare agila metoder, något som ställer stora krav på organisationen och dess anställda vad gäller omorganisering av rutiner och arbetssätt. I agila metoder är förutsättningarna lite annorlunda för de anställda där de ställs inför nya utmaningar och sätt att arbeta på, inte bara kring tekniken som används, utan också med varandra. I en vattenfallsmodell arbetar teamet i större grupper och med större projekt där leveranser sker i slutet av hela processen. I agila metoder är grupperna mindre och teamet arbetar närmare varandra och med kortare iterationer där teamet bör vara beredda att leverera färdiga inkrement när som helst (AgileSweden 2002, Sutherland 2005). Metoderna har i uppgift att hantera en snabbt förändrande marknad och enligt Cockburn (2002) bör metoderna klara av det för att de är dynamiska, förändringsomfamnade men också tillväxtorienterade, vilket är en nyckelfaktor för att organisationer ska ha möjligheten att överleva och vara konkurrenskraftiga på en snabbt förändrande marknad. Idag existerar ett stort utbud av agila metoder att välja mellan beroende på vad den specifika verksamheten har för mål och vilken marknad det gäller. Exempel på några agila metoder kan vara Extreme Programming (XP), Scrum, Crystal (Samlingsnamn), Adaptive Software Development (ASD), Dynamic Systems Development (DSDM) och Lean Software Development (Björkholm & Brattberg 2010). Av de agila metoder som nämnts ovan är Scrum den vanligaste formen av agil metod (Björkholm & Brattberg 2010). Scrum utgör tillsammans med ovan nämnda metoder en agil allians 1

7 där grundarna från samtliga metoder samlats för att behandla agila värden, vilket har dokumenterats enligt det agila manifestet (Agile Manifesto 2001). Scrum-metodiken används av många företag här i Sverige (AgileSweden 2002), och denna metod kommer att behandlas i uppsatsen eftersom det studerade fallföretaget använder sig av Scrum i systemutvecklingsprojekt. Schwaber och Sutherland (2014) anser att utvecklingsteam inom Scrum arbetar som effektivast när de sitter tillsammans i samma rum och arbetar. När ett utvecklingsteam splittras och arbetar på flera orter, på en nationell nivå påverkas teamets projekteffektivitet av detta eftersom Scrum utvecklades med närhet och samarbete i åtanke. Den inre och yttre projekteffektiviteten inom utvecklingsteamet påverkas av den nationella distribueringen genom ändrade förhållandena som skapar problem som inte hade existerat om utvecklingsteamet inte varit uppdelat. Kommunikationen och samarbetet som Scrum främjar (Schwaber & Sutherland 2014), blir nu ett mycket större problem för utvecklingsteamet. I dagsläget är det vanligt att utvecklingsteam outsourcas och offshoras för att reducera kostnader och öka vinster. Men att dela upp utvecklingsteam på nationell nivå istället för att offshora projekt internationellt, är inte lika vanligt och därför är det intressant att se på hur den inre projekteffektiviteten påverkas genom nationellt distribuerade utvecklingsteam och deras Scrumprocesser. 1.2 Syfte Syftet med denna kandidatuppsats i Informatik är att identifiera, beskriva och förklara förhållanden i en nationellt distribuerad Scrum-process som påverkar den inre projekteffektiviteten. 1.3 Målgrupp Målgruppen för uppsatsen är fallföretaget och dess intressenter som kan ta hjälp av denna uppsats för att se och utvärdera sin nuvarande inre projekteffektivitet. Men också andra företag som bedriver sitt arbete med hjälp av Scrum-metoden, som kan identifiera sig själva i situationen som detta fallföretag nu befinner sig i. Utöver det kan utvecklingsteam, produktägare och kunder använda sig av denna uppsats för att närmare förstå hur de bör agera i specifika situationer där agila team är nationellt distribuerade, d.v.s. fungera som en form av vägledning. 1.4 Avgränsning Uppsatsen har avgränsats till ett specifikt företag som fokuserar på IT-konsultation och därför kommer en fallstudie att bedrivas. Denna avgränsningen har genomförts på grund av bristande vilja att delta från andra företag. Vidare kommer inte hela projektet att fokuseras på, eftersom kund samt produktägare valt att inte delta i denna uppsats på grund av tidsbrist, detta avgränsar uppsatsens område till enbart den inre projekteffektiviteten. Denna avgränsning leder i sig till att problemen som är direkt relaterade till själva framställningen av kundens produkt inte kan vara med, d.v.s. kod eller dokument, för att det hör till den yttre projekteffektiviteten. Därför kommer fokus ligga på företagets Scrum-process i sig, och därför studeras endast den inre projekteffektiviteten. 1.5 Etiska övervägningar Studien som genomförs innebär involvering av respondenter i och med insamlandet av data genom intervjuer samt en observation och det är därför viktigt att ta hänsyn till etiska aspekter som kan påverka arbetet. Patel och Davidsson (2011) menar att undersökarens uppgift är att generera kunskap som anses trovärdig, och det ställer krav på tillvägagångssättet som undersökaren använder. Respondenter får inte utsättas för kränkningar, förödmjukelse eller annan psykisk och fysisk skada under samt efter intervjuerna och observationen. Respondenterna blev informerade om syftet med fallstudien och hur intervjuerna och observationen kommer att användas i uppsatsen. Genom arbetet har företaget begärt att stå som anonymt, därför har varje respondent kallats efter sin befattning och inte efter namn. Utöver detta behöver det också nämnas att data som genererats genom fallföretaget endast kommer att användas i denna fallstudie. 2

8 2. Teori I detta kapitel kommer relevant litteratur för området att presenteras för att skapa förståelse hos läsaren för själva forskningsområdet. Litteraturstudien i denna uppsats innefattar böcker men också elektroniska dokument i form av artiklar eller e-böcker som framtagits genom databassökningar från Karlstad Universitets bibliotek, men också främst genom användandet av Harzings programvara Publish or perish som hjälper till att sortera källor efter antal gånger som de har refererats av andra författare. Alla de former av litteratur som framtagits har ansetts vara relevanta för området som studeras, samtidigt som den klarat en källkritisk granskning och har därför tagits med i uppsatsen som ett stöd vid senare tillfälle genom användning vid analys över den empiriska datainsamlingen. Litteraturstudien har använts som en utgångspunkt vid starten av arbetet för att samla relevant kunskap för att sedan möjliggöra förberedelser av det empiriska arbetet i uppsatsen. Genom litteraturstudien minskas denna uppsats felaktigheter som kan uppstå vid skapandet av empirin, analysen och slutsatsen genom att låta det funktionera som en vägledning. Under litteraturstudien har jag i stor utsträckning utgått från grundkällan, detta innebär att litteraturen som tagits fram för att beskriva teorin är till majoriteten av Scrums skapare och deras guide till Scrum, Jeff Sutherland och Ken Schwaber, men också andra oberoende källor t.ex. Tomas Björkholm och Hans Brattberg har använts för att jämföra påståenden. Varför jag väljer att följa Scrums guide är för att det minskar risken för att hamna över opålitliga källor som kan färga teorin och mina egna åsikter, vilket i slutändan påverkar resultatet av hela arbetet. Men att studera andra källor som ansetts varit pålitliga, genom användandet av programvaran som räknar referenser, har det hjälpt till att skapa en mer objektiv bild av området. Att vid majoriteten av fallen enbart förlita sig på vad grundarna har att säga har försökt att undvikas i största möjliga mån eftersom det kan skapa en felaktig bild, därför har alltid jämförelser utförts med annan kvalificerad litteratur. Grundarna av Scrum har en akademisk bakgrund och arbetar idag med att föreläsa om Scrum, agila värden samt andra agila metoder och kan därför ses som en pålitlig källa vid uthämtning av information angående agila metoder (Agile Manifesto 2001, Scrumguides 2017). 2.1 Agila metoder Ordet agil härstammar ursprungligen från engelskans agile som betyder lättrörlig eller vig. Agila metoder kan ses som ett gemensamt synsätt för en grupp med flera lättrörliga metoder (AgileSweden 2002). Själva grundtanken med agila metoder är att de fungerar i en föränderlig värld, d.v.s. att metoderna bör klara av att hantera förändringar som en del av verkligheten och att de inte blundar för alla förändringar eller helt enkelt väljer att reglera bort dem (Schwaber & Sutherland 2014). Fler regler ger inte fler lyckade projekt, istället behövs flexibilitet, och inte rigiditet (Asproni 2004, Schwaber & Sutherland 2014). Agila metoder kan ses som en paraplyterm, det är inte en systemutvecklings-metodik men det bygger istället på stor uppsättning med värderingar, attityder och principer (AgileSweden 2002). Agila metoder anses vara lättrörliga eftersom själva upphovsmannen bekänner sig till de agila värderingarna, och de agila värderingarna är utformade i och med sammankomsten av grundarna från ett flertal agila metoder (Nyman 2010, Agile Manifesto 2001). Under flera år har IT-utvecklingen i största grad baserat sig på diverse varianter av vattenfallsmodellen, vilket har sin grund i att utvecklarna börjar med att fånga alla krav som ligger till grund för systemet och sedan designas lösningen (Nyman 2010). Nyman (2010) menar också att när detta är klart, påbörjas implementeringen, vilket leder till tester och validering tillsammans med verifiering. Sist sjösätts själva lösningen och övergår till drift och underhåll (Figur 1). 3

9 Kravinfångning Analys & Design Implementering Validering & Verifiering Drift & Underhåll Figur 1: Traditionell vattenfallsmetod Källa: Modifierad utifrån Nyman (2010:1) Det existerar dokumenterade exempel på att agila metoder fungerar lika bra som vattenfallsmetoden (Nyman 2010, Björkholm & Brattberg 2010). Svårigheterna som uppstår när teamet försöker finna och dokumentera krav i förväg för att sedan producera specifikationer till underlag i utvecklingen kan hanteras på ett mycket mer effektivt vis med hjälp av agila metoder (Schwaber & Sutherland 2014). Detta är väldigt tydligt i diverse miljöer där krav hela tiden förändras. Ett motiv till att ändra på det vattenfallsliknande arbetssättet är själva betydelsen av att tidigt generera delresultat som kan användas och ge nytta i verksamheten långt i förväg istället för när själva projektet är färdigt (Nyman 2010, Björkholm & Brattberg 2010). Under 1990-talet genererades ett antal alternativa arbetssätt som kunde ses som en reaktion mot vattenfallsliknande metoder, oberoende av varandra och med olika upphovsmän (Agile Manifesto 2001). Agila arbetssätt började uppstå i och med att utvecklare började få en bild av att vattenfallstänket helt enkelt började bli allt för trögt och omfattande i takt med att behovet av snabbare utveckling uppstod (Nyman 2010, Björkholm & Brattberg 2010). Exempel på metoder som utvecklades i och med detta är Scrum och DSDM, Adaptive Software Development, Crystal, Feature- Driven Development och Pragmatic Programming (Schwaber & Sutherland 2014). De blev också väldigt populära. Gemensamt för metoderna är att när de växte fram var grunden i dem erfarenheter från tidigare IT projekt (Schwaber & Sutherland 2014). Utvecklarna av metoderna tog med sig det som hade fungerat bra och det som har lett till att många projekt havererar (Nyman 2010, Björkholm & Brattberg 2010, Schwaber & Sutherland 2014). Initiativ till lättrörliga metoder kan i sig leda till något positivt eftersom att samtliga ledande profiler istället för att börja bråka om vems metod som var bäst, samlades för att diskutera vad profilerna var överens om och vad som skiljde tankesätten åt (Agile Manifesto 2001). I slutändan enades alla de ledande profilerna för sina metoder om principer och värderingar. Synsättet kom att kallas Agile efter detta. Under mötet, vilket genomfördes januari 2001 i Utah, skapades nätverket Agile Alliance, vars mål är att gemensamt vidareutveckla och dela med sig av värderingar, principer och arbetssätt som ligger till grunden för alla lättrörliga metoder idag (Nyman 2010, Agile Manifesto 2001). De gemensamma principerna och värderingarna dokumenterades i ett gemensamt manifest som kom att kallas Agile Manifesto (Agile Manifesto 2001). Det agila manifestets principer utvecklades för att möjliggöra en mer generell terminologi, i och med detta kan det hela tillämpas inom andra branscher där ett agilt arbetssätt anses vara lämpligt (Björkholm & Brattberg 2010). Enligt det agila manifestet prioriteras: Individer och interaktioner framför processer och verktyg Fungerande programvara framför omfattande dokumentation Kundsamarbete framför kontraktsförhandling Anpassning till förändring framför att följa en plan Det agila synsättet värdesätter det förstnämnda i listan med prioriteringar, men det existerar fortfarande ett värde i det andra (Björkholm & Brattberg 2010, Agile Manifesto 2001). Agila metoder funktionerar inte alltid optimalt. Jalali (2012) nämner att agila metoder inte är tillräckligt effektiva i stora organisationer och specifika typer av projekt på grund av sin specificerade definition som betonar små och samlade team, vilket komplicerar appliceringen i andra kontexter, till exempel distribuerade team. 4

10 2.2 Agil utveckling Agil utveckling kan ses som en form av systemutvecklingsmetod, som har varit ett centralt område sedan datorer blev hjälpmedel för informationshantering och ses som en central del i många, om inte alla verksamheter (Björkholm & Brattberg 2010). Systemutveckling sker på två olika vis generellt sett. Traditionellt som innebär mycket dokumentation och liten flexibilitet, där kända metodansatser är vattenfallsmetod och RUP, eller kan systemutveckling också ske agilt, som tar hand om förändringsbehoven men inte lägger lika stor vikt på dokumentationen i utvecklingsprocessen (Björkholm & Brattberg 2010). De agila systemutvecklingsmetoderna har fyra saker gemensamt när det gäller själva leveransen av systemen och hur de bör gå till, enligt Björkholm och Brattberg (2010), och det är följande: Iterativa Som innebär att ett helt system levereras tidigt och sedan förändas dess funktionalitet med varje ny release. Inkrementella Det innebär att det system som specificerats i kraven delas in i delsystem med hänsyn till funktionalitet. Nya funktion läggs sedan till vid varje ny release. Självorganiserande Utvecklingsgruppen har en självständighet som innebär att de kan organisera sig själva på bästa sätt för att slutföra arbetet. Plötslig/framdykande Detta innebär att teknologi och krav tillåts att uppstå genom hela produktutvecklingens cykel. 2.3 Nationell och internationell distribuering - outsourcing av agila metoder Under det senaste årtiondet har stora ansträngningar gjorts för att konvertera lokala marknader till nationella och internationella marknader (Nuevo et al. 2011). Detta scenario involverar mer konkurrens och samarbete mellan företag men också en hel del utmaningar uppstår, som till exempel fel i projekt eller brist på resurser, som också finns behov av att lösa (Alqahtani et al. 2013). Både agil och distribuerad mjukvaruutveckling är växande trender eftersom utvecklingen av mjukvara kräver snabbare produktion samtidigt som samma kvalitet levereras, men till ett billigare pris (Shrivastava & Date 2010). Shrivastava och Date (2010) menar att många agila metoder utgår ifrån att teamet är samlat i ett och samma rum, men tyvärr passar inte denna princip inte in på agila team som är nationellt och internationellt distribuerade. Faktorer som expanderande affärsmöjligheter, skapandet av en arbetsstyrka som håller högre kvalitet eller reducerade kostnader genom outsourcing är alla en form av drivkraft för att expandera från lokalt till nationellt och internationellt (Shrivastava & Date 2010). Shrivastava och Date (2010) nämner i sin artikel att det allt mer nationella, internationella och outsourcande tänkandet inte ligger i linje med det agila konceptet som säger att det agila teamet bör sitta i samma rum. Därför ökar behoven av en expansion av den agila praxisen ytterligare. Vidare nämns också att många problem uppstår samt förstärks vid expansionen av agila metoder. Dokumentationen blir bristande eftersom inte teamet sitter samlat, vilket resulterar i att detaljer går förlorade. Detta i kombination med konversationer som ofta blir fattiga på innehåll och detaljer skapar en dokumentation som saknar kvalitet (Alqahtani et al. 2013). En annan aspekt att tänka på vid distribueringen av agila metoder är att många agila aktiviteter försvåras, som till exempel parprogrammeringen där två medlemmar i teamet arbetar sida vid sida på samma kod. Detta innebär att teamen behöver använda sig av andra, likvärdiga lösningar till detta problem (Jalali 2012). Arbetstiderna kan dessutom skilja åt, och planeringen samt schemaläggningen kan variera från kontor till kontor eftersom alla team har olika behov (Jalali 2012, Shrivastava & Date 2010). Men Alzoubi et al. (2015) menar samtidigt att den distribuerade konstellationen kan minska produktionskostnader samtidigt som tillgång till mer arbetskraft existerar. Vid träning samt studerande av agila metoder hos nya medlemmar kan bristen på kommunikation på grund av distribueringen leda till bristande kunskap inom området, vilket kan komma att skapa 5

11 problem i framtiden (Majchrzak et al. 2012). Lahiri (2010) nämner att kvaliteten av innovationer blir lidande när distribueringen av utvecklingen blir alldeles för bred. Om teamet är starkt integrerat över flera orter går det att dra större nytta av distribueringen. Fördelningen av arbetet inom projektet kan också komma att påverkas och kan bli ett stort hinder, därför är det viktigt att fördelningen av arbetet inte sker enligt den nationella placeringen, detta kan leda till en arkitektur som reflekterar teamets nationella distribution (Alqahtani et al. 2013). Detta kan leda till överspecialisering inom områden, på ett av kontoren. Detta är ett problem eftersom det är meningen att arbetet i agila metoder bör fördelas utefter user stories och inte specifika komponenter eller kompetensspecialisering (Shrivastava & Date 2010). 2.4 Scrum Scrum är en metod som är designad för att angripa komplexa, adaptiva problem samtidigt som det produktivt och kreativt levererar produkter med det högsta möjliga värdet. Scrum är en lättviktig metod som är lätt att förstå men som är svårt att bemästra (Schwaber & Sutherland 2014). Scrum är en metod som använts för att hantera komplex produktutveckling sedan början av 90-talet (Nyman 2010). Det är inte en process eller teknik för att bygga produkter men det anses istället vara en metod där team kan utnyttja processer och tekniker. Scrum tydliggör den relativa effektiviteten i produktstrategierna och utvecklingsmetoderna att teamet kan göra förbättringar (Schwaber & Sutherland 2014). Scrum består av ett utvecklingsteam samt deras roller, aktiviteter, artefakter och regler. Varje del i denna metod tjänar ett särskilt syfte för framgångsrik användning av Scrum, och varför det? Främst för att metoden är lättviktig och endast det som anses vara viktigast är med (Schwaber & Sutherland 2014). Reglerna som existerar inom Scrum knyter samman aktiviteterna, rollerna och artefakterna samt styr hur de samverkar och relaterar till varandra (Majchrzak et al. 2012). Scrum har sina grunder i empirisk processtyrningsteori, eller empirism. Empirismen säger att kunskapen kommer av erfarenheter och av beslutsfattande som baseras på det som är känt (Lindvall et al. 2002). Scrum använder ett iterativt, inkrementellt tillvägagångssätt, likt många andra agila metoder, för att optimera förutsägbarhet och för att göra det möjligt att hantera risk, enligt Schwaber och Sutherland (2014). Schwaber och Sutherland (2014) samt Lindvall et al. (2002), nämner också att varje implementation av empirisk processtyrning vilar på tre stycken pelare och det är transparens, granskning och anpassning. Juyun (2008) förklarar att transparens innebär att alla processens aspekter bör vara synliga och transparenta för de som ansvarar för resultaten. För att uppnå en transparens genom projektet/arbetet krävs det att vissa delar är definierade i en gemensam standard att alla som har tagit del av resultatet har en förståelse för det som teamet ser. Schwaber och Sutherland (2014) tar upp några exempel: Ett gemensamt språk rekommenderas för alla deltagare när teamet talar om processen. De som utför arbetet och de som accepterar det bör ha en gemensam definition av klart. Granskning är tillgängligt för användare av Scrum som möjliggör granskning av Scrums artefakter och arbete främst för att upptäcka eventuella avvikelser (Juyun 2008). Granskningarna i sig bör inte ske tillräckligt frekvent i den grad att de stör arbetets process och planer. Granskningar är effektivast och väldigt givande när de utförs noggrant och regelbundet av en utsedd, skicklig granskare i anslutningen till själva arbetet (Sutherland et al. 2008). En anpassning kan göras om en granskare upptäcker att aspekter, artefakter och aktiviteter avviker utanför acceptabla gränser och den resulterade produkten inte accepteras, vilket i sig leder till att en justering av processen eller att materialet bearbetas främst för att minska ytterliga avvikelser (Sutherland et al. 2008). Scrum har fyra gransknings- och anpassningstillfällen inom en sprint, och kan kallas för aktiviteter (Schwaber & Sutherland 2014). Aktiviteterna är: Sprintplanering Dagligt möte Sprintgranskning Sprintåterblick 6

12 2.4.1 Scrumteamet Enligt Schwaber och Sutherland (2014) består Scrums team av produktägare, utvecklingsteamet, och en Scrum master. Utvecklingsteam ses som självorganiserade och tvärfunktionella. De självorganiserande teamen kan själva välja hur de bäst kan utföra sitt arbete istället för att styras av andra utanför teamet vilken skulle leda till förvirring och avvikelser i och med att personen i fråga inte har samma kunskap om projektet som personerna inom projektet/teamet (Sutherland et al. 2008). Tvärfunktionella, linjära team har alla de kompetenser som krävs för att utföra arbetet enligt specifikation utan att vara beroende av andra som inte är en del av teamet (Alzoubi et al. 2015). Jansson (2015) berättar att de arbets-relaterade relationerna är viktigare än vänskaps-relationerna för att skapa ett sammansvetsat team. Utvecklingsteam levererar produkter enligt plan på ett iterativt och inkrementellt sätt för att maximera möjligheterna till återkoppling. Inkrementella leveranser av en klar produkt möjliggör användandet av en potentiellt användbar version som alltid finns till hands, enligt Schwaber och Sutherland (2014) Produktägare Enligt Schwaber & Sutherland (2014) ligger produktägarens ansvar på att maximera produktens värde och arbetet som utvecklingsteamet utför. Detta tillvägagångssätt kan variera från fall till fall eftersom individer, utvecklingsteam och organisationer har olika mål, ambitioner och intressen (Deemer et al. 2009). Det är produktägaren som har ett ensamt ansvar för själva hanteringen av produktbacklogen och denna hantering innebär enligt Schwaber och Sutherland (2014) att: Tydligt beskriva posterna i produktbacklogen Ordna posterna i backlogen för att bäst uppnå mål och fullfölja uppgifter Optimera värdet av det arbete som utvecklingsteamet utför Se till att produktbacklogen är synlig, transparent och tydlig för alla, och att den visar vad utvecklingsteamet ska arbeta med härnäst Se till att utvecklingsteamet förstår posterna i produktbacklogen tillräckligt bra Björkholm och Brattberg (2010) nämner att det är produktägaren som på egen hand bör utföra arbetet ovan men det är möjligt att i vissa fall även låta utvecklingsteamet göra det, ansvaret för arbetet ligger fortfarande på produktägaren dock. Produktägaren som namnet avslöjar, är en enskild person och inte en kommitté (Schwaber & Sutherland 2014). Produktägaren kan dock välja att ta med önskningarna från en kommitté i produktbacklogen, fast om en post i backlogen förändras bör detta tas med produktägaren eftersom huvudansvaret ligger på denne. Hela organisationen bör därför respektera produktägarens beslut för att produktägaren ska lyckas och besluten som tas av denne är synliga genom innehållet och ordningen av självaste produktbacklogen (Björkholm & Brattberg 2010). Ingen får dela ut uppdrag åt utvecklingsteamet som de behöver arbeta med, utifrån andras krav, och utvecklingsteamet har inte tillåtelse att agera i enlighet med vad någon annan säger (Eckhart & Feiner 2016) Utvecklingsteamet Sutherland et al. (2008) menar att utvecklingsteamet består av yrkesmänniskor som levererar potentiellt releasebara iterationer av en klar produkt genom sitt arbete i slutet av varje sprint, och det är endast medlemmarna inom utvecklingsteamet som har rätt att bidra till att framställa produktinkrement. Enligt Schwaber och Sutherland (2014) sätts utvecklingsteam samman av organisationen och ges befogenheter att organisera och styra sig själva i sin riktning och det är tänkt att detta resulterar i en synergi som optimerar teamets kapacitet och effektivitet (Schwaber & Sutherland 2014). Teamet i sig kan även kännetecknas genom följande, vilket Sutherland et al. (2008) nämner: Att de är självorganiserade. Ingen bör tala om för teamet hur de behöver omvandla produktbacklogen till inkrement av potentiellt releasebar funktionalitet, detta betyder att inte produktägaren bör lägga sig i heller. 7

13 I Scrum-team tillåts inte individuella titlar. Titeln är utvecklare, oavsett vilket arbete var och en utför, och inget undantag kan göras till denna specifika regel. Scrum väljer att inte erkänna del-team inom det specifika utvecklingsteamet oavsett vilka domäner som adresseras, t.ex. testning eller verksamhetsanalys. Enskilda medlemmar inom teamet kan möjligen ha en specialkompetens inom ett visst område men det överliggande ansvaret ligger fortfarande hos teamet i sin helhet. Schwaber och Sutherland (2014) säger i sin artikel att den optimala storleken för ett utvecklingsteam är litet nog för att jobba smidigt och stort nog för att åstadkomma något av värde i en sprint. Färre än tre resulterar i lägre produktivitetsvinster, vilket också kan leda till att teamet saknar rätt kompetens och färdighet för att utföra något under en viss sprint, vilket i sig orsakar att teamet inte kan leverera något potentiellt releasebart inkrement (Schwaber & Sutherland 2014). Fler än nio medlemmar kräver för mycket samordning och ger det hela för mycket komplexitet för att faktiskt klara av att hanteras av en empirisk process. Det är värt att notera att produktägaren samt Scrum mastern inte räknas in i teamet, om inte dem också utför arbete inom sprintbacklogen (Nuevo et al. 2011) Scrum master Enligt Schwaber och Sutherland (2014) ansvarar Scrum mastern för att säkerställa att Scrum förstås och efterlevs inom hela teamet. Detta görs genom att se till att alla håller sig till teorin, tillämpningar och regler inom Scrum. Denna person kan ses som en tjänande ledare för hela utvecklingsteamet (Schwaber & Sutherland 2014). Scrum mastern fungerar också som en brygga mellan utomstående för att hjälpa andra att begripa vilka av deras interaktioner med utvecklingsteamet är till faktisk nytta och vilka som inte är till lika stor nytta. Interaktionerna förändras av Scrum mastern för att maximera värdet som skapas av teamet (Schwaber & Beedle 2002). Enligt Schwaber och Sutherland (2014) är Scrum mastern där för att hjälpa produktägaren på flera sätt: Finna tekniker för effektiv hantering av produktbacklog Hjälpa utvecklingsteamet att förstå behov av tydliga och koncisa poster i produktbacklog Förstå produktplanering i en empirisk miljö Säkerställa att produktägaren vet hur denne ordnar produktbacklog för att maximera värdet Förstå och praktisera det agila tankesättet Vägleda vid Scrums aktiviteter om han eller hon ombeds att göra det eller om det behövs Schwaber och Sutherland (2014) nämner också att Scrum mastern gör nytta för utvecklingsteamet på följande sätt: Coacha utvecklingsteamet i självorganisering och tvärfunktionalitet; Hjälpa utvecklingsteamet i att skapa produkter med högt värde Undanröja hinder för utvecklingsteamets framsteg Vägleda vid Scrums aktiviteter om det efterfrågas eller behövs Coacha utvecklingsteamet i organisationer där Scrum ännu inte har införts eller förståtts fullt ut Schwaber och Sutherland (2014) vad Scrum mastern bidrar med till organisationen som helhet: Leda samt coacha organisationen i dess införande av Scrum Planera införandet av Scrum i organisationen Hjälpa medarbetare och intressenter förstå samt utöva Scrum och en empirisk produktutveckling Få till en förändring som ökar produktiviteten hos utvecklingsteamet Arbeta tillsammans med andra Scrum masters för att få ut mer av användandet av Scrum inom organisationen 8

14 2.5 Scrums aktiviteter Aktiviteterna som Scrum använder sig av är tillgängliga främst för att skapa en regelbundenhet och för att minska behovet av aktiviteter som inte officiellt definierats i Scrums regler. Alla aktiviteterna tidsbegränsas och får en maxlängd som de kan köras (Pries-Heje & Pries Heje 2011). När en sprint är påbörjad är tidsomfattningen fastställd, vilket innebär att den inte får förlängas eller förkortas under sprintens gång. Återstående aktiviteter kan avslutas fort när syftet är uppnått, dock inte passera den maximala tiden, det är för att minska bortslösad tid (Pries-Heje & Pries Heje 2011). Schwaber och Sutherland (2014) nämner att varje aktivitet utöver sprinten inom Scrum ger tillfälle att granska eller anpassa något. De aktiviteterna är utformade specifikt för att möjliggöra en kritisk transparens och granskning. Om en viss aktivitet utelämnas helt kan detta innebära en minskad transparens och detta leder i sig till ett förlorat tillfälle för granskning och anpassning (Schwaber & Sutherland 2014) Sprint Sprinten ses av många som Scrums hjärta (Schwaber & Sutherland 2014). Björkholm och Brattberg (2010) nämner att sprinten är en begränsad tidsperiod på en månad eller mindre. Under denna tid bör ett klart och användbart, potentiellt releasebart produktinkrement tas fram. Längden på sprinten hålls oftast konstant under hela utvecklingen. Efter att en pågående sprint avslutats, tar en ny sprint vid. En sprint omfattas av sprintplanering, dagliga Scrum möten, utvecklingsarbeten, sprintgranskning och sprintåterblick (Björkholm & Brattberg 2010). Schwaber och Sutherland (2014) rekommenderar att inga förändringar som kan äventyra sprintens mål utförs, kvalitetsmål bör inte heller sänkas under sprinten eftersom att även omfattningen förtydligas och omförhandlas mellan produktägare och utvecklingsteam allt mer eftersom alla lär sig mer under arbetets gång. Sutherland et al. (2006) anser att det går att se varje sprint som ett separat projekt med en månads horisont som längst. Lika som projekt, använder teamet sig av sprintar för att åstadkomma något. Inom varje sprint existerar en definition av allt som behöver byggas och designas och en flexibel plan som är tillgänglig som vägledning under arbetets gång, och självklart den kompletta produkten som bör vara med under varje release (Sutherland et al. 2006). Björkholm och Brattberg (2010) rekommenderar en begränsning av sprintar till högst en hel kalendermånad för att definitionen av vad som behöver byggas kan komma att ändras om denna passeras, vilket ökar komplexitet inom projektet, vilket i sig kan öka riskerna. Riskerna kan leda till en produkt vid slutet av sprinten som inte är komplett, och kan inte ses som releasebar. Deemer et al. (2009) menar också att sprintar är designade för att möjliggöra en förutsägbarhet genom att se till att granskning och anpassning sker minst en gång per sprint (Figur 2). 9

15 24 timmar 2-4 veckor Produktbacklogg Sprintbacklogg Leveransbart Figur 2: Sprintcykel: Visualisering av sprint-cykeln Källa: Modifierad utifrån Deemer et al. (2009:3) Schwaber & Sutherland (2014) samt Deemer et al. (2009) menar att sprintar kan avbrytas tidigare men endast produktägaren har befogenheterna som krävs för att göra detta. Varför teamet väljer att avbryta en sprint kan bero på en rad med faktorer. Det kan till exempel ske något inom projektet som gör att sprinten inte längre blir aktuell, företaget kan också påverkas av faktorer som ändrade marknadsvillkor, ändrade tekniska förutsättningar eller ekonomiska förutsättningar. Men det är sällan som detta sker på grund av den lilla tidsrymden inom en sprint (Schwaber & Sutherland 2014). Om produktägaren väljer att avbryta sprinten bör färdigställda samt klara ärenden från produktbacklogen granskas för att avgöra om arbetet är releasebart eller inte. Om det är potentiellt releasebart, godkänns det normalt av produktägaren. Ärenden som inte anses vara klara ges nya estimat för att sedan återinföras tillbaka in i produktbacklogen (Sutherland et al. 2008). Enligt Björkholm och Brattberg (2010) bör det arbetet som behöver genomföras i en sprint planeras under sprintplaneringen (Figur 3). Alla inom utvecklingsteamet deltar vid planeringen för att alla behöver bli informerade över det som bör utföras inom sprinten. För en sprint som är en månad lång bör sprintplaneringen maximalt ta åtta timmar (Schwaber & Sutherland 2014). Det är upp till Scrum mastern att se till att alla inom utvecklingsteamet är införstådda i allt som behöver göras och att hela teamet håller sig till tidsplaneringen inom tidsramen. Vid sprintplaneringen är det viktigt att teamet definierar vad som bör utföras under sprinten, vad som bör levereras inom iterationer som denna sprint resulterar i, samt hur teamet åstadkommer detta (Schwaber & Sutherland 2014). 10

16 Produktbacklogg Leveransbar produkt Demo Sprintbacklogg Första veckan Andra veckan Sprintplanering Dagliga Scrum Återblicksmöte Figur 3: Scrums process Källa: Modifierad utifrån Björkholm och Brattberg (2010:13) I varje sprint har teamet ett sprintmål (Schwaber & Sutherland 2014). Det är tänkt att funktionera som vägledning för utvecklingsteamet och för att besvara frågan till varför teamet bygger den här produkten. Sprintmålen skapas också under sprintplaneringen och är tänkt att ge teamet en viss flexibilitet vid utvecklingen. Ärendena från produktbacklogen som valts ut till denna sprint bör leverera en sammanhängande funktion som kan vara sprintmålet (Schwaber & Sutherland 2014) Releasecykler Sutherland (2005) menar att inom sprintar arbetar teamet i releasecykler som kan vara organiserade på specifika, fördefinierade sätt (Figur 4). Det existerar isolerade releasecykler, överlappande releasecykler och alla på en gång (Sutherland 2005, Takeuchi & Nonaka 2004). Inom isolerade releasecykler sker all form av utveckling i en iteration åt gången, alltså är en releasecykel lika med en sprint. Isolerade releasecykler har driftstopp mellan varje iteration för att möjliggöra en organisering av nästa sprint/releasecykel. Driftstoppet ger teamet möjligheten att planera en sprint mycket noggrant och på det viset öka varje iterations produktivitet (Takeuchi & Nonaka 2004). Figur 4: Releasecykler Källa: Modifierad utifrån Sutherland (2005:1) Genom att börja arbeta med produktbacklogen på nästa sprint/releasecykel under tiden som den nuvarande sprinten pågår eliminerar teamet driftstoppet och förlorar mindre tid, Sutherland (2005) menar dessutom att den överlappande releasecykeln är ett gott alternativ för internationellt distribuerade utvecklingsteam som inte ligger inom samma tidszon, samtidigt som det är ett relativt ovanligt angreppssätt (Takeuchi & Nonaka 2004). Alla på en gång syftar på att samma utvecklingsteam kör överlappande releasecykler där samma team släpper flera releaser genom samma sprint, vilket kräver mycket erfarna utvecklingsteam, produktarkitekturer med effektiv design och 11

17 automatisering av produkt- samt sprintbacklog (Sutherland 2005, Takeuchi & Nonaka 2004). Teamet bör vara sammansvetsat och alla i teamet bör ha en global syn på hela projektet på en daglig basis, d.v.s. graden av transparens genom teamet bör vara stor (Takeuchi & Nonaka 2004) Dagliga möten Enligt Sutherland et al. (2008) är det dagliga mötet en av de viktigaste beståndsdelarna i Scrum. Mötet har en begränsning satt till en tidsperiod på 15 minuter och alla i utvecklingsteamet bör samlas för att tillsammans samordna arbetet och planera arbetet som behöver genomföras det nästkommande dygnet, vilket är för att främja kommunikation och samarbete som anses vara viktigt i Scrum (Agile manifesto 2001). Det genomförs främst genom att granska arbetet som redan har utförts sedan förra mötet och skapa en prognos för vad som bör göras innan nästa. Genom att göra dagliga prognoser över vad som bör göras till nästa möte minskar felaktigheten på estimeringarna (Björkholm & Brattberg 2010). Björkholm & Brattberg (2010) gör en jämförelse och menar att det kan liknas vid prognoserna vi får genom väderleksrapporter. Vi får bra uppskattningar av vädret imorgon, samtidigt som vi får lite mindre precision för några dagar framåt, och för flera veckor framåt fås en prognos som inte säger mycket, men för varje dag som går tillkommer ny information som gör att prognoserna ändras (Björkholm & Brattberg 2010). Björkholm & Brattberg (2010) menar att det är av precis samma anledning som teamet har det dagliga mötet, för att minska felaktigheter i prognoser, vilket i sig effektiviserar teamet genom att minska storleken på problemen som kan uppstå. Det är rekommenderat att det dagliga mötet hålls på samma plats, vid samma tid för att minska komplexiteten (Schwaber & Sutherland 2014). Vidare förklarar Schwaber och Sutherland (2014) att vid detta möte redovisar alla medlemmarna i teamet vad de har gjort igår för att hjälpa teamet att nå sprintens mål, vad de har planerat att göra idag för att hjälpa teamet att nå sprintens mål, och om medlemmarna ser några hinder från att nå målen med sprinten? Mötet används för att enklare estimera hur teamet ligger till i förhållande till sprintmålet för att avgöra om teamet är i fas med planeringen för att genomföra arbetet i sprintbacklogen eller om teamet ligger efter. Efter det dagliga mötet kan fortfarande teammedlemmar separat ha möten och djupare diskussioner mellan varandra för att anpassa eller omarbeta en specifik del av sprinten. Men under det dagliga mötet håller teamet sig till specifika ramar med hjälp av Scrum mastern som har i uppgift att se till att mötet inte spårar ur och fortsätter mer än 15 minuter. Schwaber och Sutherland (2014) menar dessutom att mötet i längden kan förbättra teamets kommunikation samtidigt som behovet av andra möten elimineras samtidigt som hinder identifieras i tid. Det främjar snabba beslut vilket dessutom kan förbättra teamets kunskapsnivå (Schwaber & Sutherland 2014) Sprintgranskning, Sprintåterblick & Sprintplanering Vid slutet av varje sprint inom projektet gör teamet en sprintgranskning för att granska inkrement och anpassa produktbacklogen (Schwaber & Sutherland 2014, Marchenko & Abrahamsson 2008). Marchenko och Abrahamsson (2008) förklarar att teamet samarbetar vid sprintgranskningen tillsammans med andra intressenter för att anpassa produktbacklogen, och för att prata om vad som har gjorts under sprinten. Baserat på eventuella förändringar i produktbacklogen samarbetar teamet för att komma fram till vad som behöver göras för att optimera värdet mer. Det kan ses som en informell typ av möte och alltså inte någon form av statusrapportering som till exempel det dagliga mötet till en viss del fungerar som. Schwaber och Sutherland (2014) berättar att den här typen av möten också begränsas inom sprinten, oftast till en period på 4 timmar per sprint beroende på sprintens längd, mötet planeras av Scrum mastern som ser till att tiderna följs. En sprintgranskning omfattas av följande moment enligt Schwaber och Sutherland (2014): Produktägaren förklarar vilka poster ur produktbacklogen som blivit klara och vilka som inte blivit klara Utvecklingsteamet diskuterar vad som gått bra under sprinten, vilka problem de råkade på och hur de problemen löstes Utvecklingsteamet demonstrerar arbetet som är klart och svarar på frågor om inkrement Produktägaren berättar om produktbacklogens tillstånd. Baserat på de hittills gjorda 12

18 framstegen lämnar han eller hon en prognos för troliga slutdatum (om det behövs) Hela gruppen samarbetar om vad som ska göras härnäst, vilket ger sprintgranskningen värdefullt underlag till kommande sprintplanering Granskning av hur marknaden eller den tänkbara användningen av produkten kan ha ändrat vad som är det mest värdefulla att göra härnäst Granskning av tidsaspekter, budgeten, tänkbara egenskaper och marknaden för nästa förväntade release av produkten Björkholm och Brattberg (2010) nämner att sprintgranskningen resulterar i en produktbacklog som nu är uppdaterad och förhåller sig till ärendena för nästa sprint. Om nya möjligheter önskas ta vara på kan teamet också utföra justeringar som helhet i produktbacklogen. Sprintåterblicken är en annan form av möte, och fungerar som ett retrospektivt tillfälle som används för att blicka tillbaka på tidigare prestationer inom utvecklingsteamet för det pågående projektet (Björkholm & Brattberg 2010). Det tillåter medlemmarna att granska sina egna prestationer, och skapa planer för att förbättras inför kommande sprintar. Sprintåterblickarna bör ske efter varje sprintgranskning men före nästa sprintplanering (Schwaber & Sutherland 2014). Tiden som allokeras för denna typ av möten varje sprint är ungefär tre timmar beroende på sprintens totala längd. Huvudsyftet med återblicken är att se hur personer, relationer, processer och verktyg har funktionerat under föregående sprint, vilket i sig bör leda till förbättringsplaner. Det är upp till Scrum mastern att se till att utvecklingsteamets medlemmar förhåller sig till återblicken (Sutherland et al. 2006). Efter att sprintgranskningarna och sprintåterblickarna har genomförts påbörjas nästa sprintplanering (Schwaber & Sutherland 2014). Sprintplaneringen är ett tidsbegränsat möte som främst dedikeras till utveckling av detaljerade planer för framtida sprintar (Hossain et al. 2009). Beslut om vad som behöver åtas i sprintbacklog beslutas gemensamt under planeringen (Schwaber & Sutherland 2014, Hossain et al. 2009). Sprintplaneringen är tidsbegränsad till maximalt åtta timmar för en sprint på en månad, men för kortare sprintar är aktiviteten vanligtvis kortare (Hossain et al. 2009). Scrum mastern ser till att aktiviteten äger rum och att deltagarna förstår dess syfte. Scrum mastern lär teamet att hålla planeringen inom tidsramen (Schwaber & Sutherland 2014). Hossain et al. (2009) menar att sprintplaneringen bör besvara frågor som t.ex. vad målet med sprinten är, vad kan levereras i det inkrement som kommande sprint resulterar i, hur bör arbetet som krävs för att åstadkomma inkrementet utföras. Björkholm och Brattberg (2010) menar att det oftast tas fram prognoser under sprintplaneringen för att skapa och sätta reella mål för utvecklingsteamet under sprinten. 2.6 Scrums artefakter Björkholm & Brattberg (2010) berättar att Scrum innehåller ett antal artefakter och i detta sammanhang syftar artefakterna till att representera arbete eller värde på olika sätt som kan tänkas ge transparens men också möjliggöra, granskning och anpassning. Artefakterna som utformats i Scrum bör maximera transparensen av nyckelinformation, vilket leder till att alla kan inneha samma förståelse för artefakten (Schwaber & Sutherland 2014). Artefakterna i Scrum kallas för: produktbacklog, sprintbacklog och produktinkrement eller enbart inkrement, samt består det även av valbara artefakter som t.ex. burndown diagram (Schwaber & Sutherland 2014) Produktbacklog Jeldi och Chavali (2013) nämner att produktbacklogen är en komplett lista över allt som kan komma att behöva göras inom produktens väggar, det är allt som kommer in från beställarna i form av user stories. Det anses vara den enda källan av krav till ändringar och arbetsuppgifter som behöver utföras inom produkten. Björkholm och Brattberg (2010) nämner att det är produktägaren som ansvarar för produktbacklogen och dess innehåll, åtkomsten till produktbacklogen men också ordningen på alla ärenden i produktbacklogen. Det är produktägaren som dirigerar utvecklingsteamet och därför också ordningen av uppgifterna. Det kan givetvis förändras i samtal med utvecklingsteamet (Björkholm & Brattberg 2010). 13

19 Schwaber och Sutherland (2014) berättar att en produktbacklog aldrig kan bli helt komplett men det ses istället som en dynamisk lista som växer fram allt mer i och med produktens och miljöns utveckling där det är planerat att produkten verkar. Därför är det viktigt att endast kända och förstådda krav, eller ärenden som det också kallas, ställs fram i produktbacklogen för att göra produkten konkurrenskraftig och användbar som möjligt. Schwaber och Sutherland (2014) menar också att produktbacklogen därför behövs lika länge som produkten existerar. Genom produktbacklogen definieras alla egenskaper, förbättringar, krav, funktioner och rättningar som utgör alla de förändringar som bör utföras i produktens framtida releaser. Poster i produktbacklogen har attributen: beskrivning, ordning, estimat och värde (Schwaber & Sutherland 2014). I och med att produkten utvecklas och växer i form av värde kommer mer återkopplingar in, vilket i sig leder till att produktbacklogen blir mer omfattande (Jeldi & Chavali 2013). Jeldi och Chavali (2013) menar att denna artefakt är dynamisk eftersom det kan komma in förändringar från kunden i själva kraven, villkoren eller genom tekniska aspekter. Vidare kan produktbacklogen vid olika tillfällen förfinas, vilket innebär att detaljer och estimat läggs in i ärenden, vilket är en ständigt pågående process som aldrig bör kräva mer än tio procent av utvecklingsteamets totala kapacitet (Björkholm & Brattberg 2010, Jeldi & Chavali 2013) Sprintbacklog Björkholm och Brattberg (2010) förklarar att sprintbacklogen är precis som namnet avslöjar en mindre version av produktbacklogen som existerar inom en sprint. Det är en uppsättning av ärenden som tagits från produktbacklogen och placerats i sprinten tillsammans med planen för produktinkrement, vilket används för att nå sprintens mål. Schwaber och Sutherland (2014) menar att sprintbacklogen fungerar som en prognos av utvecklingsteamet som är framställd för att avgöra vilken funktionalitet som bör vara med vid nästa inkrement och det arbetet som krävs för att utföra samt leverera funktionaliteten som utgör det klara inkrement (Schwaber & Sutherland 2014). Utvecklingsteam kan modifiera sprintbacklogen under sprintens gång, vilket teamet gör främst för att förändringar kan ske i takt med att teamet blir allt mer införstådda i sprinten (Nuevo et al. 2011). Vid varje dagligt dagligt möte summeras den totala återstående arbetsmängden i sprinten för att beräkna och avgöra hur troligt det är att teamet blir klart med arbetet i tid, och det styr upp arbetet (Schwaber & Sutherland 2014) Produktinkrement Schwaber och Sutherland (2014) samt Sutherland et al. (2008) förklarar att produktinkrement också kallat inkrement, är alla ärenden från produktbacklogen som har färdigställts under en specifik sprint. Vid slutet av varje sprint bör nya inkrement vara klara, detta innebär att de behöver vara i ett användbart skick och uppfylla utvecklingsteamets definition av klart och denna definition kan ibland skilja sig åt, vilket gör detta väldigt olika från fall till fall. Men det bör vara användbart oavsett om produktägaren väljer att leverera det eller inte (Schwaber & Sutherland 2014, Sutherland et al. 2008). 2.7 Scrums tre pelare Schwaber och Sutherland (2014) förklarar att Scrum är grundat på empirisk processtyrningsteori där kunskap kommer från erfarenheter och beslutsfattande som baseras på sådant som är känt. Ett iterativt, inkrementellt tillvägagångssätt används för optimeringen av förutsägbarheten och hanteringen av risker. Implementationen av den empiriska processtyrningen grundar sig i tre pelare som är anpassning, transparens och granskning (Plohmann et al. 2013, Juyun 2008, Deemer et al. 2009). Transparensen avgör hur synliga och förstående samtliga delar av processen är för deltagarna. För att uppnå en hög nivå av transparens krävs det att alla delar är definierade och standardiserade, för att samtliga som tar del av resultaten också har en gemensam förståelse för allt. Exempel på transparens kan vara användandet av samma språk vid talandet av processerna eller att teamet har en gemensam definition av vad klart innebär som delas mellan de som står bakom arbetet och de som accepterar arbetsresultatet (Plohmann et al. 2013, Juyun 2008, Deemer et al. 2009). Plohmann et al. (2013) samt Juyun (2008) och Deemer et al. (2009) menar att granskning innebär att de som använder Scrum 14

20 granskar Scrums artefakter och arbete mot ett mål för att upptäcka eventuella oönskade avvikelser. De granskningarna bör inte ske i den grad att de påverkar arbetets gång, därför är det mest optimala alternativet att skickliga granskare utses i anslutning till arbetet (Plohmann et al. 2013, Juyun 2008, Deemer et al. 2009). Vidare menar Plohmann et al. (2013) samt Juyun (2008) och Deemer et al. (2009) att anpassningen säger att om eventuellt en utsedd granskare ser aspekter av en process, artefakt eller arbete som avviker utanför de utsatta gränserna, som inte kan accepteras, bör justering ske av det som avviker och därför bör också en anpassning ske omgående för att ytterligare minimera avvikelsen som redan har skett. Schwaber och Sutherland (2014) menar att det är möjligt att se fyra formella gransknings- och anpassningstillfällen i Scrum, de kan också beskrivas som aktiviteter. Aktiviteterna är sprintplaneringen, det dagliga mötet, sprintgranskningen och sprintåterblicken (Plohmann et al. 2013, Juyun 2008, Deemer et al. 2009, Schwaber & Sutherland 2014). 2.8 Inre projekteffektivitet inom agila metoder Effektivitet i sig är ett brett begrepp som kräver en precision vid användandet. Jacobsen et al. (2008) nämner att effektivitet är ett begrepp som används för att beskriva hur väl företag, personer och organisationer klarar av att producera produkter och tjänster med hjälp av resurserna som är tillgängliga. Jacobsen et al. (2008) nämner också att det går att dela upp projekteffektivitet i yttre och inre projekteffektivitet, där yttre projekteffektivitet kan definieras som att göra rätt saker, och inre projekteffektivitet är att göra saker rätt, att ha ett internt perspektiv som skall leda till strukturering inom själva företaget eller organisationen. Jalali (2012) nämner att agila metoder inte är tillräckligt effektiva i stora organisationer och specifika typer av projekt på grund av sin specificerade definition som betonar små och samlade team, vilket komplicerar appliceringen i andra kontexter, till exempel distribuerade team. Jalali (2012) menar också att det är svårt att hitta effektiva mekanismer inom distribuerade team för kontroll och koordinering av projekt. Dessutom nämner Jalali (2012) att distribuering resulterar i nya utmaningar men avståndet förstärker dessutom de redan existerande svårigheterna som hittas i samlokaliserade team. Det påverkar den inre projekteffektiviteten negativt (Jalali 2012). Eckhart och Feiner (2016) nämner att effektivitet inom agila metoder påverkas till större del av kommunikationen som sker inom teamet, de anser att den mest effektiva metoden att överföra information på är med direkt kommunikation, d.v.s. ansikte mot ansikte. Kommunikationen ses som den avgörande punkten när det gäller teamets effektivitet eftersom agila metoder främjar samarbete och kommunikation för att nå målen (Schwaber & Sutherland 2014). Eckhart och Feiner (2016) anser att bristande kommunikation leder till bristande transparens genom Scrums processer, och den bristande kommunikationen kan bero på distribueringen av teamet därför att kommunikationen sker via olika former av plattformar, vilket Eckhart och Feiner (2016) anser är en dålig ersättning för den direkta kommunikationen. Det blir helt enkelt för svårt för Scrum mastern att få medlemmarna att hålla kontakten, vilket resulterar i minskad effekt inom projektet (Eckhart & Feiner 2016). Jeff Sutherland som är en av grundarna av Scrum sökte under 80- och 90-talet efter mönster för hyperproduktiva team. Han besökte olika team för att försöka finna gemensamma mönster bland de team som var effektivare än alla andra. Han hittade mönster som senare blev grunden för Scrum. Däribland hittas punkter som till exempel samlokaliserade team, fokus på kommunikation mellan medlemmarna i utvecklingsteamet och betoning på samarbete mellan parterna som är involverade (Sutherland et al. 2008). Björkholm och Brattberg (2010) menar att agila metoder gör att teamet kan fokusera på rätt saker i rätt tid genom stenhård prioritering och fokus genom arbetet. Björkholm och Brattberg (2010) nämner att effektivitet kommer utifrån att människor mår bra och får jobba ostört. Det som motverkar effektiviteten brukar på engelska kallas för thrashing, till exempel när personer har så mycket att göra att de inte får något gjort. Björkholm och Brattberg (2010) beskriver några punkter som är vanliga orsaker till thrashing, som gör att effektiviteten minskar och kvaliteten blir sämre; att inte kunna hålla prioriteringen för de saker som påbörjats 15

21 att ständigt störa personer med sidopuckar att sätta mål som behöver uppnås, utan att medarbetarna fått påverka att trycka på och stressa människor att jobba hårdare att långvarigt jobba övertid att inte ta sig tid att reflektera och förbättra Projekteffektiviteten går hand i hand med transparensen, granskningen och anpassningen (Björkholm & Brattberg 2010). Björkholm och Brattberg (2010), Plohmann et al. (2013), Juyun (2008) och Deemer et al. (2009) menar alla att agila metoder sätter högt värde på transparens, det vill säga synliggöra och gärna visualisera vad som bör utvecklas för alla i teamet, vad som utvecklas just nu och när det beräknas bli klart. När information är lätt tillgänglig uppstår diskussioner. Allt är gott och väl när hälsosamma diskussioner uppstår, men om det händer att någon är obekväm med den information som blir synlig av olika anledningar, motverkar det viljan till synlighet. När allt fungerar som planerat föder transparens tillit som göder mer transparens, vilket blir en god spiral. Detta innebär att kommunicering mellan teamets medlemmar är viktig för att skapa transparens, vilket i sig gynnar projektets effektivitet (Björkholm & Brattberg 2010). 2.9 Analysmodell Miles och Huberman (1994) menar att en analysmodell beskriver de huvudsakliga delarna som studeras i en grafisk eller berättande form, genom användandet av nyckelfaktorer, hypotetiska konstrukter och variabler och deras förmodade förhållanden mellan varandra. Analysmodellerna kan vara enkla eller detaljerade, teoridrivna eller skapade med sunt förnuft, beskrivande eller orsaksmässiga (Miles & Huberman 1994). Maxwell (2005) menar att grafiska analysmodeller synliggör implicita teorier och klargör existerande teorier. Detta innebär att det är enklare att se gränserna för teorin, och dess relevans till undersökningen. Det är som att tänka på papper, vilket också möjliggör chansen att upptäcka samband, hål i teorin eller motsägelser som annars hade passerat oupptäckta (Maxwell 2005). Figur 5: Analysmodell över förhållanden i en distribuerad Scrum-process som påverkar den inre projekteffektiviteten Källa: Modifierad utifrån Schwaber och Sutherland (2011:16) 16

22 En analysmodell har framtagits för att bidra till ett ökat fokus för genomförandet av uppsatsarbetet (Figur 5). Analysmodellen är min syntes av den genomförda litteraturstudien. Analysmodellen har sedan operationaliserats i form av intervjuguiderna, d.v.s. för insamlingen av empiriska data. Analysmodellen fungerar också som en struktur för analysen. Analysmodellens utformning har med andra ord sin grund i den studerade litteraturen, som har haft den agila metoden Scrum som utgångspunkt. Alla aktiviteter och artefakter i Scrum-metoden har använts som utgångspunkt för att utforma analysmodellen, den innehåller också den inre projekteffektiviteten. Det eftersträvade positiva resultatet av Scrum-processen utgörs av den inre projekteffektiviteten (beroende variabeln), vilken bedöms i form av Scrums tre grundpelare, som behandlats tidigare i kapitlet: transparens, anpassning och granskning. Analysmodellen är planerad att fungera som fokus och struktur för analys-kapitlet, i vilket den insamlade empirin relateras till den presenterade teorin Inre projekteffektivitet Grundstenarna i denna analysmodell är först och främst Scrums tre pelare, transparens, granskning och anpassning som också Ken Schwaber och Jeff Sutherland redogör för i sin guide (Schwaber & Sutherland 2014). Juyun (2008) och Deemer et al. (2009) nämner att i Scrum-metoden används en empirisk processkontroll som har tre pelare som stöd för alla sina implementationer. De tre pelarna fungerar som en form av indikatorer för den inre projekteffektiviteten, d.v.s. den beroende variabeln (Jalali 2012). Den inre projekteffektiviteten avgörs av hur väl de tre grundpelarna är integrerade i företagets Scrum-process (Juyun 2008, Plohmann et al. 2013). Därför kan varje artefakt och aktivitet ses som en direkt koppling till de tre grundpelarna och den inre projekteffektiviteten som påverkanspilen indikerar i analysmodellen (Figur 5). Enligt Schwaber och Sutherland (2014) innebär transparensen att samtliga aspekter av processen som påverkar resultatet är något som teamet tillsammans bör ha en gemensam förståelse för. Allt bör vara känt av alla involverade i processen (Schwaber & Sutherland 2014, Plohmann et al. 2013). Granskning kräver att olika delar av processen granskas tillräckligt frekvent främst för att förhindra upptäckten av variationer i processen som inte har planerats för, vilket därigenom påverkar den inre projekteffektiviteten (Juyun 2008, Schwaber & Beedle 2002, Schwaber & Sutherland 2014). Anpassning kräver att den som inspekterar processerna också justerar processerna om en eller flera aspekter av processen har ett oacceptabelt omfång (Schwaber & Sutherland 2014). Juyun (2008) och Deemer et al. (2009) säger att de tre pelarna bör vara synliga genom hela arbetet för samtliga deltagare. Därför är det planerat att jag med hjälpen av analysmodellen ser närmare på hur det distribuerade utvecklingsteamet förhåller sig till de tre pelarna för Scrum i sina aktiviteter samt artefakter och hur uppdelningen påverkar dem genom att analysera varje artefakt och aktivitet i processen, för att sedan samla ihop allt och jämföra det med det teorin Team A - Team B och påverkanspilar Analysmodellen innehåller ett antal påverkanspilar, som symboliserar orsak-verkan-riktningar (Figur 5). I detta sammanhang representerar Team A och Team B inom analysmodellen tillsammans det distribuerade teamet, vilket fysiskt är allokerat på två orter. Alzoubi et al. (2015) menar att ett allt större fokus på mer pålitliga produkter och reducerade kostnader tvingar företag till sanktioner, detta innebär reformer av företagets interna struktur. Därför är teamets struktur direkt kopplad till utformningen av Scrum. Alqahtani et al. (2013) menar att teamets struktur påverkar slutresultatet av alla aktiviteter och artefakter. När teamet dessutom är uppdelat på flera orter kan det leda till en förstoring av redan existerande problem, samt uppkomsten av nya problem (Sutherland et al. 2008). Den streckade påverkanspilen som binder Team A samt Team B representerar kommunikationen mellan teamet under tiden som produktbacklogen påverkas av teamet gemensamt, vilket den heldragna pilen indikerar (Figur 5). Påverkanspilarna som binder samman de oberoende variablerna med 17

23 varandra representerar påverkan som sker genom analysmodellen, där varje heldragen påverkanspil syftar till att påvisa den påverkan som den föregående aktiviteten/artefakten har på den nuvarande aktiviteten/artefakten (Figur 5). Påverkanspilen som dras från rutan som representerar alla oberoende variabler tillsammans, till beroende variabeln, som är inre projekteffektivitet. Detta visar att samtliga oberoende variabler, ger en samlad påverkan på den inre projekteffektiviteten (Figur 5). Främst genom att påverka transparens, granskning och anpassning vilket också Sutherland et al. (2008) påpekar Produktbacklog Jeldi och Chavali (2013) menar att sprintar genomförs med hjälpen av en produktbacklog som innehåller att krav för det som utvecklas i form av user stories från kunden i den ordning som de också förväntas färdigställas men självklart sker justeringar, nedbrytningar och sammanslagningar under arbetets gång. Jansson (2015) samt Sutherland et al. (2008) förklarar att delarna bryts ner alternativt slås samman för att placeras i en sprintbacklog. Vid planeringen är det upp till produktägaren att informera teamet om allt som behöver föras vidare till sprintplaneringen (Jansson 2015, Sutherland et al. 2008). Prioritering utförs av produktägaren i samarbete med teamet främst för att sortera punkter som blir mer eller mindre viktiga inom arbetet (Björkholm & Brattberg 2010). Vidare berättar Björkholm och Brattberg (2010) därför att produktbacklogen behöver rangordnas, brytas ner i mindre delar, eller slås samman till en större punkt. Estimering bör utföras senare eftersom punkterna anpassas för tidsrymden i sprinten (Jeldi & Chavali 2013). Förfining bör ske vid slutet av varje sprint, där förfinas oftast de högst prioriterade kraven inför nästa sprint (Jeldi & Chavali 2013) Sprintplanering Hossain et al. (2009) beskriver sprintplanering som en form av tidsbegränsade möten som dedikeras till utvecklingen av detaljerade planer för en specifik sprint. Där åtar sig gruppen delar av produktbacklogen för att utföra dem under sprinten, detta kallas sprintbacklog (Hossain et al. 2009). Under denna aktivitet är det precis som med övriga aktiviteter inom Scrum viktigt med kommunikation mellan gruppen och produktägaren för att komma fram till beslut om vilka delar som bör tas med i nästa sprint (Jansson 2015). Det hela kräver noggrann planering som bör utföras gemensamt för att uppnå det bästa resultatet och en sprintbacklog som är utförbar (Hossain et al. 2009, Sutherland & Schwaber 2014) Sprintbacklog Sprintbacklogen är listan med allt som åtas under en sprint och som önskas färdigställas under sprinten, denna sammanställs av teamet tillsammans (Schwaber & Sutherland 2014). Fördelning av arbetsuppgifter bestäms av teamets medlemmar som själva väljer vilka av sprintens uppgifter som bör åtas (Nuevo et al. 2011). Men Nuevo et al. (2011) menar att innan detta krävs det att en nedbrytning av arbetsuppgifterna utförs, vilket möjliggör utförbara poster inom ramen för sprinten. Delar som inte är utförbara på grund av för många åtagna poster och för lite tid kan flyttas fram till nästa sprint eller returneras till produktbacklogen genom att regelbundet utföra en uppdatering (Nuevo et al. 2011). Sprintbacklogen fungerar också som referenspunkt för utvecklingsteamet som möjliggör mätningar av framstegen dagligen, samtidigt som det tydligt delar upp produktägarens och utvecklingsteamets uppgifter för att främja autonomi av utvecklingsteamet (Björkholm & Brattberg 2010, Jansson 2015) Sprint och dagligt möte Sprinten är själva hjärtat i Scrum, där det dagliga mötet är den viktigaste beståndsdelen (Sutherland et al. 2008). Genom hela Scrum är kommunikation viktigt och under själva sprinten är det extra viktigt att främja detta för att värdesättningen av individer och interaktioner framför processer och verktyg men också för att kundsamarbete framför kontraktsförhandling bör uppnås (Jansson 2015). Manifestet för agil programvaruutveckling (Agile manifesto 2001) nämner att själv-organiserade team producerar den bästa arkitekturen samt design. Schwaber och Sutherland (2014) samt Björkholm och Brattberg (2010) menar att det även är viktigt med kontroll över sprinten och därför är det ytterst vanligt att 18

24 använda sig av en sprint burndown diagram och dagliga möten för att ständigt ha full kontroll över sprinten samt vart teamet ligger i tid, i förhållande till det som estimerades från första början Produktinkrement Schwaber och Sutherland (2014) menar att produktinkrement, också kallat inkrement, är den viktigaste artefakten som existerar i Scrum. Inom varje sprint framställer teamet ett inkrement av produkten (Sutherland et al. 2008). Vidare förklarar Sutherland et al. (2008) att inkrementet bör hålla en hög kvalitet för att möjliggöra spridning till slutanvändaren. Därför är det viktigt att inkrement uppfyller teamets definition av klart och dessutom krävs det att inkrement accepteras av produktägaren. Därefter återkommer vi till kommunikationen som är den viktigaste beståndsdelen (Jansson 2015). Det bör finnas kommunikation mellan teamet samt slutkund där teamet också bör redovisa inkrement för slutkunden för eventuell feedback (Jansson 2015, Sutherland et al 2008) Sprintgranskning Schwaber och Sutherland (2014) förklarar att sprintgranskningen är mötet som hålls vid slutet av varje sprint. Vid detta möte demonstrerar teamet produktinkrement för produktägaren och kunden. Därför anses kommunikationen vara viktig även i detta moment främst för att kund samt produktägare bör vara införstådda vad som har producerats under sprinten (Schwaber & Sutherland 2014). Marchenko och Abrahamsson (2008) förklarar att samarbete mellan alla involverade parter genom hela mötet är viktigt att uppnå för att få ut det mesta av mötet i form av återkoppling på det som producerats. Vidare är granskningen som namnet avslöjar en viktig aspekt och de granskningarna utförs av hela teamet i samarbete med produktägare och kund (Marchenko & Abrahamsson 2008). De tre indikatorerna granskning, kommunikation och samarbete har tagits med främst eftersom det är intressant att se hur det studerade teamet granskar, planerar och kommunicerar genom sina inkrement eftersom konstellationen är nationellt uppdelad Sprintåterblick Schwaber och Sutherland (2014) menar att sprintåterblicken används av utvecklingsteam för att få möjligheten att granska sig själva och möjliggöra förbättringar inför nästa sprint. Målen med detta möte är att granska senaste sprinten, med tanke på relationer, processer, personer samt verktyg, identifiera det som gick bra samt det som gick sämre för att utveckla förbättringsförslag och skapa en plan som hjälper till vid införandet av förbättringsförslagen i utvecklingsteamet (Sutherland et al. 2006). 19

25 3. Metodredogörelse I detta kapitel presenteras tillvägagångssättet och metodiken som har brukats vid genomförandet av denna uppsats, de diskuteras och motiveras sedan. 3.1 Metodansats: Fallstudie Denna uppsats har utförts som en kvalitativ fallstudie för att fånga djupet i forskningsområdet, genom att studera ett fallföretag djupare. Fallstudier används för att studera ett objekt närmare för att generera något som annars inte hade varit möjligt, vilket Oates (2006) motiverar användandet av fallstudien med. En kvalitativ fallstudie fokuserar på en specifik instans, till exempel en organisation, ett projekt, ett beslut eller ett informationssystem (Oates 2006). I detta specifika fall är målet ett specifikt företag med ett Scrum-team. Oates (2006) berättar att det absoluta målet med en fallstudie är att erhålla en rik och detaljerad insikt inom ett fall och dess verkliga sammanhang. Fallföretaget som i detta specifika fall är ett ITkonsultbolag, valdes ut eftersom de gick med på att ge tillgång till sin process och ställa upp på intervjuer samt en observation, vilket underlättade eftersom urvalet av företag som vill ställa upp var minimalt, och därför blev också valet en fallstudie. Enligt Oates (2006) kan en fallstudie karakteriseras genom fyra drag, det första är fokus på djup snarare än bredd där forskaren erhåller mycket information om en instans. Det andra är att fallet studeras i dess naturliga miljö och inte i en artificiell miljö som är förutbestämd. Det tredje är att fallstudien ses som en holistisk studie för att författaren fokuserar på processernas komplexitet och hur de är sammankopplade och relaterade till varandra. Det sista draget är att flera källor och metoder används vid processen. Författaren kan använda sig av flera datainsamlingsmetoder för att bygga uppsatsen på en stadig grund (Oates 2006). Detta passar in på beskrivningen av utförandet av denna uppsats eftersom mycket information samlas om en specifik instans, samtidigt som fallet studeras i dess naturliga miljö, d.v.s. i ett pågående projekt, vilket också Oates (2006) ser som positivt. Vidare är meningen med denna uppsats också att se processernas komplexitet och hur de är sammankopplade för att påverka den inre projekteffektiviteten (Figur 5). Dessutom använder jag mig av flera källor samt datainsamlingsmetoder vid utformningen av uppsatsen. Dessa är som observering, intervjuer och litteraturstudier. Bryman och Bell (2003) nämner att den kvalitativa ansatsen lägger stor vikt på insamling samt analys av data där fokus ligger på ord och inte kvantifiering. Att använda sig av en kvalitativ ansats innebär att forskaren lägger vikt på hur deltagarna i fallstudien uppfattar miljön som de befinner sig i (Bryman & Bell 2003). Fallstudien skiljer sig från andra metoder genom att forskaren intresserar sig i belysningen av unika drag för specifika fall, utifrån ett antal synvinklar (Bryman & Bell 2003). Denna uppsats utformades som en kvalitativ fallstudie för att specifikt fånga upp djupgående information från ett fall som kan användas för att tillämpas på andra liknande händelser i framtiden. I detta fall har det planerats att ett specifikt Scrum-team ska undersökas, för att sedan jämföras med den insamlade teorin och se var skillnaderna ligger och utifrån detta hitta förhållanden inom Scrumprocessen som påverkar den inre projekteffektiviteten av utvecklingsteamet hos nationellt distribuerade Scrum-team, och detta gör jag genom att lägga vikt på insamlingen av data, som sker genom intervjuerna och observationen, där jag lägger fokus på det som respondenterna säger och gör Fallstudiens nackdelar Fallstudiemetoden som utnyttjas i denna uppsats har sin förankring i verkliga situationer och konsekvenserna av detta leder till att fallstudien i sig kan resultera i en omfattande redogörelse av fallet som analyseras, detta kan bli tidskrävande och svårt att tolka för målgruppen (Oates 2006). 20

26 I och med detta har jag försökt skriva en uppsats som på ett tydligt och metodiskt sätt går genom det belysta området för att minska svårigheten av tolkningen. Den kvalitativa fallstudien kan komma att leda till funderingar och tankar i slutändan eftersom resultatet av detta specifika fall inte fullt ut kan generaliseras till andra fall, men eftersom min avsikt med denna uppsats inte är att generalisera, utan att undersöka hur respondenterna uppfattar och eftersträvar Scrum i detta fallföretag för att sedan utifrån den empiriska insamlingen utföra en teoretiskt förankrad analys, kommer problematiken med generaliseringen inte att vara lika stor. Dessutom kommer denna uppsats i enlighet med det som Denscombe (2009) redogör för, vara mycket noga med att förhindra misstänksamhet genom att öppet visa i vilken utsträckning fallet liknar andra av samma typ. Utöver detta är det planerat att denna fallstudie enligt analysmodellen samt bakomliggande teori, fokuserar på teamet i sig och inte kunder eller produktägare runt omkring, vilket reducerar behovet av utsatt tid, men också komplexiteten som skulle ha gjort det hela mer svårt att tolka för utomstående. Denscombe (2009) anser att det kan vara svårt att definiera fallets gränser på ett absolut och tydligt sätt. Maxwell (2005) anser däremot att analysmodellen kan användas för att skapa en tydlig gräns för det studerade området. Därför används analysmodellen i denna uppsats i precis detta syfte Yin (1989) nämner att intentionen med en fallstudie är att utföra en teoretiskt förankrad reflektion med den empiriska undersökningen som grund för att skapa en fallstudie av kvalitet. Det är en ytterligare motivering samt en av anledningarna till användandet av kvalitativ fallstudie som metod för denna uppsats Fallstudiens fördelar Denscombe (2009) samt Oates (2006) nämner att den huvudsakliga fördelen med fallstudier är att inriktningen på ett fåtal enheter kan ge forskaren möjlighet att ägna sig åt subtiliteter och vanskligheter i komplicerade sociala situationer. Vidare berättar Oates (2006) att fallstudien tillåter forskaren att ta itu med förhållanden och sociala processer på ett sätt som till exempel en enkätundersökning inte tillåter. Eftersom Scrum är en process som främjar interaktion och samarbete mellan individer (Schwaber & Sutherland 2014), passar denna uppsats in på detta väl eftersom processer som innehåller sociala situationer studeras och genom detta vill jag få fram möjliga förhållanden inom utvecklingsteamets Scrum-process som påverkar den inre projekteffektiviteten för nationella team. Fallstudier gör det möjligt att använda sig av en rad olika forskningsmetoder (Oates 2006, Denscombe 2009). Oates (2006) menar att den mer eller mindre uppmuntrar användandet av flera metoder för att fånga in och noggrant undersöka den komplicerade verkligheten, och på samma sätt som den stödjer flera metoder stödjer den också användningen av flera datakällor. I och med detta har jag i min uppsats utnyttjat observation och intervjuer för att få fram relevant data Val av fallföretag Företaget som är studieobjektet för denna fallstudie är ursprungligen ett svenskt konsultbolag som grundades Företaget arbetar idag inom design, kommunikation, konsultverksamhet samt IT. Företaget existerar på totalt 14 orter i Sverige. Kontoren som tillsammans deltar i ett projekt arbetar från Borlänge samt Örebro och metodiken som utvecklingsteamet använder för systemutveckling är Scrum. Personerna som deltar i projektet utgör tillsammans ett utvecklingsteam där fyra utvecklare sitter i Borlänge och fyra utvecklare, en testare och en Scrum master sitter i Örebro. I en strävan att utveckla sitt arbetssätt och effektivisera sin Scrum-process ser de gärna att någon utomstående granskar deras arbetssätt för att hitta möjliga förhållanden i utvecklingsteamets Scrum-process som påverkar projekteffektiviteten och gav därför möjligheten att utföra denna fallstudie, dock med begränsad tillgång till innehållet i projektet som t.ex. 21

27 kod, dokument o.s.v. på grund av känslig information. Det är deras Scrum-process som studeras och inte projektets innehåll i sig och det har därför påverkat slutresultatet i en mindre utsträckning Fallföretagets arbetssätt I detta kapitel presenteras företagets nuvarande arbetssätt, på vilket sätt Scrum har applicerats i detta fallföretag. Men också hur arbetet med releaserna till kunderna går till genom att studera deras sprintar, och hur deras planering ser ut. Ett utdrag från företagets beskrivning över hur de arbetar med releaserna visar en specifik tidsperiod på 10 veckor (Figur 6). Denna beskrivning illustrerar hur en releasecykel går till. Figuren visar hur varje releasecykel delas upp i olika färger. Figuren beskriver vidare hur till exempel den röda och den blåa releasecykeln hanteras överlappande. Den röda releasecykelns sprintplanering påbörjas samtidigt som den blå releasecykeln har finessfrys, vilket innebär att samtliga backlogens objekt inte kan ändras ytterligare. Samtidigt som teamet varvar med sprintplanering för den andra releasecykeln. Produktion påbörjas samma vecka som den sista sprintplaneringen för den röda releasecykeln utförs. Vid detta stadium är den blå releasecykeln avklarad och ett mellanrum på en vecka skapas innan en ny releasecykel påbörjas, som i detta fallet illustreras med färgen grön, samtidigt som det fortfarande finns en aktiv sprint, vilket är den röda. Fallföretaget använder sig av de överlappande releasecyklarna för att de har längre ledtider mellan färdig programvara och produktionssättning. Det är under veckorna som sprintplaneringarna utförs som själva produkten tar form, produktionstest innebär att teamet inleder produktionssättning tillsammans med kunden, d.v.s. teamet skapar en simulering av slutprodukten för att visa kunden vad teamet har gjort hittills under denna releasecykel, samt får kunden möjligheten att testa produkten och komma med eventuella åsikter, förslag, förändringar som teamet kan implementera vid nästa releasecykel. Här får också testaren chansen att testa produkten efter buggar som kan ha uppstått i och med testandet tillsammans med kunden. Figur 6: Releasecykelperiod - samma färg relaterar till samma releasecykel Källa: Fallföretag I och med att teamet har fler releasecyklar körandes samtidigt i olika stadier, är det viktigt att alla vet vad som behöver göras och när detta bör utföras. Därför har teamet möten varannan vecka som funktionerar till en viss del som en granskning för att diskutera hur det går med sprinten. Det fungerar som en metod till förbättring vad gäller sprintarna, vad teamet kan göra bättre till nästa sprint, hur teamet kan förbättra och effektivisera upplägget för projektet. Utvecklingsteamet använder sig av samma upplägg under alla projekt, alltså är fallföretagets team projektöverskridande där samtliga utvecklare behåller sina utvecklingsområden under samtliga projekt, releasecykeln består också av samma upplägg. 3.3 Tillvägagångssätt Med litteraturstudien som grundsten utvecklades intervju- och observationsansatsen. En kombination av metoderna utfördes främst för att det kan öka chanserna att utveckla ett arbete med en hög nivå av yrkesrelevans som Johansson och Svedner (2006) påpekar. Ejvegård (2009) menar också att det kan öka uppsatsens vetenskapliga värde. Därför används både observation och intervjuer. Detta leder till insamling av data som sedan analyseras genom reflektion och jämförelse med den teoretiska modellen 22

28 av Scrum för att påvisa förhållanden inom företagets Scrum-process som påverkar den inre projekteffektiviteten för nationellt distribuerade team. Denscombe (2000) nämner att användandet av flera metoder kan generera mer pålitliga resultat om metoderna kombineras med varandra. Användandet av metodiken som nämnts ovan innebar först och främst själva valet av tema, som bestämdes genom dialog med fallföretaget och vilket behov som de har. När ett tema tagits fram i enighet med fallföretaget, bestämdes syftet. Med temat och syftet formulerat brukades litteraturstudien som grund för insamlingen av teori och lärande av metoden. Med val av teori och metod tillkommer också utformningen av analysmodellen som hjälper till att koncentrera den empiriska undersökningen på mer specifika delar inom processerna, d.v.s. specifika delar från generering av produktbacklog till klar sprintåterblick. I analysen ställs empirin mot den teoretiska modellen av Scrum som avgränsats enligt analysmodellen. Denna analys av konstellationen leder till slutsatser som identifierar, beskriver och förklarar förhållanden inom det nationellt distribuerade utvecklingsteamets Scrum-process som påverkar den inre projekteffektiviteten. 3.4 Intervjuer En av datainsamlingsmetoderna i denna uppsats har varit kvalitativa intervjuer. Intervjuer är en datainsamlingsmetod som används för att samla primärdata, alltså data som genereras av författaren och inte genom att referera till andra författare (Oates 2006). Kvale (1997) nämner att den kvalitativa intervjun har syftet att få fram vad den intervjuades åsikter och tankar är, och varför personen tycker som den gör. Det är fallet för min uppsats eftersom mitt syfte är att få påvisa förhållanden i det nationellt distribuerade teamets Scrum-process som påverkar den inre projekteffektiviteten. Vidare kan intervjuer struktureras på olika sätt för att få fram olika typer av svar från respondenten, allt från fullt strukturerade och semi-strukturerade till ostrukturerade (Oates 2006). I mitt fall har jag valt att använda mig av semi-strukturerade intervjuer. Oates (2006) nämner att i semi-strukturerade intervjuer existerar fortfarande en lista med teman som bör täckas och frågor som bestämts tidigare, som behöver ställas. Men intervjuaren är villig att förändra ordningen på frågorna beroende på intervjuns gång och konversationens flöde och intervjuaren kan eventuellt komma med extra följdfrågor som framkommer under själva intervjuns gång (Oates 2006). Detta tillåter respondenten att prata mer detaljerat om frågorna som intervjuaren ställer och kan producera ytterligare information som är relevant för temat (Oates 2006). Det är därför som denna struktur följs av mig, främst för att det bör finnas en fördefinierad mall med frågor att följa, men jag vill inte vara låst till frågorna om det framkommer aspekter som kan vara intressanta under intervjuns gång, som kan vara relevanta för arbetet. Intervjuerna genomfördes på företagets kontor enligt schemat som beskrivs (Tabell 2). Frågorna som ställdes har varit semistrukturerade och tillåter respondenten att utveckla sina svar mer djupgående för ett få en djupare förståelse i hur de arbetar Intervjuernas fördelar Oates (2006) nämner att intervjuer ger djup och detaljer som möjliggör en helhetsbild och förståelse för komplexa situationer. Därför har intervjuerna brukats i samband med fallstudien eftersom jag med uppsatsen vill se djupet snarare än bredden. Därför är fallstudier och intervjuer en perfekt kombination i det här sammanhanget. Vidare tar intervjuaren del av personers resonemang kring en fråga, som har direkt koppling till verkligheten (Oates 2006). Därför har den semistrukturerade metoden använts av mig i denna uppsats Intervjuernas nackdelar Att använda sig av kvalitativa intervjuer kan inte heller vara problemfritt menar Repstad (1998) som menar att metoden är för individualiserad och idealistisk eftersom för stort fokus ligger på enskilda personers åsikter. Kvale (1997) säger också att det är syftet med intervjun som styr metoden, och om 23

29 det specifikt handlar om att ta reda på hur eller varför anser Kvale (1997) att det inte är något fel med att använda kvalitativa intervjuer. Vilket är precis det som är syftet med denna uppsats, att identifiera, beskriva och förklara förhållanden i en nationellt distribuerad Scrum-process som påverkar den inre projekteffektiviteten. Intervjuer tar även stor tid i anspråk och det gäller därför att vara ute i god tid för att minska risken att hamna i tidsnöd, inte bara för att anordnandet av själva intervjuguiderna och tiderna för intervjuer kan ta tid, men också själva analysen av svaren som kan vara svår att tyda ibland (Bell 2000). Intervjuer kan påverkas av respondenternas humör och tolkning av frågor, och på andra sidan kan intervjuaren tolka svaren annorlunda än vad som var menat (Solvang et al. 1997). Risken för detta har minimerats i denna uppsats genom att jag har kontakt med respondenterna på fallföretaget innan själva intervjuerna vilken kan påverka replicerbarheten negativt men det hjälper att minska nervositet, vilket innebär att respondenterna öppnar upp sig mer och svaren kan blir mer givande och innehållsrika. Detta är också ett fenomen som Oates (2006) beskriver Urval Eftersom själva syftet med kvalitativa intervjuer är att skapa djupare förståelse kring ämnet som studeras, krävs det att urvalet av intervjupersoner är strategiskt handplockat och inte är byggt på slump eller tillfälligheter (Oates 2006). Genom själva urvalet kan intervjuaren få fram trovärdig information av de personer som intervjuas som senare kan leda till djupa analyser som en fallstudie är ämnad för (Oates 2006). Det krävs att intervjupersonerna på förhand känner till det område som studeras väldigt väl (Solvang et al. 1997). Bryman (2011) menar att urvalsmetoden som anses vara den mest optimala för kvalitativa intervjuer är den målinriktade urvalsmetoden. Med denna metod väljer forskaren ut ett fördefinierat antal intervjupersoner som anses ha betydelse för syftet med uppsatsen. Detta menar Bryman (2011), innebär att det inte kan leda till generalisering av en stor population. Alla personer som valts ut av mig är kopplade till utvecklingsteamet och alla har en annorlunda position inom teamet för att få in ett brett spektrum av respondenter och vinklar i uppsatsen. Respondenterna har därför stor koppling till arbetet och deras åsikter om hur det nationellt distribuerade teamet arbetar har därför störst påverkan på denna uppsats. Att utvecklarna som intervjuades är samlokaliserade kan påverka sättet som rollspecifika frågor från intervjuguiden besvaras och en utvecklare från Örebro kan möjligen ha bidragit med helt andra vinklar. På grund av att tiden för uppsatsen har varit begränsad har det bidragit till detta urval. Testaren har däremot tidigare arbetat med utveckling och kan därför i viss utsträckning bidra med åsikter i detta område. Det är också viktigt att nämna att det finns flera typer av intervjupersoner och jag talar om dem som respondenter. Utöver detta existerar även informatörer som klassas som observatörer eftersom de har en mer saklig uppfattning och inte är relaterade till detta specifika fall (Solvang et al. 1997). Därför har endast respondenter som är kopplade till fallet kontaktats. Respondenterna som intervjuats har angivits i tabellen där deras befattning specificeras samt datum för intervjuer presenteras (Tabell 2). Respondent: När: Scrum master 9/ minuter Utvecklare 1 8/ minuter Testare 9/ minuter Utvecklare 2 8/ minuter Tabell 1: En sammanställning av utförda intervjuer Källa: Författare 24

30 Introduktion av uppsatsens fyra respondenter Scrum master Intervjun med Scrum mastern har utförts på plats hos företaget där han är stationerad. Detta skedde i Örebro. Intervjun utfördes enskilt och endast mellan intervjuaren och respondenten i fråga. Scrum mastern har tidigare studerat ett datatekniskt program vid Örebro Universitet, men har ingen certifiering inom rollen som Scrum master, han har istället tagit den långa vägen och arbetat sig upp genom att använda sig av tidigare erfarenheter. Han anser sig dock ha stor kunskap om teorin bakom Scrum. Han har arbetat inom företaget i totalt sex år där han från början jobbade som utvecklare men bestämde sig för att ta sig an rollen som Scrum master eftersom den tidigare bestämt sig för att gå i pension, det är denna person som har lärt upp den nuvarande Scrum mastern men han anser att det fortfarande är viktigt att hålla sig uppdaterad med processerna och effektivisera dem eftersom utvecklingen går framåt väldigt snabbt och det gäller att arbeta snabbt samtidigt som det bör vara effektivt. Testare Intervjun med testaren utfördes på plats i Örebro på företagets kontor under samma dag som Scrum mastern intervjuades. Detta skedde också enbart mellan intervjuaren och respondenten. Testaren har tidigare gått det systemvetenskapliga programmet vid Uppsala Universitet. Testaren nämner att han inte har någon specifik certifiering för testande, men att han har lärts upp för att utföra arbetsuppgifterna som testaren bör klara av. Testaren har tidigare jobbat som utvecklare. Testaren har jobbat på företaget i fyra år och har tidigare jobbat med utveckling hos andra företag men aldrig inom Scrum. Utvecklare 1 Intervjun med utvecklaren utfördes på plats hos företagets kontor i Borlänge under samma dag som den andra utvecklaren intervjuades. Utvecklaren har varit på företaget i ett år och har också en intern utbildning inom Scrum. Inga tidigare erfarenheter av Scrum existerar, inte heller någon certifiering. Utvecklaren är nyligen nyutexaminerad från systemvetenskapliga programmet vid Högskolan Dalarna och detta är första jobbet som är relevant för Scrum och utveckling. Utvecklaren känner att han har någorlunda bra koll på teorin bakom Scrum och att det sitter ganska fräscht i minnet. Dock känner han att han inte vet fullt ut vilka vägar som kan tas och hur teamet kan anpassa Scrum utefter företaget. Utvecklare 2 Utvecklaren sitter stationerad på företagets kontor i Borlänge tillsammans med den andra utvecklaren som intervjuats i denna uppsats. Utvecklaren har ingen certifiering men har tidigare utbildning inom Scrum från ett annat företag. Utvecklaren har jobbat på företaget i två år och enbart jobbat som utvecklare under den tiden. Tidigare har utvecklaren studerat på Örebro Universitet med inriktning mot Informatik. Utvecklaren anser sig ha full koll på teorin bakom Scrum främst för att han jobbat inom projekt som styrts med hjälp av Scrum under tidigare år Intervjuguider Patel och Davidsson (2003) nämner att fördefinierade frågor är ett effektivt sätt att strukturera intervjuer för att samla information som är relevant för arbetet. Därför bör intervjuguiden delas upp i flera mindre delar för att skapa struktur i vad som annars skulle resultera i en intervju som är väldigt svår att analysera i slutet (Patel & Davidsson 2003). Därför användes i detta fall den semi-strukturerade intervjustrategin i kombination med tratttekniken som Patel och Davidsson (2003) nämner. Denna teknik karakteriseras av en inledning med öppna frågor som sedan rör sig mer mot djupet vad gäller frågans karaktär. I och med användandet av tratt-tekniken blir språket i frågorna mycket viktigt för att underlätta förståelsen hos respondenten (Patel & Davidsson 2003). Utformningen och ordningen av intervjuguidens frågor bestäms utifrån 25

31 ansvaret som intervjuaren har i uppsatsen, d.v.s. vilken position och i vilken grad som respondenten är relevant för själva målet med uppsatsen (Patel & Davidsson 2003). Patel och Davidsson (2003) nämner att det är viktigt att ge personen svarsutrymme under själva intervjun, dessutom nämns det att förklaringen av deras roll i undersökningen är viktig att få fram till respondenten för att denne ska ha möjligheten att förstå hur deras bidrag används för att besvara syftet med uppsatsen. För att få fram en bra struktur i denna undersökning utnyttjades analysmodellen (Figur 5) vid skapandet av frågorna för att se till att frågorna hålls relevanta och inom ramen för arbetets område. Antalet intervjuguider som utformades är totalt tre stycken, för utvecklarna, testaren och Scrum mastern, intervjuguiderna har sammanslagits och delats upp med rollspecifika frågor. Alla börjar med öppna frågor och smalnar av för att hantera det specifika området som respondenten har (Bilaga 1). 3.5 Observation Observationer kan generera data som kan vara omöjligt att ta fram med andra metoder, främst genom att studera verkligheten (Palm & Östman 2001). Detta funktionerar därför som ett bra komplement till intervjuer menar Palm och Östman (2001). Oates (2006) nämner att observationer studerar vad personer faktiskt gör och inte på vad de säger att de gör när de tillfrågas, vilket kan ge en mycket mer riktig bild av verkligheten. Oates (2006) nämner också att metoden är lämplig för att studera möten mellan personer och hur interaktioner mellan personer sker. I denna uppsats användas observering för att studera hur interaktionen i det nationellt distribuerade teamet går till och därigenom vill jag få en reell bild genom att studera verkligheten. Genom observationer är det inte enbart fysiska handlingar som studeras men också verbala yttranden, relationer mellan individer, känslouttryck etc. (Palm & Östman 2001). En observation kan antingen vara deltagande eller också kan forskaren agera som "flugan på väggen" (Palm & Östman 2001). Den deltagande observationen innebär att observatören observerar verksamheten samtidigt som denne deltar i den verksamhet som observeras, men att agera "flugan på väggen" innebär däremot att den som observerar en verksamhet enbart står vid sidan och studerar utan att vara en del av den (Palm & Östman 2001). Genom denna observation planerar jag att vara precis det som Palm och Östman (2001) nämner, vilket är flugan på väggen. Personerna som deltar vid intervjuerna i denna uppsats observeras i deras naturliga arbetsområden för att få fram äkta verbala yttranden, känslouttryck och relationer. En observation kan vara strukturerad eller ostrukturerad (Oates 2006). En strukturerad observation innebär att observatören i förväg bestämt vilka fenomen som fokuseras på i observationen, samtidigt som en ostrukturerad observation används när observatören vill erhålla mycket kunskap, d.v.s. observerar allt i en speciell omgivning (Palm & Östman 2001). I min observation studerar jag inte något specifikt men tar istället in helhetsintrycket från observationen för att bedöma det studerade. Observationen som utförs i denna uppsats fokuserar på möten i form av dagliga möten och presentationer av arbetssättet, vilket innebär att observationen kommer att vara ostrukturerad för att ta in mycket kunskap under själva observeringen, samtidigt som den inte kommer att vara deltagande för att jag inte vill gå in och påverka personernas åsikter eller uttryck. Observationen av mötet utfördes under en dag där det dagliga mötet mellan Borlänge och Örebros kontor observerades. Sutherland et al. (2008) nämner att det dagliga mötet är den viktigaste beståndsdelen i Scrum. Syftet med att observera det dagliga mötet har främst varit att studera hur kommunikationen, organiseringen och de dagliga kontrollerna går till, alltså har det skett i enlighet med analysmodellen (Figur 5). Utöver detta har det även varit av intresse att studera hur teammedlemmarna kommunicerar ut det som är allra viktigast under det dagliga mötet för att skapa transparens, d.v.s. vad som har åstadkommits sedan förra mötet, vad som planeras fram till nästa möte och vad som hindrar personen från att bli 26

32 färdig, och allt detta gör teamet för att kontrollera framgångarna mot de uppsatta målen som befinner sig i projektet och den nuvarande sprinten Observationens fördelar Denscombe (2009) ser observationer som en direkt datainsamling eftersom observationen registrerar det som människor gör, till skillnad från vad de säger att de gör. Därför är det ett ypperligt tillfälle att jämföra observationen med intervjuerna för att se om den insamlade empirin stämmer överens, vilket jag planerar att göra i denna uppsats. Vidare är det ett effektivt sätt att samla in avsevärda mängder data under en relativt kort tidsperiod (Denscombe 2009). Fördelen med observationsmetoden är att undersökningspersonerna inte behöver ha en tydlig minnesbild som de sedan vidarebefordrar till de som utför undersökningen, att de uppfattar den rätt (Denscombe 2009). En annan fördel är att det krävs mindre samarbete med de utvalda individerna till skillnad från de flesta andra metoder (Palm & Östman 2001). I mitt fall krävs det inte något samarbete under observationen eftersom jag endast agerar flugan på väggen under självaste observationen, vilket inte kräver någon interaktion med personerna (Palm & Östman 2001) Observationens nackdelar Observationers nackdel är att de är tidskrävande (Palm & Östman 2001). Palm och Östman (2001) nämner att det är väldigt svårt att avgöra när spontana beteenden fångas och när beteenden som observeras faktiskt är representativa. Det är svårt att avgöra eftersom observatören inte är osynlig, vilket kan leda till att personer som observeras förändrar sitt beteende, vilket i sig förvränger hela bilden, men risken för detta kan minskas genom att hålla sig neutral (Palm & Östman 2001). Eftersom observationen fungerar som komplement till intervjuerna i denna studie är det enklare att se på om det som faktiskt observeras stämmer överens eller om beteendet förändras på grund av forskarens närvaro. Observationen i denna uppsats är inte deltagande och inte heller strukturerad, för att minska påverkan av min närvaro och för att studera fenomen i dess naturliga närvaro som flugan på väggen. 3.6 Validitet, reliabilitet och generaliserbarhet Det existerar många tolkningar av hur validitet och reliabilitet bör hanteras (Cohen et al. 2007). Hoten mot själva validiteten och reliabiliteten, eller trovärdigheten och tillförlitligheten, kommer aldrig att elimineras fullt ut men det går att minimera hoten genom att uppmärksamma det ständigt genom hela arbetets process (Cohen et al. 2007). En uppsats trovärdighet ligger i förmågan att utföra samma process igen och få fram samma resultat, nämner Jacobsen (2002). Min förhoppning är att denna fallstudie samt slutsatserna som presenteras är möjliga att tillämpa på andra exempel eftersom Scrum är en universell metod där många liknelser finns mellan olika konstellationer. Men att uppnå en hög reliabilitet kan vara svårt vid användandet av kvalitativa metoder eftersom det blir svårt att utföra intervjuer av en annan forskare för att få fram samma resultat eftersom det helt enkelt existerar för många faktorer som kan påverka det enskilda svaret, vilket i sig kan leda till att resultatet leder till en helt annan slutsats (Cohen et al. 2007). Men för att kvalitetssäkra mitt arbete kommer intervjufrågorna studeras innan jag genomför intervjuerna, dessutom om möjligt kommer intervjuerna spelas in för att minska missförstånd och för att jag helt enkelt inte klarar av att komma ihåg allt på egen hand, vilket i sig minskar validiteten stort och det är därför otroligt viktigt att spela in om möjligt. Intervjuerna spelas in och intervjufrågorna (Bilaga 1) utgår ifrån analysmodellen för att skapa ett strukturerat arbete (Figur 5). Intervjufrågorna inkluderas som bilaga för att stärka trovärdigheten och replicerbarheten i uppsatsen (Bilaga 1). Eftersom reliabiliteten är svår att bestämma i kvalitativa studier blir istället validiteten mycket viktig (Cohen et al. 2007). Validitet delas in i externa och interna delar där den interna validiteten avser att ta ställning till att det som undersökts faktiskt är fullt korrekt och att slutsatserna som dras från detta är korrekta (Jacobsen 2002). Den externa validiteten avser att se på uppsatsens giltighet i andra sammanhang till exempel om det är möjligt att använda sig av slutsatserna som dragits på andra företag annat än själva fallföretaget, också kallat för generaliserbarhet (Jacobsen 2002). Generaliserbarheten inom fallstudier är svårt att hantera eftersom det blir väldigt anpassat utefter den 27

33 rådande situationen samt tidpunkten, och i detta fall är antalet respondenter lågt, eftersom endast fyra intervjuer har genomförts, vilket också påverkar generaliserbarheten. Resultatet blir inte helt generaliserbart eftersom det existerar skillnader i arbetssättet med Scrum i alla konstellationer. Dock kommer det delvis att finnas överförbarhet till andra IT-konsultföretag som anammar Scrum på liknande sätt om hur de bör hantera sin nuvarande situation. Skillnaden mellan generaliserbarhet och överförbarhet handlar om huruvida forskaren lyckas med att etablera tolkningar och beskrivningar som är användbara i andra sammanhang till skillnaden mot att försöka att ange hur vanligt ett visst fenomen är, alltså generaliserbarhet (Johannessen & Tufte 2003). Den interna validiteten i denna uppsats är stärkt den genom användandet av flera respondenter som ingår i samma team men som har olika befattningar. Att intervjua flera personer som innehar olika roller i teamet stärker uppsatsens slutsats och undersökningens inre validitet (Malterud 1998). Malterud (1998) kallar också detta för källtriangulering. Det innebär att forskaren intervjuar fler personer och samtidigt använder sig av observationer, och stärker giltigheten ytterligare (Malterud 1998). I och med en högre validitet och reliabilitet, kan många verksamheter som använder sig av Scrum därför ta till sig kunskap från denna uppsats eller företag som likt detta är nationellt distribuerat och letar efter vägar att öka den inre projekteffektiviteten genom att se vilka förhållanden som kan påverka. 28

34 4. Analys I detta kapitel analyseras de centrala uppfattningarna som respondenterna uttrycker under de personliga intervjuerna, samt det som uppfattades under observationen, vilket relateras till den presenterade teorin. Intervjuerna och observationen presenteras i bilaga 2 och 3. Figur 7: Analysmodell över förhållanden i en distribuerad Scrum-process som påverkar den inre projekteffektiviteten med analysområden inlagt Källa: Modifierad utifrån Schwaber och Sutherland (2011:16) Datainsamlingen för denna uppsats har främst skett genom intervjuer och en observation där fokus främst har lagts på hur det nationellt distribuerade teamet arbetar genom Scrum-processen och därigenom se vilka förhållanden som påverkar den inre projekteffektiviteten. Motivet bakom kartläggningen över företagets arbetssätt genom Scrum-processen är att hitta reella möjligheter som kan bidra med förändringar i fallföretagets synsätt på Scrum, förändringar i arbetssättet och nya kunskaper samt färdigheter genom att se på hur förhållanden i Scrum-processen påverkar den inre projekteffektiviteten. Genom uppsatsen har fyra intervjuer genomförts och kombinerats med observation av ett dagligt möte samt redovisning av företagets arbetssätt där Scrum mastern redovisat kort för hur utvecklingsteamet arbetar genom sprintarna. I analysen beskrivs analysmodellens variabler och dess underliggande indikatorer som har presenterats i tidigare kapitel (Figur 5). Indikatorerna har kursiverats i analysen för att tydligare markera dessa. En illustrering av hur analysen kommer att struktureras kan ses ovan (Figur 7). 4.1 Inre projekteffektivitet Enligt Schwaber och Sutherland (2014), Juyun (2008) och Deemer et al. (2009), bestäms den inre projekteffektiviteten av Scrums tre grundpelare som betyder att transparens, granskning och anpassning bör finnas genom hela Scrum-processen från det att user stories kommer in genom produktbacklogen till att ett produktinkrement står färdigt och sprintgranskningen tillsammans med sprintåterblicken är utförda (Juyun 2008, Deemer et al. 2009, Schwaber & Sutherland 2014). Plohmann et al. (2013) menar att den inre projekteffektiviteten påverkas direkt av innehållet i artefakterna och aktiviteterna som används av organisationen, och som befinner sig i Scrumprocessen. Denna koppling har tydliggjorts i tidigare kapitel (Figur 5). Scrum-processens sammankoppling med de tre indikatorerna, d.v.s. grundpelarna, analyseras här; 29

35 Transparens Juyun (2008) samt Schwaber och Beedle (2002) menar att transparens genom hela Scrum-processen är avgörande för dess funktion eftersom det innebär att alla involverade individer förstår vad som händer i varje sprint. Men också före och efter sprinten, och det leder i sin tur till att teamet förbättrar kommunikationen och förtroendet för varandra (Plohmann et al. 2013, Juyun 2008, Deemer et al. 2009). Transparensen genom fallföretagets Scrum-process upplevs som varierande beroende på vilken aktivitet och artefakt som är i fokus och beroende på vem inom teamet som tillfrågas (Bilaga 2). Detta kan betyda att det existerar en avsaknad av transparens eftersom teamet inte är överens i denna fråga. Scrum mastern ser inte något problem med den nationella distribueringen samtidigt som han menar att ett samlokaliserat utvecklingsteam vore att föredra (Bilaga 2). Samtliga respondenter är noga med att påpeka specifikt detta, vilket tyder på att det finns en gemensam förståelse om detta genom utvecklingsteamet. Att utvecklingsteamet är splittrat i denna fråga innebär att rutinerna bör ses över, i och med att det tyder på svårigheter i kommunikationen mellan teamen kan till exempel en av medlemmarna från varje kontor utses som förmedlare av information, vilket Alqahtani et al. (2013) ser som en möjlighet för distribuerade team. Detta innebär till exempel att inte hela teamet behöver vara med vid alla möten mellan kontoren, istället kan förmedlaren från Örebro deltaga vid möten som hålls på kontoret i Borlänge, och förmedlaren som är stationerad i Borlänge kan deltaga i möten som hålls på kontoret i Örebro och blir då en länk mellan teamen, detta kan skapa ett tydligare flöde av transparens vilket Alqahtani et al. (2013) tar upp. Granskning Utvecklingsteam granskar ofta Scrum-artefakter samt aktiviteter för att upptäcka avvikelser. Det bör inte ske i den grad att det hamnar i vägen för arbetet (Plohmann et al. 2013). Granskningar är som mest givande när de utförs noggrant och regelbundet av skickliga granskare som utsetts av resterande utvecklingsteamet i anslutning till arbetet (Schwaber & Sutherland 2014, Juyun 2008, Schwaber & Beedle 2002). Utvecklingsteamet utför granskning av artefakterna och aktiviteterna i samband med möten som sprintplaneringsmöten, sprintgranskningsmöten och sprintåterblicksmöten med obligatoriskt deltagande. Utvecklarna anser dock att mötena upplevs som kontrollerade och strikta, vilket medfört att medlemmar inte alltid får fram åsikter främst för att någon kan ta illa upp av kritiken (Bilaga 2). Alqahtani et al. (2013) menar att om hela teamet deltar vid samtliga av dessa möten, kan det det innebära att värdefull tid försvinner som annars kan spenderas på produktion. Ytterligare motiverar användandet av en utsedd förmedlande part från varje kontor. Vidare menar Alqahtani et al. (2013) att en rotation varje vecka mellan medlemmar kan ske för att skapa variation som binder teamet över de distribuerade gränserna. Detta kan lösa fallföretagets problematik med mötena som anses vara strikta och kontrollerade. Dessutom behöver alla inte vara med vid dessa möten om istället endast en behöver förmedla informationen mellan kontoren. Anpassning Om artefakter och aktiviteter avviker utanför acceptabla gränser är det upp till teamet att justera dessa eller bearbeta relaterat material, vilket teamet arbetar med, t.ex. dokument eller kod (Schwaber & Sutherland 2014). En anpassning bör utföras snarast för att minimera ytterligare avvikelser (Schwaber & Sutherland 2014). Anpassningarna inom fallföretagets team sker med hjälp av produktägaren som avgör när en avvikelse är tillräckligt stor för att skada projektet. Detta sker i enlighet med det som Björkholm och Brattberg (2010) tar upp, att det är produktägaren som har det slutliga ansvaret för denna uppgift. Utvecklarna anser dock att produktägarens anpassningar är alldeles för kontrollerande och restriktiva och önskar att anpassningarna som utförs diskuteras med utvecklarna innan de utförs (Bilaga 2). Om detta är alldeles 30

36 för problematiskt, kan Scrum mastern användas vid liknande tillfällen för att kommunicera med produktägaren innan beslut tas, vilket trots allt ingår i hans roll, vilket också Deemer et al. (2009) påpekar Produktbacklog User stories kommer in i projektet genom produktägaren som har för uppgift att se till att produktbacklogen avspeglar projektets mål och mission, d.v.s. att teamet har ett meningsfullt mål att arbeta mot (Jeldi & Chavali 2013). Detta innebär att kraven i produktbacklogen vid detta tillfälle bör vara tillräckligt tydliga för att hela teamet ska ha möjlighet att förstå vad de innebär (Jansson 2015, Sutherland et al. 2008). Fallföretaget har en produktägare för det pågående projektet som prioriterar och estimerar samtliga objekt på egen hand, vilket Scrum mastern nämner (Bilaga 2). Vidare berättar Scrum mastern att han önskar att teamet är mer involverat i detta stadie för att öka förståelsen för objekten i produktbacklogen. Även utvecklarna håller med om detta, dock inte testaren (Bilaga 2). Produktägaren bör se över tydligheten vid specificeringen av produktbacklog-objekten som hanteras i projektet, och Scrum mastern bör vara tydligare vid kommunikationen och förmedlingen mellan produktägare och resterande utvecklingsteamet för att hantera denna problematik eftersom att det är ingångspunkten under projektet och kräver full förståelse (Björkholm & Brattberg 2010). Teamet är dessutom med vid förfiningen av objekten. Jeldi och Chavali (2013) menar att detta kan skapa en gemensam förståelse för objekten och motverka den nuvarande problematiken. Scrum mastern anser dock att det stora deltagandet skapar problem vid förfiningen, vilket främst är för att det är ett tillfälle som objekten behöver detaljeras, vilket kräver tid (Bilaga 2). Teamet hinner helt enkelt inte detaljera objekten tillräckligt på grund av tidsbristen (Bilaga 2). Detta minskar förståelsen och minskar även transparensen genom det fortgående arbetet (Björkholm & Brattberg 2010). Jansson (2015) berättar att det alltid är produktägaren som har sista ordet vid prioriteringen, estimeringen och förfiningen. Men det hindrar inte teamet från att tillsammans delta vid dessa tillfällen för att informera alla om de objekt som behöver föras in i projektet för att skapa förståelse. Därför kan hela teamet tillsammans delta vid de tillfällena med produktägaren på ett passivt sätt för att objekten som kommer in i projektet ska bli tydligare för alla, för att öka förståelsen, alternativt ha en förmedlare från varje kontor som distribuerar ut denna viktiga information, vilket enligt Alqahtani et al. (2013) minskar problematiken vid nationellt distribuerade konstellationer. Testaren kan vara med vid de tillfällena också eftersom ingen i utvecklingsteamet bör urskiljas eller separeras från den resterande delen av utvecklingsteamet. Men detta har inte utförts eftersom att teamet inte är tvärfunktionellt. Det går emot Scrums teorier där grundarna Ken Schwaber och Jeff Sutherland (2014) säger att Scrum främjar kommunikation och samarbete mellan individer. Testaren kan förslagsvis bli mer involverad, men dock är det ett problem eftersom pressen på testaren redan är stor som den är (Bilaga 2). Därför passar förslagsvis förmedling mellan teamet mycket bättre jämfört med obligatoriskt deltagande för alla. Fallföretaget har redan brist på tid vilket framkommer under intervjuerna och det kan ge teamet mer tid (Bilaga 2) Sprintplanering Sprintplaneringen är mötet under vilket produktägaren tillsammans med teamet diskuterar och beslutar om objekt, krav och ärenden som implementeras i sprinten, från produktbacklogen (Hossain et al. 2009, Sutherland & Schwaber 2014). Hela teamet inom fallföretaget är med vid sprintplaneringen tillsammans med produktägaren (Bilaga 2). Detta kan ses som positivt eftersom teamets uppgift är att bestämma processens innehåll samtidigt som produktägaren bestämmer produktens innehåll (Jansson 2015). 31

37 Respondenterna berättar att beslutfattandet är begränsat och detta beror förmodligen på bristerna i kommunikationen som respondenterna uppfattar finns (Bilaga 2). Kommunikationen kan i sig påverka om målet uppnås i slutet av en sprint eftersom planeringen av sprinten blir av sämre kvalitet (Eckhart & Feiner 2016). Jansson (2015) berättar att när två parter kommer överens om arbete är det viktigt att båda parterna förstår vad arbetet syftar till och att parterna bedömer arbetet som rimligt att klara. Svaren som testaren ger under intervjun tyder på att det finns missförstånd eftersom testaren känner sig pressad samtidigt som utvecklarna inte känner någon större press på sig, och det innebär att en obalans uppstår (Bilaga 2) Sprintbacklog Sprintbacklog är listan med krav, objekt och ärenden som bör utföras under den pågående sprinten (Schwaber & Sutherland 2014). Listan är i detta stadium en förfinad, prioriterad och estimerad version av de user stories som har kommit in genom produktbacklogen via produktägaren (Schwaber & Sutherland 2014, Nuevo et al. 2011). Respondenterna anser att fördelningen av uppgifter sker utefter kompetens och kontor, vilket innebär att teamet inte blir tvärfunktionellt (Bilaga 2). Om teamet antar större uppgifter resulterar det i en fördelning på ett av kontoren istället för en fördelning mellan de två kontoren. Det innebär att teamet på kontoret som inte antagit sig uppgifterna nu har svårigheter att begripa vad det andra kontoret gör eftersom kontoret som antagit sig uppgifterna inte levererar ständiga uppdateringar om arbetet genom uppgiften, vilket bör ske vid dagliga möten. Detta kan innebära att synkroniseringen mellan teamen inte är optimal och att det finns behov av en lösning som tillåter förståelse mellan teamen i form av konstanta och tydliga uppdateringar. När fallföretagets team antar större uppgifter fördelas det på ett kontor och inte mellan de två kontoren och detta innebär att teamet som inte antagit sig uppgifterna nu inte vet vad det andra kontoret gör om inte ständiga uppdateringar förses, vilket Nuevo et al. (2011) nämner som en problematik vid distribuerade team. Scrum mastern berättar vid intervjun att problematiken med uppdateringarna mellan kontoren har påverkat sammanhållningen negativt (Bilaga 2). Sammanhållningen kan förmodligen komma att påverka produktiviteten om fallföretaget väljer att fortsätta på samma spår. Antingen bör man flytta sig mot en mer sluten struktur där varje kontor hanterar sina egna möten, eller hittar en alternativ lösning som skapar tydligare uppdateringar, t.ex. en förmedlare vilket Alqahtani et al. (2013) rekommenderar. Jansson (2015) berättar att sprintbacklogen fungerar som en referenspunkt mot vilket teamet kan mäta sina framsteg emot på en daglig basis. Men om teamet fördelar uppgifterna tillräckligt mycket mellan kontoren blir det svårt att se framsteg på en daglig basis då stegen som tas blir mindre och mindre, vilket påverkar teamets synsätt på projektet negativt (Alqahtani et al. 2013). Detta går att relatera till fallföretaget (Bilaga 2). Jansson (2015) berättar även att produktbacklogen kan fungera som en fördelning mellan produktägarens uppgifter och utvecklingsteamets uppgifter, vilket i sig kan påverka teamets autonomi positivt. Men avsaknaden av det tvärfunktionella teamet i detta stadium, där fallföretaget försöker arbeta över de lokala gränserna, påverkar inte fallföretagets autonomi på ett positivt sätt eftersom uppgifterna delas upp efter utvecklarnas kompetens, vilket är ett resultat av det fokus som företaget lägger på specialkompetens. Avsaknaden av tvärfunktionalitet behöver inte vara något negativt i sig men fallföretaget befinner sig i en delad position där viljan finns att samarbeta mellan kontoren, vilket skapar problematiken. Samtliga respondenter är däremot nöjda med nedbrytningarna och uppdateringarna som utförs på sprintbacklogen eftersom det sker till den utsträckningen där det är genomförbart och acceptabelt (Bilaga 2) Sprint och Dagligt möte Ett projekts förlopp kan delas upp i arbetscykler som inom Scrum kallas för sprintar (Schwaber & Sutherland 2014). Varje sprint är i förhand planerad vad gäller tid och innehåll (Sutherland et al. 32

38 2008). Varje sprint resulterar dessutom i ett potentiellt releasebart inkrement (Schwaber & Sutherland 2014). I fallföretagets arbetscykler är varje sprint planerad på förhand men vad som skiljer arbetssättet från det som nämns av Schwaber och Sutherland (2014) är att varje sprint bör vara uppdelad i maximalt 30 dagars intervaller för att klara av att behålla fokus och planera effektivt. Fallföretaget har ett lite annorlunda angreppssätt som också nämnts under presentationen av arbetssättet och releasecyklarna. Angreppssättet som teamet har är överlappande releasecykler som överskrider 30 dagar (Tabell 1). Det är totalt 7 8 veckor långa releasecykler från första sprintplaneringen till produktion. Att ha överlappande releasecykler som dessutom överskrider maxgränsen 30 dagar kan hindra transparensen genom arbetsprocessen därför att teamet kan förlora fokus under längre perioder (Shrivastava & Date 2010). Jansson (2015) berättar att genom de kortare tidshorisonterna får teamet en tydligare bekräftelse på arbetet, vilket också innebär att den dagliga upplevelsen av arbetets framgång blir tydligare, vilket kan motivera fallföretagets team. Åsikterna kring hur väl sprintarna och de dagliga mötena funktionerar upplevs som väldigt delade bland respondenterna (Bilaga 2). Överlag upplevs de dagliga mötena som värdefulla för att hålla sig uppdaterade genom kommunikationen det främjar, dessutom förenklar det uppdateringarna om hur arbetet går och om teamet förhåller sig till planerna (Bilaga 3). Men testaren ansåg att det var svårt att nå målen på grund av en krävande sprintbacklog vilket tyder på att avsaknaden av det tvärfunktionella teamet påverkat teamets funktionalitet i sprintarna (Bilaga 2). Det dagliga mötet som observerades upplevdes som produktivt men samtidigt är det 15 minuter varje dag som går till denna aktivitet där hela teamet deltar, och som i detta fall, var det inte alla som hade någonting att ta upp (Bilaga 3). Detta i sig kan i det långa loppet leda till värdefull tid som går förlorad. Att istället låta kontoren ha separata dagliga möten där varje dag en ny medlem från det andra kontoret deltar för att synkronisera med det andra kontoret kan till exempel minska grupperna, och tiden som krävs för mötena, vilket också Alqahtani et al. (2013) påpekar. Schwaber och Sutherland (2014) och det Agila Manifestet (Agile Manifesto 2001) nämner att en av de största styrkorna med Scrums metodik är samarbetet mellan personer. Vilket teamet i detta stadium inte främjar med sin uppdelning av arbetet, därför behöver fallföretaget se över organiseringen under sprintarna, vilket i sig kan bidra till att kontrollen av sprintens innehåll blir tydligare och mer transparent. Om fallföretaget däremot går den motsatta vägen behöver en tydligare uppdelning mellan kontoren ske, där till exempel två utsedda medlemmar förmedlar information mellan kontoren, vilket enligt Alqahtani et al. (2013) kan underlätta vid liknande situationer då mer tid skapas för resterande delen av teamet Produktinkrement, sprintgranskning och sprintåterblick Varje produktinkrement som levereras efter sprinten bör i detta stadium vara klart för leverans till kunden. Därför är det viktigt att hela teamet är överens om vad klart specifikt innebär (Schwaber & Sutherland 2014). Jansson (2015) samt Sutherland et al. (2008) förklarar att den gemensamma överenskommelsen om vad klart innebär inom teamet förhindrar uppkomsten av negativa situationer av flera slag, bland annat otydliga mål för en sprint, inte tillräckligt specificerad definition av vad klart innebär, missförstånd mellan produktägare och team vid återkopplingen av sprinten och att olika individer tolkar enskilda arbetsuppgifter på olika sätt. Det framgick av intervjuerna att teamets definition av vad klart innebär var relativt tydlig och samtliga respondenter var väl informerade om vad klart är (Bilaga 2). Men utvecklare 1 nämnde att produktägaren vid ett tidigare tillfälle missuppfattat teamets definition av klart och det resulterade i extra arbete vid nästa sprint (Bilaga 2). Detta behöver specifikt inte bero på att teamets definition av klart inte stämmer överens med det som produktägaren anser, men kan istället bero på andra aspekter inom processen. Till exempel kan en uppgift från sprintbacklogen ha misstolkats av utvecklare och produktägare, vilket snarare tyder på problem med kommunikation istället för problem med definitionen av vad klart är. 33

39 Scrum mastern berättar att sprintgranskningen och sprintåterblicken utförs kontorsöverskridande för att få med alla, vilket innebär att obligatoriskt deltagande gäller, och det innebär att produktägaren samt hela teamet är med (Bilaga 2). Detta kan bidra till förbättrat samarbete mellan utvecklarna vilket påverkar utvecklingsteamets granskningar. Utvecklare 2 berättade att mötena kan ses som väldigt strikta och kontrollerande, det var också svårt att yttra sig ansåg han (Bilaga 2), vilket kan påverka förbättringarna som genereras genom sprintåterblicken. Det kan skapa en helt annan bild av planeringen eftersom förbättringsförslagen påverkar planeringen av nästa sprint, vilket Marchenko och Abrahamsson (2008) också tar upp. Denna problematik kan också ha sin botten i avsaknaden av tvärfunktionella utvecklare (Majchrzak et al. 2012, Marchenko & Abrahamsson 2008). Jansson (2015) menar att det är arbets-relationer snarare än vänskaps-relationer som håller teamet samman. Genom det gemensamma arbetet blir individen en del av gruppen, detta innebär att teamet arbetar nära varandra, planerar ihop, hjälps åt, löser problem tillsammans och tillsammans ser lösningarna ta form. Företaget som studeras i denna uppsats saknar denna gemenskap eftersom företaget inte enbart delar upp teamet nationellt men också skärmar av varandra genom att jobba enskilt. Detta påverkar i sig resultatet av återblicksmötet och granskningsmötet. Det skapar också en kedjereaktion som kan komma att påverka nästa sprint och nästa produktinkrement. Redovisning och kommunikation med kund angående produktinkrement sker vanligtvis hos kund om möjligt och är därför en fördel eftersom det sker ansikte mot ansikte och det påverkar relationen med kunderna eftersom att det blir enklare att skapa kontakt med kunderna, vilket också Majchrzak et al. (2012) påpekar Team A och Team B Team A och Team B inom analysmodellen tillsammans utgör det distribuerade teamet, vilket fysiskt finns på två orter. Genom datainsamlingen som utförts med hjälp av intervjuer, observering och litteraturstudier, har data relaterat till utvecklingsteamets arbetssätt samlats in och analyserats, vilket presenteras här. Fallföretagets uppdelning har resulterat i ett antal problematiska situationer som tagits upp i föregående avsnitt. Scrum-processen påverkas främst av att teamet är delat mellan nationell distribuering och isolering. Det går att tolka det som att teamet befinner sig i ingenmansland eller en gråzon. Det finns en tydlig vilja att samarbeta mellan kontoren samtidigt som arbetet delas mellan kontoren med fokus på kompetensen specifikt (Bilaga 2). Detta ger i sig en underliggande påverkan på fallföretagets Scrum-process som har en liknelse med det som Alqahtani et al. (2013) påpekar. Det som är unikt med nationella team gentemot lokalt- och internationellt placerade team är att inom lokala team sker majoriteten av synkroniseringen under en längre period som är utspridd över en hel dag (Sutherland et al. 2008). Samtidigt som det internationella teamet kan gå tillbaka och se vad det andra teamet har utfört under föregående dag på grund av skillnaderna i tidszoner Alqahtani et al. (2013). Nationella team saknar de möjligheterna och svårigheterna här blir därför större, vilket kan lägga större vikt på viktiga synkroniseringstillfällen, t.ex. det dagliga mötet Fallföretagets arbetssätt Fallföretaget använder sig av överlappande releasecykler under sprintarna, vilket enligt utvecklare 1 resulterar i att testaren inte hinner med testandet av samtliga objekt på ett effektivt sätt (Bilaga 2). Det som framkommit genom litteraturstudierna är att överlappande releasecykler inte är vanliga (Sutherland 2005, Takeuchi & Nonaka 2004). Det kan med största sannolikhet bero på flera aspekter, bland annat att teamet fokuserar på två eller fler stadier av samma projekt och hoppar mellan dem jämnt och ständigt, vilket kan göra målen otydliga för teamet. Sutherland (2005) samt Takeuchi och Nonaka (2004) anser samtidigt att det är bra med överlappande releasecykler eftersom det levererar produkter i en mycket snabbare takt än konkurrenterna som använder isolerade sprintar, men långsammare än konkurrenter som kör alla sprintar samtidigt (Figur 4). Men det som också kan nämnas i detta fall är att Sutherland (2005) diskuterar projekt där flera team arbetar enskilt men mot samma mål, vilket tillåter uppdelningen av arbetet på ett effektivare sätt 34

40 för att minska ledtiderna genom överlappande releasecykler eller alla genomförandet av samtliga releasecykler samtidigt. Detta fallföretag har dock endast ett Scrum-team, och en Scrum master. Detta innebär att det saknas arbetskraft för att faktiskt effektivt använda sig av de överlappande releasecyklerna. Istället kan t.ex. utvecklingsteamet fokusera på isolerade releasecykler för att ge tid att återhämta sig mellan varje isolerad releasecykel, vilket ger mer tid för granskning och anpassning vilket också Takeuchi och Nonaka (2004) påpekar. Teamet bör också fundera på om det faktiskt är aktuellt att börja använda sig av olika effektiva verktyg som sprint burndown diagram för att skapa ytterligare en dimension av kontroll istället för att enbart sköta allt via digitala plattformar som för tillfället är fallet, vilket uppmärksammades under observationen av det dagliga mötet (Bilaga 3) Fallföretagets nationellt distribuerade team Den nationella distribueringen av fallföretaget har resulterat i nya utmaningar (Bilaga 2, Bilaga 3). Jalali (2012) nämner att avståndet förstärker de redan existerande svårigheterna som också kan hittas i samlokaliserade team, vilket påverkar projekteffektiviteten negativt. Avsaknaden av tvärfunktionella team, långa och svåra releasecykler samt svag och otillräcklig kommunikation är alla exempel på problem som förstärkts som ett resultat av den nationella distribueringen av fallföretaget. Detta skapar i sig en avsaknad av transparens, granskning och anpassning (Plohmann et al. 2013, Juyun 2008, Deemer et al. 2009). Lahiri (2010) nämner att kvaliteten av innovationer blir lidande när distribueringen av utvecklingen blir alldeles för bred. Om teamet är starkt integrerade över flera orter går det att dra större nytta av distribueringen menar Lahiri (2010). Det leder tillbaka till fallföretaget - utvecklingsteamet kan dra nytta av den nationella distribueringen om medlemmarna integrerar sig väl, d.v.s. om medlemmarna samarbetar och kommunicerar med varandra för att minska bredden. Genom att skapa ett dagligt möte likt det som Alqahtani et al. (2013) nämner, där varje kontor utser en ny förmedlare varje vecka, och synkroniserar med teamets andra kontor istället för de gemensamma dagliga mötena med obligatoriskt deltagande som för tillfället har blandade åsikter (Bilaga 2), kan teamet stärka integrationen Den nationella distribueringen har också medfört positiva effekter i relationen mellan fallföretaget och kunderna eftersom den nationella distribueringen med flera kontor på olika orter medför en närhet till kunderna som annars inte hade existerat, vilket Scrum mastern nämner (Bilaga 2). Alzoubi et al. (2015) redogör för olika fördelar som existerar inom nationellt distribuerade utvecklingsteam som fördelaktigt bör utnyttjas, till exempel kan distribuerade team innebära en lägre produktionskostnad och möjlighet att involvera större talanger eftersom närheten till talang ökar. 4.2 Scrum-processens påverkan på den inre projekteffektiviteten I följande kapitel samt underkapitel analyseras förhållanden inom Scrum-processen som påverkar den inre projekteffektiviteten genom de tre indikatorerna granskning, anpassning och transparens. Scrum-processens påverkan på den inre projekteffektiviteten illustreras av påverkanspilen som sammankopplar Scrum-processen och den inre projekteffektiviteten (Figur 5). Förhållandena som framtagits och analyseras här, grundar sig i teorin (Kapitel 2), som jämförts med empirin. Det studerade området kan hjälpa till att utvärdera fallföretagets arbetssätt genom att bidra med kunskap om förhållanden inom Scrum-processen som påverkar den inre projekteffektiviteten. Det ger fallföretaget underlag för framtida, reella förändringar inom den nationellt distribuerade konstellationen. Förhållandena inom Scrum-processen som påverkar den inre projekteffektiviteten hos nationellt distribuerade team diskuteras och analyseras i följande kapitel Synkronisering av utvecklingsteamet Förhållandena som diskuteras och analyseras är inte i alla möjliga situationer specifikt unika för den nationellt distribuerade konstellationen. De kan också finnas i andra typer av konstellationer, samlade som internationellt distribuerade team kan också uppleva dessa förhållanden, vilket kan noteras. 35

41 Därför är det möjligt för andra typer av konstellationer att också ta del av denna uppsats vilket har nämnts tidigare. Men den underliggande orsaken till förhållandena som uppstår i den nationellt distribuerade konstellationen skiljer sig från det som samlade och internationellt distribuerade team upplever. Sättet som förhållandena appliceras inom olika konstellationer kan också ha olika effekter på utvecklingsteamet beroende på hur det är strukturerat (Alzoubi et al. 2015). Inom internationellt distribuerade konstellationer synkroniserar medlemmarna med varandra genom att gå tillbaka och kolla på vad som har utförts under natten, vilket sker främst på grund av skillnaden i tidszoner (Sutherland et al. 2006). I samlade team sker synkroniseringen genom att samtliga i teamet samlas under dagen och har det dagliga mötet, och under dagen kan också teamet enkelt kommunicera med varandra om det uppstår behov för det, vilket ger mer tillfällen för synkronisering mellan medlemmarna (Shrivastava & Date 2010). Vid nationellt distribuerade konstellationer uppstår problematik i detta skede (Bilaga 2). Främst eftersom grupperna är uppdelade på flera orter, men eftersom tidszonen är densamma på samtliga orterna blir det svårt för medlemmarna att veta vad som konstant sker på det andra kontoret, och att koppla upp sig mot det andra kontoret är mer tidskrävande jämfört med att kommunicera med varandra på samma kontorsplats (Sutherland et al. 2006). Shrivastava och Date (2010) menar att det kan ta längre tid att kontaktera en annan medlem som är lokaliserad på ett annat kontor och det kan leda till att medlemmar väljer att helt enkelt lösa uppgifter på egen hand istället för att välja att kommunicera med utvecklare på andra kontoret. Detta kan motarbetas genom användandet av dagliga möten där teamet kort sammanfattar och redovisar vad som har utförts under föregående dag (Sutherland et al. 2006). Men en sammanfattning kan också utelämna viktiga detaljer, vilket skapar en bristande synkronisering (Alqahtani et al. 2013). Utvecklingsarbetet fortskrider under samma tid på dygnet på alla kontoren i ett nationellt distribuerat team vilket gör det betydligt svårare att gå tillbaka och kolla på vad teamet på andra kontoret har utfört under dagen (Alqahtani et al. 2013). Detta jämfört med det internationella teamet som har möjligheten att se vad det andra teamet har utfört under tiden som det andra kontoret har avslutat sin arbetsdag eftersom tidszonerna inte stämmer överens (Alqahtani et al. 2013). Fallföretagets utvecklingsteam hade delade åsikter kring mötena som möjliggör synkronisering mellan teamets kontor och medlemmar (Bilaga 2). Synkroniseringsmöten innefattar främst dagliga möten men också sprintplanering, sprintgranskning och sprintåterblick (Schwaber & Sutherland 2014). Det är möjligt att de delade åsikterna skapar problematik under möten där det är tänkt att utvecklarna bör synkronisera med varandra genom bristande engagemang. Fallföretaget bör jobba mot ett mer enat utvecklingsteam, där Scrum mastern t.ex. kan lyssna på vad varje utvecklare har att säga angående arbetssättet för att ena teamet ytterligare, vilket kan förbättra samarbetet och kommunikationen Användningen av releasecykeln Det som framkommit från intervjuerna och observationen är att teamet för tillfället använder sig av överlappande releasecykler (Bilaga 2, Bilaga 3). Teamet består av en Scrum master, en testare och fyra utvecklare i Örebro samt fyra utvecklare i Borlänge, vilket är för få teammedlemmar för att hantera överlappande releasecykler vilket är i enlighet med det som Takeuchi och Nonaka (2004) menar, där isolerade releasecykler tar längst tid men kräver minst resurser, överlappande releasecykler kräver mer resurser och i gengäld minskar det tidskonsumptionen. Sutherland (2005) berättar att isolerade sprintar ger mindre team fördelen att granska och anpassa under stopptiden mellan sprintarna. Respondenterna påpekade att mötena som hanterar granskning och anpassning är alldeles för kontrollerade och restriktiva, vilket kan bero på tidsbristen under de överlappande releasecyklerna (Bilaga 2). Överlappande releasecykler påverkar testaren i hög grad och stressen är synlig, vilket testaren framhåller (Bilaga 2). Det kan bli svårt att hålla ihop det i det långa loppet under projekt i framtiden då fallföretaget vill ha en nationell distribuering samtidigt som mycket av arbetet sker på lokal nivå (Bilaga 2). 36

42 Takeuchi och Nonaka (2004) hävdar att alla på en gång (Figur 4) är den ultimata releasecykeln, men det kräver ett sammansvetsat utvecklingsteam som har stor erfarenhet av sprintar inom Scrum och kan exekvera det felfritt. Utvecklingsteamet i denna uppsats har en längre väg att gå innan det kan använda sig av denna metod som Takeuchi och Nonaka (2004) anser vara den effektivaste. Därför att det genom intervjuerna och observationerna framkommer att utvecklingsteamet är fast i valet mellan lokalt placerade team och nationellt distribuerade team därför att teamet anammar metodik från båda alternativen (Bilaga 2) Linjära utvecklingsteam och fokus på specialkompetens Enligt Schwaber och Sutherland (2014) består ett Scrum-team av produktägare, utvecklingsteamet, och en Scrum master. Utvecklingsteamen rekommenderas i största möjliga utsträckning vara självorganiserade och tvärfunktionella (Alzoubi et al. 2015). Därför kan det vara av potentiellt intresse för fallföretaget att sätta samman utvecklingsteamet tvärfunktionellt genom att distribuera testningen på flera personer och testaren kan få möjlighet att delta i utvecklingen till en viss grad också. Utvecklarna bör i första hand inte fördela uppgifterna utöver varje utvecklares specialiseringsområde, d.v.s. inte fördela uppgifterna utefter specialkompetensen (Sutherland et al. 2008). Istället bör utvecklingsteamet fokusera på att utföra uppgifterna tillsammans. Detta fungerar självklart endast till en viss grad vilket har påpekats tidigare (Kapitel 2). Där Sutherland et al. (2008) menar att enskilda medlemmar inom teamet möjligen kan ha en specialkompetens inom ett visst område men det överliggande ansvaret bör fortfarande ligga hos teamet i sin helhet. Majchrzak et al. (2012) nämner att team som inte är tvärfunktionella kan omvandlas genom att låta utvecklaren med specialkompetensen lära ut kunskap till de övriga medlemmarna i utvecklingsteamet i mindre iterationer, vilket resulterar i att tid åsidosätts för utlärning. Om detta kombineras med isolerade sprintar ger det teamet tid som det annars är brist på, främst genom stopptiden som uppstår mellan varje sprint, vilket också Takeuchi och Nonaka (2004) nämner. Sutherland et al. (2008) betonar betydelsen av att inte använda sig av några titlar inom utvecklingsteamet eftersom teamet bör vara linjärt. Det innebär att det inte borde existera testare överhuvudtaget. Alla rekommenderas existera som utvecklare och ingenting annat, Scrum master och produktägare exkluderade eftersom de inte ingår i utvecklingsteamet (Schwaber & Sutherland 2014). Schwaber och Sutherland (2014) anser att linjära utvecklingsteam skapar en bättre transparens därför att alla får ta del av all information inom Scrum-processen och projektet. Vilket i nuläget hindrar transparensen eftersom utvecklare och testare inte delar med sig av arbetsuppgifterna som de har med andra utvecklare som i nuläget inte har samma specialkompetens (Bilaga 2). I dagsläget prioriterar fallföretagets utvecklingsteam den enskilda individens kompetens d.v.s. specialkompetensen, framför samarbete mellan flera individer vid framtagningen av produktinkrement, vilket leder till att kommunikationen mellan utvecklarna blir lidande på grund av isoleringen (Bilaga 2). Detta kan också vara till en fördel i mindre och kortlivade projekt som kräver mindre interaktion mellan utvecklare från olika kompetensområden. Men eftersom de överlappande releasecyklarna överskrider den rekommenderade gränsen, på grund av längre ledtider mellan färdig programvara och produktionssättning, går det att dra slutsatsen att projektet inte är kortlivat. Jansson (2015) nämner en punkt som kan vara viktig för nationella konstellationer och som fallföretaget kan tänka på, och det är att det allra starkaste arbetet sker i ett kollektiv. Det är genom arbets-relationer snarare än vänskaps-relationer som teamet håller ihop (Jansson 2015). Genom det gemensamma arbetet blir individen en del av gruppen, teamet bör arbeta nära varandra, planera ihop, hjälpas åt och lösa problem tillsammans och se lösningarna tillsammans (Jansson 2015). Det är också det som Scrum främjar: kommunikation och samarbete (Schwaber & Sutherland 2014). Främjandet av kommunikation och samarbete framför individuell kompetens och isolering kan leda till transparens inom utvecklingsteamet. Det blir lättare att granska och anpassa sig, om alla delar med sig genom ökad kommunikation. Hur gör fallföretaget för att samarbeta när teamet är nationellt distribuerat? Det kan fallföretagets utvecklingsteam göra genom att börja arbeta över de nationella gränserna där utvecklingsteamet 37

43 tidigare avskärmat sig från varandra, d.v.s. genom att sluta dela upp projektets uppgifter utefter specialkompetensen. Det kontorsöverskridande samarbetet samt kommunikationen kan i längden förstärkas, vilket kan ske via chatt, videomöten samt andra tekniska hjälpmedel mellan utvecklarna under arbetstid. Alternativt kan teamet välja att gå en helt annan väg vilket är att minska samarbetet mellan kontoren, vilket kan gynna kortlivade utvecklingsteam, men eftersom detta utvecklingsteam är projektöverskridande resulterar det i att teamet jobbar tillsammans konstant, oavsett projekt. Ett alternativ till detta är att tilldela en person från varje kontor en position som förmedlare vilket Alqahtani et al. (2013) rekommenderar. Kommunikationen mellan kontoren kan då ske genom de tilldelade personerna som förmedlar information till det andra kontoret, samtidigt som utvecklingsteamen på de två kontoren enskilt kan fokusera på sina egna arbetsuppgifter. Det skapar en koppling mellan teamen som kan det leda till mindre stress på alla medlemmarna, samtidigt som det ger mer tid till utvecklingsteamet för andra arbetsuppgifter. Om det också sker en rotation varje vecka där den förmedlande personen byts ut leder det också till att samtliga utvecklare får kommunicera med det andra kontoret, vilket Alqahtani et al. (2013) menar kan påverka teamets kommunikation positivt i sin helhet. 38

44 5. Slutsatser I detta kapitel presenteras slutsatserna som baseras på analysen som har utförts. Vidare presenteras förslag på fortsatta studier som belyser områden som kan vara intressanta för framtiden och för fallföretagets arbete. Syftet med denna kandidatuppsats i Informatik var att identifiera, beskriva och förklara förhållanden i en nationellt distribuerad Scrum-process som påverkar den inre projekteffektiviteten. Det som framkommit genom studerandet av fallföretagets produktbacklog, sprintplanering, sprintbacklog, sprint, dagliga möte, sprintgranskning, sprintåterblick och produktinkrement är förhållanden som påverkar den inre projekteffektiviteten (Figur 5), och förhållandena kan användas som förslag, råd och vägledning. Företag och organisationer kan använda detta för att utvärdera sitt nuvarande arbetssätt. Indikatorerna för den beroende variabeln, inre projekteffektivitet (Figur 5), som är granskning, anpassning och transparensen påverkas av Scrum-processens innehåll. Det illustreras genom användandet av påverkanspilen i analysmodellen (Figur 5), där samtliga oberoende variabler och underliggande indikatorer i Scrum-processen ger en samlad påverkan på den inre projekteffektiviteten. Förhållandena i en nationellt distribuerad Scrum-process som kan påverka den inre projekteffektiviteten har jag redogjort för genom analysen. Det som företag, organisationer och andra nationellt distribuerade användare av Scrum-metoden bör tänka på är hur synkroniseringen påverkar utvecklingsteamet, därför att det kan skapa förhållanden inom utvecklingsteamet som inte är önskvärda, men som också kan vändas till teamets fördel om det appliceras korrekt. Det finns ingen absolut slutsats som säger att det bara finns ett korrekt tillvägagångssätt. Det beror helt på den rådande situationen inom det studerade området. Till exempel påverkar teamets uppbyggnad; är det ett projektöverskridande utvecklingsteam eller ett kortlivat som bara uppstår och avvecklas under ett projekt, hur stora är tidsskillnaderna mellan kontoren, vilken teknisk utrustning finns tillgänglig för utvecklingsteamet, har alla kontor samma förutsättningar, har utvecklarna alltid samma positioner inom projektet. Funderingar och frågor som kan ställas angående detta är många och det är väldigt situationsanpassat. Det som fungerar, eller inte fungerar för denna situation kan inte ses som en en universal sanning för alla konstellationer. Det gäller istället att först överblicka varje situation enskilt och därefter jämföra, hitta liknelser och skillnader, för att kunna dra några slutsatser. Synkroniseringen mellan utvecklingsteamets medlemmar inom nationellt distribuerade konstellationer skiljer sig från det som existerar inom internationellt och lokalt samlade konstellationer i och med att arbetstiderna inte skiljs åt likt det inom internationella konstellationer, men medlemmarna är inte lika tillgängliga för varandra likt samlade team. Att arbetet fortskrider under samma tider på dygnet på kontoren gör det svårt att se vad det andra kontoret har utfört. Dagliga möten bör fungera som det primära synkroniseringstillfället för utvecklingsteamet men det finns en delad åsikt om hur väl mötena fungerar (Bilaga 2). Under uppsatsen visade det sig att förhållandet till ett linjärt, tvärfunktionellt team kan påverka den inre projekteffektiviteten. Grundarna betonar betydelsen av det tvärfunktionella teamet genom sin Scrum-guide. Detta innebär det att varje utvecklare inom utvecklingsteamet bör släppa fokus från området som hanterar den specifika specialkompetensen. Scrum-metoden är i grunden avsedd för utvecklingsteam som är tvärfunktionella och avsaknaden av tvärfunktionalitet inom ett utvecklingsteam innebär att varje utvecklare enbart arbetar med det som de anses vara bäst lämpade för kunskapsmässigt. Det resulterar i att utvecklarna inte har någon kännedom om vad som pågår utanför specialiseringsområdet och det leder till att transparensen påverkas, som är direkt kopplad till den inre projekteffektiviteten (Figur 5). Att genomföra en övergång mot ett mer tvärfunktionellt, linjärt stadium har fördelar och nackdelar, t.ex. får teamet fler aspekter på problemlösningen eftersom det är en blandad grupp som har olika kunskaper, detta innebär att samarbetet med utvecklare som har andra kunskaper skapar en 39

45 behagligare väg till utvecklingsteamets mål. Samordningen i utvecklingsteamet påverkas positivt och kan leda till att produktionstiden minskar, vilket möjliggör en kortare releasecykel. Det kan också medföra nackdelar, exempelvis kan det bli en utmaning för teamet att balansera gruppens erfarenheter och kunskaper. Tvärfunktionalitet är också något som förmodligen inte kommer att ha någon positiv effekt i kortlivade konstellationer främst för att det tar tid för utvecklarna att ta sig an nya uppgifter och kunskaper, och därför lönar sig det istället att helt bryta samarbetet mellan teamen och skapa två separata team som jobbar mot samma mål, men att produktspecifikationen bryts mellan de två kontoren för att skapa oberoende, självständiga team. Tvärfunktionalitet är i sig ingenting unikt för nationella konstellationer men kan påverka andra typer också. Men sättet som förhållandena påverkar utvecklingsteamet kan skilja sig åt, vilket har exemplifierats. Det kan också ses som betydelsefullt att minska pressen på specifika rollinnehavare, t.ex. testare, genom att avskaffa överlappande releasecyklar och övergå till isolerade releasecykler (Figur 4). De isolerade releasecyklerna tillåter utvecklingsteamet i Scrum-metoden att genomföra granskning och anpassning mellan sprintarna eftersom det uppstår stopptid. Nackdelen blir att de isolerade sprintarna leder till en längre produktionstid, men under långa projekt som kräver ständigt fokus är det viktigt att granskning och anpassning sker regelbundet för att behålla transparensen i utvecklingsteamet. Valet av releasecykel bör återspeglas på teamets struktur. Om teamet är nationellt uppdelat, stort, och endast består av en gemensam Scrum master, bör utvecklingsteamet använda sig av isolerade releasecykler för att ge teamet tid att samla krafterna och synkronisera mellan varje releasecykel. Användandet av en synkroniserad releasecykel, d.v.s. alla på en gång (Figur 4) är positivt om utvecklingsteamet har erfarenheten som krävs för att implementera den. Alla på en gång innebär att utvecklingsteamet behöver vara sammansvetsat och alla i teamet bör ha en global syn på hela projektet på en daglig basis, d.v.s. graden av transparens genom teamet bör vara stor. Men som jag ser det är det väldigt svårt att klara av detta eftersom utvecklingsteamet får det väldigt svårt att synkronisera med varandra p.g.a. distansen mellan alla medlemmar. Kommunikationen i utvecklingsteamet är ett av verktygen i Scrum-metoden som är det viktigaste för att teamet ska kunna fungera och prestera. Scrum-metoden ställer krav på en linjär struktur, vilket innebär att det inte finns någon uttalad chef och det betyder att större krav ställs på att medlemmarna pratar och samarbetar med varandra för att se till att utvecklingsteamet gör rätt och når målen. Om utvecklingsteamets medlemmar isolerar sig och enbart fokuserar på sitt eget arbete kan det leda till att transparensen påverkas negativt. De dagliga mötena, sprintplanering, sprintgranskningen samt sprintåterblicken är alla ypperliga tillfällen för utvecklingsteamet att kommunicera ut det som är i produktion för tillfället. Problematiken kring mötena kan försöka lösas genom användandet av utsedda förmedlare, som analyserats tidigare. Det som tidigare också framkommit är att distribueringen bidrar till att interaktionen mellan medlemmarna minskar, vilket påverkar teamets gruppdynamiska utveckling eftersom interaktionen tar längre tid, och blir därför bräckligare (Bilaga 2). Därför kan det vara fördelaktigt att fokusera på att främja samarbete och kommunikation för att minimera den nationella distribueringens påverkan på utvecklingsteamets inre projekteffektivitet. Vid en eventuell avveckling av de tydliga rollerna för att utföra transitionen till ett tvärfunktionellt team, ställer det krav på att medlemmarna delar med sig av kunskapen som de har med varandra, vilket till att börja med kan leda till problem och missförstånd eftersom inlärningsprocessen kan ta tid. Om specifika roller existerar inom utvecklingsteamets struktur, kan denne med den specifika rollen, börja med att lära upp delar av utvecklingsteamet för att minska beroendet och pressen på denne. I framtiden kan det leda till komplett avveckling av dennes specifika roll, och arbetsuppgifter. En kunskapsspridning kan även ge kraftfullare team framöver genom att flera kan göra varandras arbetsuppgifter. Det ger ökad teamkänsla då tydlighet, öppenhet och bättre samarbete blir till samtidigt som alla utvecklarna motiveras av varandra och bidrar till ökad transparens, granskning och anpassning i utvecklingsteam som arbetar projektöverskridande. Men vid tillfällen där utvecklingsteam uppstår och avvecklas under korta perioder är det svårt att utföra dessa transitioner eftersom att arbetsuppgifterna är komplicerade och kan kräva mycket ansträngning från utvecklarnas sida vilket inte resulterar i något större värde under kortare tider. 40

46 Fallföretaget är för tillfället väldigt delat i åsikterna, som det går att se under uppsatsens gång, där det finns en vilja att samarbeta mellan kontoren samtidigt som majoriteten av arbetet sker enskilt. Till att börja med rekommenderas det att oenigheten reds ut innan andra beslut tas för att motverka påverkan som det kan ha på den inre projekteffektiviteten. 5.1 Förslag på fortsatta studier Det kan i framtiden vara intressant att studera den yttre projekteffektiviteten, d.v.s. hur produktägare, kunder och andra investerare påverkas av utvecklingsteamets hantering av Scrum i nationellt distribuerade konstellationer. I dagsläget är majoriteten av litteraturen som behandlar distribuerade utvecklingsteam fokuserade på den internationella nivån istället för den nationella, och den uppdelningen påverkar team annorlunda. Efter denna uppsats genomförande finns fortfarande frågor att ställa och besvara. Det finns ytterligare utrymme att utföra vidare studier inom området genom olika fördjupningar i slutsatserna som framkommit genom uppsatsen. Därigenom kan denna uppsats nyttjas som utgångspunkt för de eventuella fortsatta studierna. Vidare skulle det också vara intressant att utföra ett liknande arbete om något år för att se vad som har förändrats i den nationellt distribuerade konstellationens Scrum-process. Om en sådan uppsats genomförs skulle det vara intressant att inkludera förhållanden i den yttre projekteffektiviteten som påverkar Scrum-processen, d.v.s. inkludera kunder, produktägare och andra intressenter av projektet, och inkludera projektets aspekter mer, istället för att enbart fokusera på Scrum-processen. Uppsatsen genomfördes i en Scrum-process där projektet inte är avklarat, vilket innebär att förändringar kan ske i ett senare skede, det skulle därför vara intressant att ett studera och utvärdera ett avslutat arbete, och därigenom intervjua produktägare, kunder och andra intressenter för att inkludera inre samt yttre projekteffektivitet. 41

47 Källförteckning Skriftliga källor Agile Manifesto. (2001). Principles behind the Agile Manifesto. (Hämtad ) Agile Sweden. (2002). Om Agile. (Hämtad ) Alqahtani, A-S. Moore, J-D. Harrison, D-K. Wood, B-M. (2013). The Challenges of Applying Distributed Agile Software Development: A Systemmatic Review. International Journal of Advances in Engineering & Technology. (5) Alzoubi, Y. Gill, A. Al-Ani, A. (2015). Empirical studies of geographically distributed agile development communication challenges: A systematic review. Information & Management, 53, Andersen, E-S. (1994). Systemutveckling: principer, metoder och tekniker. Lund: Studentlitteratur. Asproni, G. (2004). Motivation, Teamwork, and Agile Development. Agile Times. (4) Bell, J. (2000). Introduktion till forskningsmetodik, Lund: Studentlitteratur. Björkholm, T. Brattberg, H. (2010). Prioritera, Fokusera, Leverera Din snabbguide till Lean, Agile, Scrum och XP. (Hämtad ) Bryman, A. (2011). Samhällsvetenskapliga metoder. Stockholm: Liber. Bryman, A. Bell, E. (2003). Företagsekonomiska forskningsmetoder. Malmö: Liber. Cockburn, A. (2002). Agile Software Development. The agile Software Development Series. Pearson Education, Inc. Cohen, L. Manion, L. Morrison, K. (2007). Research methods in education. 6th edition. London: Routledge. Computer Sweden. (2014). Så lockas en agil utvecklare. (Hämtad: 2/2 2017) Deemer, P. Benefield, G. Larman, C. Vodde, B. (2009). The Scrum Primer. Version 1.1. Scrum Training Institue. Denscombe, M. (2000). Forskningshandboken. Lund: Studentlitteratur. Denscombe, M. (2009). Forskningshandboken för småskaliga forskningsprojekt inom samhällsvetenskaperna. Lund: Studentlitteratur. Eckhart, M. Feiner, J. (2016). How Scrum Tools May Change Your Agile Software Development Approach. 8 th International Conference SWQD 2016, Engwall, M. Kling, R. Werr, A. (2005). Models in action: how management models are interpreted in new product development. R&D Management. (4) Ejvegård, R (2009). Vetenskaplig metod. 4. uppl. Lund: Studentlitteratur 42

48 Hossain, E. Babar, A-M. Paik, H. (2009). Using Scrum in Global Software Development: A Systematic Literature Review. Fourth IEEE International Conference on Global Software Engineering Jacobsen, D-I. (2002). Vad, hur och varför Om metodval i företagsekonomi och andra samhällsvetenskapliga ämnen. Översatt till svenska av: Sandin, G. Bearbetning av den svenska upplagan av Hellström, C. Lund: Studentlitteratur. Jacobsen, D-I. Thorsvik, J. Sandin, G. (2008). Hur moderna organisationer fungerar. Översatt till svenska av: Sandin, G. Larson, P. Lund: Studentlitteratur. Jalali, S. (2012). Efficient Software Development Through Agile Methods. Licentiate thesis: Blekinge Tekniska Högskola: Karlskrona. Jansson, T. (2015). Agila projektledningsmetoder och motivation: Varför man blir produktiv av att flytta lappar på en whiteboard. Doktorsavhandling: Karlstad Universitet: Karlstad. Jeldi, P-N. Chavali, V-K. (2013). Software Development Using Agile Methodology Using Scrum Framework. International Journal of Scientific and Research Publication. (3) Johannessen, A. Tufte, P-A. (2003). Introduktion till samhällsvetenskaplig metod. Malmö: Liber. Johansson, B. Svedner, P.O. (2006). Examensarbetet i lärarutbildningen: undersökningsmetoder och språklig utformning. 4. uppl. Uppsala: Kunskapsföretaget Juyun, C. (2008). Issues and challenges of agile software development with Scrum. Colorado State University: Colorado, Kvale, S. (1997). Den kvalitativa forskningsintervjun. Studentlitteratur. Lahiri, N. (2010). Geographic Distribution of R&D Activity: How Does It Affect Innovation Quality? Academy of Management Journal. (53) Lindvall, M. Basili, V. Boehm, B. Costa, P. Dangle, K. Shull, F. Tesoriero, R. Williams, L. Zelkowiz, M. (2002). Empirical Findings in Agile Methods. SpringerVerlag Majchrzak, A. More, P. Faraj, S. (2012). Transcending Knowledge Differences in Cross-functional teams. Organization Science. (23) Malterud, K. (1998). Validitet. Kvalitativa metoder i medicinsk forskning. Lund: Studentlitteratur. Marchenko, A. Abrahamsson, P. (2008). Scrum in a Multiproject Environment: An Ethnographically- Inspired Case Study on the Adoption Challenges. Nokia: Tampere. Maxwell, J. (2005). Qualitative research design: An interactive approach. Sage publications. Miles, M. Huberman, A. (1994). Qualitative data analysis. Sage Publications. Nuevo, E. Piattini, M. Pino, F. (2011). Scrum-based Methodology for Distributed Software Development. Sixth IEEE International Conference on Global Software Engineering Nyman, M. (2010). Agila metoder Radikal revolution eller enkel evolution? Wenell Management AB. (Hämtad ) 43

49 Oates, B. (2006). Researching information systems and computing. London: SAGE. Palm, J & Östman, A. (2001). Användarna nyckeln till ökad användbarhet. Magisteruppsats. Göteborg: Göteborgs Universitet/Institutionen för Informatik. (Hämtad ) Patel, R. Davidsson, B. (2003). Forskningsmetodikens grunder: Att planera, genomföra och rapportera en undersökning. Lund: Studentlitteratur. Patel, R. & Davidsson, B. (2011). Forskningsmetodikens grunder: Att planera, genomföra och rapportera en undersökning. Lund: Studentlitteratur. Plohmann, D. Eschweiler, D. Gerhards-Padilla, E. (2013). Patterns of a Cooperative Malware Analysis Workflow. 5th International Conference on Cyber Conflict Pries-Heje, L. Pries-Heje, J. (2011). Why Scrum works: A case study from an agile distributed project in Denmark and India Agile Conference Repstad, P. (1998). Närhet och distans - Kvalitativa metoder i samhällsvetenskap. Studentlitteratur: Oslo. Scrumguides. (2017). The Scrum Guide. (Hämtad ) Schwaber, K. Beedle, M. (2002). Agile Software Development with Scrum. Upper Saddle River, NJ: Prentice-Hall, Inc. Schwaber, K. Sutherland, J. (2011). The Scrum papers: nuts, bolts and origins of an agile method. Scrum Inc, Paris. Schwaber, K. Sutherland, J. (2014). Scrumguiden, den definitiva guiden till Scrum: Spelets regler. (Hämtad ) Shrivastava, S-V. Date, H. (2010). Distributed Agile Software Development: A Review. Journal of Computer Science and Engineering. (1) Solvang, B. Floistad, G, Kjeldstadli, K. O Gorman, D & Holme, I. (1997). Forskningsmetodik om kvalitativa och kvantitativa metoder. Lund: Studentlitteratur. Sutherland, J. (2005). Future of Scrum: Parallel Pipelining of Sprints in Complex Projects. Agile 2005 Conference Sutherland, J. Viktorov, A. Blount, J. Puntikov, N. (2006). Distributed Scrum: Agile Project Management with Outsourced Development Teams. International Conference on System Science Sutherland, J. Schoonheim, G. Rustenburg, E. Rijk, M. (2008). Fully Distributed Scrum: The Secret Sauce for Hyperproductive Offshored Development Teams. in Agile Takeuchi, H. Nonaka, I. (2004). Hitotsubashi on Knowledge Management. Singapore: John Wiley & Sons. Yin, R. (1989). Case study research Design and Methods. Newbury Park: Sage Publications. 44

50 Muntliga källor Scrum master Personlig intervju. Fallföretag /12. Örebro Utvecklare 1 Personlig intervju. Fallföretag /12. Borlänge Utvecklare 2 Personlig intervju. Fallföretag /12. Borlänge Testare Personlig intervju. Fallföretag /12. Örebro 45

51 Bilagor Bilaga 1 Intervjuguide 1 Bakgrundsrelaterade frågor: 1.1 Vad har du för akademisk bakgrund? Har du någon specifik utbildning/certifiering inom Scrum/agila metoder, hur väl tycker du att du känner till teorin bakom Scrum? 1.2 Hur länge har du arbetat med Scrum under ditt arbetsliv? Hur länge har du arbetat på detta företag och hur länge har du haft denna befattning? 2 Inre projekteffektivitet: 2.1 Vilka är enligt dig de största fördelarna med Scrum? Finns det något i utvecklingsteamets arbetssätt som du känner, bör förändras? 2.2 Team i Scrum ska enligt praxis vara tvärfunktionella, d.v.s. att inte några klara roller får finnas, men hos er finns det tydliga roller och arbetsuppgifter (Scrum master-utvecklare-testare), hur påverkas teamet av detta, hur påverkar den nationella distributionen av teamet det hela? 2.3 Teamet är uppdelat på två orter, hur tycker du att detta har påverkat er? Sitter teamen tillsammans i samma rum på kontoren eller sitter alla för sig? Vad ser du för nackdelar/fördelar med denna nationella uppdelning? Vad har ni för planer i framtiden? Känner du att ett lag på en ort skulle fungera bättre eller vill du ha ett lag som är uppdelat på två orter? Varför? Hur är sammanhållningen i teamet, har den påverkats av uppdelningen? Hur effektivt anser du att det är att ha teamet uppdelat på två orter? Tror du att det skulle vara effektivare och dela upp teamen helt eller flytta ihop, ser du alternativt någon annan lösning? 2.4 Tycker du att det finns en transparens genom er process, finns det en gemensam förståelse för det man ser och gör? Hur ofta granskar ni processerna samt artefakterna? Vilka utför granskningarna och sker det regelbundet? Om avvikelser hittas vid granskningarna, hur anpassar man sig för att utesluta avvikelser? 3 Produktbacklog: 3.1 Hur sker prioritering av user stories hos er, vilka är delaktiga i prioriteringen? 3.2 Hur går estimeringen av inkommande user stories till, hur delaktiga känner ni att ni får vara i bestämmandet av detta? 3.3 Inkommande krav behöver förfinas för att passa in i en sprint, hur delaktiga är ni i detta? 3.4 Hur tycker du att distribueringen av teamet har påverkat aspekterna som vi precis har pratat om? 4 Sprintplanering och sprintbacklog: 4.1 Hur delaktig känner du, att du är vid planeringen samt beslutsfattandet av sprintens innehåll? 4.2 Hur påverkar den nationella distributionen av teamet själva kommunikationen under sprintplaneringen? 4.3 Hur sker fördelningen av backlogens uppgifter? Fördelas det utefter kompetens, kontor eller båda? 4.4 Utförs nedbrytning och uppdatering av uppgifterna, vem gör det och varför? 5 Sprint och dagligt möte 5.1 Tycker du att det finns något värde i de dagliga mötena, varför tycker du det? Är deltagande obligatoriskt? Tycker du att tidsbegränsningen på 15 minuter påverkar resultatet av mötet? 5.2 Hur kommunicerar ni med andra deltagarna under sprinten, alltså Scrum master, produktägare, kund och andra medarbetare i teamet? 5.3 Vad tycker du om sprintens uppbyggnad, når ni era uppsatta mål varje sprint? 46

52 6 Produktinkrement, sprintgranskning och sprintåterblick 6.1 Hur ser du på definitionen av klart, är ni överens om detta inom teamet? 6.2 Redovisning och kommunicering med kund angående produktinkrement, hur sker detta? 6.3 Hur sker samarbetet och kommunikationen under sprintgranskningen? 6.4 Hur delaktig känner du att du får vara under granskningen 6.5 Vilka deltar vid sprintåterblicken, hur kommuniceras allt från mötet ut, är det obligatoriskt deltagande? 6.6 Hur delaktig känner du att du är vid planeringen och förbättringen av nästa sprint? 7 Rollspecifika frågor: Scrum master 7.1 Beskriv din roll som Scrum master i detta företag, vad är det specifikt som du gör? Hur hjälper du ditt team att nå målen, vilka problem kan du tänkas lösa åt teamet? 7.2 Tycker du att den nationella distribueringen av teamet påverkar din kommunikation med hela teamet och produktägaren, varför? 7.3 Om du av någon anledning är borta, hur hanteras teamet? 7.4 Skulle du föredra ett samlat team eller tycker du att det som används för tillfället är bättre, varför? 7.5 Hur påverkar den nationella uppdelningen er kontakt med kunden? 8 Rollspecifika frågor: Utvecklare 8.1 Hur bra anser du att kommunikationen är mellan utvecklare och Scrum master respektive testare? 8.2 Hur är arbetsbelastningen, ni använder er av överlappande releasecykler, hur påverkar det dig? 8.3 Hur tycker du att samarbetet med utvecklarna på den andra orten går? 8.4 Kör ni med parprogrammering, om ja, hur har den nationella uppdelningen påverkat detta, om nej, vad kör ni med för andra tekniker? 9 Rollspecifika frågor: Testare 9.1 Du är den enda testaren i teamet, vad händer om du är borta? 9.2 Hur hanteras problem, till exempel buggar, problem med design eller kod, om du behöver ha kontakt med någon på andra kontoret? 9.3 Vad gör du om det uppstår problem? Vem rådgör du med eftersom det inte finns ytterligare testare? 47

53 Bilaga 2 Sammanställning av intervjuer Här har samtliga intervjuer sammanställts för att tydliggöra svarens plats i analysmodellen. Kolumnen till vänster visar den aktuella variabeln samt de underliggande indikatorerna. Högra kolumnen visar vad varje respondent har sagt i frågan. Del i analysmodell Inre projekteffektivitet Team A och Team B Produktbacklog Sprintplanering Sprintbacklog Sprint och dagligt möte Produktinkrement Sprintgranskning Sprintåterblick Sammanställning - Rollspecifika frågor Scrum master Scrum mastern sammanfattar sin roll inom företaget med att han ska se till att målen nås, hålla kontakt med produktägaren, kunderna och teamet, för att se till att behoven alltid är synkade och att rätt saker görs vid rätt tid. Problemen som oftast inte testare eller utvecklare klarar av på egen hand utan istället kräver kommunikation med Scrum mastern som i sig oftast kontaktar produktägaren är till exempel större funktioner som kräver mer uppmärksamhet för att få helt enligt kundernas specifikationer. Scrum mastern tycker personligen inte att den geografiska uppdelningen är ett större hinder, han känner även att han har en bra kontakt med alla inom teamet främst för att det finns tillgång till en videolänk. Han nämner att utan videolänken så hade det inte varit möjligt att kommunicera på ett effektivt vis mellan kontoren överhuvudtaget. Självklart hade ett samlat team varit att föredra när det gäller Scrums riktlinjer och metodiken bakom Scrum nämner han, men kostnaden för detta hade varit alldeles för stor och påfrestande för själva företaget. Om jag är borta så har alla uppgifter som måste utföras och detta är förspeciferat, nämner han. Ansvaret fördelas över hela teamet men det har aldrig hänt att Scrum mastern varit borta under en längre tid och det har aldrig påverkat teamet. Den geografiska distribueringen har påverkat kontakten med kunden på ett positivt sätt då det blir närmare för kunden att besöka oss och besöken sker på ett mer frekvent vis än vad som hade skett om endast ett kontor hade funnits. Men självklart försöker vi åka ut till kunderna i de flesta fallen så detta är inte något som påverkar kunden för mycket. Om något ska demonstreras så sker det oftast på plats hos kunden om det inte gäller något betydligt mer avancerat som kräver att demonstrationen sker på något av företagens kontor i Borlänge och Örebro. Testare Det som händer när testaren är borta är att någon måste fylla hans position vilket oftast blir någon annan utvecklare. Han nämner att det inte är alla som har tidigare erfarenhet av testande och om alla som besitter kunskap inom testandet är borta så kan det bli kris men detta har aldrig hänt och han hoppas att det aldrig händer, men han känner att det inte kommer att funktionera i längden och att det måste hittas en bättre lösning, där han föreslår att företaget utbildar flera av utvecklarna och lättar på uppgifterna för den utsedda testaren, alternativt sprida ut uppgifterna som är relaterade till testningen över alla utvecklare istället för att ha en utstedd testare. Han anser att det lättaste skulle vara att anställa en testare till som arbetar på heltid med det men han nämner att det inte skulle vara det mest kostnadseffektiva. Om problem som är relaterade till projektet måste lösas med någon utvecklare på andra kontoret så sköts det via en videolänk mellan testaren och den berörda utvecklaren som tar hand om den specifika uppgiften i backloggen. Om inte videolänk funktionerar så finns alltid tillgång till en chattfunktion som alla utvecklare har tillgång till. Det är inte alltid lätt att demonstrera och förstå sådant som nämns över videolänk och missförstånd har skett väldigt många gånger då en bugg som skulle fixats enkelt istället eskladerade och blev ett ännu större problem med fler berörda utvecklare på grund av missförstånd i grunden. Att sitta tillsammans hade självklart varit det mest effektiva men att flytta ett helt kontor är troligen inte värt det då resurserna som krävs är allt för stora i dagsläget. Om problem uppstår som är relaterade till testningen så rådgör testaren med andra utvecklare i teamet för att höra hur det tycker och tänker. Om det fortfarande inte går att lösa så tar teamet det till Scrum mastern som då tar upp det med hela teamet men detta sker endast i extremfall och har enligt testaren aldrig hänt under dennes tid på företaget. 48

54 Inre projekteffektivitet Team A och Team B Produktbacklog Sprintplanering Sprintbacklog Sprint och dagligt möte Produktinkrement Sprintgranskning Sprintåterblick Utvecklare 1 Kommunikationen mellan utvecklare och scrummästare är tillräckligt bra för att utföra arbetet som det planerats men utvecklaren känner att det fortfarande kan förbättras om teamet får bättre kontakt med Scrum mastern det krävs ett bättre socialt band som kanske sträcker sig utöver det arbetsrelaterade. Utvecklaren hade önskat fler sociala aktiviteter med hela teamet för att komma närmare de personerna som sitter på andra kontoret eftersom att kontoren Örebro och Borlänge samarbetar i många projekt under lång tid vilket skulle stärka banden och göra det hela bättre, anser utvecklaren. Bandet mellan testaren och utvecklaren anser han är bättre då det är enkelt att få kontakt med honom via videolänk genom arbetets gång under dagarna. Arbetsbelastningen passar utvecklaren perfekt med det kan uppstå förstoppning eftersom att det endast finns en testare nämner han. Många funktioner måste testas innan de kan slutföras helt och har utvecklaren ingenting att göra så uppstår det ett stopp i produktionen för honom. De överlappande releasecyklarna är orsaken till detta enligt honom då testaren måste testa väldigt ofta, och releasecyklarna är lite längre än vanligt som teorin i scrum nämner vilket gör att när det tar slut på uppgifter att utföras så kan det ta lite längre tid innan fler funktioner måste utvecklas. Att det blir stopp innebär att det kan ta längre tid innan en funktion går igenom, och om den inte gör det så får utvecklaren tillbaka den samtidigt som han är mitt uppe i en annan uppgift, och då kan det hända att utvecklaren glömmer bort vad som gjorts och det saktar ner arbetet. Samarbetet med utvecklarna på andra orten är ganska bra, tyvärr arbetas det inte så ofta med de utvecklarna, teamet försöker istället dela upp arbetet så att utvecklarna på Borlänges kontor jobbar tillsammans och utvecklarna på Örebros kontor arbetar tillsammans, samarbete mellan kontoren sker oftast när större funktioner skall implementeras och det krävs kompetens från båda kontoren för att få resultat. I och med att utvecklarna oftast samarbetar mellan varandra på kontoret som utvecklarna finns stationerade på så förekommer inte någon parprogrammering mellan kontoren och då berörs vi inte av problemen som skulle uppstå där säger han. Istället använder teamet sig av parprogrammering mellan utvecklarna som finns på kontoret, om det så krävs, om funktionerna istället är väldigt små så ser han inte poängen med parprogrammering. Då håller utvecklarna sig istället för sig själv och sedan när utvecklaren i fråga är klar så skickar denne funktionen till testaren för slutförandet och implementeringen. Utvecklare 2 Utvecklaren tycker att kommunikationen mellan utvecklare och Scrum master är dålig. Ibland kan det ta lång tid att få svar och eftersom att Scrum mastern har många bollar i luften i detta projektet så kan det ta lång tid innan respons fås på sådant som frågats. Självklart beror det på den geografiska uppdelningen nämner han, det skulle ju ha varit betydligt enklare att få direkt kontakt om vi varit på samma kontor. Detta gäller testaren också, och eftersom att testaren är väldigt överbelastad verkar det som, så kan det också ta lång tid innan utvecklaren får sina funktioner testade och implementerade. Men trots det så är det lättare att få kontakt med testaren då denna oftast finns tillgänglig via chattfunktionen. De överlappande releasecyklarna är alldeles för långa för utvecklaren smak och det drar ut på det hela. Utvecklaren nämner att det saknas fart i arbetet och att det ofta händer att funktionernas deadline missas vilket gör att det snabbt blir ett påslag med stress samtidigt som de inledande dagarna i varje cykel är väldigt lugna. Samarbetet med utvecklarna på den andra orten är helt okej, de gånger vi arbetar tillsammans, vilket är väldigt sällan, nämner han. När det gäller parprogrammeringen så ser han gärna att fler arbetar tillsammans för att stärka banden och han hade önskat att parprogrammering sker mellan kontoren för att stärka banden mellan utvecklarna på de två kontoren. 49

55 Del i analysmodell Produktbacklog Sammanställning Scrum master Prioritering och estimering av user stories sker främst av produktägaren men Scrum mastern nämner att han helst önskat att teamet varit mer delaktigt då det underlättar vid förståelsen av backlog objekten. Scrum mastern vill se ett lika stort deltagande vid prioritering och estimering som vid förfiningen. Scrum mastern anser att det är en utmaning att försöka anamma de aspekterna på ett geografiskt distribuerat team främst på grund av kommunikationen som ibland tar längre tid men han säger att man försöker se det positiva på det hela. Testare Testaren ser inte något som helst problem med att låta produktägaren utföra prioriteringen av user stories på egen hand, han anser också att estimeringen och förfinandet kan utföras av produktägaren eftersom att det hör till hans uppgifter att hantera user stories som kommer in men att det förmodligen påverkar teamets förståelse av allt som kommer in. Testaren är inte med vid förfiningen men hade önskat det för att skapa en bättre förståelse och transparens för honom. Det underlättar också vid testandet om deltagande vid förfining existerat, nämner testaren. Testaren tror att det hade varit betydligt mer effektivt att hantera produktbackloggen om alla fick ta del av alla delar för att möjliggöra transparensen genom hela processen men att den geografiska distribueringen kan sätta "käppar" i hjulen. Utvecklare 1 Utvecklare 1 anser att teamet bör vara mer delaktigt vid prioriteringen och estimeringen av produktbackloggen men att produktägaren fortfarande ska vara huvudansvarig för den som kommer in. Förfiningen är utvecklare 1 med och deltar och anser att det är bra att så många är med. Utvecklare 1 säger att det enbart påverkar negativt att hantera produktbackloggen om teamet är geografiskt uppdelat med undantag för att det blir närmare till kunderna om något måste klargöras, även fast detta också kan göras via telefon i de flesta lägena, säger han. Utvecklare 2 Utvecklare 2 vill att hela teamet är delaktigt vid upplägget av produktbackloggen för att få en större förståelse för alla user stories som kommer in, detta innebär deltagande vid prioritering, estimering och förfinande. Utvecklare 2 tycker att det stora deltagandet vid förfiningen kan skapa problem och tidsbrist för att alla vill vara med och disskutera. Utvecklare 2 berättar att han inte ser någon större påverkan på själva produktbackloggen i och med den geografiska distribueringen. 50

56 Del i analysmodell Sprintplanering Sprintbacklog Sammanställning Scrum master Scrum mastern berättar att han försöker få med hela teamet vid sprintplaneringen genom att anordna videokonferenser för att främja kommunikation mellan teamen, vilket samtliga respondenter instämmer om i sina respektive svar. Fördelningen av backloggens uppgifter sker utefter kompetens berättar Scrum mastern Detta på grund av att det inte är ett tvärfunktionellt team och några utvecklare besitter bättre kompetens inom specifika områden. Om det är en större grupp med uppgifter som ska utföras som hör till samma område så fördelas oftast backloggens uppgifter utefter kontor, vilket påverkar sammanhållningen mellan kontoren negativt men det ökar produktiviteten menar scrummästaren. Scrum mastern berättar att kraven kommer in genom produktägaren där de förs in i produktbackloggen nedbrytna och klara, därefter så bryts de ner ytterliga under sprintplaneringen för att passa in i sprintens tidsrymd. Uppdatering av sprintbackloggen sker av teamet tillsammans fortsätter han. Testare Samtliga berättar att de är deltagande vid mötet men att mängden beslutsfattande är ganska begränsat, detta är båda utvecklarna noga med att poängtera. Samtliga anser även att kommunikationen påverkas lika i denna del av arbetet som i alla andra, att det finns brister i kommunikationen som sker via videomöten eller chatt är ingen nyhet, menar testaren. Utvecklare 1 Utvecklare 1 är deltagande vid sprintplaneringen men berättar att beslutsfattandet vid mötet är begränsat. Vidare berättar utvecklaren att fördelningen av sprintens uppgifter sker utefter kompetens vilket han menar är negativt då det resulterar i att kompetensen inom specifika områden kommer ligga på enskilda personer och inte hela gruppen tillsammans vilket skapar problem. Utvecklare 2 Utvecklare 2 anser också att deltagandet är delvis begränsat på grund av kommunikationen, vilket i sig påverkar besluten och planeringen under mötet. Detta påverkar direkt fördelningen, nedbrytningen och uppdateringen av produktbackloggens uppgifter menar utvecklaren. Vidare berättar utvecklaren att han anser att problemet delvis ligger i uppdelningen av teamet. 51

57 52