Sådan går du til overgangen fra Scrum til SAFe

At implementere funktionelle Scrum-teams i en organisation er en udfordring i sig selv, og mange fejler konstant på dette trin. Men når du har flere stærkt afhængige teams, der arbejder inden for samme produkt eller værdistrøm, har du brug for noget stærkere.

Det er nødvendigt at bruge en skaleringsramme, der dækker Scrum-teamene. At give dem processer og regler at følge for at blive synkroniseret med hinanden, afstemt og ikke fare vild undervejs.

Ofte ender man med Silo-teams, som dybest set betyder selvstændige scrum-hold, der arbejder mod deres lokale mål, men som knapt har en anelse om det ultimative fælles mål for hele programmet. Det er her, Scaled Agile Framework (SAFe) kommer i spil.

Hvad er SAFe?

Kilde: scaledagileframework.com

SAFe er en tilgang, der anvender agile rammer og processer til fortidens hierarkiske organisationer. Det dækker strukturniveauerne og processerne, men i stedet for at genskabe dem, genindfører det et andet system på en organisk måde, som er kendt for de fleste af de eksisterende interessenter i det oprindelige system.

SAFe er bygget op omkring flere kerneværdier.

Justering

• Alle scrum-teams skal forstå visionen og strategien, og hvad er det ultimative mål, de marcherer mod.
• Forbind strategi mellem teamene og led dem til fælles eksekvering.
• Kommuniker med teamene med et fælles sprog, de nemt kan forstå.
• Tjek konstant, om holdene forstår målene og visionen.
• Holdene skal være kundecentrerede, og de skal forstå, hvem der er kunderne, og hvad de har brug for. Opdater strategien for at afspejle det.

Gennemsigtighed

• Skab et miljø, hvor alle kan arbejde på deres bedste og uden mangel på tillid.
• Kommuniker åbent dine argumenter og fakta. Vær direkte og ærlig, og skjul ikke vigtige fakta foran holdene.
• Mislykkes hurtigt og gør fejl til læringsøjeblikke. Hvis noget viser sig ikke at lykkes, så indse det snart og lær af det. Skift derefter din strategi.
• Visualiser det arbejde, du bygger, så alle bedre kan forstå.
• Giv let adgang til nødvendige oplysninger.

Respekt for mennesker

• Understreg, hvad det vil sige at være menneske. Behandl ikke mennesker som ressourcer.
• Værdsætte mangfoldighed af mennesker og deres meninger. Støt ærlig feedback.
• Vokse og uddanne mennesker gennem coaching og mentoring.
• Omfavn, at din kunde er den, der forbruger dit arbejde.
• Opbyg langvarige partnerskaber inden for teamene og uden for teamene.

ubarmhjertig forbedring

• Byg et miljø, hvor løsningen af ​​problemerne motiverer teamene.
• Reflekter over, hvordan du gjorde i sidste uge, og identificer, hvad der kan gøres bedre næste gang.
• Tag fakta som det vigtigste argument for at forbedre tingene.
• Giv tid og rum til innovationer. Giv holdene mulighed for at eksperimentere og prøve forskellige ruter, selvom de ikke er de sikreste.

SAFe bringer et lag af samarbejde og kommunikation til skalerede Agile systemer. Det erstatter ikke de individuelle Scrum Team Sprint-aktiviteter, du laver i dag.

En vigtig del af enhver SAFe er Agile Release Train (ART). Det er et langvarigt, stabilt team af Scrum-teams (typisk op til 12 separate teams), der regelmæssigt bringer nye inkrementelle funktionaliteter efter hver sprintudgivelse. De udvikler, leverer og understøtter en eller flere løsninger i en arbejdsstrøm.

Kilde: scaledagileframework.com

SAFe’s roller

SAFe er afhængig af mennesker med forskellige sæt af ansvar. At holde sig til forventningerne til rollerne er den afgørende faktor, der afgør, hvor vellykket implementeringen af ​​rammeværket bliver. Det er derfor også vigtigt at forstå, hvad disse roller er, og hvad deres formål er.

#1. Agile Team

Agile teams er tværfunktionelle, hvilket betyder, at de kan dække hele det område, de implementerer i selve teamet. De er også selvorganiserende enheder, der definerer, bygger, tester, implementerer og frigiver værdistigninger.

