Hvordan tilnærming til overgang fra Scrum til SAFe

Å implementere funksjonelle Scrum-team i en organisasjon er en utfordring i seg selv, og mange feiler stadig på dette trinnet. Men når du har flere svært avhengige team som opererer innenfor samme produkt eller verdistrøm, trenger du noe sterkere.

Det er nødvendig å bruke et skaleringsrammeverk som dekker Scrum-teamene. Gi dem prosesser og regler å følge for å bli synkronisert med hverandre, på linje, og ikke gå seg vill underveis.

Ofte ender du opp med Silo-team, som i utgangspunktet betyr frittstående scrum-team som jobber mot sitt lokale mål, men som knapt har peiling på det endelige felles målet for hele programmet. Det er her Scaled Agile Framework (SAFe) kommer inn i bildet.

Hva er SAFe?

Kilde: scaledagileframework.com

SAFe er en tilnærming som anvender et smidig rammeverk og prosesser til de hierarkiske organisasjonene fra fortiden. Den dekker strukturnivåene og prosessene, men i stedet for å gjenskape dem, gjeninnføres et andre system på en organisk måte som er kjent for de fleste av de eksisterende interessentene i det opprinnelige systemet.

SAFe er bygget rundt flere kjerneverdier.

Justering

• Alle scrum-team må forstå visjonen og strategien og hva som er det endelige målet de marsjerer mot.
• Koble strategi mellom teamene og lede dem til felles utførelse.
• Kommuniser med teamene med et enhetlig felles språk de lett kan forstå.
• Sjekk hele tiden om lagene forstår målene og visjonen.
• Teamene må være kundesentrerte, og de bør forstå hvem som er kundene og hva de trenger. Oppdater strategien for å gjenspeile det.

Åpenhet

• Skap et miljø der alle kan jobbe på sitt beste og uten mangel på tillit.
• Kommuniser åpent argumentene og faktaene dine. Vær direkte og ærlig, og ikke skjul viktige fakta foran lagene.
• Mislykkes raskt og gjør feil til læreøyeblikk. Hvis noe viser seg å ikke være vellykket, innse det snart og lær av det. Deretter endrer du strategien din.
• Visualiser arbeidet du bygger slik at alle bedre kan forstå.
• Gi lett tilgang til nødvendig informasjon.

Respekt for mennesker

• Understrek hva det vil si å være menneske. Ikke behandle mennesker som ressurser.
• Verdi mangfold av mennesker og deres meninger. Støtt ærlig tilbakemelding.
• Vokse og utdanne mennesker gjennom coaching og veiledning.
• Omfavn at kunden din er den som bruker arbeidet ditt.
• Bygg langvarige partnerskap innen teamene og utenfor teamene.

Nådeløs forbedring

• Bygg et miljø der det å løse problemene motiverer teamene.
• Reflekter over hvordan du gjorde forrige uke og identifiser hva som kan gjøres bedre neste gang.
• Ta fakta som det viktigste enkeltargumentet for å forbedre ting.
• Gi tid og rom for innovasjoner. Gi lagene muligheten til å eksperimentere og prøve ut ulike ruter, selv om de ikke er de sikreste.

SAFe bringer et lag med samarbeid og kommunikasjon til skalerte Agile-systemer. Det erstatter ikke de individuelle Scrum Team Sprint-aktivitetene du gjør i dag.

En sentral del av hver SAFe er Agile Release Train (ART). Det er et langvarig, stabilt team av Scrum-team (vanligvis opptil 12 separate team) som regelmessig kommer med nye inkrementelle funksjoner etter hver sprintutgivelse. De utvikler, leverer og støtter én eller flere løsninger i en arbeidsstrøm.

Kilde: scaledagileframework.com

Rollene til SAFe

SAFe er avhengig av mennesker med ulike sett med ansvar. Å holde seg til forventningene til rollene er den avgjørende faktoren som vil avgjøre hvor vellykket implementeringen av rammeverket blir. Det er derfor også viktig å forstå hva disse rollene er og hva deres formål er.

#1. Smidig team

Agile team er tverrfunksjonelle, noe som betyr at de kan dekke hele området de implementerer i teamet selv. De er også selvorganiserende enheter som definerer, bygger, tester, distribuerer og frigir verdiøkninger.

