EXAMENSARBETE. Varför misslyckas organisationer med agil metodtillämpning vid systemutvecklingsprojekt? Marcus Tinnsten

EXAMENSARBETE Varför misslyckas organisationer med agil metodtillämpning vid systemutvecklingsprojekt? Marcus Tinnsten Filosofie kandidatexamen Systemvetenskap Luleå tekniska universitet Institutionen för system- och rymdteknik

LULEÅ TEKNISKA UNIVERSITET Varför misslyckas organisationer med agil metodtillämpning vid systemutvecklingsprojekt? Marcus Tinnsten, martin-9@student.ltu.se 2012-05-31

Förord Denna uppsats på C-nivå omfattar 15 högskolepoäng och är det avslutande momentet i det systemvetenskapliga programmet vid Luleå Tekniska Universitet institutionen för system- och rymdteknik. Jag vill rikta ett stort och varmt tack till alla vid Logicas Östersundskontor, med ett speciellt tack riktat till mina respondenter som möjliggjorde uppsatsens datainsamling. Jag vill även tacka mina handledare vid Luleå Tekniska Universitet, Sören Samuelsson och Dan Harnesk för sitt stöd via mail och telefon under arbetets gång, i forma av råd och konstruktiv kritik. Avslutningsvis vill jag även rikta ett speciellt tack till min flickvän, Marielle Odén, som har varit mitt konstanta stöd och bollplank under arbetets gång. i

Sammanfattning Organisationer har ökat tillämpningen av agila metoder i systemutvecklingsprojekt markant under de senaste åren. Tidigare forskning visar trots det att systemutvecklingsprojekt fortsätter att misslyckas i en alarmerande takt. Syftet med uppsatsen var att identifiera de bakomliggande orsakerna till varför systemutvecklingsprojekt med agil metodtillämpning misslyckas. Undersökningen genomfördes genom att först samla in en teoretisk grund till de ämnesintressanta områdena. För att komma fram till resultatet på den frågan genomfördes en utforskande fallstudie. Datainsamlingen bestod av tre semistrukturerade intervjuer med respondenter i det valda fallet. Teorin och empirin ställdes sedan mot varandra i en analys som resulterade i uppsatsens slutsatser. Uppsatsens resultat pekar dels på det som tidigare forskare redan sett; att systemutvecklingsprojekt med tillämpning av agila metoder är känsligt för misslyckande av ett antal olika orsaker. Uppsatsens slutsatser visar att en organisation kan misslyckas med ett systemutvecklingsprojekt av ett antal skäl. Ett skäl tyder på att bristande ingångspunkter till ett systemutvecklingsprojekt har en stor påverkan under hela processen. Ett annat skäl menar att det decentraliserade ledningen av projekt som många agila metoder innehåller, inte passar alla individer och kan därför vara problematiskt att lyckas med rent praktiskt. Vidare berättar slutsatserna att det är viktigt att organisationernas ledningsgrupper till systemutvecklingsprojekten lär sig av tidigare erfarenheter och reflekterar hur ingångspunkterna kan förbättras, för att inte misslyckande ska bli återkommande. Slutsatserna pekar även på att kunden och det aktuella konkurrensläget har en betydelse för hur ingångspunkterna till ett sytemutvecklingsprojekt formas. Nyckelord: Agila metoder, Scrum, misslyckade systemutvecklingsprojekt. ii

Innehållsförteckning 1. INLEDNING... 1 1.1 BAKGRUND... 1 1.2 PROBLEMDISKUSSION... 2 1.3 FORSKNINGSFRÅGA... 3 1.4 SYFTE... 3 1.5 AVGRÄNSNING... 3 2. TEORI... 4 2.1 SYSTEMUTVECKLING... 4 2.2 AGILA METODER... 5 2.2.1 Det agila manifestet... 5 2.3 SCRUM... 6 2.3.1 Artefakter... 7 2.3.2 Teamet... 7 2.3.3 Aktiviteter... 7 2.3.4 Sammanfattning av Scrum... 9 2.4 PROJEKT OCH PROJEKTSTYRNING... 10 2.4.1 Projektledare... 11 2.5 ORGANISATIONERS LÄRANDE VID SYSTEMUTVECKLINGSPROJEKT... 11 2.5.1 Begränsningar av organisatorisk intelligens... 13 2.5.2 Hinder för lärande... 13 2.5.3 Organisatorisk design... 13 2.5.4 Utbildningsbarriärer... 13 2.6 RISKER I SYSTEMUTVECKLINGSPROJEKT... 14 2.6.1 Systemets funktionalitet... 14 2.6.2 Schema- och tidplan... 14 3.6.3 Kravhantering... 14 2.6.4 Resursanvändning och utförande... 14 2.6.5 Personalhantering... 15 2.6.6 Rekommendationer... 15 2.7 RISKHANTERINGSSTRATEGI... 15 2.8 TEORETISK SAMMANFATTNING... 17 3. METOD... 19 3.1 FORSKNINGSANSATS... 19 3.2 UTFORSKANDE FALLSTUDIE... 19 3.3 URVAL OCH EMPIRISK MILJÖ... 20 3.4 KVALITATIV OCH KVANTITATIV UNDERSÖKNING... 21 3.5 DATAINSAMLING... 21 3.5.1 Intervjuer... 21 3.6 BEARBETNING AV INSAMLAD DATA... 22 3.7 VALIDITET OCH RELIABILITET... 23 3.7.1 Validitet... 23 3.7.2 Reliabilitet... 24 4. EMPIRI... 26 4.1 PRESENTATION AV EMPIRISK MILJÖ... 26 iii

4.2 AGILA METODER I SYSTEMUTVECKLINGSPROJEKT... 27 4.3 PROJEKTLEDNING OCH PROJEKTSTYRNING... 28 4.4 ORGANISATIONENS LÄRANDE VID SYSTEMUTVECKLINGSPROJEKT... 29 4.5 RISKER VID SYSTEMUTVECKLINGSPROJEKT... 30 5. ANALYS... 33 5.1 AGILA METODER I SYSTEMUTVECKLINGSPROJEKT... 33 5.2 ORGANISATIONERS LÄRANDE VID SYSTEMUTVECKLINGSPROJEKT... 35 5.3 RISKER I SYSTEMUTVECKLINGSPROJEKT... 36 6. SLUTSATSER OCH DISKUSSION... 39 6.1 SLUTSATSER... 39 6.2 DISKUSSION... 40 6.3 FÖRSLAG TILL FORTSATT FORSKNING... 41 7. REFERENSER... 42 7.1 LITTERÄRA KÄLLOR... 42 7.2 ELEKTRONISKA KÄLLOR... 43 BILAGA 1.... A.1 BILAGA 2.... B.1 Figurförteckning FIGUR 1. LIVSCYKELMODELLEN (ANDERSEN, 1994:48).... 4 FIGUR 2. ILLUSTRATION ÖVER SCRUM PROCESSEN (BJÖRKHOLM & BRATTBERG, 2010:74).... 9 FIGUR 3. KOPPLINGEN MELLAN UTVECKLINGSMODELL OCH PROJEKTSTYRNING (ANDERSEN, 1994:113).. 10 FIGUR 4. MODELL ÖVER FELAKTIGT LÄRANDE I SYSTEMUTVECKLING (LYYTINEN & ROBEY, 1999:91).... 12 FIGUR 5. PROJEKTLEDARENS PERSPEKTIV PÅ EXTERNA OCH INTERNA RISKER (CULE ET AL. 2000:67).... 16 FIGUR 6. FIGUREN VISAR HUR UPPSATSENS TEORI LADES MOT EMPIRIN I EN ANALYS.... 23 iv

