1. Scrum i projektledelse
[ Et studie af Scrum of Scrums hos firmaet Bluegarden ]
Hold › 62P30 (SIP 01) Scrum i projektledelse E16
Projekt forfattet af › Laurits West
Studie nummer: S160268
Underviser › Jens Lindhardt
Undervisningsinstitution › Ingeniørhøjskolen i København
Lautrupvand 15
2750 Ballerup
Antal anslag › 11.832 anslag inkl. mellemrum

2. SDF
14. oktober 2016 Laurits West
Scrum i projektledelse
› Det starter og slutter med mennesker Side
Sdf
1 af 9
Eksamensprojekt for
Scrum i projektledelse
Problemformulering
Hvordan kan et team på 13 personer strukturere sig, hvis de skal
løse to separerede ansvarsområder, der er afhængige af
hinanden?
- Er der specielle principper der kan effektivisere teamet?
- Hvordan håndteres afhængigheder i leverancer bedst?
- Findes der en standardiseret metode der kan hjælpe?
Metodevalg
Der er blevet valgt at fokusere på Scrum of Scrums da dette
princip hjalp team’et med at opnå langt bedre resultater som
team og resultat.
Afgrænsning
Der vil ikke blive fokuseret på processen Scrum eller princippet
Scrum of Scrums, og det er derfor forudsat kendskab til
processerne her beskrevet.
Analyse
I dette afsnit vil der analyseres hvorfor der er valgt metoden
Scrum of Scrums, samt fordele og ulemper og hvad der er lært af
processen.
Visionen for projektet
HR-systemet Orkide har tidligere haft envejs-integration til
lønsystemet MultiLøn Erhverv (MLE) via løsningen kaldet
”Broker”. For at skabe nye vækstmuligheder, tovejs-integration til
MLE, og at undgå meget høje nyudviklings omkostninger på grund
af Broker, er det ønsket at lave et HR-API som skal implementeres
i Orkide.
Derfor var det naturligt at nogle medlemmer skulle stå for at
udvikle dette nye API, og andre medlemmer som skulle
implementere dette nye API i Orkide, samtidigt med at håndtere
den eksisterende Broker løsning for ikke migrerede kunder.
Herefter kaldet API-team og Orkide-team.
Se et overblik over systemlandskabet under ”Overblik over
systemlandskab” på side 7.
Forord
Dette projekt er udarbejdet i
forbindelse med holdet
”SCRUM i projektledelse”, der
omhandler processen SCRUM
som ledelsesværktøj.
Projektet skal perspektivere
hvordan oplevelsen af Scrum of
Scrums har fungeret i
virksomheden Bluegarden.
Når der i denne rapport
henvises til Scrum, menes der
Scrum i forbindelse med
softwareudviklingsprocessen.
▪▪▪▪
Indledning
Firmaet Bluegarden har et IT-
projekt der involverer at udvikle
et API der udstiller HR-data og
forretningsregler, og
implementere brug af dette API
i HR-løsningen Orkide.
Projektet indebærer herudover
tilretning i systemet Orkide
således det kan håndtere
konverterede kunder og
eksisterende kunder,
datavask/datakonvertering,
samt test af alle ovenstående
processer er korrekt udført med
ønsket resultat.
Grundet arbejdsbyrden er
teamet på 13 personer, og efter
kun få antal sprints blev det
besluttet at køre Scrum of
Scrums, og de erfaringer der er
blevet gjort vil blive beskrevet i
denne rapport.

