Evaluering af tilpassede SCRUM metoder - report final · Men hvor meget kan metoden egentlig...

of 69

Evaluering af tilpassede Scrum

metoder

Rapport

Gruppe: 10

Jan Thorup Bjerg (20064588)

Dato: 14-06-2012

Abstract

Scrum er en banebrydende metode og er på kort tid blevet den mest benyttede indenfor agil softwareudvikling. Men metoden bruges ikke altid helt i overensstemmelse med retningslinjerne, hvilket må ses som et udtryk for, at metodens elementer er stærke projektledelsesprincipper, som med fordel kan bruges i andre sammenhænge.

Jeg har i dette studie analyseret og fortolket brug af Scrum i fire virksomheder, som arbejder med softwareudvikling, for at søge en forklaring på hvorfor Scrummetoden ofte bruges på forskellig vis. Undersøgelsen indikerede, at der var brug for et digitaliseret Scrumværktøj til understøttelse af atypisk Scrumbrug. Derfor har jeg på baggrund af analysen, eksisterende forskning i brugen af Scrum samt softwarearkitektoniske principper lavet en mockup prototype af et digitaliseret Scrumværktøj, som kan understøtte denne brug af Scrum.

of 69

Indhold

1 Motivation ......................................................................................................... 4

1.1 Indledning ................................................................................................. 4

1.1.1 Kort om Scrum .................................................................................. 4

1.2 Agil udvikling og Scrum ........................................................................... 6

1.3 Kort om Scrum .......................................................................................... 7

1.3.1 Scrummetoden og dens bestanddele ................................................. 7

1.4 Kanban .................................................................................................... 10

2 Problemformulering ........................................................................................ 12

2.1 Afgrænsninger ......................................................................................... 12

3 Relateret arbejde ............................................................................................. 13

3.1 Andre projekter ....................................................................................... 13

3.1.1 Scrummer ........................................................................................ 13

3.1.2 Det interaktive Scrum Board ........................................................... 14

3.1.3 The Cooperative Task Board .......................................................... 16

3.1.4 Diskussion af projekterne ................................................................ 16

3.2 Eksisterende værktøjer ............................................................................ 17

3.2.1 SpiraPlan ......................................................................................... 17

3.2.2 JIRA-Greenhopper .......................................................................... 19

3.2.3 Axosoft ............................................................................................ 20

3.2.4 VersionOne ..................................................................................... 22

3.2.5 Scrum-it ........................................................................................... 23

3.2.6 Sammenfatning ............................................................................... 24

4 Metode ............................................................................................................ 25

4.1 Interviews ................................................................................................ 25

4.2 Geeknight event ...................................................................................... 26

4.3 Softwarearkitektur ................................................................................... 27

4.3.1 Arkitektur for et Scrumsystem ........................................................ 28

4.3.2 Tactics ............................................................................................. 29

5 Analyse og diskussion ..................................................................................... 32

5.1 Interviews og event ................................................................................. 32

5.1.1 Interview med Birte, Logica ........................................................... 32

5.1.2 Interview med Thomas, Vertica ...................................................... 34

5.1.3 Interview med Henrik, Unifeeder ................................................... 35

of 69

5.1.4 Interview med Svend, Alexandra Instituttet .................................... 36

5.1.5 Geeknight om ”Distributed Scrum and Agile” ............................... 38

5.2 Udfordringer ved brug af Scrum ............................................................. 39

5.2.1 Resultat af interviews ...................................................................... 39

5.2.2 Tilpasning af Scrum ........................................................................ 39

5.2.3 Hvad gør Scrum så populær? .......................................................... 43

5.2.4 Brug af Scrum værktøjer ................................................................. 43

6 Generisk Scrum prototype .............................................................................. 46

6.1 Systemkrav .............................................................................................. 46

6.1.1 Funktionalitet .................................................................................. 47

6.1.2 Pervasive interaktion ....................................................................... 49

6.1.3 User Stories ..................................................................................... 51

6.1.4 Interfaces ......................................................................................... 55

6.1.5 Objekter ........................................................................................... 56

6.2 Præsentation af prototypen...................................................................... 58

6.3 Feedback på prototypen .......................................................................... 58

7 Konklusion ...................................................................................................... 60

8 Referencer ....................................................................................................... 62

9 Appendiks ....................................................................................................... 64

9.1 Interviewguide ........................................................................................ 64

9.2 Interviewskema ....................................................................................... 65

9.3 Mockup Prototype ................................................................................... 68

of 69

1 Motivation

1.1 Indledning

Formålet med dette studie er at bidrage med viden om brug af Scrum i forskellige virksomheder og hvilke Scrumværktøjer, de har valgt at benytte, samt at præsentere en værktøjsprototype til understøttelse af atypisk brug af Scrum. Studiet tager udgangspunkt i en undersøgelse af erfaringer fra fire virksomheder i Århusområdet, som bruger Scrum på hver sin måde. Erfaringerne er indsamlet vha. interviews med repræsentanter for disse virksomheder, samt forfatterens egne observationer om brug af Scrum hos Unifeeder. På baggrund af disse undersøgelser vil jeg søge at kombinere It-projektledelse, softwarearkitektur og pervasive computing i en værktøjsprototype, som kan understøtte atypisk brug af Scrum.

Der er to hovedgrene indenfor forskning om udbredelsen af Scrum: studier i effekten af omlægning til Scrum og etnografiske studier af metodens introduktion i forskellige virksomheder ol. Der findes kun enkelte studier, som beskriver erfaringerne med Scrum og hvorledes denne proces understøttes (Kniberg, 2006). Heriblandt mangler der undersøgelser, som kortlægger virksomheders erfaringer mht. brug af Scrum i årene efter, at metoden er implementeret i virksomheden.

Den øvrige del af studiet er organiseret som følger:

Kapitel 2: En detaljeret problemformulering som beskriver de spørgsmål, som dette studie vil besvare.

Kapitel 3: En gennemgang af relateret forskning og analyse af enkelte eksisterende værktøjer på markedet.

Kapitel 4: Præsentation af den valgte metode.

Kapitel 5: Gennemgang og diskussion af interviewdata på baggrund af eksisterende forskning om brug af Scrum samt Kanban. Derudover præsenteres et udkast til et digitaliseret Scrumværktøj.

Kapitel 6: Præsentation af en generisk mockup prototype af et Scrumsystem.

Kapitel 7: Konklusion.

1.1.1 Kort om Scrum

Scrum er på kort tid blevet den mest udbredte udviklingsmetode inden for agil softwareudvikling (Sutherland & Schwaber, 2007; Hossain et al., 2009; Overhage et al., 2010). Men metoden er ofte tilpasset den kontekst eller empiri, hvori den indgår, som atypisk brug af Scrum. Mange softwarevirksomheder, som benytter Scrum metoden har ofte ændret noget i forhold til Sutherland & Schwaber’s oprindelige metode. Denne opfattelse bekræftes bl.a. af videnskabelige artikler og eksisterende forskning inden for dette område (Overhage et al., 2010; Rising & Janoff, 2000).

of 69

I 2008 publicerede Salo og Abrahamsson en undersøgelse om brug af Scrum og XP i den europæiske softwareindustri. Af denne undersøgelse fremgår det bl.a. at Product Backloggen det mest benyttede Scrum element, men også at det er meget varierende i hvilket omfang, de andre Scrum elementer benyttes (Salo & Abrahamsson, 2008).

Fig. 1. Brug af Scrumelementer i projekter (Salo & Abrahamsson, 2008).

Selvom atypisk brug af Scrum ikke var undersøgelsens fokus, må ovenstående også ses som et udtryk for, at en del virksomheder ikke benytter Scrum i sit fulde omfang.

Atypisk brug af Scrum, hvor metoden ikke bliver fulgt præcist, fordi en af metodens regler, ceremonier og artefakter ikke bliver benyttet, bliver også kaldt for Scrum-but (Scrum).

En Scrum-but defineres med syntaksen (ScrumBut)(Reason)(Workaround) og de er hver især forskellige grunde til, at et team eller en organisation ikke umiddelbart kan drage fuldt udbytte af Scrum. Hver rolle, regel og timebox i Scrum er designet til at opnå de ønskede fordele eller løse kendte tilbagevendende problemer. Scrum-buts afslører en dysfunktion eller defekt, der bidrager til et problem, men som ikke umiddelbart kan afhjælpes. Ved at introducere Scrum-buts og derved ændre på Scrummetoden, usynliggøres dysfunktionen, så den ikke længere er til gene for teamet.

Eksempel "(vi bruger Scrum, men...) (afholdelse af Daily Scrummøde hver dag er

unødvendigt,) (så vi afholder kun et pr. uge)" (Scrum)

Men hvor meget kan metoden egentlig ændres og stadig kaldes for Scrum? Ifølge The Scrum Guide er der kun mulighed for meget små ændringer, før der ikke længere er tale om Scrum:

”Scrum exists only in its entirety and functions well as a container for other

techniques, methodologies, and practices” (Sutherland & Schwaber, 2011, s.15).

Men som jeg senere vil komme ind på i kapitel 5, er der ikke helt enighed om denne fortolkning og der er flere forskellige fortolkninger af, hvad Scrum er – og hvad metoden, frameworket eller ”værktøjskassen” kan bruges til.

Ovenstående kan være et udtryk for, at alle, som bruger Scrum, ikke er helt afklaret omkring metoden og dens begrænsninger. Men det kan også være et udtryk for, at

of 69

nogle af de elementer, som indgår i metoden, er stærke projektledelsesprincipper, som med fordel kan bruges i mange andre sammenhænge, hvor der ikke nødvendigvis er tale om softwareudvikling (Nyboe et al., 2009).

I forbindelse med brug af Scrumværktøjer er det iøjnefaldende, at de softwareproducenter, som lever af at udvikle digitaliserede systemer, ofte selv benytter lavpraktiske værktøjer. Det kan f.eks. være en tavle med små selvklæbende sedler, tegnede Burndown Charts og Excel ark (Kniberg, 2006; (Ericsson et al., 2011).

Der findes en del software på markedet, som understøtter Scrumprocessen, men i flere tilfælde benyttes de kun, når en lavpraktisk løsning ikke længere er brugbare – f.eks. ved distribuerede eller globaliserede Scrumteams (Hossain et al., 2009). Nogle af disse systemer bliver gennemgået senere i afsnit 3.2

Forskning viser, at administrative Scrumværktøjer skal være intuitive og indgå som naturlige del af Scrumprocessen for at blive accepteret og anvendt (Alexandra; Rubart & Freykamp, 2009). Men Scrum er underudforsket i forhold til metodens udbredelse. Det er hovedsagelig effekten ved at introducere Scrum i form af forøget produktivitet, kvalitet og kundetilfredshed, som er blevet undersøgt (Overhage et al., 2010). I andre tilfælde er der tale om etnografisk forskning med fokus på Scrumimplementeringsprocessen i en organisation (Marchenko & Abrahamsson).

1.2 Agil udvikling og Scrum

I 90'erne var det almindeligt, at softwareudvikling blev baseret på en langsigtet udviklingsindsats med stabile og disciplinerede processer. I modsætning hertil var der en tendens til, at mange softwareprojekter blev berørte af hurtige ændringer i krav og uforudsigelig kompleksitet. Dermed opstod et behov for at opnå en balance mellem fleksibilitet og disciplin i udviklingen, hvilket blev grundlaget for den agile softwareudvikling (Pries-Heje, 2011).

Agil udvikling er et paradigme inden for softwareudvikling, hvor man i modsætning til den ”klassiske” softwareudvikling fokuserer på nogle agile principper:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

(agilemanifesto)

Baggrunden for det agile paradigme skal bl.a. findes i nedenstående fejl og faldgruber, som er blevet identificeret i forbindelse med den klassiske vandfaldsmetode tilgang (Sutherland & Schwaber, 2007):

• Requirements are not fully understood before the project begins

• Users know what they want only after they see an initial version of the software

of 69

• Requirements change often during the software construction process

• New tools and technologies make implementation strategies unpredictable

Der findes en række forskellige anerkendte metoder til understøttelse af agil softwareudvikling: Extreme Programming (XP), Adaptive Software Development

(ASD), Dynamic Systems Development Method (DSDM), Crystal, Feature Driven

Development (FDD), Agile Modeling, Kanban og Scrum, hvoraf Scrum er den mest udbredte.

Visionen i de agile metoder er en mere lærende eller eksperimentel tilgang, hvor man typisk opdeler udviklingen i mindre iterationer, som i højere grad tillader ændringer, samt sikrer hurtigere fremdrift mht. eksekverbar kode (Rising & Janoff, 2000). Iterationerne indeholder de almindelige udviklingsaktiviteter: analyse, design, kodning og test (Pries-Heje, 2011).

Hovedtemaerne i de agile udviklingsmetoder er hurtigere brugbar kode og tæt samarbejde:

”Agile methods stress two concepts: the honesty of working code and the

effectiveness of people working together with goodwill” (Highsmith & Cockburn, 2001, s.121).

Hvor metoderne, udover at understøtte de agile principper, skal sikre struktur i forbindelse med udviklingen, for at undgå ad hoc eller ”cowboy coding” (Highsmith & Cockburn, 2001).

1.3 Kort om Scrum

Scrum er udsprunget af inspiration fra japansk best business practices baseret på Lean principper og team-building, som i 80’erne blev udviklet i japanske industrigiganter som f.eks. Honda og Toyota - og senere beskrevet af Takeuchi & Nonaka (Sutherland & Schwaber, 2007).

Scrum blev udviklet i 90’erne af Jeff Sutherland og Ken Schwaber blandt andre. Metoden blev introduceret i forbindelse med et softwareprojekt hos Easel Corporation i 1993 (Sutherland & Schwaber, 2007) og første gang præsenteret for offentligheden ved OOPSLA konferencen i 1995 (Sutherland & Schwaber, 2011).

Scrum er banebrydende og er på kort tid blevet den mest benyttede metode indenfor agil udvikling af komplekse softwareprodukter (agilemanifesto).

Men i litteraturen varierer opfattelsen af, hvad Scrum er og hvordan det kan bruges – f.eks. i hvilket omfang tilpasning er muligt. Dette ser vi nærmere på i afsnit 5.2.2.

1.3.1 Scrummetoden og dens bestanddele

Begrebet Scrum stammer fra Rugby, hvor holdene samles i en klynge for at kæmpe om bolden og føre den videre frem på banen (Sutherland & Schwaber, 2007). I denne forbindelse bruges udtrykket som en metafor for, hvorledes et udviklingsteam (det ene hold) samarbejder om at få produktet (bolden) i mål.

of 69

Kort fortalt er Scrum en iterativ proces, hvor en iteration (kaldet et Sprint) normalt varer fra to til fire uger. Den ønskede funktionalitet er beskrevet i forretnings- eller almindeligt sprog i form af User Stories, som prioriteres i en Product Backlog af en Product Owner, der repræsenterer kundens synspunkter (Fig. 2).

Den højest prioriterede funktionalitet bliver udvalgt som målet for udviklingen i et Sprint. Et Sprint starter med et Sprint Planning møde, hvor den udvalgte funktionalitet brydes op i mindre opgaver, som estimeres mht. udviklingstid.

Under et Sprint mødes projektgruppen dagligt til et Daily-Scrum stand-up møde, som ofte finder sted foran et Scrum Board beklædt med sedler, der hver især repræsenterer en opgave.

Mødet må ikke tage mere end 15 minutter og ledes af en Scrum Master, som er ansvarlig for processen og at teamet fungerer optimalt. Under mødet skal hvert teammedlem besvare tre spørgsmål:

1) Hvad han/hun har gennemført siden sidste møde

2) Hvad han/hun vil gennemføre inden næste møde

3) Hvilke hindringer der evt. er i vejen for, at han/hun kan gennemføre sit arbejde

Hver gang en opgave er færdig, flyttes den på Scrum Boardet til en Done! kategori og registreres på et Burndown Chart, hvor man kan se status mht. løste opgaver i forhold til de i sprintet aktuelle/planlagte opgaver.

Ved afslutningen af hvert Sprint skal der ved et Sprint Review møde normalt demonstreres en leverance i form af en eksekverbar version af værdi for kunden, som repræsenteres af en Product Owner.

Afslutningsvis afholdes et Retrospektivt møde, hvor teamet ser tilbage og forsøger at lære af det netop afsluttede Sprint - f.eks. hvad der fungerede godt, hvad der ikke gjorde og hvilke forandringer, man med fordel kan introducere i det næste Sprint (Sutherland & Schwaber, 2007).

Udover ovenstående indgår der i metoden en række regler, som understøtter processen, men som ikke vil blive gennemgået, da de ikke er relevante for nærværende studie.

Fig. 2. Scrum processens bestanddele (agileforall.com).

of 69

I et Scrum team er der tre roller:

1. Product Owner - er ansvarlig for indhold og prioritering af Product Backlogen, og derved værdien af Scrum-teamets arbejde

2. Scrum Master - er ansvarlig for udvikling af teamet samt at processen er forstået og følges

3. Teamet - en gruppe på 5 - 9 udviklere som udfører arbejdet og former produktet

De elementer, der bliver planlagt, som timeboxes omfatter:

• Sprintforløbet - en iteration af maksimum en måneds varighed som resulterer i en funktionel udvidelse af et frigivelsesklart produkt

• Release Planning - et møde, hvor man omformer vision til et produkt ved at planlægge og etablere nogle mål

• Sprint Planning - et op til 8 timer langt "hvad?" og "hvordan?" møde, hvor en iteration planlægges

• Sprint Review - et op til 4 timer langt møde, hvor det opnåede arbejdsresultat præsenteres, drøftes og vurderes

• Sprint Retrospective - et op til 3 timer langt effektiviserende møde, hvor Scrum Master tilskynder teamet til at revidere udviklingsprocessen

• Daily Scrum - et dagligt møde på op til et kvarter, som forbedrer kommunikationen og projektkendskabet

I Scrum anvendes fire primære artefakter:

1. Product Backlog - en prioriteret liste over alt, hvad der kan være behov for i produktet (features, funktioner osv.)

2. Release Burndown Chart - angiver i tid summen af den forventede arbejdsindsats for den resterende Product Backlog for en releaseplan

3. Sprint Backlog - en liste over opgaver, der skal gennemføres i et sprint for at realisere dele af Product Backlogen

4. Sprint Burndown Chart - angiver i tid summen af de resterende opgaver i et Sprint

Ovenstående er iht. Myllerups oversættelse af "The Scrum Guide" af Ken Schwaber and Jeff Sutherland (Myllerup, 2010).

Scrum metoden stiller dog ingen specifikke krav til artefakternes indhold eller udseende.

Et ofte benyttet redskab, som dog ikke er et element i Scrum metoden, er et Scrum

Board (Fig. 3) - en oversigt, der bruges til at vise status over de opgaver, som indgår i det indeværende sprint. Normalt håndteres Sprint backloggen på Scrum Boardet ved, at den opsplittes i små sedler, som flyttes og skifter status f.eks. i forbindelse med Daily Scrum mødet.

of 69

Fig. 3. Illustration af et typisk Scrum board (Kniberg, 2006).

1.4 Kanban

I dette studie vil Kanban, som alternativ agile softwareudviklingsmodel, blive gennemgået, fordi Kanban er speciel, idet den på flere punkter minder om Scrum. Kanban kan bruges selvstændigt eller sammen med Scrum, og kan derfor være et alternativ til Scrum (Boeg, 2011, s.15).

Kanban, som på japansk betyder Visual Card, er baseret på et visuelt overblik, hvor man benytter en tavle (Fig. 4) på samme måde som i mange Scrumprojekter. Det er en industiel teknik, der går ud på at trække arbejde gennem hele dets livscyklus, så effektivt og ubesværet som muligt, ved at have fokus på flow og kontekst. Metoden er baseret på Just-In-Time og Lean produktionssytemet, hvor det er målet kun at producere det absolut nødvendige på det rigtige tidspunkt – dvs. umiddelbart før brug.

of 69

Fig. 4. Kanban board (Ketil Jensen’s blog).

Metoden er ligesom Scrum også opstået i Japan og repræsenterer en mere direkte implementation af Lean principper end traditionelle agile metoder. Både Scrum og Kanban er letvægtsudviklingsmetoder, som mest benyttes i små eller mellemstore udviklingsorganisationer.

I modsætning til Scrum er Kanban mindre formel og omfatter ikke krav til:

• udviklingsiterationer som sprints

• definerede roller som Scrum Master og Product Owner

• faste møder, såsom Daily Scrum, Sprintmøde, retrospektiv analyse eller demo af leveringer.

• krav mht. artefakter, som f.eks. Release Backlog.

Kanban fokusere i stedet på visualisering af arbejdsgangen, begrænsning af igangværende arbejde og måling af lead time1. Målet er at begrænse Work in

progres, dvs. antallet af igangværende opgaver, så udviklingsteamet har ro til at fokusere på disse, hvilket skaber et konstant workflow og er med til at reducere lead times. Af samme årsag kan Kanban kombineres med Scrum og supplere de vigtigste principper herfra. Den mindre formelle tilgang til agil softwareudvikling har bl.a. medført, at Kanban er blevet en populær udvidelse til Scrum og XP (Boeg, 2011, s.11).

1 Gennemløbstiden for en opgave fra den anmodes/beskrives til den leveres.

of 69

2 Problemformulering Fokus for dette projekt er analyse og fortolkning af brugen af Scrum som udviklingsmetode. Derudover er målet også at søge en forklaring på, hvorfor Scrummetoden ofte bruges forskelligt samt at skabe et værktøj som kan understøtte atypisk Scrumbrug.

Projektets problemformulering er defineret som følgende:

Med udgangspunkt i interviews og eksisterende viden om brug af Scrum vil dette studie:

a) Analysere og diskutere forskellig brug af Scrummetoden med hensyn til metodens ceremonier og værktøjer.

b) Diskutere anvendte Scrumværktøjer/systemer med hensyn til hvordan de understøtter de analyserede Scrumløsninger.

c) Anbefale softwarearkitektoniske principper, som kan implementeres i et digitaliseret værktøj til generisk understøttelse af Scrumprocessen.

d) Lave en mockup prototype af et digitaliseret Scrumværktøj, som anvender de i pkt. c anbefalede principper.

2.1 Afgrænsninger

Samarbejde og roller er vigtige elementer i Scrum, idet metoden fokuserer meget på teamwork, som ofte foregår i selvstyrende grupper. Det er dog et af de mere velbelyste områder indenfor Scrum. Litteraturen om emnet er imidlertid så stor, at Scrum teamwork er et studie i sig selv og er derfor blevet fravalgt i dette studie. Det samme gælder for kommunikation og de dertil knyttede kommunikationsværktøjer, som telefon, e-mail, Skype, videomødeudstyr osv.

Problemstillinger i forbindelse med Scrum-of-Scrum, hvor Scrum benyttes i flere afdelinger eller teams samtidig, som arbejder sammen på et fælles projekt, vil heller ikke blive belyst.

På grund af det omfattende teoretiske grundlag inden for projektledelse og softwareudvikling, behandles flere teoretiske områder kun overfladisk eksempelvis brugervenlighed og andre agile udviklingsmodeller.

Til punkt d ville det have været interessant at lave en funktionel prototype eller et delvist implementeret Scrumsystem, som kunne afprøves på et par projekter. Men den løsning var desværre ikke realiserbar indenfor den berammede tid.

of 69

3 Relateret arbejde Scrum er den mest benyttede udviklingsmetode inden for agil softwareudvikling og derfor findes der naturligvis også en del eksisterende produkter samt enkelte projekter, hvor man har udviklet forskellige digitaliserede løsninger til understøttelse af Scrum.

Der er begrænset litteratur, som beskæftiger sig med digitaliserede værktøjer. De fleste forskningsprojekter er typisk etnografiske studier, som omhandler implementering af Scrum i en organisation. I den forbindelse kommer man sjældent ind på de værktøjer, der benyttes. Men ofte er der tale om lavpraktiske værktøjer, som Excel og en tavle med post-it sedler.

I dette kapitel beskrives og diskuteres et par eksisterende projekter, hvor man forsøger at understøtte Scrumprocessen lidt anderledes end i de eksisterende kommercielle produkter. Derudover beskrives udvalgte eksisterende produkter.

3.1 Andre projekter

Herunder følger en beskrivelse af nogle relaterende projekter, som på forskellig vis understøtter Scrumprocessen.

3.1.1 Scrummer

For et par år siden designede fire studerende fra RUC et digitaliseret Scrum Board (Scrummer) til et arkitektfirma, som i den daglige ledelse benyttede sig af en lavpraktisk tavle med sedler, hvorpå aktiviteter (arbejdspakker) fremgik. Arkitektfirmaets langsigtede planlægning blev håndteret i Microsoft Project.

Scrummer er en interaktiv Smart Boardløsning til en konkret organisation og understøtter i varierende omfang fire grundelementer: Daily Scrum, Scrum Board, Planlægningstavle og Arkiv.

Gruppen konkluderede, at Scrum også blev brugt udenfor softwareindustrien, samt ”at der eksisterer en væsentlig afstand imellem den i litteraturen teoretisk

beskrevne Scrum og den praktiske brug af metoden” (Nyboe et al., 2009, s.24).

De erfarede også: ”at der i den praktiske brug af Scrum ofte benyttes flere og

andre artefakter” end de obligatoriske – som f.eks. et Scrum Board (Nyboe et al., 2009, s.23).

Gruppen påpegede en af udfordringerne ved et digitaliseret Scrum Board:

”Mere avancerede teknologi hæver ofte kompleksiteten - en kompleksitet, som et

stående 15 min. Scrum møde ikke efterlader meget plads til” (Nyboe et al., 2009, s.35).

I deres analyse kom de frem til fire overordnede behov: intuitivt, nem

tilgængelighed, commitment til Scrum og bedre historik. Men deres projekt

of 69

afslørede også, at Scrum Boardet kan have andre funktioner mht. personale eller ressourceobservation i forbindelse med f.eks. sygdom (Nyboe et al., 2009, s.38).

Med hensyn til en interaktiv tavle konkluderede gruppen, at brugen var succesfuld: ”men ser samtidigt et stort fremtidigt potentiale for videreudvikling indenfor dette

område” (Nyboe et al., 2009, s.72).

Derudover var det lykkedes for dem at fremstille en applikation, der indeholdt egenskaber, som arkitektfirmaets lavpraktiske model ikke omfattede. De formåede derved at skabe en merværdi med deres digitaliserede løsning.

Gruppen stiller også spørgsmål ved:

”om man overhovedet bør ændre Scrum og under hvilke forudsætninger det kan

gøres?” (Nyboe et al., 2009, s.39).

Dette spørgsmål diskuteres bl.a. ud fra Schwabers bog: ”The enterprise and scrum” fra 2007, hvor gruppen peger på kulturelle forskelle mellem USA og Skandinavien – f.eks. at metoden tilpasses i forhold til rollerne, hvor ”den mindre

hierarkiske og autoritære skandinaviske struktur” (Nyboe et al., 2009, s.20) påvirker diskursen bland teammedlemmerne og øvrige interessenter. Lignende erfaringer har man fra Finland, hvor man også har observeret mentale forskelle mellem amerikanere og skandinaver (Marchenko & Abrahamsson).

Nyboe et al. får dog ikke rigtig besvaret spørgsmålet, men tilkendegiver dog:

”Ovenstående eksempel viser, mener vi, meget fint viser hvordan positive

resultater kan opnås udelukkende ved implementering af nogle Scrum dele” (Nyboe et al., 2009, s.40).

Hvilket tyder på, at de trods alt mener, at de ændringer, som arkitektfirmaet har foretaget, er acceptable og giver værdi i deres kontekst.

3.1.2 Det interaktive Scrum Board

På Alexandra Instituttet i Århus arbejder man i øjeblikket med et projekt, som omfatter et interaktivt Scrum Board. Her er omdrejningspunktet det lavpraktiske Scrum Board, hvor man prøver at forene det bedste fra to verdener, ved at lade udviklerne beholder deres gule Post-it sedler, men hvor ændringer på boardet registreres i et bagvedliggende computersystem (Fig. 5). Dette gøres ved brug af QR tags, webkamera og projektor.

of 69