1. Inledning Uppsatsens inledande kapitel. Här kommer ämnet och problemets bakgrund att beskrivas. En kort bakgrund kommer att presenteras för att ge läsaren en bättre helhetsbild om ämnet. Kapitlet avslutas med beskrivning om uppsatsens syfte och frågeställningar, samt hur, vart och vilka perspektiv som uppsatsen avgränsar sig till. 1.1 Bakgrund När en organisation arbetar med systemutveckling krävs det i de flesta fallen att någon slags metod tillämpas. En metod innebär en effektivare systemutvecklingsprocess och det leder i sin tur en effektivare verksamhet. Förr var det traditionella metoder, exempelvis vattenfallsmodellen, som stod som ett av de mest centrala valen. Vattenfallsmodellen kan sammanfattas som ett sekventiellt sätt att bedriva systemutveckling. Grundtanken med modellen är att varje segment i utvecklingen (kravinsamling, design, implementering osv.) ska vara klart innan utvecklingen fortsätter till nästa steg. Vattenfallsmodellen har använts flitigt inom systemutvecklingsprojekt sedan 1970-talet. (Larman, 2004) Teoretiskt sätt är de flesta traditionella metoderna fantastiska, men de har visat sig svåra att fungera rent praktiskt (Cohn, 2010). Andersen (1994) beskriver att systemutveckling nästan alltid bedrivs i projektform. Vi lever i en tid då affärsklimatet ständigt förändras och komplexiteten ökar, vilket i sin tur sätter hårdare press på organisationerna - stora som små. Kraven som ställs på organisationer som vill fortsätta med sin verksamhet i ett konkurrenskraftigt syfte är att kunna svara snabbt på förändringar. (Turban, et al. 2007) Den gemensamma uppfattningen om traditionella metoder är att de kräver för mycket planeringsarbete, är för sekventiella och lägger för mycket fokus på omfattande dokumentering - aspekter som inte kan ge svar på snabba förändringsbehov (Cronholm, 2008). Av de skälen strävar i dagsläget många organisationer mot att bli mer flexibla, mer agila (Cohn, 2010). Vad innebär det för en organisation att tillämpa agila metoder i systemutvecklingsprojekt? Mike Cohn (2010) beskriver att organisationer som arbetar efter agila metoder ofta resulterar i produkter med en högre kvalitet, mer tidsenligt och med lägre kostnader än vad ett projekt som följer mer traditionella metoder uppnår. Agila metoder lägger en stor tyngd på enkelhet och individer och interaktion före processer och verktyg (Beck et al. 2001). Förutsättningarna för att lyckas med tillämpning av agila metoder i systemutvecklingsprojekt kräver en stor flexibilitet hos organisationen, som gör det möjligt att svara snabbt på förändringar som kan uppkomma. Det innebär att organisationens lärande och styrning av projekt får en viktig roll. Agila metoder lägger en stor tyngd på iterationer och inkrementellt utvecklingsarbete, där varje iteration ger förutsättningarna att kunna redovisa fungerande mjukvara, istället för redovisning 1

med omfattande dokumentation. (Fowler & Highsmith, 2001) Punkterna ovan kan ses som de grundläggande kraven för att agila metoder ska fungera rent praktiskt i systemutvecklingsprojekt. Övergången till agila metoder i systemutvecklingsprojekt är ofta en svårare process än organisationer inledningsvis har räknat med. Inför användningen av agila metoder i systemutvecklingsprojekt krävs vissa, större eller mindre, förändringar hos organisationen. En vanlig orsak varför organisationer misslyckas med övergången till agila metoder är bedömningen att endast projektgruppen kommer att beröras av förändringar. (Cohn, 2010) Förändringarna rör inte bara utvecklarna, utan nästan alla led i organisationen. En innebörd med agilt tankesätt är att de olika rollerna i utvecklingsgruppen får mer ansvar, vilket innebär att förändringen blir stor då ansvar och befogenheter ökas längre ned i leden hos organisationen. (Brattberg & Björkholm 2010). Utöver att genomföra de praktiska förändringarna, menar Cohn (2010) att en annan stor utmaning är att förändra och anpassa tankesättet omkring agila metoder i systemutvecklingsgrupper. 1.2 Problemdiskussion Enligt Mike Cohn (2010) har organisationer ökat tillämpningen av agila metoder i systemutvecklingsprojekt markant under de senaste åren. Det internationella IT forskning- och konsultbolaget The Standish Group gjorde 1994 en undersökning som visade på att hela 85 % av alla mjukvaruprojekt misslyckades. The Standish Group (2009) rapporterar nära tio år senare att 32 % av alla undersökta projekt har blivit avslutade som lyckade, medan 24 % av projekten avbröts eller misslyckades. Resterande 44 % av samtliga undersökta projekt överskred tidsramar, budgetering och/eller levererade inte alla krav och funktioner som angivits i specifikationerna. Siffrorna visar på en förbättring, men är i sin helhet fortfarande usla. Författarna till dessa rapporter redovisar att många åtgärder som används för att tillämpa bästa praxis vid projektledning inte ökar andelen av projekt som lyckas. Projectplace (2009) definition av ett misslyckat systemutvecklingsprojekt är när de uppsatta tid- och kostnadsramarna för projektet har blivit spräckta, slutproduktens kvalitet är bristande, eller om produktens omfattning skiljer sig från vad som har lovats. Om projektet har misslyckats eller inte handlar sedan om hur kunden upplever det. Om kunden är nöjd med resultatet, även då budgetering och utsatta ramar har blivit spräckta, bör systemutvecklingsprojektet klassas som ett lyckat projekt. Organisationer har inte samma problem idag som för 20 år sedan, men trots mer flexibla tillvägagångssätt fortsätter systemutvecklingsprojekt att misslyckas i en alarmerande takt. Lyytinen och Robey (1999) drar slutsatserna att vidareutvecklad teknologi inte är det väsentliga för att öka andelen lyckade systemutvecklingsprojekt. De menar att systemutvecklingsprojekt är känsliga för misslyckanden för att organisationer inte lyckas lära sig från sina egna erfarenheter. Det är dock högst tveksamt att den enskilda individens handlande eller svagheter som är orsaken till att så många systemutvecklingsprojekt misslyckas. 2

Det är sällan att ett IT-projekt misslyckas på grund av en eller två orsaker. De flesta felen är en kombination mellan tekniska problem, metodanvändning, projekthantering eller projektstyrning. Komplexiteten av samspelet mellan de olika dimensionerna föder ett antal risker som kan leda till problem och i värsta fall att projektet misslyckas. (Charette, 2005). Enligt Andersen (1994) måste metoden som väljs vid systemutvecklingsprojekt vara anpassad efter organisationens behov, det innebär att organisationen måste ha tillgång till de resurser (tid, pengar, bemanning) som metodvalet kräver för att ett systemutvecklingsprojekt ska bli lyckat. Lyytinen och Ropponen (2000) beskriver att ett systemutvecklingsprojekt är utsatt för många risker under processen, där varje risk kan innebära en orsak till att organisationer misslyckas med systemutvecklingsprojekt. Enligt Cule, Schmidt, Lyytinen, och Keil (2000) måste riskerna identifieras för att de ska kunna åtgärdas, något som kanske organisationer inte alltid lyckas med. 1.3 Forskningsfråga Varför misslyckas organisationer med agil metodtillämpning vid systemutvecklingsprojekt? 1.4 Syfte Uppsatsens syfte är att identifiera vad som är orsakerna till att systemutvecklingsprojekt med agil metodtillämpning misslyckas. 1.5 Avgränsning Det finns näst intill oändligt med faktorer som kan ha en påverkan som gör att organisationer misslyckas med systemutvecklingsprojekt med agil metodtillämpning. Därför har uppsatsen avgränsat sig till att undersöka perspektiven som handlar om organisationens misslyckande till lärande, agila metoder i systemutvecklingsprojekt, projektledning och projektstyrning (på operativ nivå och organisatorisk nivå), samt vilka generella risker som finns med systemutvecklingsprojekt. Avgränsningar har skett till att inte beröra kundens perspektiv i detalj, angående dess delaktighet till varför systemutvecklingsprojekt med agil metodtillämpning misslyckas. 3

