• No results found

AKADEMIN FÖR TEKNIK OCH MILJÖ

N/A
N/A
Protected

Academic year: 2021

Share "AKADEMIN FÖR TEKNIK OCH MILJÖ"

Copied!
45
0
0

Loading.... (view fulltext now)

Full text

(1)

AKADEMIN FÖR TEKNIK OCH MILJÖ

Avdelningen för elektronik, matematik och naturvetenskap

AKADEMIN FÖR TEKNIK OCH MILJÖ

Avdelningen för elektronik, matematik och naturvetenskap

En jämförelse av Scrum i praktik och teori

Ramverket Scrum vid mjukvaruutveckling i

praktiken

Eventuell underrubrik på ditt arbete

Peshang Suleiman

2020

Examensarbete, Grundnivå(yrkesexamen), 15 hp Datavetenskap

Dataingenjörsprogrammet

(2)
(3)

Förord

Jag vill tacka samtliga respondenter som med stort intresse och engagemang ställt upp på intervjuer och gjort studien möjlig att genomföra. Jag vill även tacka min handledare Anders Jackson för att ha bidragit med relevant feedback och idéer under arbetets gång.

(4)
(5)

Sammanfattning

Det finns många olika teorier om hur man skall bedriva framgångsrik mjukvaruut- veckling. Metoderna har gått alltifrån mer sekventiella metoder till mer agila arbets- metoder. Misslyckanden inom projekt och brister i programvarorna var anledningen till att den agila arbetsmetoden definierades [1]. Det agila arbetet innebär att regel- bunden kommunikation och ett inkluderande och iterativt arbete där utvärdering är en viktig beståndsdel [2]. Syftet med denna studie är att undersöka hur arbetsme- toden Scrum fungerar i praktiken idag och om eller hur mycket det skiljer sig från det teoretiska för metoden. Studien skall även undersöka hur slutprodukter eventu- ellt påverkas av den metod en organisation eller företag använder.

Arbetsmetoden Scrum studerades innan för att få en bra och fullständig uppfattning om hur metoden fungerar i teorin och de olika beståndsdelarna. Därefter skapades ett formulär med intervjufrågor baserad på den studerade teorin. Frågorna bestäm- des utifrån metoden och dess beståndsdelar, och omfattade hela metoden. Totalt in- tervjuades sex respondenter och respondenterna valdes ut utifrån roll på organisat- ion/företag. Kravet var att intervjua Scrummästare, projektledare och en mjukvaru- utvecklare för att få en lite bredare bild. Deltagande respondenter bestod av en ut- vecklare, tre med roller som Scrummästare/Agil coach och två med roller som pro- jektledare. Vid avslutade intervjuer sammanställdes dessa och presenterades i rap- porten. De olika intervjuerna och dess svar användes sedan i slutsatsen för arbetet, för att kunna dra slutsatserna om hur Scrum används hos olika och om det skiljer sig mycket.

De sex olika intervjuerna som genomfördes gav liknande svar i sin helhet, men de- taljerna skiljer sig åt mellan organisationerna. Samtliga företag har valt större delar av Scrum vid användningen av metoden, men har gjort egna modifieringar och an- passningar. De flesta modifieringar som gjorts är så pass små att det inte påverkar slutprodukten mycket, bortsett från ett företag som inte ägnar tid åt viktiga delar i slutet av en sprint.

Nyckelord: Mjukvaruutveckling, Agil arbetsmetod, Scrum, Scrum i praktiken.

(6)
(7)

Abstract

During a look back in history, there have been many theories over the years about how successful software development should be conducted. The methods have gone from more sequential methods to more agile working methods. Failures in projects and software shortcomings were the reason why the agile working method was de- fined [1]. The agile work means that regular communication and an inclusive and it- erative work where evaluation is an important element [2]. The purpose of this study is to investigate how the working method Scrum is used in practice today and whether or how much it differs from the theoretical for the method. The study will also examine how end products may be affected by the method used by an organiza- tion or company.

The working method Scrum was first studied to get a good and complete idea of how the method works in theory and the various components. A form of interview questions based on the studied theory was created. The questions were determined from the method and its constituents, and covered the whole method. A total of six respondents were interviewed and the respondents were selected based on role on organization/company. The requirement was to interview Scrum master, project manager and a software developer to get a slightly broader picture. Participating re- spondents consisted of one developer, three with roles as Scrum master/agile coach and two with roles as project managers. At closed interviews, these were compiled and presented in the report. The various interviews and their answers were then used in the conclusion for the work, in order to be able to draw the conclusions about how Scrum is used by different people and whether it differs widely.

The six different interviews that were conducted gave quite similar answers in their entirety, but the details differed between the organizations. All companies have cho- sen larger parts of Scrum when using the method, but have made their own modifi- cations and adjustments. For most who have made modifications, it is so small that it does not affect the final product much, except for a company that does not spend time on important parts at the end of the sprint.

Keywords: Software development, Agile methodology, Scrum, Scrum in practice.

(8)
(9)

Innehållsförteckning

Förord ... i

Sammanfattning ... iii

Abstract ... v

1 Introduktion ... 1

1.1 Bakgrund ... 1

1.2 Syfte ... 2

1.3 Frågeställningar ... 2

1.4 Avgränsningar ... 2

2 Teori ... 3

2.1 Mjukvaruutveckling ur ett historiskt perspektiv ... 3

2.2 Agil arbetsmetod ... 3

2.3 Scrum ... 4

2.3.1 Terminologi ... 5

2.3.2 Product Backlog ... 6

2.3.3 The Sprint ... 6

2.3.4 Sprint Planning ... 7

2.3.5 Daily Scrum ... 8

2.3.6 Sprint Review ... 8

2.3.7 Sprint Retrospective ... 8

3 Process ... 10

3.1 Kvalitativ forskningsmetodik ... 10

3.2 Datainsamling ... 11

3.3 Utvalda respondenter ... 11

3.4 Intervjuer ... 12

4 Resultat ... 14

4.1 Respondent A1 ... 15

4.2 Respondent A2 ... 16

4.3 Respondent A3 ... 17

4.4 Respondent A4 ... 19

4.5 Respondent A5 ... 20

4.6 Respondent A6 ... 21

5 Diskussion ... 24

5.1 Diskussion av resultat ... 25

5.1.1 Roller i teamen ... 25

5.1.2 Metodiken i teamen ... 26

5.1.3 Resultatmätning i teamen ... 27

6 Slutsats ... 29

6.1 Summering ... 29

6.2 Vidare forskning ... 31

Referenser ... 32

Bilaga A ... 1

Bilaga B ... 1

(10)
(11)

1 Introduktion

1.1 Bakgrund

Enligt Keith var många misslyckanden med många IT- och försvarsprojekt ett fak- tum fram till åttiotalet [1]. Misslyckanden med programvarorna inom IT resulterade mycket höga kostnader som inte skapade bra resultat för kunderna, brister i funkt- ionalitet för dessa och vissa programvaror fungerade inte alls vid leverans [1]. Pro- gramvaror kunde bli försenade eftersom att de inte uppfyllde kundens krav och be- hövde göras om. Längre projekttider resulterade givetvis i att det krävdes mycket mer tid för ett projekt och på så vis blev slutkostnaden för projektet mycket högre än tänkt. Stora omfattande IT-projekt beställdes av kunder, som skulle ha en viss funktionalitet, men vid lansering av projektet visade resultaten att kunden inte fick det som hade beställts [1]. Problemen eller bristerna fanns under de åren på grund av användning av bland annat Vattenfallsmetoden [1]. Vattenfallsmetoden är en ar- betsmetod som i stora drag syftar till att leverera en kostnadseffektiv lösning till kunden. Leverantören tar emot en beställning/projekt, utvecklar det utifrån hel- hetslösningen som kunden framtagit och sedan levereras programvaran. Metoden bi- drar till mer komplexitet för förändringar under processens gång och ändringar i ti- digare skapade delar.

Misslyckanden inom projekt och brister i programvarorna var anledningen till att nya metoder som Agil arbetsmetod definierades [1]. Agila arbetet innebär att regel- bunden kommunikation och ett inkluderande och iterativt arbete där utvärdering är en viktig beståndsdel [2].

Utifrån detta utvecklades den agila arbetsmetoden Scrum av Ken Schwaber och Jeff Sutherland [3]. Arbetsmetoden Scrum utvecklades för att minimera kostnader för kunder och för förändringsbara projekt [3]. Minimering av kostnader är en viktig del för kund och möjligöring av förändringar av delar under ett projekt bidrar till mer fungerade programvara vid lansering. Arbetsmetoden blev populär vid utveckling av IT-projekt med tanke på dagens användning. Metodens positiva aspekter med att kunna förändra under processens gång, utan att påverka systemet som helhet, har gjort metoden mer populär.

