Når et Scrum-team bliver til mange, ændrer udfordringerne sig. Det er ikke længere kun et spørgsmål om at levere et sprintmål, men om at sikre, at flere teams leverer noget, der faktisk passer sammen, bliver testet i tide og kan sættes i drift uden drama.
Scrum of Scrums (SoS) er en enkel teknik til netop det: koordinering mellem flere Scrum-teams, uden at du bygger et tungt styringslag ovenpå. Den blev formuleret af Jeff Sutherland og bygger på en ret jordnær pointe: store leverancer lykkes sjældent uden tæt kommunikation om afhængigheder og blokeringer.
Hvad Scrum of Scrums er, og hvornår det giver mening
Scrum of Scrums kan ses som et “daily scrum på tværs”. Hvert delteam kører stadig deres eget Daily Scrum, men supplerer med, at én repræsentant (en ambassadør) mødes med repræsentanter fra de andre teams for at synkronisere.
— Du kan få dem tilsendt herunder! —
Det giver især mening, når I er over et dusin personer, eller når flere teams arbejder på samme produkt, samme release eller samme platform. Hvis teams reelt er uafhængige, kan SoS hurtigt blive endnu et møde, som ingen savner, når det aflyses.
En god tommelfingerregel er: Brug SoS, når der er reelle tværgående afhængigheder, fælles integration eller delte risici, som ikke bliver håndteret hurtigt nok i dagligdagen.
Vælg en SoS-struktur, der passer til jeres størrelse
Mange starter med ét fælles SoS-møde. Det fungerer fint for 3 til 5 teams. Når antallet vokser, bliver mødet nemt for langt, og så skal koordineringen organiseres i flere lag eller klynger.
Tabellen her kan bruges som beslutningshjælp, når I skal vælge struktur:
| Struktur | Hvornår den passer godt | Typisk faldgrube | Praktisk tip |
|---|---|---|---|
| Flad SoS (ét møde) | 3-5 teams, relativt samme domæne | For mange detaljer fra hvert team | Brug stram timebox og “parkering” af emner |
| Klynge-baseret SoS | Flere teams, tydelige moduler (fx backend, frontend, data) | Klynger optimerer lokalt og glemmer helheden | Aftal fælles kvalitetskrav og integrationscadence |
| Hierarkisk SoS | Meget store programmer med mange teams | Risiko for langsom eskalation og statuskultur | Hold hvert niveau fokuseret på hindringer og beslutninger |
Det er helt legitimt at ændre struktur undervejs. SoS er en teknik, ikke en organisationsreligion.
Ambassadører: vælg rigtigt og giv dem mandat
Ambassadøren skal kunne repræsentere sit team og samtidig tænke på det samlede flow. I nogle kontekster giver det bedst mening, at Scrum Master deltager. I andre, at en teknisk nøgleperson gør det. Nogle steder roterer rollen. Det vigtigste er ikke titlen, men effekten.
Hent vores bøger og skabeloner herunder
Det hjælper at være tydelig om, hvad ambassadøren skal kunne, før I starter. Overvej disse kriterier:
- Kender teamets sprintmål og aktuelle risici
- Har overblik over afhængigheder og kommende afleveringer
- Kan tage små beslutninger på stedet
- Kan sige “det ved jeg ikke, jeg vender tilbage” og faktisk vende tilbage
- Kan kommunikere kort og konkret
Giv også ambassadøren et klart mandat. Hvis repræsentanten altid skal “tage det med hjem og spørge”, bliver SoS langsom, og teams begynder at løse ting uden om hinanden.
Mødet, der ikke må blive et mini-vandfald
SoS-mødet skal være kort, forudsigeligt og fokuseret. Mange får god effekt med 15-30 minutter, 2-3 gange om ugen, ofte lige efter teamenes Daily Scrum. I perioder med høj integration kan det være dagligt, men lad behovet styre frekvensen, ikke kalenderen.
Start med en fast rytme, og hold jer til et simpelt format. En praktisk dagsorden kan se sådan ud:
- Runde pr. team: færdigt siden sidst, plan til næste møde
- Blokeringer: hvad stopper os, og hvem kan hjælpe
- Afhængigheder: hvad påvirker andre teams de næste dage
- Beslutninger: hvad skal afklares nu, og hvem ejer opgaven
- Parkering: emner der kræver en separat snak med færre deltagere
Nøglen er “parkering”. Hvis to teams skal diskutere en API-kontrakt i 20 minutter, så aftal et opfølgningsmøde med de relevante personer og kom videre i SoS. Mødet er et sted at opdage og fordele arbejde, ikke et sted at løse alt.
Én sætning, der ofte hjælper facilitatorkulturen: “Hvad er næste konkrete skridt, og hvem gør det inden hvornår?”
Afhængigheder: gør dem synlige, og håndtér dem løbende
De fleste SoS-problemer handler ikke om tempo, men om afhængigheder, der bliver opdaget for sent. Derfor bør SoS have et synligt sted, hvor afhængigheder registreres og følges op.
I praksis kan det være en fælles tavle, et simpelt spreadsheet, et Jira-dashboard eller en fysisk “dependency wall”. Formatet er mindre vigtigt end disciplinen: én ejer, én forventet leverance, én deadline, én status.
Tre konkrete greb gør en stor forskel:
- Fælles Definition of Done på tværs: Hvis “done” betyder noget forskelligt, ender I med halvfærdige leverancer, der ikke kan integreres.
- Fast integrationscadence: Aftal hvornår der merges, testes og deployes på tværs. Når integration er “noget vi gør sidst”, bliver SoS et krisemøde.
- Små serviceaftaler: Når Team A lover et endpoint til Team B, så gør aftalen konkret. Hvad leveres, hvornår, og hvordan kan B teste det tidligt.
Et enkelt eksempel: Frontend-teamet melder i SoS, at de om tre dage skal bruge et nyt felt i en API. Backend-teamet kan så enten prioritere feltet, tilbyde et mock-svar, eller aftale en midlertidig løsning. Pointen er, at problemet bliver synligt, mens der stadig er handlemuligheder.
SoS sammen med SAFe, LeSS og andre skaleringstilgange
Scrum of Scrums kan sagtens leve side om side med større rammeværk. Mange bruger SoS som den praktiske “synk”, mens andre møder håndterer planlægning på højere niveau.
I SAFe kan SoS minde om en del af ART Sync, hvor afhængigheder og impediments bliver koordineret. I LeSS vil man ofte forsøge at minimere behovet for koordinationsmøder ved at omorganisere teams omkring feature-leverancer, men selv dér kan et SoS-lignende møde være nyttigt i perioder med tung integration.
Hvis I allerede har flere skaleringsceremonier, så vær ekstra opmærksom på dobbeltarbejde: SoS bør være det hurtige forum, der fjerner blokeringer, ikke endnu et lag status.
Tegn på at det virker: mål det, uden at gøre det tungt
Du behøver ikke et stort KPI-system for at vurdere effekten. Et par enkle målepunkter og observationer kan fortælle meget, hvis I følger dem over nogle uger.
Start med at definere, hvad “bedre koordinering” betyder hos jer, og hold så øje med:
- Tid til at løse afhængigheder: fra problem nævnes til der er en aftalt løsning
- Antal overraskelser i integration: fejl og konflikter der først opdages sent
- Mødekvalitet: hvor ofte SoS ender i dybe diskussioner uden klare ejere
- Rework mellem teams: arbejde der må laves om pga. misforståelser
- Stabilitet i repræsentation: om de samme personer møder op og kan følge op
Hvis I ser bedre forudsigelighed og færre “vi vidste ikke, I var i gang med det”, er I på rette spor.
Et 30-dages indføringsforløb, der er til at styre
Indfør SoS som et eksperiment med tydelige spilleregler. Det øger chancen for, at mødet får legitimitet, og gør det lettere at justere formatet, når I lærer.
Aftal først formål, deltagere, cadence og timebox på én side papir. Så kan I køre et kort forløb, der bygger gradvist op:
- Uge 1: Vælg struktur, udpeg faste ambassadører, og opret en fælles afhængighedstavle
- Uge 2: Kør SoS 2-3 gange, med stram mødeledelse og parkering af detaljer
- Uge 3: Tilføj et simpelt dashboard for integration og vigtigste blokeringer
- Uge 4: Justér cadence, afklar mandat, og fjern det, der føles som status
Efter 30 dage har I typisk nok erfaring til at svare på to spørgsmål: Hvad skal SoS altid gøre, og hvad skal det aldrig gøre?
Typiske faldgruber og hurtige rettelser
Den klassiske fælde er, at SoS bliver et statusmøde for ledelse eller interessenter. Hvis det sker, mister teamrepræsentanterne lysten til at bringe problemer op tidligt, og så forsvinder hele ideen om hurtig koordinering. Rettelsen er ofte enkel: afgræns deltagere, hold fokus på afhængigheder, og lad status leve i dashboards.
En anden fælde er for skiftende deltagelse. Når forskellige personer dukker op hver gang, gentager I de samme samtaler, og opfølgning glider. Her virker det godt med faste repræsentanter og en tydelig backup, der også har kontekst.
Den tredje er, at SoS prøver at kompensere for utydelig produktretning. Hvis teams ikke er enige om mål og prioritet, kan SoS ikke “møde det væk”. Så skal I tilbage til produktstyring, fælles backlog-arbejde og en klar plan for, hvad der skal leveres sammen og hvornår.
— Du kan få dem tilsendt herunder! —