2. Teori I teorikapitlet kommer teorin som jag har valt utifrån mina valda perspektiv att presenteras. Det innefattar teori om organisationers lärande vid systemutvecklingsprojekt, agila metoder, Scrum, projektstyrning och projektledning, systemutveckling, samt generella risker vid Systemutvecklingsprojekt. 2.1 Systemutveckling Systemutveckling är själva utvecklingsarbetet av ett informationssystem. Det är ett omfattande arbete som kräver att inblandade aktörer behärskar metoder, beskrivningstekniker och de verktyg som krävs för att utföra uppgiften. Det är viktigt att kännedom och förståelse finns i den miljö där systemutvecklingen ska äga rum. Systemutvecklingsprocessen bedrivs ofta som ett projekt med hjälp av någon slags metod. Vilka metoder och verktyg som används vid systemutvecklingsarbetet beror mycket på vad för slags informationssystem som ska utvecklas, verksamhetens syn på utvecklingsarbetet samt användarnas och systemutvecklarnas erfarenheter. (Andersen, 1994) En utvecklingsmodell kallas ibland för ett ramverk, och beskriver i sin helhet vilket arbete som måste utföras och vem som bör utföra arbetet. Andersen (1994) beskriver att en utvecklingsmodell kan innehålla arbetsuppgifter som sträcker sig från start till slut; från idé, till ett färdigt och implementerat system. Ett typiskt exempel att titta på utvecklingen av ett informationssystem är med den traditionella livscykelmodellen. Livscykelmodellen visar hela informationssystemets livslopp, där faserna analys till implementering är själva systemutvecklingen (se figur 1). Figur 1. Livscykelmodellen (Andersen, 1994:48). Ett sätt att bedriva systemutvecklingsprojekt är genom användning av vattenfallsmodellen. I vattenfallsmodellens livscykel strävar man efter att definiera alla, eller näst intill alla, krav innan programmeringsfasen startar. Man strävar också att ha en genomgående design innan programmeringsfasen. I sin helhet handlar vattenfallsmodellen om att alla föregående steg ska vara klara innan processen går vidare till nästa steg, något som Larman (2004) beskriver var framtaget genom spekulationer och rykten, istället för evidensbaserade utövande. 4

2.2 Agila metoder Kärnmeningen med användning av agila metoder vid systemutvecklingsprojekt innebär att man tar bort de tunga momenten som vanligtvis förknippas med traditionella metoder, för att snabbt kunna anpassa sig till den ständigt förändrande affärsmiljön. Agila metoder karaktäriseras av dess flexibla och rörliga tankesätt som möjliggör förändringar. Att bedriva systemutvecklingsprojekt med agila metoder möjliggör anpassning till förändrande deadlines och krav med mera (även sent i processen), något som, enligt Erickson, Lyytinen och Siau (2005), inte traditionella metoder har de egenskaper eller möjligheter till att kunna genomföra. Både traditionella och agila metoder består av rekommendationer om vad som bör göras och hur det bör utföras. Det som skiljer agila metoder från traditionella metoder är att traditionella metoder styr systemutvecklingsprojekten på ett strikt detaljerat sätt, medan agila metoder är flexibla och anpassningsbara efter situation. (Cronholm, 2008). Cronholm (2008) beskriver att de förväntade effekterna av agila metoder i systemutvecklingsprojekt är: rationalitet, struktur, lagarbete, anpassningsmöjligheter, minskad dokumentation, tillåtande av förändringar, enkelhet, kreativitet och improvisation. 2.2.1 Det agila manifestet År 2001 samlades en grupp människor med ett gemensamt intresse för iterativa och agila metoder för att hitta en gemensam grund. Mötet resulterade i att den agila alliansen formades och ett manifest över de centrala budskap, sammanställningar och principer som agila metoder förkroppsligar. Nedan följer en sammanställning över de punkter som agila metoder värdesätter. Det finns mycket värde i punkterna till höger, men punkterna till vänster i fet stil värdesätts mer av utövare av agila metoder. (Fowler & Highsmith, 2001) 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 Nedan följer de tolv principer bakom det agila manifestet som utövare av agila metoder strävar efter att följa (Beck et al. 2001). 1. Högsta prioritet är att tillfredsställa kunden, från ett tidigt stadie i processen till slutprodukten; genom en kontinuerlig leverans av fungerande programvara. 2. Välkomna förändrande krav, även sent under utvecklingen. Agila metoder utnyttjar förändring till kundens konkurrensfördel. 3. Leverera fungerande programvara ofta, med ett par veckors till ett par månaders mellanrum, ju oftare desto bättre. 5

4. Verksamhetskunniga och utvecklare måste arbeta tillsammans dagligen under hela projektet. 5. Bedriv projekt med motiverade individer, ge dem möjligheter till den miljö och det stöd de behöver, och lita på att de får jobbet gjort. 6. Nära kommunikation, ansikte mot ansikte, är det bästa och effektivaste sättet att förmedla information, både till och inom utvecklingsteamet. 7. Fungerande programvara är främsta måttet på framsteg. 8. Agila metoder verkar för uthållighet. Intressenter, utvecklare och användare skall kunna hålla jämn utvecklingstakt under obegränsad tid. 9. Kontinuerlig uppmärksamhet på förstaklassig teknik och bra design stärker anpassningsförmågan. 10. Enkelhet - konsten att maximera mängden arbete som inte görs - är grundläggande. 11. Den bästa arkitekturen, kraven och designen växer fram med självorganiserade teams. 12. Med jämna mellanrum ska utvecklingsteamet reflektera över hur de kan bli effektivare, och arbetar sedan för att uppnå detta. 2.3 Scrum Schwaber och Sutherland (2011) beskriver att den agila metoden Scrum har sitt fokus på projektstyrning. Metoden är inget verktyg som tillgodoser svar till hur man producerar mjukvara med hög kvalitet under ett högt tempo. Däremot är det ett verktyg, ett ramverk, som används för att ta reda på vad som behöver göras för att snabbare kunna producera mjukvara med hög kvalitet. Scrum är en metod som kan användas för att adressera komplexa problem och leverera produkter med bästa möjliga resultat. Författarna beskriver vidare att metoden är lättviktig, enkel att förstå - men svår att bemästra. Arbetssättet i Scrum består av självorganiserade, tvärfunktionella teams bestående av individer med olika kompetenser som jobbar tillsammans mot ett uppsatt mål (Björkholm & Brattberg, 2010). Individerna som ingår i de självorganiserade teamen ansvarar själva för att arbetet ska bli utfört, ansvaret som i ett traditionellt projekt ligger hos projektledaren (Schwaber & Sutherland, 2011). Figur 2 illustrerar de moment som ingår i Scrum, och som kommer att beskrivas följande. Användning av Scrum kan under vissa omständigheter vara mindre lämpligt, ett sådant fall kan innefatta organisationer eller avdelningar som har svårt att uppskatta hur mycket arbete som kan utföras under en sprint (iteration) (Björkholm & Brattberg, 2010). 6