Scrum används idag i många IT-projekt för olika orsaker såsom bättre slutprodukt, mer strukturerad kod och för en mer tydlig och regelbunden kommunikation mellan samtliga inblandade [2].

(12)

1.2 Syfte

Det blir allt vanligare att organisationer och företag som jobbar med systemutveckl- ing, övergår till de agila arbetsmetoderna och främst Scrum. Organisationer som övergår till denna arbetsmetod gör det på olika vis, det vill säga att metoden imple- menteras på olika sätt. Syftet med detta arbete är att undersöka hur arbetssättet Scrum idag implementeras av olika organisationer & företag och hur mycket deras implementering skiljer sig från de teoretiska riktlinjerna för Scrum. Arbetet skall även undersöka hur en slutprodukt eventuellt påverkas av den metod som en organi- sation/företag använder.

1.3 Frågeställningar

De frågeställningar som detta arbete kommer att baseras på:

• Hur används Scrum-metoden i praktiken?

• Hur mycket skiljer det sig från teorin?

Följdfråga till mina frågeställningar är:

• Hur ser resultaten ut om Scrum-metoden inte appliceras enligt riktlinjerna för Scrum-ramverket?

1.4 Avgränsningar

Detta arbete är avgränsat till en studie baserad på sex olika intervjuer med olika fö- retag och organisationer. Utvalda företag som valts ut har inte valts baserat på några riktlinjer eller krav, utan endast på att företaget arbetar med systemutveckling, ar- betar enligt Scrum givetvis och att rollen Scrummästare eller projektledare funnits.

(13)

2 Teori

2.1 Mjukvaruutveckling ur ett historiskt perspektiv

Mjukvaruutveckling är en logisk process som innebär att skapa ett IT-system för ett visst ändamål. Ett system skall vara programmerad för att hantera en process eller ett mål. Vid utveckling av mjukvara används processen SDLC(Software Develop- ment Life Cycle) [4], bestående av analys av problemet, planering, design av syste- met, implementering av kod, testning, dokumentation och slutligen distribution &

underhåll. Fram till åttiotalet var misslyckanden med många IT- och försvarsprojekt ett faktum, vilket ledde till att detta sågs över och nya metoder definierades i hopp om att få bättre resultat på projekten [1]. Fram till denna period användes mindre hanterbara och förändringsanpassade arbetssätt såsom Vattenfallsmodellen, som fo- kuserar på mycket planering och mer komplex dokumentation [5]. Anledningen till att det blir mer komplex dokumentation är att vid vattenfallsmetoden finns en plan och ett mål, och vid upptäckt av problem under processens gång stannar utveckl- ingen i just den fasen för att försöka lösa problemet, utan att ta hänsyn till hur det gått till i den tidigare fasen. När problemet är löst påbörjas nästa fas för att slutligen uppnå målet. När denna typ av arbetsmetod används, kommer testning in i ett sent stadie, och detta kan leda till att nya och stora problem upptäcks och det blir försent att återgå för att åtgärda felet.

2.2 Agil arbetsmetod

Med tanke på de många misslyckanden inom IT-projekt och dess arbetsmetod så var målet som sagt att försöka implementera en ny metod för att uppnå bättre resultat med färdiga programvaror. I februari 2001 träffades sjutton utvecklare för att för- söka finna nya alternativ till den tidigare arbetsmetoden vattenfallsmodellen. Mötet mellan utvecklarna resulterade i att ”Manifesto for Agile Software Development”

[2], utvecklades. Det framtagna manifestet bestod i sin tur av många olika utveckl- ingsprocesser och metoder och hjälpte många andra utvecklare ute på marknaden.

Utveckling av den agila arbetsmetoden syftade till mycket nära kontakt mellan kund och utvecklare, distribution i tid och till en lägre kostnad [5]. Nära kontakt mellan kund och utvecklare innebar bättre kommunikation, mer öppenhet för förändringar under arbetets gång och mindre omfattande dokumentation.

Enligt studien ”Chaos report 2015” [6] som gjorts av The Standish Group har det vi- sats att det är betydligt fler misslyckade projekt vid användning av Vattenfallsmet- oden än agila arbetsmetoden. Rapporten har baserats på olika storlekar av projekt inom både agila och Vattenfallsmodellen, som utvecklats mellan 2011-2015 och to-

(14)

talt 10.000 mjukvaruprojekt. Studien visar att projekt utvecklade enligt arbetsme- toden Vattenfallsmodellen hade hela 29% misslyckade projekt och projekt utveck- lade enligt agila arbetsmetoden bestod av 9% misslyckade projekt [6].

2.3 Scrum

En utav processerna som valdes i samband med mötet för utveckling av arbetspro- cesser och var baserad på de agila principerna var arbetsmetoden Scrum [2]. Scrum skapades i början av 1990-talet och är enligt grundarna Ken Schwaber och Jeff Sut- herland egentligen ingen teknik eller definierad metod, utan de uttrycker det som:

”Scrum is a process framework that has been used to manage work on complex products since the early 1990s. Scrum is not a process, technique, or definitive method. Rather, it is a framework within which

you can employ various processes and techniques. Scrum makes clear the relative efficacy of your prod- uct management and work techniques so that you can continuously improve the product, the team, and

the working environment.” [3]

Scrum är en så kallad lättviktig metod, en iterativ process för att utveckla bland an- nat mjukvara och som används numera i de flesta mjukvaru-projekten för att uppnå bättre resultat och för förändringar under processen [7]. Scrum består av ett antal beståndsdelar för ett lyckat och resultatgivande projekt och dessa delar är att under- söka och analysera problem, utveckla produkter och förbättringar, distribuera ut produkten iterativt och helst många gånger innan slutgiltig distribution. Tanken med detta så kallade ramverk är att kunden skall kunna vara med under processen och på- verka, det vill säga kunna återkoppla till utvecklarna om eventuella förändringar el- ler upptäckter av problem. Med denna teknik kan förändringar eller lösning av pro- blem implementeras under processen, vilket innebär att målet närmar sig stegvis.

Metoden i sig är strukturerad på ett vis och det finns riktlinjer för hur detta skall föl- jas enligt det teoretiska. Enligt en studie som gjorts av Michal Hron och Nikolaus Obweeger vid Aarhus University i Danmark, har det visat sig att det finns många olika typer av anpassningar av Scrum [8]. Anpassningar har enligt studien skett inom organisationer för att kunna anpassa metoden i sin helhet till berörd organisation [8].

Arbetssättet eller tekniken Scrum består av tre grupper, en produktägare, en Scrummästare och utvecklingsgruppen [9]. En produktägare är den personen eller organisationen som beställt produkten och ansvarar för att maximera värdet på den beställda produkten. En Scrum-mästare är en person som agerar chef eller mellan- hand mellan en produktägare och utvecklarna, han eller hon ansvarar även för att projektgruppen följer Scrum-processen [10]. Slutligen finns ett utvecklingsteam be- stående av ett antal olika utvecklare som skall skapa den produkt som beställts och tillsammans komma överens om hur systemet skall byggas.

(15)

Enligt Wawryk är Scrum en bra arbetsmetod att jobba efter, om principerna följs fullt ut [11]. Scrum fungerar bäst när varje team består av cirka sju personer och +/- 2 personer. I varje team har uppdelningen skett på så sätt att samtliga har en egen roll. Skulle ett team bestå av färre medlemmar, blir slutsatsen att de olika medlem- marna måste ta sig an nya roller. Nya roller kan innebära att utvecklare som utveck- lar kan komma att behöva agera även testare.

Trots de positiva aspekterna med att fullfölja metoden Scrum, sker modifieringar av detta för att anpassa ett team. Enligt Girma som gjort en studie där han undersöker Scrum vid storskalig programvaruutveckling, gör företagen en modifiering av meto- den för bästa anpassning [2]. Behovet av säkerhetsanalys och pålitlighetsanalys med- för att modifieringar behöver ske innan en rutin skapas för teamet [2].

Figur 1: Scrum process i helhet. Bild hämtad från Scrum.org [12].

2.3.1 Terminologi

I uppsatsen nämns svenska termer som Scrum inkluderar och nedan finns en ordlista på översättningar på dessa begrepp som används för en tydligare förståelse.

Product Owner Produktägare

Scrum Master Scrummästare

The Team Utvecklingsteam

Product Backlog Produktspecifikation

Sprint Backlog Sprintspecifikation

Sprint Sprint

(16)

Daily Scrum Meeting Dagligt Scrummöte

Sprint Review Meeting Granskningsmöte/demonstration Sprint Retrospective Meeting Retrospektivmöte