Hvert Agile-team har ferdighetene til å utføre på deres avtalte og forpliktede omfang. Teamet implementerer dette omfanget i trinn hver sprint på en forutsigbar måte. Forutsigbarheten er avgjørende fordi først da kan teamet forplikte seg til å levere konkrete mål i konkret tid. Kommunikasjon og levering er de avgjørende verdiene teamet stadig skal forbedre.

Det smidige teamet er en grunnleggende del av Program Increment (PI) planleggingsøkter for å lage historier innenfor og planlegge dem innenfor Sprints. Til slutt forplikter de seg til sine egne PI-mål.

Scrum Master coacher Agile Team og legger til rette for teammøter. De fjerner hindringer og beskytter teamet mot påvirkning utenfra. De deltar på Scrum-møter som en del av ART.

Produkteieren (PO) er et annet spesielt medlem av teamet. PO er stemmen til kunden og har direkte innflytelse på historiene og deres prioritering. PO kommuniserer med andre POer for å definere og prioritere historier i teamenes etterslep.

#2. Produktledelse

Produktledelsen sitter over scrum-teamene og tar seg av justeringen mellom lagene. De må dekke følgende ansvarsområder:

• Møt forretningsmålene ved å sikre at utviklingsteam skaper gjennomførbare og bærekraftige produkter og løsninger.
• Forstå kundenes behov og sikre at produktene er ferdigstilt til et definert kundeperspektiv.
• Sørg for at det er nok ferdige funksjoner i backloggen til enhver tid.
• Støtt flyten av arbeidet gjennom programstyrene og inn i programetterslepet.
• Bestem omfanget av neste programtilvekst ved å gi prioritet til funksjonene teamene har laget. Produktledelsen er til syvende og sist ansvarlig for definisjonen av neste PI.

#3. Systemarkitekt / Engineering

Ingeniørteamet analyserer og utvikler det avtalte innholdet i backlog-historiene. De er ekspertisen i teamet, og de dekker følgende ansvarsområder:

• Opprett og vedlikehold Architectural Runway slik at nye funksjoner kan bruke de teknologiske aktivatorene.
• Delta aktivt i Program Increment Planning. Vær tilstede under systemdemoer på slutten av hvert programtrinn.
• Jobb med smidige team for å implementere nye arkitekturaktiverere. Bare dette vil tillate teamene å bygge nye funksjoner.
• Hjelp smidige team med å definere designløsninger og beslutninger på høyt nivå. Foreslå alternative løsninger og den beste tilnærmingen for proof of concept-aktiviteter i de smidige teamene.
• De lager en arkitektonisk rullebane. Det er en definisjon av teknologiske muliggjørere klare til å bli konsumert av funksjoner som er definert av respektive team.

#4. Bedriftseiere / Interessenter

Dette er teamene utenfor Scrum-teamene, men de spiller fortsatt en viktig rolle i SAFe-rammeverket i alle trinn av utførelsen.

Før PI-planlegging:

• Gi innspill til aktiviteter for justering av etterslep.
• Delta i Pre-PI-planlegging etter behov.
• Sikre at forretningsmål blir forstått og godtatt av sentrale interessenter i toget, inkludert Release Train Engineer (RTE), Product Management og System Architects.

Under PI-planlegging:

• Gi forretningskonteksten og visjonen for den kommende PI.
• Delta i Draft Plan Review og tilordne forretningsverdi til teamets PI-mål.
• Delta i ledelsesgjennomgangen og bidra til å løse problemer som vil føre til aksept av den endelige planen.

Etter PI-planlegging:

• Delta aktivt i å opprettholde forretnings- og utviklingstilpasning ettersom prioriteringer og omfang uunngåelig endres.
• Hjelp med å validere definisjonen av Minimum Viable Products (MVP) for Program Epics og veilede beslutningen om pivot eller persevering basert på levering av MVP.
• Delta på systemdemoen for å se fremdriften og gi tilbakemelding.
• Delta på Agile team Sprint Planning og Sprint Retrospective events, etter behov.
• Delta i Release Management, med fokus på omfang, kvalitet, distribusjonsalternativer, utgivelse og markedshensyn.

#5. Release Train Engineer (RTE)

RTE organiserer aktivitetene til menneskene og lagene i ART. Dette er rollen som Scrum Master for hele programmet. Følgende er hovedoppgavene:

• Administrer og optimer flyten av verdi gjennom ART.
• Etablere og kommunisere årlige kalendere for sprint og programtilvekster (PIer).
• Vær moderator for PI-planleggingsmøter.
• Organiser team og hjelp dem med å lage et sammendrag av deres identifiserte PI-mål. Overfør teamenes mål til de overordnede PI-planens mål.
• Samle teamene for å kommunisere og løse risikoer og avhengigheter mellom hverandre.
• Koble produktledelse, produkteiere og andre eksterne interessenter sammen for å samkjøre partene etter deres felles strategi.
• Organisere Inspect and Adapt-verkstedene med mål om kontinuerlig å forbedre allerede eksisterende prosesser og aktiviteter.
• Evaluer gjeldende modenhetsnivå for den smidige metodikken som tas i bruk på tvers av teamene, og definer de oppfølgende handlingspunktene for å forbedre teamene fremover.

#6. Ledelse

Ledelse definerer strategien for programmet og gir teamene alle de verktøyene og støtten som er nødvendig for å aktivere deres arbeid. Til syvende og sist definerer de systemet der resten jobber. Derfor er det avgjørende å ha en ledergruppe som gir teamet riktig formål og verdidefinisjon. Deres primære ansvar er følgende:

• Led ved eksempel.
• Vedta en veksttankegang.
• Fremhev verdiene og prinsippene til SAFe.
• Utvikle mennesker.
• Led endringen.
• Fremme psykologisk sikkerhet.

Program Increment (PI) Planlegging

PI Planning er en to til tre dager lang begivenhet med mål om å forstå og forplikte seg til arbeidet for neste programtilvekst. Dette kan for eksempel være perioden neste kvartal.

Produktstyring eier prioriteringen av funksjonene identifisert under PI-planleggingen. Smidige teams eier kapasitetsplanlegging, historieskaping, estimering og forpliktelse til PI-målene.

PI-planlegging er avgjørende for SAFe. Hvis du ikke gjør PI-planleggingen, betyr det i utgangspunktet at du ikke gjør SAFe.

PI-prosess

Kilde: scaledagileframework.com

PI-planlegging starter med noen innganger på bordet. Hver arbeidsstrøm vil samle inn sine behov og ideer om hva de ønsker å bygge videre for produktene sine. Deretter bringer de det til PI som en inngang:

• Topp 10 funksjoner å implementere neste,
• ART Backlog av klare til formulerte epos eller funksjoner,
• Produkteierens visjon.

Diskusjonen starter mellom de ulike arbeidsstrømmene. Hver av dem presenterer sine visjoner og funksjoner. De fremhever hva som er viktig å implementere videre og hva de trenger for å lykkes mens de gjør det. Dette kan bety flere forskjellige ting:

• Aktivering leveres av andre arbeidsstrømmer for å la dem fortsette med funksjonene.
• Avhengighet av andre arbeidsstrømmer og nødvendigheten av å prioritere bestilling.
• Aktuelle problemer som er tilstede i systemet og som må fikses først for å fortsette.
• Bemanningsutfordringer for laget. Det kan være flere nøkkelroller i teamet som fortsatt mangler for innholdsimplementeringen funksjonene krever.
• Budsjettbegrensninger hindrer arbeidsstrømmen din i å utføre visjonen på den gitte tidslinjen.
• Eventuelle andre risikoer, problemer, forutsetninger eller avhengigheter teamet kan gjenkjenne, og en bredere diskusjon på tvers av resten av SAFe-teamene er nødvendig for å tilpasse seg det felles målet.

PI gjennomgang

Selve PI-planleggingen er ofte delt inn i flere dager, typisk to til tre dager, hvor agendaen kan være som følger:

Dag 1

• Diskuter redegjørelsen for virksomheten og viktige kommende mål som danner den overordnede programmets visjon og strategi. Ledelse eier denne delen og kommuniserer tydelig til teamet.
• Plasser alle funksjonene fra arbeidsstrømmene på bordet og prioriter dem i tråd med den vanlige visjonen.
• Gå inn i arkitekturvisjonen og definer hovedmålene for utviklingskravene. Fremhev de tekniske utfordringene og bli enige om å løse hindringene på tvers av lagene.

Dag 2