2.3.1 Artefakter En av Scrums artefakter är produktens backlog. Produktens backlog är en ordnad lista över allt som behövs för produkten, och är den enda källan till uppsättning av krav som förändringar av produkten kommer utgå ifrån. Produkt backloggen är dynamisk och förändras allt eftersom produkten som utvecklas och miljön förändras. Dessa förändringar sker kontinuerligt under processen för att identifiera vad produkten behöver för att vara lämplig och konkurrenskraftig (Schwaber & Sutherland, 2011). Metoden Scrum innehåller en artefakt med namnet burndown chart. Artefakten är ett diagram som mäter antal dagar samt antal gjorda processer. Varje dag prickar man in en punkt i diagrammet över hur mycket arbete som är kvar. Diagrammet ger en tydlig översikt över hur mycket arbete som är gjort och om processen löper på efter plan. Alla intressenter av projektet kan titta på diagrammet för att få en överblick hur arbetet fortskrider. (Björkholm & Brattberg, 2010) 2.3.2 Teamet Enligt Schwaber och Sutherland (2011) är storleken på den optimala utvecklingsgruppen liten nog för att behålla sin rörlighet och stor nog för at utföra något signifikant arbete. I ett Scrum team ingår utöver utvecklingsgruppen kravarbetare och en testgrupp. Det finns inte traditionella projektledare i agila projekt (Tonnquist, 2012). En Scrum Master har ansvaret att se till att allt flyter på som det ska med Scrum processen. Det innebär att försäkra att Scrum teamet förstår Scrum teoretiskt och praktiskt, samt dess regler (Schwabber & Sutherland, 2011). Scrum Mastern har rollen som coach, ordningsvakt och vaktmästare, med sin främsta uppgift att se till att Scrum teamet kan arbeta ostört och strukturerat (Björkholm & Brattberg, 2010). Eftersom Scrum handlar mycket om att projekt bedrivs och leds av hela teamet så är Scrum Masterns roll som ledare att coacha teamet, vilket skiljer sig från den traditionella projektledarens uppgifter (Tonnquist, 2012). Det ansvar som produktägaren har är att se till att utvecklingsgruppen producerar resultat med så mycket kundvärde som är möjligt. Tillvägagångssättet till detta kan variera från organisationer, Scrum team och individer. (Schwaber & Sutherland, 2011) 2.3.3 Aktiviteter De dagliga mötena (daily scrum) är en viktig beståndsdel i metoden Scrum. De mötena varar vanligtvis i omkring 15 minuter. Mötena används som reflektionstillfällen över vad som gjort sedan föregående möte, vad som har varit problematiskt, samt vad som ska göras till nästkommande möte. När det dagliga mötet är över uppdateras burndown charten med en punkt. Mötet Scrum of 7

Scrums är ett möte där de olika Scrum Masters träffas och diskuterar i omkring en kvart över hur projektprocessen fortlöper. (Björkholm & Brattberg, 2010). Författarna beskriver att grupper och teams som använder sig av metoden Scrum bedriver sitt arbete under iterationer, så kallade sprintar. Det finns en varietet av olika sprintar; dagliga sprintar, planeringssprintar, utvecklingssprintar, genomgång av sprintar och återblickssprintar (retrospektiv). Längderna på sprintarna skiljer sig, en viss sprint kan exempelvis sträcka sig över två veckor, medan en annan typ (exempelvis den dagliga sprinten) sträcker sig över 24 timmar. Schwaber och Sutherland (2011) beskriver att sprintarna är själva hjärtat av metoden. Varje ny sprint påbörjas så fort den föregående sprinten är avklarad. En sprint innehåller alla delar som ska göras i projektet; kravarbete, utveckling och test. Efter varje övergripande sprint (som vanligtvis sträcker sig mellan 2-4 veckor) ska teamet vara beredd att ge kunden en demonstration med fungerande programvara. I slutet på varje sprint äger Scrums retrospektiv, återblick, rum. Teamet och produktägaren träffas under ett möte där det gjorda arbetet diskuteras, vad som har fungerat bra och vad som kan förbättras till nästa sprint för att bli effektivare. Mötet resulterar i en lista som innehåller de punkter som behöver eventuella åtgärder eller förbättringar. Scrum Masterns uppgift här är att se till att punkterna blir avbetade. (Björkholm & Brattberg, 2010) 8

2.3.4 Sammanfattning av Scrum Figur 2. Illustration över Scrum processen (Björkholm & Brattberg, 2010:74). Sammanfattningsvis innehåller Scrum fem punkter (Kniberg & Skarin, 2010): 1. Fördelning av projektet i mindre grupper (självorganiserade teams). 2. Fördelning av arbetet till mindre konkreta objekt (som sorteras efter prioriteringsnivå) och estimera varje objekts omfattning. 3. Fördelning av tiden till anpassade sprintar (vanligtvis mellan 1-4 veckor) som ger potential att demonstrera färdiga objekt/kod efter varje sprint (iteration). 4. Optimering av plan av release och uppdatering av prioriteringar i kollaboration med kunden, baserat på den insikt som getts efter varje iteration. 5. Optimering av processer genom att ha ett retrospektiv (återblick) efter varje sprint. 9

2.4 Projekt och Projektstyrning Ett projekt karaktäriseras av strävan att nå upp till ett visst resultat inom en bestämd kostnad- och tidsram. Projektarbetsformen används ofta när en organisation står inför en ny engångsuppgift som kräver medverkan av individer med olika kompetens och expertis i verksamheten. (Andersen, 1994) Alan MacCormack (2001) beskriver att ett lyckat systemutvecklingsprojekt karaktäriseras av möjligheterna till en tidig release av den evalverande produkten till kund, daglig uppdatering av ny kod och nya funktioner som varvas med feedback från kund, utvecklingsteam med god erfarenhet av rätt beslutsfattande och erfarenheter, samt omfattande arbete av produktens design och arkitektur. Projectplace (2009) har en liknande definition av ett lyckat systemutvecklingsprojekt. De faktorerna som samspelar i den definitionen är en god projektplanering, rätt verktyg och metod, samt projektstyrning, ledning och uppföljning av projektets utförande. Eftersom systemutveckling ofta organiseras som projekt så är projektstyrning ett hjälpmedel till att bedriva processen. Projektstyrning har sitt fokus i definiering av projektets ramar och upplägg. Andersen (1994) beskriver att placering av projektstyrningen kan vara problematisk; ska projektstyrningen ligga i utvecklingsmodellen eller ska man hålla projektstyrningen utanför utvecklingsmodellen och låta användarna av modellen bestämma vilken projektstyrning som skulle passa bäst, är inte alltid ett lätt val. Andersen tillägger att det enklast att kombinera systemutvecklingen och projektstyrningen om mest kritiska händelserna i utvecklingsmodellen har syftet som kontrollpunkter för projektstyrningen. Figur 3 illustrerar projektstyrning med kontrollpunkter i den traditionella livscykelmodellen. En relativt enkel koppling mellan systemutveckling och projektstyrning är en kontroll som kan användas för att se om systemutvecklingsprojektet fortlöper enligt plan är om resultaten föreligger de avtalade datumen. Utöver användningen av tid som en kontrollpunkt i projektstyrningen är resursåtgången, kostnaderna, en traditionell kontrollpunkt i projektstyrning. Figur 3. Kopplingen mellan utvecklingsmodell och projektstyrning (Andersen, 1994:113). 10