3. Indholdsfortegnelse
Forord................................................................................................................................................................ 1
Indledning.......................................................................................................................................................... 1
Forord................................................................................................................................................................ 1
Indledning.......................................................................................................................................................... 1
Problemformulering.......................................................................................................................................... 1
Metodevalg........................................................................................................................................................ 1
Afgrænsning ...................................................................................................................................................... 1
Analyse .............................................................................................................................................................. 1
Visionen for projektet.................................................................................................................................... 1
Opstart af Scrum teamet............................................................................................................................... 2
Scrum of Scrums rammer.............................................................................................................................. 2
Taskforce -boardet .................................................................................................................................... 2
”No man down”............................................................................................................................................. 3
Fokus, viden, og effektivitet .......................................................................................................................... 3
Daily standup & Scrum of Scrums-møder ..................................................................................................... 4
Synlighed & gennemsigtighed....................................................................................................................... 4
Konklusion ......................................................................................................................................................... 5
Perspektivering.................................................................................................................................................. 5
Bilag ................................................................................................................................................................... 6
Definition of Scrum of Scrums....................................................................................................................... 6
Synonymer for Scrum of Scrums ................................................................................................................... 6
Model for Nexus / Scrum of Scrums.............................................................................................................. 7
Overblik over systemlandskab....................................................................................................................... 7
Referencer......................................................................................................................................................... 7
Definition af Scrum of Scrums....................................................................................................................... 7

4. SDF
14. oktober 2016 Laurits West
Scrum i projektledelse
› Det starter og slutter med mennesker Side
Sdf
2 af 9
Opstart af Scrum teamet
På trods af teamet består af 13 teamdeltagere, og det er anbefalet at holde et team under 7 ± 2 deltagere,
så startede man op som et fælles team. Dette var med henblik på at opbygge one team-mentalitet, og
skabe stærke teamrelationer, da flere medlemmer ikke var bekendte med Scrum og Scrum’s principper.
De første sprints foregik Sprint planning-møderne med et fælles tema for begge grupperinger (fx Employee
eller Employment eller sikkerhed), og det var muligt at arbejde uden om afhængigheder.
Så længe der var dette fælles tema var alle 13 medlemmer engagerede i det fælles mål for sprintet, men
det blev hurtigt tydeligt at API-teamet måtte bruge længere tid på at implementere forretningsregler, end
det tog Orkide-teamet at implementere disse endpoints1
. Det var derfor nødvendigt at API-teamet måtte
fokusere på at udvikle og stabilisere områder før Orkide skulle implementere disse områder.
Til Retrospective-møderne blev det tydeligt, at et samlet team ikke fungerede, og det blev besluttet at
prøve Nexus-frameworket, også kaldet Scrum of Scrums. Dette følte alle var nødvendigt da flere teams
arbejder på samme produkt, og der var tydelige afhængigheder teams imellem, som i et leverandør-
forhold. Der måtte formaliseres nogle rammer for at planlægge afhængigheder for at kunne planlægge
effektive sprints, og kunne sikre forsat stabil fremgang.
Scrum of Scrums rammer
Hvert team besluttede sig for at have samme sprintlængde, og sideløbende sprint, da man med samme
start/slut-tidspunkt nemmere kan planlægge i forhold til hinanden, og reagere på input fra Retrospektive-
møderne i det kommende sprint. API-teamet ønskede at køre digitalt Scrum-board i TFS, hvor Orkide-
teamet ønskede at køre fysisk tavle.
Taskforce -boardet
Det fælles Scrum of Scrums–møde blev besluttet at holdes ved en fysisk tavle, inddelt i domæne-områder
der hver havde 3 prioritetsområder – som blev navngivet Taskforce-boardet.
Prioritet 1
Stopper et teammedlem i at fortsætte enten udvikling, eller test af et område og skal løses
hurtigst muligt.
Prioritet 2
Vil være kritisk inden for kortere tid. Bruges typisk for at påpege en afhængighed som vil
blive aktuel inden for kort tid.
Prioritet 3
Er nødvendig for at kunne lave en fuldendt release, men kan udføres senere. En huskeliste
til MUST-HAVE-fokus områder.
Synlighed fra Taskforce-boardet
Begge teams er glade for synlighed og gennemskuelighed i processen, som fortsatte ved dette board.
Hver task/bug på tavlen skulle noteres på tavlen med en post-it i en af to kontrast-farver, for at kunne nemt
identificere mængden af forskellig prioritet task/bug’s til de respektive teams.
1
Endpoint: Definerer et forbindelsespunkt I form af en adresse/url, med ønsket funktionalitet.

