Transition till en agil metod En studie av stora mjukvaruorganisationers användning av agila metoder

Transkript

1 Uppsala Universitet Inst. för informatik och media Transition till en agil metod En studie av stora mjukvaruorganisationers användning av agila metoder Lucas Grönlund & William Magnusson Kurs: Examensarbete Nivå: C Termin: VT-17 Datum: Handledare: Franck Tétard

2 Sammanfattning Målet med denna uppsats är att bidra med förklarande kunskap om hur en transition från traditionella systemutvecklingsmetoder till agila systemutvecklingsmetoder kan genomföras, vilka problem som kan uppstå under övergången samt de utmaningar organisationen ställs inför vid en övergång. Vidare är målet också att bidra med vägledande kunskap i den mån att den ska belysa möjliga fallgropar som kan undvikas och vilka aspekter som är viktiga att ta hänsyn till vid en övergång till en agil metod. Detta genomförs genom en förklarande fallstudie (Oates, p. 143, 2006) av övergången till agil systemutveckling från en annan, icke-agil metod. Den slutgiltiga uppsatsen ämnar att bidra med en kunskapsgrund till i vilka förhållanden det finns en möjlighet att byta till en agil metod. Undersökningens resultat visar att det det finns goda möjligheter för en övergång men att det är viktigt att både de som driver förändringen och övriga involverade har förståelse för vad som kommer att förändras. Framförallt människors ovilja att lämna bekväma strukturer och ta sig an nytt ansvar är problem som en organisation behöver vara medveten om och har förståelse för ifall en övergång ska lyckas. På en större skala är det också extra viktigt för organisationen att besitta de rätta förutsättningarna för en övergång utöver en djupare kunskap i de olika variationerna av skalning som tas upp i uppsatsen. Nyckelord Agile, agilitet, agil systemutveckling, systemutveckling, systemutvecklingsmetoder, transition, övergång till agil, scrum, LeSS 1

3 Innehållsförteckning 1. Inledning 1.1 Bakgrund 1.2 Problemformulering 1.3 Syfte och forskningsfrågor Förväntningar 1.4 Avgränsning 1.5 Kunskapsintressenter 1.6 Disposition 2. Teori 2.1 Begreppsdefinition Systemutveckling Ramverk och metoder Kundkontakt Skalbarhet Co-located, remote team member, distributed team: Onshore och Offshore Definition of Done 2.2 Den agila filosofin 2.3 Agil systemutveckling 2.4 Ramverk: Scrum och LeSS Grundläggande Scrum Roller inom Scrum Grundläggande LeSS, Large-Scale Scrum Smaller LeSS Sprintplanering 2.5 Tidigare forskning Nerur et. al (2005) Turk et. al. (2002) Saeeda et. al. (2015) Rolland et. al. (2016) Bass (2014) 2.6 Teoretiskt ramverk 3. Metod 3.1 Forskningsstrategi 3.2 Val av empiri 3.3 Metodik för datainsamling 3.4 Intervjuer Utformning av intervjufrågor 2

4 3.4.2 Urval av informanter 3.5 Metodik för dataanalys 3.6 Forskningsparadigm 3.7 Kritisk granskning av metoden 4. Resultat 4.1 Bakgrundsinformation om informanterna 4.2 Genomgång av resultaten Begränsningar och Utmaningar Kommunikation och koordinering Förutsättningar Skalbarhet Kundkontakt Samförstånd Sammanfattning 5. Analys 5.1 Begränsningar och utmaningar 5.2 Kommunikation och koordinering 5.3 Förutsättningar 5.4 Skalbarhet 5.5 Kundkontakt 5.6 Samförstånd 6. Avslutande diskussion och slutsats 6.1 Besvarande av forskningsfrågor 6.2 Slutsats 6.3 Framtida forskning 6.4 Reflektion 7. Källförteckning Bilaga 1 - Intervjufrågor 3

5 1. Inledning I detta inledande kapitel av uppsatsen ges en bakgrund till uppsatsens forskningsområde samt en problemformulering som bl. a. tar upp varför detta är intressant att undersöka. Ytterligare disposition av uppsatsen återfinns i slutet av detta kapitel. 1.1 Bakgrund Att jobba agilt har de senaste åren varit som många organisationer velat förknippas med, men som bara mindre team och utvecklingslag har lyckats med. Att arbeta agilt kan innebära många saker, t. ex. att arbeta iterativt, föränderligt och öppet. I vårt fall handlar det om agil systemutveckling, alltså processen att arbeta agilt när man utvecklar mjukvarusystem. Agil systemutveckling är i grunden några värderingar som återfinns i Manifesto for Agile Software Development från år 2001 (Agilemanifesto.org, 2017). Manifestet belyser bland annat vikten av att agera efter förändring istället för att vara låst i en planering. Det finns flera agila metoder som bygger på samma värderingar, exempelvis Scrum som är en av de mest välkända agila metoderna när det kommer till mjukvaruutveckling (Scrum presenteras mer utförligt under rubriken 2.4). Det finns även andra agila metoder som Extreme Programming och metoder med många likheter som Lean Software Development. Det som kännetecknar agil systemutveckling är således inte metoden som används, utan de agila värderingarna bakom utvecklingen. Utmaningarna som finns med agil utveckling forskade Turk et. al. (2002) på redan Ett problem som identifierades med agil systemutveckling är dess oförmåga att vara förutsägbar. Förutsägbarhet är en viktig del för de stora projekten, eftersom utvecklare, projektledare och kunder har förväntningar som måste uppfyllas. Är projektet inte förutsägbart så kommer risken att vara för hög. Slutsatsen är att det kanske inte går att använda sig av agila processer som de såg ut då, i stora projekt och organisationer som bygger stora komplexa system. 15 år senare har dessa agila processer och metoder utvecklats vidare för att kunna tillämpas även i större organisationer och projekt. Den agila metoden Scrum som tidigare nämnts har utvecklats vidare till LeSS, Large Scale Scrum. LeSS har samma fundamentala syfte som scrum, men med riktlinjer och regler som gör det mer skalbart (Larman and Vodde, 2013). LeSS är alltså en form av Scrum fast med flera Scrum-team som arbetar mot samma mål, med en gemensam produktbacklogg. Dock existerar fortfarande problematik med att gå över till LeSS. Det är en relativt ny agil metod, så det krävs mer forskning på ämnet innan flertalet stora organisationer kommer våga att gå över till LeSS. Ambitionen hos de stora bolagen och projekten finns däremot, eftersom de kan se att det finns många fördelar med att arbeta agilt, speciellt i en snabb föränderlig tid som vi lever i idag. 4

