Examensarbete

Johan Eriksson 2010-03-10 Ämne: Informationslogistik Nivå: Kandidat Kurskod: IL7903

Bättre med Scrum?

En studie om den ”nya” utvecklingsmodellen

Bättre med Scrum? En studie om den ”nya” systemutvecklngsmodellen

Kandidatuppsats i Informationslogistik (15 h p)

Författare: Eriksson, Johan

Examinator: Lindh, Jörgen

Handledare: Fagerström Kareld, Birgitta

Borlänge: Januari 2010

2

Abstract

The Thesis purpose is in the context of system development validate the Scrum Methodol-ogy. Projects concerning information technology are difficult to manage and tend to fail in quality, time or costs.

Scrum presents a new view of the system development. Better cooperation between cus-tomers and developers, continuous follow-up on daily basis and extensive communication in the development team are all characteristics of Scrum. Scrum is described as a new para-digm by its founders but has been criticized by experts of system development too.

This Thesis discuss if Scrum is a better way to develop software than older models like the Rational Unified Process and the Spiral Model with focus in five factors.

The result of the study is that Scrum has given system development new ways to manage requirements and methods to push the project forward. Lack of management commitment and user involvement can be better with Scrum if the model is used in the right way. An-swers concerning coding and testing differ between the respondents in the study which makes it different to make conclusions regarding this factor.

3

Sammanfattning

Syftet med uppsatsen är att i en systemutvecklingskontext beskriva de problem som gör att IT-projekt misslyckas och utvärdera om användningen av den agila utvecklingsmodellen Scrum reducerar problemen.

IT-projekt tenderar att misslyckas och de bakomliggande orsakerna är flera. Uppsatsen grupperar misslyckande av IT-projekt i fem faktorer. Ledningsstöd, användarmedverkan, projektstyrning, kravhantering samt kodning och test.

Scrum är en agil systemutvecklingsmodell som av sina skapare beskrivits som ett paradigm-skifte inom systemutvecklingen. Korta tidsintervaller, självgående systemutvecklare, daglig uppföljning är några av Scrums kännetecken.

För att besvara syftet har en kvalitativ datainsamlingsmetod använts. En intervjuserie med tio intervjuer och en observation ligger till grund för undersökningens resultat. All insamlad data är insamlad på fallföretaget Banverket Verksamhetsstöd IT.

Undersökningen har visat att Scrum ger en del nya angreppssätt främst avseende projekt-styrning och kravhantering. Scrum innehåller möjligheter för ökad användarmedverkan och ledningsstöd men det krävs konkreta åtgärder från projektorganisationen om det ska lyckas fullt ut. Uppfattningar kring kodning och test skiljer sig åt beroende på vilken respondent som frågas. Det tyder på att det saknas tydliga rutiner i det här avseendet.

Slutsatsen blir därmed att Scrum reducerar några av de problem som finns i IT-projekt och därmed med fördel kan användas som en best practice.

4

Förord

Uppsatsen är en kandidatuppsats i informatik med inriktning på Informationslogistik. Uppsatsen är för-fattad under höstterminen 2009 vid Centrum för informationslogistik i Ljungby och omfattar 15 hp. Upp-satsen är även till en viss del uppdragsstyrd av fallföretaget Banverket Verksamhetsstöd IT i Borlänge. Uppdraget handlar om att utvärdera Scrum som systemutvecklingsmodell.

Jag skulle vilja passa på att tacka några personer som hjälpt till under skrivandeprocessen.

- Birgitta Fagerström Kareld vid Linnéuniversitetet för handledning, litteraturförslag och stöd i skrivpro-cessen.

- Personalen på fallföretaget Banverket Verksamhetsstöd IT i Borlänge för möjlighet till empiriska stu-dier och förmånen att få skriva på plats.

- Ulla-Margarethe Carlsson vid Centrum för Informationslogistik för hjälp med litteratur.

- Jonas Högberg för meningsfulla diskussioner och många skratt under arbetets gång samt för hjälp med valideringshjälp av intervjufrågor.

- Klasskompisar på CIL för diskussioner och för valideringshjälp av utvärderingsfrågor.

Utan hjälp från ovan nämnda personer hade uppsatsen aldrig blivit vad den är idag.

Med detta sagt återstår bara att önska dig som läsare en trevlig läsupplevelse.

Johan Eriksson

Borlänge, Hösten 2009

5

Innehåll

1 Inledning ................................................................................... 8 1.1 Bakgrund............................................................................................8 1.2 Syfte .................................................................................................10 1.3 Frågeställning...................................................................................10 1.4 Disposition........................................................................................10 1.5 Definitioner .......................................................................................11

2 Metod....................................................................................... 12 2.1 Vetenskapligt förhållningssätt...........................................................12 2.2 Vetenskapligt angreppssätt ..............................................................12 2.3 Observation......................................................................................13 2.4 Intervju .............................................................................................13 2.5 Val av angreppssätt..........................................................................14 2.6 Relationen mellan teori och empiri ...................................................14 2.7 Idealtypisk eller situationell metodanalys .........................................15 2.8 Vetenskaplighet................................................................................16

3 Teori ........................................................................................ 17 3.1 IT-projekt ..........................................................................................17 3.2 Orsaker till misslyckade IT - projekt..................................................17

3.2.1 Ledningsstöd.............................................................................19 3.2.2 Användarmedverkan.................................................................19 3.2.3 Projektstyrning ..........................................................................20 3.2.4 Kravhantering............................................................................21 3.2.5 Kodning och test .......................................................................21

3.3 Systemutvecklingsmodeller ..............................................................23 3.3.1 Sekventiell utveckling................................................................23 3.3.2 Inkrementell utveckling .............................................................25 3.3.3 Iterativ utveckling ......................................................................25 3.3.4 Evolutionär systemutveckling....................................................27 3.3.5 Sammanfattning Systemutvecklingsmodeller............................28

3.4 Agile .................................................................................................29 3.5 Scrum...............................................................................................31

3.5.1 Roller ........................................................................................32 3.5.1.1 Scrum Master ...........................................................................................32 3.5.1.2 Product Owner .........................................................................................33 3.5.1.3 Scrum Team.............................................................................................33

3.5.2 Artefakter ..................................................................................34 3.5.2.1 Product Backlog .......................................................................................34 3.5.2.2 Sprint Backlog ..........................................................................................34 3.5.2.3 Burndown Chart .......................................................................................34

3.5.3 Ceremonier ...............................................................................35 3.5.3.1 Daily Scrum ..............................................................................................35 3.5.3.2 Sprint Planning Meeting ...........................................................................36 3.5.3.3 Sprint Review ...........................................................................................37

6

3.5.4 Test ...........................................................................................37 3.6 Avrundning av teorikapitlet ...............................................................38

4 Undersökning ......................................................................... 39 4.1 Presentation av fallföretag................................................................39 4.2 Observation......................................................................................39 4.3 Urval av intervjupersoner .................................................................40 4.4 Intervjuer ..........................................................................................40 4.5 Analysmodell ....................................................................................40

5 Resultat och Analys ............................................................... 42 5.1 Ledningsstöd....................................................................................42

5.1.1 Bättre med Scrum? ...................................................................44 5.2 Användarmedverkan ........................................................................45

5.2.1 Bättre med Scrum? ...................................................................46 5.3 Projektstyrning..................................................................................47

5.3.1 Bättre med Scrum .....................................................................50 5.4 Kravhantering...................................................................................52

5.4.1 Bättre med Scrum? ...................................................................54 5.5 Kodning och test...............................................................................56

5.5.1 Bättre med Scrum? ...................................................................57

6 Slutsatser och Reflektion....................................................... 59 6.1 Slutsatser .........................................................................................59

6.1.1 Väl underbyggda slutsatser.......................................................59 6.1.2 Indikationer ...............................................................................59

6.2 Sammanfattande värdering ..............................................................60 6.3 Förslag till fortsatt forskning .............................................................61 6.4 Reflektion .........................................................................................61

Litteraturförteckning.................................................................... 63 Böcker.........................................................................................................63 Vetenskapliga publikationer ........................................................................64 Tidningsartiklar ...........................................................................................65 Internetkällor ...............................................................................................65 Bilder ..........................................................................................................66

Bilaga 1 Observationsschema Sprint review och Sprint Planning........................................................................................... I

Bilaga 2 Intervjuguide Product Owner ........................................ III

Bilaga 3 Intervjuguide Systemutvecklare....................................VI

Bilaga 4 Intervjuguide Scrum Master ........................................VIII

Bilaga 5 Rules for Daily Scrum ....................................................XI

7

Figurförteckning Figur 1 Den deduktiva processen (Bryman & Bell, 2005)..................................15 Figur 2 Ramverk för kategorisering av risker (Keil et al, 1998)..........................18 Figur 3 Fem orsaker till misslyckade IT-projekt (Egen bild)...............................18 Figur 4 Sekventiell utveckling (Egen bild) .........................................................24 Figur 5 RUP (FCI Global, 2009) ........................................................................26 Figur 6 Spiralmodellen (Boehm, 1988)..............................................................28 Figur 7 Scrum (Sutherland, 2009) .....................................................................32 Figur 8 Burndown Chart (Moving Summit, 2009). .............................................35 Figur 9 Analysmodell (Egen bild) ......................................................................41 Figur 10 Resultatbild (Egen bild) .......................................................................60

Tabellförteckning Tabell 1 Sammanställning, Systemutvecklingsmodeller....................................28

8

1 Inledning

I inledningskapitlet presenteras undersökningens syfte och bakgrunden till det. Kapitlet innehåller även uppsatsens disposition samt definitioner av centrala begrepp.

1.1 Bakgrund

Informationslogistik handlar om att optimera informationsflöden för att styra och effekti-visera en verksamhet (Centrum för Informationslogistik, 2009). Ett verktyg för effektivise-ring är informationssystem. För att skapa väl fungerande informationssystem krävs arbets-sätt för nyutveckling och förvaltning.

Sedan 1970-talet har olika modeller för att utveckla informationssystem tagits fram, alla med ändamålet att bli bättre än sina föregångare. De senaste årens ökade konkurrens och allt mer omfattande globalisering har ställt krav på företagens sätt att organisera sina pro-cesser, vilket smittat av sig på informationssystemen (Brundin, 2009).

IT-projekt1 tenderar att misslyckas och orsakerna är flera, exempelvis dålig kunskap om projektarbete, otydliga kravspecifikationer (Hullberg, 2003) och bristande användarmed-verkan (The Standish group, 1995). Ett projekt förklaras som misslyckat när det inte lyckas följa den uppsatta tidsplanen, kvaliteten inte överensstämmer med vad som utlovats eller att budget har överstigits (Gustavsson, 2007). Enligt Jerräng (2009) misslyckas var tredje IT-projekt enligt ny forskning. Fler studier i ämnet visar liknande resultat och en historisk tillbakablick vittnar om mycket få framsteg under åren som gått (Jerräng, 2009).

För att rädda projekt på väg att misslyckas har flera åtgärder vidtagits, exempelvis snabba korrigeringar i tidsplaner, men utan att helt förlora kontrollen. Ett annat exempel är fler an-tal del-leveranser under projekttiden för att enklare genomföra stora förändringar. Att an-vända sig av åtgärder som räddat ett projekt även när det inte är kris är ett tankesätt som på senare tid smittat av sig på systemutvecklingsmodeller (Gustavsson, 2007).

Att föra in erfarenheter från tidigare projekt i arbetssättet har kontinuerligt skapat nya sy-stemutvecklingsmodeller (Gustavsson, 2007). eXtreme Programming (XP) och Scrum är två nya modeller som kritiserats och hyllats i branschtidningar och på internet. Kritik har riktats mot äldre modeller som exempelvis RUP (Rational Unified Process) då de anses vara dokumenttunga (Brundin, 2009), alltför fasinriktade samt att de till stor del består av planering (Cronholm, 2008). De agila modellerna sägs vara uppbyggda av positiva erfaren-heter från äldre systemutvecklingsmodeller. Negativa erfarenheter har tagits bort eller er-satts av något som ansetts bättre (Cronholm, 2008).

1 Begreppet innefattar systemutvecklingsprojekt, infrastrukturprojekt, upphandling av mjukvara, nätverksin-stallation, förvaltning av system och implementering av standardsystem. I uppsatsen avses endast systemut-vecklingsprojekt (Picatilu, 2007).

9

Scrum, som uppsatsen kommer att handla om beskrivs av Schwaber & Beedle (2002) som ett radikalt och annorlunda tillvägagångssätt för att utveckla informationssystem. Ord som anpassningsbarhet, produktivitet och flexibilitet sammankopplas ofta med modellen. Alltef-tersom förutsättningar förändras, behöver utvecklingsprocessen snabbt kunna svara på ex-empelvis förändrade krav.

I systemutvecklingens barndom fanns möjligheten att frysa kraven i arton månader, något som idag anses vara omöjligt (Brundin, 2009). De agila modellerna sägs föra med sig bättre kodkvalitet, färre buggar och en snabbare arbetsprocess. Tiden från idé till färdig produkt har kortats ner (Larsson, 2007). Sutherland (2008) påpekar att ett företag ökat sin produkti-vitet fem gånger som en följd av användandet av Scrum. En positiv faktor sägs också vara kostnadsreduceringar (Larsson, 2007). Kostnadsreduceringar med upp till 50 %, mindre de-fekter, roligare arbetssätt och bättre arbetsmiljö påpekas av Sutherland (2008) vara skäl till att använda Scrum till systemutvecklingsprojekt. Bättre funktionalitet och kodkvalitet kom-pletterar Larsson (2007) med.

Trots de agila systemutvecklingsmodellernas lovord och popularitet är det viktigt att kritiskt granska dessa modeller lika mycket som tidigare modeller granskats (Cronholm, 2008). I en tidningsartikel från november 2009 kritiseras Scrum för att vara alltför lättvindigt. Scrum har framställts som en snabb och enkel modell att använda och lära sig. Nyttan med model-len sägs däremot ligga i att tänka lättrörligt. Något som sägs vara betydligt mer komplicerat än Scrum (Stadigs, 2009). Enligt Brundin (2009) misslyckas nio av tio projekt som använt Scrum som modell för systemutveckling. Bristande helhetsbild, ineffektiva projektgrupper och en övertro till utbildningar i Scrum tros vara orsakerna.

Scrum innebär ett paradigmskifte inom systemutvecklingen avseende makt, kontroll, sam-arbete, dokumentation och kodning (Schwaber, 2004). Jacobsson (2009 A) anser däremot att de skillnader som finns mellan Scrum och äldre modeller är ringa. Scrum är en trend som är över inom ett par år. Jacobssons resonemang stärktes när Kent Beck, förespråkare för agila utvecklingsmodeller på en konferens talade om en trötthet på agil utveckling i USA. Beck menade att Scrum skapar religiösa figurer i organisationen och på sikt tröttnar utvecklarna på att dagligen prata om sitt arbete istället för att koda (Jacobsson, 2009 B). Ja-cobssons (2009 A) åsikt är istället att ta vara på de bra idéerna med Scrum och agile och använda det i befintlig arbetsmetodik.

I tidigare studier har Carlzon & Nilsson (2008) kommit fram till att en beställares positiva upplevelse av ett projekt kan härledas till användningen av en agil utvecklingsmodell. Kommunikationen mellan beställare och leverantör fungerar och möjligheten att förändra krav under utvecklingsprocessen finns. Carlzon & Nilsson (2008) har dragit slutsatsen att det finns ett samband mellan beställarens nöjdhet, det agila arbetssättet och det utvecklade systemet. Det går däremot inte att bevisa att ett system blir bättre med en agil utvecklings-modell. Däremot påvisar studien att de intervjuade beställarna både är nöjda med arbetssätt och med systemleveranser (Carlzon & Nilsson, 2008).

Weinhoff & Wirström (2009) har jämfört IT-projekt med byggprojekt och kommit fram till att IT-projekt behöver en egen utvecklingsmodell för projektarbete. Många IT-projekt är komplexa och svårplanerade och många frågor kommer upp under projektets gång. För att

10

förenkla planeringen kan projektet med fördel istället delas upp i iterationer med delmål och strävan mot en vision.

Att misslyckade IT-projekt sägs skapa nya och bättre systemutvecklingsmodeller och de olika uppfattningar som finns kring Scrum har väckt intresset för att utvärdera nyttan med Scrum. Schwaber & Beedles (2002) uppfattning om att Scrum är ett nytt radikalt tillväga-gångssätt torde innebära att flera av de problem som finns inom systemutveckling reduce-ras. Att ställa dessa ord mot exempelvis Jacobssons (2009 A) att Scrum är nya ord på gamla företeelser och bara är en trend har lett fram till följande syfte och frågeställning.

1.2 Syfte

Syftet med uppsatsen är att i en systemutvecklingskontext beskriva de problem som gör att IT-projekt misslyckas och utvärdera om användningen av den agila utvecklingsmodellen Scrum reducerar problemen.

1.3 Frågeställning

För att besvara syftet har jag valt att ställa följande forskningsfråga.

Kan problem i IT-projekt reduceras med hjälp av den agila utvecklingsmodellen Scrum?

1.4 Disposition

Kapitel 1 Inledning I kapitel 1 beskrivs uppsatsens bakgrund bestående av tidigare forskning, aktuella tidnings-artiklar, positiva och negativa utsagor om Scrum. Därefter presenteras syftet och forsk-ningsfrågan. Kapitlet innehåller även ett antal definitioner av centrala begrepp i uppsatsen.

Kapitel 2 Metod I kapitel 2 beskrivs de metodval som undersökningen grundar sig på. Förhållandet mellan teori och empiri diskuteras och kapitlet avrundas med en diskussion om undersökningens vetenskaplighet. Egna resonemang med stöd i metodlitteratur återges. ·

Kapitel 3 Teori I kapitel 3 beskrivs den teoretiska referensramen i uppsatsen. Teorin är uppdelad i tre om-råden. Först beskrivs IT-projekt och orsaker till misslyckande. Faktorerna för misslyckande presenteras under fem rubriker som jag definierat som kritiska faktorer för ett IT-projekt. Härefter ges en historisk tillbakablick över systemutvecklingen för att sätta in läsaren i rätt kontext. En förklaring till begreppet systemutvecklingsmodell ges och olika modeller be-skrivs. Därefter presenteras det agila synsättet och Scrum. Kapitlet avslutas med en kort av-rundning. Teorin är mestadels inhämtad från böcker och vetenskapliga artiklar.

Kapitel 4 Undersökning Kapitel 4 inleds med en kort beskrivning av fallföretaget. Därefter beskrivs det faktiska ge-nomförandet av intervjuer och observation. Undersökningskapitlet beskriver även urvalet

11

av intervjupersoner och introducerar även analysmodellen som används i det kommande analyskapitlet.

Kapitel 5 Resultat och Analys I kapitlet som heter Resultat och Analys beskrivs den empiriskt insamlade datan. Datan presenteras och analyseras enligt modellen som beskrivs i kapitel 4 med hjälp av teori som beskrivs i kapitel 3. För att läsaren ska lätt ska kunna följa med i resonemanget används de fem kritiska faktorerna för ett IT-projekt som huvudrubriker i kapitlet. Efter varje avsnitt ställs frågan om Scrum är bättre för att sammanfatta och lättare kunna spåra slutsatserna som presenteras i det kommande kapitlet.

Kapitel 6 Slutsatser och reflektion I kapitel 6 presenteras svaret på syfte och forskningsfrågan i form av par slutsatser och en sammanfattande värdering. I kapitlet presenteras även ett par förslag på fortsatt forskning samt en reflektion kring uppsatsarbetet.

1.5 Definitioner

Arkitektur är en benämning på den organisatoriska uppbyggnaden i ett datasystem som beskriver hur olika delar i systemet är kopplade till varandra och hur de samverkar (Pagina, 2009).

Fas är en delperiod av en modell där en viss aktivitet genomförs exempelvis testfas eller designfas (Eriksson, 2007).

Iteration är ett utvecklingsvarv som består av ett antal faser såsom krav, design, konstruk-tion och test (Eriksson, 2007).

Metod avser en vägledning för hur arbetet ska utföras i respektive modellfas (Karlsson, 1997).

Modell avser övergripande struktur i ett antal faser och som beskriver vad som ska göras i respektive fas (Karlsson, 1997).

Sprint är en tidsbestämd period som Scrum Team (se 3.5.1.3) arbetar i (Schwaber & Beed-le, 2002).

12

2 Metod

Kapitlet metod beskriver undersökningens metod. Det börjar med vetenskapligt förhållningssätt och fortsät-ter vidare in på forskningsansatsen och avslutas med en diskussion om undersökningen vetenskaplighet.

2.1 Vetenskapligt förhållningssätt

