Laurits West - S160268- Scrum i Projektledelse

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

SDF

14. oktober 2016 Laurits West


› Det starter og slutter med mennesker

Side Sdf

1 af 9

Eksamensprojekt for


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.

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

SDF




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.

SDF




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.

SDF




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.

SDF




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.

SDF




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/

https://www.agilealliance.org/glossary/scrum-of-scrums/

SDF




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

https://www.agilealliance.org/glossary/scrum-of-scrums/

Documents

Laurits West - S160268- Scrum i Projektledelse