6 1.2 Problemformulering Inom ämnet informatik finns det många bra vetenskapliga artiklar som undersöker de begränsningar hos agila systemutvecklingsmetoder. Turk et. al. (2005) menar att dessa begränsningar ofta är ett resultat av de antaganden som många agila metoder baseras på. Ett exempel på detta är att kostnaderna för att rätta till misstag i ett senare skede av utvecklingen inte ökar nämnvärt jämfört med noggrann planering. Detta låter utvecklare fokusera på att iterativt förbättra systemet allt eftersom arbetet fortgår. En av fördelarna som ofta sammankopplas med detta är att de som arbetar med projektet har bättre möjligheter att hantera förändrade förväntningar och förutsättningar. Forskning i ämnet menar att fler stora organisationer ser fördelarna och väljer att undersöka en övergång till agila systemutvecklingsmetoder (Saeeda et al., 2015). Då blir även frågor som Hur kan en övergång till en agil metod genomföras? mer intressanta att svara på. Alltså behövs mer forskning kring ämnet. (Notera att i uppsatsen används transition och övergång som synonymer för att ge texten mer språklig variation.) För att kunna ge ett svar på ovanstående fråga behöver vi först förstå ett par skillnader mellan traditionella och agila systemutvecklingsmetoder. Dessa skillnader tydliggörs genom att titta närmare på några av de centrala aspekter som finns hos metoderna. En aspekt som har undersökts grundligt är huruvida den stora skalan av projekt hos stora organisationer är förenlig med agil systemutveckling, eller om agila metoder enbart fungerar på en mindre skala (Nerur, Mahapatra och Mangalaraj, 2005). Den andra aspekten är kundkontakten, som är viktig i vissa skeden av utvecklingen när det kommer till traditionella metoder. Hos agila metoder är den däremot central. Anledningen till detta är att ständig feedback från slutanvändaren är nödvändig för att iterativt förbättra produkten. Således kan man se att skalbarhet och kundkontakt är värda att undersöka vidare på grund av att de är centrala aspekter hos agil systemutveckling, men också ligger till grund för skillnader mellan agila metoder och mer traditionella metoder. Slutligen bör man också ha människors anpassningsbarhet i åtanke, då en transition från en traditionell till en agil metod onekligen kommer att medföra förändringar som inte nödvändigtvis välkomnas av alla involverade. Då skillnaderna mellan traditionell och agil metodik ofta kan vara en orsak till problem vid ett eventuellt byte av metod blir människors anpassningsbarhet och vilja eller ovilja att förändras mycket intressant för sammanhanget. 1.3 Syfte och forskningsfrågor Syftet med denna uppsats är att undersöka transitionen från en traditionell systemutvecklingsmetod till en agil systemutvecklingsmetod (även kallat ramverk) samt vilka utmaningar dessa organisationer ställs inför vid transitionen. Vidare är syftet också att undersöka hur dessa problem kan undvikas. Genom en fallstudie (med kvalitativa intervjuer) kommer vi att undersöka hur viktiga aspekter inom agil metodik som skalbarhet och kundkontakt hanteras vid en övergång från en metod där nämnda aspekter inte är lika viktiga. Frågeställningen som ligger till grund för denna undersökning är: 5

7 Hur kan en transition från en traditionell metod till en agil metod genomföras hos en stor organisation? För att besvara denna frågeställning undersöks även följande delfrågor: Vilka utmaningar ställs stora organisationer inför vid en transition från traditionell metodik till agil metodik specialiserad för systemutveckling? Hur hanterar stora organisationer aspekterna skalbarhet och kundkontakt vid transitionen? 1.4 Avgränsning Vi har valt att inte gräva för djupt ner i den tekniska delen av agil utveckling, och istället fokusera mer på de processer och metoder som är relevanta för syftet. Med agila metoder menar vi metoder som är specialiserade för utveckling av mjukvarusystem, t. ex. Scrum eller Large-Scale Scrum (LeSS). Vi har valt att begränsa dessa organisationer till företag som är inriktade på mjukvaruutveckling och/eller systemutveckling som deras primära affärsverksamhet. De ska även befinna sig inom den privata sektorn med ett vinstintresse, då vi främst är intresserade av hur agila metoder fungerar i en miljö med konkurrerande intressenter som möjligtvis använder sig av mer traditionella metoder. Slutligen har vi valt att begränsa möjliga organisationer som kan vara av intresse för undersökningen till företag som har övergått till en agil systemutvecklingsmetod eller för tillfället genomför en sådan övergång. Anledningen till detta är att undersökningen främst fokuserar på själva transitionen av metod. 1.5 Kunskapsintressenter Möjliga kunskapsintressenter är stora företag och projektgrupper som utför systemutveckling på ett traditionellt arbetssätt. Kunskapen utvecklas för att de lättare ska kunna utföra en övergång från en annan systemutvecklingsmetod till en agil sådan. Andra intressenter är bland annat konsultbolag, systemutvecklare, projektchefer och deltagare av projekt. Dessa kan vara intresserade av övergången, för att de lättare ska kunna genomföra en övergång med hjälp av den här kunskapsprodukten. 1.6 Disposition Teori I kapitel 2 kommer relevanta begrepp för uppsatsen att förklaras. Här kommer även bakomliggande teori som står till grund för uppsatsen att gås igenom för att ge läsaren en bättre helhetsbild av området undersökningen hör till och dess relevans för området. Metod I kapitel 3 beskrivs den ansats som tagits till undersökningen, vilken forskningsstrategi som använts samt hur vi gått tillväga gällande datainsamlings- och dataanalys-metodik. Här tas även det valda forskningsparadigmet med tillhörande motivering upp. 6

8 Resultat I kapitel 4 presenteras den empiriska miljön för att ge läsaren en uppfattning av företaget som undersökningen utförts hos. I kapitel 4 presenteras också resultaten av undersökningens intervjuer. En sammanställning av resultaten återfinns i slutet av detta kapitel. Analys I kapitel 5 analyseras de resultat som presenterades i föregående kapitel i förhållande till tidigare presenterad teori från kapitel 3. Slutsatser och diskussion I det avslutande kapitlet presenteras våra slutsatser baserade på analysen och en diskussion förs kring det vi kommit fram till. Här ger vi även förslag till framtida forskning. 7