Uppsatsens frågeställning är om Scrum kan lösa de problem som finns i IT-projekt. Syftet är att utvärdera utvecklingsmodellen Scrum utifrån de vanligaste problemen och undersöka om den kan reducera problemen.

Min undersökning bedrivs med ett hermeneutiskt synsätt. Min uppfattning om verkligheten är att det inte räcker att tro på vad människor säger utan också hur de framför sina åsikter.

Hermeneutik kan översättas till tolkningslära och har ursprung i bibeln och annan texttolk-ning. Tolkning är brett och omfattar allt från symboler till att förstå ett meddelande trots störningar som språkfel och missuppfattningar. Tolkning innebär också att visa på inne-börder som ligger bakom ett fenomen och fångas genom att studera hur respondenter framför sina åsikter i exempelvis en intervju (Wallén, 1996).

Motsatsen till hermeneutik är positivism som istället menar att kunskap endast är verklig om den kan bevisas empiriskt. Människan framställs i den positivistiska skolan som ett ob-jekt och utesluter känslor som individen visar (Wallén, 1996).

Att studera människors beteende ställer krav på mig som forskare att kunna urskilja san-ningshalten i det som en intervjuperson uppger eftersom en del frågor kan uppfattas som kritiska till personens arbete. Förhållningssättet hos forskaren torde i detta fall vara herme-neutiskt.

2.2 Vetenskapligt angreppssätt

En kvalitativ undersökning syftar till att se forskningsområdet ur den intervjuades perspek-tiv (Kvale, 1997). En kvalitativ undersökning passar bäst när forskaren är intresserad av att skapa klarhet kring ett begrepp eller fenomen. Den kvalitativa ansatsen ger djup förståelse och en helhetsbild av det studerade fenomenet (Jacobsen, 2002).

Den vanligaste formen vid en kvalitativ undersökning är intervjuer. Intervjuer kan ha olika grad av struktur och olika antal respondenter (Jacobsen, 2002).

Kvalitativa studiers nackdelar är att de är resurskrävande och tar lång tid. Metoden har be-kymmer med generalisering externt till skillnad från kvantitativa metoder som har det som en av sina styrkor. Det kan även vara svårt att i en kvalitativ undersökning tolka det som framkommer då nyanser i svar kan variera mycket (Jacobsen, 2002).

Jacobsen (2002) hävdar även att forskaren lätt kan bli ”en i gänget” när ett fenomen stude-ras med den närhet som den kvalitativa metoden förespråkar. Förmågan att tänka kritiskt

13

kan rubbas. Däremot kan en större närhet till det som studeras göra att fler personer vågar öppna sig och vågar uttrycka sina åsikter kring det som studeras.

Debatt om närhet eller distans förekommer ofta inom forskningsmetodik. Distans gör forskningen sämre enligt Jacobsen (2002) och istället bör forskning genomföras på så jäm-lika förhållanden som möjligt. Det är först när ett jämlikt förhållande uppstår som vissa re-spondenter öppnar sig och vågar framföra sina åsikter. När fler vågar framföra sina åsikter uppstår även en djupare förståelse kring det studerade fenomenet. Problemet är att en allt för stor närhet till det studerade kan leda till att forskarens förmåga att tänka kritiskt rubbas (Jacobsen, 2002).

Att studera ett fenomen med en alltför stor närhet försämrar studiens möjlighet till repli-cerbarhet. Replicerbarhet handlar om att en annan forskare ska kunna genomföra samma undersökning och få samma resultat (Jacobsen, 2002).

2.3 Observation

Observation handlar om att betrakta personer i en naturlig kontext. Styrkan i en observa-tion är att forskaren ser vad personer faktiskt gör istället för det de påstår sig att göra i en intervju. Observation kan göras dolt eller öppet. Dold observation har fördelen att indivi-der inte vet att de blir observerade och kan då uppträda normalt. Personer som vet om att de är observerade kan ändra beteende eftersom de kan vara nervösa (Jacobsen, 2002).

Observation kan ske både deltagande och ickedeltagande. En deltagande observation är att föredra om undersökningen ämnar undersöka vad som sker i en viss grupp en viss tid. Ob-servation sägs vara förenat med en stor risk att forskaren påverkar resultatet starkt vilket minskar tillförlitligheten till den insamlade datan (Jacobsen, 2002).

Vid observation ska s.k. fältanteckningar göras. Intryck ska skrivas ner direkt när något in-tressant yttras. Fullständiga noteringar ska göras mot slutet av observationen. Anteckningar ska göras tydligt och levande för att forskaren ska veta vad som menas med specifika ut-tryck. Fältanteckningar klassificeras i tre olika typer: mentala, preliminära och fullständiga. De mentala är det som memorerats i minnet på forskaren. De preliminära anteckningarna är korta noteringar som skrivs ner för att skapa en minnesbild. Fullständiga anteckningar är de anteckningar som ska sammanställas efter observationen. Både reaktioner och den miljö som studerats ska tas med (Bryman & Bell, 2005).

2.4 Intervju

En intervju passar bra när få enheter undersöks och när intresset är att lyssna till den en-skilda individens tolkning av ett fenomen. En intervju ansikte mot ansikte sägs ge en större trygghet för den som intervjuas. Den intervjuade har en förmåga att tala mer sanningsenligt än vid exempelvis en telefonintervju. Att tillämpa en personlig intervju ger också en möj-lighet att kunna observera den intervjuade under samtalet (Jacobsen, 2002).

14

Intervjuer kan ha olika grad av struktur, alltifrån att öppet samtal utan begränsningar till ett fördefinierat frågeformulär. En bra intervju bör vara en noga avvägning mellan strukture-rad och ostrukturerad (Jacobsen, 2002).

Att spela in intervjuer gör att intervjuaren i en större utsträckning kan fokusera på samtalet istället för att dokumentera. Intervjuaren bör däremot göra enklare stödanteckningar för att lättare kunna hitta höjdpunkter i inspelningen. Inspelning gör även att det blir enklare att få med direkta citat från intervjun till studien. Däremot kan vissa personer bli stressade av bandspelaren och kan bli tystlåtna. Att tänka på är att även tekniska problem kan innebära en risk när intervjuer spelas in (Jacobsen, 2002).

2.5 Val av angreppssätt

Eftersom syftet med uppsatsen är att utvärdera en modell bygger analysen på olika perso-ners erfarenheter och åsikter av modellen. Åsikter är svårt att få fram i en enkät och därför har valet fallit på en kvalitativ studie med intervjuer och observation som datainsamlings-metod. Insamlingen av data beskrivs mer detaljerat i Kapitel 4 Undersökning.

2.6 Relationen mellan teori och empiri

Undersökningen är gjord med en deduktiv ansats. Arbetsgången i en deduktiv process är att först studera teori kring ett fenomen för att sedan beskriva verkligheten kring detsam-ma. Deduktiv ansats rekommenderas när forskaren vill ha individens syn på klart definiera-de områden och där syftet är utformat för att ställa olika begrepp mot varandra. Kritik har framkommit mot deduktion då det anses vara en slags självuppfyllande profetia då forska-ren beskriver bara det som denne tycker är relevant. En annan farhåga är att tolkning sker i alltför många steg. Resultatet kan då bli att forskarens bild av verkligheten testas istället för respondenternas bild av den samma. Forskaren ska för att undvika detta fenomen uppfylla relevans för sin undersökning (Jacobsen, 2002).

Bryman och Bell (2005) beskriver deduktion i en process i sex steg. Utgångspunkten är teo-rin. Utifrån teorin sätter forskaren upp ett antal hypoteser. Därefter samlas den empiriska datan in och analyseras fram till ett resultat. Utifrån resultatet kan hypoteserna bekräftas el-ler förkastas och därefter kan en revidering eller förstärkning av teorin genomföras. Figur 1 på nästa sida beskriver den deduktiva processen med en bild.

15

Figur 1 Den deduktiva processen (Bryman & Bell, 2005)

Motsatsen, den induktiva ansatsen innebär att forskaren först samlar in empirisk data och sedan försöker strukturera den med hjälp av teori. Svårigheten ligger i att kunna se på ett fenomen utan någon som helst uppfattning om det innan. Den induktiva ansatsen har en tolkningsnivå mindre än den deduktiva eftersom deduktion innefattar litteratururval innan den empiriska datainsamlingen. Detta första urval är unikt för deduktion och sägs ge längre distans till verkligheten än induktion (Jacobsen, 2002).

Eftersom syftet är att ta reda på om problemen i IT-projekt kan reduceras bör undersök-ningen börja med en deduktiv datainsamlingsmetod för att kunna förstå de problem som gör att IT-projekt misslyckas. För att sedan kunna ställa frågor kring hur modellen faktiskt används och fungerar behöver även sekundärdata om modellen samlas in. Därefter ska det empiriska materialet samlas in och jämföras med teorin.

2.7 Idealtypisk eller situationell metodanalys

När en systemutvecklingsmodell ska utvärderas är det av vikt att känna till att det finns två synsätt på metodanalys. Den idealtypiska metodanalysen utgår helt från teorin kring model-len i exempelvis handböcker och analyserar den. Den situationella metodanalysen utgår istället ifrån hur modellen faktiskt används (Karlsson, 1997). I uppsatsen beskrivs modellen idealtypiskt i teorin men det är den situationella metodanalysen som beskrivs i resultat och analys.

Teori

Hypoterser

Datainsamling

Resultat

Hypoteser bekräftas eller förkastas

Teorin revideras

16

2.8 Vetenskaplighet

Med reliabilitet avses undersökningens tillförlitlighet och trovärdighet. Ett bra mått på tro-värdighet i undersökningen är att kunna få fram samma resultat vid en exakt likadan under-sökning igen (Jacobsen, 2002).

Reliabilitet är svårt att uppnå i en kvalitativ studie. En intervju är svår att göra om i exakt samma kontext av en annan forskare. För att kvalitetssäkra intervjuerna har jag dels valide-rat intervjufrågorna innan intervjuer och även spelat in på diktafon för att minimera risken för missförstånd. För att stärka trovärdigheten finns i bilagorna samtliga intervjufrågor (Bi-laga 2-4). Att jag redan känner personerna på fallföretaget som intervjuats kan ses som en faktor som gör att det blir ännu svårare att upp nå replicerbarhet. Jag vill däremot hävda att det även har varit till fördel då respondenterna enklare kunnat öppna sig och dela med sig av åsikter.

I kvalitativa studier är det istället validitet, dvs. giltighet som är viktigt. Validiteten delas in i intern och extern giltighet. Intern validitet avser att ta ställning till att det som mätts är kor-rekt och att slutsatserna är korrekta utefter det (Jacobsen, 2002).

Den interna giltigheten i studien stärks då flera respondenter i olika projekt intervjuats och flera personer i olika roller har intervjuats. Att intervjua flera personer i olika roller stärker slutsatserna och undersökningens inre validitet. Fenomenet kallas källtriangulering (Malte-sare, 1998). Undersökningen har även triangulerings i metoden med en observation vilket ytterligare stärker validiteten (Maltesare, 1998). Urvalet av intervjupersoner är en av under-sökningens styrkor då endast ett fåtal personer på fallföretaget arbetar enligt Scrum. Urvalet beskrivs i kapitel 4, där också intervjuerna beskrivs. För att stärka den interna giltigheten finns intervjufrågorna med som bilagor (Bilaga 2-4).

Metodtriangulering och källtriangulering har redan nämnts som faktorer som ökar validite-ten i uppsatsen. Det finns ytterligare en typ av triangulering som stärker validiteten på den här undersökningen. Teoritriangulering innebär att se på ett fenomen utifrån flera perspek-tiv (Malterud, 1998). Uppsatsen utvärderar Scrum efter fem olika faktorer som kan ses som fem olika perspektiv.

Extern giltighet handlar om undersökningens giltighet i andra sammanhang. Den externa giltigheten är hög om det går att föra över de slutsatser som dragits från ett företag till ett annat (Jacobsen, 2002).

Undersökningen anser jag vara externt giltig då utgångspunkten är generella problem och en generell modell. Verksamheter som använder sig av Scrum eller funderar på det kan ta till sig goda erfarenheter från undersökningen, men också få svar på om Scrum kommer motsvara de förväntningar som finns på Scrum.

17

3 Teori

Teorin är uppdelad i tre delar där den första beskriver de problem som finns med IT-projekt för att bygga upp en analysmodell. Den andra delen består av teori kring systemutvecklingsmodeller för att sätta in läsa-ren i rätt kontext. Slutligen introduceras Agitera och Scrum.

3.1 IT-projekt

Projekt är en arbetsform med en tydlig avgränsning i tiden. Ett projekt kännetecknas av en unik uppgift och att organisationen är tillfällig (Landquist, 2006). Projektarbetsformen an-vänds när en engångsuppgift som kräver olika slags kompetens ska genomföras (Andersen, 1994).

Traditionella projektledningsmetoder har sitt ursprung från Kalla krigets dagar då NATO och Warsavapakten tävlade mot varandra i att vara klar med försvarsvapen. Målet var att vara klar snabbast möjligt med en kort ledtid2. För att korta ledtiden togs verktyg fram för koordinering av fler aktiviteter parallellt och med ett resursantal på upp till 20 000 perso-ner. Dagens projekt är betydligt mindre och omfattar vanligen mindre än tio personer (Gustavsson, 2007).

Ett informationssystem är en samling objekt som är förbundna med varandra och har till uppgift att samla in, lagra, behandla och distribuera information (Kansler, 1990). Systemut-veckling är vetenskapen om människors arbete med att utveckla och förändra datorbasera-de informationssystem i en verksamhet (Karlsson, 1997).

Systemutvecklingsuppgifter har de drag som ett projekt kännetecknas av. Det finns ett tyd-ligt mål med systemutvecklingen och gruppen känner till vad som ska utvecklas inom ra-men för projektet. Verksamheten kan tidigare ha utvecklat informationssystem, men olika frågeställningar och användare utgör en skillnad mellan utveckling av exempelvis lagerhan-teringssystem och bokföringssystem (Andersen, 1994).

En verksamhet som ska utveckla ett informationssystem står även inför en unik engångs-uppgift. Därför är det inte aktuellt med en särskild enhet i företaget för denna typ av upp-gifter. Flera kategorier av medarbetare ska involveras i projektet. Genom att tillämpa ar-betsformen projekt för systemutveckling skapas möjligheter till enkel fördelning och dis-kussion av arbetsuppgifter (Andersen, 1994).

3.2 Orsaker till misslyckade IT - projekt

Ett IT-projekt bedöms som misslyckat om det överstiger budget, överskrider tidsplanen el-ler inte lever upp till den efterfrågade funktionaliteten (Hinde, 2005).

2 Ledtid är tiden mellan projektstart och projektavslut (Gustavsson, 2007).

18

Keil, Cule, Lyytinen och Schmidt (1998) menar att de viktigaste riskerna faller utanför pro-jektledarens mandat och direkta kontroll. För att visualisera detta fenomen beskrivs riskka-tegorisering av IT-projekt som en fyrfältsmatris (se Figur 2). Faktorerna i matrisen är upp-levd betydelse och upplevd kontrollnivå. Upplevd betydelse avser en kombination av risk-frekvens och riskpåverkan och upplevd kontrollnivå avser i hur stor omfattning projektle-daren kan påverka att riskerna inte uppkommer.

Figur 2 Ramverk för kategorisering av risker (Keil et al, 1998).

Customer Mandate handlar om att skapa delaktighet både bland ledning och bland användar-na. De projekt som lyckas bäst är de som bäst lyckas förankra nyttan hos både ledning och slutanvändare.

Scope and Requirements handlar om de risker som uppstår vid ett projekts etablering. Krav-hantering och prioritering av krav är centralt där kunden och projektledaren ska förstå var-andra.

Execution är det faktiska utförandet av projektet. När rätt krav har identifierats måste även personalen kunna utföra arbetet. Rätt mängd och rätt kompetens är av vikt för att lyckas.

Environment inbegriper faktorer både innanför och utanför projektens avgränsning. Det handlar om att projektledaren ska ha vetskap om vilka händelser som kan påverka projek-tets resultat (Keil et al, 1998).

Andra författare både styrker och utvecklar resonemanget som Keil et al (1998) tagit fram. Jag har valt att sammanfatta övriga författares uppfattningar om misslyckande inom IT-projekt i fem faktorer. Faktorerna beskrivs med Figur 3.

Figur 3 Fem orsaker till misslyckade IT-projekt (Egen bild)

19

3.2.1 Ledningsstöd

Stöd från ledning beskrivs som den faktor som enligt Keil et al (1998) är viktigast i ett IT-projekt. Författarna anser att ledningsstöd inte är ett tillräckligt bra ord och istället används termen ledningsengagemang (Top Management Commitment). Ledningen ska uppvisa en-gagemang i hela utvecklingsprocessen och ha en aktiv roll systemutvecklingen.

Även The Standish Group (1995) tar upp ledningsstöd som en faktor för misslyckande för IT-projekt. Ledningsstöd är även den näst största framgångsfaktorn för ett lyckat IT-projekt enligt samma rapport.

Hullberg (2003) menar att affärsledningens kompetens är avgörande för om ett IT-projekt ska lyckas eller inte. Ett IT-projekt sträcker sig ofta över flera verksamhetsområden vilket gör att det är svårt att definiera vem i organisationen som är produktägare. Ansvaret läggs då högt upp i organisationen hos någon som varken har tid eller kompetens nog att styra projektet.

Uppskattning av tid är ett problem i IT-projekt. Ledningen är dålig på att uppskatta den tid det faktiskt tar att driva ett IT-projekt. Engagemanget blir lågt och den operativa verksam-heten prioriteras högre än IT-projektet. Följden blir en underbemanning av IT-projektet (Hullberg, 2003).

Hullberg (2003) menar att IT-projekt har tendenser till att bli självuppfyllande profetior. Ledningen går tidigt ut med att ett informationssystem ska utvecklas och implementeras och skyhöga besparingar utlovas. Behoven fastställs inte helt utan ledningen tror på ett specifikt system. Ofta misslyckas ledningen med förankring av nyttan med systemet hos slutanvändarna och i och med detta saknas en formell acceptans från slutanvändarna. Sy-stemet blir då bara formellt accepterat av ledningen och inte av dem som faktiskt ska an-vända systemet (Hullberg, 2003).

Hullberg (2003) beskriver även dålig projektuppföljning som en orsak till misslyckade IT-projekt. Uppföljning är svårt delvis på grund av dåliga kravspecifikationer. Om det däremot finns en kravspecifikation kan problemet istället vara att avvikelser i en projektplan upp-täcks för sent eftersom den som ska följa upp projektet sitter för högt upp i organisationen. Då uppstår ett glapp mellan projektledare och produktägaren vilket kan leda till att projek-tet styr sig själv och slutar i ett misslyckande (Hullberg, 2003).

3.2.2 Användarmedverkan

Den största orsaken till misslyckade IT-projekt är enligt The Standish Group (1995) bristen på användarmedverkan. Det är även användarmedverkan som beskrivs som den största framgångsfaktorn för IT-projekt enligt samma rapport (The Standish Group, 1995).

Keil et al (1998) menar att användarengagemang är av vikt för att lyckas med IT-projekt. Att involvera användare redan i arbetet med kravhantering gör att de får en känsla av ägan-de vilket minskar risken för motstånd vid implementering. Keil et al (1998) menar också att engagemang från medarbetare kan kompensera dåligt engagemang från ledning. Användar-na känner till verksamhetens processer och vet vilken funktionalitet systemet behöver in-

20

nehålla. Utan medverkan från användarna riskerar projektet att inte uppfylla sitt ursprungli-ga syfte (Keil et al, 1998).

Gulliksen & Göransson (2002) poängterar en aktiv användarmedverkan i hela systemets livscykel. Användare ska involveras både innanför projektets ramar men också utanför. Det är av vikt att skilja på domänexperter och slutanvändare. Domänexperter är de som är väl insatta i verksamheten medan slutanvändarna är de som ska använda det färdiga systemet. Det är av vikt att rätt användare deltar vid rätt tillfälle. Omfattande arbete ska därför läggas på att arbeta med urval av användare (Gulliksen & Göransson, 2002).

3.2.3 Projektstyrning

Whittaker (1999) menar att den största felkällan till misslyckade IT-projekt är bristfällig projektplanering och dålig förankring av olika projekts nytta. Whittaker (1999) menar att fel i teknik, ofullständig mjukvara, fel i kravspecifikationer och underskattning av risker inte alls är lika förekommande felorsaker.

Hullberg (2003) anser att ett vanligt fel i IT-projekt är att rollfördelningen mellan beställare och systemleverantör är otydlig. Ansvarsfrågan är sällan tydliggjord från början och det får effekter i hela projektet.

