1. Disposition
 Opstart af et scrum team
 Hvordan foregik det med et team?
 One team vs Scrum of Scrums
 Taskforce boardet
 Hvordan passer det med Scrum?
 Konklusion
 Empowerment - Hvordan skabes
lidenskab i medarbejderne?
 Perspektivering og tiden efter
17-11-20161

2. Opstart af et scrum team
 Under grooming/planning blev begge teams enige om et tema
17-11-20162
Employee
Employee
Emp.
Phone
Emp.
Reg/konto
nummer

3. Hvordan foregik det med et team?
17-11-2016 Scrum I projektledelse3
Sprint 37
Build server
Units tests
Emp. Reg/konto
nummer del 1
Swagger genering imod
API
Employee skærmbillede
(Stubbe data)
Sprint 38
Test automatisering
Emp. Reg/konto
nummer del 2
Employee skærmbillede
(Stubbe data)
Repository design
Datavask support
Sprint 39
Absence
Rolle mapping
Employee phone
Employee skærmbillede
(Tilrette igen)
Påmindelser
AFKLARING
Det blev tydeligt at
der var mange
afhængigheder.
Det blev tydeligt at
man kan stubbe sig
ud af meget, ind til et
hvis punkt.
Her blev det
besluttet at køre
Scrum of Scrums

4. One team
 Fælles tema
 Samlet planning
 Svært at estimere
 Manglende domæneviden
 Følte meget spildtid
 Manglende commitment
 Fokus på ”at komme i gang”, og
manglende forståelse af nødvendighed af
at definere målsætning for sprintet/scope
af opgaver/forventninger til funktionalitet
og at alle forstår at når API leverer X, så
er det muligt for Orkide at gøre Y, Z, etc.
Scrum of Scrums
 Hver sit team gik ud og plannede
 Kom tilbage og afklarede afhængigheder
 Afklarede forventninger (dato’er,
funktionalitet) til hinanden
 Estimering er nemmere
 Forståelse for sit eget domæne
 Skal løse opgaven selv og derfor skal det
være korrekt til planning
 Fælles fokus på at nå i mål – så ønske at
fjerne forhindringer for det modsatte team
fordi det giver større fremgang.
 Alle roller kan have afhængigheder til
dato’er/funktionalitet – udviklere for at kunne
implementere, testere for at kunne nå at
teste, UX’ere for at have et design færdigt
17-11-20164

5. Taskforce-boardet
Se udprintede billede
Scrum of scrums-møder har ingen fast struktur og
derfor måtte vi lave vores egen. Vores begov var
større end det beskrevet i teori’en.
• Domæne område indeling
• Prioritet 1, 2, 3  se side 2 i rapport.
• Procent færdig – alle roller ser på mangler.
• Ansvarlig – synlighed af afhængighed af
kerneressourcer og fremgang ved sygdom.
• Afhængighed i tid og funktionalitet for at nå i mål
• Synliggøre deadlines for at kunne gennemføre til
forventet tid (afhængigheder)
• Bugs – afsætte timebox for at sikre tid til bugs
(fremgang for testerne)
• ”No man down”
17-11-20165

6. Value Based Prioritization
Vi prioriterer hele tiden
hvad der er mest værdi
dagligt for at få værdi for
alle deltagere Collaboration
Samarbejde på tværs af
teams som om man er et
team
Self organization
Vi organiserer selv vores
møderækkefølge, tider, og laver
et taskforce board og tilføjer
ambassadører til modsatte teams
daily
Timeboxing
Fokus på at afsætte tid til
at teste områder af, men
også afsætte tid til at der
skal løses bugs
Imperical Process Control -
Transparency – sprint burn downs,
taskforce-board.
Inspection - inspirerer processen
Adaptation – vi tilpasser processen
Hvordan passer det med Scrum?

7. Konklusion
Efter 3 sprints med Scrum of Scrums var dommen til Retrospective:
3 eller over ud af 4 mulige.
1 = Rød sur smiley
2 = Gul smiley med lige mund
3 = Grøn almindelig smiley
4 = Grøn almindelig smiley med kongekrone

8. Empowerment – Hvordan skabes lidenskab i medarbejderne?
 Fordel at opdele i teams pga. fokus på egne opgaver giver
 Ejerskab for opgaven
 Korrekte estimater (Domæne viden)
 Fokus ved at kun skulle forholde sig til egne opgaver (API / Orkide)
 One goal – Alle arbejder hen imod samme mål
 Overtage fra hinanden når nødvendigt – fokus på endgoal (sprint og projekt)
 Working software over comprehensive documentation – selvdokumenterende kode
 One-team spirit med fokus på målet – selvom man er flere teams
 Ved at vi startede som et team blev alle et stort team, selvom vi senere blev flere teams
 Responding to change – Hver dag kunne man overtage opgaver fra en syg/overbebyrdet
kollega for at alle kan fortsætte og arbejde imod det fælles mål. Bugs kunne komme op i
prioritet foran aftalt funktionalitet.
17-11-20168

9. Perspektivering
 Vigtigt at afsætte bugfixing timebox
 Repræsentant fra modsatte team var
vigtig for afklaring af spørgsmål og
forståelse og større teamspirit
 Forkorte møder og ændre rækkefølge af
møder giver mindre forstyrrelser
 Flere ambassadører til Scrum of Scrums
pga. bugs til sidst
Tiden efter
 Tirsdag efter aflevering havde vi
retrospective med fokus på ingen
forstyrrelser og skærme teamsene
 Ny projektleder
 Fjerne møder = flere timer til udvikling
 Overveje Kanban fremover
 Scrums møder er gode ved usikkerhed og
opstart for at alle får talt alt igennem
 Kanban er bedre når opgaverne er
velkendte, og teamet er fasttømret, og
man får ”mindre” tid på møder
17-11-20169