9 2. Teori I teorikapitlet kommer vi att gå igenom begreppsdefinitioner och hur den agila filosofin fungerar. Vi går även igenom de två ramverken vi baserar uppsatsen på, Scrum och LeSS. Därefter kommer en beskrivning av den tidigare forskningen på området. 2.1 Begreppsdefinition Nedan följer definitioner av återkommande termer. Här beskrivs vad de har för betydelse i undersökningens kontext, hur de används i uppsatsen och en förklaring på varför de är viktiga att förstå Systemutveckling Systemutveckling i denna text kommer att användas som ett samlingsnamn för många av de delprocesser som traditionellt sett ingår i utveckling av mjukvara och tillhörande stödfunktioner. Dessa delprocesser kan exempelvis vara planering av ett projekt, utveckling och test av mjukvaran eller andra processer vars syfte är att stödja projektet, alltså själva utvecklingen av systemet. System är i det här fallet de samlade funktioner som ingår i produkten som ett projekt resulterar i (IT-ord, u.å.). Vi har valt att använda oss av begreppet agil systemutveckling över agil mjukvaruutveckling. Anledningen till detta valet är begränsningen i ordet mjukvaruutveckling. Då termen syftar enbart på utvecklingen snarare än helheten, ansåg vi att systemutveckling passade bättre, då målet med undersökningen är att få en bredare förståelse för hela processen. Agil systemutveckling kan innebära att man arbetar agilt även i andra delar än själva mjukvaran. Exempelvis vid utformningen av processer, krav och tester, men även vid projektledning och styrning Ramverk och metoder I denna text används ramverk och metoder som i stort sett synonymer, då översättningar mellan engelska och svenska ofta resulterar i att framework översätts till metod eller metodik. Ett agilt ramverk består oftast av en samling värderingar och principer som baseras på det agila manifestet (agilemanifesto.org, 2017), samt ett antal practices (praxis) vars funktion är att bidra med konkreta riktlinjer som hjälper användaren av ramverket att implementera de agila värderingarna och principerna i sin systemutveckling och därmed öka agiliteten. Dessa practices är i sig ofta verktyg eller mindre metoder med målet att öka agilitet. Vi kan alltså se här att målet att göra organisationer mer agila faciliteras genom användningen av agila ramverk, utöver målet att leverera en produkt (IT-ord, u.å.) Kundkontakt Den första principen av tolv i det agila manifestet (agilemanifesto.org, 2017) menar att den högsta prioriteten är att tillfredsställa kunden och kunden har definitivt en stor roll i den agila filosofin. Syftet med en agil organisation är, som namnet antyder, att vara lättrörlig och flexibel. Att kunna förändra sig för att svara på nya förutsättningar eller krav från omvärlden är något som är värt att eftersträva i den moderna IT-branschen. Att kunna hantera förändrade krav från kunden är särskilt viktigt. Dessa förändringar kan uppstå av en rad olika 8

10 anledningar som exempelvis att man har tolkat kundens krav fel. Det kan också vara så att kunden redan från början varit osäker på vad det egentligen är den vill ha, eller att kunden har beskrivit sina förväntningar på en lösning snarare än de egentliga behoven som lösningen ska hjälpa. Dessa problem möter agila ramverk ofta genom ett par olika lösningar. Först och främst är målet att ha ett närmare och mer kontinuerligt samarbete med kunden. Genom att skapa sig en bättre förståelse för kundens behov snarare än krav genom iterativa feedback-loopar försöker man att öka både agiliteten och kundens tillfredsställelse Skalbarhet Skalbarhet i denna uppsats används för att benämna hur många människor som är involverade. Detta gäller både så kallad out-scaling där man skalar ut till andra delar av organisationen för att öka agiliteten även hos dem, och up-scaling där man ökar antalet involverade i vad man med ett traditionellt perspektiv kallar projektet (IT-ord, u.å.) Co-located, remote team member, distributed team: Onshore och Offshore Co-location innebär inom agil systemutveckling att teamet är lokaliserat på samma fysiska plats (Rubin, 2017). Där man kan ha ansikte mot ansikte kommunikation och kollaboration. Team behöver inte nödvändigtvis vara co-located, utan vanligt är att man även har remote team members, det vill säga team medlemmar som inte är på samma fysiska plats (Rubin, 2017). Har teamet en eller fler remote team members så kallas det för ett distributed team (Rubin, 2017). Vilket är motsatsen till ett co-located team. Alltså att medlemmarna inte kan ha face to face kommunikation och kollaboration. Istället sköts mycket av kommunikationen via telefon, videosamtal och chatt. 2.2 Den agila filosofin Manifestet för agil systemutveckling togs fram 2001 av en grupp programmerare som var trötta på den dåvarande metodiken som baserades mer på verktygen, processerna och kravspecifikationerna än människorna, interaktionerna, fungerande mjukvara och kundkollaborering ( Agilemanifesto.org. 2017). Det finns tolv grundprinciper i manifestet för agil systemutveckling som hämtats från agilemanifesto.org (2017). Dessa har vi valt att översätta på följande sätt: Den högsta prioriteten är att tillfredsställa kunden med kontinuerlig leverans och värdefull mjukvara. Förändring är välkommet, även sent in i utvecklingen, vilket hjälper till att öka kundens konkurrenskraft. Leverera fungerande mjukvara ofta, med preferens för en kortare leveranscykel. Affärsfolk och utvecklare måste arbeta tillsammans dagligen på projektet. Bygg projektet efter motiverade individer, ge dem stöd och lita på att dem får jobbet gjort. Den mest effektiva metoden för att förmedla information till och inom ett utvecklingsteam är genom konversation ansikte mot ansikte mellan individerna. Fungerande programvara är det bästa måttet på framsteg. Agila processer främjar hållbar utveckling. Utvecklarna och användarna ska kunna hålla en konstant utvecklingstakt på obestämd tid. 9

