Hur man närmar sig övergången från Scrum till SAFe

Att införa ett skalat agilt ramverk som SAFe

Att skapa fungerande Scrum-team är en utmaning i sig, och många organisationer har svårigheter med detta. När flera team är beroende av varandra och arbetar med samma produkt eller värdeflöde, behövs en starkare struktur.

Det är då nödvändigt att använda ett skalningsramverk som kan samordna Scrum-teamen. Ramverket ger processer och riktlinjer som gör att teamen kan synkroniseras, anpassas och hålla kursen.

En vanlig fallgrop är att teamen hamnar i silos, där fristående Scrum-team arbetar mot sina egna mål, utan att ha en tydlig bild av det gemensamma målet för hela programmet. Det är här Scaled Agile Framework (SAFe) kommer in i bilden.

Vad innebär SAFe?

Källa: scaledagileframework.com

SAFe är en metod som applicerar agila ramverk och processer på tidigare hierarkiska organisationer. Istället för att helt ändra organisationens struktur, lägger SAFe till ett extra lager på ett sätt som är bekant för många av de befintliga intressenterna.

SAFe bygger på flera kärnvärden:

Samordning

  • Alla Scrum-team måste ha en tydlig förståelse för visionen, strategin och det övergripande målet.
  • Strategin ska samordnas mellan teamen, så att de kan arbeta mot samma mål.
  • Kommunikationen med teamen ska ske på ett tydligt och enhetligt språk.
  • Det är viktigt att regelbundet kontrollera att teamen förstår målen och visionen.
  • Teamen måste vara kundcentrerade och förstå vilka kunderna är och deras behov. Strategin ska anpassas efter dessa behov.

Öppenhet

  • Skapa en arbetsmiljö där alla känner förtroende och kan prestera sitt bästa.
  • Var transparent med argument och fakta. Var ärlig och dölj inte viktig information.
  • Acceptera misslyckanden som lärotillfällen. Om något inte fungerar, inse det snabbt och lär av det. Justera strategin därefter.
  • Visualisera arbetet så att alla kan förstå.
  • Säkerställ enkel tillgång till relevant information.

Respekt för individer

  • Fokusera på vad det innebär att vara människa. Behandla inte människor som resurser.
  • Värdesätt mångfald och olika åsikter. Uppmuntra ärlig feedback.
  • Stöd medarbetarnas utveckling genom coachning och mentorskap.
  • Acceptera att kunden är den som konsumerar ditt arbete.
  • Bygg långsiktiga relationer inom och mellan teamen.

Ständig förbättring

  • Skapa en miljö där problemlösning motiverar teamen.
  • Reflektera över hur arbetet utfördes föregående vecka och identifiera förbättringsområden.
  • Använd fakta som det främsta argumentet för förbättringar.
  • Ge tid och utrymme för innovation. Låt teamen experimentera och testa nya vägar.

SAFe skapar ett samarbets- och kommunikationslager för skalade agila system. Det ersätter inte de individuella Scrum-aktiviteterna.

En central del av SAFe är Agile Release Train (ART). Det är ett långlivat, stabilt team av Scrum-team (ofta upp till 12) som regelbundet levererar inkrementella funktioner efter varje sprint. De utvecklar, levererar och stöder en eller flera lösningar inom ett värdeflöde.

Källa: scaledagileframework.com

Roller i SAFe

SAFe bygger på att individer har olika ansvarsområden. Det är avgörande att rollerna följs, vilket påverkar hur framgångsrik implementeringen av ramverket blir. Därför är det viktigt att förstå vilka roller som finns och deras syfte.

#1. Agilt team

Agila team är tvärfunktionella, vilket innebär att de har kompetensen att täcka hela området de arbetar med. De är självorganiserande enheter som definierar, bygger, testar, implementerar och släpper värdeökningar.

Varje agilt team har kompetensen att utföra det avtalade arbetet. Teamet genomför arbetet stegvis under varje sprint, vilket skapar förutsägbarhet. Förutsägbarhet är viktigt för att teamet ska kunna leverera konkreta mål inom en viss tid. Kommunikation och leverans är centrala värden som teamet ständigt ska utveckla.

Det agila teamet deltar i Program Increment (PI) planeringssessioner för att skapa user stories och planera dem i sprintar. Slutligen åtar de sig sina egna PI-mål.

Scrum Master coachar det agila teamet och faciliterar teammöten. Scrum Master tar bort hinder och skyddar teamet från yttre påverkan. Scrum Master deltar i Scrum-möten som en del av ART.

Produktägaren (PO) är en annan viktig teammedlem. PO representerar kundens röst och har ett direkt inflytande på user stories och deras prioritering. PO kommunicerar med andra PO:s för att definiera och prioritera user stories i teamens backloggar.

#2. Produktledning