Det ultimata i ett projekt ska vara att kunna sätta samman en projektgrupp med de bästa resurserna för att lösa en specifik uppgift. Ofta finns däremot inte de resurser som projekt-ledaren behöver tillgängliga och istället bemannas projektet utifrån tillgängliga resurser (Hullberg, 2003).

Kunskap om att bedriva projekt är avgörande för att lyckas med ett IT-projekt. Erfarenhet och kompetens krävs när komplexa IT-projekt ska styras. Det som ofta underskattas är verksamhetskompetensen som i många fall är viktigare än kompetensen kring IT. Kunskap om slutanvändarnas arbetsuppgifter och rutiner är avgörande för att projektet ska bli en framgång (Hullberg, 2003).

Projektledarens kompetens är en bidragande orsak till projektets framgång eller misslyck-ande. Ansvaret för genomförandet av projektet ligger helt på projektledaren som ibland också får ta itu med frågor som egentligen ligger inom produktägarens ansvarsområde. Följden blir att projektledaren kan bli överbelastad och inte lyckas styra projektet mot det uppsatta målet. Projektledning är en svår kompetens att behärska och om en projektledare blir utarbetad blir det svårt att hitta en fullvärdig ersättare (Hullberg, 2003).

Problem finns även med åtgärder som inte vidtas direkt. Projektgruppen håller sams efter-som det sägs att god sammanhållning i gruppen ger ett lyckat projekt. Att ställa krav och reagera negativt upplevs som att förstöra stämningen i gruppen och gör att projektdeltagare och projektledare istället utgår från att problemen löser sig av sig själva och skjuter proble-men framför sig hellre än att ta tag i problemen. Eftersom förutsättningarna ständigt för-ändras är det av vikt att följa upp de förändringar och problem som uppkommer under projektets gång. Problem ska ställas mot konsekvenser för projektets intressenter och mot inverkan på budget och tidsplan (Hullberg, 2003).

21

Tidspress är en faktor som kan påverka ett IT-projekt negativt. Systemleverantören kan uppleva en tidspress över att förhandlingar drar ut på tiden. Systemleverantören är angelä-gen om att knyta kunden till sig och gör allt för att få till ett avtal. Avtalet hetsas fram efter-som systemleverantören tror att mer tydliga riktlinjer ska arbetas fram senare i projektet. Tidspress förekommer också från beställarorganisationen som kan uppleva en stress över att projektet överstiger gällande tidsplan (Hullberg, 2003).

3.2.4 Kravhantering

”Kravhantering är en uppsättning aktiviteter som omfattar insamling, dokumentation, prioritering, struk-turering, kvalitetssäkring och förvaltning av krav för ett IT-system” (Eriksson, 2007 s 22).

The Standish Group (1995) menar att ofullständiga kravspecifikationer och förändrade krav är en bidragande orsak till IT-projekts misslyckande. Hullberg (2003) menar att krav-specifikationer ofta är dåligt utformade. Kraven är för övergripande och kan t.o.m. saknas helt. Följden blir att systemleverantören får svårt att kunna leverera en programvara som motsvarar kundens förväntningar (Hullberg, 2003).

Whittaker (1999) menar att missförstånd i kraven är en bidragande faktor till att IT-projekt misslyckas. Eriksson (2007) menar att beställare kan ha svårt att uttrycka sina önskemål på systemet vilket gör att utvecklarna får problem med att förstå beställarens krav. Då uppstår missförstånd som i längden kan leda till utveckling av helt andra funktioner än vad som är angivet i kravspecifikationen (Eriksson, 2007).

Tidsbrist får till följd att olika personer gör fel (Eriksson, 2004). Eriksson (2004) refererar till en undersökning av Martin som undersökt källorna till fel i IT-system och kommit fram till att den största felkällan i IT-system är arbetet kring kravhantering. Fel krav samlas in med fel metoder och av fel personer. Projektets slutresultat blir då att informationssystemet inte motsvarar beställarens ursprungliga önskemål på informationssystemet.

Fel och brister i kraven är kostsamt att åtgärda. Det är av vikt att göra detta tidigt i projek-tet eftersom fel blir dyrare att åtgärda ju senare de påträffas. För att ta fram bra krav poäng-teras användarmedverkan tidigt samt granskning av dokumentation. Att använda sig av prototyper kan också vara ett verktyg för kvalitetssäkring av krav (Eriksson, 2007).

3.2.5 Kodning och test

Bristande testning beskrivs ofta som ett fel i IT-projekt. Tester görs inte på rätt sätt. Redan från början kan det bli bekymmer om testfallen innehåller fel. Tester görs ofta av personer som är kunniga i systemet vilket gör att testarna vet hur de ska hantera mjukvaran. Med denna testmetod hittas inte alla fel i informationssystemet (Eriksson, 2004).

Dåliga felrapporter från testarna gör också att testerna brister. Brister i testdokumentatio-nen leder till att en systemutvecklare inte vet vad som ska åtgärdas. Traditionellt ligger test sent i systemutvecklingsprocessen. Är projektet försenat kan det därför hända att test inte

22

hinns med i den utsträckning som det är planerat för. Felen upptäcks då sent och kan i värsta fall inte hinna korrigeras innan driftsättning3 (Eriksson, 2004).

Fel kan även uppstå i den faktiska systemutvecklingen. Felaktighet i kod korrigeras efter test men kan ändå innehålla fel när systemet levereras. En annan felkälla är det faktum att utvecklarna programmerar fel och det inte upptäcks (Eriksson, 2004).

3 Med begreppet driftsättning avses att implementera ett system i verksamheten (egen definition).

23

3.3 Systemutvecklingsmodeller

Efter att ha resonerat kring orsaker till IT-projekts misslyckande beskrivs nu systemutveckling i ett histo-riskt perspektiv för att sätta in läsaren i en systemutvecklingskontext.

De första informationssystemen utvecklades på 1960-talet utan stöd av någon speciell mo-dell. Vid denna tid var användarmedverkan vid utveckling av informationssystem låg, pro-jekten var ständigt sena och förändringar i systemen undveks eftersom korrigering av fel orsakade nya fel i systemen. Med tiden blev informationssystem en mer naturlig del i var-dagen och den ad hoc-mässiga situationen vid systemutveckling blev till slut ohållbar (Avi-son & Fitzgerald, 2006).

Lösningen på problemen blev att implementera standardiserade arbetssätt för utveckling av informationssystem, dvs. systemutvecklingsmodeller (Avison & Fitzgerald, 2006). En sy-stemutvecklingsmodell beskrivs av Fagerström (2003) som ett koncept för utveckling av ett IT-system. En modell består av ett antal fördefinierade steg som ska lösa olika uppgifter i arbetet. Systemutvecklingsmodellens syfte är att utveckla ett informationssystem av god kvalitet (Fagerström, 2003). Syftet är också att föreskriva ordningen mellan de olika stadier som ingår i utvecklingen samt ange de kriterier som är avgörande för att övergå från ett stadie till ett annat (Boehm, 1988). De olika modeller som finns att tillgå skiljer sig åt avse-ende omfattning i arbete, roller och antalet timmar som spenderas på olika faser i modeller (Eriksson, 2007).

Eftersom systemutveckling genomförs i projektform ges en valmöjlighet för dem som ut-vecklar systemutvecklingsmodeller om projektstyrning ska inkluderas eller bortses. Att kombinera projektstyrning med systemutveckling fungerar enklast om de viktigaste händel-serna i systemutvecklingen fungerar som kontrollpunkter. Svårigheten uppstår om projekt-styrningen vill ha andra kontrollpunkter än de som anses viktiga i systemutvecklingen, vil-ket inte är ovanligt (Andersen, 1994).

3.3.1 Sekventiell utveckling

Sekventiell systemutveckling eller vattenfallsutveckling handlar om att utveckla system i en sekvens. Modellen består av ett antal faser där systemutvecklingen går från en fas till nästa. Ett exempel kan vara Analys-Design-Konstruktion-Test (Eriksson, 2007). Sekventiell ut-veckling kan beskrivas med bilden Figur 4.

24

Figur 4 Sekventiell utveckling (Egen bild)

Vattenfallsmodellen beskriver ett systems livscykel från förstudie till utvärdering av syste-met (Avison & Fitzgerald, 2006). Idén med vattenfallsmodellen är att aldrig behöva gå mot strömmen vattenfallet utan istället skapa slutgiltiga resultat i varje fas. De krav som tas fram ska exempelvis vara fastställda innan designen kan påbörjas. Bekymret med denna metodik är att mycket tid läggs på att skapa perfekta krav och när systemutvecklingsprojektet når slutskedet inser projektgruppen att systemet som utvecklats inte längre lever upp till de ställda förväntningarna. Risken finns också att allvarliga fel upptäcks i slutet av projektet i testfasen och färden uppåt i vattenfallet blir därför kostsam (Eriksson, 2007).

Fördelarna med en sekventiell utveckling är framförallt noggrannheten i arbetet. Med detta arbetssätt säkerställs utbildning, dokumentation och kommunikation till intressenter och användare eftersom det ligger i egna faser. Möjligheterna för kontroll ökar också i och med uppdelningen i olika faser (Avison & Fitzgerald, 2006).

Nackdelarna med denna typ utveckling är svårigheten med att följa en styrd arbetsgång för processförändring när processerna ständigt är under förändring. Modellen anses även inte vara tillräckligt flexibel. Eftersom det tidigt beslutas över resultatet kan förändrade krav bli en dyr historia (Avison & Fitzgerald, 2006). Test kommer in sent i utvecklingsprocessen och gör att de fel som behöver korrigeras blir både svåra och dyra att genomföra (Eriksson, 2007).

I en sekventiell utvecklingsmodell involveras användaren tidigt i samband med kravställ-ningen. Därefter upphör kontakten fram till implementeringsfasen. Då uppstår en risk i att användarna vägrar använda det levererade systemet eftersom det inte längre motsvarar de förväntningar som angavs vid kravhanteringen. Ytterligare ett problem är att utvecklingen är tidskrävande. Tiden från ursprunglig förfrågan till slutlig leverans av det utvecklade in-formationssystemet kan vara flera år (Avison & Fitzgerald, 2006).

25

3.3.2 Inkrementell utveckling

Enligt de inkrementella utvecklingsmodellerna ska arkitektur utvecklas först. Därefter ut-vecklas mindre delar i s.k. inkrement. Varje inkrement har en egen livscykel som påminner om de steg som finns i de sekventiella systemutvecklingsmodellerna.

Fördelarna med denna utveckling är att projektet styckas upp i mindre delar och blir mer hanterbart framförallt gällande styrning och test. Samtliga krav på informationssystemet behöver inte samlas in initialt. Inför varje nytt inkrement kan nya krav samlas in och befint-liga krav kan förändras. Ett arbetssätt med mindre omfattande och mer frekventa leveran-ser tillåter användarna att komma med fler synpunkter om det slutliga informationssyste-met till skillnad från om det skulle ha levererats som en enda del (Gulliksen & Göransson, 2002).

3.3.3 Iterativ utveckling

Ordet iterativ betyder repeterbar. Synsättet i iterativa modeller är att det inte går att göra rätt i början av projektet eftersom det är först när det grävs djupare som de verkliga pro-blemen hittas. Systemutvecklarna måste ständigt vara beredda på att ompröva sina lösning-ar för att få fram den bästa (Gulliksen & Göransson, 2002). Fördelen med att jobba itera-tivt blir framförallt en snabb återkoppling från användare som gör att informationssystemet lättare kan uppfylla organisationens krav. Förändringar i kraven förekommer och med ett iterativt arbetssätt hanteras kraven på ett enkelt sätt. En ytterligare fördel är att arbetet får ett bättre driv framåt till skillnad från ett sekventiellt utvecklingsprojekt där arbetet långa stunder kan gå på låg intensitet eftersom projektöverlämnandet ligger längre fram i tiden (Eriksson, 2007).

Ett exempel på en iterativ systemutvecklingsmodell är RUP (Rational Unified Process). Modellen utvecklades i slutet av 1980-talet och beskrivs som en användningsfallsdriven, ar-kitekturcentraliserad, iterativ och inkrementell utvecklingsprocess. RUP består av ett antal faser, iterationer och discipliner som tillsammans skapar ett färdigt informationssystem (Gulliksen & Göransson, 2002) och är uppbyggt av Best Practices från systemutvecklings-projekt (Kruchten, 2004). Faserna är fyra stycken förberedelse (inception), utredning (ela-boration), konstruktion (construction) och överlämning (transition) (Avison & Fitzgerald, 2006, Gulliksen & Göransson, 2002). Varje fas består av arbete i ett antal discipliner eller aktiviteter såsom kravhantering, utveckling och test. Betoningen på hur mycket arbete ska göras i varje disciplin i respektive iteration visualiseras i modellen med tjockare respektive smalare linjer. RUP visualiseras enligt bilden Figur 5.

26

Figur 5 RUP (FCI Global, 2009)

De två största skillnaderna mellan RUP och sekventiell systemutveckling är det iterativa angreppssättet och ett annorlunda angreppssätt avseende kravhantering. Det iterativa an-greppssättet och förändrade krav sägs ge bättre IT-projekt i flera avseenden enligt Kruch-ten (2004).

• Att tillämpa förändrade krav ger nöjdare kunder, mindre frustrerade systemutvecklare och att projekten bättre håller tiden.

• Att arbeta med förändrade krav sägs ge bättre koll på komplexa projekt, högre kvalitet och kundnytta, reducerade kostnader eftersom det är dyrt att korrigera fel sent i sy-stemutvecklingsprocessen.

• Att kontinuerligt integrera informationssystemet med övriga applikationer gör att integ-rationen blir enklare eftersom integration genomförs oftare. I RUP integreras informa-tionssystemet sex till nio gånger med övriga applikationer till skillnad från en gång som är brukligt i sekventiell utveckling.

• Den kontinuerliga integrationen gör också att riskhantering involveras tidigt. Det är vid integration risker vanligtvis uppdagas. Eftersom integration görs kontinuerligt uppdagas risker tidigare och kan elimineras innan de utgör en fara för systemutvecklingsprojek-tets budget och tidsplan.

• Det iterativa arbetssättet ger också en mer flexibel systemutvecklingsprocess. Möjlighe-ten att kunna jämföra med existerande mjukvara finns. Möjligheten att kunna göra in-formationssystemet tillgängligt på marknaden tidigare finns också om en konkurrent skulle släppa en liknande produkt.

27

• RUP sägs också ge stabilare och robustare informationssystem eftersom mjukvaran ständigt förändras.

• RUP innebär även bättre kommunikation i systemutvecklingsprocessen eftersom an-vändarna tidigt involveras. Välformulerade krav från användare uppges skapa en gemensam syn på systemets funktionalitet och samarbetet mellan systemutvecklings-projektets intressenter blir då också bättre.

RUP är en strukturerad modell men kräver anpassning eftersom modellen innehåller rikligt med dokumentation, roller processbeskrivningar. Modellens omfattning gör det svårt för mindre organisationer att implementera RUP och genom åren har många organisationer misslyckats med just RUP-införande (Eriksson, 2007).

Det finns i RUP inget uttalat stöd för användarmedverkan. Frågor som rör användbarhet, användargränssnitt och användarnas inverkan på funktionalitet hanteras tidigt i utveckling-en för att förklara det avklarat (Gulliksen & Göransson, 2002).

Gulliksen & Göransson (2002) har föreslagit en ny disciplin i RUP för att få ett mer använ-darcentrerat perspektiv. Författarna föreslår en ny disciplin i RUP som de kallar Usability Design. Att föra in användbarheten som en egen disciplin gör att det får en mer framträ-dande roll i systemutvecklingen.

3.3.4 Evolutionär systemutveckling

Som en reaktion på problemen med en sekventiell systemutvecklingsmodell och med in-tryck från iterativ systemutveckling skapades 1988 en evolutionär systemutvecklingsmodell. Karaktärsdraget för evolutionär systemutveckling är att varje fas avslutas med att fungerande systemtillägg läggs till en mjukvara (Gulliksen & Göransson, 2002).

Inkrementen utvecklas sekventiellt där varje inkrement består av analys, design, kod, test och implementering. I ett kundperspektiv ses informationssystemet i form av delar som le-vereras kontinuerligt. Systemutvecklarperspektivet ser det mer som att kraven från början är otydliga men sedan klarnar längre fram i systemutvecklingsprojektet (Gulliksen & Gö-ransson, 2002).

Ett exempel på en evolutionär systemutvecklingsmodell är spiralmodellen (Figur 6) som uppstod i slutet av 1980-talet (Boehm, 1988). Tanken är att inte specificera det fullständiga systemet direkt utan att bara den högst prioriterade funktionaliteten. Därefter implemente-ras funktionerna och en återkoppling till kund sker. I varje cykel tas separata mål fram för den del av mjukvaran som är viktig i aktuellt inkrementet (Gulliksen & Göransson, 2002).

En viktig del som poängteras i spiralmodellen är att varje cykel i modellen ska avslutas med ett möte med projektmedlemmar och intressenter. Till detta möte ska det också finnas en plan för hur nästkommande cykel ska se ut. När mötet är avslutat ska samtliga mötesdelta-gare ha en förståelse för det kommande inkrementet. Modellen passar även bra för vidare-utveckling av ett befintligt informationssystem. Då läggs ytterligare en spiral till där arbetet sist slutade (Boehm, 1988).

28

Fördelarna med spiralmodellen är att den förbereder projektgruppen på att det färdiga sy-stemet kan bli mer omfattande än vad det i inledningsskedet var tänkt. Modellen fokuserar också starkt på att mindre bra alternativ och fel ska elimineras i ett tidigt skede. I ett tidigt skede förespråkar modellen även på att existerande mjukvara med fördel ska återanvändas (Boehm, 1988).

Begränsningarna är att evolutionär systemutveckling bäst fungerar på interna projekt efter-som dessa sägs vara mer flexibla än externa projekt. Riskhantering sägs vara en nyckelkom-petens i evolutionärt systemutvecklingsarbete men är svår att få tag på. Spiralmodellen sak-nar också en metod att arbeta efter (Gulliksen & Göransson, 2002).

Figur 6 Spiralmodellen (Boehm, 1988).

3.3.5 Sammanfattning Systemutvecklingsmodeller

För att sammanfatta kapitlet om systemutvecklingsmodeller har jag valt att sammanställa tabellen nedan.

Tabell 1 Sammanställning, Systemutvecklingsmodeller.

Modell Vattenfallsmodellen RUP SpiralmodellenLedningsstöd Saknas i modellen Saknas i modellen Intressenter informeras månadsvisAnvändarmedverkan I början och i slutet Tidigt KontinuerligtProjektstyrning Utanför modellen I modellen Utanför rmodellenKravhantering Frysta Förändrade FörändradeTest I slutet Kontinuerligt men huvudsakligen i slutet KontinuerligtArbetsgång Sekventiellt Iterativt Iterativt

29

3.4 Agile

Att dra lärdomar från misslyckade projekt (Gustavsson, 2007) och ta hänsyn till den snabba tekniska utvecklingen har nya systemutvecklingsmodeller uppkommit (Brundin, 2009).

Agile betyder lättrörlig och är ett samlingsnamn för ett antal modeller för att utveckla mjukvara (Higsmith, 2001). Gemensamt är modellernas filosofi, mål och värderingar (Stro-de, Huff & Tretiakov, 2009). Det primära målet för agila modeller är att leverera mjukvara kontinuerligt och att snabbt svara på förändringar i projektets process, produkt och miljö (Strode et al, 2009). Agila modeller har blivit hyllade främst för sin förmåga att leverera re-sultat. En av grunderna i modellerna är att leverera delresultat till beställaren istället för en stor leverans i projektets slutskede (Gustavsson, 2007).

Fram till februari 2001 figurerade ordet agile runt i media utan att det fanns någon fullstän-digt vedertagen definition kring synsättets betydelse (Turk, France & Rumpe, 2002). Den första agila utvecklingsmodellen hade kommit vid mitten på 90-talet och hade följts av yt-terligare ett par (Strode et al, 2009). Därför samlades grundare för de olika systemutveck-lingsmodellerna en vinterdag 2001 för att komma överens kring ett gemensamt synsätt om begreppet Agile. Resultatet blev författandet av det agila manifestet som även undertecknades av sjutton representanter för olika agila systemutvecklingsmodeller. Sällskapet bakom det agila manifestet kom sedermera att kalla sig för Den agila alliansen. Under processen med att ta fram det agila manifestet kom sällskapet fram till fyra viktiga skillnader mellan traditionell och agil systemutveckling (Strode et al, 2009).

• Individer och interaktion är viktigare än processer och verktyg.

• Fungerande mjukvara är viktigare än dokumentation.