11 Kontinuerlig uppmärksamhet på teknisk förträfflighet och god design ökar agiliteten. Enkelhet, förmågan att maximera jobb som inte måste göras är grundläggande. Den bästa arkitekturen, kraven och designen kommer från självorganiserade team. Med regelbundna intervall reflekterar teamet över hur man kan bli mer effektiv, sedan anpassar teamet sitt beteende därefter. Sammanfattat är detta den agila filosofin som la grunden till den stora mängden ramverk och agila metoder som finns idag. 2.3 Agil systemutveckling Agil systemutveckling är ett samlingsnamn för olika systemutvecklingsmetoder som kan användas vid mjukvaruutveckling eller andra projekt och följer den agila filosofin som har sitt ursprung i Manifestet för agil systemutveckling ( Agilemanifesto.org. 2017). En systemutvecklingsmetod är en metod som kan användas som stöd för att utföra utvecklingen av ett system. Metoden är i det här fallet ett sätt att förhålla sig för att enklare kunna utföra utvecklingsprocessen på ett bra och effektivt sätt. Följer man metoden så är tanken att utvecklingen ska gå smidigare och vara mer genomtänkt. Agil står för lättrörlig och innebär i det här fallet att man enkelt kan svara på förändring. Ett tydligt exempel är om en kund skulle vilja förändra en del av den applikation man bygger sent in i utvecklingen. Har man byggt upp applikationen agilt, så ska det inte vara några problem att förändra applikationen utefter feedback. Till skillnad från en icke-agil metod, där allting byggs efter kravspecifikationen istället och som därefter har problem att svara på förändring (IT-ord, u.å). I Essential Scrum (Rubin, 2015) förklarar Rubin följande om agil systemutveckling. Det som kännetecknar agil systemutveckling är inkrementellt och iterativt arbete, alltså att arbetet sker i mindre cyklar där stegen görs om flera gånger. Ett vanligt sätt att arbeta agilt är att bygga alla grundpelare först, och sedan iterera över varje grundpelare för att förbättra den efter feedback. Därför krävs också ofta en nära kontakt med en representant hos beställare eller kund som kan ge feedback på förändringar. Något som är viktigt att förstå är att agil systemutveckling inte är en metod i sig. Att uppnå agilitet sker genom att använda sig av agil metodik, och om det görs på rätt sätt kommer organisationen som resultat att bli mer agil. Agilitet är alltså ett mål att sträva efter, ett perspektiv som kan verka underligt för de som tidigare använt sig av traditionella metoder. Resultatet av att målet uppnås är dock tydligt. Organisationen (t. ex. en projektgrupp med flera mindre team) har lättare för att hantera plötsliga förändringar som ett resultat av den iterativa karaktären hos agila metoder. En aspekt som blir viktigare i takt med att system blir mer komplexa. Den iterativa karaktären hos agila metoder gör också att en fungerande produkt kan levereras tidigare i systemets livscykel och ger även möjlighet till kontinuerliga förbättringar av kvaliteten hos systemet (IT-ord, u.å.). För syftet av undersökningen är motsatsen till agil systemutveckling att använda en traditionell systemutvecklingsmetod, vilket ofta kopplas till vattenfallsmodellen eller traditionell projektledning. Skillnaden är att vid en agil metodik så fokuserar man på att vara lättföränderlig, och det uppnås ofta genom att decentralisera beslut och ge beslutsmandat till utvecklingsteamet över hur implementering ska ske. Traditionell metodik innebär ofta att en 10

12 stor del av tiden läggs på förberedande arbete, genom att skriva ner alla krav och lägga upp en plan för hela systemutvecklingen på förhand. Problemet är att många gånger så vet inte kunden exakt hur den vill ha systemet innan (IT-ord, u.å.). Arbetet sker sekventiellt och när ett steg i kedjan är klart går man vidare till nästa. Men med begränsningen att det inte går att återvända till föregående steg. Fördelarna med exempelvis vattenfallsmetoden är att kunden alltid vet vad den kan förvänta sig, projektet är väldokumenterat och slutligen så spelar det inte så stor roll om det är hög personalomsättning, eftersom hela projektet är väl dokumenterat och på så sätt lätt att komma in i (Base36.com, 2012). 2.4 Ramverk: Scrum och LeSS I detta avsnitt kommer vi presentera grundläggande information om ramverken scrum och LeSS Grundläggande Scrum Scrum är ett agilt ramverk som används för att utveckla system och tjänster. Ramverket börjar med en product backlog, dvs en prioriterad lista med funktioner som måste utvecklas för en lyckad produkt (Rubin, 2015). Sedan följer teamet backloggen och utvecklar den högst prioriterade funktionen. Arbetet i Scrum utförs i korta, tidsbestämda iterationer. Vanligtvis är en iteration en vecka, två veckor eller en månad (Rubin, 2015). Under varje iteration så arbetar ett team med flera olika typer av arbetsuppgifter tillsammans på en av funktionerna i backloggen, exempelvis testare och utvecklare tillsammans. Med syfte att färdigställa hela den funktionen så att den är helt klar att läggas i produktion (Rubin, 2015). Det är inte helt ovanligt att det finns fler funktioner än vad som kan genomföras under en iteration, därför arbetar man på en del av funktionerna, de högst prioriterade först. I slutet av iterationen gör teamet en redogörelse för vad som är klart och tar in feedback från intressenter i projektet, exempelvis beställaren och projektledaren. Produktägaren och teamet kan i sin tur lägga till funktioner som beställaren kommit på i efterhand (Rubin, 2015). Då läggs den nya funktionen in i produktbackloggen och produktägaren bestämmer en prioritering. Varje iteration ska potentiellt även ha en produkt som ska gå att släppa. När iterationen slutar så påbörjas planeringen av nästa iteration (Rubin, 2015) Roller inom Scrum Det finns tre huvudroller inom Scrum som måste finnas med, men det kan även förekomma fler roller vid behov (Rubin, 2015). Produktägare Ansvarar för vad som ska utvecklas och i vilken ordning. Produktägaren har huvudansvaret för ledarskap och kommunicerar klart och tydligt med alla parter vad scrumteamet försöker uppnå. Det innebär också att produktägaren har huvudansvar för att hela produkten ska lyckas. 11