Produktledningen arbetar ovanför Scrum-teamen och ansvarar för samordningen mellan teamen. Produktledningen har följande ansvarsområden:

  • Att uppnå affärsmål genom att säkerställa att utvecklingsteam skapar genomförbara och hållbara produkter och lösningar.
  • Att förstå kundens behov och säkerställa att produkterna uppfyller kundens förväntningar.
  • Att se till att det alltid finns tillräckligt med färdiga funktioner i backloggen.
  • Att stötta arbetsflödet genom programstyrning och in i programeftersläpningen.
  • Att bestämma omfattningen av nästa programökning genom att prioritera funktioner som teamen har skapat. Produktledningen har det yttersta ansvaret för att definiera nästa PI.

#3. Systemarkitekt / Ingenjör

Ingenjörsteamet analyserar och utvecklar det avtalade innehållet i user stories. De är expertdelen av teamet och har följande ansvarsområden:

  • Att skapa och underhålla en Architectural Runway så att nya funktioner kan använda de tekniska möjligheterna.
  • Att delta aktivt i planering av programinkrement. Att närvara under systemdemonstrationer i slutet av varje programsteg.
  • Att arbeta med agila team för att implementera nya arkitekturmöjligheter. Endast detta gör det möjligt för teamen att bygga nya funktioner.
  • Att hjälpa agila team att definiera designlösningar och beslut på hög nivå. Att föreslå alternativa lösningar och det bästa sättet att genomföra ”proof of concept”-aktiviteter inom de agila teamen.
  • De skapar en arkitektonisk ”landningsbana”, en definition av tekniska möjligheter som är redo att användas för de funktioner som de olika teamen definierar.

#4. Företagsägare / Intressenter

Det är team utanför Scrum-teamen, men de har en viktig roll i SAFe-ramverket i alla skeden av genomförandet.

Före PI-planering:

  • Ge input till eftersläpningsaktiviteter.
  • Delta i förberedande PI-planering vid behov.
  • Se till att affärsmålen är tydliga och godkända av viktiga intressenter, inklusive Release Train Engineer (RTE), produktledning och systemarkitekter.

Under PI-planering:

  • Ge affärssammanhang och vision för den kommande PI.
  • Delta i granskningen av planer och tilldela affärsvärde till teamens PI-mål.
  • Delta i ledningsgenomgångar och hjälp till att lösa problem som leder till godkännande av den slutgiltiga planen.

Efter PI-planering:

  • Delta aktivt i att upprätthålla affärs- och utvecklingsanpassning när prioriteringar och omfattning ändras.
  • Hjälp till att validera definitionen av Minimum Viable Products (MVP) för Program Epics och vägleda beslut om pivot eller fortsatt arbete baserat på leveransen av MVP.
  • Delta i systemdemonstrationer för att se framstegen och ge feedback.
  • Delta i agila teams sprintplanering och sprintretrospektiv vid behov.
  • Delta i releasehantering, med fokus på omfattning, kvalitet, distributionsalternativ, lansering och marknadsöverväganden.

#5. Release Train Engineer (RTE)

RTE organiserar aktiviteter för personer och team inom ART. Det är rollen som Scrum Master för hela programmet. Huvudansvaret är följande:

  • Att hantera och optimera värdeflödet genom ART.
  • Att skapa och kommunicera årliga kalendrar för sprintar och Program Increment (PI).
  • Att vara moderator för PI-planeringsmöten.
  • Att organisera team och hjälpa dem att skapa en sammanfattning av sina PI-mål. Att överföra teamens mål till de övergripande målen för PI-planen.
  • Att samla team för att kommunicera och lösa risker och beroenden.
  • Att skapa kontakt mellan produktledning, produktägare och andra externa intressenter för att samordna strategin.
  • Att organisera workshops för ”Inspect and Adapt” för att kontinuerligt förbättra processer och aktiviteter.
  • Att utvärdera den aktuella mognadsnivån för agil metodik i teamen och definiera åtgärder för att förbättra teamens arbete.

#6. Ledarskap

Ledarskapet definierar programmets strategi och ger teamen de verktyg och det stöd de behöver. I slutändan definierar de systemet där alla andra arbetar. Därför är det viktigt att ha en ledningsgrupp som ger teamet rätt syfte och värderingar. Deras huvudsakliga ansvarsområden är:

  • Att föregå med gott exempel.
  • Att ha ett tillväxttänk.
  • Att betona värderingarna och principerna i SAFe.
  • Att utveckla medarbetare.
  • Att leda förändring.
  • Att främja psykologisk säkerhet.

Program Increment (PI) Planering

PI-planering är ett två till tre dagar långt evenemang där målet är att förstå och engagera sig i arbetet för nästa programsteg. Det kan till exempel vara under nästa kvartal.

Produktledningen prioriterar de funktioner som identifierats under PI-planeringen. Agila team ansvarar för kapacitetsplanering, skapande av user stories, uppskattning och åtagande för PI-målen.

PI-planering är avgörande för SAFe. Utan PI-planering fungerar inte SAFe.

PI-process

Källa: scaledagileframework.com

PI-planeringen startar med att samla in behov och idéer från olika arbetsflöden om vad de vill bygga. Dessa används sedan som indata till PI:

  • De 10 främsta funktionerna som ska implementeras.
  • ART-backloggen med färdiga epics eller funktioner.
  • Produktägarens vision.