• Samarbete med kund är viktigare än kontraktsförhandlingar.

• Svar på förändringar är viktigare än att följa en uppsatt plan.

Utefter dessa fyra punkter sattes tolv stycken principer upp som sedan kom att kallas det agila manifestet (Higsmith, 2001).

1. Högsta prioritet är att tillfredsställa kunden genom att tidigt och kontinuerligt leverera värdeskapande programvara.

2. Välkomna förändrade krav även sent i utvecklingsprocessen. Utnyttja förändringar till kundens fördel.

3. Leverera körbar programvara med korta tidsintervaller från ett par veckor till några må-nader.

4. Verksamhetsrepresentanter och utvecklare måste jobba tillsammans dagligen i projektet.

5. Ansvarstagande individer är den viktigaste tillgången. Ge de ansvar för att lösa uppgiften och stöd dem på vägen.

30

6. Det bästa sättet att utbyta information på är via personliga möten.

7. Fungerande programvara är det viktigaste måttet på framsteg i projektet.

8. Agila processer förordar uthållig utveckling. Utvecklingsteamet ska ha en jämn arbetsbe-lastning så länge som det är möjligt.

9. Kontinuerlig uppmärksamhet på teknisk elegans och bra design stärker förmågan till an-passning.

10. Enkelhet. Konsten att göra rätt saker på rätt nivå är nödvändig.

11. De bästa lösningarna för arkitektur, krav och design kommer från självorganiserade grupper.

12. Gruppen ska regelbundet utvärdera om hur den kan arbeta effektivare.

Carlsson (2008) pekar på två viktiga punkter i det agila tänkandet.

• Agila metoder är anpassningsbara istället för förutsägbara. Tidigare modeller, framförallt de se-kventiella bygger på en tanke om att det går att planera systemutvecklingsprocessen. Det fungerar bra så länge allt går enligt den uppgjorda planen. Vid avvikelser ställer äld-re modeller till med problem. Agila modeller däremot välkomnar förändring och försö-ker hela tiden anpassa sig till rådande omständigheter.

• Agila metoder är fokuserade på människor istället för processer. Fokus i det agila tänkandet är att processen eller metodiken i modellen ska stödja människorna som arbetar i utveck-lingsprojektet och inte styra dem.

Arbetssätten som används i de agila modellerna är i sig inte nya i sig utan det är kombina-tionen av äldre modeller och metoder som gör det agila unikt. Agila modeller har sitt ur-sprung i fyra andra synsätt och modeller på systemutveckling (Carlsson, 2008).

• Objektorientering från UML (Unified Modelling Language) och RUP (Rational Unified Process).

• Evolutionär utveckling från spiralmodellen och prototypbyggen.

• Internettekniken och den snabba utvecklingen i näthastighet.

• Metodteknik från s.k. methodology engineering.

31

3.5 Scrum

“Scrum is different. Work feels different. Management feels different. Under Scrum, work becomes straight-forward, relevant and productive” (Schwaber & Beedle, 2002 sid. 23).

1986 presenterade forskarna Takeuchi och Nonaka artikeln The new new product deve-lopment game. Den kom att bli startskottet för det som sedan kom att bli Scrum. Bakgrun-den till artikeln var att forskarna konstaterat att flexibilitet höll på att bli en lika viktig faktor som hög kvalitet, låg kostnad och differentierbarhet4 inom produktutveckling. Forskarna presenterade i artikeln The Rugby Approach som gick ut på att projektgruppen skulle skapa en helhetssyn och sedan passa bollen fram och tillbaka för att bättre kunna svara upp mot pro-duktens krav (Takeuchi & Nonaka, 1986).

Resultatet av artikeln blev sex karaktärsdrag för den nya produktutvecklingsmodellen. In-byggd instabilitet, självorganiserade projektgrupper, överlappande projektfaser, Multilear-ning, hårfin kontroll5 och kunskapsutbyte (Takeuchi & Nonaka, 1986).

Schwaber (1996) skiljer på definierade och empiriska processer. En definierad process är upprepbar och ger lika resultat varje gång. En empirisk process är till skillnad från den de-finierade delvis okänd om nästa steg.

Eftersom systemutvecklingsmodeller är komplicerade och omvärlden ständigt förändras krävs flexibilitet i systemutvecklingen. Ju närmre omvärlden systemutvecklingen sker desto mer ändamålsenligt blir systemet. Den största skillnaden mellan Scrum jämfört med tidigare systemutvecklingsmodeller är att aktiviteterna i projektet är oförutsägbara. Äldre modeller som Vattenfallsmodellen och RUP har definierade faser för exempelvis design och test. I Scrum används istället en kontrollmekanism för att styra oförutsägbarheten och kontrollera riskerna (Schwaber, 1994).

Ordet Scrum är en term hämtad från rugby där Scrum beskriver den klunga som spelarna bildar när bollen sätts i spel. Namnet är ingen slump utan Scrum liknar rugby i tre avseen-den enligt Gustavsson (2007).

1. Självstyre där alla spelare har ansvar för sin position.

2. Tydliga mål där alla vet att bollen ska över till andra sidan planen.

3. Kollektivt ansvar där alla är ansvariga tillsammans för att vinna matchen.

Enligt Schwaber (2004) innebär Scrum ett paradigmskifte för systemutveckling avseende makt, kontroll, samarbete, dokumentation och kodning.

Scrum beskrivs enklast i form av tre roller, tre ceremonier och tre artefakter och kan visua-liseras enligt Figur 7 .

4 Särskildhet

5 I originalverket nämns Subtle control. Författarna beskriver fenomenet som självkontroll och felsökande.

32

Figur 7 Scrum (Sutherland, 2009)

3.5.1 Roller

Scrum delar in personer relaterade till projektet i två grupper, kycklingar och grisar. Grisar är de som deltar och arbetar mot projektmålet. Kycklingar är de som inte är involverade i projektet utan är mer intresserade av projektet. Kycklingarna får besöka möten men ska hålla sig i bakgrunden för att inte störa projektgruppen. Bland kycklingarna finns det i hu-vudsak tre viktiga roller som är avgörande för att lyckas med Scrum (Schwaber & Beedle, 2002).

3.5.1.1 Scrum Master

”Scrum Master’s job is to increase the productivity of the team in any way possible” (Schwaber & Beedle, 2002 sid. 42).

Personen som styr IT-projekt i en organisation som använder Scrum kallas för Scrum Mas-ter (Schwaber & Beedle, 2002). Jämfört med en projektledare har Scrum Master ett större ansvar (Schwaber, 2004). Scrum Masters uppgifter är att utse en Produktägare (Product Owner) och en projektgrupp (Scrum Team). Under en sprint, som vanligtvis är en månad lång ansvarar Scrum Master för att hålla dagliga möten med Scrum Team. Under dessa mö-ten ansvarar Scrum Master för att röja undan eventuella hinder och att se till att viktiga be-slut tas. I Scrum poängteras vikten av att fatta beslut även om kompletta beslutsunderlag saknas. Motiveringen är att Scrum Team hela tiden ska arbeta då beslut ändå kan ändras senare (Schwaber & Beedle, 2002).

Svårigheten med Scrum är att verkligen förstå sig på konsten att vara Scrum Master. Schwaber (2004) menar att du som Scrum Master måste förstå filosofin bakom för att lyck-as. Som exempel tar Schwaber (2004) upp ett företag som implementerat Daily Scrum för att förbättra kommunikationen i utvecklingsgruppen. Schwaber (2004) menar att syftet med Daily Scrum är socialisering och synkronisering av arbetet i gruppen.

Det är av vikt att som Scrum Master fokusera på att gruppen ska vara i fokus och inte indi-viden. Schwaber (2004) hänvisar till ett fall där en Scrum Master kallade mötet sitt Daily

33

Scrum. Scrum Master hade i detta fall delegerat uppgifter och följt upp arbete likt en tradi-tionell projektledare. Exemplet ovan belyser att det innebär en förändring att gå från att vara projektledare till Scrum Master. En projektledare är mer likt en chef medan en Scrum Master ska fungera mer som en coach (Schwaber, 2004). Ett vanligt misstag är att en Scrum Master fattar för mycket beslut åt gruppen och inte låter gruppen ta besluten (Schwaber & Beedle, 2002). För att bli en framgångsrik Scrum Master krävs framgång i flera sprintar. Scrum innebär inte några tekniker som går att anamma på traditionell projektledning utan är ett nytt tankesätt enligt Schwaber (2004).

Schwaber (2004) menar även att ett lyckat Scruminförande föregås av att Product Owner och systemutvecklarna har ett bra förhållande. Scrum Master har som ansvar att föra sam-man dessa och få de att förstå varandra.

Scrum Master ansvarar för att tiden för Daily Scrum hålls till femton minuter, att aktiviteter läggs till och tas bort från Sprint Backlog att uppdatera Burndown Chart samt att säkerstäl-la att olika hinder blir lösta av avdelningschef eller Product Owner.

3.5.1.2 Product Owner

Product Owner är ansvarig för att representera alla som har en åsikt om det färdiga syste-met. Product Owner ska vara en enskild person (Schwaber & Beedle, 2002) och ska säker-ställa att funktionaliteten för systemet uppnås och att affärsnyttan ständigt är i förankrad. Att vara Product Owner kräver mycket engagemang. Därför är rekommendationen att Product Owner att utses av Scrum Master i samråd med beställaren för att samarbetet ska bli bästa möjliga (Schwaber, 2004).

3.5.1.3 Scrum Team

Scrum Team ansvarar för att genomföra sina åtaganden i varje sprint och har fulla befo-genheter att göra det som krävs inom organisationens ramar. Scrum team ska vara självor-ganiserande och hela teamet ska bidra till slutresultatet. Scrum team behöver inte lyda råd som kommer utifrån utan bestämmer helt själva vad som behöver göras inom varje sprint. Det enda som Scrum Team måste anpassa sig till är de faktiska förhållandena som råder, exempelvis tillgänglig arkitektur (Schwaber & Beedle, 2002).

Scrum Team bör bestå av sju plus/minus två medlemmar (Schwaber, 2004). Teamet ska vara en mix av flera olika kompetensområden för att lyckas med målet för den aktuella sprinten Ett Scrum Team bestående av färre medlemmar än fyra kan dra nytta av idéerna i Scrum men begränsar interaktionen mellan deltagarna (Schwaber & Beedle, 2002).

Scrum Team behöver en miljö att arbeta i för att främja samarbete och produktivitet. Or-ganisationen ska tillhandahålla utrustning och en arbetsmiljö som främjar detta. Miljön ska även vara avskild från störningar (Schwaber & Beedle, 2002). Larman (2004, återgiven i Forsberg & Lindström, 2008) menar att det finns en fara i att Scrum Team skärmar av sig från övriga organisationen. De bryter då mot de normer som finns och kan på sikt leda till konflikter.

34

3.5.2 Artefakter

Product Backlog, Sprint Backlog och Burndown Chart är tre artefakter som anses vara vik-tiga inom Scrum.

3.5.2.1 Product Backlog

Product Backlog är ett dokument innehållande de krav som finns uttalade på det slutliga in-formationssystemet. Dokumentet motsvarar en traditionell kravspecifikation och innehåller önskemål på funktionalitet, infrastruktur och arkitektur. Product Backlog kan ständigt för-ändras med nya krav och blir aldrig helt färdig. Product Backlog ska vara prioriterad och de viktigaste kraven ska placeras överst av Product Owner inför varje Sprint Planning Meeting (Schwaber & Beedle, 2002).

För att lyckas med en bra Product Backlog bör Product Owner tänka i banor kring affärs-mål och inte kring teknik. För att komma ifrån teknikfokuseringen bör Product Owner tänka i banor kring orsaken till en viss funktionalitet. Med detta tankesätt visualiseras målen med informationssystemet på ett bra sätt och den tekniska beskrivningen kan istället an-vändas som en notering. Kraven kallas i Scrum för stories (Kniberg, 2007).

3.5.2.2 Sprint Backlog

Sprint Backlog innehåller de stories som ska utföras under en aktuell sprint för att uppnå sprintens mål (Schwaber & Beedle, 2002). Stories bryts sedan ner till uppgifter (tasks) som estimeras i valfri tidsenhet. Tidsestimering görs med en aktivitet som heter Planning Poker. I Planning Poker används en speciell kortlek där varje medlem får 13 kort var med olika siffror på. För varje uppgift som genomgås får varje gruppmedlem lägga ett kort som visar den tid hon tror uppgiften ska ta. Hela gruppen ska lägga sitt kort samtidigt för att undvika påverkan sinsemellan i gruppen. Vid alltför stora skillnader bland gruppmedlemmarnas kort ska uppgiften diskuteras och en gemensam tidsuppskattning beslutas om.

Det är den enskilda medlemmen i Scrum Team som ansvarar för att uppdatera Sprint Backlog med tiden. När uppgiftens tid är nere på noll ska uppgiften vara slutförd. Om den inte skulle vara det ska en ny uppgift skapas i Sprint Backlog. Det går alltså inte att fylla på tid eller ha ett negativt värde på någon uppgift (Schwaber & Beedle, 2002).

3.5.2.3 Burndown Chart

En Burndown Chart används för att väga återstående arbetstid i sprinten mot kvarvarande dagar i sprinten. Grafen kan se ut som Figur 8 och ska användas som stöd för uppföljning av arbetet i aktuell sprint. Uppföljning sker dagligen och det går att se om sprinten är i fas med uppsatt tidsplan eller inte (Schwaber, 2004). Varje deltagare redovisar hur mycket de har kvar att göra på sin uppgift och tiden räknas ner mot noll (Gustavsson, 2007). Burn-down Chart kan även användas på Product Backlog (Carlsson, 2008).

Arbetstiden ska med fördel anges i ett mått som inte har med tid att göra, exempelvis ba-naner. Istället för att räkna ut hur många dagar eller timmar en aktivitet tar ska istället tids-uppskattningen ha sin utgångspunkt i förhållandet mellan två aktiviteter i systemutveck-lingsprojektet. En aktivitet som är värd två poäng tar exempelvis dubbelt så lång tid som en

35

som är värd en poäng. När en aktivitet ska tidsuppskattas får var och en i Scrum Team möjlighet att skriva på en lapp hur många bananer hon tror att aktiviteten kommer att ta. Därefter följer en diskussion där tidsuppskattningen bestäms (Gustavsson, 2007). I kapitlet ovan beskrevs Planning Poker som är en annan metod för att göra tidsuppskattning. Båda metoderna kan användas.

I projektets inledande sprintar kan tidsuppskattning vara komplicerat. Det kan vid den för-sta Sprint Planning Meeting beslutas att sprinten ska innehålla 40 bananer. När Sprinten är avslutad kanske bara 32 bananer har klarats av. Scrum Team vet då ungefär hur många po-äng de klarar i en sprint kan välja att ha 32 bananer i den kommande sprinten (Gustavsson, 2007).

Figur 8 Burndown Chart (Moving Summit, 2009).

3.5.3 Ceremonier

I Scrum finns tre olika ceremonier som fungerar som avstämningspunkter och tillfällen där delar av mjukvara kan levereras.

3.5.3.1 Daily Scrum

Daily Scrum kallas det dagliga mötet som Scrum Team och Scrum Master har. Mötet ska pågå i maximalt femton minuter och styrs av ett antal regler6. Syftet med ett Daily Scrum är att förbättra kommunikationen i Scrum Team, eliminera andra projektmöten, röja undan hinder, fatta beslut samt att förbättra kunskapen om projektet hos hela projektgruppen.

Rummet där mötet hålls ska vara lätt att ta sig till för alla involverade i projektet. Hela gruppen ska närvara vid mötet. För de som inte kan vara där fysiskt ska möjligheten till al-ternativa möjligheter för deltagande finnas, exempelvis telefonkonferens.

Enligt Schwaber & Beedle (2002) är det Scrum Masters ansvar att mötet genomförs kor-rekt. Scrum Master ska fördela ordet under mötet mellan de olika deltagarna och ställa tre korta frågor till samtliga deltagare.

6 För fullständiga regler se Bilaga 5 Rules for Daily Scrum.

36

• Vad har du gjort sedan förra Daily Scrum?

• Vad ska du göra fram till nästa Daily Scrum?

• Vad har du för hinder i ditt arbete?

Scrum Master ska se till att tiden för mötet hålls till femton minuter. Om diskussioner spå-rar ur eller blir utdragna bör Scrum Master se till att mötet fortgår och råda de diskuterande projektmedlemmarna att talas vid efter mötet. Att möten ska hållas korta motiveras med att mötet alltid ska hinnas med och för Daily Scrums fortsatta existens. Börjar möten dra ut på tiden finns risken att chefer ifrågasätter Daily Scrums nödvändighet (Gustavsson, 2007). Eftersom utvecklare kan vara med i flera projekt är det av vikt att deltagarna i mötet bara tar upp det som rör det aktuella projektet men även endast aktuell sprint. Meningen är att kunna genomföra ett effektivt och kärnfullt möte (Schwaber & Beedle, 2002).

Personer som kommer sent till möten påverkar mötets effektivitet negativt. Därför före-språkar Schwaber (2004) att en avgift ska tas ut vid sen ankomst. Avgiften ska läggas i en pott som ska gå till gemensamma aktiviteter som exempelvis en projektavslutningsfest (Gustavsson, 2007).

När det gäller röjandet av hinder är Scrum Master ansvarig för att anteckna och se till att handla mot hindren omgående efter mötet för att inte störa Scrum Teams arbete (Schwaber & Beedle, 2002).

Under mötet har deltagarna full befogenhet att fatta beslut inom ramen för att nå den aktu-ella sprintens mål (Schwaber & Beedle, 2002).

Gustavsson (2007) menar att Daily Scrum låter som en utopi och fungerar bara när delta-garna jobbar heltid. Hänsyn tas inte till att medarbetare jobbar exempelvis halvtid. I dessa fall föreslår Gustavsson (2007) att de dagliga mötena ska bytas ut mot möten t.ex. varannan dag.

Ett problem som kan uppstå vid Daily Scrum är att en eller flera gruppmedlemmar inte vet vad de ska göra när de får frågan om vad de ska göra aktuell dag. Vid detta scenario ska alla uppgifter genomgås för att säkra att projektet ligger i fas och att hela gruppen vet vad varje arbetsuppgift innebär. Efter det ska frågan ställas igen och förhoppningen är då att hela gruppen har arbetsuppgifter den kommande dagen. I annat fall kan det finnas möjligheter till parprogrammering7 (Kniberg, 2007).

3.5.3.2 Sprint Planning Meeting

Sprint Planning Meeting är det viktigaste mötet i Scrum (Kniberg, 2007). Syftet med Sprint Planning Meeting är att planera nästkommande sprint i systemutvecklingsprojektet (Schwaber & Beedle, 2002). Målet är att ge Scrum Team tillräckligt med information för att de ska kunna arbeta ostört de kommande veckorna (Kniberg, 2007).

7 Parprogrammering innebär att två personer sitter vid samma dator och arbetar med samma design, kod, al-goritm och test (Fälth & Svahn, 2003).

37

Product Owner ansvarar för att uppdatera och prioritera kraven i Product Backlog till mö-tet. En förutsättning för ett lyckat Sprint Planning Meeting är en välstrukturerad Product Backlog. Detta innebär enligt Kniberg (2007) att det ska finnas en ständigt uppdaterad Product Backlog och en ansvarig Product Owner för systemutvecklingsprojektet.

Scrum Team beslutar i samråd hur mycket de uppskattar att hinna med i den kommande sprinten. Utifrån dessa uppskattningar sätts ett mål för den aktuella sprinten upp. Detta mål ska sedan genomsyra arbetet i hela sprinten. Efter att det beslutats om vad som ska göras måste även beslut tas om hur arbetet ska utföras. Detta kan exempelvis innefatta upphand-ling av expertis som inte finns inom projektgruppen. Scrum Team tar även fram en s.k. Sprint Backlog som mer detaljerat beskriver vad som behöver göras för att uppnå målet för sprinten (Schwaber & Beedle, 2002).

Product Owner ska medverka på Sprint Planning Meeting. Tillsammans med Scrum Team ska Product Owner bestämma över systemutvecklingsprojektets omfattning, tidsuppskatt-ning och vikt. Product Owner ansvarar för att bestämma vikt och omfattning medan Scrum Team ansvarar för tidsuppskattning (Kniberg, 2007).

3.5.3.3 Sprint Review

Vid slutet av varje sprint hålls ett möte med Product Owner och andra eventuella intressen-ter8. På mötet, som pågår i fyra timmar presenterar Scrum Team först vad de har gjort un-der sprinten. Därefter resonerar mötesdeltagarna tillsammans kring vad som ska göras i den kommande sprinten fram till nästa Sprint Review, som bör hållas exakt 30 dagar senare. Ansvarig för mötet är Scrum Master tillsammans med Scrum Team tar fram en agenda för mötet och förbereder presentationen av de framsteg som gjorts i sprinten (Schwaber & Be-edle, 2002).

