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

Att implementera funktionella Scrum-team i en organisation är en utmaning i sig, och många misslyckas ständigt i detta steg. Men när du har flera mycket beroende team som arbetar inom samma produkt eller värdeström, behöver du något starkare.

Det är nödvändigt att använda ett skalningsramverk som täcker Scrum-teamen. Ge dem processer och regler att följa för att bli synkroniserade med varandra, anpassade och inte gå vilse på vägen.

Ofta hamnar man i Silo-team, vilket i princip betyder fristående scrum-team som jobbar mot sitt lokala mål men som knappt har en aning om det slutgiltiga gemensamma målet för hela programmet. Det är här Scaled Agile Framework (SAFe) kommer in i bilden.

Vad är SAFe?

Källa: scaledagileframework.com

SAFe är ett tillvägagångssätt som tillämpar ett agilt ramverk och processer på tidigare hierarkiska organisationer. Det täcker strukturnivåerna och processerna, men istället för att återskapa dem återinför det ett andra system på ett organiskt sätt som är bekant för de flesta av de befintliga intressenterna i det ursprungliga systemet.

SAFe är uppbyggt kring flera kärnvärden.

Inriktning

  • Alla scrum-team måste förstå visionen och strategin och vad som är det slutliga målet de marscherar mot.
  • Koppla ihop strategi mellan teamen och leda dem till gemensamt utförande.
  • Kommunicera med teamen med ett enhetligt gemensamt språk som de lätt kan förstå.
  • Kontrollera hela tiden om teamen förstår målen och visionen.
  • Teamen måste vara kundcentrerade och de bör förstå vem som är kunderna och vad de behöver. Uppdatera strategin för att återspegla det.

Genomskinlighet

  • Skapa en miljö där alla kan arbeta på sitt bästa och utan brist på förtroende.
  • Kommunicera öppet dina argument och fakta. Var direkt och ärlig och göm inte viktiga fakta inför lagen.
  • Misslyckas snabbt och gör misstag till lärostunder. Om något visar sig inte lyckas, inse det snart och lär av det. Ändra sedan din strategi.
  • Visualisera det arbete du bygger så att alla bättre kan förstå.
  • Ge enkel tillgång till nödvändig information.

Respekt för människor

  • Betona vad det innebär att vara människa. Behandla inte människor som resurser.
  • Värdesätt mångfald av människor och deras åsikter. Stöd ärlig feedback.
  • Växa och utbilda människor genom coachning och mentorskap.
  • Omfamna att din kund är den som konsumerar ditt arbete.
  • Bygg långvariga partnerskap inom teamen och utanför teamen.

Obeveklig förbättring

  • Bygg en miljö där att lösa problemen motiverar teamen.
  • Reflektera över hur du gjorde förra veckan och identifiera vad som kan göras bättre nästa gång.
  • Ta fakta som det enskilt viktigaste argumentet för att förbättra saker och ting.
  • Ge tid och utrymme för innovationer. Ge teamen möjlighet att experimentera och prova olika rutter, även om de inte är de säkraste.

SAFe ger ett lager av samarbete och kommunikation till skalade agila system. Det ersätter inte de individuella Scrum Team Sprint-aktiviteterna du gör idag.

En viktig del av varje SAFe är Agile Release Train (ART). Det är ett långlivat, stabilt team av Scrum-team (vanligtvis upp till 12 separata team) som regelbundet kommer med nya inkrementella funktioner efter varje sprintsläpp. De utvecklar, levererar och stödjer en eller flera lösningar i en arbetsström.

Källa: scaledagileframework.com

SAFe:s roller

SAFe förlitar sig på människor med olika uppsättningar av ansvar. Att hålla fast vid förväntningarna på rollerna är den avgörande faktorn som avgör hur framgångsrik implementeringen av ramverket kommer att bli. Det är därför också viktigt att förstå vad dessa roller är och vad deras syfte är.

#1. Agilt team

Agila team är tvärfunktionella, vilket innebär att de kan täcka hela området de implementerar inom själva teamet. De är också självorganiserande enheter som definierar, bygger, testar, distribuerar och släpper värdesteg.