13 ScrumMaster ScrumMastern är en coach för den agila utvecklingen med huvuduppgift att hjälpa alla som är involverade att förstår scrums värderingar, principer och den agila filosofin. ScrumMastern finns också för att ta teamet över hinder som förändring till en agil metod kan medföra. Utvecklingsteamet Ett team med flera olika roller inom systemutveckling. Det innefattar allt från traditionella programmerare till UI/UX designers och databasadministratörer för att nämna några roller. Det som skiljer sig från ett vanligt utvecklingsteam är alltså att i scrum blandas alla rollerna för att få ett så diversifierat team som möjligt, med olika kunskaper. Teamet arbetar även självorganiserat och väljer själva vad som är det bästa sättet att lyckas utveckla den funktion som produktägaren har valt (Rubin, 2015). Vanligtvis är dessa team begränsade till att vara mellan fem och nio personer. Behövs fler personer är det istället flera olika scrum team. (Rubin, 2015) Grundläggande LeSS, Large-Scale Scrum LeSS har många likheter med scrum och det går även att säga att LeSS är scrum, fast skalat. LeSS är ett ramverk för att kunna fortsätta använda de principer och den agila filosofin som scrum följer, även med fler team än scrum tillåter (Larman and Vodde, 2017). LeSS lägger även mycket vikt på att fungera med team som geografiskt sett ligger på olika platser. Large-Scale Scrum har två olika frameworks, LeSS och LeSS Huge (Larman and Vodde, 2017). LeSS är applicerbart när man använder mellan två och åtta team, medan LeSS Huge är när man använder fler än 8 team. Storleken är inte en satt mängd, men enligt Craig Larman finns inte många fall då större team har fungerat med den mindre varianten. LeSS och LeSS Huge delar några principer, båda har en enda produktägare och en product backlog. Alla teamen kör en gemensam sprint tillsammans och alla arbetar med en gemensam leverans (levererbar produkt ökning/shippable product increment) (Larman and Vodde, 2017). LeSS grundare Craig Larman rekommenderar inte någon att arbeta i större team eller off-shore om det går att undvika. Av den anledningen skapade han LeSS, för att det alltid finns företag som kommer vilja applicera agila systemutvecklingsmetoder på stora team (Larman and Vodde, 2017) Smaller LeSS Smaller LeSS kallar man ibland den mindre varianten av LeSS för att förtydliga skillnaden mellan LeSS och LeSS Huge. LeSS har på samma sätt som scrum bara en produktägare som äger produkten och product backlog. Teamen arbetar med en gemensam sprint och är funktionsteam, det vill säga att de är diversifierade och kan tillsammans utveckla hela funktioner till produkten (Larman and Vodde, 2017). Exempelvis finns både utvecklare, testare och UX/UI designers i teamet. Rollerna i LeSS skiljer sig inte mycket från Scrum, den enda skillnaden är att det kan finnas fler Scrum Masters. Vanligt är att ha en Scrum Master för ett till tre team. Utveckling av artefakten skiljer sig inte heller mycket från Scrum, den största skillnaden är att det finns en separat sprint backlog för varje team, utöver det så gäller samma principer som i scrum, en gemensam produkt backlog. LeSS bygger även på regler för att kunna 12

14 behålla en fungerande och gemensam grund för alla team. Det finns en enda sprint på produktnivå, inte en sprint för varje team (Larman and Vodde, 2017) Sprintplanering Sprintplanering 1, är den gemensamma sprintplaneringen där representanter från alla olika team samlas för att välja vilka olika funktioner som teamet bäst kan hantera (Larman and Vodde, 2017). Produktägaren kommer till mötet med en prioriterad lista över funktioner som ska implementeras. Frågor om funktioner kan tas upp och diskuteras. De första mötena kan vara tillsammans med alla medlemmar ur alla team. För att sedan övergå till att bara ha några få representanter från varje team, när teamen har mer vana att arbeta med LeSS. Frågor som kan komma upp och diskuteras i sprintplanering 1 är exempelvis ifall ett team tar för många högprioriterade funktioner, och om det kan skapa problem ifall teamet skulle stöta på problem under sprinten (Larman and Vodde, 2017). Det vill säga hur distribution ska skötas för att inte skapa problem under sprinten. Sprintplanering 2, nu tar representanterna från teamet med sig de valda funktionerna som teamet ska arbeta på till resterande medlemmar av teamet för att planera hur de ska arbeta under sprinten (Larman and Vodde, 2017). Ibland finns det team som måste arbeta tillsammans lite närmare på funktioner, då kan man även ha multi-team sprintplanering 2 för att sedan arbeta normalt, mot en varsin sprint backlog. Det är en viktig regel i LeSS. Vi har valt att inte dyka djupare in på sprintplanering eftersom den förmodligen skiljer sig mycket beroende på vem som koordinerar. Men Sprintplanering 2 fortsätter med flera olika möten och snabba workshops mellan teamen där alla premisser och designval görs. För multi-team möten delar man upp tiden i flera olika delar för att både ha chansen att diskutera ansvarsområden och hur arbetet ska utföras under sprinten, men samtidigt ha chansen att diskutera lite med bara det egna teamet (Larman and Vodde, 2017). När sprintplaneringen är klar går man över till utvecklingsaktiviteter. Här är det viktigt att kommunicera med kod, det vill säga att man inte koordinerar centralt utan istället tillåter att teamen själva får bestämma vad som behöver göras (Larman and Vodde, 2017). 2.5 Tidigare forskning Allt eftersom agilt har ökat i popularitet har också mer forskning genomförts kring agila utvecklingsmetoder, men ett ämne som fortfarande är relativt nytt är agila metoder även inom stora företag. Detta avsnitt presenterar tidigare forskning rörande begränsningar hos agila metoder och dess skalbarhet. Här tas även tidigare antaganden kring agila metoder i stora organisationer upp och och motbevisar även en del av dessa. Källorna presenteras med notiser om vilka teman som baserats på respektive artikel. Värt att notera är att vissa av källorna används i flera teman Nerur et. al (2005) Begränsningar och Utmaningar; Förutsättningar; I artikeln Challenges of migration to agile methodologies av (2005) av Nerur, Mahapatra och Mangalaraj behandlas några av de utmaningar som organisationer kan möta vid en övergång från traditionella systemutvecklingsmetoder till agila systemutvecklingsmetoder. 13

