Vad är det skalade agila ramverket (SAFe)?

Varför är SAFe^® användbart? 

SAFe erbjuder organisationer en vägledning (eller färdplan) som hjälper dem på vägen mot tillväxt. Ramverket introduceras på teamnivå och sträcker sig ända upp till den högsta ledningen, portföljnivån eller programnivån. 

Utöver färdplanen finns det särskilda utbildningar som organisationer kan delta i. SAFe erbjuder en djup kunskapsbas för särskilda agila roller som Scrum Master, produktägare, arkitekter och det agila teamet som helhet.

Är SAFe^® en metod eller ett ramverk?

Som framgår av själva namnet är SAFe ett mycket anpassningsbart ramverk. Eftersom det används av minst 1 000 000 yrkesverksamma och 20 000 företag globalt skulle SAFe sannolikt inte ha fått samma breda genomslag och globala spridning om det hade varit en rigid metod.

Med det sagt är detta en mycket vanlig fråga, eftersom metod och ramverk i vardagligt språk ofta används synonymt. För att stödja mitt svar på frågan är det därför bra att ha Michael Woods ord i åtanke från hans artikel om metod kontra ramverk:

I allmänhet skapar ramverk en struktur för vad som ska göras, men överlåter åt den som utför arbetet att avgöra det bästa sättet att genomföra detta, medan en metod beskriver allt i detalj: vad som ska göras, när det ska göras, hur det ska göras och varför.

Michael Wood

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Create Free Account

Have an account? Log In

SAFe^®-principer

Eftersom SAFe ger organisationer ett sätt att skala upp agilt arbete i takt med att organisationerna växer, är grunderna i linje med agil produktutveckling, Lean-produktutveckling och systemtänkande. Det ger vägledning inte bara för ett agilt team, utan för ”team av team”.

Det finns 10 Lean-agila principer som ramverket bygger på:

1. Ta ett ekonomiskt perspektiv: Fokuserar på konceptet att leverera värde till kunder tidigt och ofta. Att ta ett ekonomiskt perspektiv belyser också behovet av att beakta alla kostnader (risk, tillverkning, drift, utveckling) och att verka inom godkända budgetramar
2. Tillämpa systemtänkande: Kräver en förståelse för de system där organisationen som skapar lösningen är ett system och där lösningen också är ett system (projektet, produkten)
3. Utgå från variation; bevara alternativ: Kretsar kring konceptet att inte besluta om en enda designuppsättning eller uppsättning krav tidigt i utvecklingen, utan i stället ha flera designalternativ och kravuppsättningar och använda faktiska data (från experiment och tester) för att begränsa alternativen
4. Bygg stegvis med snabba, integrerade inlärningscykler: Följer konceptet att leverera arbete i mindre (och mer frekventa) delar och bygga vidare på det tidigare arbetet
5. Basera milstolpar på objektiv utvärdering eller fungerande system: Utvärdera arbete under utveckling vid olika tidpunkter under hela den agila utvecklingslivscykeln för att bedöma om det som utvecklas kommer att ge ekonomisk nytta och vara ändamålsenligt
6. Visualisera och begränsa pågående arbete (WIP), minska batchstorlekarna och hantera kölängden: Som principen antyder fokuserar den på att sätta en gräns för det arbete som personer eller team har tilldelats vid en viss tidpunkt (för att inte överbelasta dem och säkerställa ett jämnt flöde i arbetet och leveransen)
7. Tillämpa en takt; synkronisera med planering över domängränser: Följer ett mönster för att samordna planeringen med andra team
8. Frigör kunskapsarbetares inneboende motivation: Förstå behovet av att ge autonomi, tydliga begränsningar och hinder samt skapa en kultur av engagemang för dina teammedlemmar
9. Decentralisera beslutsfattandet: För att kunna agera snabbt och leverera oftare måste besluten decentraliseras, så att de som står närmast arbetet får fatta besluten
10. Organisera efter värde: I stället för att organisera team kring specifika funktioner (exempelvis design, testning och så vidare) bör man organisera kring tvärfunktionella team samt kund- och affärsvärde.