2.4.1 Projektledare Den mest övergripande uppgiften hos en projektledare är att leda projektgruppen på ett sätt som levererar resultat till projektägaren. Uppdraget en projektledare har innebär att styra ett projekt på ett sådant sätt att det är möjligt att leverera resultat efter de uppsatta kostnads- och tidsramarna. Det är viktigt att en projektledare behärskar grundläggande ledningsuppgifter. Enligt Tonnquist (2012) så måste en projektledare ha ett genuint intresse för människor, veta vad som motiverar dem och ha en förmåga att kommunicera så att alla känner sig sedda och hörda, för att bli en framgångsrik projektledare. En traditionell projektledning innebär att all kontroll ligger hos projektledaren, som är i centrum av projektet. Den traditionella projektledarens arbetsuppgifter är att samla in, analysera och distribuera information vertikalt i projektet. Tonnquist (2012) beskriver att uppgiften kan försvåras då all information är koncentrerad hos en person i projektet. Därför har mer decentraliserade tillvägagångssätt utvecklats som gör det möjligt för alla parter i teamet att bli mer involverade och få större möjlighet att bidra. 2.5 Organisationers lärande vid systemutvecklingsprojekt Efter många misslyckade systemutvecklingsprojekt har också många lösningsalternativt genererats för att förbättra organisationers utövande av systemutvecklingsprojekt. Några av dessa möjligheter innefattar riskhanteringstekniker, användare medverkan, verktyg för representation av systemabstraktion och specifika rekommendationer för organisationen och hantering av systemutvecklingsprojekt. Många systemutvecklingsorganisationer är motvilliga eller otillgängliga att anpassa sitt utövande av systemutveckling, även när de inte lyckas att producera ett förväntat, eller önskat, resultat. En av slutsatserna som kan dras utifrån detta är att avancerade utvecklingsverktyg och metodologier inte ensamt kan bidra till inlärningen av detta utövande, utan att organisationer måste lära sig från tidigare erfarenheter, något som många organisationer misslyckas med. (Lyytinen & Robey, 1999) Hur kommer det sig att organisationer inte lyckas lära sig från sina tidigare erfarenheter? Figur 4 visar en översiktlig bild för att svara på den frågan. Bilden visar sambanden mellan misslyckande att lära sig från erfarenheter och inlärande av misslyckande. Att en organisation misslyckas med att lära sig leder till återkommande misslyckanden, och som i sin tur blir sedd som den normala situationen på ett långsiktigt perspektiv. Användandet av ogiltiga teorier leder således till att misslyckande fortsätter att bli inlärt i organisationen, eftersom relevant information från tidigare erfarenheter filtreras ut eller omtolkas. 11

Figur 4. Modell över felaktigt lärande i systemutveckling (Lyytinen & Robey, 1999:91). På ett långsiktigt perspektiv blir organisationer förblindad av återkommande misslyckande av nytt inlärande, som gör att organisationer inte ser alternativ och undersöker dess lämplighet. Detta orsakar, enligt Lyytinen och Robey (1999), att rutiner som innefattar standardmetoder hos organisationen blir kvarvarande som myter i användning (s. 94), trots att de är olämpliga. Vidare beskriver de att organisationer lär sig att leva med bristande utförande och ett synsätt som pekar på att negativa resultat uppkommer från externa orsaker istället för att titta på den interna process som organisationen bedriver. Figur 4 visar sambandet av misslyckande med inlärning som i sin tur leder till att dessa olämpliga metoder blir kvarvarande i systemutvecklingen, och sedan hur detta leder till att olämpliga (och felaktiga) metoder och teorier fortsätter bli inlärt i organisationen. Ofta ser organisationer för defensivt på de standardmetoder som används inom systemutvecklingen, istället för att försöka förnya och förbättra metodanvändandet. Det leder till att organisationer behåller sina myter och fortsätter att bedriva systemutvecklingsprojekt som de alltid gjort. Med andra ord, organisationen har då lärt sig att misslyckas. (Lyytinen & Robey, 1999) Lyytinen och Robey (1999) har identifierat fyra barriärer som de anser är orsakerna till varför inte organisationer inte lär sig av tidigare erfarenheter och fortsätter att misslyckas med systemutvecklingsprojekt. Dessa barriärer är: 1. begränsningar av organisatorisk intelligens (limits on organizational intelligence), 2. hinder för lärande (disincentives for learning), 3. organisatorisk design (organizational design), 4. utbildningsbarriärer (educational barriers). 12

2.5.1 Begränsningar av organisatorisk intelligens Enligt Lyytinen och Robey (1999) är organisationers förmåga att lära begränsad av fyra specifika orsaker. Den första orsaken är att organisationer blir överbelastade med mängder av information som gör det svårt att hantera och forma kunskap. Det mest typiska skälet till varför den här problematiken uppstår är att systemutvecklingsorganisationer kontinuerligt arbetar med uppgifter, som gör det svårt att hinna reflektera över redan befintlig information. Den andra orsaken till begränsad förmåga av inlärning är att många organisationer med hög omsättning gör dem blinda mot nya relevanta erfarenheter och kunskap. Den tredje orsaken är att aktörer följer tidigare organisatoriska upplägg och relaterade tankebanor, istället för att testa nya arrangemang. Den fjärde orsaken är att teorier som används ofta saknar vetenskaplig validitet av skäl som att experimentella kontroller saknas, åtgärder är näst in till obefintliga eller för att analyser saknar grund. Den problematiken leder till att aktörer drar felaktiga slutsatser från sina erfarenheter i systemutvecklingsprojekt. 2.5.2 Hinder för lärande Den andra identifierade orsaken varför organisationer inte lär sig av sina tidigare erfarenheter och fortsätter misslyckas är hinder för lärande. Det är mycket vanligt att de möjligheter till nytt lärande inom systemutveckling som finns tillgängliga till organisationer missas, på grund av besatthet av framgång. Ofta förtränger organisationer misslyckade systemutvecklingsprojekt, av rädsla att de ska upprepas igen, och det resulterar i sin tur att värdefull information (som används vid internt lärande) ignoreras. (Lyytinen & Robey, 1999) 2.5.3 Organisatorisk design Enligt Lyytinen och Robey (1999) kan den organisatoriska designen vara utformad på ett sätt som hindrar lärande. Organisationens institutionsgränser kan begränsa åtkomsten till värdefull information och påverka ansatsen till att ändra teorier och metoder som används vid systemutvecklingprojekt. Det är lätt att organisationer blir kvar i åldrade upplägg där metoder som används inte passar organisationens behov, eller är rent ut av omoderna. 2.5.4 Utbildningsbarriärer Traditionella systemutvecklingsmetoder innebär ofta att giltigheten av en teknisk lösning som tillgodoser alla önskemål som givits, måste ha alla kraven färdigställda innan själva utvecklingsfasen börjar. Med det antagandet går ofta inlärandet till miste, då den djupt rotade vikten av funktionaliteten blockerar ut andra viktiga moment. Exempel på ett sådant moment är lärande som tillgodoser en mer reflekterande analys. (Lyytinen & Robey, 1999) 13

