Scrum med flera team

Att organisera flera Scrum team görs på en hel del olika sätt. Här beskriver vi likheter och skillnader mellan några av de ramverk som vi har stött på hos våra kunder och utbildare, LeSS, SAFe och Scrum@Scale.

Gemensamt för LeSS, SAFe och Scrum@Scale

I alla tre ramverken utgår man från att man i botten har vanliga Scrum-team som är tvärfunktionella och självorganiserande.

Man utgår också från att vi alltid försöker bryta ner kraven vertikalt, så att varje inkrement blir så litet som möjligt men ändå kan driftsättas separat.

Underförstått är även att man kör kontinuerlig integration och automatiserad regressionstestning, och att man efter varje sprint har en produkt som går att driftsätta ifall man så väljer.

LeSS (Large-Scaled Scrum)

LeSS är ett skalningsramverk som kommer från Craig Larman och Bas Vodde och baserar sig på det jobb de gjorde inom finans- och telekomindustrin.

Minimalism och minsta möjliga process är något som genomsyrar hela LeSS. Lägg till så lite process som bara är mjöligt för att få fler team Scrum att fungera. LeSS består av ett minimalt antal regler och sedan tillkommer det en hel del guider och exempel på tillämpningar som man kan ösa ur i takt med att man växer.

I grund och botten är LeSS ett förtydligande av hur Scrum är tänkt att fungera. Till exempel förtydligas det att teamen ska vara tvärfunktionella featureteam som är långlivade även över flera projekt och sitta tillsammans. Tanken är att hantera den komplexa situation storskalig utveckling utgör genom att förenkla så mycket det bara går. Därför föreslår LeSS att team kör synkroniserade sprintar och det finns en produktägare och en produktbacklog gemensamt för alla teamen.

En produktägare men en produktbacklog och flera team, med var sin sprintbacklog.

Det kan tyckas omöjligt att en enda person ska klara av att vara produktägare för upp till åtta team, men filosofin i LeSS är att genom detta så kan den personen inte lägga sig i så mycket detaljer och behöver istället överlämna mer till teamen att ta reda på. Detta gör att utvecklarna tvingas komma närmare användarna vilket ger dem bättre förståelse för sina användares vardag, deras behov och problem. Genom detta får man högre engagemang och mer anpassade lösningar med högre kvalitet och man arbetar effektivare. “Get more with LeSS” helt enkelt.

Översikt över LeSS med synkroniserade sprintar.

Processmässigt följer LeSS vanlig Scrum (tidsboxade iterationer, sprintplanering, dagliga scrummöten, sprintgranskning och återblicksmöte) med det tillägget att sprintplaneringens första del görs aning annorlunda: Under första delen träffas representanter från teamen och produktägaren för att välja ut vilka saker som de tror kan göra klart under sprinten. Andra delen av sprintplaneringen ägnar teamen åt att planera hur de ska utveckla funktionerna, precis som för vanlig Scrum. Eventuellt kan detta förlänga sprintplaneringen med någon timme.

Gemensamt sprintslut med alla team i LeSS

Även sprintslut behöver synkroniseras. Detta görs genom att Sprint Review är gemensamt för samtliga team. Retrospective delas upp i två delar på liknande sätt som Sprint plannering, genom att varje team först har ett team retrospektiv. Och sedan har man ett gemensamt retrospektiv med representanter från samtliga team där man tar upp saker som inte går att lösa på enskild teamnivå.

LeSS Huge

Om vi har fler än åtta scrumteam delas produktbackloggen upp i olika kravområden med 4-8 team i varje. Varje område har då en områdesproduktägare (eng: area product owner) och en backlog precis som för vanlig LeSS. Rollen produktägare finns kvar och denne ansvarar för alla områden tillsammans. Processen (sprintplanering, daglig Scrum, granskning och återblick) körs på både övergripande och produktområdesnivå.

Produktägare med sina områdesproduktägare och deras team.

SAFe