15 En utmaning som tas upp är de de teknologiska förutsättningarna en organisation har. Agila systemutvecklingsmetoder bygger på empirisk testdriven utveckling med snabba feedback-loopar (Rubin, 2015) och detta kräver också tekniska verktyg och hjälpmedel för att underlätta dessa processer, särskilt på en större skala. Författarna menar att organisationer som vill gå över till en agil metod måste investera i sådana tekniska hjälpmedel som stödjer och faciliterar snabb iterativ utveckling, refaktorering och versionshantering med mera. Most organizations cannot ignore the agile wave, but for those steeped in traditional systems development, adoption of agile methodologies will likely pose several challenges. - Nerur et. al., (s.74, 2005). En annan utmaning, som kan hamna i skymundan, är svårigheten gällande valet av en specifik metod eller ramverk. På grund av att många metoder är relativt nya finns det en brist på empirisk data för dessa. Därmed kan det ofta vara svårt för den ansvarige att avgöra vilken metod som bör användas och varför en viss metod passar bättre eller sämre för organisationen. Skillnader mellan metoder såsom antal team eller storleken hos team och andra skillnader gör det till en utmaning att hitta en metod som passar bra med organisationens existerande egenskaper och praxis. En ansats som organisationer kan ta för att underlätta en övergång är enligt författarna en noggrann bedömning om organisationen i fråga är redo, en bedömning som bland annat utgår från ovan nämnda utmaningar Turk et. al. (2002) Begränsningar och Utmaningar; Kommunikation och Koordinering; Kundkontakt; I artikeln Limitations of Agile Software Processes tar författarna Turk et. al. (2002) upp några av de begränsningar som finns med agila systemutvecklingsmetoder. Dessa baseras på att ett antal (inte nödvändigtvis alla) av de 11 antaganden som presenteras stämmer. Dessa antaganden berör allt från att kunden är tillgänglig för muntlig kommunikation med utvecklarlaget till att utvecklarna är kompetenta nog att definiera och anpassa deras processer så att det passar uppdraget. Många av dessa antaganden har till viss del sin grund i det agila manifestet och i förlängningen agila ramverks principer och praxis. Dessa antaganden används som sagt för att beskriva en önskbar situation där begränsningar hos agila metoder synliggörs. Den sjätte grundprincipen i det agila manifestet handlar om att den mest effektiva sättet att förmedla information mellan medlemmar i ett projekt är genom konversation ansikte mot ansikte. Detta tar Turk et. al. upp som den första begränsningen hos agila metoder, att det kräver, eller åtminstone starkt föredrar s.k. co-location, på svenska samlokalisering. Samlokalisering innebär att de involverade i ett projekt, t. ex. utvecklare, ledare och kund alla finns på samma geografiska plats för att underlätta kommunikationen (som är vitalt om snabba och oförutsedda ändringar ska kunna ske på ett effektivt och önskvärt sätt). Turk et. al. menar att detta skär sig med vissa branscher och företags vilja att vara globala i sitt arbetssätt, där vissa funktioner är outsourcade till andra länder. Även om detta kan underlättas med hjälp av telefon- och/eller videokonferenser har agila metoder trots allt begränsat stöd för s.k. distribuerade utvecklingsmiljöer. 14

16 Nästa begränsning som tas upp i artikeln är att agila metoder i lägre grad tillåter outsourcing av utvecklingsuppgifter, dels på grund av ovanstående skäl men också på grund av hur kontrakt ofta utformas, där väldigt specifika krav ställs på underleverantören. Författarna föreslår som lösning på detta ett kontrakt som utformas för att stödja agil utveckling. Kontraktet består av två delar: En s.k. Fixed Part definierar ramverket som underleverantören använder för att avgöra om en förändring ska accepteras eller nekas, vilka aktiviteter som ska utföras av underleverantören och slutligen vad som ska levereras. Den andra delen kallas Variable Part och bestämmer vilka krav och delresultat som kan variera inom Fixed Part samt hur mycket de kan variera. Senare i artikeln tas även det begränsade stödet för utveckling som involverar large teams upp. Turk et. al. menar att agila ansatser fungerar bättre hos så kallade management-in-the-small processer med mindre team. Artikeln ger dock inget stöd för varför detta skulle vara fallet. Till sist nämns också begränsningarna hos agila metoder när det kommer till att utveckla stora, mer komplexa system. Författarna menar att det kan finnas kritiska aspekter inom systemets arkitektur som är väldigt kostsamma att ändra i ett senare skede och därför borde man så mycket det går försöka förutse dessa förändringar så tidigt som möjligt. I stycket tar man särskilt upp refaktorering av kod, som enligt Turk et. al. dels inte tar bort behovet att designa för förändring men även att i sammanhanget kan kostsamma misstag lätt ske på grund av komplexiteten. Sammanfattningsvis menar författarna att det finns användningsområden för agilitet men att det ofta kan göra att processer lider om komplexiteten blir för hög och skalan blir för stor Saeeda et. al. (2015) Kommunikation och koordinering; Skalbarhet; Ytterligare en artikel som tar upp begränsningar hos det agila är Agile Scalability for Large Scale Projects: Lessons Learned av Hina Saeeda, Fahim Arif, Nasir Mehmood Minhas och Mammona Humayun (2015), som undersökt begränsningar kring skalbarheten hos agila metoder genom en litteraturstudie. Artikeln tar främst upp begränsningar relaterade till skalning av agila ramverk och metoder. Ett exempel på detta är enligt Saeeda et. al. att många av de agila verktyg som används i ramverk och självständigt inte är förenliga med storleken på större projekt. Mindre dokumentation är ett sådant exempel. Dokumentationens funktion i traditionella metoder hjälper ofta de stora antalet involverade individer att få bättre förståelse för hur långt projektet har kommit, vad som fortfarande måste göras och så vidare och hjälper därmed till att göra skalan hos projekt mer lätthanterlig. I agila sammanhang är detta ett problem då en av de agila värderingarna är Working software over comprehensive documentation (Agilemanifesto.org, 2017), alltså ska man lägga mer fokus på att få mjukvaran att fungera framför att dokumentera vad som har gjorts. Ett annat problem som tas upp är klyftan i kommunikation som kan uppstå vid outsourcing av arbetsuppgifter. Svårigheter att kommunicera är en tydlig begränsning, särskilt i agila sammanhang då det direkt minskar flexibiliteten hos de involverade. Det agila manifestet förespråkar ansikte mot ansikte-kommunikation, men när detta inte är en möjlighet lider agiliteten såvida ingen annan lösning ges. 15

17 I den avslutande delen av artikeln skriver författarna att tack vare den ökande efterfrågan på marknaden är det nödvändigt att anamma de senaste agila metoderna för projekt av en större storlek, men att i dagsläget sker det lite forskning för att motverka de problemen som en större skala medför. Avslutningsvis föreslår författarna att i framtiden behöver det finnas en modell specifik för hanteringen av problem rörande agil skalbarhet Rolland et. al. (2016) Kommunikation och koordinering; Problematizing agile in the large: alternative assumptions for large-scale agile development (Rolland et. al., 2016) tar upp några antaganden om large-scale agile development. Rolland et. al. tar upp att tidig forskning inom ämnet hade antaganden som att det agil utveckling var bäst lämpat för små projekt med co-located teams (utvecklingslag som är på samma geografiska plats) och på oviktiga projekt. Men nu har forskare börjat att ifrågasätta dessa antaganden. Ett definierat problem är att det inte finns någon överenskommelse om vad som definierar Large vid agil utveckling. Förslag som finns i annan forskning är genom att mäta mängden utvecklingsteam, mängden utvecklare, rader kod eller tid som projektet tar att göra.rapporten tar upp mängder av antaganden kring olika delar av storskalig agil utveckling, och kommer fram till att de antaganden som funnits i tidigare forskning har varit mer relevant till små istället för stora agila projekt. Det man kommer fram till är en lista med alternativa antaganden som ska vara mer relevanta till storskaliga agila projekt. Följande antaganden var extra intressanta och enligt rapporten viktiga för att lyckas med storskalig agilitet: Kunskap måste bli överförd, översatt och transformerad över gränserna. Både produktägare och team medlemmarna måste bli kunskapsmäklare och föra vidare den kunskapen man får. Stora projekt växer inte organiskt, utan skalar mer abrupt. Koordinering mellan team är viktigare än att koordinera internt inom teams. Lägg fokus på mångsidig kollaboration mellan team och roller Bass (2014) Kommunikation och koordinering; Kundkontakt; How product owner teams scale agile methods to large distributed enterprises (Bass, 2014) tar upp large scale offshore enterprise development, med fokus på produktägarens roll, där produktägaren står för att prioritera kundkraven. Istället för att produktägaren ska ta på sig massor av ansvar så beskrivs nio olika roller som man istället kan sätta på ett team av produktägare i stora projekt. Rollerna innefattar de delarna som produktägaren normalt jobbar med, men delar istället upp det i flera mindre roller som ska förenkla processen. Bland dessa finns exempelvis Groom, som har i uppgift att samla in krav från kunder. Medan Prioritiser arbetar med att prioritera kraven på ett sätt som ger mervärde. Utöver dessa roller finns 16