Därefter startar diskussioner mellan olika arbetsflöden. Varje arbetsflöde presenterar sin vision och sina funktioner. De lyfter fram vad som är viktigt att implementera och vad de behöver för att lyckas. Det kan innebära:

  • Aktiveringar som levereras av andra arbetsflöden för att teamen ska kunna fortsätta med funktionerna.
  • Beroenden av andra arbetsflöden, vilket innebär att ordningen måste prioriteras.
  • Aktuella problem i systemet som måste åtgärdas innan arbetet kan fortsätta.
  • Bemanningsutmaningar inom teamet, med avsaknad av nyckelroller för att genomföra funktionerna.
  • Budgetbegränsningar som hindrar arbetsflödet från att uppfylla visionen inom tidsramen.
  • Andra risker, problem, antaganden eller beroenden som teamen kan identifiera, vilket kräver en bredare diskussion för att nå det gemensamma målet.

PI-genomgång

Själva PI-planeringen är ofta uppdelad på två till tre dagar, med följande agenda:

Dag 1

  • Diskutera affärsredogörelsen och kommande mål som utgör den övergripande programmets vision och strategi. Ledningen ansvarar för denna del och kommunicerar tydligt till teamet.
  • Placera alla funktioner från arbetsflöden på bordet och prioritera dem i linje med den gemensamma visionen.
  • Gå igenom arkitekturvisionen och definiera huvudmålen för utvecklingskraven. Lyft fram tekniska utmaningar och kom överens om hur man ska hantera hinder mellan teamen.

Dag 2

  • Förklara planeringsprocessen i detalj för teamen. Beskriv de förväntade resultaten efter avslutad PI.
  • Gör gruppindelningar där teamen för första gången skapar utkast till planer och identifierar hinder och risker.
  • När breakout-sessionen är klar presenterar och granskar teamen sina utkast till planer inför de andra teamen.
  • Nästa steg är en ledningsgenomgång där planerna gås igenom och vägledning ges för de problemlösningar som följer. Planerna justeras utifrån utmaningar, risker och hinder.

Dag 3

  • Börja dagen med att justera planerna baserat på gårdagens ledningsgenomgång.
  • Teamen kommer att ta fram de slutgiltiga planerna och förfina risker och hinder. Företagsägare tilldelar affärsvärde till teamets mål.
  • Därefter presenterar teamen de slutgiltiga planerna för hela publiken.
  • De återstående riskerna på programnivå diskuteras och ROAM (resolved, owned, accepted, mitigated) riskhantering tillämpas.
  • Teamen röstar på sitt förtroende för resultatet av programinkrementplaneringen.
  • Om rösterna är för få eller om det totala förtroendet är lågt, genomförs ytterligare planering.
  • Efter att PI-åtagandet är klart planerar RTE en retrospektiv för teamen, där de diskuterar hur planeringen gick och vad som ska förbättras till nästa gång. Ledningen ger en översikt om vad som händer framöver och slutliga instruktioner.

PI-resultat

Det slutgiltiga resultatet av PI-planeringen är en lista över funktioner som planeras att genomföras under de olika sprintarna inom nästa PI-period. Alla kända beroenden har en plan för hur man löser dem så att funktionerna kan fortskrida.

Teamen kommer att åta sig sina mål och omfattningar. Om det finns ytterligare mål som inte nödvändigtvis ingår i listan, behandlas de som ej åtagna mål. De kan potentiellt genomföras om tid och resurser finns.

Teamen dokumenterar och spårar alla risker för programmet och har en plan för hur de ska hanteras.

Teamen samlar också alla idéer från den retrospektiva sessionen och markerar dem som lärdomar inför nästa PI-planering.

För teamen specifikt finns det några konkreta förväntningar, som:

  • Teamen åtar sig mål med affärsvärden.
  • Teamen beräknar sin kapacitet per sprint för att bättre kunna uppskatta genomförbarheten av planens innehåll.
  • De tar även hänsyn till den faktiska belastningen per sprint.
  • User stories tilldelas konkreta sprintar för varje arbetsflöde baserat på tillgänglig kapacitet.
  • Teamen röstar på sitt förtroende för PI-planen och innehållet som ska levereras.

Slutsats

Det kan verka svårt även efter att ha läst fakta ovan, men jag kan bekräfta att det är extremt utmanande att omvandla en stor organisation till SAFe. I vissa fall kan det verka omöjligt. Även om man tillämpar grundläggande principer, krävs det många iterationer innan man kan säga att man verkligen är SAFe.

Ofta förstörs hierarkiska principer och gamla regler, som inte vill ge vika oavsett hur mycket man försöker. Det går att ha en omfattande PI-planering och resultat, men vad spelar det för roll om teamen inte arbetar på ett korrekt agilt sätt?

Det finns inte plats för hybrider här. Antingen är man fullt engagerad med rätt processer, människor och tankesätt, eller så är man inte med om inte alla delar av metoden efterlevs.

Innan du ens överväger att implementera SAFe, se till att du behärskar de agila principerna. Låt teamen rösta och ge ärliga åsikter. Du kan bli överraskad över resultatet.

Utforska bra utbildningsresurser för agil certifiering.

Var den här artikeln hjälpsam?

Tack för din feedback!