2.6 Risker i systemutvecklingsprojekt Definitionen av en risk är en egenskap eller ett tillstånd av ett utvecklingsarbete eller utvecklingsmiljö som ökar sannolikheten att ett projekt kommer att misslyckas om ignoreras. Lyytinen och Ropponen (2000) har identifierat följande riskkomponenter i systemutvecklingsprojekt: risker i systemets funktionalitet schema- och tidsrisker risker vid kravhantering risker med resursanvändning och utförande risker vid personalhantering 2.6.1 Systemets funktionalitet Den första komponenten summerar de risker som är associerad med att få till systemets önskade funktionaliteter, både utifrån ett användarperspektiv och utifrån ett tekniskt perspektiv (användarvänlighetsgraden av gränssnittet, de huvudsakliga funktionerna, hård- och mjukvara kapaciteten). (Lyytinen & Ropponen, 2000) 2.6.2 Schema- och tidplan Den andra faktorn har fått sitt namn efter de svårigheter som finns med att schemalägga ett projekt. Risken innefattar problem och ändringar i tidplanen och estimerade kostnader mot faktiska kostnader. Övriga problem som relaterar till risken (som exempelvis fel hantering av projektets komplexitet, estimering av personalens behov och uppskattning av storlekt) är konsekvenser som följer efter problem med schema och tidplan. (Lyytinen & Ropponen, 2000) 3.6.3 Kravhantering Risken behandlar projektgruppens kompetens och kapacitet att kunna hantera ändringar av krav. Denna risk har en nära koppling till den föregående risken. Kontinuerliga och okontrollerade ändringar i kraven leder till ändringar i den uppsatta tidplanen, vilket i sin tur kan leda till svårigheter med projektets resursuppskattning. (Lyytinen & Ropponen, 2000) 2.6.4 Resursanvändning och utförande Lyytinen och Ropponen (2000) beskriver att det som i huvudsak utgör riskerna för resursanvändning och utförande består av två faktorer. Den första faktorn är projektledningens tidigare erfarenheter av riskhantering i projekt. En erfaren ledning har ofta lättare att hantera dessa risker än en oerfaren ledning. Den andra faktorn är storleken på organisationen som utför systemutvecklingsprojektet. Enligt författarna är mindre organisationer generellt sett bättre än stora på att hantera risker som rör resursanvändandet och själva utförandet. Övriga variabler som utgör risken är utvärdering av prestanda, hantering av ett projekts komplexitet och uppskattning av hård- och mjukvara kapacitet. Ett dåligt 14

hanterande av dessa variabler resulterar i okontrollerad resursanvändning och ett dåligt utförande. 2.6.5 Personalhantering Den sista riskkomponenten summerar de faktorer som samspelar vid risker med personalhantering. Några exempel på dessa faktorer kan vara otillräcklig kompetens och orealistiska förväntningar på personalens förmågor. Dålig resursanvändning och bristande krav resulterar ofta i att personalen blir stressade i de senare stegen av projekten, vilket i sin tur ökar personalens risker. (Lyytinen & Ropponen, 2000) 2.6.6 Rekommendationer Lyytinen och Ropponen (2000) rekommenderar att organisationen och projektgruppen bör identifiera och hantera de sex ovanstående riskkomponenterna i systemutvecklingsprojekt. Vidare rekommenderas att projektgruppen tar riskhanteringsmetoder på största allvar och strävar efter att utveckla en god användarerfarenhet av riskhantering. Några av riskkomponenterna är utanför projektgruppens direkta kontroll, men de är trots det kritiska problem som bör uppmärksammas. Nödvändiga åtgärder för att reducera relaterade risker bör genomföras. 2.7 Riskhanteringsstrategi Cule et al. (2000) beskriver att om en risk skall kunna hanteras måste den först identifieras. Den förslagna riskhanteringsstrategin har varit att utveckla en checklista över de risker som finns och sedan adressera varje enskild risk. Detta kan vara svårt, menar författarna, då komplexa projekt kan ha många olika risker. Att hantera en sådan mängd av risker (varav några risker som är odefinierade och oigenkännliga) som unika objekt på en checklista, är opraktiskt. Det finns då ett behov av tillvägagångssätt som minskar långa checklistor till hanterbara former, utan att överse någon risk. En möjlighet är ett integrerat tillvägagångssätt som innebär att risker delas in i olika kategorier, där varje kategori kräver ett specifikt hanteringsbeteende tillsammans med de strategier som används för att undvika eller minska risker. Genom ett sådant integrerat tillvägagångssätt blir risker mer lätthanterliga och projektledare slipper oroa sig över om alla risker, eller liknande faktorer, är identifierade. Författarna beskriver vidare att en del risker ligger utanför projektledarens kontroll och att risker kan delas upp I två huvudkategorier; interna risker och externa risker (där externa risker innefattar de risker som ligger utanför projektledarens kontroll). På grund av den stora varieteten av interna och externa risker, har två underkategorier identifierats; klient och miljö i externa risker 15

och sig själv och uppgift i interna risker. Figur 5 illustrerar riskkategorierna ur en projektledares perspektiv. Figur 5. Projektledarens perspektiv på externa och interna risker (Cule et al. 2000:67). Riskerna i kategorin sig själv (self) reflekterar de centrala karaktäristiska dragen hos projektledaren och om denne har den förståelsen och kompetensen som positionen kräver (som exempelvis de egenskaper som en gruppledare behöver). En projektledare behöver således utveckla sin kompetens kontinuerligt för att kunna bemöta de krav som projektet ställer. Den andra interna kategorin uppgift (task) innefattar de risker som finns med det aktiva projektet och riktningen som valts (exempel på risker är dålig sammanhållning i gruppen, dålig expertis hos gruppmedlemmarna eller dålig projektuppskattning). Projektledaren har möjlighet att kontrollera och påverka dessa risker. Riskerna i kategorin klient (client) innefattar externa risker som inte projektledaren kan kontrollera, men är risker som projektledaren kan påverka med inflytande (som exempelvis slutanvändarens förväntningar). Riskerna i den andra underkategorin miljö (environment) innefattar risker som inte kan kontrolleras eller påverkas av projektledaren (som exempelvis instabil företagsmiljö). Även fast inte projektledaren har någon kontroll över miljö - klassade risker bör denne agera så effektivt och snabbt som möjligt när en sådan risk inträffar. (Cule et al. 2000) 16

2.8 Teoretisk sammanfattning För att ge läsaren en tydligare bild över det teoretiska ramverkets olika delar, kommer följande en kort sammanfattning innehållandes hur jag som författare har tolkat de olika områdena, samt hur de hänger ihop med varandra. Tidigare studier gjorda av undersökningsgrupperna The Standish Group (2009) och Projectplace (2009) visar på ett chockerande stort antal av systemutvecklingsprojekt som misslyckas. De har liknande definitioner av när ett systemutvecklingsprojekt klassas som misslyckat. De innefattar följande kriterier: utsatt budget överskrids, tidsplanen för projektet blivit spräckt, slutproduktens kvalitet är bristande, eller att produkten inte levererar uppfyllda krav som beställdes av kunden. Under de senare åren har många organisationer tillämpat agila metoder i systemutvecklingsprojekt. Författarna Cronholm (2008), Erickson, Lyytinen och Siau (2005) beskriver att agila metoder i systemutvecklingsprojekt bidrar till flexibilitet, stärker lagarbete och ger möjlighet till förändring under processens gång. Schwaber och Sutherland (2011) beskriver Scrum som ett enkelt och kraftfullt verktyg vid systemutvecklingsprojekt, men menar att det kan vara svårt att bemästra metoden till fullo. Björkholm och Brattberg (2010) beskriver att organisationer kan ha svårt att estimera hur mycket arbete som kan utföras under en sprint. Om organisationen inte bemästrat metoden kan det därmed leda till att ineffektiva sprintar tar upp tiden som initialt var rekommenderad för reflektioner och lärande, som i sin tur kan leda till problematiken som författarna Lyytinen och Robey (1999) beskriver. Lyytinen och Robey (1999) har dragit slutsatserna att några av de främsta orsakerna till att systemutvecklingsprojekt misslyckas, är för att organisationer inte lyckas lära sig från sina tidigare erfarenheter. Verktyg och metodologier kan inte ensamt bidra med den lärandeprocessen, utan organisationer måste lära sig från sina tidigare erfarenheter. De beskriver att organisationers förmåga att lära kan begränsas. Orsakerna till detta är enligt författarna bland annat att organisationer kan bli överbelastade av mängder med information som gör det svårt att hantera och forma kunskap. Figur 4 (s. 12) illustrerar felaktigt lärande. Författarna Björkholm, Brattberg (2010), Schwaber och Sutherland (2011) beskriver på liknande sätt ett av Scrums moment, retrospektivet, som möjliggör reflektioner och tillvaratagandet av erfarenheter. Utöver retrospektivet så tillgodoser Scrum diverse möten som fungerar som reflektionsinstrument. En organisation som arbetar strikt efter Scrum får alltså ett antal verktyg och moment ägnat just till lärandet och tillvaratagandet av tidigare erfarenheter och lärdom (i syftet att minimera problematiken som Lyytinen och Robey (1999) beskrev i stycket ovan). Projektledning skiljer sig till viss del mellan traditionella projekt och agila projekt. Författarna Tonnquist (2012), Schwaber och Sutherland (2011) beskriver att samtliga medlemmar i gruppen ansvarar för att arbetet ska bli utfört. 17