Så implementerar du Scaled Agile Framework^® 

Steg 1: Ha rätt inställning

För att börja implementera SAFe måste en organisation vilja förbättra sin affärsmässiga agilitet och vara beredd att anta ett Lean-Agile-tankesätt.

Lean-Agile kombinerar övertygelser, principer och handlingar från Agile Manifesto och Lean-tänkande. Det är en omvandling från ett fast tankesätt till ett utvecklingsinriktat tankesätt där yrkesverksamma är redo att experimentera, inspireras av andra, utforska möjligheter, anta utmaningar och omfamna misslyckanden.

Målet med Lean är att leverera maximalt värde till kunderna på minimal tid och samtidigt erbjuda högsta möjliga kvalitet. Lean-tänkande kan definieras som:

• Specificera produktens värde
• Definiera en värdeström för varje produkt
• Skapa ett oavbrutet värdeflöde
• Låta kunden dra till sig värde
• Sträva efter perfektion

Steg 2: Definiera en värdeström 

En värdeström är en serie steg (och organisatoriska komponenter) som krävs för att leverera värde till en kund – från den första utlösande händelsen till mottagandet av den slutliga produkten eller tjänsten. Den är oerhört viktig när SAFe implementeras.

SAFe fokuserar på att optimera värdeströmmen för att skapa ett kontinuerligt värdeflöde genom att organisera människor kring värdeströmmar, så att personer och team arbetar sömlöst tillsammans i stället för i silor eller segment.

Om ett företag exempelvis tillverkar specialdesignade keramiska kaffemuggar för försäljning på sin webbplats kan en värdeström se ut så här:

I exemplet ovan organiseras alla processer som krävs för att leverera värde – från det att kunden lägger sin beställning på kaffemuggen tills leveransen tas emot – för att säkerställa att värdet flödar.

Steg 3: Konfigurera Agile Release Train (ART)

En Agile Release Train (ART) är en kombination av flera agila team. De byggs kring en värdeström och förväntas kontinuerligt leverera värde genom att utveckla lösningar som gynnar slutanvändare och kunden.

SAFe kretsar kring samordningen av flera agila team, och en ART omfattar alla personer som krävs för att utveckla, testa och distribuera produkten eller tjänsten. Den består vanligtvis av 50–125 personer eller 10–12 olika agila team (med en teamstorlek på 8 till 10 personer).

En ART är tvärfunktionell och innehåller alla personer och organisatoriska resurser som krävs för att utveckla, bygga och leverera en komplett uppsättning produkter eller tjänster till en kund. Beroende på organisationens storlek kan det finnas flera ART:er (tänk stora organisationer med fler än 500 personer).

Steg 4: Definiera olika roller i SAFe^®

Precis som i alla organisationsstrukturer krävs vissa roller, och de bör tilldelas. I SAFe liknar rollerna på individuell agil teamnivå dem i ett litet agilt team, men med några fler roller och intressenter:

• Scrum Master: faciliterar agila ceremonier och undanröjer hinder
• Produktägare: ansvarar för produktbackloggen och prioriterar posterna i den
• Medlemmar i Scrumteamet: slutför prioriterade backlogposter och leveranser för att skapa värde för kunderna
• Release Train Engineer (RTE): I en SAFe ART är detta programansvarig och samordnare för de agila teamen
• Systemarkitekter/-ingenjörer: I både tekniska och icke-tekniska organisationer bidrar systemarkitekter och ingenjörer till produkt- eller programvaruutvecklingen genom att tillhandahålla en stabil arkitektonisk grund för lösningen

Steg 5: Förbered en programbacklogg för Agile Release Train

Du har konfigurerat din ART och har nu flera agila team. För att samordna vad som ska utvecklas eller byggas skapar du en programbacklogg.