Hvert agile team har de færdigheder, der skal udføres på deres aftalte og engagerede omfang. Holdet implementerer dette omfang i trin hver sprint på en forudsigelig måde. Forudsigeligheden er afgørende, fordi kun da kan teamet forpligte sig til at levere konkrete mål i konkret tid. Kommunikation og levering er de afgørende værdier, som teamet konstant skal forbedre.

Det agile team er en grundlæggende del af Program Increment (PI) Planlægningssessioner for at skabe historier inden for og planlægge dem inden for Sprints. Endelig forpligter de sig til deres egne PI-mål.

Scrum Master coacher det agile team og faciliterer teammøder. De fjerner hindringer og beskytter holdet mod udefrakommende påvirkning. De deltager i Scrum møder som en del af ART.

Product Owner (PO) er et andet særligt medlem af teamet. PO er kundens stemme og har direkte indflydelse på historierne og deres prioritering. PO’en kommunikerer med andre PO’er for at definere og prioritere historier i holdenes backlog.

#2. Produktstyring

Produktledelsen sidder over scrum-teamene og tager sig af ensretningen mellem teamene. De skal dække følgende ansvarsområder:

• Opfyld forretningsmål ved at sikre, at udviklingsteams skaber gennemførlige og bæredygtige produkter og løsninger.
• Forstå kundens behov og sikre, at produkterne er færdiggjort til et defineret kundeperspektiv.
• Sørg for, at der er nok færdige funktioner i backlog til enhver tid.
• Understøtte arbejdsflowet gennem programbestyrelserne og ind i programefterslæbet.
• Bestem omfanget af den næste programtilvækst ved at give prioritet til de funktioner, som teamene har oprettet. Produktledelsen er i sidste ende ansvarlig for definitionen af ​​den næste PI.

#3. Systemarkitekt / Engineering

Ingeniørteamet analyserer og udvikler det aftalte indhold af backlog-historierne. De er ekspertisen i teamet, og de dækker følgende ansvarsområder:

• Opret og vedligehold Architectural Runway, så nye funktioner kan bruge de teknologiske muligheder.
• Deltag aktivt i Program Increment Planning. Vær til stede under systemdemoer i slutningen af ​​hvert programtrin.
• Arbejd med agile teams for at implementere nye arkitektur-enablere. Kun dette vil give holdene mulighed for at bygge nye funktioner.
• Hjælp agile teams med at definere designløsninger og beslutninger på højt niveau. Foreslå alternative løsninger og den bedste tilgang til proof of concept-aktiviteter i de agile teams.
• De skaber en arkitektonisk landingsbane. Det er en definition af teknologiske enablere klar til at blive brugt af funktioner, der er defineret af respektive teams.

#4. Virksomhedsejere / Interessenter

Det er de teams, der er eksterne i forhold til Scrum-holdene, men de spiller stadig en vigtig rolle i SAFe-rammen i alle faser af udførelsen.

Før PI-planlægning:

• Giv input til efterslæbsforfiningsaktiviteter.
• Deltage i Pre-PI Planlægning efter behov.
• Sikring af, at forretningsmål forstås og accepteres af togets nøgleinteressenter, herunder Release Train Engineer (RTE), Product Management og System Architects.

Under PI-planlægning:

• Giv den forretningsmæssige kontekst og vision for den kommende PI.
• Deltag i Draft Plan Review og tildel forretningsværdi til team PI-mål.
• Deltag i ledelsesgennemgangen og hjælp til at løse problemer, der vil føre til accept af den endelige plan.

Efter PI-planlægning:

• Deltag aktivt i at opretholde forretnings- og udviklingstilpasning, da prioriteter og omfang uundgåeligt ændrer sig.
• Hjælp med at validere definitionen af ​​Minimum Viable Products (MVP’er) for Program Epics og vejled omdrejnings-eller-vedholdende beslutningen baseret på leveringen af ​​MVP.
• Deltag i systemdemoen for at se fremskridt og give feedback.
• Deltag i Agile team Sprint Planning og Sprint Retrospective events efter behov.
• Deltage i Release Management, med fokus på omfang, kvalitet, implementeringsmuligheder, release og markedsovervejelser.

#5. Release Train Engineer (RTE)

RTE organiserer aktiviteterne for folk og teams inden for ART. Dette er rollen som Scrum Master for hele programmet. Følgende er de vigtigste ansvarsområder:

• Administrer og optimer værdiflowet gennem ART.
• Etablere og kommunikere de årlige kalendere for Sprints og Program Increment (PI’er).
• Vær moderator for PI-planlægningsmøder.
• Organiser teams og hjælp dem med at skabe en oversigt over deres identificerede PI-mål. Overfør teamenes mål til de overordnede PI-planmål.
• Saml teamene for at kommunikere og løse risici og afhængigheder mellem hinanden.
• Forbind produktledelse, produktejere og andre eksterne interessenter sammen for at bringe parterne på linje med deres fælles strategi.
• Tilrettelæg Inspect and Adapt workshops med det mål løbende at forbedre allerede eksisterende processer og aktiviteter.
• Evaluer det aktuelle modenhedsniveau for den agile metodologi, der anvendes på tværs af teamene, og definer de opfølgende handlingspunkter for at forbedre teams fremadrettet.

#6. Ledelse

Ledelse definerer strategien for programmet og giver teamene alle de værktøjer og støtte, der er nødvendige for at muliggøre deres arbejde. I sidste ende definerer de systemet, hvor alle de andre arbejder. Derfor er det afgørende at have et ledelsesteam, der giver teamet den rigtige formåls- og værdidefinition. Deres primære ansvar er følgende:

• Gå foran med eksempel.
• Adopter en væksttankegang.
• Fremhæv værdierne og principperne for SAFe.
• Udvikle mennesker.
• Led forandringen.
• Fremme psykologisk sikkerhed.

Program Increment (PI) Planlægning

PI Planning er en to til tre dages begivenhed med det mål at forstå og forpligte sig til arbejdet for den næste programtilvækst. Dette kan for eksempel være perioden i næste kvartal.

Produktstyring ejer prioriteringen af ​​de funktioner, der er identificeret under PI-planlægningen. Agile teams egner kapacitetsplanlægning, historieskabelse, estimering og forpligtelse til PI-målene.

PI-planlægning er afgørende for SAFe. Hvis du ikke laver PI-planlægningen, betyder det dybest set, at du ikke laver SAFe.

PI proces

Kilde: scaledagileframework.com

PI-planlægning starter med nogle input på bordet. Hver workstream vil indsamle deres behov og ideer til, hvad de gerne vil bygge næste gang for deres produkter. Så bringer de det til PI’en som input:

• Top 10 funktioner at implementere næste,
• ART Backlog af klar til formulerede epos eller funktioner,
• Produktejerens vision.

Diskussionen starter mellem de forskellige arbejdsstrømme. Hver af dem præsenterer deres visioner og funktioner. De fremhæver, hvad der er vigtigt at implementere næste gang, og hvad de har brug for for at få succes, mens de gør det. Dette kan betyde flere forskellige ting:

• Aktivering leveres af andre arbejdsstrømme for at lade dem fortsætte med funktionerne.
• Afhængighed af andre arbejdsstrømme og nødvendigheden af ​​at prioritere bestilling.
• Aktuelle problemer, der er til stede i systemet, og som skal rettes først for at fortsætte.
• Bemandingsudfordringer for teamet. Det kan være, at flere nøgleroller i teamet stadig mangler for den indholdsimplementering, som funktionerne kræver.
• Budgetbegrænsninger forhindrer din arbejdsstrøm i at udføre visionen på den givne tidslinje.
• Alle andre risici, problemer, antagelser eller afhængigheder, som teamet kan genkende, og en bredere diskussion på tværs af resten af ​​SAFe-holdene er nødvendige for at nå det fælles mål.

PI gennemgang

Selve PI-planlægningen er ofte opdelt i flere dage, typisk to til tre dage, hvor dagsordenen kan være som følger:

Dag 1

• Diskuter redegørelsen for virksomheden og de vigtigste kommende mål, der danner den overordnede programvision og strategi. Ledelse ejer denne del og kommunikerer tydeligt til teamet.
• Placer alle funktionerne fra workstreams på bordet, og prioriter dem i overensstemmelse med den fælles vision.
• Træd ind i arkitekturvisionen og definer hovedmålene for udviklingskravene. Fremhæv de tekniske udfordringer og enig om at løse forhindringerne på tværs af holdene.

Dag 2