Schwaber & Beedle (2002) menar att det bästa sättet att genomföra en Sprint Review på är att börja övergripligt med att beskriva betydelsefulla händelser i sprinten och sedan presen-tera programvaran som tagits fram. Genom att alltid visa upp körbar programvara menar förespråkare för Scrum att en perfekt utgångspunkt för brainstorming uppkommer. Mötes-deltagarna ser praktiskt hur informationssystemet ser ut och kan enklare komma med för-slag till förbättringar och förändringar i kraven. Eftersom hela Scrum Team deltar på mötet är det också enklare att svara på frågor i en lägre detaljnivå (Schwaber & Beedle, 2002).

3.5.4 Test

Idealfallet i Scrum är att utveckla systemet och presentera det på Sprint Review. Kniberg (2007) menar däremot att det är betydligt mer komplext. Att endast utveckla ett system och sedan presentera det på en Sprint Review är inte att föredra. Inom systemutvecklingspro-jektets ramar bör en testgrupp tillsättas. Testare är experter på test och genomför fler tester än systemutvecklarna. Tester som systemutvecklarna inte tänkt på genomförs också. Tester

8 Med andra intressenter avses företagsledning hos utvecklingsföretaget, användaren samt övriga kundrepre-sentanter.

38

kan även göras på en annan hårdvara än den som utvecklarna har tillgång till (Kniberg, 2007).

Kniberg (2007) menar att testare ska ingå i Scrum Team. Först när koden testats och god-känts av testaren är den att betrakta om färdigt. Eftersom det tidigt i projektet inte finns färdig mjukvara att testa ska testaren då istället fokusera på att förbereda testarbetet med att exempelvis bygga testmiljöer och skriva testfall.

För att enklare kunna tillämpa test i Scrum krävs en reducering av antalet uppgifter som ska utföras i en sprint. Att göra mindre i varje sprint höjer kvaliteten på mjukvaran som bidrar även till ett stabilare informationssystem. Istället för att stressa ihop flera halvfärdiga delar med många fel ska färre uppgifter istället göras ordentligt. Kniberg (2007) menar att det all-tid är billigare att utveckla mindre stabila delar istället för större instabila delar som måste korrigeras senare i projektet.

Acceptanstest ska egentligen inte behövas inom Scrum eftersom varje ny version accepte-ras av beställarorganisationen på Sprint Review (Kniberg, 2007).

3.6 Avrundning av teorikapitlet

Kapitlet teori har presenterat fem faktorer som gör att IT-projekt misslyckas. Lednings-stöd, användarmedverkan, projektstyrning, kravhantering samt kodning och test. Olika för-fattares utsagor har samlats under dessa kategorier.

En systemutvecklingsmodell är ett koncept för utveckling av informationssystem. Genom åren har olika modeller för att utveckla informationssystem kommit och gått. Vattenfalls-modellen, RUP och Spiralmodellen är tre exempel på modeller som både hyllats och kriti-serats åren som gått.

Agila systemutvecklingsmodeller är det senaste i raden av angreppssätt som ska bidra med en högre andel lyckade IT-projekt. 2001 författades det agila manifestet med syfte att skapa enighet i begreppet Agile. Svar på förändrade krav, mindre dokumentation, kunden i fokus och fungerande mjukvara är några av de ståndpunkter som beskrivs i manifestet. Scrum som är en agil systemutvecklingsmodell kännetecknas av korta tidsintervaller, tydligt fokus på systemutvecklarna och en ständig uppföljning av projektet. I kommande kapitel ska Scrum utvärderas utefter de faktorer som gör att IT-projekt misslyckas för att kunna besva-ra forskningsfrågan om problemen i IT-projekt kan reduceras med Scrum.

39

4 Undersökning

För att besvara frågan om en agil utvecklingsmodell kan eliminera negativa effekter i IT-projekt har jag använt mig av observation och intervjuer med respondenter på ett fallföretag .

4.1 Presentation av fallföretag

Banverket är den myndighet i Sverige som ansvarar för järnvägsfrågor. I Banverkets upp-drag ingår det bland annat att driva utvecklingen av järnvägen, bistå med expertis till reger-ing och riksdag samt samordna regional, lokal och interregional järnvägstrafik. Banverket har idag ca 6500 anställda i hela Sverige. Från och med den första april kommer Banverket att bli en del i det nya Trafikverket tillsammans med delar av Vägverket, Luftfartsverket, Sjöfartsverket och Statens institut för kommunikationsanalys (SIKA).

Banverket Verksamhetsstöd IT har till uppgift att förvalta och ta fram en produktportfölj inom IT som baseras på Banverkets IT-strategi. Enheten har idag totalt ungefär 110 medarbetare inklusive konsulter.

I undersökningen ingår tre olika projekt på Banverket Verksamhetsstöd IT.

4.2 Observation

En observation har genomförts på en Sprint Review och en Sprint Planning med syftet att studera hur Scrum fungerar i praktiken. Nya modeller framställs som ofta som frälsare av sina skapare. För att se hur modellen tillämpas har därför observation använts som datain-samlingsmetod. Eftersom mitt synsätt är hermeneutiskt anser jag att observation är ett bra komplement till intervjuer då jag först observerat och skapat mig en uppfattning om ett fe-nomen och sedan kunnat intervjua de personer som jag observerat.

Innan Sprint Review gick jag genom teorin och satte upp en enkel mall för att observera mötet. Mallen återfinns i Bilaga 1.

Mitt fokus under mötet har främst varit att studera hur Product Owner, Scrum Master och Scrum Team agerar under mötet. Jag har även använt observationen för idégenerering till intervjufrågor.

Ledningsstödet har också utvärderats genom observationen. Vilka personer från ledande befattningar finns med under mötet och vilka frågor de fokuserar på i projektet. Jag har även studerat Product Backlog under mötet för att studera hur mycket förändringar som görs och vem som är mest drivande i det arbetet.

Observationen pågick under fem timmar och genomfördes öppet deltagande där alla besö-kare på mötet visste vad jag hade för syfte med min närvaro. Eftersom mitt uppdrag är känt på fallföretaget och samtliga vet vad jag håller på med ansågs det som omöjligt att un-der mötet dölja mitt syfte.

40

Direkt efter observationen gick jag genom den med hjälp av mitt schema och skrev ner mina intryck för att enkelt kunna arbeta vidare med intervjuer och analys. På observationen deltog en ytterligare examensarbetare och vi hade en kort diskussion om våra intryck direkt efteråt.

4.3 Urval av intervjupersoner

På fallföretaget är det totalt fyra projekt som använder Scrum som systemutvecklingsmo-dell. Jag har i ett första skede valt ut tre Scrum Masters, tre Product Owners och tre sy-stemutvecklare. De tre Scrum Masters kändes givna på förhand då tre av fyra Scrum Mas-ters är anställda på fallföretaget och den sistnämnda är inhyrd konsult. När jag har valde Scrum Masters blev det naturligt att välja de Product Owners som var involverade i samma projekt. När jag skulle välja systemutvecklare gick jag också efter premissen hellre anställd på fallföretaget än inhyrd konsult. Jag har själv fått välja ut respondenter men har haft visst stöd av Scrum Masters för att få ett bra urval.

Att jag intervjuat fyra systemutvecklare kommer sig av ett missförstånd som gjorde att jag intervjuade fel systemutvecklare. Detta har däremot inte någon större inverkan på under-sökningens resultat eftersom denna person också deltar i ett Scrum-projekt. Innan intervju-erna påbörjades presenterades urvalet för en chef på fallföretaget för att säkerställa att urva-let var bra och för att få synpunkter. Då synpunkter saknades genomfördes intervjuer på de personer jag valt ut.

4.4 Intervjuer

Utgångspunkterna för intervjuerna har varit de faktorer som gör att IT-projekt misslyckas samt hur de olika personerna arbetar i Scrum. Intervjumaterialet syftar till att ge en bild av hur Scrum används på fallföretaget och om arbetssätten som Scrum förespråkar fungerar i praktiken och leder till bättre IT-projekt.

Frågorna utformades från början strukturerat och omvandlades sedan till mer ostrukture-rade och öppna frågor med syftet att få mer fria svar. De strukturerade frågorna har behål-lits för att vara ett stöd vid intervjuerna för att kunna ställa följdfrågor. Frågorna har valide-rats av två personer för att säkerställa att kvaliteten på frågorna är bra.

Intervjuerna har genomförts i lokaler på fallföretaget, ansikte mot ansikte och spelats in på diktafon med en inbyggd mikrofon med tillstånd av de intervjuade personerna.

Efter varje intervju har jag gått genom intervjun genom att utifrån intervjuguiden skriva rent intervjun. Vid otydligheter har jag även lyssnat på intervjun en gång till.

4.5 Analysmodell

Efter att ha genomfört intervjuer och observation samt sammanställt dessa påbörjades ana-lysarbetet. De fem faktorer som definierades i teorikapitlet kring misslyckade IT-projekt har gett analysen en tydlig avgränsning och utgångspunkt. Därefter har jag placerat data

41

från de sammanställda intervjuerna under respektive rubrik och på så vis försökt finna skillnader och likheter med teori.

I kapitlet Resultat och Analys som följer redovisas empiri och analyseras också direkt för att ge läsaren en bättre möjlighet att följa resonemangen. Analysen beskrivs grafiskt med bilden

Figur 9. Till höger ses en bild över de fem faktorerna och till vänster Scrum. Att projekt-styrning är cirkelformad och centralt placerad är inte av någon speciell anledning. Alla fak-torer diskuteras i analysen. Bilden är endast en grafisk sammanställning. Pilen i analysmo-dellen beskriver att Scrum ska utvärderas gentemot de fem faktorerna och närma sig dessa. Om Scrum är det paradigm som Schwaber (2004) menar ska Scrum täcka faktorerna helt, annars bara till en viss del.

Figur 9 Analysmodell (Egen bild)

42

5 Resultat och Analys

I kapitlet Resultat och Analys redovisas empirisk data insamlad genom intervjuer. Det empiriska resulta-tet analyseras samtidigt med stöd i teori tidigare presenterad i Kapitel 3 .

5.1 Ledningsstöd

I den empiriska undersökningen har det framkommit tre aspekter på ledningsstöd. Led-ningsstöd från beställarorganisationen, ledningsstöd från systemleverantörens organisation samt rollen Product Owner som ett uttryck för ledningsstöd.

Samtliga systemutvecklare som intervjuats deltar i sitt första Scrum-projekt. Två av fyra har genomgått utbildning i Scrum. Systemutvecklarna i Scrum Team upplever stödet från led-ningen på sin organisation som lågt. Tre av fyra uppger att närmaste chef någon gång då och då kommer in och frågar hur det går med projektet. En fjärde berättar att Scrum Mas-ter i projektet också är hennes närmsta chef vilket gör att hon har ”full koll” som respon-denten uttrycker det.

En systemutvecklare påpekar att närmaste chefen inte lägger sig i projektet nämnvärt men att genomförandeansvarige chef är mer aktiv och intresserad av projektets fortskridande. Genomförandeansvarig chef har deltagit på en del Sprint Demonstrationer och sitter även med i projektets styrgrupp. Tre av fyra systemutvecklare påtalar däremot att Scrum Master har projektuppföljningar med genomförandeansvarig chef. En systemutvecklare påtalar att en chef utan genomförandeansvar två gånger i rad besökte projektets Sprint Review och uppskattade mötet. En systemutvecklare påpekar att en ytterligare fördel med att ha chefer med på Sprint Review är att hela projektgruppen kan bedömas och få feedback och inte bara Scrum Master.

De tre intervjupersoner som har rollen som Scrum Master har alla utbildning i Scrum. Led-ningsstödet som Scrum Master uppfattar är främst statusrapporteringen9 i projektet. Status-rapportering sker tio gånger per år och är inriktad på ekonomiska aspekter berättar en Scrum Master. En Scrum Master anser att chefernas stöd är bra då de ofta är med och be-söker Sprint Demo och Sprint Review. En annan Scrum Master anser att ledningens stöd i projektet är bra men att cheferna från systemleverantörsorganisationen borde vara med på Sprint Review någon gång ibland. Även den tredje Scrum Mastern hävdar att ett mer aktivt deltagande från ledningen på Sprint Review hade varit bra. Motiveringen för ett deltagande är främst för att visa beställarorganisationen att projektet även är viktigt hos systemutveck-laren.

Ledningsstöd kan också ses ur ett beställarperspektiv. De personer som utsetts till Product Owner har alla ett starkt stöd från ledningen i respektive beställarorganisation. Även i detta fall sker den huvudsakliga uppföljningen från ledningen i form av statusrapportering till an-

9 Statusrapporten är en del i Props som används för projektuppföljning på fallföretaget.

43

svarig chef. En Product Owner beskriver sin relation till sin beställare som ett bra samarbe-te. De har tillsammans arbetat med frågeställningar som rör projektet och vid oklarheter har hon alltid fått svar på det hon behövt. Nu har däremot beställaren lite olyckligt för-svunnit ur projektet och ersatts av tre andra personer. Product Owner känner en osäkerhet inför framtiden eftersom dessa tre personer är upptagna med andra uppgifter än projektet.

En annan Product Owner beskriver att stödet från ledningen är riktigt bra. Product Ow-ners chef sitter med i projektets styrgrupp och är snabb på att lyfta frågor till verksamheten och är som hon uttrycker det

”på tårna till 100 % ”.

En aktiv ledning är i detta fall ett måste eftersom Product Owner är inhyrd konsult. Hon poängterar att hon inte kan verksamheten utan måste kontinuerligt rådfråga den. En tredje Product Owner anser att ledningsstödet i det aktuella projektet är bättre än i tidigare pro-jekt. Product Owner menar även att om en beställare är oengagerad ska det påtalas och be-ställaren ska tvingas till att bli mer aktiv i rollen.

Den Sprint Review jag observerade bemannades av Product Owners chef samt ytterligare två personer från beställarorganisationen. Från Systemleverantörsorganisationen deltog ingen chef. Det framkom inga kommentarer från mötesdeltagarna om de tyckte någon per-son saknades på mötet eller inte.

Trots att ledningsstöd ständigt poängteras som en faktor som gör att IT-projekt misslyckas poängteras det inte i någon systemutvecklingsmodell. Sekventiell systemutveckling, RUP och Spiralmodellen saknar alla tydliga rutiner för att involvera ledning i IT-projekt. Scrum som utvecklingsmodell ger inte heller några tydliga förhållningssätt till ledningsstöd. Upp-följning sker som flera respondenter säger i statusrapportering enligt Props månadsvis.

Keil et al (1998) påpekade ett aktivt ledningsdeltagande i hela utvecklingsprocessen och en ledning med en aktiv roll i systemutvecklingsarbetet. Genom att bara studera Chefers enga-gemang för IT-projektet skulle en tillämpning av Scrum som utvecklingsmodell inte göra utgöra någon större skillnad gentemot tidigare systemutvecklingsmodeller. Statusrapporte-ringen som förekommer både från beställarorganisation och från systemleverantörsorgani-sationen är inget som ingår i Scrum utan i Props. Sprint Review är ett öppet möte som vem som helst får besöka (Schwaber & Beedle, 2002). Därmed skapas förutsättningar för bättre ledningsstöd om chefer väljer att delta på mötet. Deltagarna i projekt där ledningen besöker Sprint Review är mer positiva till ledningsstödet än deltagarna som har chefer som inte be-söker Sprint Review. Det tyder på att ledningsstödet i ett Scrum Projekt kan öka vid ett ak-tivt ledningsdeltagande på Sprint Review. Då de flesta systemutvecklarna påtalat att de sak-nar ledningsstöd i projekten motiverar det ännu mer till att chefer ska besöka Sprint Revi-ew. Ett ytterligare skäl för chefer att besöka Sprint Review är det faktum att mötet ger ut-rymme till att utvärdera hela gruppens arbete och inte bara Scrum Masters.

Att betänka när ledningsstöd diskuteras är att rollen Product Owner representerar bestäl-larorganisationen under hela projektet. Personen är i samtliga studerade projekt inte slutan-vändare av systemet utan har en högre befattning i beställarorganisationen. Därför skulle ledningsstödet kunna uttryckas i rollen Product Owner istället för hos chefer. Scrum ger

44

vid detta resonemang en hög grad av ledningsdeltagande. Hullberg (2003) menade att det i IT-projekt är svårt att definiera vem i projektet som är produktägare. I och med rollen Product Owner vet samtliga projekt och intressenter vem som representerar beställarorga-nisationen och är produktägare.

Att tillämpa Scrum och att specifikt ha en aktiv Product Owner gör även att beställare och systemleverantör kommer närmare varandra. Det glapp som Hullberg (2003) hävdar upp-står däremellan försvinner i och med den nästintill dagliga kontakten som både Scrum Mas-ters och Product Owners vittnar om i intervjuerna.

De Product Owners och Scrum Masters jag har intervjuat vittnar alla om att kontakten sker löpande från ett par gånger i veckan till dagligen. Samtliga Product Owners deltar på ett par dagliga möten i veckan. Motiveringar från Product Owners till att besöka möten har varit dels att enkelt kunna följa projektet men också för att det är ett enkelt forum där hela gruppen är samlad. En Product Owner använder mötet för att lyfta frågor från verksamhe-ten som är viktiga. En annan Product Owner uttrycker sig med att Daily Scrum passar ut-märkt för att snappa upp frågor från Scrum Team och sedan ta med dessa tillbaka till be-ställarorganisationen.

5.1.1 Bättre med Scrum?

Likt tidigare systemutvecklingsmodeller finns det inget uttalat stöd i Scrum för lednings-stöd. Det stöd som finns i de studerade projekten är statusrapportering i Props. Statusrap-portering fungerar som avstämning både hos systemleverantör och hos beställarorganisa-tion.

Studien har pekat på att ett aktivt ledningsdeltagande på Sprint Review från systemleveran-tören ger nöjdare projektdeltagare. Scrum Masters påpekar just att besök på Sprint Review skulle underlätta främst för att visa att projektet är viktigt även för systemleverantören.

Rollen Product Owner kan uttrycka ledningsstödet eftersom denne har en högre position än slutanvändarna. Product Owner är aktiv i hela projektet och utgör ett högre ledningsdel-tagande med Scrum jämfört med äldre systemutvecklingsmodeller där beställarrollen inte haft en lika framträdande karaktär.

45

5.2 Användarmedverkan

De projekt som studerats på fallföretaget har samtliga involverat slutanvändare i olika grad beroende på informationssystemets natur. En av projektens slutanvändare är inte männi-skor utan andra informationssystem inom fallföretaget. I detta projekt representeras de an-gränsade informationssystemen av en referensgrupp som deltagit på informationsmöten vid tre tillfällen under projektets gång. Product Owner och Scrum Master har reflekterat över att bjuda in denna referensgrupp till Sprint Review men tagit beslut om att inte genomföra detta. Anledningen är att referensgruppen är alltför stor och att det då inte skul-le bli ett effektivt möte om alla mötesdeltagare då skulle få komma och ha åsikter.

Projektet är tvådelat och handlar dessutom om att ta fram ett administrationsverktyg som ska användas av systemförvaltarna. Dessa systemförvaltare sitter med i huvudprojektet hos kärnverksamheten. Systemförvaltarna tillhandahåller verksamhetskompetens till projektet eftersom Product Owner är en inhyrd konsult. Systemförvaltarna medverkar även ibland på Sprint Review. De flesta projekt inom IT på fallföretaget omges av ett större verksamhets-projekt. Product Owner i detta projekt är projektledare för hela projektet medan Scrum Master ser sig som en delprojektledare för just systemutvecklingen.

Att systemutveckling ska ses som ett delprojekt till ett större verksamhetsprojekt är en åsikt som delas med Product Owner i ett annat projekt. I projektet anser Scrum Master att slut-användarna är samtliga av Sveriges tågresenärer. Det färdiga systemet ska administreras av trafikinformatörer som i projektet representeras av en referensgrupp av äldre trafikinforma-törer. Referensgruppen består av tre personer som längre fram ska delta vid test av använ-dargränssnittet. Hittills är projektet i ett tidigt skede och referensgruppen har bara fått möj-lighet att uttrycka önskemål på användargränssnittet.