5. SDF
14. oktober 2016 Laurits West
Scrum i projektledelse
› Det starter og slutter med mennesker Side
Sdf
3 af 9
Hver post-it seddel skal have en kort sigende overskrift, et task/bug-nummer. Til Scrum of Scrums mødet
tildeles en ansvarlig fra det respektive team som skrives ved siden af sedlen. Dette er i tilfælde af fravær,
hvor det er det nemmere at udskifte ansvarlig på kritiske opgaver.
Dette giver også teamet synlighed for hvor stor en arbejdsbyrde der er tilbage.
Hvis der mandag hænger 20 røde sedler i prio 1, og fredag hænger 19 tilbage, viser det at enten er der ikke
blevet løst ret mange bugs, eller også er der løst en del bugs, men der er blevet opdaget tilsvarende flere.
Det er således nemmere for teamet at føle om de kommer tættere på målet eller ikke.
Hvis en enkeltperson har flere opgaver inden for samme område og prioritet, prioriteres opgaverne ved at
placere dem under hinanden for den ansvarliges navn. Således ved hver person hvad der mest kritisk af
prioritet opgaver, der skal løses. Dette skal også hjælpe teamet med at nemt at belyse problemområder
hvor specialister har for mange opgaver simultant, og dermed lade andre overtage opgaver.
Hvert område på tavlen får så skrevet en procentsats som begge teams mener er hvor tæt på ”done” man
er. Dette giver en synlighed af hvor mange kritiske opgaver der er tilbage (post-it’s), og hvor langt man er
ud over de kritiske opgaver (procent). Denne evaulering foretages af alle roller, både UX’ere, udviklere og
testere fra begge teams som kender hver deres respektive område og eventuelle mangelområder.
Dette sikrer at man kommer rundt om alle områder og sikrer alt er færdigt i alle rollers øjne.
Uden for tavlen er der bugs og tasks, som ikke er kritiske for leverancen eller er stoppende for
teammedlemmer i teamsene, men task-force boardet er kun til at give et overblik over det mest vigtige lige
nu, på kort sigt og inden samlet release.
”No man down”
Da der var stærke afhængigheder fra Orkide-teamet til API-teamet om at delområder skulle være færdige
før andre områder kunne påbegyndes eller færdiggøres, blev det aftalt at begge team skulle fokusere på at
ingen personer skulle forblive unødigt længe i en afventende position. Dette kaldte vi for ”No man down”.
Dette blev aftalt ud fra et udvikler-behov, men senere viste det sig at hjælpe også over for testere som blev
begrænset fra at udføre yderligere test før en given fejl blev rettet. Dermed blev det synligt for alle hvad
der skulle fokuseres på og alle kunne være effektive og levere værdi til projektet.
Fokus, viden, og effektivitet
Det blev meget tydeligt til backlog refinement, sprint planning at ved at dele fysiske teams var alle langt
mere effektive. De fleste møder blev startet fælles, og derefter dele sig i de respektive teams for at
gennemgå detaljerne for det enkelte team, med et forventet sluttidspunkt til samling, som kunne
forlænges efter behov.
Derefter mødes begge teams for at kort fremlægge planerne for hinanden, med stærk fokus på
afhængigheder til modsatte team. Dette er både tidsmæssige og funktionsmæssige, således at når en
opgave kræver 50 timers udvikling, men har en afhængighed så kan man allerede ved sprint start fortælle
at opgaven den er er afhængig af, senest skal være færdig dato x, da denne opgave ellers ikke kan
gennemføres til tiden. Dette giver alle deltagere et klart billede af forventningerne til sprintet og afviklingen
for at man kan se om det er realistisk både med tid, og opgaver fordelt på individerne. Derudover er det
tydeligt for hvert team, at vise hvad de har behov for af det modsatte team, for at færdiggøre det planlagte
i sprintet.