Scrum of Scrums Scrum av Scrum

Burndown-chart Processdiagram

Tabell 1: Ordlista över terminologier inom Scrum översatta till engelska.

2.3.2 Product Backlog

En produktspecifikation är en skapad och ordnad lista över samtliga krav och funkt- ioner som en produkt skall bestå av samt det som blir ett arbete för ett utvecklings- team. Produktägaren är den person som ansvarar över en produktspecifikation och dess innehåll och tillgänglighet [3]. Produktspecifikationen är en lista som aldrig är komplett, utan är dynamisk och kan förändras mycket och ofta, beroende på hur en produkt skall utformas för att vara användarvänlig.

2.3.3 The Sprint

Sprint är kärnpunkten med Scrum, och är en tidsplanering mellan 2-4 veckor bero- ende på vad ett team anser lämpligt för ett projekt [3]. En sprint inleds med en sprintplanering, under det dagliga arbetet sker dagliga Scrummöten och slutligen hålls ett granskningsmöte och ett retrospektivmöte [3]. En sprint är en process som startar direkt när en tidigare avslutats. Under en sprint sker inga förändringar som skulle påverka målet för den aktuella [3]. Det som valts in till den bestämda sprinten är det som skall utföras och varje sådan del kan ses om ett bestämt projekt som varar under en kortare tid av hela projekt-processen.

(17)

2.3.4 Sprint Planning

Sprintplanering är det arbete som sker innan en sprint påbörjas, och här planeras ett arbete för bestämd tid för aktuell period. Detta är ett möte där produktägaren, Scrummästare och utvecklingsteamet deltar och där samtliga tillsammans är delakt- iga att planera [3]. En Scrummästare har ansvaret att se till att dessa möten blir av och utvecklingsteamet deltar där och förstår anledningen. Alla berörda parter disku- terar tillsammans vad som skall ingå i nästa sprint och där väljer man ut olika funkt- ioner/krav från en produktspecifikation. Vid en sprintplanering besvaras två frågor [3]:

• Vad kan levereras i den kommande sprinten?

• Hur skall arbetet som krävs uppnås för att kunna leverera?

Det är upp till ett utvecklingsteam att bestämma hur många olika punkter som skall lyftas in från produktspecifikationen till en sprint och försöka förutse hur mycket som kan åstadkommas under den bestämda tiden. Utvecklingsteamet har som upp- gift att lyfta in olika funktioner för att sedan bryta ned problemen till mindre delpro- blem som löses på en dag.

Figur 3: Frågor och ämnen som ingår i en sprintplanering. Bild hämtad från Scrum.org [14].

(18)

2.3.5 Daily Scrum

Dagliga Scrummöten är ytterligare ett möte som hålls vid dagens start och detta är på maximalt femton minuter. Det hålls varje dag och det är Scrummästare tillsam- mans med utvecklingsteamet som deltar. Vid det dagliga mötet diskuteras och plan- eras den kommande dagens arbete. Med hjälp av detta optimeras teamets samarbete genom att diskutera och inspektera stegen mot målet.

Det är upp till teamet att strukturera upp hur ett möte skall vara planerad, antingen genom att det skall vara med diskussionsbaserat eller att följande frågor skall besva- ras för att få en bild av varje persons arbete [3]:

• Vad gjorde jag igår som bidrog till att vi kom närmare målet för denna sprint?

• Vad skall jag göra idag för att komma närmare målet?

• Finns det några aktuella problem i mitt arbete eller hinder som kommer att uppstå under dagen?

Under denna tid kan eventuella problem tas upp för att teamet tillsammans skall dis- kutera eventuella lösningar alternativt att problemet kan diskuteras och försöka lösas efter mötet. Dagliga Scrummöten förbättrar kommunikationen och identifierar hin- der för utvecklingen och förbättrar gruppens kunskapsnivå [3].

2.3.6 Sprint Review

Ett granskningsmöte är ett möte som hålls i slutet av en sprint och hålls för att disku- tera vad som åstadkommits under denna period [3]. Vid detta deltar Scrummästare, utvecklingsteamet, produktägare och eventuella intressenter. Om en produktägare deltar vid detta möte, hålls även en demokörning av det som utvecklats och pro- duktägaren kan se vad som gjorts och inte gjorts under sprinten. Utvecklingsteamet får även chansen att diskutera och reflektera över vad som gick bra under perioden, vilka problem de stött på och hur dessa problem löstes. Här diskuteras även vad som skall tas med till nästa sprint eller inte. Precis som många andra möten är det

Scrummästarens ansvar att facilitera detta.

2.3.7 Sprint Retrospective

Det sista mötet som hålls i en sprint är ett retrospektivmöte där utvecklingsteamet får chansen och möjligheten att diskutera förbättringsmöjligheter inför nästa [3].

Detta hålls efter ett sprint granskningsmöte och givetvis innan nästa sprint. Syftet med det är att se över hela projektet och diskutera allt kring arbetet, processen, verktyg och individernas insatser.

(19)

När mötet är avslutat skall teamet ha identifierat förbättringsmöjligheter som tas med och implementeras i nästa sprint.

(20)

3 Process

Syftet med detta arbete var att få en mer förståelse och inblick i hur Scrum fungerar hos företag och organisationer. Det fanns givetvis olika alternativ och valmöjligheter för att få en inblick hur det fungerar i praktiken. Antingen genom att besöka företag för att se och studera deras arbete, men även genom intervjuer. Att studera företag på plats hade inneburit en studie en längre tid på bestämt företag och sedan jämföra det mot det teoretiska. Eftersom tanken med studien var att få en bredare inblick, var det sistnämnda inget alternativ för detta arbete. Intervjuer valdes till detta arbete för att få en större inblick i hur det fungerar på olika arbetsplatser och för att se olika modifieringar av metoden.

Arbetet startade med att olika företag kontaktades där en förfrågan skickades ut om företaget ifråga hade ett utvecklingsteam som utvecklade mjukvaror och om de arbe- tade enligt Scrum. Vid svar från kontaktade organisationer om visat intresse för en intervju och om ovanstående krav stämde in, skickades även ett informationsbrev ut, som kan läsas under avsnitt Bilaga B. Informationsbrevet bestod av viktig informat- ion till berörd respondent för att de skulle få en inblick i vad det berörde, beräknad tid för intervju och tillvägagångssättet.

Tanken med arbetet var att genomföra intervjuer med sex utvalda personer som skulle besvara olika frågor gällande denna arbetsmetod. Med hjälp av intervjuerna skulle viktig och användbar information gällande hela Scrum-processen samlas in. Av den anledningen var den mest lämpliga metoden för detta arbete intervjuer med öppna frågor som omfattar hela Scrum.

Med tanke på att arbetet bestod av ett antal intervjuer, valdes kvalitativ forsknings- metodik där öppna frågor ställdes till berörd respondent. Kvalitativ forskningsmeto- dik passade eftersom att tanken med arbetet var att samla in information om ämnet Scrum och hur det fungerar i praktiken.

3.1 Kvalitativ forskningsmetodik

Vid forskning för undersökningar finns två metoder, dels kvantitativa forskningsme- toder men även kvalitativa forskningsmetoder [15]. Enligt Kärsten har kvantitativa forskning sitt ursprung från latinets ”Quantitas”, som betyder ”kvantitet” och kvalita- tiv forskning från latinets ”Qualitas”, som betyder ”kvalitet” [15]. Det är olika meto- der som används beroende på vilken typ av information eller kunskap forskaren strä- var efter och hur det kan uppnås.

(21)

Kvantitativ forskning är den forskningsmetod där kvantitativa och exempelvis statist- iska resultat sökes [16]. Detta innebär att kvantitativ data består av exempelvis siff- ror och mätvärden [16]. Kvantitativa metoder är användbart när siffror eftersöks för att bevisa ett slutresultat.

Kvalitativ data består till största delen av textbaserad undersökning och icke-nume- risk data där berörd person besvarar frågor [15]. Vid kvalitativ forskning samlas kva- litativ data in, som är mer en beskrivande form om ett ämne. Processen för denna studie skulle bestå av intervjuer av cirka 5-7 respondenter innehållandes ett frågefor- mulär bestående av öppna frågor. De öppna frågorna skulle vara fokuserade på hur arbetet utförs på organisationen eller företaget och av den anledningen valdes den kvalitativa forskningsmetodiken.

3.2 Datainsamling

Arbetet har bestått av två olika delar, dels insamling av data genom olika litteratur- studier men även genom den kvalitativa forskningsmetoden som bestått av inter- vjuer. Viktig och lämplig information har samlats in till rapporten genom sökning i olika databaser såsom IEEE Xplore och Google Scholar där vetenskapliga artiklar funnits för ändamålet. Det har funnits mycket information kring ämnet, dock har det varit ont om artiklar och arbeten som omfattat den typen av arbete som denna studie.