Det sista projektet består i att ta fram två olika system. Slutanvändarna för det första sy-stemet är i dagsläget med och påverkar systemet främst när det gäller användargränssnitt. Slutanvändarna bjuds in till Sprint Demonstrationen som genomförs före Sprint Review. Synpunkter tas då emot vad gäller användargränssnittet. Frågor som rör andra delar i sy-stemet tas inte upp på dessa möten med hänsyn till slutanvändarnas kompetens enligt Pro-duct Owner. Orsaken är slutanvändarnas kompetens kring systemets uppbyggnad. Det andra systemet som sedan ska tas fram har betydligt fler användare än vad det första har och här ska ett urval bland användarna göras för att få fram en referensgrupp. Däremot har representanter för denna användargrupp redan börjat delta på Sprint Demonstrationer med syfte att väcka idéer till det kommande gränssnittet men också för att lära sig hur arbetet enligt Scrum går till.

Användarmedverkan beskrevs 1995 av Standish Group som den största felorsaken till att IT-projekts misslyckande (The Standish Group, 1995). I samtliga projekt involveras använ-dare i någon grad. Två av projekten involverar direkta slutanvändare medan det tredje till-lämpar s.k. domänexperter (Gulliksen & Göransson, 2002).

I Scrum finns inga uttalade rutiner för att involvera slutanvändare i systemutvecklingen (Schwaber & Beedle, 2002). Däremot kan arbetssättet med Sprint Review månadsvis med demonstration likt det som används i det sist beskrivna projektet skapa ett enkelt forum för att få in användaråsikter. Med detta arbetssätt försvinner med problemen med att använda-

46

re endast involveras tidigt eller sent i projektet som Eriksson (2007) beskrev eftersom Sprint Review genomförs i givna tidsintervaller. Att kontinuerligt involvera användare säk-rar att det slutliga informationssystemet överensstämmer med användarnas önskemål. Keil et al (1998) menade att detta varit en orsak till misslyckande av IT-projekt. Att stämma av månadsvis med användare vid varje Sprint Review gör att användarnas åsikter kontinuerligt uppdateras i systemutvecklingsprojektet.

Graden av användarmedverkan är däremot en valmöjlighet beroende på projektets natur. I det först beskrivna projektet har det aktivt valts bort att inte ha med referensgruppen på Sprint Review och istället valt att informera denna i andra forum. I tredje projektet däremot involveras referensgruppen vid Sprint Review. Att bjuda in slutanvändarna till Sprint Revi-ew kan vara en bra väg att gå eftersom en visualisering av det färdiga systemet kan ge ett ut-tryck för bra diskussioner enligt Schwaber & Beedle (2002).

Det faller inom projektstyrningens ansvar att involvera användare i olika grad. Att reflekte-ra över är dock användarkompetensen. En Product Owner menade att användarna egentli-gen bara kan påverka användargränssnittet. Finns det däremot slutanvändare med system-vetenskapskompetens ska givetvis kunskapen tas till vara likt det första projektet som be-skrevs. I det här projektets fall är det ju faktiskt dessa systemförvaltare som är slutanvända-re av administrationsverktyget.

Att plocka in framtida användare tidigt redan innan likt det sista projektet som beskrevs i det sista projektet är positivt. Scrum innefattar en del nya sätt att arbeta på och en inskol-ningsperiod kan då vara att föredra

5.2.1 Bättre med Scrum?

Likt ledningsstöd finns inget direkt stöd för användarmedverkan i Scrum.

Skillnaden i hur användare har involverats pekar på att tydliga rutiner för hur användar-medverkan ska ske i Scrum saknas. Att betänka är däremot att projektens natur gör att an-vändarna ska engageras på olika sätt. Det skiljer sig åt i att utveckla ett mellanlager där slut-användaren egentligen är andra system och ett informationssystem som ska användas av människor.

Till en viss mån kan användarmedverkan på Sprint Review leda till bättre IT-projekt. Scrum kan ge bättre stöd för användarmedverkan i uttryck av att låta användare delta på Sprint Review. I de fall kan där många slutanvändare finns kan representanter komma och representera slutanvändargruppen. Product Owner och Scrum Master måste i det här fallet vara noggranna i hur användarmedverkan ska gå till i systemutvecklingsprojektet.

47

5.3 Projektstyrning

Dålig projektplanering gör att IT-projekt misslyckas menar Whittaker (1999). Scrum å andra sidan tar i sin form avstånd från traditionella projektmodeller och anammar ett mer fritt angreppssätt. Dagliga möten, tidsestimering i bananer samt självstyrande projektgrup-per är alla typiska kännetecken för Scrum.

En stor skillnad mellan Scrum och tidigare systemutvecklingsmodeller är förespråkandet av en aktiv Product Owner (Schwaber & Beedle, 2002). Samtliga Product Owners besöker Daily Scrum ett par gånger i veckan för att snappa upp frågeställningar som huvudprojektet behöver ta ställning till och ställa frågor till gruppen. Att Product Owner deltar på möten anses som bra av systemutvecklarna då de kan ställa frågor direkt till denne.

”Ibland ringer både jag och Product Owner till samma person och frågar samma sak”

Ovanstående citat är hämtat från en av intervjuerna där en Scrum Master beskrev rollför-delningen mellan sig och Product Owner tidigt i projektet. Ju längre projektet gått desto bättre anser Scrum Master att rollfördelningen blivit och numera springer hon och Product Owner inte varandras ärenden. Övriga Product Owners och Scrum Masters anser att an-svarsfördelningen mellan rollerna är bra. I samtliga projekt förekommer nästintill daglig kontakt på telefon eller email och som beskrevs ovan besöker även Product Owner Daily Scrum. Den nära kontakten mellan Product Owner och Scrum Master minimerar risken för missförstånd och en otydlig rollfördelning. Hullberg (2003) menade att en otydlig rollför-delning mellan beställare och systemleverantör är en källa till att IT-projekt misslyckas. Att klargöra vem som är ansvarig för vad anses vara särskilt viktigt initialt i projektet men mås-te genomsyra hela projektet.

Stycket ovan visar på att Scrum faktiskt ger en tydligare ansvars och rollfördelning mellan beställare och systemleverantör blir bättre vid en korrekt tillämpning av Scrum. Mina in-tryck från intervjuerna är att rollfördelningen är en viktig faktor för att lyckas. Att bara utse en Product Owner räcker inte. Denne måste vara aktiv i projektet och exempelvis besöka Daily Scrum, precis som de intervjuade Product Owners gör.

Att projekt bemannas utifrån tillfälliga resurser är ett problem som sägs leda till misslyckade IT-projekt (Hullberg, 2003). På fallföretaget sätts projektgruppen samman efter att projekt-ledaren/Scrum Master fått äska de resurser som krävs för att utveckla det efterfrågade in-formationssystemet. Scrum Masters menar att förståelsen för uppgiften och rätt kompetens för uppgiften som ska utföras är avgörande för att få rätt resurser till projektet. Däremot går det inte att hänföra just resurshantering till Scrum utvecklingsmodell ofta väljs när pro-jektet är bemannat.

”Det är som vilket projekt som helst”

Citatet ovan är hämtat från en Scrum Master som beskrev skillnaden mellan ett Scrum-projekt och ett traditionellt projekt på fallföretaget. En annan Scrum Master valde att be-skriva sin roll som Scrum Master med orden:

”Jag är som en betjänt”

48

Skillnaderna mellan en Scrum Master och en projektledare beror alltså på vem som inter-vjuas. En Scrum Master anser att det inte är några större skillnader i rollen. Ett stort fokus i Scrum är att Scrum Team ska kunna arbeta utan störningar och att det är Scrum Masters uppgift att röja undan hindren (Schwaber & Beedle, 2002). En Scrum Master menar att un-danröjande av hinder görs av projektledaren eller Scrum Master oavsett om Scrum eller nå-gon annan systemutvecklingsmodell tillämpas. Respondenten som liknar Scrum Master-rollen med en betjänt menar också att det som Scrum Master innebär mindre arbete. Pro-duct Owner och Scrum Team tar i Scrum ett större ansvar för projektet och Scrum Master kan istället fokusera på andra uppgifter.

Den tredje Scrum Mastern som intervjuats har ingen tidigare erfarenhet av projektledning och har därför svårt att göra en jämförelse med tidigare arbetssätt. Åsikten är däremot att en Scrum Master arbetar mer tillsammans med teamet. Scrum Master har ett tydligt fokus på att styra och planera det som ska genomföras i projektet den närmsta tiden, istället för att arbeta med att följa upp det om redan slutförts.

Schwaber (2004) menar däremot till skillnad från respondenterna att det innebär ett större ansvar att vara Scrum Master än projektledare. Om det går att sätta likhetstecken mellan ansvar och arbetsbelastning är inte helt korrekt. Intervjuerna pekar däremot på ett mer kol-lektivt ansvar för systemutvecklingsprojektet.

I och med att Daily Scrum genomförs kontinuerligt dagligen sker en kontinuerlig uppfölj-ningsaktivitet för att kunna styra projektet framåt. Samtliga intervjuade respondenter anser att de dagliga mötena är bra. Bland systemutvecklarna är det särskilt populärt att kunna träffas dagligen för att rapportera framsteg i enskilda systemutvecklingsaktiviteter. Med Scrum som modell för systemutveckling och i synnerhet Daily Scrum som ceremoni menar flera systemutvecklare att de får ett tillfälle att ventilera sina funderingar och problem i hela projektgruppen. Enligt flera systemutvecklare har det i äldre systemutvecklingsmodeller funnits utrymme för att, som de uttrycker det:

”Smita undan med problem och återkomma efter någon vecka”.

Ett ledord i Scrum är just öppenheten i gruppen och att berätta om vilka problem som finns (Schwaber & Beedle, 2002). Med detta angreppssätt kan Scrum Master direkt angripa de problem som uppkommer i projektet. En utvecklare berättade att om arbetet sker efter en kravspecifikation och en svårighet uppkommer är det lätt att bara släppa det kravet och arbeta vidare. Mot slutet av projektet blir det då hetsigt att hinna med eftersom alla svåra uppgifter sparats till slutet. Tidsplanen spricker och projektet bedöms som misslyckat.

Hullberg (2003) menade att ett problem i IT-projekt tidigare varit att problem inte vidtas direkt. Att förstöra stämningen i projektgruppen med ett problem har ansetts vara negativt då god stämning i gruppen ansetts som en framgångsfaktor för IT-projekt. Scrum ger med Daily Scrum ett naturligt forum för att hantera problem i IT-projekt. Att dagligen väcka frågan om vilka problem som finns gör att ordet problem får en mindre negativ klang. Att i ett öppet forum med alla samlade ta upp de problem som finns dagligen gör att ansvaret för att lösa problemen hamnar hos hela Scrum Team och inte hos den enskilde systemut-vecklaren. Att lösa problem direkt gör också att risken för dyra korrigeringar senare i pro-jektet uteblir eftersom problemen redan är kända.

49

I detta skede framstår ett tydligt tecken på att Scrum Master och Product Owner måste ha ett nära samarbete. Flera respondenter har påtalat att problem som finns i projektet kan ligga utanför Scrum Teams mandat. Då måste verksamheten som ska nyttja informations-systemet fatta ett snabbt beslut för att arbetet i Scrum Team inte ska avstanna. Att som i de studerade projekten ha Product Owner med på Daily Scrum är ännu bättre då systemut-vecklarna direkt kan föra fram de problem de har till Product Owner. Det går då förmodli-gen ännu snabbare att lösa problemet istället för om Scrum Master måste kontakta Product Owner som sedan ska diskutera med verksamheten, som i sin tur måste fatta ett beslut. Därefter ska beslutet skickas tillbaka till Scrum Team via Scrum Master och Product Ow-ner. Om Product Owner får reda på problemet direkt bör lösningen kunna ta en snabbare väg och risken för förseningar kan minska.

Även om erfarenheter med öppenhet i projektet med Scrum mestadels är positiva finns det även en del negativa aspekter att ha i beaktande.

Nästan samtliga respondenter påpekar att de tror att Scrum inte passar för alla människor. Flera respondenter har påpekat att:

”En del människor trivs inte med att sitta och tala öppet dagligen om sina problem”

Vissa föredrar att sitta och klura ensam i ett par dagar och sedan redovisa lösningen för projektgruppen.

En av de intervjuade Product Owners påpekade att just att komma upp med problem di-rekt även ger projektet ett bättre driv framåt. Respondenten tror att ett högt tempo redan från start i projektet ger en jämnare arbetsbelastning i hela projektet. Att arbeta i månads-långa sprintar leder också till att tempot i projektet hålls uppe enligt samma Product Ow-ner. I äldre systemutvecklingsmodeller förekom en risk för att systemutvecklarna kunde vaggas in i en falsk trygghet och tro att det var gott om tid i projektet eftersom tiden mellan de olika systemleveranserna var lång. Med sprintar på en månad måste systemutvecklarna hela tiden arbeta aktivt för att nå de mål som satts upp för sprinten.

Att just använda sig av sprintar som varar i en månad anses som mindre fördelaktigt av en annan Product Owner som menar att det blir för lite tid till arbete med systemutveckling. Varje sprint ska inledas med en Sprint Planning och avslutas med en Sprint Review (Schwaber & Beedle, 2002). En Product Owner menar att för att hinna med att skapa nå-got som går att demonstrera och vara färdigtestat på fyra veckor är komplext. En del upp-gifter tar naturligt längre tid att genomföra och går inte att hetsa fram. Därför borde en större flexibilitet byggas in i Scrum där sprintar kan förlängas men i vissa fall också förkor-tas. Att hetsa fram något på fyra veckor kan i vissa fall vara komplext. En systemutvecklare menar också att det är svårt att gå ner ordentligt på djupet i en frågeställning när tidsramen är satt till en månad. Scrum kan på så vis leda till nya problem inom systemutveckling.

En viktig del i projektstyrning är att ha en tidsplan och följa den. För att bättre lyckas med tidsestimering i Scrum tillämpas Planning Poker (Gustavsson, 2007). De som deltar i kort-spelet är Scrum Master och Scrum Team. Hur mycket varje siffra i kortleken är värd finns det olika sätt att få fram. Ett Scrum Team definierade tidigt åtta med hjälp av en aktivitet som för alla hade en enig tidslängd. När de beslutat åttans värde kunde de enkelt värdera de

50

andra aktiviteterna mot den aktiviteten som bestämt åttans betydelse. Ett annat Scrum Team har känt sig fram lite och erfarenhet från tidigare sprintar har fått spela in.

För att tidsestimera visar alla spelare det kort med den siffra de anser en specifik aktivitet ska ta. Om alla är överens fastställs den angivna tidsåtgången. Vid olika siffror diskuterar deltagarna en stund och alla får ge sin motivation till varför de valt en viss siffra. Sedan drar alla en siffra igen och då är Scrum Team förhoppningsvis överens. Gustavsson (2007) be-skriver Planning Poker på ett liknande sätt men inte nyttan med spelet. Under observatio-nen diskuterades just Planning Poker och Scrum Master exemplifierade hur bra det var att använda det vid tidsuppskattning. Vid väldigt skilda siffror kan det vid motiveringen exem-pelvis komma upp att en systemutvecklare gjort samma sak i ett tidigare projekt. Något som inte övriga visste om när de valde sina siffror.

Exemplet ovan får mig att tro att systemutvecklarna som arbetar i projektet tillsammans kan göra en god tidsuppskattning. Fler åsikter och diskussion borde leda till en mer realis-tisk tidsuppskattning än om en projektledare sitter och estimerar själv.

Under rubriken ledningsstöd diskuterades statusrapportering som projektuppföljning. Två av de Product Owners som intervjuats har poängterat att en viktig del i Scrum är artefakten Burndown Chart. Att ha den tydligt uppsatt i ett rum gör att Product Owner, men även andra intressenter enkelt kan gå in och få en snabb överblick över vad Scrum Team i den stunden håller på med och hur de ligger till tidsmässigt i den aktuella sprinten.

Andersen (1994) menade att projektstyrning kunde uteslutas eller innefattas i systemutveck-lingsmodeller. Framgångarna för Scrum på fallföretaget kopplat till exempelvis Burndown Chart och Daily Scrum kan innebära ett samband mellan lyckade IT-projekt och använd-ning av en systemutvecklingsmodell som innefattas av projektstyrningsaktiviteter.

Kompetens inom IT, verksamhet och projektstyrning är av vikt för att lyckas med ett IT-projekt (Hullberg, 2003). Kompetensen kring både IT och projektstyrning är i samtliga pro-jekt hög. Scrum Masters har utbildning i både Scrum och Props. Två av tre Scrum Masters har erfarenhet av att leda projekt sedan tidigare medan den tredje gör sitt första. De Pro-duct Owners som intervjuats har samtliga systemvetenskaplig bakgrund. Samtliga är även inhyrda från olika organisationer, varav en från systemleverantörsorganisationen. Verksam-hetskompetensen står projektgruppen i beställarorganisationen för. Dessa är däremot inte i daglig kontakt med gruppen utan träffas månadsvis vid Sprint Review.

5.3.1 Bättre med Scrum

Det är inom projektstyrning som Scrum skiljer sig mest gentemot tidigare systemutveck-lingsmodeller. Ett nära bättre samarbete mellan beställarorganisation och systemleveran-törsorganisation är en förutsättning för att lyckas även om det i början kan vara ovant in-nan rollerna sätter sig. En aktiv Product Owner är ett måste för att få projektet att fortgå. Det räcker inte bara med att utse en Product Owner utan denne måste också delta aktivt i projektet.

Styrkan med Scrum är den dagliga uppföljningen med Daily Scrum. Projektet får ett bättre driv då alla problem kommer upp på ytan med en gång. Detta arbetssätt ger också gruppen

51

ett större ansvar för att lösa problemet istället för den enskilda systemutvecklaren eller Scrum Master. Att betänka är dock att alla människor inte gillar att prata om problem viket kan leda till bekymmer och osämja i projektgruppen.

En stor skillnad gentemot tidigare modeller är att projektgruppen hela tiden är med och planerar projektet. Gruppen har gemensamt ansvar för att estimera tidsåtgången för aktivi-teterna. Att fler får ha synpunkter på tidsestimering borde leda till en mer korrekt tidsupp-fattning och på sikt leda till att projektet håller tiden. Att hela gruppen är med kan också ses som negativt då värdefull tid för systemutveckling försvinner.

Kritik finns också mot att avstämning månadsvis är för ofta eftersom tid för test och plane-ring ska hinnas med inom tidsperioden. Det blir för lite tid kvar för att skapa något funge-rande att visa upp på Sprint Review. Kritik förekommer också mot att sprinter månadsvis inte sammanfaller med statusrapportering i Props. Svårigheterna med Scrum är att hantera Scrum vid längre tidsperioder. En del aktiviteter kräver längre sprintar vilket kan utgöra problem i projektplaneringen, framförallt i början av projektet när arkitekturen kring sy-stemet byggs upp. Samtidigt kan Scrum ge bättre projekt eftersom den innehåller artefakter som underlättar projektstyrningen.

52

5.4 Kravhantering

De studerade projekten på fallföretagen har samtliga påbörjats med en förstudie där en kravspecifikation tagits fram. Denna kravspecifikation har sedan arbetats om till en Product Backlog på två olika sätt. I ett projekt översattes den direkt av Scrum Master på egen hand. De andra två studerade projekten arbetade också om en ursprunglig kravspecifikation. Skillnaden från det tidigare exemplet var att aktiviteten genomfördes av mer än en person. Scrum Master genomförde omarbetningen tillsammans med delar av Scrum Team. En Scrum Master menar att en kravspecifikation är bra att utgå från men för att tillämpa Scrum fullt ut krävs ingen kravspecifikation. Kraven ska komma in kontinuerligt från Product Owner.

Att Product Backlog är ett levande dokument vittnar de intervjuade respondenterna om.

”Det förekommer både stora och små förändringar”

Flera Scrum Masters påpekar ovanstående citat i intervjuerna. Omprioriteringar görs konti-nuerligt av Product Owners. Krav läggs till men tas också bort från Product Backlog. En intervjuad systemutvecklare menar:

”Jag har fått slänga fungerande kod”

En annan systemutvecklare menar att de förändringar i krav som uppkommer i projektet tas upp på Sprint Planning Meeting och endast berör framtida sprintar och inte det som re-dan varit. Däremot anser samtliga systemutvecklare att arbete med förändrade krav funge-rar bra.

En Product Owner berättar att det är hon som ”äger” Product Backlog. Förändringarna görs av henne själv samt av projektgruppen från beställarorganisationen. Scrum Master och systemutvecklare från detta projekt delar samma uppfattning vad gäller ägandet av Product Backlog. Systemutvecklaren menar att Product Owner ”måste” prioritera om kraven konti-nuerligt för att Scrum Team ska ha något att göra och för att driva projektet framåt. Görs inte detta står projektet stilla. Product Owner i aktuellt projekt känner till sin kritiska roll och arbetar aktivt med Product Backlog för att gruppen ska ha arbetsuppgifter.