6. SDF
14. oktober 2016 Laurits West
Scrum i projektledelse
› Det starter og slutter med mennesker Side
Sdf
4 af 9
Efter disse afhængigheder var blevet påpeget, begyndte man internt i teamet at udpege flere af disse
afhængigheder – bl.a. hvornår skal UX senest have detaljer på plads for at det kan udvikles i indeværende
sprint? For at område/funktionalitet kan testes, hvornår skal det så være færdigudviklet og klar til test?
Ved denne logiske opdeling fik hver teammedlem mere fokus, da man her kun så på opgaver man selv var
involveret i og havde indflydelse på, og dermed tog langt større ejerskab. Derudover var meget
domæneviden forankret i teamet, som gjorde det enkelte team langt mere effektive til at vurdere
indflydelsen på det som teamet skulle løse. Prioritering blev nemmere, da teamet havde indflydelse for
egne arbejdsopgaver, og derfor havde en aktiv interesse i prioriteringen blev korrekt.
Daily standup & Scrum of Scrums-møder
Til daily standup gjorde det en enorm forskel at gå fra en gennemgang på 13 personer, til 2 møder med 6 og
7 personer. Deltagerne var langt mere engagerede, da de detaljer de blev præsenteret for var relevante for
deres arbejde den pågældende dag. At kunne holde fokus på egne områder er et stærk værktøj for
teammedlemmerne og holder dem ”på sporet” og sørger for de ikke bliver forstyrret med unødige detaljer.
Til standup på hvert team deltager altid en ambassadør fra det modsatte team for at have et indblik i hvilke
udfordringer det modsatte team har i øjeblikket, og kan give ro og klarhed for de resterende medlemmer
på ambassadørens eget team, hvis der opstår tvivl omkring hvad ”de andre” laver.
Hvis API-teamet kæmper længe med sikkerhed, eller en database-server driller, kan dette fortælles til
Orkide-standup hvis flere er irriterede over manglende fremgang på områder. Dette giver klarhed og
fjerner unødig snak om ”hvad grunden er”. Herudover giver det større teamspirit ved at ”være involveret”
og have indsigt i begge teams, og forhindrer os/dem-mentalitet.
Kl. 09.30 – 10.00 holdte ambassadører Scrum of Scrums-møde ved Taskforce-boardet for at fokusere på de
vigtigste problemer for dagen, som man således kunne tage med tilbage til sit eget daily standup møde.
Kl. 10.00 – 10.15 holdte Orkide daily standup, fordi disse kunne have prioriteret deres opgaver efter hvad
der blev besluttet ud fra Scrum of Scrums-mødet.
Kl. 10.15 – 10.30 holder API daily standup, fordi de kunne have fået input fra både Scrum of Scrums, og
Orkide daily standup til hvad der skulle fokuseres på.
Da begge teams er selvstyrende, blev det senere besluttet først at holde Orkide daily standup kl. 9.30 – 9.40
(mere kort og præcist), gå direkte til Scrum of Scrums (kl. 9.40 – 9.55) for at se på forhindringer, hvor
Orkide kunne få input fra hinanden fra daily standup som de kunne bruge til ønsker om prioriterer på
Scrum of Scrums-mødet. Herefter holder API deres møde (kl. 9.55 – 10.05), og kan tilpasse deres emner
efter input fra de to forrige.
Begge teams føler at denne nye struktur giver langt færre afbrydelser i deres arbejde, og det er nemmere
at få alle opgaver videregivet korrekt til API-teamet, som dermed nemmere kan prioritere opgaver der skal
løses nu, og inden for de kommende dage, for at ingen personer skal vente.
Synlighed & gennemsigtighed
Begge teams bruger burn down charts for at synliggøre deres fremgang i forhold til det forventede, hvor
det igen kan påpege afhængigheder fra Orkide-teamet til API-teamet – bl.a. ved sygdom, eller fejlrettelser.
Dette giver ekstern synlighed for alle interesserede, og optager ikke unødig tid fra teammedlemmer der
skal afrapportere status etc.