Den andra delen i arbetet är den kvalitativa forskningsmetodiken och där förbered- des ett frågeformulär med frågor för intervju. Intervjufrågorna baserades på arbets- sättet Scrum via den teoretiska delen för att sedan kunna göra en jämförelse i hur det skiljer sig mellan praktik och teori. Där var en viktig aspekt att ha bra kännedom om arbetsmetoden i helhet, såsom roller, möten och andra viktiga delar, eftersom inter- vjufrågorna skulle vara baserade på den teoretiska delen.

3.3 Utvalda respondenter

Vid starten av arbetet kontaktades olika former av organisationer och företag, både små och stora företag sett till antal anställda. Företagen som kontaktades var kon- sultfirmor och in house-företag där egna produkter skapades för organisationen. Vid första kontakt var det tydligt vilken roll som söktes för en eventuell intervju, nämli- gen en Scrummästare eller en projektledare. Förutom detta söktes även en utveck- lare för att få in en bild även från en utvecklares perspektiv på ett arbetssätt. Av den anledningen att arbetet skulle omfatta ett arbetssätt för ett helt utvecklingsteam, val- des respondenterna utifrån dessa riktlinjer.

(22)

3.4 Intervjuer

På grund av rådande situation och omständigheter med COVID-19 utfördes samtliga intervjuer genom videosamtal via kommunikationsprogrammet Zoom. Anledningen till att detta togs via videosamtal och inte per telefon var för att tanken med hela ar- betet var intervjuer på plats från första början. Intervjutiden var satt till maximalt sextio minuter per intervju, trots att respondenterna visade ett stort engagemang och ville förklara mycket utförligt.

Enligt Säfsten är det optimalt att göra en lista över teman som en intervju skall inne- hålla, innan frågor specificeras upp och detta för att skapa relevanta teman och frå- gor tillförandes dessa [15]. Denna metod var lämplig för detta arbete, eftersom att Scrum består av större och mindre delar. Dessa teman skapades och sedan skapades även frågorna till varje tema.

Den intervjumetod som valts för arbetet är en strukturerad metod då intervjufrå- gorna var förbestämda. Frågorna valdes som nämnts tidigare utifrån arbetssättets te- oretiska del och frågorna har kommit i en kronologisk ordning. Den kronologiska ordningen behövde följas eftersom att arbetssättet har en viss ordning när det gäller de olika beståndsdelarna.

Intervjufrågorna för detta arbete finns att ta del av under bilagor och Bilaga A. De intervjufrågor som valdes ut till arbetet var utformade för att passa till en intervju med en Scrummästare. Det som utmärker mest att intervjun var utformad för en Scrummästare är den del där frågorna är riktade specifikt till en Scrummästare. Ef- tersom att både Scrum mästare, projektledare och även en utvecklare intervjuats, har frågeställningarna gjorts om lite för att passa just den respondenten. När en pro- jektledare intervjuades, ställdes frågor om personens roll som projektledare och hur det skiljde sig från en Scrummästares arbete. Det innebär att frågorna formades om lite under arbetets gång och inför varje intervju, beroende på respondentens roll.

Att genomföra en intervju med ett stort antal frågor på cirka sextio minuter och hinna dokumentera samtidigt är ingen enkel metod. Vid kortare och mindre omfat- tande intervjuer har en intervjuare chansen att föra anteckningar och i vissa fall även minnas det mesta. Vid mer omfattande intervjuer blir det svårt att hinna anteckna samtliga svar och det finns en risk att en del information går förlorad [15]. Av denna anledning användes inspelningsverktyg för inspelning av intervju vid godkännande av berörd person. Inspelningsverktyget underlättade även för att kunna följa med foku- serat och kunna ställa följdfrågor på svar där ytterligare information kunde hämtas.

Totalt sex intervjuer genomfördes för denna studie och samtliga intervjuer tog den beräknade tiden och vid två intervjuer överskreds tiden med cirka fem minuter på grund av diskussioner och mycket engagerade respondenter. Ganska direkt efter

(23)

även ut till varje berörd respondent för godkännande innan publicering. Samtliga re- spondenter har läst igenom rapporten och vissa har haft invändningar på vissa formu- leringar, vilket ändrats efter berörd person önskemål om vissa förändringar.

(24)

4 Resultat

Här nedan redovisas samtliga resultat i form av data som samlats in med hjälp av ge- nomförda intervjuer med deltagande respondenter. Resultatet redogörs under olika rubriker, där underrubriker skapats för olika områden och delar ur Scrum. Tabellen nedan presenterar kort bakgrund om varje respondent.

Vad har du för

utbildning? Hur länge har du ar- betat med mjukvaru- utveckling?

Hur länge har du arbe- tat enligt Scrum?

Har du ge- nomgått en Scrum-utbild- ning?

Känner du att du har bra koll på teorin bakom Scrum?

Respondent A1 Systemutvecklare,

examen 1995 Sedan år 1995 Ungefär sedan

år 2005 Ja, jag tog Scrum-certifi- ering år 2006.

Ja, det tycker jag efter alla dessa år.

Respondent A2 Civilingenjörsexa- men inom medie- teknik, examen år 2017

Sedan år 1995 I cirka 2 år. Nej, jag är självlärd. Jag har läst på mycket på egen hand.

Ja, ganska bra ändå.

Respondent A3 Elektroingenjörsex- amen + examen i ekonomi, examen år 1994

I 20-25 år. I cirka 5 år. Jag fick interna utbildningar om verktygen, teorin och metodiken på min förra arbets- plats. Men jag skulle säga att jag är mest självlärd.

Ja, även om jag skulle vilja ha lite mer teoretiska ge- nomgångar för att få med alla delar.

Respondent A4 Högskoleingen- jörsexamen inom medie- kommuni- kationsteknik, exa- men år 2003.

I mer än 10

år. I mer än 10 år. Jag har gått lite olika utbildningar och har även cer- tifiering i Scrum- master. Jag har även genomgått utbildning för testning inom Scrum.

Ja, jag tror att jag har bra koll på te- orin efter dessa år med Scrum.

Respondent A5 Högskoleingen- jörsexamen inom datateknik, examen år 2018.

Till och från i

cirka 1 år. I drygt 1 år. Nej, jag har inte genomgått någon utbildning, utan jag är självlärd.

Jag har inte koll på Scrum till 100

%, men jag tycker jag har bra koll.

Respondent A6 Medicinsk biotek- nik, examen år 2003.

Jag har aldrig arbetat som det och har därför inga sådana kun- skaper.

Jag har arbetat med Scrum se- dan år 2011.

Jag har genom- gått en utbildning för Scrum master och även för Agil coach.

Ja, efter alla dessa år känner jag att jag har bra koll på teorin.

Tabell 2: En tabell över samtliga respondenter och kort bakgrund om berörda personer.

(25)

4.1 Respondent A1

Respondent A1 som intervjuats är en Scrummästare och Agil coach och arbetar på en myndighet vars huvudsakliga uppgift är att hantera en viss typ av problem till olika människor i olika situationer. Myndigheten har idag cirka 14 000 anställda run- tom i landet med kontor på över 50 olika orter i Sverige. Enligt respondenten har denna myndighet arbetat enligt Scrum sedan år 2005. Myndighetens största syfte med Scrum har varit att korta ned ledtiderna från det att ett problem uppstått till att någon lösning satts i produktion där målet varit att hämta hem effekt. Ledtiderna är den viktigaste aspekten inom denna myndighet idag.

Roller

På företaget finns det många olika teams och cirka 5-9 personer i varje team. Varje team är uppbyggt efter personer som har ett gott samarbete. Detta medför att det blir fasta roller för varje team. Teamen är flexibla och nya medlemmar kan adderas in beroende på om förstärkning krävs eller ej. Utvecklarna i teamet ser till att ut- veckla och testa, vilket innebär att en utvecklare även agerar testare. Varje team har en Scrummästare och även rollen produktägare finns i projekten. Företaget har idag projektledare i projekten, men försöker jobba sig ifrån det. På papper innebär rollen som Scrummästare att vara Scrum mästare 50 % och resterande tid skall ägnas åt att jobba med olika funktioner i sprintspecifikationen. I större konstellationer blir det annorlunda eftersom att det per automatik blir så att den personen hanterar mycket ekonomiska frågor med ledningen.

Metodik