Kommunikationen mellan systemutvecklarna i Scrum Team och Product Owner fungerar bra i de studerade projekten. De Product Owners jag intervjuat har samtliga en bakgrund inom IT och systemvetenskap. Denna bakgrund menar både systemutvecklare, Scrum Mas-ters och Product Owners vara en bidragande orsak till att det är enklare att samtala på Sprint Review. Systemutvecklarna tror att kommunikationen varit svårare om Product Ow-ner inte haft systemvetenskaplig bakgrund. Även Product Owners anser att deras bakgrund är avgörande och märker det främst under Sprint Review där även personer med annan kunskapsbakgrund medverkar vilken fördel det är. Systemutvecklarna kan ibland ha svårt att förklara för beställarorganisationen hur projektet ligger till utan att gå in på tekniska de-taljer. En Product Owner menar då att hon fungerar som tolk mellan systemutvecklare och beställarorganisation.

Kravhantering är det andra området där skillnader mellan olika systemutvecklingsmodeller märks tydligt. Som redan beskrivits samlas alla krav in från början i vattenfallsmodellen.

53

Kraven fryses och förändringar i kraven är näst intill omöjligt (Avison & Fitzgerald, 2006). Detta ansågs redan på 80-talet ohållbart och de iterativa och inkrementella modellerna togs fram. Mot slutet på 80-talet kom Boehms (1988) Spiralmodell. Återkoppling till kunden togs upp som viktigt och Boehm hävdade att avstämning skulle ske efter varje varv i spira-len.

Att kunna förändra kraven under systemutvecklingsprocessen ses numera som en självklar-het trots att The Standish Groups rapport (1995) visat på att förändrade krav leder till miss-lyckade IT-projekt. Scrum förespråkar att Product Backlog ska vara ett levande dokument som ständigt förändras. Krav ska kunna läggas till, tas bort och prioriteras om allt efter kundens önskemål (Schwaber & Beedle, 2002).

Arbete med en ständigt förändrad Product Backlog leder till att problemen med att alltför övergripande krav eller inga krav alls som Hullberg (2003) beskrev försvinner. Eftersom genomgång av krav sker kontinuerligt tvingas Product Owner att precisera vad som ska finnas med i det färdiga informationssystemet. Product Backlog blir ett levande dokument och Product Owner tvingas även kommunicera direkt med Scrum Team på Sprint Planning Meeting. Detta reducerar problemet som Eriksson (2007) påpekade. Dålig kommunikation mellan beställare och systemutvecklare kan leda till sämre informationssystem (Eriksson, 2007).

Som Schwaber & Beedle (2002) beskrev sker en uppbrytning av stories på Sprint Planning Meeting till uppgifter. I Scrum finns alltså rutiner för att precisera och konkretisera krav. Detta görs på Sprint Planning Meeting, mestadels av Scrum Team och Scrum Master men också med stöd av Product Owner. Det är Scrum Team som omsätter kraven till uppgifter vilket styrker Knibergs (2007) resonemang om att Product Owner ska fokusera på verk-samheten i sin utformning av önskemål.

Whittaker (1999) menar att missförstånd i krav är en bidragande faktor för att IT-projekt misslyckas. Enligt Kniberg (2007) är det ett måste att Product Owner ska delta på Sprint Planning Meeting. Att ha en Product Owner som deltar på Sprint Planning Meeting gör att samtliga nyckelpersoner i projektet är med vid kravhanteringsarbetet varje månad. Detta samarbete månadsvis torde leda till bättre kommunikation och mindre missförstånd mellan systemleverantör och beställarorganisationen. Bakgrunden inom IT och systemvetenskap hos Product Owners i de studerade projekten är en bidragande orsak till att kommunika-tionen fungerar bra.

Enligt Scrumteori är det som tidigare skrivits beställarorganisationens och Product Owners uppgift att ansvara för Product Backlog. Kundens10 vilja ska alltid sättas först (Schwaber & Beedle, 2002). De projekt som studerats i undersökningen har däremot delvis frånsett det här tankesättet och flera respondenter menar:

”Kunden kan inte alltid ha rätt”

10 I detta fall Product Owner och beställarorganisationen.

54

Att kunden endast ska prioritera kraven och styra projektets väg anses av flera responden-ter vara nästintill omöjligt. Respondenterna menar att för att skapa bra informationssystem behöver exempelvis den övergripande strukturen för informationssystemet skapas först.

Systemutvecklaren i ett projekt berättar att de får ha åsikter om prioriteringen på Sprint Planning Meeting. Product Owner lyssnar och tar till sig av Scrum Teams åsikter. Det kan förekomma att Product Owner vill att en specifik funktion ska skapas under en sprint. Just den funktionen kan av natur vara omöjlig att skapa om inte två andra funktioner skapas före.

Även i exemplet här märks det att det är en fördel att ha en Product Owner med en bak-grund inom systemvetenskap. För en Product Owner med bakgrund inom IT är det inte svårt att acceptera att den grundläggande strukturen ska byggas först. Om det är svårt för en icke systemvetenskapligt insatt person att förstå kan inte studien svara på då ingen sådan respondent ingått i studien.

En respondent menar att Scrum är ett nytt ord på gamla saker.

”Kalla det Scrum eller evolutionär utveckling. Det är i stort sett samma sak”

Att påpeka att Scrum är något nytt och revolutionärt tillvägagångssätt är därför fel väg att gå enligt respondenten. Istället ska de bra delarna av Scrum tas tillvara och implementeras i befintlig arbetsmetodik.

En svaghet med den evolutionära systemutvecklingen anses vara att det saknats en metod för att tillämpa spiralmodellen (Boehm, 1988). Scrum innebär ett nyare sätt att se på evolu-tionär utveckling med ett tydligare fokus på människor än på risker som är utgångspunkten i evolutionär systemutveckling. Boehm (1988) menar även att evolutionär utveckling passar bäst internt i organisationer. Här syns ett samband mellan fallföretaget och teorin. Samtliga intervjuade anser att Scrum fungerar bra i projekten. Som skrivits ovan finns det kritik mot vissa punkter men de intervjuade respondenterna har överlag varit mer positiva än negativa till Scrum.

5.4.1 Bättre med Scrum?

Rutiner för kravhantering i Scrum innehåller mycket som är taget från iterativ och inkre-mentell utveckling. Största skillnaden är att Scrum påpekar att det är Product Owner som äger Product Backlog. Detta tar sig i uttryck att projektet kan stå still när inga krav är priori-terade och att Product Owner är med vid Varje Sprint Planning Meeting.

Att aktivt arbeta med kravhantering ger bättre och mer specifika krav. En deltagande Pro-duct Owner på Sprint Planning Meeting tvingas precisera vad hon vill ha ut av systemet.

En Product Owner med bakgrund inom IT kan vara en fördel att ha då denne kan ha enk-lare för att förstå Scrum Team i diskussioner kring krav.

Kraven har förändrats en del i de studerade projekten. Kod har fått slängas i ett projekt medan andra projekt menar att det endast är det som inte är färdigt som stryks från pro-duct Backlog. Inget system är perfekt från början och möjligheten att jobba aktivt med kra-

55

ven i hela utvecklingsprocessen är därför viktig, även om det i vissa fall kan bli nödvändigt att göra sig av med fungerande kod.

56

5.5 Kodning och test

IT-projekt kan även misslyckas på grund av fel i test. Dåligt utförda tester och bristande testdokumentation är två av problemen som finns (Eriksson, 2004).

Det råder delade meningar om rutiner för test i Scrum bland respondenterna. Två Scrum Masters menar att:

”Enhetstester är en del av en Systemutvecklares arbetsuppgifter”

Ett projekt har infört frysning av kod, som innebär att systemutvecklarna slutar program-mera två dagar innan Sprint Review, detta för att hinna med test och eventuellt hinna kor-rigera innan Sprint Review. En Scrum Master menar att koden behöver frysas tidigare egentligen men tiden behövs för att hinna med de planerade aktiviteterna i sprinten. Pro-duct Owner i samma projekt vill också gärna hinna testa koden innan Sprint Review.

En annan Scrum Master menar att tester indirekt finns i Scrum. Respondenten menar att:

”Allting som presenteras på en Sprint Review ska vara testat och klart.”

Om mjukvaran inte är färdigutvecklad eller testad ska den inte heller kunna presenteras på en Sprint Review.

Systemutvecklarna genomför enhetstester både av sin egen kod men även när det är möjligt på de övriga projektdeltagarnas. Om det regleras enligt Scrum eller i någon annan utveck-lingsmodell kan de däremot inte svara på. Gränserna mot XP är otydliga enligt en utveckla-re. Enhetstester ingår antingen i Scrum, XP eller i ramverket11 som används på fallföretaget. Det spelar däremot ingen roll vilken modell testerna ingår i enligt en respondent eftersom modellerna ofta går i varandra. Det som spelar roll är att det agila tänkandet ska finnas med hela tiden. Med det agila tänkandet menas framför allt att ständigt vara beredd på förändra-de önskemål från kunden och

De systemutvecklare jag har intervjuat enhetstestar sin egen kod. En systemutvecklare be-rättar att han enhetstestar sin kollega i projektets kod. Detta möjliggörs främst enligt re-spondenten av att de delar rum med varandra. Acceptanstester från användare och bestäl-larorganisation kommer in senare i systemutvecklingsprojektet. Att det kommer in sent be-ror på att det tidigt inte finns mjukvara att utföra acceptanstest mot. Inga speciella testare förekommer i de Scrum Teams som undersökts i studien utan test sker uteslutande inom gruppen och bland projektets olika intressenter.

Skilda och otydliga svar från respondenter tyder på att Scrum saknar tydliga rutiner för test. Även avsaknad av klara direktiv i handböcker, förutom att presentera körbar kod på Sprint Review tyder på att ämnet är komplext.

Att enhetstesta samt visa upp körbar kod på en Sprint Review räcker inte för att betrakta systemet som färdigtestat. Kniberg (2007) förespråkar att testare ska inkluderas i projektet

11 Med ramverk menas regler och standarder för programmering (egen definition, skapad efter uppgifter i in-tervjuer).

57

eftersom systemutvecklare har en förmåga att bara testa systemet i en optimal miljö och på ett ändamålsenligt vis. Antalet aktiviteter i varje sprint behöver minskas ner för att hinna med att testa ordentligt (Kniberg, 2007).

Den empiriska studien har också visat att test är svårt att hinna med. Åsikten här är där-emot istället en inbyggd flexibilitet i sprintlängden. Korta sprinter kan innebära bekymmer då frågeställningar inte blir fullständigt lösta menar en Product Owner. Anledningen är att systemutvecklarna inte hinner utan tvingas göra en lösning som går att redovisa på Sprint Review. Det tas alltså inte fram den bästa lösningen utan en endast en fungerande. Försla-get från respondenten var att ha mer flexibla sprinter avseende längd för att på så sätt ut-veckla mjukvara med en högre kvalitet. En systemutvecklare menar även att korta sprinter ställer högre krav på kodningen. Det är mer komplext att koda något som ska redovisas tre veckor sedan än tre månader senare.

Att fel upptäcks och inte hinner korrigeras i tid (Eriksson, 2004) har förekommit i ett av de studerade projekten. Just den här diskussionen togs upp under observationen om hur pro-jektet skulle hantera att inte allt var helt klart till driftsättning. Beslutet blev att förlänga den sista sprinten med ett par veckor för att se till att bli klar med de viktigaste delarna. De åter-stående kraven i Product Backlog lämnades kvar till förvaltningen.

Att fel uppstår i kodningen men förblir oupptäckt beskrevs av Eriksson (2004) som ett problem. Whittaker (1999) menade däremot att fel i kodning inte varit lika frekvent som andra problem, exempelvis fel i krav. Den dagliga kontakten i Scrum Team, test av egen och andras mjukvara, kontinuerlig demonstration för beställarorganisationen kan däremot göra att fel enklare upptäcks och kan korrigeras. Direkta rutiner för att koda rätt saknas däremot inte bara i Scrum utan också i tidigare systemutvecklingsmodeller.

En respondent påpekar i intervjun att det finns brister i dokumentationen kring Scrum och ser framför sig att dokumentationen kommer innefatta en mapp med Post-it-lappar. Det blir därmed svårt att vidareutveckla system som utvecklats med Scrum i framtiden. Re-spondenten påpekade då att de valt att inte ta till sig Scrums rutiner dokumentation utan valt att dokumentera mer omfattande. Det agila manifestet förespråkar Fungerande pro-gramvara framför dokumentation (Higsmith, 2001). För att ha fortsatt fungerande pro-gramvara även i förvaltningen krävs däremot bra dokumentation. Eriksson (2004) hävdar att ett problem i IT-projekt är att utvecklare inte vet vilka fel som ska åtgärdas eftersom testdokumentationen har brister.

5.5.1 Bättre med Scrum?

Kodning och test är det som Scrum fokuserar minst på och det speglar också responden-ternas svar. Ingen vet klart och tydligt var gränserna går mellan Scrum, XP och det ramver-ket som används på fallföretaget.

Testare ingår inte i de undersökta projekten. Istället testas den egna koden av en själv eller av andra systemutvecklare i projektet. Acceptanstester kommer att förekomma i slutet av projekten.

58

Scrum brister i dokumentationen då körbar kod sätts före systemdokumentationen. Det blir då svårt att föra över systemet till förvaltning då ordentlig dokumentation saknas från systemutvecklingsprojektet.

Att leverera körbar kod ska inte alltid ses som positivt då lösning kan hetsas fram istället för att tänkas genom ordentligt först.

59

6 Slutsatser och Reflektion

I kapitlet Slutsatser och Reflektion sammanfattas det som undersökningen kommit fram till. Det ges i ka-pitlet även ett par förslag för fortsatt forskning.

6.1 Slutsatser

Slutsatserna är indelade i två kategorier där den första kategorin är välunderbyggda slutsat-ser. Den andra kategorin är indikationer som framkommit i studien.

6.1.1 Väl underbyggda slutsatser

� Likt tidigare systemutvecklingsmodeller saknas det i Scrum direkt ledningsstöd. Där-emot kan ett aktivt ledningsdeltagande på Sprint Review ge bättre IT-projekt.

� Product Owner rollen kan utgöra ledningsstöd och med detta synsätt förekommer ett aktivt ledningsdeltagande i hela projektet.

� Medverkande användare på Sprint Review kan leda till bättre IT-projekt.

� En aktiv Product Owner och uppföljning dagligen ger ett bättre driv i projektet och är avgörande för om ett IT-projekt ska lyckas eller inte.

� Problem blir en kollektiv fråga med Scrum och lösningar tas fram gemensamt inom gruppen.

� Sprint Planning Meeting ger ett naturligt forum för kontinuerligt arbete med krav. Kon-tinuerligt arbete med krav leder i sin tur till ett bättre informationssystem.

� Scrum saknar tydliga rutiner för att koda och testa.

6.1.2 Indikationer

� Stora skillnader i system gör det svårt att ta fram bestämda rutiner för användarmed-verkan i IT-projekt.

� Tidsestimering tillsammans i Scrum Team ger en mer realistisk tidsuppskattning och större möjlighet att hålla den övergripande tidsplanen.

� En systemutvecklingsmodell med projektstyrningsartefakter kan ge bättre IT-projekt än systemutvecklingsmodeller som bortser från det.

� En Product Owner med systemvetenskaplig bakgrund ger större möjlighet till ett lyckat IT-projekt.

� Månadslånga sprinter är för kort om något kärnfullt och genomarbetat ska hinna pro-duceras.

60

� För många aktiviteter i sprinter gör att test inte hinns med.

� Att leverera färdig mjukvara till Sprint Review behöver inte alltid vara positivt. Lös-ningar kan tvingas fram för att ha något att visa upp på Sprint Review.

� En Product Owner som inte arbetar aktivt i projektet kan stjälpa hela projektet.

6.2 Sammanfattande värdering

Syftet med uppsatsen var att studera om användning av den agila modellen Scrum kunde reducera de problem som finns i IT-projekt idag. Studien har pekat på att Scrum reducerar de problem som främst finns inom projektstyrning och ger en del nya arbetssätt för att ar-beta med kravhantering. Att däremot se Scrum som ett paradigmskifte (Schwaber, 2004) är att ta i. Scrum kan med fördel istället användas som en best practice som Jacobsson (2009) menar.

Ledningsstöd är svårt att föra in i en modell då olika projekt kan vara av olika svårighets-grad. De projekt som studerats har inte haft några större problem och inte krävt åtgärder från ledning på det sätt. Ledningsstöd är något som därför bör ske utifrån projektets förut-sättningar. Att däremot komplettera Scrum med Props gör att uppföljning sker kontinuer-ligt, men om projektuppföljning och ledningsstöd är något att sätta likhetstecken mellan vill jag inte spekulera i. Däremot har studien pekat på att en deltagande ledning på Sprint Revi-ew uppfattas som positivt.

Användarmedverkan har inte heller tagits upp i modellen men förutsättningar har skapats i och med olika möten främst Sprint Review. Det kan vara svårt att föra in användarmedver-kan i modeller då IT-projekt kan vara av olika karaktär. Studien har fokuserat på tre projekt med olika typer av slutanvändare. Slutanvändare kan vara både system och människor med olika kompetens. Denna komplexitet gör det svårt att föra in rutiner i en modell exakt för hur användarmedverkan bör gå till.

Kodning och test har inte heller påverkats nämnvärt. Studien visar att uppfattningar kring framförallt test i Scrum skiljer sig åt mellan respondenterna. Anledningen kan vara att Scrum helt enkelt bortser från test och låter andra modeller och metoder utveckla rutiner för det.

Resultatet av undersökningen skulle kunna visualiseras med bilden Figur 10.

Figur 10 Resultatbild (Egen bild)

61

6.3 Förslag till fortsatt forskning

� Product Owner är en nyckelroll i Scrum, men vem i organisationen passar som detta. Personen som ska ha koll på både teknik och verksamhet, ha möjlighet att delta på mö-ten med Scrum Team, ha ett högt inflytande hos ledningen och dessutom inte ha någon unik utbildning. Med denna utgångspunkt kan det vara intressant att studera om rollen Product Owner finns på riktigt eller bara är en konstgjord figur.

� Det finns en otydlig bild över hur Scrum-projekt överförs från utveckling till förvalt-ning. Det hade därför varit intressant och forska kring det och se om hur Scrum funge-rar i förvaltning.

� Studien har endast genomförts på ej slutförda projekt. Det hade varit intressant och bedriva en liknande studie när projekten är slutförda för att se hur projekten levererat inom kvalitet, tid och kostnad.

� De Product Owners jag intervjuade hade alla systemvetenskaplig bakgrund. Det hade varit intressant att genomföra en liknande studie på projekt där Product Owner endast har verksamhetskompetens.

6.4 Reflektion

Att studera Scrum och systemutveckling har varit intressant. Ämnet är aktuellt och debatte-ras flitigt kring i exempelvis Computer Sweden och på internet. Att skriva om ett ämne som är aktuellt har gjort skrivandeprocessen mer intressant. Det har även varit en förmån för mig att ha möjligheten att göra större delen av skrivandet på plats på fallföretaget. Det har dessutom gett mig input om Scrum i informella samtal på fikaraster och luncher. Att jag även delat rum med en annan student har också bidragit till att uppsatsen är vad den är idag. Diskussioner har förekommit nästan dagligen om Agile, Scrum och XP.

I efterhand har jag funderat lite på vad jag skulle ha gjort annorlunda om jag gjorde under-sökningen igen. Att jag aldrig tillämpade en observation på ett Daily Scrum kan ses som en metodologisk brist. Jag menar däremot att för att undersöka uppsatsens frågeställning hade det inte burit någon frukt att för mig lyssna till vad fem personer gjorde igår och ska göra idag. Samtliga respondenter var även överens om att mötet fungerar bra vilket gjort att det vore svårt att bevisa något annat.

Den andra kritiken jag kan se mot min studie är att jag inte jämfört Scrum direkt med en annan modell. Att jag inte gjort detta beror på två saker.

Jag har hittat två uppsatser12 där den första jämför en agil projektledare med en traditionell projektledare och den andra olika roller i projekt. Att göra en jämförande studie kan leda till att jag hamnar för nära dessa uppsatser och kan bli anklagad för plagiat.

12 Ukiza Justin, P & Bernadotte Af Wisborg Hed, J. (2009) Jämförelse av roller inom olika projekt: Traditionell pro-jektledning och Scrum

62

Den andra orsaken är att den traditionella systemutvecklingsmodellen på fallföretaget inte är specifikt framtagen för företaget. Att jämföra Scrum med denna hade fått till följd att generaliserbarheten av uppsatsen hade kunnat ifrågasättas mer.