SAFe är ett ramverk som kommer från Dean Leffingwell. Version 1 kom 2011 och 2016 var ramverket uppe i version 4. Vi antar att ramverket fortsätter att utvecklas. Texten nedan baseras på SAFe version 4.

Organisation

Det centrala i SAFe är att dela upp arbetet i värdeströmmar. En värdeström är de återkommande steg som sker i ett företag för att löpande leverera värde till kunder och användare. I en värdeström kan typiskt mellan 5 och 15 team jobba ihop. Denna gruppering av team kallas releasetåg. Ett releasetåg kan innehålla upp till 150 personer. Därefter rekommenderas det att ha flera Agila releasetåg inom samma värdeström.

Agila releasetåg är alltså en organisationsform, och releasetågsingengör är en faciliterande coachande roll, som i andra organisationer ibland kallas Agile coach.

Process

Inom det Agila releasetåget jobbar teamen enligt vanlig Scrum men SAFe tillför också programinkrement vilket är en överliggande planeringshorisont på typiskt 10 veckor även om kortare och längre intervaller förekommer. Skaparna av SAFe rekommenderar en planeringshorisont på mellan 8 till 12 veckor baserat på deras erfarenheter inom området.

Vecka för vecka hur sprintar och programinkrement hänger ihop.

Produktinkrementet börjar med storrumsplanering, ett evenemang på 1-2 dagar då teamen tillsammans planerar de närmsta 10 veckorna. Typiskt börjar mötet med att produktcheferna sätter visionen följt av att teamen gör planeringen och löser beroenden sinsemellan. Om oklarheter uppstår finns produktcheferna hela tiden på plats för att omedelbart fatta beslut. Produktinkrementet faciliteras av en releasetågsingenjör.

För att få en balans mellan förutsägbarhet, tekniska behov och flexibilitet föreslår SAFe två saker:

Planera inte sista sprinten i produktinkrementet utan spara den sista sprinten till att göra klart saker som inte hunnits med och till att hjälpa produktägare planera kommande inkrement och utöver detta testa nya saker.
Fyll inte sprintarna till 100% utan snarare 30-70%. Detta för att ge rum åt att rätta defekter, användarsupport och annat oförutsägbart. Det ger också utrymme för att göra saker som produktledningen tar för givet görs, men som ofta inte får någon dedikerad tid, t.ex. uppgraderingar av verktyg och anpassningar till nya plattformar.

Ett typiskt scrumteam har tre typer av saker i sin sprintbacklog. Buggar som går före allt, saker från storrumsplaneringen, samt sådant teamet vet borde göras men ingen annan har egentlig insikt eller åsikt om (t.ex. uppgradering av operativsystem eller databaser).

Portföljhantering

För att säkra att företagets alla initiativ syftar till samma mål har SAFe en portföljnivå. Där jobbar arkitekter, portföljhanterare och initiativägare tillsammans utifrån den strategi och vision företagsledningen tagit fram. De håller reda på alla initiativ med hjälp av en Kanbantavla som innehåller både möjliggörare (d.v.s tekniska initiativ som underlättar framtida utveckling) och affärsinitiativ (d.v.s. funktioner som kunderna direkt märker). På portföljnivå har man kontroll över hela kund- och användarprocessen, från idétratten till lanserad funktionalitet. När en epic hamnar i statusen “portföljbacklog” är den en kandidat för att brytas ner och hamnar i backloggen som en eller flera förmågor/funktioner. De epics som helt eller till del utvecklas i ett produktinkrement samlas i kolumnen “implementation”. Sammanställning av SAFe i en bild som beskriver de tre nivåerna (storskalig SAFe har även nivån “värdeström” som ligger mellan portfölj- och programnivån), vilka roller som typiskt finns på varje nivå, deras arbetssätt och vad kraven kallas på respektive nivå.

Många roller är det

Vid en första anblick kan det kännas övermäktigt med alla roller, nivåer, möten och artefakter. Detta gör att det finns risk för att man gör en SAFe implementation som blir både stel och tung. Men man bör skilja på individ och roll. En person kan med fördel ha flera roller och rollerna i bilden ovan kan bemannas av ett fåtal personer. Om man har en bra förståelse för de grundläggande principerna i Lean och Agile kan man anpassa SAFe och få till en både smärt och smidig implementation