En produktägare specificerar upp en produktspecifikation. Teamet har sprintplane- ring där det kan vara lite olika. Är det en ny programvara behöver samtliga medlem- mar delta. Vid befintliga lösningar som många teammedlemmar känner till så räcker det med att en del av teamet deltar vid det mötet för att planera nästa sprint. Många gånger är det även en kravanalytiker som hjälper till och planerar ett antal sprintar framåt som gör att teamet kan börja arbeta med en sprint när det är aktuellt.

Dagliga Scrummöten är möten som hålls varje morgon inom bestämda tidsramar om cirka 15 minuter. Där diskuterar teamet tillsammans med Scrummästare om eventu- ella problem, hur arbetet gått sedan senast och vad som planeras att göra under kommande tid.

När en sprint avslutats hålls ett obligatoriskt granskningsmöte för teamet och vissa gånger kan även produktägaren delta. Vid mötet rullas oftast ett demo av det som utvecklats. Efter ett granskningsmöte har teamet även ett retrospektivmöte där samtliga deltar. Produktägaren är dock inte alltid villig att delta vid detta möte, då denne anser att arbetet berör teamet och inte produktägaren. Vid detta möte utvär-

(26)

Resultat

Teamet använder sig av Burndown chart för att mäta resultat. Det är dock olika mellan olika team, eftersom att vissa delar och funktioner kan hamna på nästa sprint.

Scrummästaren uttrycker att teamet inte är så hårda med det sistnämnda, men att det kan bidra till en mer komplexitet att mäta exakta resultat.

Teamet mäter resultat även genom självskattningsövningar bestående av ett antal olika teman där medlemmarna får chansen att bedöma olika delar. I vissa delar av projekten blir det svårt att mäta resultat då vissa uppgifter går ut på att byta ut en del i en teknisk arkitektur. Det är lättare att möjliggöra en korrekt mätning av resul- tat när nya funktioner skall utvecklas.

4.2 Respondent A2

Respondent A2 är en anställd mjukvaruutvecklare på ett företag vars syfte är att ut- veckla applikationer för iOS och Android för en viss aktivitet som utövas ute i natu- ren. Företaget har idag ett 50-tal anställda personer inklusive ledningen. Med hjälp av applikationerna skall användarna kunna skapa egna loggar, se kartor och olika prognosverktyg för att förbättra upplevelsen. Företaget har idag över tio miljoner användare.

Roller

Företagets utvecklingsavdelningen består idag av fem olika teams och varje team ar- betar med olika delar och väldigt autonomt. Varje team är olika stora och har en helt egen del att hantera. Respondentens team består av 6 personer, två Android-utveck- lare, två iOS-utvecklare, två backend-utvecklare och en projektledare. Projektleda- ren i varje team hanterar det team som den är involverad i och har ungefär samma roll som en Scrum mästare. Han kallas dock för projektledare och inte Scrum mäs- tare eftersom att företaget inte anser att de följer Scrum fullt ut. Vid utveckling av applikationer kan fullstackutvecklare användas för att få in alla delar, men detta före- tag har valt bort sådana. Företaget fokuserar istället på utvecklare med olika expertis för att få en så bra produkt som möjligt och därför har de specifika rollerna valts ut.

Det finns även en produktägare i detta team som specificerar upp sprintspecifikat- ionen.

Metodik

En produktägare specificerar upp en sprintspecifikation. En sprintplanering hålls varannan vecka där projektledaren ger förslag på uppgifter som är aktuella. Diskuss- ioner hålls kring detaljer och en kartläggning görs över vad som krävs från iOS, Android och backend och utifrån det sker en planering för kommande veckor.

Dagliga Scrummöten hålls där samtliga i teamet deltar och presenterar vad varje medlem jobbar med och jobbat med sen senast, men även om det är något specifikt

(27)

som teamet behöver fokusera på extra mycket. Samtliga projektledare har även Scrum av Scrum där en avstämning görs. Mötet säkerställer så att olika teams inte jobbar på samma funktioner och för att även undvika konflikter i olika satsningar.

Vid avslutad sprint avsätter teamet en hel dag för granskningsmötet och retrospek- tivmötet. Samtliga i teamet och projektledaren deltar vid dessa möten. Ett gransk- ningsmöte går till på så vis att teamet diskuterar vad som hade planerats och hur må- let uppnåddes. Teamet går även igenom statistik. Vid retrospektivmötet utvärderas sprinten och en analys görs över vad som gått bra och vad som gick mindre bra. Här försöker teamet att hitta ”Actionpoints”, det vill säga att problem plockas isär till mindre bitar tills det går att lösa, utan att det påverkar någons arbete alltför mycket.

Det skall vara små förbättringar eller förändringar. Detta görs för att teamet skall få in allas åsikter och målet är att alla skall känna sig trygga.

Resultat

Respondenten anser att det nuvarande projektet är ett bra exempel på ett sådant där Scrum varit en viktig roll och metod. Mätningar som gjorts för detta projekt är i form av små lanseringar till användare för att kunna få input. Input samlas in så tidigt som möjligt för att slippa lägga ned tid på något i onödan. Små delar utvecklas och skickas upp och på så vis tas input in på minsta lilla del. Detta har medfört att slut- produkten blivit mer robust och användarvänlig.

4.3 Respondent A3

Respondent A3 är en projektledare som arbetar på en internationell konsultfirma.

Företaget är ett internationellt företag bestående av över 75 000 medarbetare på flera hundra platser i världen. I Sverige är företaget bland de se stora firmorna inom IT och finns på över 30 olika platser bestående av cirka 4 000 medarbetare. Företa- get hjälper kunder med att effektivisera verksamheter genom innovativa och effek- tiva lösningar.

Roller

Företag A3 på en specifik ort i landet har idag ett stort projekt och system bestående av två olika delar, en del för förvaltning och en annan för utveckling. Respondenten konstaterar att projektet egentligen består av ett team och ett subteam, men ser bägge som ett team eftersom att de jobbar så tätt ihop. Respondenten är något mer involverad i utvecklingsteamet bestående av cirka 11-12 personer. Utvecklingstea- met består av individer med olika kompetenser och av den anledningen är rollerna lite uppdelade. Teamet består av utvecklare som både kan utveckla och testa och det finns även testare som inte kan utveckla. Utvecklarna har dock ett ansvar att vid vissa tillfällen åsidosätta tid för testning med. Vid vissa tillfällen finns det delar i ett

(28)

Respondenten har den bestämda rollen som projektledare för både förvaltningstea- met och utvecklingsteamet. Trots rollen som projektledare har han även ansvaret för att facilitera möten såsom sprintplanering, dagliga Scrummöten och även ansva- ret för att strukturera upp sprintspecifikationen. Projektet har ingen involverad pro- duktägare, utan även den biten är projektledarens ansvar att se till att den specifice- ras upp. Respondenten uttrycker att han är en projektledare, men gör det arbete som ingår i en Scrummästares roll.

Respondenten är relativt ny på denna arbetsplats och vet således inte varför företag valt att arbeta enligt Scrum. Han vet dock att denna åtgärd vidtagits vid andra före- tag för ökad leverans, för en jämnare arbetsfördelning och tempo. Det leder även till att samtliga synliggör för varandra vad var och en arbetar med och på så sätt minskar personberoendet.

Metodik

Som tidigare nämnt arbetar respondenten som projektledare, men även som pro- duktägare för att specificera upp produktspecifikationen. Han gör i ordning specifi- kationen och sedan hålls en sprintplanering en gång i månaden, vilket innebär att en sprint är på fyra veckor. En sprintspecifikation är oftast förberedd och sprintplane- ringen blir en genomgång för att säkerställa att allt är korrekt och att den är nedbru- ten i mindre problem. Arbetet innebär även att klargöra förutsättningarna och en planering görs utifrån att olika delar från sprintspecifikationen väljs in.

Dagliga Scrummöten hålls där samtliga deltar och arbetet diskuteras. Upplägget kan vara olika, vid vissa tillfällen diskuteras varje persons uppgift och specifika problem och vid andra diskuteras större funktioner som skall implementeras. Vid mötet framgår det om vissa medlemmar har för lite eller för mycket att göra.

Detta team åsidosätter inte mycket tid specifikt för granskningsmöten eller retro- spektivmöten. Finns det problem som behöver tas upp och diskuteras, sker det många gånger vid det dagliga Scrummötet.

Resultat

Projektledaren är rätt ny här och har inte tillräckligt mycket historia för att dra en slutsats. Han anser att mognaden inte är tillräcklig för att se över statistisk. Det finns inga specifika mätetal på företaget som kan påvisa hur Scrum påverkat resultaten.

Det finns verktyg för Burndown chart, men inget som företaget reflekterar mycket över. I samband med sprintplanering fylls sprinten med timmar och vid avslutad sprint ser de kurvor över timmarna. Det finns dock påtryckningar från ledningen inom företaget om att studera kundnöjdhet, personalens välmående och lönsamhet i företag. Genom detta kan företaget få respons och mätningar från kunder.

