EXAMENSARBETE
Varför misslyckas organisationer med agil
metodtillämpning vid
systemutvecklingsprojekt?
Marcus Tinnsten
Filosofie kandidatexamen
Systemvetenskap
LULEÅ TEKNISKA UNIVERSITET
Varför misslyckas organisationer med agil
metodtillämpning vid
systemutvecklingsprojekt?
Marcus Tinnsten, martin-9@student.ltu.se2012-05-31
i
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.
ii
Sammanfattning
Organisationer har ökat tillämpningen av agila metoder i systemutvecklings-projekt 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ångs-punkterna till ett sytemutvecklingsprojekt formas.
iii
Innehållsförteckning
1. INLEDNING ... 1 1.1BAKGRUND ... 1 1.2PROBLEMDISKUSSION... 2 1.3FORSKNINGSFRÅGA... 3 1.4SYFTE ... 3 1.5AVGRÄNSNING ... 3 2. TEORI ... 4 2.1SYSTEMUTVECKLING ... 4 2.2AGILA METODER ... 52.2.1 Det agila manifestet ... 5
2.3SCRUM... 6
2.3.1 Artefakter ... 7
2.3.2 Teamet ... 7
2.3.3 Aktiviteter ... 7
2.3.4 Sammanfattning av Scrum ... 9
2.4PROJEKT OCH PROJEKTSTYRNING ... 10
2.4.1 Projektledare ... 11
2.5ORGANISATIONERS 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.6RISKER 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.7RISKHANTERINGSSTRATEGI ... 15 2.8TEORETISK SAMMANFATTNING ... 17 3. METOD ... 19 3.1FORSKNINGSANSATS ... 19 3.2UTFORSKANDE FALLSTUDIE ... 19
3.3URVAL OCH EMPIRISK MILJÖ ... 20
3.4 KVALITATIV OCH KVANTITATIV UNDERSÖKNING ... 21
3.5DATAINSAMLING ... 21
3.5.1 Intervjuer ... 21
3.6BEARBETNING AV INSAMLAD DATA ... 22
3.7VALIDITET OCH RELIABILITET ... 23
3.7.1 Validitet ... 23
3.7.2 Reliabilitet ... 24
4. EMPIRI ... 26
iv
4.2AGILA METODER I SYSTEMUTVECKLINGSPROJEKT ... 27
4.3PROJEKTLEDNING OCH PROJEKTSTYRNING ... 28
4.4ORGANISATIONENS LÄRANDE VID SYSTEMUTVECKLINGSPROJEKT ... 29
4.5RISKER VID SYSTEMUTVECKLINGSPROJEKT ... 30
5. ANALYS ... 33
5.1AGILA METODER I SYSTEMUTVECKLINGSPROJEKT ... 33
5.2ORGANISATIONERS LÄRANDE VID SYSTEMUTVECKLINGSPROJEKT... 35
5.3RISKER I SYSTEMUTVECKLINGSPROJEKT... 36
6. SLUTSATSER OCH DISKUSSION ... 39
6.1SLUTSATSER ... 39
6.2DISKUSSION ... 40
6.3FÖRSLAG TILL FORTSATT FORSKNING... 41
7. REFERENSER ... 42 7.1LITTERÄRA KÄLLOR ... 42 7.2ELEKTRONISKA KÄLLOR ... 43 BILAGA 1. ... A.1 BILAGA 2. ... B.1
Figurförteckning
FIGUR 1.LIVSCYKELMODELLEN (ANDERSEN,1994:48). ... 4FIGUR 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
1
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 systemutvecklings-process 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 system-utvecklingsprojekt? 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
2
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.
3
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 system- utvecklingsprojekt?
1.4 Syfte
Uppsatsens syfte är att identifiera vad som är orsakerna till att system-utvecklingsprojekt 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.
4
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 system-utvecklingsprojekt, 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 system-utvecklingsarbetet 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 informations-systemets livslopp, där faserna analys till implementering är själva systemutvecklingen (se figur 1).
Figur 1. Livscykelmodellen (Andersen, 1994:48).
5
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 systemutvecklings-projekt 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 system-utvecklingsprojekt ä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 planNedan 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.6
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.
7
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
8
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.
9
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.
10
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 systemutvecklings-projekt. De faktorerna som samspelar i den definitionen är en god projekt-planering, 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.
11
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 riskhanterings-tekniker, 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)
12
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),
13
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)
14
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
15
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.
16
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 projekt-ledaren kan kontrollera, men är risker som projektprojekt-ledaren kan påverka med inflytande (som exempelvis slutanvändarens förväntningar).
17
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 system-utvecklingsprojekt 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).
18
Projektgruppen blir effektivare i beslutsattande processer, men själva sytemutvecklingsprojektets komplexitet ökar i sin tur.
19
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 system-utvecklingsprojekt 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
20
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ö.
21
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
22
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öknings-medel 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.
23
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).
24
Jag strävade mot, som Bell (2005) och Patel och Davidson (2003) beskrev, att inte bara relatera till studiens datainsamling för att erhålla en god validitet, utan istället lät jag det tankesättet genomsyra hela uppsatsprocessen. Men det menar jag att jag har strävat mot att komma fram till trovärdiga slutsatser utifrån den forskningsfrågan som var ställd. Jag siktade på att utforma en trovärdig tolkning av den empiri jag samlade in och presentera den på ett tillförlitligt sätt (det vill säga, helt grundad utifrån den datainsamlingen som genomfördes).
För att vidare uppnå en god trovärdighet till min studies resultat har jag arbetat med, som tidigare nämnts, en deduktiv forskningsansats som gav mig en större förståelse om ämnets djup, innan jag strukturerade upp min datainsamlingsmetod. Respondenterna valdes efter kriterierna jag ansåg krävdes utifrån mitt teoretiska ramverk. När intervjuerna genomfördes så försökte jag hålla mig till intervjumallen till så stor mån som möjligt. Jag gjorde det i syfte att inte ge respondenterna för stor möjlighet att sväva iväg och prata i ett bredare djup om egna intressen, utan istället diskutera omkring den ställda frågan. Intervjuerna (som nämnts tidigare) spelades in och sammanställningarna av respektive intervju sammanställdes kort efter dem var gjorda, då informationen var färskast i mitt minne. I genomförandet av min datainsamling använde jag mig av multipla källor. Jag anser att de svar jag fick från min datainsamling hade en god validitet.
De litterära studierna som jag har använt för att forma mitt teoretiska kapitel har valts efter det jag har ansett varit relevant för att uppnå uppsatsens syfte. Jag har dels valt teori som gav mig själv (och läsaren) en större förståelse vad de olika begreppen innebär (såsom agila metoder, systemutvecklingsprojekt m.m.) och tidigare gjorda studier inom området, vars relevans och giltighet har noggrant granskats.
3.7.2 Reliabilitet
Bell (2005) beskriver att reliabilitet är ett mått på i vilken utsträckning ett tillvägagångssätt ger samma resultat vid olika tillfällen, då omständigheterna är relativt lika. Att studien är reliabel innebär att det presenterade innehållet är tillförlitligt. Om en individ blir intervjuad ett antal gånger i en kvantitativ undersökning med samma uppsättning av frågor, men frågorna genererar olika typer av svar, innebär det att datainsamlingen har en låg reliabilitet. Detta skiljer sig från en kvalitativ undersökning, då en individ kan ha ändrat sin uppfattning eller ha fått en ny insikt om ett specifikt område, som individen inte hade vid det första tillfället den kvalitativa datainsamlingen ägde rum. Detta behöver då inte vara ett tecken på en låg reliabilitet hos den kvalitativa undersökningen. Istället bör reliabiliteten ses mot den unika situationens bakgrund som råder vid undersökningstillfället. Reliabilitetsbegreppet har med andra ord en nära koppling till validitetsbegreppet i kvalitativa studier. Sammanflätningen av dessa två begrepp är på ett sådant vis att kvalitativa forskare sällan använder sig av begreppet reliabilitet, istället får begreppet validitet en större betydelse. (Patel & Davidson, 2003)
25
26
4. Empiri
Det fjärde kapitlet kommer följande att presentera den empiri som samlats in genom semistrukturerade intervjuer med anställda vid organisationen Logicas Östersundskontor. Kapitlets innehåll är kategoriserat efter uppsatsens perspektiv.
Datainsamlingens resultat kommer att presenteras i följande kapitel i en sammanfattad version. Om läsaren är intresserad av att se vilka frågor som ställdes, finns de tillgängliga i bilagor i slutet på rapporten. Anledningen till att presentera svaren i en sammanfattad version är att det ska vara lättläst och enkelt för läsaren att förstå sammanhanget, samtidigt som en röd tråd i arbetet bibehålls. Urvalet av svar som valts att sammanfattats och presenteras i kapitlet är svar som ansetts relevant för att svara på uppsatsens forskningsfråga. Datainsamlingen kommer att presenteras följande i kategorier av ämnen som uppsatsen har tittat på.
4.1 Presentation av empirisk miljö
Uppsatsens empiri är insamlad på koncernen Logicas Östersundskontor, genom semistrukturerade intervjuer med tre anställda på kontoret. Logica är ett stort IT-tjänsteföretag som står som ett av de ledande företagen inom branschen med sina omkring 41 000 medarbetare runt om i världen. Kontoret i Östersund består av omkring 110 medarbetare som har sitt mest förekommande arbete i förvaltningsuppdrag, men arbetar även med nya systemutvecklingsprojekt. Under åren har företaget använt sig av olika iterativa arbetssätt, som metoden ”Rational Unified Process” (RUP), för att bedriva systemutvecklingsprojekt. De senaste åren har verksamheten använt sig av metoden Scrum för att bedriva systemutvecklingsprojekt. Organisationen har använt sig av Scrums samtliga moment.
Två intervjuer genomfördes med anställda på företaget som har ingått i systemutvecklingsprojekt där metoden Scrum användes. En av dessa agerade som Scrum Master under projektet och den andra som systemutvecklare. Den tredje respondenten som intervjuades har en god organisatorisk överblick och lämpade sig därmed bra för undersökningens syfte och för att få en bild hur organisationens ledning följer fortskridandet av systemutvecklingsprojekt på operativ nivå. Alla tillfrågade respondenter har haft en god erfarenhet av att bedriva, deltaga eller att följa systemutvecklingsprojekt i allmänhet. Respondenterna har valts att presenteras med en representativ bokstav för respektive respondents roll. Nedan följer rollernas betäckningar.
Respondent A – Systemutvecklare. Respondent B – Scrum Master.
27
4.2 Agila metoder i systemutvecklingsprojekt
Ledningen väljer att använda metoden Scrum när det är lägligt och vid de arbetsuppgifter som metoden är applicerbar till. Organisationen upplever att systemutvecklingsprojekten har blivit en mer flexibel process. Respondent A beskriver att kravhanteringen var en aspekt som fungerade bra med arbetssättet som användes innan Scrum. När frågan ställdes vad skälet var att organisationen började använda Scrum i systemutvecklingsprojekt svarades att det var något som ledningen hade bestämt. Respondent C nämner att ett av de främsta skälen att agila metoder och iterativa arbetssätt har börjat användas mer är för att man försöker komma bort från ”big-bang approachen” (som innebär att man utvecklar stora delar av ett system i ett svep där allt levereras samtidigt – vattenfallsmodellen är en sådan variant). Med en iterativ arbetsgång finns det möjlighet till att dela upp arbetet i mindre portioner som går att avstämma mot kunden eftersom. En fördel med det arbetssättet är att organisationen får möjligheten att stanna upp och reflektera och lägga fokus där det behövs, eller vid andra centralt viktiga delar av projektet. Respondent C berättar vidare att anledningen till att man började arbeta med agila metoder vid systemutvecklingsprojekt var för det agila tänket: flexibilitet, lättrörlighet, möjlighet till förändringar och stort fokus på resultat. Organisationen har tidigare erfarenheter att projekt förändras och att det är näst intill omöjligt att förutse allt. Omvärlden och behoven förändras allt eftersom, och därför är det passande att använda sig av agila metoder. Det är ett av skälen till varför organisationen använder sig just av Scrum. Andra skäl är att det är en trendig metod vid systemutvecklingsprojekt och det är förekommande att kunder frågar explicit att systemutvecklingsprojektet ska bedrivas med Scrum.
Frågan om Scrum levde upp till organisationens förväntningar gav en del intressanta svar. Respondent B beskriver att det nästan bara innebar fördelar men att det var förekommande att sprintarna i projektet blev ineffektiva. I Scrums sprintar ska alla moment ingå (krav, utveckling, test), men det fungerade dåligt rent praktiskt. Testarna blev lidandes för att de inte hann med allt de skulle göra, samtidigt som utvecklarna fick en hel del dötid (idle time) mot slutet av sprintarna. Irritation skapades mellan kravarbetare och utvecklare, eftersom utvecklare tyckte att kraven som producerats var otillräckliga. Dålig synkronisering mellan olika roller i projektet ledde till stress varvat med irritation och dötid. Kravarbetarna blev satta i en jobbig situation då de behövde stressa med att producera nya krav samtidigt som de behövde korrigera tidigare ställda krav. Respondent B hävdar här att själva upplägget av ett projekt och arbetsfördelningen till de olika sprintarna fungerade bra, förutom att test och utveckling låg i samma sprint. Respondent A menar att det fungerade dåligt rent praktiskt att kravdelen låg i samma sprint av anledningen att utvecklingsdelen stod praktiskt taget still i väntan på nya krav skulle produceras.
28
annan mycket uppskattad del i Scrum var uppdelningen av arbetet i segment och att möjligheterna till kontinuerlig avstämning fanns tillgängligt. Utöver de dagliga mötena användes reguljära veckomöten, kallade ”Scrum of scrums”, där samtliga Scrum Masters diskuterade hur de olika bitarna i projektet låg till.
Respondent C beskriver att det finns en viss skillnad mellan teori och praktik. Rent teoretiskt är flexibilitet och möjlighet till förändringar bra, men det kan vara svårt att tillämpa rent praktiskt i vissa fall. Ett sådant fall kan vara att organisationen har ett avtal med en kund och en offert över vad som ska ingå. Det går inte att ändra sig hur som helst då. Det är även en konkurrensfråga. Om organisationen ändrar förutsättningarna kan konkurrenterna hävda att man inte följer uppdraget i formen som det gavs. Det är med andra ord svårt att följa det agila tänket fullt ut. Respondent C beskriver vidare att organisationen brukar uppmana medarbetarna att det är viktigt att arbeta agilt vid bitarna som tillåter detta vid ett systemutvecklingsprojekt.
”Även fast man går norrut kan man göra det agilt” – Respondent C.
4.3 Projektledning och projektstyrning
Reflektioner av projektledning och självorganiserade teams under system-utvecklingsprojekt med metoden Scrum har visat sig ha en delad karaktär. Grundtanken med Scrums självorganiserade teams är att projektets medarbetare har det främsta ansvaret att arbetsuppgifter prioriteras rätt och utförs enligt utsatta tidsramar. Scrum teamet ska således ha den bästa uppfattningen om vad som bör göras. Deltagarna i Scrum projektet får en arbetsuppgift, ett ”item”, ur produkt backloggen som denne har ansvar över blir utfört, enligt uppsatta ramar. En uppskattad aspekt med Scrums dagliga möten var att alla blev tvungna att redovisa det dem gjort sedan föregående möte, vilket ledde till en högre produktivitet.
Alla individer är olika, något som blev synligt i praktiken. Scrum Masterns roll blev i vissa fall mer likt den traditionella projektledarens, då vissa individer behövde en extra push för att utföra arbetet tidsenligt. Faktorer som har en påverkan i sådana fall kan vara individens erfarenhet. Har individen en stor erfarenhet av utföranden av systemutvecklingsprojekt brukar självorganisering vara lämpligt. Är individen ny, eller oerfaren, är det för denne inte alltid självklart vad som ska göras och vad som krävs. Respondent C nämner att det är viktigt att projektledaren är lyhörd och frågar sig själv ”vad har jag för typer av individer i gruppen?”, och anpassar sig efter rådande situation. En sådan situation kan vara då Scrum Mastern får agera mer enligt en traditionell projektledare och pusha på för att arbetet ska bli gjort. Samtliga respondenter är överens om att grundtanken med självorganiserade teams är övergripande bra. Respondent A tillägger här att om problem uppstår finns det oftast någon på kontoret man kan fråga.
29
projektet fortskrider i sin helhet. En annat uppskattat verktyg som Scrum tillgodoser till projektstyrning är sprintarnas retrospektiv. Det ger projektteamen en överblick hur olika delar har gått och om något bör beaktas till nästkommande sprintar.
Organisationens ledning är nöjd med hur projektstyrning fungerar på organisatorisk nivå. Metoden har justerats på vissa sätt för att det här ska passa organisationens behov så långt som möjligt. En av dessa justeringar innebar ett utökat ansvar till Scrum projektets Scrum Masters, som fick uppgifterna att leverera månadsrapporter innehållandes reflektioner och fortskridande av systemutvecklingsprojektet.
Utöver de införda månadsrapporterna tillägger Respondent C här att det är lätt för alla intressenter av systemutvecklings projekt med Scrum att följa processens gång, då Burndown tavlan finns tillgänglig. Respondent C beskriver vidare att det är lätt att informera produktägaren om projektets fortskridande då Burndown tavlan finns tillgänglig att peka på exakt vart projektet befinner sig och hur processen går. I helhet är samtliga respondenter överens om att Scrum lämpar sig utmärkt som ett verktyg för projektstyrning.
4.4 Organisationens lärande vid
systemutvecklingsprojekt
Organisationen jobbar med kunskapsspridning. Det vill säga, om det finns medarbetare med en viss kunskap, försöker organisationen se om det går att sprida den kunskapen till övriga medarbetare. Om inte kunskapen som krävs finns i huset kan den finnas på andra orter i koncernen. I sådana fall försöker organisationen alltid att ordna så att personen som sitter på den specifika kunskapen kan resa till orten där kunskapen krävs. Det är en stor fördel med att det är en stor koncern. När projektet startades upp fick alla Scrum Masters en inledande utbildning till Scrum som metod. Kunskapen de fick här förmedlades sedan vidare till resterande gruppmedlemmar. I övrigt tillgodoser organisationen reguljära utvecklingssamtal där eventuella kompetensutvecklande behov tas upp. Om fallet skulle vara att en individ behöver en viss kompetens försöker organisationen tillgodose detta, antingen genom att individen får böcker, eller att den får tillgång till kompetensutvecklande kurser (om vidare utbildning krävs). Respondent A tillägger här att medarbetarna i organisationen är öppna och att det nästan alltid finns någon man kan fråga om man behöver en hjälpande hand. Organisationen anser att inskolning är en viktig del under inlärningsprocessen och att de som behöver kan börja smått. Respondent C nämnde att det handlar om att ge alla en ”fair chance” att hinna komma in i projektet och området i fråga.