Scrum@Scale

Scrum@Scale kommer från en av Scrums grundare, Jeff Sutherland, och är ett ramverk på metanivå. Det tar upp vilka områden som behöver lösas för att få Scrum att skala. Man skulle kunna se det som en lista med diskussioner som man behöver ha när man bestämmer sig för sin process. Beroende på i vilket företag som man försöker skala, så kan svaret hamna i något som till exempel liknar SAFe, LeSS eller i en helt egen metod.

Områdena är uppdelade i produktägarcykeln (yttre) och scrum mastercykeln (inre) samt några principer kring mätvärden och transparens. Bild med tillstånd från Jeff Sutherland och Scrum Inc.

Produktägarcykeln

Strategisk vision – Vart ska vi med företaget och våra produkter?
Prioritering – Vad är viktigast för oss på företagsnivå / portföljnivå och inom projekt?
Nedbrytning och förfining av krav – Hur fördelas arbetsuppgifterna mellan teamen och hur genomför vi sessioner för förberedelse av dem?
Releaseplanering – Hur ska vi planera för våra leveranser? Vad kommer när?
Releasehantering – Hur synkar vi mellan team för att få till smärtfria lanseringar?
Återkoppling av releasen och produkten – Hur får vi återkoppling från användandet och mottagandet av det som lanserats och hur får vi ut den informationen till teamen?

Scrum mastercykeln

Koordinering mellan team – Hur koordinerar vi mellan olika Scrum-team så vi inte båda gör samma sak eller snubblar över varandra?
Ständig förbättring och borttagning av hinder – Hur säkrar vi att alla team är medvetna om sin förmåga och ständigt försöker förbättra den? Hur säkrar vi att det som teamen kommer på blir löst även om det gäller problem som ligger utanför deras sfär av påverkan?

Utanför dessa två cykler finns även

Mätetal och transparens – Hur ska vi mäta att vi bygger rätt saker och hur vi ser vi till att alla har tillgång till dessa mätvärden?

I vissa organisationer kan det vara väldigt svårt att få till vissa förbättringar om inte personer med beslutsmandat engagerar sig. Därför föreslår Scrum@Scale att företag sätter upp en grupp av beslutsfattare (eng: Executive action team) som tar tag i de förbättringar som teamen, produktägare och scrum masters inte själva har möjlighet att genomföra.

SAFe, LeSS eller Scrum@Scale eller något eget?

Oavsett vilket ni väljer så kommer ni att behöva ändra och komma på egna lösningar då ingen företagskultur är lik en annan.

LeSS är en bra startpunkt när man har Scrum på plats och börjar skala upp med fler team, ett i taget.

I LeSS skalar man upp med minimal extra process jämfört med ett-team Scrum. Som jämförelse kan man kan säga att SAFe är mer ett komplett ramverk, och sedan tar man bort det som inte behövs.

Två exempel på anledningar att välja SAFe före LeSS:

Man behöver koordinera en väldigt stor organisation av hundra- eller kanske tusentals människor. SAFe ger en tydlig väg framåt här för hela kedjan från företagsstrategi till produktstrategi till taktik till vad vi skall göra nästa sprint.
Man är utan någon djupare erfarenhet av agil utveckling och vill ha ett ramverk med förslag på hur man kan hantera nästan varje aspekt av en helt agil organisation. SAFe har mycket “så här kan man göra” beskrivet.

Scrum@Scale ser vi mest som ett diskussionsramverk som är användbart för de som redan idag har flera scrumteam på plats och som fungerar tillsammans. Men som gärna vill hitta saker och områden att förbättra och att föra diskussioner kring. Alternativt om du själv vill beskriva er process, så kan du utgå från Scrum@Scale för att inte missa något perspektiv.

Som alltid när det gäller agilt så är det viktigt att anpassa metoden efter era förutsättningar, att ständigt reflektera över situationen och förbättra hur ni jobbar tillsammans.