• Forklar planleggingsprosessen i detalj for teamene. Skisser de forventede resultatene når PI er stengt.
• Gjør Team Breakouts for første gang under planleggingen. Teamets mål er å lage utkast til planer og identifisere hindringer og risikoer.
• Når utbruddet er fullført, skal lagene presentere og gjennomgå utkastet til planene de laget foran de andre lagene.
• Det neste trinnet er for ledelsen, der de gjennomgår planene og gir veiledning til problemløsningstiltak som følger etterpå. Tilpasninger i planene gjøres basert på utfordringer, risikoer og hindringer.

Dag 3

• Start dagen med planleggingsjusteringer som nå er i tråd med forrige dags ledermøte.
• Lagene vil utvikle de endelige planene og avgrense risikoer og hindringer. Bedriftseiere vil tilordne forretningsverdi til teammålene.
• Deretter vil lagene presentere de endelige planene foran hele publikum.
• De gjenværende risikoene på programnivå diskuteres, og ROAM (løst, eid, akseptert, redusert) risikoinformasjon brukes.
• Lag stemmer for tilliten deres til resultatene for programtilvekstplanlegging.
• Hvis stemmene er for lave eller den generelle tilliten fortsatt er lav, skjer det ytterligere planlegging.
• Etter PI-forpliktelsen planlegger RTE retrospektivt for lagene for å diskutere hvordan planleggingen gikk og hva som skal forbedres for neste runde. Lederskap sier hva som kommer til å skje fremover sammen med endelige instruksjoner.

PI-utfall

Det endelige resultatet av PI-planleggingen er listen over funksjoner som er planlagt for fullføring i henhold til sprints innen neste PI-periode. Alle kjente avhengigheter har en nøyaktig plan for hvordan de skal løse og fjerne blokkering av fremdrift for funksjonene.

Lagene vil forplikte seg til sine mål og omfang. Hvis det er flere mål som ikke nødvendigvis er en del av listen, behandle dem som uforpliktende mål. Disse kan fortsatt potensielt løses hvis tid og ressurser tillater det.

Teamene vil dokumentere og spore alle risikoer ved programmet og vil ha en nøyaktig plan for hvordan de skal håndteres.

Teamene vil også fange opp hver retrospektiv idé de kom sammen med i sitt retrospektive møte og markere dem som læringsleksjoner for neste PI-planleggingsøkt.

Når det gjelder teamene spesifikt, er det få konkrete forventninger, som:

• Teamene forplikter seg til mål med forretningsverdier.
• Lagene vil beregne sin kapasitet per sprint slik at de bedre kan estimere gjennomførbarheten av veikartinnholdet.
• De tar også hensyn til den faktiske belastningen per hver sprint.
• Historiene føres til de konkrete spurtene til hver arbeidsstrøm basert på den tilførte kapasiteten.
• Lag stemmer for tillit til PI-planen og innholdet som skal leveres.

Konklusjon

Dette trenger ikke se åpenbart ut, selv etter å ha lest alle fakta ovenfor, men jeg kan fortelle deg at det å transformere en stor organisasjon til SAFe er en ekstremt utfordrende oppgave. Ja, i noen tilfeller kan det se ut som et umulig oppdrag. Selv om noen av disse grunnleggende prinsippene brukes, tar det vanligvis mange gjentakelser for å konvertere til en tilstand der du trygt kan si at du nå er SAFe :).

Svært ofte ødelegger fremskritt noen gammeldagse hierarkiske prinsipper og regler, som bare ikke kommer til å dø uansett hvor hardt du prøver. Du kan ha omfattende PI-planlegging og resultater av noe slag, som du til og med kan navngi med tillit. Men hva betyr det egentlig hvis arbeidsteamene ikke kommer til å operere i riktig smidig metodikk?

Jeg kan bare fortelle at det ikke er plass for hybrider her. Enten er du inne – med alle de riktige prosessene, menneskene og tankesettet, eller så er du ute hvis minst ett av metodikkaspektene ikke er oppfylt.

Naturligvis, før du i det hele tatt vurderer SAFe-implementeringen, må du bare være tydelig på det faktum at du allerede mestrer Agile-teamets prinsipper og måter å jobbe på. Ikke bare fra lederperspektivet, men la lagene stemme og uttrykke sin ærlige mening. Du kan bli overrasket over resultatene.

Deretter kan du sjekke ut gode læringsressurser for smidig sertifisering.

Var denne artikkelen til hjelp?

Takk for din tilbakemelding!