18 release master, technical architect, governor, communicator, traveller, intermediary och risk assessor. 2.6 Teoretiskt ramverk Detta teoretiska ramverk är baserat på den tidigare forskning som presenterats ovan. Tabellen innehåller de faktorer som den tidigare forskningen tagit upp, dessa faktorer har sedan legat till grund för utformningen av intervjufrågor. Dessa faktorer ligger även till grund för tematiseringen av kapitel 4, resultatet, och används för att jämföra resultatet av studien i kapitel 5, analysen. Faktor Beskrivning Källa Begränsningar och utmaningar Kommunikation och koordinering Förutsättningar Skalbarhet Kundkontakt Olika typer av begränsningar och utmaningar med en transition kopplade till agilitet. Beskriver hur kommunikation och koordinering bör ske inom organisationen för att lyckas under eller efter en övergång. Val av olika agila ramverk och förutsättningar som krävs för en smidig och lyckad övergång. Skalbarhet som i mängden personer som kan vara med och arbeta i ett agilt team, samtidigt som teamet kan producera önskat resultat. Vikten av kundkontakt i ett agilt projekt, vad krävs av kunden för att kunna arbeta med ett agilt team. (Nerur et. al., 2005) (Turk et. al., 2002) (Saeeda et. al., 2015) (Rolland et. al., 2016) (Bass, 2014) (Turk et. al 2002) (Nerur et. al., 2005) (Saeeda et. al., 2015) (Turk et. al., 2002) (Bass, 2014) 17

19 3. Metod Här presenteras den använda forskningsstrategin komplett med metod för datainsamling och dataanalys. Sedan presenterar vi den underliggande forskningsparadigmet som använts till studien och avslutningsvis en kritiskt granskning av metodvalet. 3.1 Forskningsstrategi Uppsatsen bygger på en förklarande fallstudie (Oates, p. 143, 2006) som ska resultera i en detaljerad analys av hur en övergång från en traditionell systemutvecklingsmetod till en agil systemutvecklingsmetod kan genomföras. Motivationen till valet av en fallstudie är främst att vi anser att sammanhanget och kontexten är väldigt viktigt för huruvida en övergång är fördelaktig och överhuvudtaget möjlig. Vi är alltså intresserade av den naturliga miljön, eftersom undersökningen ska spegla en realistisk situation där agil systemutveckling kan implementeras. Vidare anser vi även att de processer som utgör utvecklingen och relationer till omkringliggande organ inom organisationen är av värde för vårt resultat, därav passar en så kallad holistisk studie (Oates, p. 142, 2006). En kortsiktig, nutida studie passar bäst då vi är intresserade av själva transitionen från metod till metod. Målet här är alltså att vårt tillvägagångssätt i förhållande till tid är samtida i relation till transitionen hos företaget. Det företag som undersökningen skett hos är ett så kallat typiskt fall. Detta är den ideala situationen då resultatet blir mer representativt och går att applicera på en större mängd liknande företag. Föremålet för vår undersökning är ett relativt stort företag inom IT-branschen med många anställda, vilket var något vi letade efter redan vid planeringen av undersökningen. Ett typiskt fall är alltså när föremålet för studien delar många likheter med andra fall inom samma område/klass (Oates, pp , 2006).Vi kommer alltså använda oss av en s.k. typical instance, för att kunna dra en bredare slutsats innehållande information på hur en sådan här transition skulle kunna ske i liknande fall, med medföljande rekommendationer. Detta är i linje med hur Oates (pp , 2006) beskriver möjliga generalizations av fallstudier och i synnerhet implications -typen. 3.2 Val av empiri Som tidigare nämnt har vi valt att fokusera på vad vi benämner stora organisationer. Stora organisationer är definierade som en organisation med fler än 50 anställda och har en nettoomsättning på minst 80 miljoner kronor (Bolagsverket.se, 2017). Det är dock värt att nämna att det nödvändigtvis inte är alla dessa personer som är direkt involverade i ett Scrum-team eller liknande. Vi vill tydliggöra att startups och liknande mindre företag inte är föremål för undersökningen. Vi har valt att undersöka ett av de större företagen på den svenska IT-marknaden. Vi kommer inte att namnge företaget då de bett om att få vara anonyma i undersökningen. Företaget levererar huvudsakligen IT-lösningar och IT-tjänster i form av exempelvis konsultverksamhet. Vi valde företaget som föremål för denna undersökning på grund av ett par olika anledningar. Den första är att det är ett av de största IT-bolagen i Sverige, vilket gör att de både uppfyller kriterierna för vilket företag som skulle undersökas men också att de kan anses vara en så kallad typical instance, då många företag på den svenska IT-marknaden liknar undersökningens företag antingen i affärsmodell eller i vilken typ av uppdrag de tar sig 18