Varje agilt team har färdigheterna att utföra på sin överenskomna och engagerade omfattning. Teamet implementerar den omfattningen i steg varje sprint på ett förutsägbart sätt. Förutsägbarheten är avgörande eftersom endast då kan teamet åta sig att leverera konkreta mål i konkret tid. Kommunikation och leverans är de avgörande värden som teamet ständigt ska förbättra.

Det agila teamet är en grundläggande del av Program Increment (PI) Planningssessioner för att skapa berättelser inom och planera dem inom Sprints. Slutligen förbinder de sig till sina egna PI-mål.

Scrum Master coachar Agile Team och underlättar teammöten. De tar bort hinder och skyddar laget från påverkan utifrån. De deltar i Scrum-möten som en del av ART.

Produktägaren (PO) är en annan speciell medlem i teamet. PO är kundens röst och har ett direkt inflytande på berättelserna och deras prioritering. PO kommunicerar med andra PO för att definiera och prioritera berättelser i teamens eftersläpning.

#2. Produktledning

Produktledningen sitter ovanför scrum-teamen och tar hand om anpassningen mellan teamen. De måste täcka följande ansvarsområden:

  • Uppnå affärsmål genom att se till att utvecklingsteam skapar genomförbara och hållbara produkter och lösningar.
  • Förstå kundens behov och se till att produkterna färdigställs till ett definierat kundperspektiv.
  • Se till att det alltid finns tillräckligt med färdiga funktioner i backloggen.
  • Stöd arbetsflödet genom programstyrelserna och in i programeftersläpningen.
  • Bestäm omfattningen av nästa programökning genom att ge prioritet åt funktionerna som teamen har skapat. Produktledningen är ytterst ansvarig för definitionen av nästa PI.

#3. Systemarkitekt / Ingenjör

Ingenjörsteamet analyserar och utvecklar det överenskomna innehållet i eftersläpningshistorierna. De är expertdelen av teamet och de täcker följande ansvarsområden:

  • Skapa och underhåll Architectural Runway så att nya funktioner kan använda de tekniska möjliggörarna.
  • Delta aktivt i programinkrementplanering. Var närvarande under systemdemonstrationer i slutet av varje programsteg.
  • Arbeta med agila team för att implementera nya arkitekturmöjligheter. Endast detta kommer att tillåta teamen att bygga nya funktioner.
  • Hjälp agila team att definiera designlösningar och beslut på hög nivå. Föreslå alternativa lösningar och det bästa tillvägagångssättet för proof of concept-aktiviteter inom agila team.
  • De skapar en arkitektonisk landningsbana. Det är en definition av tekniska möjliggörare som är redo att konsumeras av funktioner som definieras av respektive team.

#4. Företagsägare / intressenter

Det är teamen utanför Scrum-teamen, men de spelar fortfarande en viktig roll i SAFe-ramverket i varje skede av utförandet.

Innan PI-planering:

  • Ge input till eftersläpningsaktiviteter.
  • Delta i Pre-PI-planering vid behov.
  • Se till att affärsmålen förstås och godkänns av tågets nyckelintressenter, inklusive Release Train Engineer (RTE), Product Management och System Architects.

Under PI-planering:

  • Ge affärssammanhanget och visionen för den kommande PI.
  • Delta i utkastet till plangranskning och tilldela affärsvärde till teamets PI-mål.
  • Delta i ledningsgenomgången och hjälp till att lösa problem som kommer att leda till godkännande av den slutliga planen.

Efter PI-planering:

  • Delta aktivt i att upprätthålla affärs- och utvecklingsanpassning när prioriteringar och omfattning oundvikligen förändras.
  • Hjälp till att validera definitionen av Minimum Viable Products (MVP) för Program Epics och vägleda pivot-eller-hålla beslutet baserat på leveransen av MVP.
  • Delta i systemdemon för att se framstegen och ge feedback.
  • Delta i Agile team Sprint Planning och Sprint Retrospective events, efter behov.
  • Delta i Release Management, med fokus på omfattning, kvalitet, distributionsalternativ, release och marknadsöverväganden.

#5. Release Train Engineer (RTE)