Projektgruppen blir effektivare i beslutsattande processer, men själva sytemutvecklingsprojektets komplexitet ökar i sin tur. Ett systemutvecklingsprojekts komplexitet och omfattning ökar antalet risker som kan uppstå under processens gång. Cule et al. (2000) drar slutsatserna att en risk först måste identifieras för att organisationen sedan ska kunna vidta nödvändiga åtgärder. Att ignorera en grupp av riskerna kan, enligt författarna, leda till att nya risker uppstår. Det kan i sin tur resultera i att ett systemutvecklingsprojekt misslyckas. Scrum tillgodoser reflektionstillfällen och andra möjligheter som teoretiskt sätt bör minska många av riskerna. Är utövandet av metoden bristande kan det leda till att sådana tillfällen blir minimerade och att relaterade risker uppstår, något som Lyytinen och Robey (1999) menar är en av de främsta orsakerna till misslyckade systemutvecklingsprojekt. 18

3. Metod I uppsatsens tredje kapitel kommer tillvägagångssättet som använts för att kunna svara på uppsatsens forskningsfråga att presenteras. Kapitlets innehåll beskriver hur det empiriska materialet har samlats in genom en kvalitativ undersökning i form av semistrukturerade intervjuer i en fallstudie med valda respondenter. 3.1 Forskningsansats Enligt Patel och Davidson (2003) finns det tre olika forskningsansatser man kan välja när teori ska relateras till verklighet. De tre forskningsansatserna är den deduktiva ansatsen, den induktiva ansatsen samt den abduktiva ansatsen. Med en deduktiv ansats avser forskaren att bedriva ett arbetssätt där slutsatser om verkligheten dras från befintliga teorier. Dessa slutsatser testas sedan mot empirin. Den induktiva forskningsansatsen kännetecknas av utforskande arbete, eftersom en studie med en induktiv ansats inte har tidigare teoretisk grund fastställd. Med en induktiv forskningsansats avser alltså forskaren att studera ett empiriskt forskningsobjekt utan att ha studerat några tidigare teorier. Den abduktiva forskningsansatsen är en blandning mellan den induktiva och den deduktiva ansatsen. Med en abduktiv forskningsansats avser forskaren att studera ett fall, med en efterkommande teori som beskriver fallet. Forskningsansatsen som valdes till uppsatsen var av det deduktiva slaget, eftersom syftet med uppsatsen var att få svar på frågan varför systemutvecklingsprojekt med agila metoder misslyckas. För att komma fram till det resultatet kan det vara fördelaktigt att ha en teori som beskriver hur systemutvecklingsprojekt med agila metoder bedrivs och andra relevanta teorier. Jag valde en deduktiv ansats av anledningen att jag ville, med hjälp av ett teoretiskt ramverk, bilda en god förståelse om de olika komponenterna vars samspel bidrar till att systemutvecklingsprojekt med agila metoder misslyckas i den stora procentuella utsträckningen som tidigare studier har visat. Jag ansåg att en deduktiv forskningsansats med ett fastställt teoretiskt ramverk skulle ge mig djupare förståelse om ämnet och därmed kunna forma datainsamlingsunderlag med högre validitet (det vill säga, att säkerställa det som avsågs att undersökas verkligen blev undersökt). 3.2 Utforskande fallstudie Den vetenskapliga ansats som valts är en utforskande fallstudie. En fallstudie är en beteckning som innebär att en undersökning kommer att genomföras på en avgränsad grupp. Exempel på ett fall som kan undersökas kan vara en grupp individer eller en organisation. (Patel & Davidson, 2003) Fallstudier ger möjlighet till att gå in på djupet av ett ämne. Det som är till en fördel med att gå in på djupet 19

med undersökningen är att man får en mer detaljerad kunskap om ämnet, än vad exempelvis en enkätstudie kan ge. Fallstudier används främst då en forskare vill svara på en fråga som inleds med varför, hur eller vad. Det finns olika ansatser till fallstudier, där varje ansats används vid olika ändamål. De vanligaste ansatserna är: utforskande, beskrivande och den förklarande ansatsen. Ansatserna har olika lämpligheter och bör väljas utifrån vilken forskningsfråga som ställts. (Bell, 2005) En forskningsfråga som inleds med varför ger, enligt Yin (2009) lämplighet till att genomföra en utforskande fallstudie. Kriterier som understryker den lämpligheten är att med frågan varför vill man utforska de bakomliggande faktorerna som bidrar till att fenomenet ser ut som det gör i dagsläget (det vill säga i mitt fall; de stora procentuella siffrorna av de totala andelarna av systemutvecklingsprojekt som misslyckas, trots moderna metoder att bedriva systemutvecklingsprojekt). Bell (2005) beskriver att fallstudier ger möjlighet att gå in på djupet av ett ämne genom att studera en avgränsad aspekt av ett problem, vilket gör det särskilt lämpligt för forskare som bedriver forskningsprocessen på egen hand. Varje individ och organisation har grundläggande gemensamma drag, men också egenskaper som är unika från varandra. Jag anser att en fallstudie med en utforskande ansats var ett utmärkt arbetssätt för min studie, då problemet krävde att man gick in på djupet av ämnet och försökte utveckla en förståelse om faktorerna som har en påverkan till varför organisationer misslyckas med agila metoder i systemutvecklingsprojekt. 3.3 Urval och empirisk miljö Patel och Davidson (2003) beskriver att valet av individer som ska medverka i undersökningen bör avgöras utifrån hur problemet är formulerat. Är problemet formulerat på ett sätt som tar med en specifik grupp av individer så ska dessa individer naturligvis ingå i undersökningen. Om problemet berör en kategori, utan att närmare fastställa en specifik grupp av individer, är det endast individer från denna kategori som ska ingå i undersökningen. Författarna fortsätter med att beskriva att om en fallstudie är den valda vetenskapliga ansatsen ska undersökaren identifiera ett lämpligt fall, det vill säga, en avgränsad grupp individer inom undersökningsområdet. Då den valda ansatsen till uppsatsen var en utforskande fallstudie gav det motivering till att undersöka ett fall i en empirisk miljö. Jag valde att applicera min fallstudie mot IT-tjänsteföretaget Logica, vid koncernens Östersundskontor. Logica arbetar med systemutveckling som bedrivs i projektform, där olika agila och iterativa metoder tillämpas. Jag valde att titta närmare på hur Logica bedriver systemutvecklingsprojekt med metoden Scrum. Min forskningsfråga var av ett brett perspektiv, där den organisatoriska ledningen, utöver själva systemutvecklingsgruppen, var berörd och motiverades att undersökas, för att kunna svara på frågan så långt som det är möjligt. Jag valde därför att genomföra tre intervjuer, där de olika aktörernas roller bestod av en systemutvecklare, en projektledare (en Scrum Master), samt en aktör som har översikt över systemutvecklingsprojekten från en organisatorisk nivå med ledningsperspektiv. Svaren från dessa individer gav mig det underlag som var 20