(29)

4.4 Respondent A4

Respondent A4 är en Agil coach och Scrummästare som arbetar på ett relativt stort bolag inom försäkring. Bolaget bedriver skadeförsäkringsverksamhet med huvudsak- lig inriktning på den svenska hushållsmarknaden. Företaget erbjuder en rad olika försäkringar till hushåll och privatpersoner med bland annat bil- och boendeförsäk- ringar. Bolaget har enligt siffror från 2019 närmare 4 000 anställda.

Roller

Företag A4 arbetar idag i stora projekt och har fortfarande ett stort projekt enligt Vattenfallsmodellen, trots att målet är att arbeta sig ifrån det och arbeta mer Agilt.

Företaget har ett utvecklingsteam på annan ort i världen där utvecklingen av syste- men sker och som sedan skickas till Sverige för testning. Detta medför att de fortfa- rande arbetar lite enligt Vattenfallsmodellen. Företaget har påbörjat arbetet med Scrum på plats i Sverige och det är ett team som arbetar enligt Scrum. Teamet be- står av 20 personer, trots att ledningen inom företaget föreslagit en uppdelning av teamet för att förenkla arbetet med Scrum. Respondenten agerar Scrummästare och teamet består av även en produktägare och ett gäng utvecklare.

Respondentens roll är att handskas med olika problem och frågor. En stor del i en Scrummästares arbete är att ha en plan, men det ingår även annat såsom berör tea- met och dess omgivning. Produktägaren ägnar mycket tid åt det förberedande arbe- tet för systemet, men deltar även vid teamets möten.

Teamen är uppdelade på olika sätt och tidigare har dessa bestått av endast testare på grund av den externa utvecklingen. Numera ser det lite olika ut, team med endast testare, utvecklare eller team där utvecklare även ängar tid åt testning. Det är upp till varje team att bestämma hur fördelningen skall se ut.

Metodik

Oftast har en del av teamet och Scrummästare tillsammans med produktägaren gjort det förberedande arbetet för produktspecifikationen och även för sprintplaneringen.

Vi sprintplaneringen deltar samtliga i teamet inklusive produktägaren där en genom- gång av sprinten görs för kommande två veckor. Större delen av sprinten har oftast förberetts och teamet ägnar denna tid åt att titta närmare på detaljerna och säker- ställa de. Teamet tittar även på nästkommande sprint för att se frånvaro och hur mycket kapacitet teamet kommer att ha. Samtliga är delaktiga att ta ett beslut gäl- lande vad som är rimligt att hinna med under sprinten och vilka delar som skall tas med till sprinten.

Teamet har även dagliga Scrummöten där Scrummästaren är väldigt noga med att teamet skall hålla sig till ämnet och att mötet varar i max 15 minuter. Vid detta

(30)

- Vad arbetade jag med igår?

- Vad skall jag arbeta med idag?

- Finns det eventuella hinder?

Företaget har även så kallade Scrum av Scrum där minst Scrummästaren behöver delta för att diskutera arbetet. Efter varje sådant möte träffas även en representant från varje team för att diskutera hinder och lösningar mellan teamen.

Granskningsmöten hålls inte, då teamet valt att bjuda in externa deltagare vid ett an- nat tillfälle för en demokörning. Vissa gånger slås detta möte ihop med retrospektiv- möten. Retrospektivmöten är ett viktigt möte för teamet där teammedlemmar och Scrummästare deltar. Mötet hålls med huvudsyftet att diskutera och reflektera över problem och fel som gjorts för att finna lösning inför nästa sprint.

Resultat

Teamet med Scrummästare försöker mäta ledtider, det vill säga hur lång tid det tar för att få delar i systemet klara. Innan arbetet med Scrum och ledtiderna påbörjades kunde det ta två år innan delar blev klara. Idag arbetar teamet med mindre saker och oftare, vilket innebär kortare ledtider. Respondenten har inga exakta siffror, men ser en markant skillnad. Företagsledningen har krav på teamen att mäta hur många funktioner per iteration som teamen klarar av att utveckla. Det är dock upp till varje Scrummästare att bestämma hur denna mätning görs. Detta utförs på olika sätt bero- ende på Scrummästarens intresse för statistik och resultat.

4.5 Respondent A5

Respondent A5 är en projektledare för ett globalt företag vars huvuduppgift är att utveckla elektronik, elektromekanik och mjukvara. Företaget är idag ett globalt fö- retag med kontor i ett antal länder runtom i världen. Företaget har idag cirka 1 300 anställda.

Roller

Respondenten är idag en projektledare för detta projekt och är ett pågående projekt under längre tid. Teamet skall utveckla stöd åt en befintlig mjukvara som är på- gående. Projektet består av tre olika teams, ett eftermarknadsteam, ett utvecklar- team och ett supportteam. Varje team består av sex personer. Utvecklarteamet be- står av endast utvecklare som utvecklar och testar mjukvaran. Teamet använder Continues Integration och Jenkins för tester, vilket innebär automatiska tester och färre manuella tester för det som utvecklat.

Projektet har en produktägare som är ansvarig för produktspecifikationen och dess upplägg. Projektledaren arbetat tätt med produktägaren vid upplägg av produktspe-

(31)

i det dagliga arbetet med planering och finns för att avlasta Scrummästarens arbetet.

Projektet har även en Scrummästare, vars uppgift är att vara mer involverad i tea- mets arbete. Scrummästaren är ansvarig för att facilitera samtliga möten.

Metodik

Oftast har projektledaren och produktägaren ett möte dagen innan en sprintplane- ringen och av den anledningen deltar han inte vid det mötet. Däremot deltar reste- rande personer involverade i teamet där de tillsammans bestämmer vad som skall prioriteras och lyftas in i nästa sprint, som är två veckor lång. Teamet har uppgiften att bryta ned arbetsuppgifter i mindre delar. Vid detta möte planeras närvaro och frånvaro med procentsats där en viss procent sätts på varje person för att se hur mycket personen ifråga kommer vara närvarande. Effektivt tid för utveckling är 65%

och resterande tid beräknas åsättas för planering, hjälpa andra och annat. Med hjälp av planeringsverktyget Hansoft planeras tiden för att se hur mycket arbetsuppgifter teamet klarar av att utföra.

Teamet och samtliga team i projekt har dagliga Scrummöten som är olika långa.

Vissa anser att det endast krävs fem minuter för en genomgång och vissa önskar lite längre tid. Det mötet hålls för att diskutera läget och för eventuella hinder. Teamet försöker att uppdatera tid för en uppgift om det tar kortare eller längre tid, för att se när nästa uppgift kan påbörjas.

Projektet har mer ett forum för Scrummästarna istället för Scrum av Scrums där dis- kussioner kan föras. Teamet har inget granskningsmöte, utan endast ett retrospek- tivmöte.

Vid retrospektivmöten deltar samtliga förutom produktägaren. Det mötet hålls varannan vecka och teamet arbetar med lappar där varje person skriver ned vad som funkat bra och mindre bra. Teamet hinner dock inte gå igenom samtliga lappar, så de allra viktigaste gås igenom och försöker åtgärdas. Dock finns det ingen i teamet som följer upp åtgärden för att se hur det gått.

Resultat

Företaget har ingen direkt specifik mätning för resultat. Teamet har ett mätresultat från produktionen där antal felmeddelanden kan beräknas med en procentsats. Där kan både kund och teamet vara orsaken till felmeddelandet beroende på om det är fel i test eller användning. Trots detta försöker teamet att ligga på en procent över 95 %. Inga andra mätresultat som Burndown chart eller liknande används.

4.6 Respondent A6

Respondent A6 har rollen Agil coach och Scrummästare och arbetar på en obero-

(32)

Roller

Oftast har företaget en strategisk produktägare eller projektledare som rotar i kun- dens problem och undersöker om kunden är villig att betala för att få tillgång till produkt. Företaget har både kommersiella produkter och mjukvaror som de inte tar betalt för. En grovplanering görs för att se vad som behöver lösas. Under tiden detta görs, finns det operativa produktägare som skuggar den strategiska produktägaren för att se mer detaljer i produkten i helhet. Här diskuteras kostnad och möjlighet att göra produkten och när detta är klart byggs en så kallad ”Walking-skeleton” för att se om det är möjligt att bygga utifrån vad som är tänkt. När modellen byggts och teamet ser att det är möjligt, påbörjas arbetet med den riktiga produkten.