En programbacklogg innehåller funktioner, epics, användarberättelser, funktionalitet och arkitekturarbete (systemarbete) som krävs för att stödja värdeströmmen och skapa värde för kunderna. 

En gemensam backlogg kräver bidrag från många ART-roller, till exempel Release Train Engineer, produktägare och andra, såsom produktledningen och organisationens ledare. En produktbacklogg hjälper också till i nästa implementeringssteg, där man definierar vem som arbetar med vad och när.

Steg 6: Planering av Program Increment (PI) och ART-synkroniseringar

I det sista steget behöver du planera vem som utför arbetet och när. I SAFe kallas denna händelse planering av Program Increment (PI). Den är central i SAFe, genomförs regelbundet och är ett tillfälle att skapa samsyn i hela ART:n.

En PI kan vara hur lång eller kort som helst beroende på organisationens önskemål, men den pågår vanligtvis i 3 månader (12 veckor). Det möjliggör 6 tvåveckorssprintar som teamen behöver planera för. Detta görs vanligtvis med hela ART:n närvarande (ja, alla agila team).

På grund av omfattningen är PI-planering vanligtvis ett tvådagarsevenemang som omfattar:

• En presentation av affärssammanhanget, de strategiska målen och uppdraget
• Planeringssessioner i mindre grupper för de agila teamen, där de skapar sin plan med poster från teamets backlogg och den gemensamma programbackloggen
• Presentation av utkast till planer från alla agila team
• Ledningens granskning och diskussioner för problemlösning
• Teamens arbete i mindre grupper för att justera och slutföra planerna
• Presentation av slutgiltiga planer och en förtroendeomröstning
• Granskning av programrisker och omarbetning av planen (vid behov)

Efter att PI-planeringen har slutförts fortsätter samordningen och samarbetet. Regelbundet under hela PI:n träffas representanter för de agila teamen (produktägaren och Scrum Mastern) tillsammans med RTE:n för en ART-synkronisering, där de granskar de agila teamens framsteg och identifierar eventuella beroenden, problem eller hinder som kräver samordning. Detta kan ske med vilket intervall som helst under en PI, men varannan vecka (eller i slutet av varje sprint eller iteration) är en bra takt.

Vilka verktyg används i SAFe^®?

Eftersom SAFe använder andra agila metoder, såsom Scrum och Kanban, finns det ett antal verktyg som kan användas för att hjälpa agila team som arbetar med SAFe.

För några rekommenderade verktyg som kan användas för SAFe kan du börja med våra listor över agila verktyg och programvara för agil projektledning.

Eftersom PI-planering rekommenderas att genomföras på plats (ansikte mot ansikte) rekommenderas även följande verktyg:

• En stor lokal där hela ART kan samlas och arbeta i team
• Whiteboardtavlor eller stora blädderblockspapper
• Whiteboardpennor
• Post-it-lappar/klisterlappar (används för att representera objekt från teamets backlogg)
• Tilltugg & förfriskningar (för vem älskar inte tilltugg 😊)

SAFe^® & andra agila metoder

Jag hoppas att du uppskattade den agila festen och att träffa vår nya festgäst SAFe. Som du kanske har lagt märke till har SAFe faktiskt mycket gemensamt med några av de andra gästerna, till exempel Scrum och Lean. Det är början på en fantastisk relation!

Om din organisation växer och det blir allt mer komplicerat att hantera flera agila team kan du på samma sätt överväga att bjuda in SAFe till din fest. Om du har frågor är du välkommen att kontakta mig via LinkedIn eller Twitter.

För andra hybrida metoder för projektledning och verktyg kan du prenumerera på nyhetsbrevet från The Digital Project Manager. Vill du ha mer? Ta en titt på vårt medlemskap!

^®SAFe och Scaled Agile Framework är registrerade varumärken som tillhör Scaled Agile, Inc.