20 an. Den andra anledningen till att vi valde just detta företag var på grund av den skalan som de arbetar på. Med skalan menar vi storleken på projekt och team som det undersökta företaget arbetar med. Denna faktor är särskilt intressant för undersökningen då skalan dels är förenlig med forskningsfrågorna men också därför att just skalan hos till exempel ett projekt ofta tas upp som en svårighet i relation till agilitet (Turk et. al, 2002). Företaget är också i en fas där övergång till agila metoder är aktuellt och några få teams har börjat arbeta agilt. Något som bör noteras är att båda författarna är anställda av det undersökta företaget. Därför finns det en möjlighet att en vinklad syn presenteras eller att denna koppling på något sätt kunnat påverka resultatet av undersökningen. Vi anser dock att vi inte påverkar undersökningen, eftersom vi inte tidigare har träffat någon av informanterna samt att ingen av författarna heller har börjat arbeta hos företaget vid färdigställningen av denna undersökning. Det bör inte heller påverka varken intervjuerna eller urvalet av informanter, då de kriterier som utgåtts ifrån vid urvalet enbart handlar om kunskap inom undersökningens ämne. 3.3 Metodik för datainsamling Den primära datainsamlingsmetoden som används i undersökningen är intervjuer. Som ovan nämnt är den valda forskningsstrategin en fallstudie, därmed krävs djupare och mer detaljerad information av en kvalitativ karaktär. Oates (p. 186, 2006) nämner även att intervjuer är en vanligt förekommande metodik vid fallstudier. Fördelen med intervjuer är att de kan ge oss mer ingående svar på frågor som hade varit för detaljerade för t. ex. en enkätundersökning. Vi får även möjligheten att ta in information från en källa som garanterat har erfarenhet av det vi försöker undersöka tack vare urvalsprocessen innan intervjuerna. Vi har valt att fokusera på semi-strukturerade intervjuer. Anledningen till detta är att vi kan förbereda frågor att ställa, men även byta spår om ett intressant problem kommer på tal. Att skapa utrymme i intervjun för att den intervjuade själv ska kunna ta upp diskussionsämnen denne finner relevanta och/eller intressanta för intervjuns huvudsakliga tema är också något vi anser vara viktigt med tanke på undersökningens mål. Med detta menas att omständigheter som kanske inte är tydliga för utomstående fortfarande kan vara intressanta för undersökningens resultat. Ytterligare en fördel med semistrukturerade intervjuer är att vi får möjligheten att styra konversationen baserat på de observationer vi har, och kan på så sätt få mer detaljerad information på det vi eftersöker i vår uppsats. Oates (p. 188, 2006) menar att semistrukturerade och ostrukturerade intervjuer har som huvudsyfte att upptäcka och inte checka av. De används därför när man vill undersöka saker djupare. Detta anser vi stämma överens med de forskningsfrågor undersökningen ämnar besvara då det är av en upptäckande karaktär snarare än att försöka verifiera en teori. Oates (pp , 2006) förklarar att en datainsamlingsmetod som intervjuer kan få olika svar beroende på hur respondenten uppfattar intervjuaren. Tillsammans med detta finns några frågor som man bör ställa sig innan man väljer intervju som metod. Vi kan argumentera för att frågor som exempelvis Finns det någon skillnad mellan intervjuaren och respondentens sociala status eller utbildningsgrad som kan vara i vägen inte kommer att vara något problem i vårt fall. Vi har en relevant utbildning för ämnesområdet samt erfarenhet av agila utvecklingsmetoder och kan bransch-språket. Vi anser också att potentiell åldersskillnad och stil inte bör vara några problem. Åldersskillnaden är inte tillräckligt stor mellan författarna av 19

21 uppsatsen och de intervjuade för att påverka situationen mycket. Ämnesområdet är också något som förändras snabbt vilket ställer krav på att de intervjuade kan anpassa sig till nya situationer även om åldersskillnaden skulle vara stor, vilket vi anser är ytterligare en anledning till att informanterna är öppna för intervjun. Vidare anser vi också att i branschen där de intervjuade är verksamma värderas kunskap och personliga egenskaper högre än social status och klädsel, vilket också bidrar till att de intervjuade är öppna till intervjun. Det är däremot frågor som vi kommer att ha i åtanke vid datainsamlingen, för att få en ökad förståelse för respondentens perspektiv. 3.4 Intervjuer Denna del av kapitel 3 är en del av datainsamlingen men på grund av att intervjuerna spelat så stor roll i undersökningen presenteras dem under en egen rubrik. Majoriteten av datan som denna uppsats baseras på kommer nämligen ursprungligen från intervjuerna. Intervjuerna utfördes med personer som är eller har varit engagerade i en övergångsprocess från traditionella systemutvecklingsmetoder till agil systemutvecklingsmetoder. Denna del av kapitlet presenterar hur vi gick tillväga för att utforma frågorna som användes i intervjuerna, samt hur urvalet för informanter bestämdes. I 3.5 återfinns processen för analys av den insamlade datan. De frågor som användes i intervjuerna återfinns i sin helhet i bilaga Utformning av intervjufrågor Med tanke på att vi tänker använda oss av en semistrukturerad intervju-ansats är en tematiskt planering av intervjun att föredra. Alltså har ett antal ämnesområden deduktivt konstruerats utifrån undersökningens forskningsfrågor. Därefter utformas frågor baserat på vad som är intressant för det ämnesområdet. Intervjufrågorna återfinns i bilaga 1. Det allra första som gjordes i form av frågor var att ge informanten möjlighet att berätta lite om sig själv för att uppmuntra till en bra och öppen intervju. Urvalsprocessen började med att tre teman sattes upp, en för varje forskningsfråga. Därefter skapade vi många frågor av olika typer där vissa var av en mer öppen karaktär för att tillåta informanten att själv fundera och ge ett djupare svar. Andra hade istället syftet att få informanten att ge ett specifikt svar. Nästa steg i urvalsprocessen var att sålla bort de frågor som var för lika andra frågor eller som vi inte ansåg vara relevanta för forskningsfrågorna. Detta görs främst på grund av att vi har en begränsad tid att genomföra intervjuerna och fokus ligger på att få svar på forskningsfrågorna Urval av informanter För att kunna diskutera urvalet av potentiella informanter att intervjua är det viktigt att ha förståelse för en särskild faktor i urvalet. Denna faktor kallar vi lämplighet, och kan beskrivas som att de slutgiltiga informanterna uppfyller exakt de krav som utformats i de tidigare skedena av undersökningen. Att hitta kunniga personer inom rätt område som är villiga att ställa upp på en intervju kan emellertid vara svårt. Med detta i åtanke har vi valt att ha ett visst överseende i förhållande till informanterna lämplighet i förhållande till urvalskriterierna. Självklart ska informanterna uppfylla de kunskapskrav vi har så att de kan bidra med relevant data till undersökningen. Däremot har vi av praktiska skäl också värderat informantens tillgänglighet högt för att garantera att undersökningen är genomförbar. 20