Scrum-teamet bör bestå av upp till tio personer. Men vad ska man göra när en större grupp specialister behöver arbeta med ett projekt? Eller om organisationen beslutar att följa en agil ledningsmetod? För att lösa detta problem föreslog Scrum-utvecklarna Scrum@Scale. Det är en skala-fri arkitektur för att organisera hela team enligt Scrum-principer.
Skalning av Scrum – innehållsförteckning:
Introduktion
Så snart en organisation växer, uppstår nya typer av problem. Till exempel en minskning av anställdas effektivitet som orsakas av en komplex intern struktur, svårigheter med beslutsfattande eller riktlinjer. Företag som arbetar agilt på den lilla projektteamnivån ser ofta behovet av att skala upp.
Många företag klarar sig bra utan att skala Scrum. Även om många Scrum-team arbetar samtidigt, behöver de ingen samordning eftersom grupperna arbetar oberoende. Detta betyder dock inte att det är en multi-team Scrum. Behovet av skalning uppstår först när de flesta av organisationen arbetar med en produkt och kan synkronisera sina flera Scrum-team effektivt.
De flesta organisationer som antar agila ledningsmetoder i stor skala väljer SAFE-modellen, eller Scaled Agile Framework. Idag kommer vi dock inte att fokusera på SAFE utan vi kommer att diskutera en annan modell som kallas Scrum@Scale, eftersom det enligt den 15:e State of Agile-rapporten från 2021 är det näst bästa valet bland företag som väljer agilt.
Scrum@Scale
År 1996 arbetade skaparna av Scrum, Jeff Sutherland och Ken Schwaber, med ett stort projekt. När de gjorde det hade de problem med att hålla mindre team som arbetade i Scrum i synk. De kom på ett sätt att skala det, vilket de så småningom kallade Scrum@Scale.
Analogt med den officiella Scrum-guiden var Scrum@Scale-guiden, som definierar detta sätt att skala arbete som:
En ram inom vilken nätverk av Scrum-team arbetar enligt Scrum-guiden för att lösa komplexa adaptiva problem och kreativt leverera produkter med så mycket värde som möjligt.
Den grundläggande premissen för Scrum@Scale är enkelhet och effektivitet. Därför baseras dess verksamhet på en skala-fri arkitektur. Med andra ord, det använder Scrum för att skala Scrum. På så sätt blir ett scrum-team som består av individer som agerar som Produktägare, Scrum Master eller Utvecklare Scrum of Scrums: ett team som består av team.
Scrum of Scrums
Scrum of Scrums är ett scrum-team med personer som tar traditionella Scrum-roller. Men eftersom uppgiften för Scrum of Scrums är att integrera resultaten av arbetet från flera Scrum-team, behöver det ytterligare poster:
- Produktägare-team – en grupp av Produktägare som möts för att enas om prioriteringar och skapa en sammanhängande produktvision
- Chief Product Owner – Scrum-teamets Produktägare eller en person som enbart arbetar med Scrum of Scrums
- Scrum of Scrums Master – den person som övervakar effektiviteten hos Scrum of Scrums.
De möts vid samma Scrum-evenemang och använder liknande Artefakter.

Ytterligare skalning och Scrum@Scale-frågor
Den skala-fria arkitekturen av Scrum@Scale innebär att den möjliggör skalning mer än en gång. Om en organisation behöver samordna team på en ännu större skala kan den sätta upp Scrum of Scrums.
Men att skala Scrum, precis som vilken annan ledningsmetodik som helst, har sina brister, och i det här fallet är de liknande de för de grundläggande Scrum-team, bara att de är proportionellt större. Det är därför vi rekommenderar att arbeta ut detaljerna för samarbetet inom varje Scrum-team innan man börjar med Scrum i större skala. Vi föreslår att skala Scrum för erfarna team som har god kunskap och förståelse för värdena och arbetssätten i Scrum.

Skalning av Scrum – sammanfattning
Att skala Scrum är ingen barnlek. Det kräver att Scrum-teamet skickligt tillämpar Scrum-principer och synkroniserar sina uppgifter med andra Scrum-team. Därför är den grundläggande frågan att besvara: Behövs skalning? Bara för att det finns många Scrum-team i en organisation betyder det inte automatiskt att samordning av dem kommer att ge bättre resultat.
Om en organisation väljer att öka Scrum, får den en skala-fri arkitektur som kan förstärkas ytterligare. Men varje förstärkning åtföljs av en ökning av den nivå av komplexitet som Produktägare-teamet, Chief Product Owner och Scrum of Scrums Master måste hantera.
Om du gillar vårt innehåll, gå med i vår aktiva community av busy bees på Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Caroline Becker
Som projektledare är Caroline en expert på att hitta nya metoder för att utforma de bästa arbetsflödena och optimera processer. Hennes organisatoriska färdigheter och förmåga att arbeta under tidspress gör henne till den bästa personen att förvandla komplicerade projekt till verklighet.
Scrum Guide:
- Ordlista över grundläggande termer, roller och begrepp
- Vad är Scrum?
- Scrum-värden
- Hur implementerar man Scrum i ditt företag?
- Scrum-team - vad är det och hur fungerar det?
- Vem är en produktägare?
- De vanligaste misstagen hos en produktägare
- Vem är Scrum Master?
- De vanligaste misstagen av Scrum Master
- Vilka statistik och mätvärden bör Scrum Mastern följa?
- Utvecklingsteam i Scrum
- De vanligaste misstagen hos utvecklare
- Scrumartefakter
- Skalning av Scrum
- Sprint Backlog
- Vad är produktbackloggen?
- Vad är användarberättelser?
- Skapa den bästa användarberättelsen med INVEST
- De vanligaste misstagen i User Stories
- Användarberättelse Acceptanskriterier
- Uppskattning och Story Points i Scrum
- Planeringspoker
- Team Estimation Game
- Definiera inkrement
- Scrum-evenemang
- Vad är en Burndown-diagram?
- Fördelar och nackdelar med burndown-diagrammet
- Kanban-tavlor i Scrum och Scrumban
- Hastighet i Scrum - Utvecklingsteamets hastighet
- Daglig Scrum
- Sprintplanering
- Sprintgranskning
- Vad är en Sprint Retrospektiv?
- Vanliga misstag under en Sprint Retrospektiv
- Produktbacklogg vård
- Hur man skapar och tolkar ett burndown-diagram?
- Vad är Sprint i Scrum?
- Samarbete mellan Produktägare och Scrum Master
- Scrumteamets åtaganden - Produktmål, Sprintmål och Definition av klarhet
- Egenskaper hos en bra Scrum Master