Fig. 5. Det interaktive Scrum Board (http://www.youtube.com).

Baggrunden for ovennævnte løsning er erfaringer fra de daglige Scrum møder, som generelt fungerer bedst, når medarbejderne benytter Post-it sedler og en simpel tavle, fordi det giver god dynamik i mødet og holder fokus på det arbejde, som teamet i fælleskab skal løse.

Man forsøger at løse den udfordring, at mange udviklere oplever de computerbaserede Scrumværktøjer som en ekstra dokumentationsbyrde, der ikke tilfører processen merværdi. Men samtidig er der fra projektledelsens side et behov for opfølgning og planlægning. De fleste eksisterende værktøjer tilbyder en masse features, der understøtter projektledelse, men for den enkelte udvikler opleves det som en administrativ byrde.

I forbindelse med at opgaverne er flyttet over på en skærm, er en af de observationer, man har gjort at folk ender med at tale til skærmen eller projektlederen i stedet for til hinanden.

En anden interessant observation i forbindelse med implementering af Scrum er, at det ikke passer til organisationens arbejdsgange og at man derfor er nødt til at justere metoden. Her er holdningen, at det er forkert at se disse Scrum-buts, som et but, da det jo netop er afgørende, at det passer til organisationens kultur, omstændighederne og de kunder, organisationen har.

Ovenstående er baseret på oplysninger fra projektets hjemmeside samt korrespondansen med Alexandra Instituttet (Alexandra).

Det interaktive Scrum Board er meget innovativ, men umiddelbart virker QR tags store og forstyrrende, da det er vanskeligt at se, hvilke opgaver de enkelte tags repræsenterer. Derudover er man nødt til at printe dem ud, hvilket bevirker, at man ikke kan oprette dem direkte ved Scrum Boardet.

of 69

3.1.3 The Cooperative Task Board

Rubart og Freykamp har lavet en prototype af et digitaliseret Scrum Board (Fig. 6), hvor de henvender sig til distribuerede teams og fokuserer på enkelthed for at kunne understøtte principperne i det agile manifesto (se afsnit 1.2):

”A distributed team needs electronic tool support for daily scrum meetings. Such

tool support should focus on simplicity to keep with the agile manifesto” (Rubart & Freykamp, 2009 s. 2).

Fig. 6. Cooperative Task Board View (Rubart & Freykamp, 2009).

De argumenter også for et digitaliseret Scrumsystem, som et nyttigt værktøj i forbindelse med retrospektiv analyse, fordi et digitalt system kan gemme oplysninger om ændringer foretaget i løbet af et Sprint:

”A common problem with scrum sprints is that at their end not all tasks are

completely done. An electronic tool, which supports change management and

special reporting, can help to identify the reasons for this problem in a scrum

retrospective” (Rubart & Freykamp, 2009 s. 2).

I lavpraktiske løsninger vil det i højere grad være Scrum Masterens opgave, at noterer ændringer f.eks. i forbindelse med Daily Scrum, hvilket kan få betydning for Scrum Masternes nærvær, når han under mødet skal tage notater. Resultatet kan være, at Scrum Masteren ikke får noteret baggrunden for en eventuel ændring, hvilket kan få betydning ved den efterfølgende retrospetive analyse.

3.1.4 Diskussion af projekterne

Fælles for ovenstående løsninger er, at man forsøger at tænke lidt anderledes og få et digitaliseret værktøj til at indgå i Scrumprocessen på en intuitiv og naturlig

of 69

måde. Formålet er at understøtte Scrumprocessen på lige fod med de lavpraktiske løsninger, men samtidig opnå gevinsten ved datagenbrug og historik, som kan opdatere Burndown Charts automatisk, samt bruges i forbindelse med analyser og rapportering.

En af fordelene ved digitaliserede Scrum Boards er også, at det kan ses og vedligeholdes af deltagerne, som arbejder i distribuerede teams eller bare arbejder hjemmefra en dag.

Grunden til, at der stadig findes mange lavpraktiske løsninger, skal formodentlig ses som et udtryk for, at der ikke findes digitaliserede værktøjer, som understøtter alles behov på en tilfredstillende måde. For der findes allerede en del eksisterende avancerede systemer, som i bred udstrækning understøtter Scrumprocessen, hvilket vil fremgå af næste afsnit.

3.2 Eksisterende værktøjer

I dette afsnit analyseres nogle af de kendte kommercielle Scrumværktøjer, som er udvalgt på bagrund af referencer i artikler og fra en OpenSpace debat, som beskrives i afsnit 5.1.5.

Analysen er foretaget på baggrund af virksomhedernes præsentationsmateriale samt egne, og i enkelte tilfælde, informanternes indtryk (fra interviews i afsnit 5.1).

Det ville naturligvis give et mere nuanceret billede af disse værktøjer, hvis det havde været muligt at installere produkterne og afprøve dem på et aktuelt udviklingsprojekt. Ligeledes ville det også være interessant at analysere i hvilket omfang, systemerne lever op til forskellige kvalitetskrav samt arkitektoniske og ikke-arkitektoniske aspekter inden for Modifiability og Useability. Men det ville være et omfattende analysearbejde og ikke realiserbar indenfor den berammede tid. Derfor er den følgende karakteristik overvejende i relation til de ikke-arkitektoniske aspekter for Modifiability og Useability.

3.2.1 SpiraPlan

Inflectra tilbyder en række værktøjer til planlægning, test og samarbejde. SpiraPlan er deres værktøj til agil softwareudvikling og består af en web-løsning, som bl.a. understøtter Scrum, Kanban og Extreme Programming (XP) med værktøjer til: Requirements Management, Release Planning, Iteration Planning, Task Tracking, Bug Tracking og Source Code Integration.

Inflectra mener, at tilpasning og konfiguration er afgørende for at sikre, at et system integrerer problemfrit med forretningsprocesser. SpiraPlan kan derfor konfigureres og tilpasses med brugerdefinerede egenskaber. Derudover hævder Inflectra, at de med SpiraPlan er blandt de førende på markedet sammen med AxoSoft og JIRA-Greenhopper.

Et umiddelbart indtryk er dog, at produktet indeholder mange skærmbilleder med en hel del felter på og dropdownlister, som kræver meget brug af mus.

of 69

Fig. 7. Backlog planning view (fra www.inflectra.com).

Et af skærmbillederne er et virtuelt Scrum Board (Fig. 8), der virker anderledes og lidt uoverskuelig, sammenlignet lavpraktiske Scrum Board løsninger (Fig. 3).

Fig. 8. Scrum Board view (fra www.inflectra.com).

of 69

SpiraPlan tilbyder dog et godt oversigtsbillede (Fig. 9), hvor man kan følge med i hele projektet, hvilket må anses for at være et område, hvor lavpraktiske løsninger kommer til kort, da det vil kræve daglige registreringer at opnå samme overblik.

Fig. 9. Project overview (fra www.inflectra.com).

3.2.2 JIRA-Greenhopper

GreenHopper tilbyder modificerbare og fleksible arbejdsgange i forbindelse med agil projektledelse. Værktøjet er baseret på JIRA og understøtter Scrum, XP samt Kanban. Atlassian hævder, at GreenHopper er perfekt til at visualisere og forbedre eksisterende processer.

Ud fra præsentationsvideoerne virker det letforståeligt og de generiske Scrum og Kanban Boards giver et godt overblik (Fig. 11). Det lader også til at næsten alle bevægelser skal foregå ved brug af mus, da der er meget drag-n-drop i skærmbillederne. Men det er uklart hvor godt disse funktioner understøttes på en trykfølsom skærm eller Smartboard.

of 69

Fig. 10. JIRA Task board (http://www.atlassian.com).

Fig. 11. JIRA Kanban board (http://www.atlassian.com).

3.2.3 Axosoft

Axosoft tilbyder en webløsning baseret på HTML5, som dækker Scrum, Helpdesk og Wiki. OnTime Scrum, som er deres Scrummodul, understøtter IDE og SCM integration til Eclipse og Visual Studio. Det er muligt at tilpasse processer, felter og tekster. Derudover kan systemet afvikles på Smart phones og Tablet.

of 69

OnTime Scrum virker som et avanceret system med mange muligheder. Skærmbillederne er strukturerede og overskuelige, men indeholder meget data (Fig. 12, Fig. 13). Nedenstående er et eksempel på en Backlog, men skærmbilledet indeholder også en del andre oplysninger. Det ser dog ud til, at nogle af disse kan gemmes væk – måske en konfigurationsmulighed (Fig. 12).

Fig. 12. OnTime Project view (http://www.axosoft.com).

Deres bud på et Scrum Board kan struktureres efter ønske mht. kolonner og filtrering. Derudover kan administrative processer konfigureres i workflows, så man eksempelvis er tvunget til at angive forbrugt tid i et pop-op vindue, når man flytter en opgave.

Fig. 13. OnTime Visual Planning Board (http://www.axosoft.com).

of 69

3.2.4 VersionOne

VersionOne er et samlet produkt, som kan tilpasses til at understøtte unikke behov i forbindelse med Scrum, Extreme Programming (XP), Kanban, DSDM og AgileUP.

Uanset, om der er tale om et lille nystartet team, multi-teams eller flere programmer, hævder VersionOne selv, at have de bedste værktøjer, som benyttes af mere end 30.000 teams i 170 lande.

Umiddelbart virker VersionOne lidt “tungt” – et administrativt system, som ikke har tænkt teamdeltagerne, som de primære brugere, men snarere Product Owners. Der er mange menuer og felter på skærmbillederne, som virker forvirrende og man skal klikke meget rundt for at udføre selv de mest almindelige handlinger, som f.eks. at oprette en opgave (Fig. 14).

VersionOne er dog et af de produkter, som nævnes i andre sammenhænge (Kniberg, 2006; Uy & Rosendahl, 2008; Rayhan & Haque, 2008).

Kniberg beskriver ikke sine erfaringer med VersionOne, men Uy & Rosendahl skiver om deres erfaringer i forbindelse med implementeringen hos Kelley Blue Book, hvor VersionOne erstattede en lavpraktisk Excel og SharePoint løsning. De beskiver ikke, i hvilket omfang VersionOne lever op til forventningerne, men i stedet at systemet er med til at skabe en ensartet håndtering af Scrumprocessen på tværs af 15 teams (Uy & Rosendahl, 2008).

Rayhan & Haque kommer til den konklusion, at Excel og e-mails ikke er særlige brugbare værktøjer i forbindelse med et distribueret Scrum team og skriver i den forbindelse lidt om deres brug af VesionOne og Basecamp. De skriver bl.a. at VesionOne ikke understøtter samarbejde ret godt og derfor vælger de et andet intuitivt system (Basecamp) til kommunikationsdelen. Til slut ender de dog med at udvikle deres helt eget værktøj (Scrumpad), fordi de undervejs vælger at bygge et timetracking modul, som kan integreres med Basecamp (Rayhan & Haque, 2008).

Ovenstående skal måske ses som et tegn på, at systemet ikke helt levede op til deres behov.

Fig. 14. Scrum Board (http://www.versionone.com).

of 69

3.2.5 Scrum-it

Scrum-it er et digitalt Scrum Board udviklet af BSgroup Technology Innovation AG, Schweiz (http://www.ti8m.ch/scrumit) og er i modsætning til de ovenstående kommercielle systemer en open source web-løsning.

Værktøjet er baseret på JSP, Java og JavaScript, og bruger derudover en Tomcat web-server til afviklingen og en MySQL database server til databasen.

Scrum-it understøtter Scrumprocessen med håndtering af elementer som projekter, teamdeltagere, sprints og user stories. Her er tænkt innovativt fra starten, idet man kan løse flere af opgaverne vha. en trykfølsom skærm. Derudover kan man forstørre opgaverne på boardet og flytte rundt på flere opgaver samtidig. Scrum Boardet og de øvrige skærmbilleder er holdt enkle og overskuelige, hvilket egner sig godt til præsentation på en storskærm foran teamet (Fig. 15, Fig. 16).

Systemet understøtter dog ikke identifikation af, hvem der flytter en opgave, da én udvikler på forhånd er tilknyttet en opgave og det derfor kun er den registrerede udvikler, der håndterer opgaven.

Fig. 15. Scrum Board (http://sourceforge.net/projects/scrum-it/).

of 69

Fig. 16. Sprint setup (http://sourceforge.net/projects/scrum-it/).

3.2.6 Sammenfatning

Umiddelbart minder de enkelte standardsystemer meget om hinanden og med undtagelse af Scrum-it, bærer de alle præg af at være mest velegnede til tastatur og mus.

En af standardsystemernes forcer er, at de er med til at optimere Scrumprocessen ved at sætte retningslinjer for, hvorledes processen skal håndteres. Uy & Rosendahl beskriver bl.a., at de 15 teams før introduktion af VersionOne benyttede forskellige artefakter og strukturer, hvilket sandsynligvis er affødt af forskellige Scrum Masters eller Backlog Owners egne arbejdsmetoder.

I modsætning hertil skal ses de individuelle lavpraktiske løsninger, som giver større frihed mht. Modifiability, idet de lettere kan tilpasses og understøtte lokale behov. I disse tilfælde er det i højere grad processen og konteksten, som dikterer værktøjerne end omvendt.

De lavpraktiske løsninger er måske også et tegn på, at selv omfattende standardsystemer ikke opfylder alle krav mht. Useability og at de i nogle tilfælde kommer til kort over for individuelle behov. Hvis Scrumprocessen er så standardiseret, som den beskrives i The Scrum guide (Sutherland & Schwaber, 2011) burde standardsystemerne jo i princippet kunne opfylde alle behov.

of 69

4 Metode For at afklare hvorfor og i hvilket omfang Scrum metoden tilpasses lokale forhold (empiri) afholdes 4 interviews med repræsentanter fra softwarevirksomheder, som benytter Scrum i forbindelse med deres projekter. Derudover gennemgås og analyseres eksisterende viden og forskning indenfor området vha. videnskabelige artikler og fora på Internettet.

Indsamling og udvælgelse af eksisterende forskning, som hovedsagligt består af videnskabelige artikler, er inspireret af Hossain et al’s. beskrivelse af Kitchenham & Charters guidelines for conducting Systematic Literature Review (Hossain et al., 2009).

Søgning af materiale er foretaget på følgende sites:

• IEEEXplore (http://ieeexplore.ieee.org)

• ACM Digital library (http://www.acm.org)

• Google Scholar (http://scholar.google.dk)

• Wiley InterSciene (http://onlinelibrary.wiley.com)

• SpringerLink (http://www.springerlink.com)

Der er overvejende søgt litteratur skrevet på engelsk og udvælgelsen er i modsætning til Hossain et al. foretaget af en enkelt person.

4.1 Interviews

Der findes forskellige metoder, som kan bruges til at få et bedre indblik i andres brug af Scrum. Man kan f.eks. udføre eksperimenter eller observere, hvordan en organisation eller et team bruger Scrum. Valget blev i dette tilfælde at interviewe fire udviklere, som har erfaringer med Scrum fra forskellige virksomheder, idet de to andre metoder ikke umiddelbart var realiserbare.

For ikke udelukkende at forholde mig til eksisterende forskning, men for at få et mere detaljeret kendskab til problemområdet mht. til forskellig brug af Scrum, valgte jeg at gennemføre fire kvalitative forskningsinterviews, også kaldet dybde-interviews. De tre første interviews var med udviklere fra forskellige softwarevirksomheder og det sidste var med It-chefen fra et rederi med egen It-afdeling, hvor jeg selv arbejder. Alle de repræsenterede virksomheder benytter Scrum, men på forskellig vis.

Det er målet med kvalitative forskningsinterviews, at få et bredt og nuanceret billede af interviewets tema: brug af Scrum (Kvale, 2006).

Hovedformålet med mine interviews var at få indblik i forskellige virksomheders eksisterende Scrumløsninger, samt hvilke tanker, forudsætninger og udfordringer, der ligger til grund for deres løsninger. For eksempel hvilke elementer i Scrum

of 69

frameworket, man eventuelt har tilpasset, hvorfor, og hvordan man understøtter disse og i hvilket omfang, man er tilfreds med den nuværende løsning.

Til undersøgelsen blev der brugt Semi-strukturede interviews, som er en velegnet og anerkendt metode til indsamling af empirisk information (Kvale, 2006).

Derudover er metoden velegnet til interview af flere personer om samme emne (Kvale, 2006), som her, hvor 4 personer blev interviewet om deres erfaringer med Scrum.

Et åbnet interview giver mulighed for, at intervieweren selv deltager aktivt i interviewet. En række prædefinerede spørgsmål nedskrevet i en interviewguide (appendiks 9.1) blev derfor udleveret et par dage før interviewene for at holde fokus og sikre et sammenligneligt grundlag til den efterfølgende diskussion af svarene. Denne fremgangsmåde sikrede, at informanterne fik mulighed for at forberede sig og indhente oplysninger, hvis de manglede viden om et område. Interviewguiden var dog stadig så åben, at der kunne spørges dybere ind til informanternes svar, såfremt dette blev skønnet særligt relevant.

Udgangspunktet for spørgsmålene var Karl Tomms spørgsmålstyper, som er opdelt i fire kategorier: Lineære, Cirkulære, Refleksive og Strategiske spørgsmål (Tomm, 1988). I dette tilfælde var der naturligvis ikke tale om terapi som Tomm forsker i, men de ovennævnte spørgsmålstyper var velegnede til at fastlægge den rette ordlyd i spørgsmålene med det formål at opnå sammenlignelige svar.

I stedet for at renskrive alle interviews, som er meget tidskrævende og derfor lå udenfor studiets rammer, blev de vigtigeste udsagn og pointer citeret eller fremhævet i teksten, og er vedlagt rapporten som vedhæftede filer. I den forbindelse var jeg meget opmærksom på ikke at "plukke" i interviewene og sammensætte udsagn på en sådan måde, at de blev citeret ud af kontekst og derved kunne komme til at fremstå ukorrekt i forhold til den oprindelige mening.

De fire interviews blev herefter analyseret og diskuteret under inddragelse af eksisterende forskning.

Andre brugbare metoder, som blev fravalgt var:

• En eksperimentel tilgang – f.eks. ved at foretage nogle forsøg i forbindelse med et nyt projekt og efterfølgende evaluere resultatet. Det ville sikkert give en god forståelse af anvendeligheden, men også vanskeligt at opnå brugbare erfaringer inden for den berammede tid.

• Observation som "fluen på væggen" f.eks. i forbindelse med afholdelse af Sprint eller Daily Scrummøder. Det har desværre ikke været muligt at få en aftale på plads.

4.2 Geeknight event

For at få en bredere emperi om brug af Scrum deltog jeg i et Geeknight event, som omhandlede ”Distributed Scrum and Agile”. Jeg håbede, at jeg derigennem ville komme i kontakt med repræsentanter fra andre softwarevirksomheder, som kunne bidrage med mere viden om andre virksomheders brug af Scrum.

of 69

Ligedes ville jeg undersøge, hvilke værktøjer, de brugte og om, der i forbindelse med distribueret Scrum, var forskel på værktøjerne i forhold til Scrum når hele teamet er samlet lokalt.

4.3 Softwarearkitektur

Arkitekturen er grundlaget for at opnå kvalitet i et softwaresystem. Bass et al. anbefaler nogle principper i form af Quality Attributes (QA), som kan hjælpe sofwarearkitekten med til at skabe kvalitet i arkitekturen, så den både lever op til de udvalgte kvalitetsattributter og ikke-funktionelle kvalitetskrav (Bass et al., 2006).

Et andet vigtigt aspekt er funktionalitet, som er et softwaresystems evne til at udfører de opgaver, det er tiltænkt at skulle løse (Bass et al., 2006, s.71). Ikke-funktionelle kvalitetskrav er i den forbindelse krav, som ikke direkte har forbindelse til systemets funktionalitet, men som er mindst lige så vigtige, fordi de bl.a. sikrer, at funktionaliteten kan afvikles på en tilfredsstillende måde. Det kan f.eks. være systemets muligheder, tjenester og adfærd (Bass et al., 2006, s.71).

Grundelementerne i Bass et al’s principper er tactics, som indenfor QA kategorierne Availability, Modifiability, Performance, Security, Testability og Usability fungerer som byggeklodser, og i kombination danner et Architectural Pattern. Tactics er forskellige designvalg, som sikrer opfyldelse af funktionalitet og påvirker kvalitetsattributternes respons, og derved bidrager til den samlede arkitektoniske løsning i en strategi (architectural strategy) (Bass et al., 2006, s.100).

For at sikre kvaliteten i de valgte arkitektoniske patterns kan man yderligere specificere scenarier (Quality Attributes Scenarios), hvor man med udgangspunkt i specifikke krav opstiller målbare scenarier, som systemet skal leve op til (Bass et al., 2006, s.75).

Derudover findes der andre kvalitetskrav, som påvirkes af de arkitektoniske valg. Det kan f.eks. være forretningskrav (Business Qualities), hvor eksempelvis time-to-

market kan stille begrænsende krav mht. udviklingstiden, hvilket kan påvirke arkitektoniske valg i negativ retning. Hvis eksempelvis udviklingen forceres for at nå en deadline, kan det gå ud over systemets performance og kvalitet. Et andet eksempel er Projected lifetime of the system, som kan stille krav til produktets modificerbarhed, hvis man forventer en lang levetid (Bass et al., 2006, s.95).

Men en god arkitektur er ikke alene nok til at sikre kvalitet i systemet - det afhænger også af implementationen af softwareelementerne samt kvalitetsattributternes indbydes påvirkning (Bass et al., 2006, s.73). For eksempel kan krav om høj modificerbarhed og høj performance være modstridende, fordi et højt abstraktionsniveau med flere lag kan påvirke afviklingen og få indflydelse på systemets performance. Derfor er arkitekten ofte nødt til at indgå kompromis mht. kravene (Tradeoffs).

of 69

4.3.1 Arkitektur for et Scrumsystem

Alle softwaresystemer har en arkitektur og det er også tilfældet med et system, som kan understøtte Scrumprocessen. Overordnet set er kerneelementerne i Scrum en mængde estimerede opgaver af forskellig type (User Stories og Tasks), som inddeles i delmængder (Sprint) og skifter status efterhånden, som der bruges tid på dem (udvikling) og de færdiggøres (Done).

”A typical Scrum maintains a Scrum board showing columns of user stories,

development tasks relating to each story, and the state of each development task

and tests associated with each story. When a task is started a card is moved across

the board into an open column. When code is complete it is move to the verification

column and when fully tested is moved to a done column” (Sutherland & Schwaber, 2007, s.100).

I systemet, som skal kunne understøtte forskellige variationer af Scrumprocessen og måske på et senere tidspunkt kunne udbygges til også at understøtte Kanban, har jeg mht. arkitekturen valgt at fokusere på Modifiability og Useability, da dette er de primære kvalitets attributter for systemet. De øvrige kvalitetsattributter Availability, Performance, Security og Testability er naturligvis også vigtige, men ikke i så høj grad i denne kontekst, hvor der er få brugere (team på 5-9 deltagere), som arbejder sporadisk i et forholdsvis simpelt system med begrænset ansvar og tilgang. Vægten bør derfor ligge på konfigurations- og tilpasningsmuligheder, samt brugervenlighed i form af intuitiv understøttelse af Scrumprocessen.

Useability og Modifiability består både af arkitektoniske og ikke-arkitektoniske aspekter. For Useability gælder det, at funktioner og kommandoer, som for eksempel Copy og Undo, der relaterer sig til systemets funktionalitet, er arkitektoniske aspekter, fordi deres virkemåde afhænger af forskellige elementers indbyrdes afhængigheder og placering. Brugergrænsefladens udseende er derimod et ikke-arkitektonisk aspekt, fordi der er tale om designvalg, som normalt ikke har nogen betydning for systemets arkitektur. Men disse valg har naturligvis stor betydning for brugernes oplevelse af systemet og er derfor også vigtige (Bass et al., 2006 , s.73).

Der er samspil mellem arkitektoniske og ikke-arkitektoniske aspekter i de tilfælde, hvor grænsefladen er afhængig af den funktionalitet, som systemet stiller til rådighed. For eksempel skal API’et for det valgte programmeringssprog understøtte konfiguration af eksempelvis sprogvalg, navngivning af felter osv. for at disse arkitektoniske valg er brugbare.

Modifiability handler i høj grad om de økonomiske omkostninger, der er forbundet med at foretage ændringer af et system. Her er de arkitektoniske aspekter eksempelvis den struktur, der er valgt i forbindelse med adskillelse af funktionaliteten, hvor et system anses for at være modificerbart, hvis en ændring kun involverer et minimum af elementer. Dette kan f.eks. opnås ved lav-kobling mellem elementerne (klasser), hvor man begrænser afhængigheder eller ved høj-samhørighed, hvor man samler ansvaret. Begge designvalg er med til at begrænse omfanget af ændringer, i forbindelse med omstrukturering af koden. Men selve kodestilen, som er et ikke-arkitektonisk aspekt, har også stor betydning for modificerbarheden, hvis eksempelvis koden er vanskelig at forstå og derved problematisk at ændre (Bass et al., 2006 , s.73).

of 69

Modifiability hænger også tæt sammen med en anden kategori Portability, som iht. Bass et al. ikke er en QA, men som også omhandler modificerbarhed i forhold til, at et system kan installeres og afvikles på forskellige platforme. I forbindelse med et Scrumsystem er portability interessant, idet man må formode at de forskellige organisationer, som benytter Scrum, sikkert også benytter forskellige platforme som Windows, Linux osv. Derfor er der også behov for at se på et andet forretningskrav Targeted marked, som netop omhandler hvor, og i hvilken udstrækning, man kan afsætte systemet (Bass et al., 2006 , s.95). Set ud fra et forretningsmæssigt synspunkt kunne målet derfor være, at basere systemet på nogle platformsuafhængige løsninger, som f.eks. Web og JAVA.

Ovenstående argumenter redegør således for, at der er mange aspekter og afvejninger, som skal tages i betragtning i forbindelse med valg af arkitekturen.

4.3.2 Tactics

Inden for de valgte kvalitetsattributter Modifiability og Usability findes der en række tactics, som er designvalg, der kan implementeres og derigennem påvirke kvalitetsattributterne. De enkelte tactics er grupperet i forskellige kategorier afhængig af deres virkermåde og Bass et al. har valgt at inddele dem i et hierarki (Fig. 17).

Modifiability tactics kan være med til at sikre, at ændringer i et system bliver så billige som muligt. Et af målene er at undgå, at ændringer breder sig (Prevent ripple effect) til andre moduler, som ikke er direkte forbundet hermed. Dette kan håndteres ved at begrænse kommunikationsmulighederne, uddelegere ansvar (Localize modifications) og kommunikerer via interfaces (Bass et al., 2006, s.106).

Fig. 17. Modifiability tactics (Bass et al., 2006 , s. 111).

of 69

Ovenstående taktikker er generel god skik inden for objektorienteret programmering, hvorimod den sidste gruppe inden for Modifiability Defer binding

time, nærmer sig Usability, fordi man med Runtime registration og Configuration files tilbyder brugerne (eller systemadministratorerne) nogle værktøjer, der kan få systemet til at ændre adfærd, uden at det kræver indgriben fra en udvikler (Bass et al., 2006, s.110). Det kræver naturligvis, at variationerne i adfærden på forhånd er implementeret i systemet og det er netop her modificerbarheden bliver aktuel.

I forbindelse med et Scrumsystem vil det være naturligt at fokusere på disse tactics, da systemet overordnet set skal have samme funktionalitet, men ofte med små ændringer, fordi den skal tilpasses lokale ønsker og forhold. Eksempler på dette kunne være opgavekategorier, statustyper og inddeling af felter/områder til: Not started, In progres og Done osv.

Usability tactics forgrener sig i to kategorier. Den ene er Runtime tactics, som bl.a. omhandler brugerkommandoer som: save, cancel og undo, samt feedback til brugeren om, hvad systemet foretager sig (fremgår af Fig. 18 som Support User

Initiative og Support System Initiative). Her skelner man mellem hvem, der tager ”initiativet” – om det er brugeren, systemet eller en kombination. Brugeren kan for eksempel starte en filoverførsel og systemet svarer med en meddelelse om, at overførslen er iværksat samt løbende status, som fortæller brugeren, hvornår processen forventes udført. Dette er et eksempel på en Maintain a model of the

system tactic, idet systemet fortæller noget om sig selv – hvor lang tid tager det for systemet at udfører handlingen (Bass et al., 2006, s.121).

Fig. 18. Usability tactics (Bass et al., 2006, s.123).

Lignende tactics findes for bruger og opgave, hvor systemet ud fra sin kontekst understøtter brugerens handlinger ud fra forventninger om, hvilke handlinger brugeren ønsker at foretage sig. I disse tilfælde skal systemet svare retvisende og respondere så hurtigt, at brugeren ikke bliver usikker på om kommandoen er i værksat, men heller ikke hurtigere end brugeren kan nå at følge med. I Scrumsystemer gælder dette for eksempel mht. oprettelse af User Stories og Tasks, hvor systemet skal åbne og lukke indtastningsvinduerne og respondere på tastetryk og registreringer. Det er også vigtigt, at systemet virker intuitivt for brugeren, så

of 69

denne ikke er i tvivl om rækkefølgen på kommandoer i forbindelse med oprettelse og editering af diverse objekter.

Den anden gren er Designtime tactics, som er tæt knyttet til Modifiability tactics, idet denne type tactics omhandler separation af brugergrænsefladen og den øvrige del af systemet, hvilket hænger sammen med Semantic coherence fra Modifiability tactics (fremgår af Fig. 18 som Separate User Interface). Dette kan håndteres vha. en lagdelt arkitektur, hvor f.eks. et Model-View-Controler pattern kan bruges til at adskille præsentation (grafik), logik og model. I Scrumsystemet kan denne arkitektur implementeres vha. et observer pattern, som f.eks. i Burndown Chartet viser effekten af de ændringer, som foretages på Scrum Boardet.

of 69

5 Analyse og diskussion I dette afsnit analyseres de afholdte interviews, input fra GeekNight event samt forskellig brug af Scrum i forhold til metodens anbefalinger og øvrig forskning på området.

5.1 Interviews og event

Kvalitative forskningsinterviews er en anerkendt og struktureret metode til indsamling af oplysninger. Det kan være en stor fordel at optage interviewet i stedet for at tage notater, da man dels er mere nærværende under selve interviewet og dels kan genhøre optagelsen. Ved sidstnævnte falder man måske over udtalelser, som man i første omgang overhørte eller ikke tillagde nogen betydning. Derudover mindsker man risikoen for fejlnotater, som beskrevet i afsnit 4.1.

Men selvom man anvender en interviewguide, kan det være vanskeligt at holde fokus på de prædefinerede spørgsmål, fordi interviewet udvikler sig – specielt når man stiller åbne spørgsmål og informanterne kommer til at svare på flere spørgsmål samtidigt. Derudover kan der være spørgsmål, som bliver overset, kun besvares delvist eller måske ikke er lige relevante for alle informanterne. Sidstnævnte kan give ”mudrede” svar, hvor uddybning af svaret efterfølgende kan være nødvendig. I appendiks 9.2 sammenlignes udvalgte emner fra de fire interviews.

Informanterne blev udvalgt på den baggrund, at jeg gennem tidligere samtaler havde fået bekræftet, at de arbejdede med Scrum.

5.1.1 Interview med Birte, Logica

Birte arbejder som udvikler hos Logica Danmark A/S og har flere års erfaring med Scrum (BLH 01:10). I Logica, som er en international virksomhed med 41.000 medarbejdere inden for teknologi- og virksomhedsservice, har man i Århus afdelingen i mere end 3 år brugt Scrum i forbindelse med udviklingsopgaver og support (BLH 00:20).

Iflg. Birte egner metoden sig bedst til nyudvikling (BLH 01:55), men kan dog også bruges til andre projekttyper, hvis man tilretter den (BLH 02:24).

Hos Logica sammensættes og prioriteres Sprint backloggen af Product Owner i fællesskab med teamet. (BLH 26:15) I den forbindelse kigger man bl.a. på kompetencerne i teamet – ”alle skal kunne se sig selv i sprintet” dvs. der skal være opgaver til alle (BLH 05:24). Alle opgaverne i backloggen skal ligeledes være estimerede (fra 2 til 40 timer), hvilket Product owner står for.

of 69

Der estimeres på baggrund af poker estimering2 eller estimat fra den deltager, som

har oprettet opgaven (BLH 13:42) (det er altså ikke kun Produkt Owner, som lægger opgaver i backloggen). Ved store opgaver er første skridt ofte at opdele opgaven i mindre ”bidder” (BLH 14:57), som f.eks. analyse, beskrivelse og samtale med kunden (BLH 15:38).

Selve opgaverne med beskrivelser og dokumentation (BLH 18:40) håndteres vha. JIRA, som også kunderne har adgang til (BLH 20:33).

I løbet af et Sprint hænder det, at opgaver tilføjes, omprioriteres eller udtages, hvis der f.eks. bliver indrapporteret alvorlige fejl eller nye presserende ønsker (BLH 27:55), og eventuelle fejlestimater rettes på deres ”Scrum tavle” (BLH 16:57).

Birte anser Scrumtavlen, som det mest anvendelige artefakt, fordi den afspejler alle opgaverne i backloggen (BLH 08:52) og skaber overblik mht. hvem der laver hvad, hvilket er en fordel, når teamet er fordelt på flere kontorer (BLH 09:19).

Udviklerne kan selv vælge blandt opgaverne:

”hvis man har lyst til at prøve noget nyt, har man mulighed for at tage en anden

[mere spændende] opgave” (BLH 08:52).

Ud fra Birtes beskrivelse om Logica’s brug af Scrum tavlen ser det ud til at tavlen er motivationsfaktor, idet udviklerne har indflydelse på deres eget arbejde.

Hos Logica har man inddelt Scrum tavlen i kategorierne: Ikke påbegyndte opgaver, Impeded (i dvale – eksempelvis hvis man mangler svar fra kunden), Igangværende og Afsluttede opgaver (BLH 10:51). Som i de fleste andre Scrum Board løsninger synliggøres opgaverne vha. små sedler (BLH 30:20) med forskellige farver afhængig af opgavetypen (udvikling, test, møde, indkomne ikke planlagte opgaver osv.) (BLH 30:30).

Sedlerne har forskellige informationer fra backloggen bl.a. et nummer, en beskrivelse, en prioritering samt et tidsestimat. Enkelte kan også have en deadline noteret (BLH 11:54).

Scrumtavlen har også været med til at løse en udfordring med at synliggøre vigtige oplysninger og opgaver, som tidligere lå fordelt i teamdeltagernes e-mails (BLH 09:50).

Et andet vigtigt artefakt, Birte nævner, er Sprint Burndown chartet, hvor man dagligt registrer løste opgaver (BLH 11:08). Opgaver, som kun er delvis løste, bliver ikke registreret (BLH 19:35). Det ser dog ud til, at også Burndown chartet har en motiverende effekt, idet ”der kan gå sport i at nå opgaverne, hvis man er kommet bagefter” (BLH 11:08).

Den største udfordring er i den forbindelse større eller specielle/vigtige supportopgaver, som kræver hjælp af andre end den person, som står for supporten (BLH 31:26). Det er vanskeligt at få disse opgaver synliggjort på Scrum tavlen og man har uden held tidligere forsøgt sig med en swimlane - en kategori af opgaver som ”flød på dagligdagen” og ikke var en del af backloggen (BLH 31:51). Birte erkender vigtigheden af den type opgaver og vil gerne have en bedre understøttelse af disse, men har umiddelbart ikke noget løsningsforslag til problemet.

2 Poker estimering (Planning Poker) er en form for kortspil, hvor de enkelte deltagere uafhængigt med hvert sit kort, estimerer udviklingstiden for en opgave. Ud fra estimaterne diskuteres opgaven i teamet. En stor variation blandt estimaterne kan være et tegn på forskellig opfattelse af opgavens omfang.

of 69

Det skal bemærkes, at både Scrumtavlen og Burndown Charts håndteres vha. lavpraktiske værktøjer og at man ikke arbejder med faste leverancer efter hvert sprint, men i stedet med halvårlige eller kvartårlige releases afhængig af kundernes ønsker (BLH 21:50).

5.1.2 Interview med Thomas, Vertica

Thomas er udvikler hos Vertica A/S, hvor man har benyttet Scrum i en del år.

Vertica er et softwarehus med ca. 40 ansatte fordelt på kontorer i Århus og København. Virksomheden har specialiseret sig indenfor systemintegrationer samt E-handels-, Portal- og mobile løsninger. Her bruger man Scrum til at skabe fokus med hensyn til opgaver og fremdrift overfor kunderne (TBE 00:30), samt internt, overfor udviklerne, til at synliggøre hvilke opgaver der skal arbejdes på (TBE 00:58).

Hos Vertica bruger man Scrum forskelligt afhængig af forretningsområdet og projekttypen (TBE 02:30). Kun i store projekter bruges Scrum i større omfang (TBE 06:40) og det bruges mest aktivt i forbindelse med ”e-handelsløsninger og portaler, hvor man anvender en ”klassisk” Scrum model, med ”Feature backlog”, Scrum møder, Burndown charts osv. (TBE 04:30).

I forbindelse med integrationsprojekter anvendes Scrum mere varieret (TBE 03:46), da der i mange tilfælde ikke er tale om decideret projektarbejde fra Vertica’s side (TBE 05:52). I stedet deltager Vertica ofte i kundens projektgruppe med rådgivende konsulenter frem for egen udvikling (TBE 06:00). I disse tilfælde er det kunderne, som definerer en eventuel Scrum model (TBE 08:30). For integrationsprojekterne er det iflg. Thomas også vanskeligt at lave en fornuftig backlog med veldefinerede opgaver, fordi disse projekter ofte består af ”mange

afhængigheder – ender, der skal mødes” (TBE 06:50). Her kan for løst definerede opgaver give økonomiske problemer, hvis det senere i projektet bliver nødvendigt med radikale ændringer (TBE 11:29).

I enkelte tilfælde bruges backloggen også som grundlag for fastprisaftale, hvilket stiller ekstra krav i forbindelse med ændringer eller tilføjelser, da disse falder uden for aftalen (TBE 12:15). I sådanne tilfælde får backloggen en ”kontraktuel” betydning (TBE 13:23) i form af en kravspecifikation.

God kommunikation er vigtig hos Vertica og man har gode erfaringer med at lade udviklerne deltage i sprintmøderne og have tæt kontakt til kunderne, da man mener, at dette bidrager til en bedre forståelse for kundens behov og ønsker (TBE 12:15). Men det kræver også ærlighed overfor kunderne, i tilfælde hvor kundens ønsker er tvetydige eller ikke harmonerer med den valgte løsning (TBE 18:18).

Vertika bruger ikke fast Sprint time-boxing, men tilpasser fra gang til gang i forhold til mængden af veldefinerede opgaver (TBE 22:02) eller iht. kundens ønsker (TBE 21:53). Man justerer altså Sprintlængden efter, hvor uklare opgaverne er. Jo mere uklare opgaverne er, jo kortere sprint, for ikke at få for mange opgaver i sprintet, da man har erfaringer med, at Sprint backloggen ellers skal ændres efterfølgende.

Internt drager man stadig fordel af den tætte kontakt, som Scrum tilbyder (TBE 43:50). Men Thomas mener, at der ofte bliver brugt for lidt tid på projektledelse i integrationsprojekter, hvilket efterfølgende giver bagslag (TBE 23:43), fordi Scrum

of 69

egner sig mindre godt til integrationsprojekter. En af udfordringerne er relationer til andre partnere, der vanskeliggør planlægning med uklare eller udetaljerede opgaver, som igen medfører et for udefinerede projektforløb (TBE 39:30).

Ved veldefinerede projekter er der meget fokus på burndown og levering, fordi kunden ofte har en deadline (time to market), som skal overholdes (TBE 30:05). Hvorimod kunder, som er mere interesseret i features og funktionalitet, ikke lægger så stor vægt på denne del, fordi der hele tiden ”kommer nye ting til” og backloggen derved ændres (TBE 30:15). I disse projekter er der mere fokus på selve sprintet og specielt den afsluttende demo (TBE 30:40).

Hos Vertica har man adskilt udvikling og drift ved at lave serviceaftaler for support af eksisterende løsninger. Denne funktion varetages af en decideret serviceafdeling (TBE 34:18), hvilket giver ro i forbindelse med nyudvikling, fordi man ikke skal afsætte tid til drift i et sprint og udviklerne ikke bliver forstyrret af driftopgaver (TBE 32:52).

5.1.3 Interview med Henrik, Unifeeder

Henrik er CIO hos Unifeeder A/S, som er et af verdens største feederrederier og har ca. 300 ansatte fordelt på 9 kontorer i Nordeuropa. Unifeeder udvikler selv kun en mindre del af virksomhedens it-systemer, men har mange forskellige typer af projekter, heriblandt dataudveksling med kunder og samarbejdspartnere.

Henrik ser mest Scrum som et effektivt projektstyringsredskab, der tilbyder projektledere (HFI 24:40) nogle praktiske værktøjer (HFI 00:35), hvor man "får meget foræret", bl.a. pga. den tætte opfølgning (HFI 20:18). Specielt de daglige Scrummøder giver stor værdi, fordi produktiviteten synliggøres og udfordringerne kommer til udtryk, uden man bruger for meget tid på det (HFI 20:58).

Hos Unifeeder valgte man Scrum for at få bedre styr på it-projekterne (HFI 01:22), som ofte er tilknyttede forskellige Product Owners og afvikles sideløbende (HFI 08:15).

Tilgangen har været "learning by doing" og modellen har derfor også udviklet sig i løbet af de 1½ år, man har brugt den (HFI 03:45). Man har ikke noget standardsystem til understøttelse af modellen (HFI 05:03), men bruger i stedet Lotus Notes til projektopgaver/backloggen og Excel til sprintplanlægning (HFI 05:20).

For at koordinere de forskellige projekter afholder man lidt utraditionelt et ”pre-planning” møde inden sprint start, hvor hovedopgaver fra de forskellige projekter diskuteres af Produkt Owners og projektlederne (HFI 13:55).

Af artefakter benytter man et Scrum board, men ikke Burndown Charts, da man mener, det ikke er muligt at restestimere opgaverne på dagligt basis (HFI 11:25). I stedet reflekterer man retrospektivt over tidsforbrug og opgavestatus i forbindelse med Sprint afslutningen, hvor man opsummerer tidsregistreringer af de enkelte opgaver (HFI 11:37).

Henrik mener, at Unifeeder’s Scrummodel mangler synlighed udadtil for eksempelvis Produkt Owners og med den nuværende løsning, er det vanskeligt at restestimere opgaverne. Derfor planlægger man at introducere Burndown Charts for herigennem synligøre opgavestatus og fremdrift over for Product Owners og andre interessenter (HFI 17:20). Hertil savner Henrik stærkere værktøjer til

of 69

opgaveestimering og evaluering (HFI 18:06). Han tror dog, at dette mål kunne opnås ved at anvende de eksisterende værktøjer med en større manuel administrativ indsats (HFI 18:55). Den nuværende løsning giver derfor størst udbytte for de deltager, som er "tæt på" projekterne (HFI 25:50).

I modsætning til ovenstående fungerer Unifeeder’s Scrum Board løsning til gengæld bedre, fordi det skaber dialog og dynamik, men man kunne godt tænke sig en bedre teknologisk løsning (HFI 21:37).

Udover planlægning bruger man også Scrummodellen til ressourcestyrring (HFI 13:55), hvor det er projektlederne, som prioriterer og tildeler opgaverne (HFI 14:44). Arbejdsopgaverne på Scrum Boardet er som udgangspunkt ikke prioriterede (Fig. 19). Det er op til udviklerne selv at bestemme rækkefølgen af disse - evt. i samråd med projektlederne (HFI 22:27).

Fig. 19. Eksemple på Unifeeder’s Scrum Board (foto: Jan Bjerg).

5.1.4 Interview med Svend, Alexandra Instituttet

Svend er projektleder på Alexandra Instituttet og har arbejdet med Scrum både i sin nuværende stilling og den forrige hos Mjølner Informatics (SRT 00:05). Hos Mjølner Informatics bruger man en struktureret udviklingsproces til sine softwareprojekter. Metoden er inspireret af IBM’s RUP (Rational Unified Process) og kombineres med Scrum (SRT 00:30).

På Alexander Instituttet arbejder man med software i kombinerede projekter for forskellige virksomheder (SRT 01:09). I disse projekter har man frie rammer og Svend kan derfor udvælge udviklingsmetoden ud fra projekttypen, karakteristika

of 69

og omstændigheder (SRT 01:30). Han kan dog ikke udelukkende bruge Scrum, fordi projekterne ikke kun omfatter softwareudvikling, men også samarbejde og udvikling med eksterne partnere om produkter, hvori softwaren indgår (SRT 02:15).

Projektdeltagerne er ofte tilknyttet andre projekter samtidig (SRT 03:36), og man afholder derfor ikke faste møder, men aftaler disse efter behov (SRT 06:30). Derudover arbejder man ofte med innovativ udvikling, hvor man opdeler projekterne i opgaver eller delprojekter, som ikke nødvendigvis omfatter software udvikling (SRT 06:58). Til disse "proof of concept" projekter (SRT 23:50) mødes man f.eks. en gang hver måned for at koordinere opgaverne (SRT 07:50) og længden af hvert sprint aftales derfor fra gang til gang, afhængig af mængden af delopgaver (SRT 09:24).

Svend er stor tilhænger af agil softwareudvikling, hvor han mener, at man skal bruge ”de bedste værktøjer”. Han ser sig selv som en "reflekterende projektleder" og benytter sig af værktøjer fra både den klassiske og agile projektledelse (SRT 11:22), idet han ud fra et projekts længde, kompleksitet og uklarhed bruger elementer fra både de klassiske og agile projektledelsesteorier (SRT 13:43). I den forbindelse er det typisk ham selv, der vælger udviklingsmodellen (SRT 15:40) og han mener, at den metode, han har valgt at bruge i sit nuværende projekt, kan sammenlignes med Scrum (SRT 10:50). Men da han ikke har et fast team og opgaverne ikke kun omfatter softwareudvikling, er det ikke altid muligt at benytte Scrum 100 % (SRT 36:30). Hvis der var tale om en ren softwareudvikling med et fasttømret team ville Svend nok vælge Scrum - måske justeret, så den passer til forholdene (SRT 38:02).

Han er i det hele taget meget inspireret af Scrum og agil udvikling. Men han påpeger, at i forbindelse med agil udvikling, er det nødvendigt med struktur, da det ellers kan ende med "cowboy kodning" eller anden form for anarkistisk udvikling (SRT 11:48), og nævner, at der er mange, som udvikler agilt, men ikke følger principperne for agil udvikling (SRT 38:30).

På Alexandra Instituttet har man vedtaget nogle faste rammer for projektledelse, som alle er underlagt for at undgå ustruktureret udvikling (SRT 13:10) og Svend ser potentiale i brug af standardværktøjer i hele organisationen til eksempelvis projektplaner (SRT 28:14). Men savner umiddelbart ikke andre værktøjer i sit daglige arbejde.

Sven påpeger også, at eventuelle administrative værktøjer skal være indlejret i udviklingsmiljøet og være en naturlig del af arbejdet, hvis det skal give værdi og ikke administrativt ekstraarbejde (SRT 22:35;SRT 31:00). Men han nævner også, at det for udviklere og projektledere er meget vigtigt at have administrative data til rådighed for at kunne styre et projekt mht. status og indsigt (SRT 33:50). I den forbindelse er det vigtigt, at det er let for udviklerne at registrerer oplysningerne, så de er motiveret for at bruge systemet, hvilket medfører højere datakvalitet (SRT 34:23).

Her nævner Svend et andet projekt på Alexandra Instituttet, hvor man netop arbejder med en virtualiseret løsning af et Scrum Board (SRT 31:20), som blev beskrevet i afsnit 3.1.2.

of 69

Mht. artefakter bruger Svend ikke Burndown Charts, fordi han mener, at man kun kan beregne realistisk velocity3, hvis man arbejder med samme opgavetyper eller systemer (SRT 21:08). Tidsestimering af opgaverne fastsætter han selv, dog nogle gange i samråd med deltagerne (SRT 22:48).

5.1.5 Geeknight om ”Distributed Scrum and Agile”

Onsdag d. 14. marts 2012 afholdte ScrumForum Aarhus et Geeknight event om ”Distributed Scrum and Agile” hos Trifork A/S i Århus.

Det bestod af et fagligt oplæg v. Mads Troels Hansen, og efterfølgende OpenSpace debat om relaterende emner udvalgt af deltagerne.

Et at emnerne var Collaboration Tools, hvor brug af forskellige værktøjer blev debatteret i en gruppe på 11 deltagere. Alle deltagerne repræsenterede forskellige softwareproducenter eller virksomheder med egen udvikling, som brugte Scrum i en distribueret kontekst. Hertil benyttede de alle dedikerede it-systemer, som understøttede processen og artefakter, som f.eks. Backlogs og Burndown Charts.

Grunden til, at alle benyttede it-baserede værktøjer, var et resultat af de behov den mere komplekse kontekst Distribuerede Scrum stiller. På grund af den fysiske adskildelse stilles der større krav til kommunikation og synliggørelse af opgavernes status i Sprintet ved distribuerede teams, end der gør ved tæt samarbejdende Scrum team med Daily Scrum og hyppig interaktion. Distribuerede løsninger kræver derfor, at teamet kan tilgå de samme ressourcer og artefakter i et digitaliseret Scrumsystem.

Ovenstående bliver også bekræftet af eksisterende forskning på området. Hossain et al. foretog i 2009 et større review af studier inden for Global Software

Development (GSD), hvor Scrum bl.a. blev benyttet. De konkluderede, at distribueret softwareudvikling stiller store krav til kommunikation og de understøttende værktøjer. Den samme konklusion kom Rubart og Freykamp også til (omtalt tidligere i afsnit 3.1.3).

Nedenfor er oplistet de systemer, som blev brugt af de distribuerede teams:

• TFS (Microsofts Team Foundation Server)

• Basecamp (http://basecamp.com/)

• JIRA-Greenhopper (http://www.atlassian.com)

• RCC (http://www.slideshare.net/prasad_keral/scrum-orientation-v10)

• Springloops (http://www.springloops.com/v2/)

• Google docs

3 En indikator for hvor produktiv teamets forventes at være i et sprint. Ofte angivet i story points eller tidsenheder, som kan sammenholdes med estimater på opgaver i Backloggen.

of 69

5.2 Udfordringer ved brug af Scrum

I dette afsnit sammenlignes og diskuteres udvalgte emner fra de afholdte interviews samt eksisterende forskning.

5.2.1 Resultat af interviews

De fire interviews afspejler, at Scrum bruges på forskellig vis i disse organisationer og at der i nogle tilfælde er så store udfordringer, at det kan diskuteres, om det overhovedet giver mening at bruge Scrum som udviklingsmodel. Thomas nævner f.eks., at det i forbindelse med integrationsprojekter er vanskeligt at lave en fornuftig backlog med veldefinerede opgaver, fordi disse projekter ofte består af mange afhængigheder (TBE). Set i den kontekst kunne Kanban måske være en bedre løsning, da man stadig opnår fordelene ved at være tæt på opgaverne med et visualiseret overblik, men ikke bliver bremset af de rigide regler i Scrum mht. ændringer af opgaver i et Sprint (Boeg, 2011).

Et emne, som er vanskeligt at håndtere i Scrum, er fejlhåndtering (Kniberg, 2006; Marchenko & Abrahamsson; BLH). Specielt, når der opstår bugs i systemer, som allerede er taget i brug og det udviklende Scrumteam også skal løse fejlen, bliver det problematisk, fordi det er vanskeligt at planlægge med sådanne opgaver, da man ikke ved hvornår de opstår. Bugs bliver af naturlige årsager, ofte prioriteret højt – dvs. at de normalt skal løses i det indeværende Sprint, hvilket får indflydelse på nyudviklingen og de øvrige aktiviteter i Sprintet. Løsningen kan være en særskilt serviceafdeling til at tager sig af disse problemer (TBE). Men denne løsning vil ofte kræve en organisation af en vis størrelse, da det kræver en del ressourcer at afsætte personale alene til fejlhåndtering.

5.2.2 Tilpasning af Scrum

I følge den eksisterende Scrumforskning lader det til, at Scrummetoden eller metodikken i årenes løb, har udviklet sig til et framework (Hossain et al., 2009).

At metoden er blevet til et framework appellere i sagens natur til tilpasninger, men der er delte meninger om, i hvilken udstrækning dette er tilladt. Om Scrum kan ændres? og er der herefter stadig tale om Scrum?

Kniberg citerer Schwaber og skriver:

“In Ken Schwaber’s words, Scrum is not a methodology, it is a framework. What

that means is that Scrum is not really going to tell you exactly what to do” (Kniberg, 2006, s.5).

Men han skiver også selv, at Scrum skal tilpasses individuelt:

“The strength and pain of Scrum is that you are forced to adapt it to your specific

situation” (Kniberg, 2006, s.5).

Myllerup skiver i sin oversættelse af The Scrum Guide at:

of 69

”Scrum er ikke en proces eller en teknik til udvikling af produkter, men nærmere

en ramme, inden for hvilken man kan anvende forskellige processer og teknikker” (Myllerup, 2010, s.3).

Det fremgår også af Myllerups oversættelse, at Scrum er funderet i teorien om empirisk proceskontrol og understøtter iterativ softwareudvikling. Frameworket består af et sæt af metoder og regler, som bl.a. omfatter møder og artefakter, der har til formål at optimere forudsigelighed og kontrollere risici (Myllerup, 2010).

I flg. ophavsmændene selv er tilpasningerne mulige, men så er der ikke længere tale om Scrum:

“Scrum’s roles, artifacts, events, and rules are immutable and although

implementing only parts of Scrum is possible, the result is not Scrum” (Sutherland & Schwaber, 2011, s.15).

Ken Schwaber skriver tydeligt i sin bog ”The Enterprise and Scrum” at man ikke bør ændre Scrum:

"Do not change Scrum. Scrum isn't a process that you modify to fit your enterprise.

Instead, it exposes every dysfunction in your enterprise while you build products. It

is your canary in a coal mine. Whenever people change Scrum, it's because they

have run into a problem, dysfunction, or conflict that they do not want to face and

fix. Instead, they change Scrum so that the problem remains invisible and remains

deadly to your enterprise. If you allow this to happen, you will have just lost

Scrum's primary benefit" (Schwaber, 2007, s.7).

I ovenstående citat argumenterer Schwaber for, at hvis man finder det nødvendigt at ændre eller tilpasse Scrum, er det et tegn på, at noget andet er galt og man bør derfor starte med at analysere og rette fejlen.

Men hvis ovennævnte er sandt, hvorfor er der så alligevel mange, som tilpasser metoden? Hvordan mapper den oprindelige Scrummetode egentlig til de mange projekter, hvori den bruges?

Scrum er uden tvivl en meget benyttet metode, men det er nok ikke fordi den i alle tilfælde benyttes præcis efter bogen (Schwaper og Sutherland’s). En anden grund kunne være, at man har fokus på de relevante opgaver, og at man motiverer udviklerne ved at give dem medbestemmelse og kun planlægger udviklingen et par uger frem, ud fra den agile betragtning om, at virkeligheden nok alligevel ænder sig undervejs.

Man kunne formode at en del, som i Unifeeders tilfælde, ikke bruger ”rigtig” Scrum, når det kommer til stykket, men i stedet bruger en fornuftig projektmodel, hvor man kalder møder og artefakter det samme som i Scrum. En årsag hertil kan være at et projekt eller organisation ikke matcher ”the sweet spot” – et begreb som Kruchten har introduceret:

”The sweet spot mirrors the kinds of projects that the method designers had in

mind when they constructed the first Agile methods. It is unsurprising that projects

in the sweet spot benefit from the application of methods such as Scrum and XP” (Hoda et al., 2010, s.84).

Dvs. at en metode ikke passer alle kontekster lige godt, hvilket ikke nødvendigvis er ensbetydende med, at metoden ikke kan bruges. Der er bare behov for tilpasning (BLH; TBE; SRT; HFI).

”We found that our participants follow many Scrum and XP practices without

adapting them. Where participants did adapt practices, we found the modification

of 69

stems from the fact that the projects do not sit within this sweet spot” (Hoda et al., 2010, s.84).

Det vil derfor være nærliggende at justere metoden, så den passer til den aktuelle kontekst, hvilket sandsynligvis er det, som er foretaget i ovennævnte tilfælde. Herved opstår de i afsnit 1.1.1 omtalte Scrum-Buts. Men i modsætning til Schwaber argumenterer Jurgen Appelo for, at det er tilpasningerne, der giver Scrum værdi: ”ScrumButs Are the Best Part of Scrum” (Appelo).

Dette udsagn begrunder han på følgende vis:

”..because optimal behavior is a function of internal structure and external

environment, the real optimal method always depends on the team's structure and

environment” (Appelo).

Altså at tilpasning er en nødvendighed for at opnå den optimale metode. Men man skal naturligvis passe på, at Scrum-but undtagelser ikke bliver en undskyldning for ikke at løse eventuelle dybereliggende problemer.

Det er heller ikke alle, der er af den opfattelse at Scrum er enestående i sine principper. Rising & Janoff argumentere for, at Scrum bygger på Barry Boehm’s Spiral model:

”The essential ideas behind the spiral model are exactly the same as those in

Scrum - just speeded up!” (Rising & Janoff, 2000, s.32).

Fig. 20. Barry Boehm’s Spiral model (http://newton.cs.concordia.ca).

of 69

Spiralmodellen har måske været en inspirationskilde bag flere af de agile metoder omtalt i afsnit 1.2, idet det er en af de første modeller, der er baseret på en iterativ fremgangsmåde. Der er afgjort visse ligheder mellem Spiralmodellen og Scrum mht. iterativ tilgang med faseinddeling/Sprint. Men Spiralmodellen indeholder nogle andre elementer end Scrum - som f.eks. risikoanalyse og tests (Fig. 20), og den stiller ikke så mange krav mht. ceremonier, artefakter og roller som Scrum gør.

Hvis Scrum skulle være en omskrivning af spiralmodellen, ville det så gøre en forskel, hvis man ikke kaldte sin udviklingsmetode for Scrum, men i stedet lavede en liste med opgaver og features, som skulle udvikles og herefter udvalgte de vigtigste af dem, som man vurderede, var realistiske at afvikle indenfor en kortere aftalt periode og så mødtes hver dag til en lille snak om, hvordan det stod til med projektet? Det ville det nok ikke i den forbindelse. Men om udeladelse af elementer fra Scrum vil få konsekvenser for et projekts gennemførsel eller sucess, vil kræve en del yderlig forskning og resultatet vil sikkert være meget afhængig af det enkelte projektets konteks.

Man kunne argumentere for, at Scrum i ovennævnte tilfælde er blevet brugt på den måde, som Rising & Janoff beskriver, nemlig at Scrum bare er en omskrivning af Spiral modellen (Rising & Janoff, 2000). Men iflg. Schwarber ville ovennævnte ikke være Scrum.

Men hvad er det, der gør Scrum til Scrum? Er det de omtalte artefakter, roller og ceremonier eller er det kravet om et eksekverbart produkt ved udgangen af hvert sprint?

Scrum er tiltænkt agil softwareudvikling, hvor deltagerne i mindre teams selv vælger blandt opgaverne og forpligter (commitment) sig til at levere disse ved Sprintets afslutning (Sutherland & Schwaber, 2007). I disse tilfælde arbejder teamet ofte som en selvstyrende gruppe. Sammenholdt med teamets engagement, har det en motiverende effekt på teamet, som Birte også oplever ”der kan gå sport i at nå opgaverne, hvis man er kommet bagefter” (afsnit 5.1.1).

I nogle tilfælde varetages rollen som Scrum Master i stedet af en projektleder (SRT; HFI) og der er i højere grad tale om et arbejdsleder/arbejdstager forhold, hvilket ikke helt harmonerer med metodes grundtanke om ”self-motivated teams” (Sutherland & Schwaber, 2007, s.87). Men det kan måske hænge sammen med, at der kan være stor forskel på deltagernes kompetencer – som Birte nævner ”alle skal kunne se sig selv i sprintet” (afsnit 5.1.1). Dvs. at ikke alle udviklere kan påtage sig alle opgaver. Hos Unifeeder er det af samme årsag projektlederne, som prioriterer og tildeler opgaverne, men det er dog stadig op til udviklerne selv at tilrettelægge deres abejde.

Ovenstående er eksempler på emperi, hvor Scrum ikke helt rammer ”the sweet sport”. Svaret på ovennævnte spørgsmålet: hvad der gør Scrum til Scrum, er derfor, at det er helheden i metoden. Dvs. at alle elementer fra Scrum frameworket skal være repræsenteret i de enkelte implementeringer før, at man kan sige, at det er Scrum, man anvender. Denne antagelse er i overensstemmelse med ophavsmændenes definition af Scrum i The Scrum Guide og i sidste ende er det denne definition, som er gældende (Sutherland & Schwaber, 2011). Dette betyder dog ikke, at Scrumelementerne ikke med fordel kan bruges enkeltvis og i mange forskellige sammenhænge – men der er i såfald ikke tale om Scrum.

of 69

5.2.3 Hvad gør Scrum så populær?

I forbindelse med softwareudvikling er Scrum formodentlig blevet populær, fordi metoden er baseret på effektive projektledelsesprincipper, som f.eks. fælles mål, synlighed, opgavefokus, opfølgning osv. – principper, der er meget formaliserede i Scrum. Både Henrik og Svend giver også udtryk for, at de ser et stort potentiale i de enkelte delelementer, som Scrum består af og at det ikke er nødvendigt, at anvende hele metoden (HFI; SRT). Men at delelementer kan anvendes uafhængigt, da det lader til at Scrum består af elementer, som kan bruges i forbindelse med andre projekttyper end softwarekonstruktion (Nyboe et al., 2009).

Grunden til populariteten er formodentlig også, at metoden bygger på nogle grundlæggende projektstyrings- og ledelsesprincipper, som bl.a. detaljeret planlægning, hyppig opfølgning og motiverende arbejdsformer, hvor udviklerne eller teamet selv har stor indflydelse på tilrettelæggelsen af arbejdet:

“We chose “Scrum” as it has a focus on day to day project management and is the

most widely adopted agile project management method” (Hossain et al., 2009, s.175).

Ud fra ovenstående citat kan man aflede, at der også er en tendens til at følge en trend og bruge andres gode erfaringer.

Umiddelbart er det vanskeligt at afgøre, om Scrum også fungerer i projekter, hvor man ikke benytter metoden helt efter forskriften. Men ud fra de fire interviews i dette studie tyder det på, at det er muligt, og jeg mener også, at der i Scrum indgår elementer, som er brugbare i mange andre sammenhænge, hvor konteksten ikke lige matcher ”the Sweet spot” for metoden. Derfor er det også vigtigt, uanset om der er tale om Scrum eller ej, at processen understøttes af et digitaliseret værktøj, som kan sikre data og hjælpe udvikleren med at bevare overblikket.

5.2.4 Brug af Scrum værktøjer

I forbindelse med Scum har man behov for et værktøj til at styre processen og der er stor forskel på de værktøjer, der bruges til at understøtte Scrum og agil udvikling. De spænder fra lavpraktiske lister og Post-it sedler, som udelukkende håndteres manuelt, til avancerede digitaliserede systemer.

Et af de mest centrale værktøjer er Scrum Boardet. Det er ofte benyttet og kan være struktureret på mange forskellige måder. Scrum Boardet bruges både som et diskussionsmedie Det interaktive Scrum Board (Alexandra) og som en visuel projektoversigt visual pulse board, hvor det synliggør status og eventuelle problemer:

”It is easy to see when the participants have a problem and reserve a separate

meeting discussing that problem” (Ericsson et al., 2011, s.8).

Det er normalt omkring Scrum Boardet, at et projektteam samles i forbindelse med Daily Scrum og Sprint Planning. Her kan boardet bl.a. være med til at højne kvaliteten i diskussionerne: ”After the implementation of visual pulse board the quality of discussions at the

weekly follow-up meetings have solidly increased compared to before when they

were realized in an office” (Ericsson et al., 2011, s.8).

of 69

Der synes dog at være en sammenhæng mellem de valgte løsninger og den empiriske kompleksitet, de bruges i. For eksempel fungerer lavpraktiske løsninger bedst i projekter, hvor hele Scrum teamet er samlet, hvorimod udvikling med distribuerede og globaliserede teams stiller højere krav til systemerne, da kommunikation over distancer og tidszoner er vanskeligere.

Iflg. Hossain et al’s review er det også ineffektive værktøjer, der fremhæves som en af udfordringerne i forbindelse med Globaliseret udvikling:

”Lack of effective collaborative tools, global task boards, suitable bug and issue

trackers, globally accessible backlog tool are also reported to be challenging

factors” (Hossain et al., 2009, 179).

”Lack of tools and insufficient infrastructure support may also make use of Scrum

practices in GSD difficult” (Hossain et al., 2009, s.182).

De fremhæver også hvilke værktøjer, der er nødvendige i denne sammenhæng:

”GSD projects that consider using Scrum need a wide range of tool support. Tools

may include communication, collaborative, project management, issue tracking,

bug tracking, globally accessible backlog, and burn down chart etc” (Hossain et al., 2009, s.181).

Derudover hævder de også, at man på et tidligt tidspunkt i sådanne projekter bør etablere de nødvendige værktøjer til at supportere processen:

”We found the practice:“proactive resource management” helps ensure that a

Scrum team has the necessary tools and skills to support their Scrum practices in

distributed settings” (Hossain et al., 2009, s.181).

”A distributed Scrum team also needs to be supported by various tools for project

management, backlog management, tracking issues, and so on” (Hossain et al., 2009, s.182).

Ved det tidligere omtalte OpenMeeting om distribueret Scrum og Agil udvikling brugte alle, der deltog i ”Tools” debatten på GeekNight, da også digitaliserede systemer til at understøtte Scrum, hvorimod mine interviews samt andre (Kniberg, 2006) hovedsagligt brugte lavpraktiske værktøjer.

Ovennævnte viser, at der findes et behov for digitaliserede værktøjer, som kan understøtte fleksibel brug af Scrum i forbindelse med agil softwareudvikling, herunder distribuerede og globaliserede teams. Her vil det specielt være Scrum Boardet, som bør understøttes. Men i den forbindelse stilles der store krav til arkitektur og design, idet lokale teams ofte foretrækker lavpraktiske løsninger (Alexandra) og en digitaliseret løsning skal være modificerbar nok til at kunne understøtte forskellig struktur/inddeling og brug.

Registreringer af f.eks. tidsforbrug, opgaveestimering og restestimering /færdighedsgrad, som er ukorrekte er i bedste fald ubrugelige, men kan i værste fald være direkte vildledende og føre til forkerte konklusioner i forbindelse med retrospektive analyser.

Hvis ovennævnte håndteres i administrative systemer, som ikke er synkroniseret med Scrumprocessen eller på anden måde er for usikre eller omstændige, så teammedlemmerne ikke er motiverede for at benytte dem korrekt, kan dette ligeledes være en kilde til fejl.

Derfor skal de administrative oplysninger om tidsforbrug, estimater, opgavestatus og færdighedsgrader helst indgå som en naturlig del af Scrum processen – dvs. de

of 69

skal understøttes i de værktøjer og artefakter, som man ellers benytter (f.eks. Scrum Board og Backlogs). Nøgleordene er synlighed, brugervenlighed, fleksibilitet og modificerbarhed. Registrering og tilgang til administrative data, kan f.eks. forgå både fra PC og Scrum Board.

of 69

6 Generisk Scrum prototype I de følgende afsnit vil jeg argumentere for, hvilke kvaliteter og funktioner, der er relevante i et Scrumsystem, som kan understøtte Scrumprocessen.

For at få afklaret hvilken funktionalitet et Scrumsystem skulle håndtere, lavede jeg, på baggrund af de afholdte interviews og artikler om Scrum, en mocup prototype af et Scrumsystem, som kunne præsenteres for informanterne. Til prototype blev der eksperimenteret med forskellige mockup tools som f.eks. lumzy (http://lumzy.com) og Balsamiq (http://www.balsamiq.com), men ingen af værktøjerne virkede overbevisende, så valgte faldt i stedet på Powerpoint, fordi det var lettere at bruge og opfyldte de samme behov mht. tekst og grafiske elementer.

6.1 Systemkrav

De arkitektoniske drivers var, som tidligere beskrevet i afsnit 4.3, usability og modifiability, da disse kvalitetsattributter er de mest relevante i et generisk Scrumsystem, som kan understøtte atypisk brug af Scrum. Målet var nemlig at tilbyde et system, som kunne tilpasses og anvendes i forbindelse med atypisk Scrum af en bred målgruppe, uden at det ville være nødvendigt at ændre i koden. Herved adskilder dette system sig fra de i kapitel 3 beskrevne systemer.

Mht. værktøjer har Sutherland & Schwaber også anbefalinger om, hvorledes Scrumsystemer bør understøtte processen.

"tools should track tasks completed by developers and work remaining. They

provide more detailed and useful data than time sheets, which should be avoided.

Timesheets are extra overhead that do not provide useful information on the state

of the project, and are de-motivating to developers" (Sutherland & Schwaber, 2007, s.82).

Det var derfor også et mål for systemet at understøtte Scrum processen på en intuitiv måde, således at de administrative funktioner håndteres, som en naturlig del af flowet og derved kræver så lidt ekstra tid af brugerne som muligt. Designet skulle derfor virke motiverende for brugerne, da det gerne skulle lette opgavehåndteringen i forhold til den manuelle proces, med små opgavesedler og tidsforbrug som efterfølgende skal registreres i et it-system.

Fokus for prototypen har derfor været at tilbyde en letvægtsudgave af et Scrumsystem, hvor konfigurationen bl.a. styrer de grafiske elementer, som f.eks. Scrum Boardet. Det er hensigten, at der på Boardet kun findes de nødvendige komponenter, så det virker overskueligt så brugerne bevarer overblikket. Inspirationen hertil har været apps til Smart phones, Pads og mobile enheder, som pga. små skærme og touch interaktion, stiller krav til det grafiske design, mht. en simpel opbygning med store komponenter, som f.eks. knapper og tekstfelter. Det samme gælder for Scrumsystemet, hvor målet er kun at vise de komponenter, som er relevante i den aktuelle kontekst.

of 69

Omdrejningspunktet er de visuelle elementer i form af et digitaliseret Scrum Board med opgaver, som typisk vil være der, hvor de daglige registreringer foretages f.eks. i forbindelse med Daily Scrum.

Ud fra opgavernes placering på Scrum Boardet, estimater og den resterende tid kan systemet holde styr på, om det er opnåeligt at få løst alle opgaver i sprintet og markere de lavest prioriterede opgaver, som er i fare for ikke at blive afsluttet i indeværende Sprint.

6.1.1 Funktionalitet

Systemet understøtter alle artefakterne i Scrum: User Story, Backlogs, Sprint og Burndown Chart. Backloggen håndteres på samme måde som i flere eksisterende systemer, hvor Product Owner eller en projektleder opretter User Stories med beskrivelser af ønsket funktionalitet og prioritet. Den funktion foretages ved en almindelig PC og er derfor uintersant i denne forbindelse, da den ikke stiller specielle krav mht. design og interaktion. Men det er muligt at tilgå systemet fra forskellige PC’er, hvor f.eks. Product Owner, projektleder og bruger kan håndtere User Stories, Tasks etc. på mere traditionel vis vha. tastatur og mus.

Kernefunktionaliteten i systemet er som i andre Scrumsystemer opgavehåndtering i form af User Stories og Tasks af forskellige karakter, som i dette tilfælde skifter status afhængig af deres aktuelle placering på Scrum Boardet. Når en Task eller User Story flyttes på Scrum Boardet skifter den status til den status, der er tilknyttet det felt, den flyttes til (Fig. 21).

Fig. 21. Task 1 flyttes fra In Progress til Done.

Status og felter sættes op i den aktuelle konfiguration af Systemet, og hver flytning logges. Ved tryk på Submit knappen gemmes alle opgaveflytninger og ændringer i en database. De kan herefter benyttes til at opdatere Backlogs og senere indgå i Sprint Review eller retrospektiv analyse. Altså et nyttigt værktøj til analyse i forhold til en lavpraktisk løsning med Post-it sedler, som f.eks. samles sammen og noteres i et regneark.

of 69

Men som udgangspunkt bør Tasks kun relatere til en User Story eller være enkeltstående i form af bugs eller ændringer af f.eks. teknisk karakter, som ikke direkte er tilknyttet en User Story. Det kunne f.eks. være refactoring af koden pga. arkitektoniske ændringer.

I min løsning kan man oprette Tasks direkte fra en User Story, hvorved der skabes en relation mellem Task og User Story. Når en bruger trykker på T feltet i en User Story (Fig. 22) åbnes et Task vindue (Step 1), hvor den nye Task automatisk har fået et nyt nummer (#2) samt en reference til den tilhørende User Story (#4). Brugeren kan herefter vælge en kategori – f.eks. Feature, samt indtaste øvrige oplysninger så som prioritet, titel, opgavebeskrivelse og tidsestimat. Ved at trykke på OK knappen lukkes Taskvinduet igen og oplysningerne valgt iht. konfigurationen, kan ses i det nye Taskobjekt på Boardet (Step 2), som placeres lige under den tilhørende User Story.

Fig. 22. Oprettelse af Task fra User Story.

Det vil dog heller ikke kræve ret store ændringer at tilføje den samme funktionalitet på Taskobjekterne og skabe en relation mellem to af disse. Derved understøttes samme funktionalitet, som beskrevet af Rubart & Freykamp (2009).

Mht. registrering af fremdrift for User Stories og Tasks findes der to typer:

1. Forbrugt tid, som angiver hvor mange udviklingstimer, man har brugt på de enkelte opgaver.

2. Restestimat, som angiver hvor mange udviklingstimer, der skal bruges for at afslutte en opgave.

Valg af registreringsmetode kan aftales for hvert enkelt projekt og vil typisk afhænge af et projekts kontekst eller et teams arbejdsmåde. Man kan også vælge helt at lade være og f.eks. kun registrere om en opgave er løst eller ej. Det afhænger af konfigurationen.

of 69

Et scenario hvor man registrer tid kunne se således ud. I figur Fig. 23 flyttes en Taks fra In Progress til Done (Step 1). Når Taskobjektet slippes i Done, åbnes automatisk et vindue (Step 2), hvori brugeren kan angive det brugte antal tidsenheder. Når brugeren trykker på OK knappen lukkes vinduet og de registrerede tidsenheder gemmes.

Fig. 23. Flytning af Task med tidsregistrering.

Ved at inkorporere tidregistrering i flytning af Tasks og User Stories bliver to opgave i stedet til én (flytning af sedler og tidsregistrering). Man sikre derved, at tidsregistreringen er fortaget, når dette sker i forbindelse med Daily Scrum, samt at Burndown Chartet er retvisende. En anden fordel kan være at eventuelle problematiske Tasks bliver synlige tidligere i Sprintet og kan diskuteres i teamet.

Denne funktionalitet vil f.eks. give nogle fordele hos Unifeeder i forhold til den eksisterende løsning, hvor tidsregistrering foretages i et andet system, hvilket er hovedårsagen til, at man ikke benytter Burndown Charts.

6.1.2 Pervasive interaktion

Et digitaliseret Scrum Board skal kunne kommunikeres med interaktivt uden brug af eksterne enheder, som tastatur eller mus, hvis det skal være brugbart, ellers er der kun tale om en almindelig PC med en forstørret skærm. Til at opfylde dette ønske findes flere interaktionsmuligheder og teknologier.

Den mest oplagte teknologi er Touch-screens, som er store trykfølsomme skærme i stil med dem, man bruger i smart phones, bare meget større. En anden mulighed er Smart boards, som består af et white board, som belyses af en projektor. Det fungerer ved, at boardet overvåges af et antal kameraer, som sammen med en PC, fortolker de handlinger, der foretages på boardet og agerer herefter. Begge

of 69

løsninger er blevet meget udbredte de seneste år og de gør det muligt at manipulere med visuelle objekter direkte på skærmen uden behov for tastatur eller mus.

En anden og mere eksperimentiel løsning er brug af QR tags i stil med den Alexandra Instituttet arbejder med, som er beskrevet i afsnit 3.1.2.

Stemmegenkendelse er også en interaktionsmulighed, som bla.a har været brugt inden for hospitalsverdenen (Hansen, 2004). Set i forhold til Scrumsystemet kunne et scenario være at deltageren taler direkte til Scrum Boardet og f.eks. siger ”command, new task” hvorefter systemet åbner et vindue til oprettelse af en task og herefter indsætter de oplysninger, som deltagerne kommanderer, f.eks. ”category, bug”, ”prioiry, 110”, ”Title, error in login” osv. Problemet med denne teknologi er, at den er mindre anvendelig i sociale situationer, idet baggrundsstøj i forbindelse med Daily Scrum, hvor hele teamet står tæt samlet foran Scrum Boardet og taler sammen, kan påvirke resultatet. Ligeledes er det en udfordring, at systemet skal kunne genkende stemmerne for hele teamet – og helst også hvis de er forkølede eller af andre årsager, har stemmeforandring.

Gestusgenkendelse, hvor brugerens bevægelser opfanges af et webcam eller en håndholdt enhed med et accelerometer og omsættes til handlinger, kunne også være en mulig interaktionsform. Men teknologien er i forbindelse med et Scrumsystem ikke så praktisk, da den er bedst egnet til faste kommandoer som eksempelvis: gem, luk og åben. For at kunne erstatte et tastatur i forbindelse med indtastning af tekst, som der vil være brug for i et Scrumsystem, vil man være nødsaget til at oversætte bestemte fagter til faste sætninger eller ord, hvilket formodentlig ikke vil være særlig anvendeligt, da der i så fald vil blive mange fakter at huske. Alternativt skulle man have en bevægelse for hvert bogstav. Men det ville nok blive for besværligt og langsomt i forhold til et tastatur på en trykfølsom skærm.

Hvis Scrum Boardet skal holde styr på, hvem der gør hvad, er det også nødvendigt at systemet kan genkende, hvem der flytter (har løst) en opgave. Den optimale løsning vil i dette tilfælde være, at systemet genkender brugeren ved boardet intuitivt, uden at brugerne skal foretage sig noget særskilt. Dette kunne f.eks. håndteres vha. RFID tags eller anden kortrækkende trådløsenhed, der udsender et signal, som fortæller, hvem brugerne er. Men en af udfordringerne er antallet af deltagerer (5-9) og afstanden til Scrumboardet, som normalt er forholdsvis kort 1-2 meter. Der er altså risiko for, at systemet modtager forkerte data eller misfortolker signalerne, hvilket kan medføre, at registreringerne bliver forkerte. En bedre løsning kunne i såfald være ansigtsgenkendelse vha. webcam, som genkender og registrere den bruger, som står nærmest. Den simpelste løsning vil dog stadig være, at lade hver bruger ”logge sig ind”, umiddelbart inden han/hun foretager sig noget ved boardet. Men denne løsning kræver mere disciplin, da det er en risikofaktor at brugerne glemmer at logge sig ind og kommer til at registrerer på hinandens opgaver.

of 69

6.1.3 User Stories

Herunder beskrives et eksemple på Scrumsystemets funktionalitet og virkemåde vha. Mockup Walk Through.

Eksemplet er baseret på en trykfølsom skærm og manuel bruger login. Funktioner, som bruges i forbindelse med opsætning og oprettelse af f.eks. brugere, projekter, sprints og User Stories vil ikke blive beskrevet, da disse operationer ikke har nævneværdig indflydelse på den daglige brug af systemet.

Eksempel: Opret en Task ved Scrumboardet

I firma SoftProd A/S, hvor man benytter version 1.0 af det nye GeniScrumsystem skal Per, Hanne, Ole og Bent til at starte på dagens Daily Scrum møde. De er i gang med at udvikle en webløsning til en E-bogs butik. Det er dag 1 i Sprint 2 og de samles foran den store trykfølsommeskærm, som viser det nye sprint med de opgaver (Fig. 24), Scrum Masteren Bent har lagt i dette sprint iflg. aftale med Product Ownerne fra E-bogs butikken.

Fig. 24. Scrum Board ved dag 1 for Sprint nr. 2.

Ole bemærker, at Bent mangler en opgave under User Story #2 ”Fjern vare fra indkøbskurv” og da det er Ole, der skal kode varehåndteringen, går han hen til Boardet og trykker på sit eget ikon på skærmen (Fig. 25). Herved angiver Ole, at det nu er ham, som skal logges som den aktive bruger.

of 69

Fig. 25. Aktivering af bruger.

Herefter trykker Ole på T knappen i User Story #2 (Fig. 26) for at oprette en ny task under denne User Story.

Fig. 26. Tryk på T tast for at oprette en Task.

Systemet kreere nu en ny opgave (Taskobjekt) og åbner et vindue, hvori Ole kan indsætte de nødvendige oplysninger (Fig. 27). Derudover kan Ole flytte rundt på vinduet ved at placere en finger på vinduet og trække det, hvorhen han ønsker det.

of 69

Fig. 27. Scrum Board med default Taskvindue.

Opgaven indeholder allerede et Task nummer, reference til den tilhørende User Story samt en katogori Feature, som SoftProd har sat til at være default. Ole vil lige tilføje en Titel så han trykker på Title og systemet åbner et tastatur på skærmen (Fig. 28)

Fig. 28. Scrum Board med Taksobjekt og Tastatur

of 69

Efter indtastning af titlen trykker Ole tastaturet væk ved at trykke på tastatur knappen i nedereste højre hjørne på tastaturet (Fig. 28). Inden han gemmer opgaven, vil han dog lige angive at udviklingen forventes at tage 2 timer, så han trykker på Remaining på Task vinduet, hvorefter systemet åbner et nyt numerisk tastatur (Fig. 29).

Fig. 29. Scrum Board med Taksobjekt og Numerisk tastatur.

Ole er nu færdig med sin opgaveoprettelse og lukker derfor de to vinduer ved, at trykke på OK knapperne i vinduerne (Fig. 29). Herefter opretter systemet en ny lille task under User Story #2 med Oles indtastninger og Ole som User (Fig. 30).

of 69

Fig. 30. Scrum Board med Oles nye Taksobjekt.

Hvis Ole ønsker at arbejde på opgaven med det samme, kan han flytte den nye Task ved at trække den med en finger fra ToDo til In Progress. Til sidst mangler han bare at trykke på Submit for at gemme sine ændringer. Hvis han har behov for det, kan han også efterfølgende logge på fra sin egen PC og rette sine opgaver derfra. Han undgår derved at spilde tid ved det korte Daily Scrum møde.

Fordelen ved ovenstående løsning er, at deltagerene kan oprette opgaver direkte på boardet, hvilket er en digitaliseret erstatning af den lavpraktiske procedure, hvor deltagerne udfylder Post-it sedler med tusch og klistre dem op. Brugerne skal ikke hen til en PC og det hele sker i én proces, idet opgaverne ikke efterfølgende skal registreres i et system for at kunne indgå i eksempelvis Burndown Charts.

6.1.4 Interfaces

Herunder nævnes de vigtigeste komponenter som systemet håndterer via grænseflader som ikke indgår i det daglige system.

Opsætning:

• Håndtering af teammedlemmer/brugere (navn, login, osv)

• Statushåndtering (navn/titel)

• Håndtering af tasktyper/farver, story points og tidsenheder

of 69

Backlog:

• Registrering af User Stories og Tasks

• Oprettelse af Sprints

• Tilknytning af User Stories og Tasks til Sprints

Scrum Board:

• Grafisk inddeling af kategorier (To Do, In Progress, Done, osv.)

• Handlinger (angivelse af aktuel bruger, undo)

• Oprettelse af Tasks og evt. User Stories (quick insert, estimering)

• Flytning af Tasks (med tracking af bruger og statusskift)

• Restestimering (tid/procent)

Øvrige visninger:

• Sprint Burndown

• Velocity beregning.

6.1.5 Objekter

Project - overordnet opgave, som består af et antal leverancer, som udvikles i løbet af et eller flere sprints.

Attributter:

• ID – autogenereret nummer

• Titel – projektnavn

• Description – beskrivelse af projektet

• Start date – dato for hvornår projektet starter

• End date – dato/deadline for hvornår projektet forventes afsluttet

Udover overstående vil der naturligvis være en del andre oplysninger for projektet, som f.eks. interessenter, budget osv. Men de er ikke interessante i denne forbindelse.

Sprint – en periode indenfor hvilken et antal User Stories skal realiseres.

Attributter:


• Titel – navn eller nummer

• Velocity – antal estimerede story points eller tidsenheder

• Start date – dato for hvornår et sprint starter

of 69

• End date – dato for hvornår et sprint slutter

User Story – en beskrivelse af afgrænset funktionalitet, som ønskes af Product Owner. User Stories kan nedbrydes i arbejdsopgaver (Tasks). En User Story kan tilknyttes flere Sprints, hvis den f.eks. ikke kan løses inden for et enkelt og har laveste status ift. tilknyttede tasks.

Attributter:

• ID – autogeneret nummer

• Titel – navn eller kort beskrivelse

• Priority – som angiver vigtigheden af funktionaliteten

• Deadline – dato hvor alle opgaver vedr. en User Story skal være færdige

• Sprint – tilknytning til et Sprint

• Estimate – den totale estimerede tid/story points

• Description – detaljerede oplysninger om funktionalitet

Task – del af en User Story eller enkeltstående opgave, som f.eks. et teknisk problem eller bug, som skal løses, men ikke kan kobles til en bestemt User story.

Attributter:


• Titel – navn eller kort beskrivelse

• Type - En taks skal kunne have en type (new feature, bug, unplaned osv)

• Priority – som angiver vigtigheden af opgaven

• Deadline – dato, hvor opgaven skal være færdig

• Sprint – tilknytning til aktuel Sprint eller arves fra en tilknyttet User story

• User – tilknytning til den/de brugere som har/skal arbejde på opgaven

• Estimate – tid

• Residual estimat – resterende tid

• Realisert tid – summen af registreret tid brugt på opgaven

For at man visuelt lettere kan skelne mellem forskellige opgavetyper, kan typen f.eks. være afgørende for, hvilken farve opgaven har på Scrum Boardet:

Afgrænsninger

• Sikkerhed af teknisk eller datamæssig karakter, som f.eks. roller, interaktion og netværk, vil ikke blive håndteret, da dette ikke er fokus for denne mockup prototype.

• Retrospektiv vil der ligeledes ikke blive fokuseret på, da dette er en proces, som ikke kræver megen brugerfunktionalitet af systemet. Det ville dog være naturligt at logge relevante indtastninger og ændringer, så man

of 69

efterfølgende kan udtrække historisk data til understøttelse af en retrospektiv analyse.

6.2 Præsentation af prototypen

Jeg har i første omgang valgt at basere interaktionen i prototypen på en trykfølsom skærm, da dette var den mest oplagte interaktionsform. De andre interaktionsformer, som beskrives i afsnit 6.1.2 vil kunne tilføjes efterfølgende, idet brugsmønsteret og funktioner vil være ens – kun interaktionen og konfigurationen vil være forskellig.

Da mockup protypen var færdig, blev de simulerede skærmbilleder printet ud og præsenteret for Birte, Thomas og Henrik med henblik på at få deres feedback på layout/grafik, interaktion og funktionalitet, samt om systemet ville være brugbart i deres kontekst.

Selve præsentationen foregik ved, at de fire mockup skærmbilleder (Appendiks 9.3 figur. Fig. 31 - Fig. 34) blev bredt ud på et bord, hvorefter de blev præsenteret og forklaret mht. funktioner, afhængigheder, samt beskrivelse af hvorledes prototypen skulle ses i en kontekst. For eksempel hvordan felter og typer kunne konfigureres og hvordan et Scrum team kunne diskutere opgaverne på Scurm Boardet, oprette nye og skiftes til at flytte rundt på dem.

Derudover blev et par af de vigtigeste scenarier som f.eks. flytning af en opgave med tidsregistrering samt oprettelse af User Stories og Tasks simuleret ved, at pege på vinduerne i den rækkefølge, som de ville blive præsenteret for brugeren.

6.3 Feedback på prototypen

I forbindelse med præsentationen blev kommentarer fra informanterne noteteret dels direkte på papirskærmbillederne, hvis de var tæt knyttet til disse – og dels på en notesblok, hvis der var tale om mere overordnede synspunkter. To af præsentationerne blev også optaget på et lydmedie, hvilket ikke var til megen nytte, da det efterfølgende var uklart, hvilke skærmbilleder, der blev diskuteret. Hvis visuelt udstyr som video eller webcam havde været tilgængeligt, kunne jeg have med fordel have anvendt billedeoptagelser i stedet.

Birte var positiv overfor prototypen og påpegede, at værktøjet skulle være overskueligt og nemt at bruge. Hun mente, at begge disse kvaliteter blev understøttet i prototypen og at den ved første øjekast indeholdte de nødvendige oplysninger og funktioner. Derudover sammenholdte hun prototypen med erfaringer fra JIRA.

Mht. forbedringer nævnte Birte, at de hos Logica havde brug for et felt mere til impeded, som et variationspunkt, der i prototypen kunne håndteres via konfiguration (Grafisk inddeling af kategorier – afsnit 6.1.4).

Både Thomas og Henrik var også positiv overfor prototypen og mente, at funktionaliteten ville være en brugbar erstatning for en lavpraktisk løsning.

of 69

Enkelte Use Cases blev gennemgået – f.eks. oprettelse og flytning af Tasks og User Stories, og i den forbindelse diskuterede vi, hvordan sammenhængen mellem disse skulle håndteres. For eksempel kunne der være behov for at gruppere Tasks under den tilhørende User Story.

Derudover blev håndtering af estimater og tidsregistrering diskuteret – f.eks. om dette skulle ske ved Scrum Boardet i forbindelse med Daily Scrum. Fordelene ville være at registreringerne sammen med restestimater kunne bidage med aktuelle oplysning til status på Burndown Chartet. Ulemperne kunne være, at det kan virke demotiverende, at skulle registrere et tidsforbrug offentligt, som var større end forventet. Men her kunne det så måske afsløre, om en opgave var rigtigt forstået eller om udvikleren havde brug for hjælp.

Et par mangler som tilføjelse af User Story nummer, titlen på tasks samt en funktion til registrering af forbrugt tid blev identificerede og tilføjet på prototypen.

of 69

7 Konklusion I dette studie er forskellig brug af Scrum blevet analyseret ud fra interviews med erfarne Scrumbrugere fra fire virksomheder, hvor man i en årrække har brugt Scrum. De fire afholdte interviews er blevet analyseret og diskuteret på baggrund af eksisterende forskning. I alle fire tilfælde blev det belyst, at Scrum bruges i forskellige tilpassede varianter afhængig af virksomhedernes empiri og deres projekters kontekst. Med afsæt i denne erkendelse er betydningen af afvigelser i forhold til den oprindelige Scrummetode og hvilke konsekvenser dette har for it-projektledelse blevet diskuteret.

Både interviews og forskning viste også tydeligt, at der findes et behov for digitaliserede værktøjer, som kan understøtte atypisk brug af Scrum. I den forbindelse stilles der store krav til arkitektur og design, mht. intuitivt, overskuelighed og nem tilgængelighed, hvis lokale Scrumteams skal foretrække en en digitaliseret løsning frem for de nuværende simple lavpraktisk løsninger. I modsætning til lokale teams er distribuerede teams i højere grad afhængige af digitaliserede løsninger, hvilket bekræftes af både eksisterende forskning samt Geek Night Event.

Med inspiration fra forskellige softwarearkitektoniske principper indenfor Modifiability og Useability er en mockup prototype på et system til generisk understøttelse af Scrumprocessen blevet udviklet. Prototypen blev derefter præsenteret for informanterne fra de fire interviews og kommenteret af disse. Derudover er den blevet diskuteret ud fra komparativt materiale, som dels bestod af eksisterende produkter og dels af alternative løsninger, der understøtter Scrum. Prototypen adskilder sig fra flere af de eksisterende løsninger ved at den fra starten af er enkel, innovativ og samtidig kan understøtte Scrum i varierende kontekster.

Dette studie bidrager derved med ny viden inden for forskningen om udbredelsen og brug af Scrum, speciel hvad angår etablerede løsninger, som med tiden er blevet tilpasset lokale forhold. Dette område er tilsyneladende ikke vel belyst i den eksisterende forskning.

Et studie baseret på fire tilfældige eksempler kan naturligvis ikke give mere end et fingerpeg om i hvilket omfang Scrum benyttes i modificeret form, taget i betragtning af, hvor stor en udbredelsen Scrum har. Men alle informanterne har givet udtryk for, at de bruger Scrum i varierende omfang og på forskellig vis og det må derfor antages, at der ikke er tale om enkeltstående tilfælde, men at denne trend vil kunne genfindes i mange andre virksomheder.

Sprøgsmålet er så, hvor mange der i virkeligheden bruger Scrum, når man ser bort fra alle de tilpassede variationer? Ud fra dette studie må det formodes, at der findes en del andre eksempler, hvor brug af enkeltstående elementer fra Scrum, er blevet et synonym for Scrum. Men det vil kræve en større undersøgelse at kunne bekræfte denne tendens.

På baggrund af ovenstående må det anbefales, at der forskes videre inden for området, da Scrum er meget udbredt indenfor agil softwareudvikling og der trods flere eksisterende produkter, stadig er et stort potentiale i optimering af digitaliserede værktøjer, som intuitivt understøtter processen vha. de nye teknologier, som har vundet indpas inden for de seneste år. I den forbindelse bør der forskes yderligere i brug af eksempelvis Scrum Boards samt eksperimenteres

of 69

med de i afsnit 6.1.2 omtalte teknologier for at afklare om teknologierne er brugbare i en Scrumkontekst.

En stor tak til

Anne, Birte, Erik, Henrik, Line, Svend og Thomas for deres medvirken og hjælpsomme bidrag til dette studie.

of 69

8 Referencer (agilemanifesto) http://agilemanifesto.org (27.03.2012)

(alexandra) http://www.alexandra.dk/dk/lige_nu/nyheder/

nyheder-2012/Sider/interaktiv-scrumboard.aspx (26.03.2012)

(Appelo) Jurgen Appelo http://www.noop.nl/2009/09/ scrumbuts-are-the-best-part-of-scrum.html (27.03.2012)

(Bass et al., 2006) Bass, L., Clements, P., and Kazman, R., 2006. ”Software Architecture in Practice, 2nd Edition, Addison Wesley” (kap. 4 – 5)

(BLH) Interview med Birte, Logica ”BLH.m4a” (45:14)

(Boeg, 2011) Jesper Boeg, 2011 ”Priming Kanban” Trifork Agile Excellence Mini Book Series

(Ericsson et al., 2011) Evelina Ericsson, Joakim Lilliesköld, Liv Marcks von Würtemberg, 2011 ”Visual Planning Applied in a Research Environment”

(Hansen, 2004) Thomas Riisgaard Hansen, 2004 ”Interacting with pervasive computer systems – How to support physical, mobile, collaborative and distributed work”

(HFI) Interview med Henrik, Unifeeder ”HFI.m4a” (27:17)

(Highsmith & Cockburn, 2001) Jim Highsmith & Alistair Cockburn, 2001 ”Agile Software Development: The Business of Innovation”, SOFTWARE MANAGEMENT

(Hoda et al., 2010) Rashina Hoda, Philippe Kruchten, James Noble, 2010 ”Agility in Context”, OOPSLA/SPLASH’10

(Hossain et al., 2009) Emam Hossain, Muhammad Ali Babar & Hye-young Paik, 2009 ”Using Scrum in Global Software Development: A Systematic Literature Review”, Fourth IEEE International Conference on Global Software Engineering

(Kniberg, 2006) Henrik Kniberg, 2006 ”Scrum and XP from the Trenches”, Crisp

(Kvale, 2006) Kvale, Steinar, 2006 ”En introduktion til det kvalitative forskningsinterview” Kap. 4: ”Kvalitativ forskning i videnskab og i praksis”

(Marchenko & Abrahamsson) Artem Marchenko og Pekka Abrahamsson "Scrum in a Multiproject Environment: An Ethnographically-Inspired Case Study on the Adoption Challenges"

of 69

(Myllerup, 2010) Bent Myllerup, 2010 Oversættelse af ”The Scrum Guide - The Definitive Guide to Scrum: The Rules of the Game” af Ken Schwaber and Jeff Sutherland

(Nyboe et al., 2009) Freja Bange Nyboe, Louise Smed Møller, Tobias Bornakke Jørgensen & Jens Jarl Broe ”Scrummer to scrum or not to scrum”

(Overhage et al., 2010) Sven Overhage, Sebastian Schlauderer, Dominik Birkmeier, Jonas Miller, 2010 ”On the Developer Adoption of Scrum: A New Acceptance Model for Agile Methodologies” Working Papers on Information Systems, Sprouts

(Pries-Heje, 2011) Lene Pries-Heje & Jan Pries-Heje, 2011 ”Why Scrum works”

(Rayhan & Haque, 2008) Syed H. Rayhan and Nimat Haque, 2008 ”Incremental Adoption of Scrum for Successful Delivery of an IT Project in a Remote Setup”

(Rising & Janoff, 2000) Linda Rising & Norman S. Janoff, 2000 ”The Scrum Software Development Process for Small Teams” IEEE SOFTWARE

(Rubart & Freykamp, 2009) Jessica Rubart & Frank Freykamp, 2009 ”Supporting Daily Scrum Meetings with Change Structure”

(Salo & Abrahamsson, 2008) O. Salo & P. Abrahamsson, 2008 ”Agile methods in European embedded software development organisations: a survey on the actual use and usefulness of Extreme Programming and Scrum”

(scrum) http://www.scrum.org (27.03.2012)

(SRT) Interview med Svend, Alexandra Instituttet ”SRT.m4a” (47:07)

(Sutherland & Schwaber, 2007) Jeff Sutherland, Ken Schwaber, 2007 ”The Scrum Papers: Nuts, Bolts, and Origins of an Agile Process”

(Sutherland & Schwaber, 2011) Jeff Sutherland, Ken Schwaber, 2011 ”The Scrum Guide”

(Schwaber, 2007) Ken Schwaber, 2007 “The Enterprise and Scrum”

(TBE) Interview med Thomas, Vertica ”TBE.m4a” (44:59)

(Tomm, 1988) Tomm, Karl., 1988 “Family Process, Vol. 27” “Intending to ask lineal, circular, strategic, or reflexive questions?” (1-15)

(Uy & Rosendahl, 2008) Edward Uy & René Rosendahl, 2008 "Migrating From SharePoint to a Better Scrum Tool" Agile 2008 Conference

of 69

9 Appendiks

9.1 Interviewguide

1. Hvad er Scrum for jer og hvorfor bruger I Scrum ?

2. Hvor længe har I brugt Scrum ?

3. I hvilket omfang bruger I Scrum (alle projekter) ?

4. Hvilke af følgende artefakter bruger I og hvordan bruger I dem ?

a. Product Backlog

b. Release Burndown chart

c. Sprint Backlog

d. Sprint Burndown charts

5. Bruger i andre artefakter, som ikke er blevet nævnt ?

6. Hvilke artefakter, synes du, er de vigtigste eller mest anvendelige ?

7. Hvilke krav har I til elementerne i Backloggen ? (fx detaljeringsgrad)

8. Hvordan håndterer I funktionalitet ? (fx Use Cases/Stories, ønsker)

9. Hvilke af følgende møder afholder I og hvor meget tid bruge I på dem:

a. Release Planning

b. Sprint Planning

c. Daily Scrum

d. Sprint Review

e. Sprint Retrospective

10. Bruger i andre ?

11. Hvor har I tilpasset jeres Scrum metode ? (hvorledes og hvorfor ?)

12. Bruger I altid en fast struktur eller kan det variere ?

13. Har jeres måde at bruge Scrum på ændret sig, siden det blev introduceret?

14. Hvilke programmer bruger I til at understøtte Scrum ?

15. Bruger I et Scrum board ? (hvis ja, hvordan og hvordan er det opbygget ?)

16. Synes du Scrum er effektivt ? (hvorfor/hvorfor ikke ?)

17. Hvilke fordele og ulemper er der ved at bruge Scrum ?

18. Hvis du havde mulighed for det, ville du så ændre jeres Scrum løsning ?

19. Kunne du evt. tænker dig at bruge noget andet i stedet ?

of 69

9.2 Interviewskema

Emner Birte, Logica (BLH) Thomas, Vertica (TBE)

Henrik, Unifeeder (HFI)

Svend, Alexandra Instituttet (SRT)

Hvad er Scrum ?

En metode med nogle overordnede rammer [01:28]

En metode [01:36] Et projektstyringsredskab [00:35]

En model med et arsenal af værktøjer [35:45]

Erfaring med Scrum

3 år 4 år [01:51] 1½ år [02:28] Flere år [02:50]

Omfang af brug

Udvikling og support Overfor kunder og internt [00:30]

Hele porteføljen af It-projekter [01:45]

Projekter, hvor det er brugbart [13:43]

Artefakter:

- Product Backlog

Ja [02:45] Ja [05:29] Ja [05:20] Ja [08:25]

- Release Burndown Chart

Ikke besvaret Ikke besvaret Nej [10:46] Ja, i nogle tilfælde [21:15]

- Sprint Backlog

Ja [02:47] Ja [05:30] Ja [05:20] Ikke besvaret

- Sprint burndown chart

Ja [02:49] Ja [25:40] men bruges ikke altid [29:45]

Nej [10:46] Ja, i nogle tilfælde [21:15]

Andre artefakter

Scrum tavle [02:50] retrospektive smiley [07:34]

Skabeloner til løsningsbeskrivelser [21:09]

Scrum Board [03:10]

Bruges ikke altid

Excel ark med tidsforbrug [13:05]

Scrum Board – white board med post-it sedler [21:37]

Liste over delprojekter [08:01]

Interessent- og risikoanalyser [11:30]

Projektstyringsark [13:05]

Møder/-

ceremonier:

- Release Planning

Ja, halvårligt [21:50] eller hver 3. måned [22:25]

Ikke besvaret Nej [13:38] Ikke besvaret

- Sprint Planning

Ja [04:24] Ja [15:10] Ja [13:45] Ja [08:50]

- Daily Scrum

Ja [02:52] Ikke besvaret Ja, [13:48] Ikke altid

- Sprint Review

Ikke besvaret Ja [21:30] Ja [13:50] Ja [08:45]

- Sprint Retro-

Ja [07:20] Ikke besvaret Ja [13:20] Ikke besvaret

of 69

spective

Andre møder/-ceremonier

Ja, kundemøder [03:05]

Ja, opsamlingsmøde [27:13]

Ja, pre-planning [13:54]

Ja, koordinerings-møder efter aftale [09:42]

Bruges Timeboxing

Ja [23:11]

Daily Scrum 15 min. [09:28]

Sprintplanlægning 1,5 time [23:37]

Retrospektiv 1,5 time [24:26]

Nej, er forskelligt fra projekt til projekt [19:18].

Nej Ikke besvaret

Bruges fast sprintlængde

Nej [02:59] Nej, [20:55]

Ja , 14 dage [17:18] Nej, 1, 2 eller 4 uger [09:24]

Tidsestimer-ing

Timeestimering med velocity [13:17]

Features tidsestimers på sprintmøderne sammen med kunden [26:13]

Ja [12:19] Ja, af projektlederen evt. i samråd med deltagerne [22:48]

Opgavefor-deling

Frivillig, men der skal være opgaver til alle [04:26]

Ikke besvaret Bestemmes af projektlederne [14:44]

Ikke besvaret

Backlog krav Prioriteret rækkefølge [06:24]

Opgaver skal være estimerede [12:20]

Ja, jo bedre beskrivelse, jo bedre teknisk løsning [10:50]

Projektlederens ansvar [12:41], men diskutere løsninger med udviklerne [17:12].

Bruges prototyping

Ja, iflg. aftale med kunden [35:59]

Ja, i stor stil [37:38] Ikke besvaret Ja [23:56]

Bruges pair-programming

Ja, i sjældne tilfælde [40:36]

Ja, i enkelt tilfælde [37:02]

Ikke besvaret Ikke besvaret

Metode-tilpasninger

Ja, ved projekter som ikke er nyudvikling. Trækker en person ud til support [03:19]

Ja, afhængig af projekttypen [02:30]

Der er ikke krav om et eksekverbart system efter hvert sprint [21:30]

Ja, [04:48]

Bruger ikke User Stories [09:20]

Ja, bruger ikke Daily Scrum, men mødes efter behov [05:55]

Backloggen består bl.a. delprojekter [08:25]

Fast sprint struktur

Nej, er tilpasset de enkelte grupper

Nej, kan være både 2 og 3 ugers sprint

Ja, 2 ugers sprint Nej [07:50]

of 69

[00:40] f.eks. 3 ugers sprint [11:23]

2-3 udviklings sprint og et test sprint [33:40]

[20:55]

Fastsættes ofte sammen med kunden iht. ønsker og opgaven [21:53] [31:50]

System-under-støttelse

JIRA til opgave styring [18:09], bugs og kommunikation med kunder [20:35]

Sprint backlog håndteres i et regneark [29:15]

Separat tidsregistrerings-system [18:55]

Ressource- og opgavestyring håndteres i Excel [07:45] [24:58]

Burndown Charts laves ligeledes udfra Excel [29:30]

Brugte tidligere Ekstra net [32:15]

Lotus Notes til projektopgaver/ backloggen [05:20] og tidsregistrering [12:19]

Excel til sprint planlægning [06:10]

Tidsregistrerings-system [13:01]

Projektstyringsark i Excel med timeregistrering og omkostninger [13:05] [18:05]

Sharepoint ved distribueret udvikling [26:07]

Om Scrum

- Fordele Fællesskab og tilhørsforhold til opgaverne [39:01]

Synlige opgaver [43:40]

Udviklere, projekt folk og produkt er i sync [35:50]

Agilmetode og kommunikation via Daily Scrum [36:07]

Kontinuerlig opfølgning [23:32]

Skaber fælles forståelse [24:03]

En god model som viser flowet i processen [37:02]

Stiller artefakter til rådighed [37:13]

Skaber fokus på opgaverne som motiverende forpligter og skaber fremgang [44:50]

- Ulemper Indkomne ikke planlagte opgaver kan ødelægge et sprint [43:44]

Egner sig mindre godt til integrations-projekter [39:30]

Manglende synlighed udadtil for Produkt Owners [25:50]

Man skal ikke følge processen blindt – den skal tilpasses [39:03]

Mest anvendelige elementer

Scrum tavle [08:52] Ikke besvaret Daily Scrum [20:58]

Scrum Board [21:37]

Ikke besvaret

- Ændrings-forslag

Bedre support håndtering [31:26]

Strukturere Scrum lidt bedre til integrationsprojekter [39:10]

Brug af User Stories [10:07]

Brug af Burndown Charts [17:06]

Teknologisk bedre Scrum Board løsning [21:55]

Ikke besvaret

of 69

9.3 Mockup Prototype

Nedenestående er mockup skærmbillder fra prototypen inklusive forklaringer.

Fig. 31. Scrum Boardet.

Fig. 32. Task- og forskellige interaktionsvinduer.

of 69

Fig. 33. Backlog og Sprint overview.

Fig. 34. Sprint Burndown Chart.

Evaluering af tilpassede SCRUM metoder - report final · Men hvor meget kan metoden egentlig...

Documents

Transcript of Evaluering af tilpassede SCRUM metoder - report final · Men hvor meget kan metoden egentlig...