7. SDF
14. oktober 2016 Laurits West
Scrum i projektledelse
› Det starter og slutter med mennesker Side
Sdf
5 af 9
Konklusion
Ved at anvende metoden Scrum of Scrums til et team på 13 personer, og fordele dem i to seperate teams,
har det vist sig at begge teams i langt højere grad kan effektivisere tid, og skabe fokus2
, og herved opnå
langt bedre resultater.
Afhængigheder bliver langt mere synlige og nemmere at håndtere ved at benytte Scrum of Scrums, da
metoden tvinger teams til at kommunikere og samarbejde om de fælles udfordringer som stopper alle
teams om at komme i mål.
Både Orkide- og API-teamet har været glade for at lære om metoden Scrum of Scrums, der har hjulpet
begge til at opnå bedre resultater og blive high-performing teams.
Efter 3 sprints med Scrum of Scrums oplevede man til Retrospective at få udelukkende karakter 3 eller over,
ud af karakterer på 4 mulige fra begge teams.
Perspektivering
Under hele denne proces har begge teams indset flere ting som har kunne forbedres.
Som man kom tættere på det færdige produkt der skulle releases, kom der større og større fokus på at løse
bugs, og begge teams kunne se en fordel i at afsætte en fast tidsboks til bugfixing til hver udvikler på hvert
team. Dette gav et synligt fokus på at bugs skulle løses for at kunne helt færdiggøre områder, og ville have
været en fordel at begynde på tidligere i processen. Dette gjorde der blev afsat tid til at fokusere på at løse
bugs, og ved at bruge en tidsboks blev der ikke fyldt op med andre opgaver i sprintet, der kunne forhindre
tid til udførsel af bugfixing.
Ved ikke at holde daily standup for Orkide og API simultant, var det muligt for API med en repræsentant at
lytte på input fra Orkide, og dermed allerede have større fokus til deres daily standup om fokusområder.
Orkide havde ligeledes også en repræsentant med hos API for at følge med i arbejde og udfordringer.
Effekten af at forkorte Orkide’s daily standup med 5 minutter, og ændre rækkefølgen i møder, havde en
enorm effekt på at give alle projektdeltagere en ekstra form for ro, og følelse af at opnå mere og have
bedre tidsstyring. Før følte mange de ikke fik lavet noget før efter frokost, men det har dette ændret.
På tidspunkter i forløbet har der til tider været utroligt mange bugs, som gjorde det nødvendigt at have
flere ambassadører med til Scrum of Scrums møder på grund af domæneviden omkring et enkelt område.
2
Fokus er en af Scrums værdier.

8. SDF
14. oktober 2016 Laurits West
Scrum i projektledelse
› Det starter og slutter med mennesker Side
Sdf
6 af 9
Bilag
Definition of Scrum of Scrums
Synonymer for Scrum of Scrums
 “meta Scrum”
 Nexus modellen
 Scaled Scrum
A technique to scale Scrum up to large groups (over a dozen people), consisting of
dividing the groups into Agile teams of 5-10. Each daily scrum within a sub-team
ends by designating one member as "ambassador" to participate in a daily
meeting with ambassadors from other teams, called the Scrum of Scrums.
Depending on the context, ambassadors may be technical contributors, or each
team's Scrum Master, or even managers of each team.
The Scrum of Scrums proceeds otherwise as a normal daily meeting, with
ambassadors reporting completions, next steps and impediments on behalf of the
teams they represent. Resolution of impediments is expected to focus on the
challenges of coordination between the teams; solutions may entail agreeing to
interfaces between teams, negotiating responsibility boundaries, etc.
The Scrum of Scrum will track these items via a backlog of its own, where each
item contributes to improving between-team coordination.
KILDE: https://www.agilealliance.org/glossary/scrum-of-scrums/

9. SDF
14. oktober 2016 Laurits West
Scrum i projektledelse
› Det starter og slutter med mennesker Side
Sdf
7 af 9
Model for Nexus / Scrum of Scrums
Overblik over systemlandskab
Referencer
Definition af Scrum of Scrums
https://www.agilealliance.org/glossary/scrum-of-scrums/
Orkide
Broker
MultiLøn Erhverv
HR-API
HR løsning
Integrationspunkt
Lønsystem
Nuværende løsning
Nye løsning