RTE organiserar aktiviteterna för människorna och teamen inom ART. Detta är rollen som Scrum Master för hela programmet. Följande är huvudansvaret:

  • Hantera och optimera värdeflödet genom ART.
  • Upprätta och kommunicera de årliga kalendrarna för Sprints och Program Increment (PIs).
  • Var moderator för PI-planeringsmöten.
  • Organisera team och hjälp dem att skapa en sammanfattning av deras identifierade PI-mål. Överför teamens mål till de övergripande PI-planens mål.
  • Samla teamen för att kommunicera och lösa risker och beroenden mellan varandra.
  • Koppla samman produktledning, produktägare och andra externa intressenter för att anpassa parterna till deras gemensamma strategi.
  • Ordna Inspect and Adapt-workshoparna med målet att kontinuerligt förbättra redan befintliga processer och aktiviteter.
  • Utvärdera den nuvarande mognadsnivån för den agila metodikens antagande i teamen och definiera uppföljningsåtgärder för att förbättra teamen framöver.

#6. Ledarskap

Ledarskap definierar strategin för programmet och ger teamen alla verktyg och stöd som behövs för att möjliggöra deras arbete. I slutändan definierar de systemet där alla andra fungerar. Därför är det avgörande att ha en ledningsgrupp som ger teamet rätt syfte och värderingar. Deras primära ansvar är följande:

  • Föregå med gott exempel.
  • Anta ett tillväxttänk.
  • Framhäv värdena och principerna för SAFe.
  • Utveckla människor.
  • Leda förändringen.
  • Främja psykologisk säkerhet.

Program Increment (PI) Planering

PI Planning är ett två till tre dagar långt evenemang med målet att förstå och engagera sig i arbetet inför nästa programsteg. Detta kan till exempel vara perioden nästa kvartal.

Produkthantering äger prioriteringen av de funktioner som identifierats under PI-planeringen. Agila team äger kapacitetsplanering, skapande av berättelser, uppskattning och engagemang för PI-målen.

PI-planering är avgörande för SAFe. Om du inte gör PI-planeringen betyder det i princip att du inte gör SAFe.

PI-process

Källa: scaledagileframework.com

PI-planering börjar med några ingångar på bordet. Varje arbetsflöde kommer att samla in sina behov och idéer om vad de skulle vilja bygga härnäst för sina produkter. Sedan tar de det till PI som en ingång:

  • Topp 10 funktioner att implementera nästa,
  • ART Backlog av färdiga epos eller funktioner,
  • Produktägarens vision.

Diskussionen startar mellan de olika arbetsflödena. Var och en av dem presenterar sina visioner och funktioner. De lyfter fram vad som är viktigt att implementera härnäst och vad de behöver för att lyckas samtidigt som de gör det. Detta kan betyda flera olika saker:

  • Aktivering levereras av andra arbetsströmmar för att låta dem fortsätta med funktionerna.
  • Beroende av andra arbetsflöden och nödvändigheten av att göra beställning till en prioritet.
  • Aktuella problem som finns i systemet och som måste åtgärdas först för att kunna fortsätta.
  • Bemanningsutmaningar för teamet. Det kan vara flera nyckelroller inom teamet som fortfarande saknas för innehållsimplementeringen som funktionerna kräver.
  • Budgetbegränsningar hindrar din arbetsström från att utföra visionen inom den givna tidslinjen.
  • Alla andra risker, problem, antaganden eller beroenden som teamet kan känna igen och en bredare diskussion mellan resten av SAFe-teamen behövs för att nå det gemensamma målet.

PI genomgång

Själva PI-planeringen är ofta uppdelad i flera dagar, vanligtvis två till tre dagar, där agendan kan vara följande:

Dag 1

  • Diskutera redogörelsen för verksamheten och viktiga kommande mål som utgör den övergripande programmets vision och strategi. Ledarskapet äger 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å in i arkitekturvisionen och definiera huvudmålen för utvecklingskraven. Lyft fram de tekniska utmaningarna och kom överens om att lösa hindren mellan teamen.