• Forklar planlægningsprocessen i detaljer for teamene. Skitser de forventede resultater, når PI’en er lukket.
• Lav Team Breakouts for første gang under planlægningen. Teamets mål er at lave udkast til planer og identificere hindringer og risici.
• Når breakouten er afsluttet, skal holdene præsentere og gennemgå de udkast til planer, de har lavet foran de andre hold.
• Næste skridt er for ledelsen, hvor de gennemgår planerne og giver anvisninger til problemløsningstiltag, der følger derefter. Tilpasning af planerne foretages på baggrund af udfordringer, risici og forhindringer.

Dag 3

• Start dagen med planlægningstilpasninger, der nu er i tråd med forrige dags ledelsesmøde.
• Teams vil udvikle de endelige planer og forfine risici og hindringer. Virksomhedsejere vil tildele forretningsværdi til teamets mål.
• Dernæst vil holdene præsentere de endelige planer foran hele publikum.
• De resterende risici på programniveau diskuteres, og ROAM (løst, ejet, accepteret, dæmpet) risikoinformation anvendes.
• Hold stemmer for deres tillid til resultaterne af programtilvækstplanlægningen.
• Hvis stemmerne er for lave, eller den samlede tillid stadig er lav, sker der yderligere planlægning.
• Efter PI-forpligtelsen planlægger RTE retrospektivt for holdene for at diskutere, hvordan planlægningen gik, og hvad der skal forbedres til næste runde. Lederskab angiver, hvad der skal ske fremover sammen med de endelige instruktioner.

PI udfald

Det ultimative resultat af PI-planlægningen er listen over funktioner, der er planlagt til færdiggørelse i henhold til sprints inden for den næste PI-periode. Alle kendte afhængigheder har en nøjagtig plan for, hvordan man løser og fjerner blokering af fremskridt for funktionerne.

Teams vil forpligte sig til deres mål og omfang. Hvis der er yderligere mål, som ikke nødvendigvis er en del af listen, skal du behandle dem som uforpligtende mål. Disse kan stadig potentielt løses, hvis tid og ressourcer tillader det.

Hold vil dokumentere og spore alle risici ved programmet og vil have en nøjagtig plan for, hvordan de skal håndtere dem.

Teams vil også fange hver retrospektiv idé, de kom sammen med, i deres retrospektive møde og markere dem som læringslektioner til den næste PI-planlægningssession.

Hvad specifikt angår holdene, er der få konkrete forventninger, såsom:

• Holdene forpligter sig til mål med forretningsværdier.
• Holdene vil beregne deres kapacitet pr. sprint, så de bedre kan vurdere gennemførligheden af ​​køreplanens indhold.
• De tager også hensyn til den faktiske belastning pr. hver sprint.
• Historierne føres til de konkrete sprints af hver arbejdsstrøm baseret på den tilvejebragte kapacitet.
• Hold stemmer for tillid til PI-planen og indholdet til at levere.

Konklusion

Dette behøver ikke se indlysende ud, selv efter at have læst alle fakta ovenfor, men jeg kan fortælle dig, at det er en ekstremt udfordrende opgave at transformere en stor organisation til SAFe. Ja, i nogle tilfælde kan det ligne en umulig mission. Selvom nogle af disse grundlæggende principper anvendes, tager det normalt mange gentagelser for at konvertere til en tilstand, hvor du trygt kan sige, at du nu er SAFe :).

Meget ofte ødelægger fremskridt nogle old-school hierarkiske principper og regler, som bare ikke vil dø, uanset hvor meget du prøver. Du kan have omfattende PI-planlægning og resultater af en eller anden art, som du endda kan navngive med tillid. Men hvad betyder det egentlig, hvis workstream-teamene bare ikke kommer til at operere i ordentlig agil metodologi?

Jeg kan kun fortælle, at der ikke er plads til hybrider her. Du er enten inde – med alle de rigtige processer, mennesker og mindset, eller også er du ude, hvis mindst et af metodologiske aspekter ikke rigtig er opfyldt.

Naturligvis, før du overhovedet overvejer SAFe-implementeringen, skal du bare være klar over, at du allerede mestrer Agile-teamets principper og måder at arbejde på. Ikke kun fra ledelsesperspektivet, men lad holdene stemme og udtrykke deres ærlige mening. Du kan blive overrasket over resultaterne.

Tjek derefter gode læringsressourcer til agil certificering.

Var denne artikel til hjælp?

Tak for din feedback!