Ett sätt att få mer spridning i svaren hade kunnat vara att även intervjua inhyrda konsulter. Eftersom fallföretaget däremot har konsulter från flera konsultföretag kändes det som mindre fruktbart att få intryck från exempelvis tre företag, varav åtta intervjuer från ett fö-retag (Banverket), en från ett annat och en från ett tredje. Urvalet skulle som synes bli för ojämnt fördelat. Att jag delvis varit uppdragsstyrd av ett företag motiverar också till att en-dast intervjua respondenter från ett företag för att få det specifika företagets synpunkter på Scrum.

Att istället jämföra en generell modell med generella problem gör att uppsatsen ger en bätt-re möjlighet till generaliserbarhet eftersom företag använder olika systemutvecklingsmodel-ler. Uppsatsen belyser hur pass bra Scrum ger bättre IT-projekt. Företag kan därmed ta till sig de delar som de tycker är bra och föra in det i sin befintliga systemutvecklingsmodell istället för att ta till sig hela modellen.

Att gå utanför fallföretaget och jämföra med andra företag hade kunnat vara en väg att gå, men jag ansåg att det skulle ta för mycket tid eftersom jag skrivit uppsatsen själv. Då föll istället valet på att göra fler intervjuer på ett företag.

Jacobsen, B. & Engvall, E. (2007) Agil systemutveckling – en jämförelse mellan den agila och traditionella projektledaren

63

Litteraturförteckning

Böcker

Andersen, E S. (1994). Systemutveckling: Principer Metoder och tekniker. Lund: Studentlitteratur.

Avison, D. & Fitzgerald, G. (2006). Information systems development methodologies, techniques & tools. Berkshire: McGraw-Hill Education.

Bansler, J. (1990). Teori och historia i skandinaviskt perspektiv. Lund: Studentlitteratur.

Bryman, A. & Bell, E. (2005). Företagsekonomiska forskningsmetoder. Malmö: Liber.

Eriksson, U. (2007). Kravhantering för IT-system. Lund: Studentlitteratur.

Eriksson, U. (2004) Test och kvalitetssäkring av IT-system. Lund: Studentlitteratur.

Gulliksen, J. & Göransson, B. (2002). Användarcentrerad systemdesign. Lund: Studentlitteratur.

Gustavsson, T. (2007). Agile – Konsten att slutföra projekt. Karlstad: TUK Förlag AB

Hullberg, A-M. (2003). IT-upphandling I praktiken. Lund: Studentlitteratur.

Jacobsen, D-I. (2002). Vad, hur och varför – Om metodval i företagsekonomi och andra samhällsveten-skapliga ämnen. Lund: Studentlitteratur.

Kniberg, H. (2007). Scrum and XP from the Trenches – How we do Scrum. C4media inc. Hämtat 2009-09-15 från http://www.infoq.com/minibooks/scrum-xp-from-the-trenches.

Kruchten, P. (2004) The Rational Unified Process: an introduction. Boston: Pearson Education

Malterud, K. (1998) Validitet. Kvalitativa metoder i medicinsk forskning. Lund: Studentlitteratur.

Schwaber, K. (2004). Agile project management with Scrum. Washington: Microsoft Press.

Schwaber, K. & Beedle, M. (2002). Agile system development with scrum. New Jersey: Pearson Prentice-Hall.

Tonnquist, B. (2006). Projektledning. Stockholm: Bonnier Utbildning.

Wallén, G. (1996). Vetenskapsteori och forskningsmetodik. Lund: Studentlitteratur.

64

Vetenskapliga publikationer

Carlsson, C. (2008). Öka dina chanser med att lyckas med Scrum – Ett ramverk för inkrementellt in-förande av Scrum i en organisation. Hämtat 2010-01-05 från http://gupea.ub.gu.se/dspace/bitstream/2077/10440/1/gupea_2077_10440_1.pdf

Carlzon, L. & Nilsson, L. (2008). Ger ett agilt arbetssätt nöjda beställare? Hämtat 2010-01-05 från http://biblioteket.ehl.lu.se/olle/papers/0003198.pdf

Cronholm, S. (2008). Using Agile Methods? – expected effects. Accepted to the 17th Interna-tional Conference on Informations Systems Development (ISD2008).

Fagerström, B. (2003). IT-användning – En analysmodell för IT-nytta. Doktorsavhandling, Insti-tutionen för industriell ekonomi och samhällsvetenskap. Avdelningen för sy-stemvetenskap, Luleå tekniska universitet.

Forsberg, E. & Lindström, M. (2008). Scrum med XP-relaterade tekniker, Införandet av Scrum och dess påverkan på systemutvecklargruppen. Hämtad 2010-01-05 från http://biblioteket.ehl.lu.se/olle/papers/0003141.pdf

Fälth, K. & Svahn, L. (2003). Parprogrammering – Ökad tidsåtgång uppvägs av dess fördelar? Häm-tat 2010-01-05 från http://www.bth.se/fou/cuppsats.nsf/all/d0801d5b6f392eaac1256d1200383ef2/$file/Parprogrammering.pdf

Hinde, S. (2005 januari). Why do so many IT projects fail? Computer Fraud & Security. Sid. 15-17.

Karlsson, B. (1997). Metodanalys för förståelse och utveckling av systemutvevecklingsverksamhet. Li-centiatavhandling, institutionen för Datavetenskap, Linköpings universitet.

Keil, M., Cule, P-E., Lyytinen, K. & Schmidt, R-C. (1998 november). A Framework for Identifying software project risks. Communication of the ACM. Vol. 41. Nr. 11. sid. 76-83.

Picatilu, P. (2007). IT Project management metrics. Revita Informatica Economicá. Nr. 4.

Schwaber, K. (1994).SCRUM development process. Hämtat 2010-01-05från http://www.jeffsutherland.com/oopsla/schwapub.pdf

Schwaber, K. (1996) Controlled Chaos: Living on the edge. Hämtat 2010-01-05 från http://www.controlchaos.com/download/Living%20on%20the%20Edge.pdf

Strode, D., Huff, S. & Tretaikov, A. (2009). The impact of organizational culture on agile method use. Proceedings of the 42nd Hawaii International Confernce on System Sciences – 2009.

65

Takeuchi, H. & Nonaka, I. (1986). The new new product development game. Harvard busi-ness review. January- February, sid. 137- 146.

The Standish group. (1995). The Standish group report – Chaos. Hämtat 2010-01-05 från http://www.projectsmart.co.uk/docs/chaos-report.pdf.

Turk, D., France, R. & Rumpe, B. (2002) Limitations of agile software process.

Whittaker, B. (1999). What went wrong? Unsuccessful information technology projects. In-formation Management & Computer Security. Sid. 23-29.

Weinoff, A. & Wirström, E. (2009). Vägen till ett lyckat IT-projekt. Hämtat 2010-01-05 från http://liu.diva-portal.org/smash/record.jsf?pid=diva2:228529

Tidningsartiklar

Brundin, S. (2009, 3 februari). Populär utvecklingsmetod. Computer sweden.

Jacobsson, I. (2009 A, juni). Vi är i desperat behov av en teori för mjukvaruutveckling. ON Time. Nr 2 sid. 17-19.

Jacobsson, I. (2009 B, 3 april). Det knakar rejält i Scrums fogar. Computer Sweden.

Jerräng, M. (2009, 20 oktober). ”Miljarder och åter miljarder i sjön”. Computer Sweden.

Larsson, P. (2007). Stora besparingar med lättrörlig systemutveckling. Computer sweden.

Stadigs, J. (2009, 6 november). Het utvecklingsmetod väcker känslor. Computer Sweden. Sid. 12-13.

Sutherland, J. (2008, 21 november). Scrum ledande agil metod. Comuputer Sweden.

Internetkällor

Centrum för informationslogistik. (2009). Informationslogistiken optimerar informationsflöden. Hämtat 2010-01-05 från http://www.cil.se/index.cfm?id=10&l=2 .

Higsmith, J. (2001). History: The Agile Manifesto. Hämtat: 2010-01-05 från http://agilemanifesto.org/history.html

Pagina. (2009) Paginas IT-ordbok. Hämtat 2010-01-05 från http://itord.pagina.se/default.asp?Id=936

66

Bilder

FCI Global (2009). RUP Overview. Hämtat 2010-01-05 från http://www.fciglobal.com/graphics/rup_overview.jpg

Moving Summit. (2009) Burndown Chart. Hämtat 2010-01-05från http://www.movingsummit.co.uk/images/burndown_chart.JPG

Sutherland, J. (2009). Scrum Overview. Hämtat 2010-01-05 från http://jeffsutherland.com/scrum/uploaded_images/scrum-overview-723500.gif

I

Bilaga 1 Observationsschema Sprint review och Sprint Planning

Vem sitter var?

Demonstration

Vem provkör?

Vem frågar?

Vem förklarar?

Var görs demonstrationen?

Teamkänslan

Frågar man team eller scrum master?

Är det vi tillsammans eller enskilda individer som gör något?

Scrum Master

Försvarar hon teamet?

Hyllar hon teamet eller individen?

Svarar hon på frågor?

Scrum Team

Eniga?

Hur lång tid tar det att enas?

Svarar de på frågor?

II

Product Owner

Pratar man om omfattning och vikt

En del av team eller motpart.

Bestämmer beställare över tidsuppskattning?

Vem vänder man sig till

Intressenter

Vilka pratar?

Vad fokuserar de olika intressenterna på?

Har intressenterna något inflytande?

Använder intressenterna sin möjlighet att påverka?

Förhållandet beställare/leverantör

Tydligt/otydligt

III

Bilaga 2 Intervjuguide Product Owner

Vem är du?

Projekt?

Vill du medverka med namn?

Vad har du för bakgrund, utbildning?

Vad har du för roll på din avdelning?

Vad är din erfarenhet av systemutvecklingsprojekt? Tidigare varit med om liknande? OIt andra org.

Varit med om misslyckat IT-projekt?

Har du scrum utbildning?

Inledande intryck

Vad anser du vara den viktigaste faktorn för att lyckas med ett projekt?

Vad är det första du tänker på när jag säger Scrum?

Varför kör ni Scrum i projetktet?

Din roll?

Vad är din roll i Projektet?

Product Owner, produktägare?, beställare? Vad ser du dig som?

Hur utsågs du till Product Owner?

Hur skulle du beskriva din roll till gruppen? Som en motpart eller en med-part?

Känner du att rollfördelningen är tydlig i projektet?

Känner du dig trygg i din roll?

Berätta hur ni jobbar med projektet från beställarsidan?

Hur många är delaktiga i projektet från din del av organisationen?

Hur involverad är din närmsta chef i projeket?

Hur många har fått vara med och komma med önskemål för det kommande syste-met?

Hur stor projektgrupp är ni på beställarsidan?

Vem är slutanvändare?

Hur många Slutanvändare är med i utvecklingsprojeket?

Hur sker uppföljning av projektet?

IV

Berätta om när ni tog fram Backlogen första gången?

Vilka var med?

Hur mycket har förändrats i backlogen under arbetets gång?

Hur arbetar du med Backlogen?

Hur ofta uppdaterar du den?

Hur går du tillväga för att uppdatera den?

Förstår du och utvecklarna varandra? Har ni alltid gjort det?

Hur pass aktivt har förändringsförslag kommit under previewerna?

Hur för du vidare intrycken från previewerna till övriga gruppen?

Förändringsförslag från användare hur kommmer det vidare till utvecklarna?

Berätta om ditt arbete under sprinten?

Endast på sprint review eller kontaktar du scrum master löpande under pro-jektet?

Hur mycket kontakt har du med Scrum Master under en sprint?

Uppfattar du att det är du som bestämmer på sprint reviewen över viktning och omfattning av aktiviteterna?

Har du något inflytande över tidsestimeringen för aktiviteterna?

Vilka roller hade de andra två som var med på mötet idag? Systemförvaltare? Inte slutanvändare?

Hur upplever du sprint reviewen som möte?

Planering av projektet? Har du egen? Eller räcker det med det som görs på sprint planning

Hur många från din organisation är med på reviewerna?

Vad fokuserar du på när det är sprint review? Kvalitet, tid kostnad?

Får ni demo innan eller får du med dig något till sprint reviewen?

Vad tycker du om att hela gruppen är med på sprint reviewerna. Utnyttjar du tillfället att prata med alla.

Berätta om Sprint Planning mötet?

Hur går det till?

Vad gör du på mötet?

Vilka från er organisation är med på Sprint Planneringen?

Medverkar du på några daily scrums?

V

Berätta om en gång då gruppen gjort något för dig som gjorde att du kände dig uppmärksammad som kund?

Vad finns det för avtal mellan er och OIt?

Skillnader mellan detta projekt och andra du varit med i?

Vad ser du för begränsningar med Scrum?

Vad är den avgörande faktorn till projektets ev. framgång?

VI

Bilaga 3 Intervjuguide Systemutvecklare

Vem är du?

Vill du medverka med namn?

Vad har du för bakgrund, utbildning?

Hur många projekt har du varit med i på ett ungefär?

Hur länge har du jobbat på OIt?

Har du scrum utbildning?

Inledande intryck

Har du varit med om något misslyckat IT-projekt? Vill du berätta om det?

Vad anser du vara den viktigaste faktorn för att lyckas med ett projekt?

Vad är det första du tänker på när jag säger Scrum?

Vad är Scrum för dig?

Vad är den absolut största vinsten med att jobba enligt Scrum?

Vad är de största skillnaderna i att jobba i ett Scrum-Projekt till skillnad från ett traditionellt projekt?

Rollen som utvecklare

Hur uppfattar du teamgemenskapen i Scrum gentemot Bandit?

Hur mycket sammanspråkar ni i gruppen med varandra dagligen gentemot bandit? Bortsett från daily scrum

Bestämmer ni själva i gruppen vad ni ska göra?

Känner du att ni i gruppen har fulla befogenheter att ta ut svängarna lite?

Utvärderar ni era arbetssätt i gruppen?

Hur tillämpar du scrum i din vardag?

Sitter ni i samma rum och utvecklar?

Hur skulle du beskriva skillnaden mellan en projektledare och Scrum Master?

Hur uppfattar du Product Owner till skillnad från en traditionell beställare? Är personen mer som en projektledare?

Vilken kontakt har du med Product Owner under en sprint?

Product Backlog?

Vad var din roll på detta möte? Hur arbetade du?

Kändes det som att det var meningsfullt för dig?

VII

Har det uppkommit förändrade krav?

Hur reagerar du som utvecklare förändrade krav?

Hur stora förändringar är det i kraven?

Berätta om hur du uppfattar daily scrum?

Vad anser du om mötesformen?

Håller ni tiden?

Gör det något om ni går över tiden?

Är det meningsfulla diskussioner?

Vad skulle kunna göra de dagliga mötena bättre?

Har det någon gång hänt att du inte visste helt vad du skulle göra en dag på ett daily scrum?

Sprint Review och planning?

Samma möte? Bra/dåligt?

Hur upplever du mötet generellt? Anser du att det är meningsfullt för dig att vara där?

Anser du att Product Owner och utvecklarsidan förstår varandra väl?

Behövs tolkning?

Är det bra eller en hets att ha som krav på sig att kunna leverera körbar programkod.

Vad ställer det för krav på dig som utvecklare?

Test?

Hur testar man scrum?

Är Scrum test?

Acceptans= Sprint review?

Enhetstestning? Systemtest?

Vilken kontakt har du och med vem av dina chefer om projektet under en sprint?

VIII

Bilaga 4 Intervjuguide Scrum Master

Vem är du?

Projekt?

Gruppstorlek?

Slutanvändare?

Vill du medverka med namn?

Vad har du för bakgrund, utbildning?

Ungefär hur många projekt har du lett?

Har du scrum utbildning?

Inledande intryck

Varit med om misslyckat IT-projekt?

Vad anser du vara den viktigaste faktorn för att lyckas med ett projekt?

Vad är det första du tänker på när jag säger Scrum?

Vad är den absolut största vinsten med att jobba enligt Scrum?

Vad är den största skillnaden i att leda ett Scrum-Projekt till skillnad från ett traditionellt projekt

Din roll?

Skulle du beskriva dig som en Scrum Master eller projektledare?

Vad är den största skillnaden mellan Scrum Master och projektledare?

Hur jobbar du med projektplanering?

Behövs någon sådan?

Anser du att rollfördelningen är tydlig i ditt projekt?

Berätta om vilka hinder du röjer undan?

Berätta om din projektgrupp?

Hur fick du just den här gruppen?

Fungerar Scrum på en grupp med den storleken du har?

Anser du att projektgruppen är mer sammansvetsad i Scrum-projektet än i ett tradi-tionellt projekt?

Chefens stöd?

Hur stöttar din chef dig i projektet?

IX

Vem? Magnus? Eller gruppchef

Hur blir projektet uppföljt från Oit:s sida?

Statusrapportering?

Övrig uppföljning?

Vem följer upp?

Kan du berätta hur ni tog fram den första Backlogen?

Vilka var med?

Slutanvändare?

Vilka var drivande i kravställandet?

Antal deltagare från er och beställarsidan?

Uppstod några problem under detta möte?

Effektivt?

Har det förekommit mycket förändringar i backlogen?

Ligger förändringar i krav eller bara i prioriteringen?

Deltar slutanvändare i det här arbetet?

Hur mycket kontakt har du med beställaren i Scrum-Projektet gentemot ett traditionellt projekt?

Berätta om ditt dagliga arbete i ett scrumperspektiv?

Är det lättare att styra projektet med Scrum?

Var ligger projektledarrollen, hos dig eller product Owner.

Berätta om ett vanligt Daily Scrum-möte.

Håller ni tiden till 15 min.

Är alla i tid?

Är det meningsfullt?

Är mötet fokuserat till det som ska göras eller svävar folk ut?

Vad gör du om folk svävar ut?

Har ni någon mer punkt på dagordningen än de som enligt metoden föreskriver?

Har du varit med om att någon inte har haft något att göra?

Hur skulle du vilja förändra de dagliga mötena

Sprint Planning meeting?

X

Håller mötet 4 timmar? Mer? Mindre?

Varför?

Vad planeras krav eller aktiviteter?

Vilken roll har du på Sprint planning?

Tillbakadragen?

Drivande?

Mötesledare?

Har Product Owner någon inflytande över tidsestimeringen?

Sprint review meeting?

Får hela gruppen prata?

Är det bra att hela gruppen är med?

Vilka från beställarsidan är med?

Får användaren vara med?

Är alltid sprint review och planning på samma dag?

Hur jobbar ni med test i scrum?

Acceptanstest?

Är test Scrum eller XP.

Vad har ni för avtal mellan beställare och leverantör?

XI

Bilaga 5 Rules for Daily Scrum

Hämtad från Schwaber (2004)

The Daily Scrum meeting is time boxed to 15 minutes regardless of the number of team members.

• Hold the Daily Scrum in the same place at the same time every work day. The Daily Scrum is best held first thing in the day so that the first thing team members do on arriving at work is think of what they did the day before and what they plan to do today.

• All team members are required to attend. If for some reason a team member cannot attend in person, the absent member must either attend by phone or by having another team member report on the absent members status.

• Team members must be prompt. The Scrum Master starts the meeting at the appointed time, ragrdless of who is present. Any member who is late pays $1 to the scrum master immediately.

• The Scrum Master begins the meeting by starting with the person to his or her left and proceeding counter clockwise around the room until everyone has reported.

• Each team member should respond to three questions only:

1. What have you done since the last Daily Scrum regarding this project? 2. What will you do between now and the next daily scrum meeting regarding this project? 3. What impedes you from performing your work as effectively as possible?

• Team members should not digress beyond answering these three questions into issues, designs, discussion of problems, or gossip. The scrum master is responsible for moving the reporting along briskly, from person to person.

• During the Daily Scrum, only one person talks at a time. That person is the one who is reporting his / her status. Everone else listens. There is no side conversations.

• When a team member reports something that is of interest to other team members or needs the assistance of other team members, any team meber can immediately arrange for all interested parties to get together after the Daily Scrum to set up a meeting.

• Chickens are not allowed to talk, make observations, make faces or otherwise make their presence in the daily scrum meeting obtrusive.

• Chickens stand on the periphery of the team so as not to interfere with the meeting

• If too many chickens attend the meeting, the Scrum Master can limit attendance so that the meeting can remain orderly and focused.

• Chickens are not allowed to talk with team members after the meeting for clarification or to provide advice or instructions.

• Pigs or chickens who cannot or will not conform to the above rules can be excluded from the meeting (chickens) or removed from the team (pig)

351 95 Växjö / 391 82 Kalmar Tel 0772-28 80 00 dfm@lnu.se Lnu.se