Dag 2

  • Förklara planeringsprocessen i detalj för teamen. Beskriv de förväntade resultaten när PI är stängd.
  • Gör Team Breakouts för första gången under planeringen. Teamets mål är att skapa utkast till planer och identifiera hinder och risker.
  • När breakouten är klar ska teamen presentera och granska utkastet till planer de skapat inför de andra lagen.
  • Nästa steg är för ledningen, där de går igenom planerna och ger anvisningar till problemlösningsinsatser som följer därefter. Justeringar av planerna görs utifrån utmaningar, risker och hinder.

Dag 3

  • Börja dagen med planeringsjusteringar som nu ligger i linje med föregående dags ledningsmöte.
  • Teamen kommer att utveckla de slutliga planerna och förfina risker och hinder. Företagsägare kommer att tilldela affärsvärde till teammålen.
  • Därefter kommer teamen att presentera de slutgiltiga planerna inför hela publiken.
  • De återstående riskerna på programnivå diskuteras och ROAM (löst, ägt, accepterat, minskat) riskinformation tillämpas.
  • Lag röstar för sitt förtroende för programmets inkrementplaneringsresultat.
  • Om rösterna är för låga eller det totala förtroendet fortfarande är lågt sker ytterligare planering.
  • Efter PI-åtagandet planerar RTE retrospektivt för teamen att diskutera hur planeringen gick och vad som ska förbättras för nästa omgång. Ledarskap anger vad som kommer att hända framåt tillsammans med slutliga instruktioner.

PI-utfall

Det slutliga resultatet av PI-planeringen är listan över funktioner som planeras för slutförande enligt sprints inom nästa PI-period. Alla kända beroenden har en exakt plan för hur man löser och avblockerar framsteg för funktionerna.

Teamen kommer att förbinda sig till sina mål och omfattningar. Om det finns ytterligare mål som inte nödvändigtvis ingår i listan, behandla dem som oengagerade mål. Dessa kan fortfarande potentiellt lösas om tid och resurser tillåter det.

Teamen kommer att dokumentera och spåra alla risker med programmet och kommer att ha en exakt plan för hur de ska hanteras.

Teamen kommer också att fånga varje retrospektiv idé de kom med i sitt retrospektiva möte och markera dem som lärdomar för nästa PI-planeringssession.

När det gäller teamen specifikt finns det få konkreta förväntningar, som:

  • Teamen förbinder sig till mål med affärsvärden.
  • Teamen kommer att beräkna sin kapacitet per sprint så att de bättre kan uppskatta genomförbarheten av färdplanens innehåll.
  • De tar också hänsyn till den faktiska belastningen per varje sprint.
  • Berättelserna förs till de konkreta spurterna för varje arbetsflöde baserat på den tillhandahållna kapaciteten.
  • Lag röstar för förtroende för PI-planen och innehållet att leverera.

Slutsats

Detta behöver inte se självklart ut, även efter att ha läst all fakta ovan, men jag kan berätta att det är en extremt utmanande uppgift att omvandla en stor organisation till SAFe. Ja, i vissa fall kan det se ut som ett omöjligt uppdrag. Även om vissa av dessa grundläggande principer tillämpas, tar det vanligtvis många iterationer för att konvertera till ett tillstånd där du säkert kan säga att du nu är SAFe :).

Mycket ofta förstör framsteg en del hierarkiska principer och regler av gamla skolan, som helt enkelt inte kommer att dö hur mycket du än försöker. Du kan ha omfattande PI-planering och resultat av något slag, som du till och med kan namnge med förtroende. Men vad betyder det egentligen om arbetsteamen bara inte kommer att verka i korrekt agil metodik?

Jag kan bara säga att det inte finns plats för hybrider här. Antingen är du inne – med alla rätt processer, människor och tankesätt, eller så är du ute om åtminstone en av metodaspekterna inte riktigt uppfylls.

Naturligtvis, innan du ens överväger SAFe-implementeringen, var bara tydlig med att du redan behärskar Agile-teamets principer och sätt att arbeta. Inte bara ur ledarskapsperspektivet, utan låt lagen rösta och uttrycka sin ärliga åsikt. Du kan bli förvånad över resultatet.

Kolla sedan in bra lärresurser för agil certifiering.

var den här artikeln hjälpsam?

Tack för din feedback!