nödvändigt för att kunna svara på den ställda forskningsfrågan. Organisationen Logica kommer att presenteras vidare i uppsatsens empirikapitel. 3.4 Kvalitativ och kvantitativ undersökning Med en fallstudie som den valda vetenskapliga ansatsen innebär det att man går in på djupet av ett problem och försöker utveckla en mer detaljerad förståelse om ämnet. De vanligaste två undersökningsformerna är den kvalitativa och den kvantitativa undersökningen. Det mest övergripande målet med kvantitativ undersökning är att få information från en stor mängd individer, vars svar har uppgiften att agera som ett representativt urval från en större grupp eller population. Representanternas svar används sedan för att se genomsnitt eller se gemensamma mönster hos den berörda gruppen eller populationen. (Bell, 2005) Helt i motsats mot den kvantitativa undersökningen är målet med kvalitativa undersökningar inte att få fram statistiska eller kvantifierbara resultat. En kvalitativ undersöknings främsta mål är däremot att försök hitta de djupgående orsakerna, själva essensen, eller kvaliteten av ämnet för att få en mer detaljerad kunskap i det område som avses att undersökas. En kvalitativ undersökningsansats är intervjuer med ett begränsat antal respondenter. (Yin, 2009) Patel och Davidson (2003) beskriver att syftet med kvalitativa undersökningar är att få en djupare kunskap än vad som kan erhållas vid användningen av kvantitativa undersökningar. Till min studie valde jag att använda mig av en kvalitativ undersökning med semistrukturerade intervjuer. 3.5 Datainsamling Det finns olika tillvägagångssätt för en forskare att samla in data på. De olika tillvägagångssätten är datainsamling från dokumentation, arkiv, observation, enkätstudier och intervjuer. Med en fallstudie som vetenskaplig ansats kommer den främsta datainsamlingen komma från en kvalitativ undersökning som bedrivs empiriskt i en verklig miljö. (Yin, 2009) 3.5.1 Intervjuer Bell (2005) beskriver att en stor fördel med kvalitativa intervjuer är dess flexibilitet; att en duktig intervjuare kan ställa motfrågor och diskutera motiv och känslor. Dessa aspekter är näst intill omöjliga att fånga in i en kvantitativ enkätstudie. Att se hur respondenten tolkar frågorna och sedan tonfallet och pauserna i svaren som ges kan ge information som inte är möjlig att hämta från skriftliga svar. Ett sådant svar kan föda följdfrågor som ger ett mer djup i undersökningen. Enligt Trost (2005) kan kvalitativa intervjuer beskrivas genom karaktäriserande raka och enkla intervjufrågor. Författaren menar att med raka och enkla frågor till respondenterna, får forskaren omfattande och utförliga svar. En kvalitativ intervju kan vara strukturerad, semistrukturerad eller ostrukturerad. Med strukturerade intervjuer är frågorna utformade med fasta svarsalternativ, där 21

samma frågor ställs till alla respondenter. Svaren kategoriseras sedan till någon typ av svarskategori, och resultatet blir således lätt att sammanfatta och analysera. I ostrukturerade intervjuer är frågorna som ställs till respondenterna öppna och formulerade på ett sätt som kan uppfattas på olika sätt. Semistrukturerade intervjuer är en blandning mellan strukturerade och ostrukturerade intervjuer. Den typen av kvalitativ intervju ger alla respondenter samma frågor men möjlighet till öppna svar. (Bell, 2005) Jag valde att använda mig av semistrukturerade kvalitativa intervjuer eftersom jag ville ställa liknande frågor till samtliga respondenter med öppna svar, och sedan analysera vilken uppfattning respektive respondent, och dess roll i organisationen hade, angående vad som fungerade bra och vad det fanns för brister med agil metodtillämpning vii systemutvecklingsprojekt. Jag spelade in mina intervjuer för att, utöver anteckningarna, säkerställa att jag fick med allt som respondenterna sa. 3.6 Bearbetning av insamlad data När data har blivit insamlad, genom kvalitativa eller kvantitativa undersökningsmedel till ett forsknings- utrednings- eller utvecklingsarbete, är nästa steg att systematisera, komprimera och bearbeta materialet för att möjliggöra att kunna svara på forskningsfrågan som ställts. Metoderna som används vid att analysera data i form av textmaterial kallas för kvalitativa metoder. (Patel & Davidson, 2003) När en kvalitativ analys tillämpas är det ofta data i form av textmaterial som ska bearbetas, från exempelvis intervjuer, böcker eller artiklar. Patel och Davidson (2003) beskriver att det även går att bearbeta kvalitativt material som samlats in genom video- eller ljudinspelning. En kvalitativ datainsamling som består av ett begränsat antal intervjuer genererar ofta en stor mängd textmaterial, vilket gör kvalitativa undersökningar tids- och arbetskrävande. Författarna rekommenderar att undersökaren för en dagbok där tankar omkring undersökningen dokumenteras, eftersom det är viktigt till den slutliga analysen. En bra kvalitativ analys kännetecknas av en bra inre logik som kan relateras till en meningsfull helhet. Uppsatsens analys påbörjades kort efter den första intervjuen var färdig. Patel och Davidson (2003) beskriver att den tekniken är bra, eftersom svaren finns färskt i minnet. Min insamlade data bestod av textmaterial och ljudinspelningar. Jag gjorde som författarna rekommenderade; jag komprimerade mitt material till ett hanterbart format, för att sedan bearbeta det och möjliggöra att kunna ge ett svar till min forskningsfråga. Jag lade det systematiserade materialet mot uppsatsens teori och försökte därifrån utskilja likheter och skillnader. Utifrån dessa likheter och skillnader förde jag uppsatsens analys för att sedan kunna dra uppsatsens slutsatser. Figur 6 illustrerar hur mitt upplägg inför analysen såg ut. 22

Figur 6. Figuren visar hur uppsatsens teori lades mot empirin i en analys. 3.7 Validitet och reliabilitet När datainsamling av uppsatsens empiri ska ske, måste dess validitet och reliabilitet tas i beaktning. Patel och Davidson (2003) beskriver att validiteten och reliabiliteten hos en studie är viktigt, då begreppens kärnmening innebär att det som är menat att undersökas verkligen blir undersökt. 3.7.1 Validitet Bell (2005) beskriver att begreppet validitet är synonymt med begreppet giltighet och att det är ett mått på om en viss fråga mäter eller beskriver det som syftet med frågan var. Att man upphåller en god validitet innebär att frågeställningen har som syfte att kunna ge trovärdiga slutsatser och att det resultat som en undersökning leder fram till ska ge ett starkt stöd till de tolkningar som görs. Enligt Patel och Davidson (2003) är validiteten i en kvalitativ studie inte enbart relaterat till datainsamlingen, utan strävan att uppnå en god validitet i studien florerar genom hela forskningsprocessen. Validitetens roll i en kvalitativ datainsamling är kopplad till hur vida undersökaren lyckas med att skapa en trovärdig tolkning av forskningsobjektets omvärld. Angående extern validitet beskriver författarna Lewis, Saunders och Thornhill (2009) att det kan vara problematiskt att generalisera resultaten generade av en fallstudie, då fallet som undersöks ofta är en enskild organisation. Författarna fortsätter att beskriva att undersökarens syfte i ett sådant fall inte är att producera en teori som är generaliserbar mot alla populationer. De menar att undersökarens syfte är att försöka förklara vad som händer i den unika situationen där fallstudien appliceras. De sammanfattar med orden: så länge undersökaren inte hävdar att resultaten från studien är generaliserbara, så är det inget problem (s. 158). Eftersom jag har genomfört en fallstudie på en enskild organisation så tycker jag att de författarna beskriver ovan stämmer bra överens med min situation. 23