Organisationen har idag fem olika team bestående av 7-8 personer i varje team. Tea- met har en produktägare och i vissa fall har två team samma produktägare. Två av teamen har även en test coach. Teamen har dock inga Scrummästare, utan det är re- spondenten som agerar Scrummästare för samtliga team. Scrummästarens uppgift är att koordinera arbetet, facilitera möten och delta vid olika möten. Samma person har även uppgifter som att ta fram strategier för infrastrukturen och sköta arbetet med projektledaren. Teammedlemmar har rollen utvecklare, men ser till att göra ett testarbete med, även fast organisationen försöker automatisera testerna. Organi- sationen har produktägare som kommer uteslutande från företaget och hjälper till att få produktspecifikationen komplett.

Metodik

Teamen har sprintar om två veckor och vid sprintplaneringen ser teamet över när- varo för kommande period. Vid mötet har produktägaren oftast ett mål med sprin- ten och ett antal uppgifter. Den personen skall ha koll på hur mycket som skall tas med på varje sprint, det vill säga hur mycket som teamet klarar av. Teamet har valt bort att mäta i timmar eftersom att det sällan stämmer. Trots planeringen från pro- duktägaren kan teammedlemmar vara med och påverka vad som teamet skall lägga fokus på inför kommande sprint.

Vid dagliga Scrummöten ser teamen till att diskutera olika arbetsuppgifter uppifrån och ned utifrån specifikationen för sprinten istället för varje individs arbete. Tillsam- mans försöker de identifiera vad som skall göras och efter mötet diskuterar berörda personer lösningen. Respondenten uttrycker att teamet tillsammans försöker foku- sera på att saker kommer i rätt ordning än att fokusera på personer.

För att stämma av mellan olika teams hålls Scrum av Scrum där produktägare, Scrummästare, chef för utvecklingssektion, chef för produktchefer och även pro- duktcheferna deltar. Vid mötet reder deltagarna ut status på förstudier och där dis- kuteras även koordinering mellan samtliga team och produktägare.

(33)

Varje sprint avslutas med ett granskningsmöte där produktchef, utvecklingsteam, Scrummästare, enterprise arkitekt och interna användare deltar. Vid mötet hålls en kort demonstration på det som åstadkommits med hjälp av ett GUI och en kort Po- werPoint-presentation. En utvecklare ser till att facilitera det mötet och det görs samma dag under dagliga Scrummötet. I anslutning till granskningsmötet hålls även ett retrospektivmöte där teamet diskuterar vad som gått bra och mindre bra och eventuella lösningar på problemet.

Resultat

Tidigare mätte teamen resultat med hjälp av Burndown chart, men sedan en tid till- baka har det valts bort på grund av stor fokus på kurvan. Stor fokus lades på att kur- van skulle bli bra och mindre fokus på ett bra resultat. Numera gör teamet en relativ poängsättning av produktspecifikationen och alla uppgifter i början av ett projekt och sedan följs hastigheten. Detta gör teamet för att få en indikation på om det hin- ner bli klart under avsatt tid, men även för att se om mycket tid lagts på oplanerat arbetet. Teamet har dock inte analyserat några resultat från projekt utifrån meto- den.

(34)

5 Diskussion

Det inledande arbetet med studien var att företag kontaktades, första kontakten som nämnts tidigare. Drygt 30 företag kontaktades och cirka 13 företag svarade på första mailkontakt och ur dessa valdes 6 företag, som arbetade enligt Scrum och hade en Scrummästare eller projektledare för eventuell intervju. Förhoppningarna var att fler företag skulle svara och visa intresse för studien, men så var inte fallet. Det svaga intresset medförde att tidsplaneringen ändrades vid det inledande förberedande ar- betet med intervjuer. Det tog längre tid att genomföra intervjuerna eftersom att da- tum för intervjuer skulle bokas in och passa både mig och respondenterna. Planen var att samtliga intervjuer skulle genomföras första veckan, men det tog istället cirka tre veckor innan de var genomförda.

Planen för intervjuerna var att de skulle utföras på plats hos olika företag, men på grund av rådande situation kring COVID-19 ändrades planerna och intervjuerna ge- nomfördes via kommunikationsprogrammet Zoom. Trots COVID-19 intåget kunde intervjuerna genomföras på ett smidigt och bra sätt. Detta medförde att jag på ett enkelt sätt kunde genomföra intervjuer med respondenter på andra orter i landet.

Enligt min teori bidrog situationen till att fler företag hade respondenter med lite tid över för intervjuer. Med tanke på det relativt svaga intresset för intervjuer bidrog detta till att studien kunde genomföras med intressenter på andra platser i landet.

Syftet med arbetet var att få ut information om hur metoden används i praktiken för att sedan göra en jämförelse med teorin. Valet av intervjufrågor var mycket bra och gav konkreta svar angående hur metoden används i praktiken. Intervjuerna blev väl- digt omfattande eftersom att en hel metod skulle studeras och trots detta skulle fler frågor behövts ställas angående slutresultatet. Respondenterna gav ingen större in- blick i resultat från varje projekt. Om respondenterna hade varit villiga att lämna mer information om resultat, hade studien blivit bättre med mycket information kring resultatet för en bättre summering. Samtliga deltagande respondenter var soci- ala, vilket medförde att det blev bra intervjuer med mycket information från varje person. Valet av metoden för studien var ett bra val för att få ut den viktiga inform- ationen.

Resultaten som samlats in via intervjuer och kring metoden var sådant som var för- utsatt. Innan studien påbörjades fanns det en aning om att metoden Scrum används där större delar implementeras, men att det skulle bestå av modifieringar och resul- tatet av studien visade just det.

(35)

5.1 Diskussion av resultat

5.1.1 Roller i teamen

Enligt teorin som beskrivits tidigare i rapporten skall ett team i Scrum bestå av cirka 7 personer +/- 2 personer för bästa möjliga resultat och varje person skall ha en egen roll. Om ett team består av färre medlemmar blir slutsatsen att de olika med- lemmarna måste ta sig an nya roller. Ett team skall enligt teorin bestå av en produkt- ägare, en Scrummästare och ett antal utvecklare.

Samtliga företag som deltagit i studien har gett olika siffror på antalet medlemmar i varje team och det varierar med några personer. Företag A1 har team bestående av 5-9 personer, varav en produktägare, en Scrummästare och resterande utvecklare med bestämda roller. Medlemmarna i teamet har rollen som utvecklare, men agerar även testare när det krävs. Teamet har även en projektledare, trots att målet är att arbeta sig ifrån det. Företag A2 har olika teams, men respondentens team består av 7 personer, varav en projektledare. Detta team har bestämda roller för medlemmarna eftersom att företaget satsar på utvecklare med olika expertis för bästa möjliga resul- tat. Företaget har även en produktägare som ser till att specificera upp produktspeci- fikationen. Företag A3 har teams bestående av 11-12 personer varav en projektle- dare och övriga utvecklare med bestämda roller. Projektledaren uttrycker att han är projektledare, men gör det arbete som Scrummästaren gör och agerar även produkt- ägare genom att specificera upp produktspecifikationen. Roller är uppdelade ef- tersom att de besitter olika kompetenser, men samtliga har dock ansvar att testa så- dant som utvecklas. Företag A4 har idag ett team bestående av 20 medlemmar, trots rekommendationer från ledningen om en uppdelning om två för att underlätta arbe- tet med Scrum. Teamet består av en produktägare, Scrummästare och ett antal ut- vecklare. Rollerna för utvecklarna är olika i olika team, i vissa team är utvecklarna både utvecklare och testare och i vissa team finns det bestämda testare. Företag A5 har olika teams och respondentens team består av 6 medlemmar med bestämda rol- ler som utvecklare. Teamen har även en produktägare, en projektledare och en Scrummästare. Scrummästaren arbetar närmare teamet och projektledare sköter ar- betet i högre skikt mot kund och ledningen. Företag A6 har en Scrummästare som har rollen för tre olika teams och varje team har även en produktägare som ansvarar för produktspecifikationen. Varje team består av 7-8 personer med roller som ut- vecklare, men har även ansvaret för att se till att testning utförs.

Den slutsats som kan dras enligt ovanstående resultat är att samtliga företag har ett team på minst 6 medlemmar. Vissa team har ungefär 8 personer i varje team, som teorin säger, och vissa har fler. Ett företag har även 20 medlemmar, men som re- kommenderats en uppdelning för bästa resultat. Rollerna ser olika ut i teamen, men

(36)

Projektledarna i dessa projekt har rollen projektledare, men agerar Scrummästare i det dagliga arbetet. Projektledare eller Scrummästare arbetar ungefär med samma typ av arbetsuppgifter och det är endast benämningen som skiljer de åt. Nästintill alla team har en produktägare som ser till att specificera upp produktspecifikationen, förutom företag A3 där produktägare saknas och arbetet görs av antingen Scrum- mästare eller projektledare.

5.1.2 Metodiken i teamen

För samtliga företag, förutom A3 finns det produktägare som ser till att en produkt- specifikation upprättas innan en sprintplanering. Företag A3 har däremot en projekt- ledare som ser till att specifikationen ordnas. Specifikationen är en viktig del i arbe- tet och samtliga företag ser till att den är färdigställd och genomtänkt. Sprintplane- ring är ett möte som genomförs av samtliga företag, dock är innehållet lite olika. Fö- retag A1 har sprintplaneringar där samtliga deltar om det är ny programvara. Vid befintliga lösningar behöver endast en del av teamet närvara. Teamet har även en kravanalytiker som planerar ett antal sprintar framåt så teamet kan påbörja arbetet så fort det är aktuellt. Resterande företag har liknande sprintplaneringar där teamet tillsammans med Scrummästare och produktägare har en genomgång av kommande sprint. Där diskuteras vad som skall prioriteras och lyftas in och teamet kan även vara med och ge åsikter på sådant som de inte förstår eller kanske inte anser vara mest prioriterad. Företag A5 sätter under sprintplaneringen en procentsats på varje individ som påvisar individens närvaro vid kommande sprint. Detta görs med plane- ringsverktyget Hansoft och detta görs för att få en bild över hur mycket teamet kla- rar av att utföra. Detta är en metod som skiljer sig från resterande.

Även dagliga Scrummöten är ett möte som genomförs av samtliga företag och team.

Målet med dagliga Scrummöten är enligt respondenterna att teammedlemmarna pratar om vad som gjorts sedan senast, vad som planeras göras kommande tid och eventuella hinder. Företag A6 har däremot ett annat upplägg av mötet, där väljer teamet att fokusera på varje uppgift från specifikationen, uppifrån och ned istället för varje individ och dess arbete. Diskussion kring olika uppgifter sker och efter mötet diskuterar berörda personer eventuella lösningar.

Företag A2, A4 och A6 har även ett Scrum av Scrum möte för en avstämning tea- men emellan. A2 har en genomgång under mötet för att säkerställa att olika teams inte jobbar på samma funktioner och för att undvika konflikter i olika satsningar. Fö- retag A4 har Scrums av Scrums där Scrummästarna diskuterar arbetet och efter mö- tet träffas en representant från varje team för att diskutera hinder och lösningar mel- lan teamen. Företag A6 lägger stor vikt på det mötet och där deltar projektledare, Scrummästare, chef för utvecklingssektion, chef för produktchefer och även pro- duktcheferna själva. Där diskuteras status på förstudier och även koordinering mel-

(37)

Varje sprint skall avslutas med en sprint review, ett granskningsmöte, men även där är det lite olika. Företag A3, A4 och A5 har valt bort granskningsmöten. Företag A4 har inte detta möte då externa deltagare bjuds in vid ett annat tillfälle för demokör- ning. Företag A1håller granskningsmöten där ett demo körs av det som utvecklats.

Det är ett obligatoriskt möte för teamet och ibland kan även produktägaren delta.

Även företag A2 håller ett sådant möte där teamet diskuterar vad som hade planerats och hur målet uppnåddes. Teamet lägger även ned lite tid på att gå igenom statistisk.

Företag A6 har även de ett sådant möte där produktchef, utvecklingsteam, Scrum- mästare enterprise arkitekt och interna användare deltar. Vid mötet hålls en kort de- monstration på det som åstadkommits med hjälp av ett GUI och en kort Power- Point-presentation. En utvecklare får uppdraget att facilitera mötet.

Avslutningsvis skall ett så kallat retrospektivmöte hållas efter en sprint och efter granskningsmötet, och oftast i anslutningen till det mötet. Företag A1, A4 och A6 håller retrospektivmöten där teamet deltar och vid vissa fall även produktägaren, för att utvärdera sprinten och diskutera eventuella förbättringar för nästkommande sprint. Även företag A2 har detta möte men teamet fokuserar på att hitta ”Act- ionspoints”, problemen plockas isär till mindre bitar tills det går att lösa. Detta görs utan att det skall påverka någons arbete för mycket. Företag A3 ägnar inte mycket tid alls åt retrospektivmöten, precis som granskningsmötet. Finns det problem som behöver diskuteras, görs det vid det dagliga Scrummötet. Företag A5 håller retro- spektivmöten med lappar där var och ned skriver ned det som behöver förbättras.

De viktigaste lapparna och åtgärderna röstas fram och gås igenom för att åtgärdas, dock finns det ingen som följer upp för att se hur det gått.

Samtliga teams specificerar upp en produktspecifikation och planerar sprintar, vilket är en stor del i Scrum. Dessa teams håller även dagliga Scrummöten som även det är en stor del för att få arbetet att rulla och fungera på rätt sätt. Det som är avvikande gällande metoden är att vissa teams inte lägger ner mycket energi och tid på gransk- ningsmöten och retrospektivmöten. Scrum av Scrum är även ett möte som inte är särskilt aktuellt för alla, och detta för att varje team har tydliga beskrivningar över vad det teamet skall syssla med. På så vis minskar risken för att två teams skall arbeta på samma funktioner, som är något teamet säkerställer under ett sådant möte.

5.1.3 Resultatmätning i teamen

Gällande resultat har samtliga företag någon typ av mätning för resultat och dessa re- sultat skiljer sig åt. Däremot har inga specifika mätresultat i form av siffror presente- rats under intervjuerna. Både företag A1 och A3 har mätverktyg för Burndown chart, men inget de reflekterar över särskilt mycket. A1 mäter resultat även genom självskattningsövningar där medlemmar får chansen att bedöma olika delar i pro-

(38)

statistisk över i form av kurvor över timmarna. Däremot har teamet krav från led- ningen inom företaget att studera kundnöjdhet, personalens välmående och lönsam- het i företaget. Även företag A6 har använt sig av Burndown chart, men har numera plockat bort den mätningen eftersom att teamet ägnade mycket tid åt att fokusera på kurvan istället för bra resultat. Idag fokuserar teamet på att poängsätta produktspeci- fikationen och mäta hastigheten och detta ger indikation på om det poängsatta hinner bli klart under avsatt tid.

Företag A2 gör mätningar i form av små lanseringar till användare för att få input och ju tidigare dessa input inkommer, desto mindre tid ägnas åt delar i onödan.

Detta har enligt respondenten medfört att slutprodukten blivit mer robust och an- vändarvänlig.

Företag A4 fokuserar på ledtider, och arbetar idag med mindre delar och oftare, vil- ket leder till kortare ledtider. Respondenten har inga specifika siffror, men ut- trycker att de sett en markant skillnad. Företagsledningen har däremot krav på tea- men att mäta hur många features per iteration som teamet klarar av att hantera. En- ligt respondenten utförs detta på olika vis beroende på Scrummästarens intresse. Fö- retag A5 mäter antal felmeddelanden genom procentsats där kravet är att ligga på minst 95 % fungerande system. Liksom många andra finns inga andra mätresultat som Burndown chart eller liknande.

Resultatmätningen är något dessa teams inte lägger ned särskilt mycket tid på. Vissa gör mätningar av olika slag, men det är inget som används i syfte att förbättra eller analysera konkreta resultat. Detta medför att just den biten skiljer sig mycket mellan praktiken och teorin, då den teoretiska biten handlar om att utföra statistik med hjälp av Burndown-chart.

References

Related documents

Vi resonerade kring hur detta kunde påverka utvecklingen och Scrum och kom fram till att så länge vi tog ansvar för respektive roll vid rätt tillfälle så skulle det inte bli

I den här studien kommer kulturella skillnader att undersökas mellan Brasilien och Sverige för att sedan ta reda på hur dessa påverkar arbetet med scrum och

The vision can help to create a shared understanding in the team and gives direction to the software development projects.. The vision is not a part of the Scrum process but

Vilket resulterade i att systemet enbart såg de som aktiva studenter under andra terminen när de läste i Uppsala men inte i Stockholm Ett tag la man in de studenterna temporärt på

Införa bättre prognostisering: För att företag ska kunna flytta sin KOP och minska risken med arbetet att fylla lager efter riskfyllda lagernivåer bör man enligt den

En slutsats som kan dras är att både logistik och marknadsföring syftar till att skapa värde för kund.. Det som skiljer de två begreppen åt är de metoder som används för att skapa

Spänningarna är beräknade för systemet under drift och för befintligt rörsystem efter fixerade punkter lades in vid nod 1900, 1240 och 1320.. Figur 19 visar en 3D-genererad bild

Till denna studie har utöver de undersökta naturliga populationerna från prestudien även öring från två närliggande fiskodlingar undersökts eftersom öringar från