Å etablere funksjonelle Scrum-team i en virksomhet kan være en betydelig utfordring, og mange mislykkes i dette steget. Men når det er flere sterkt avhengige team som arbeider innenfor det samme produktet eller verdikjeden, kreves det en mer robust tilnærming.
Det er avgjørende å implementere et skaleringsrammeverk som omfatter Scrum-teamene. Dette gir dem de nødvendige prosessene og reglene for å oppnå synkronisering, enhetlighet og for å unngå forvirring underveis.
Ofte ender man opp med silo-team, som i praksis er selvstendige scrum-team som jobber mot sine egne lokale mål, men som har begrenset forståelse av det felles overordnede målet for hele prosjektet. Det er her Scaled Agile Framework (SAFe) kommer inn som en løsning.
Hva innebærer SAFe?
Kilde: scaledagileframework.com
SAFe er en metode som implementerer smidige rammeverk og prosesser i tradisjonelle hierarkiske organisasjoner. Det omfatter strukturelle nivåer og prosesser, men i stedet for å reprodusere dem, introduseres et nytt system på en organisk måte som er lett gjenkjennelig for de eksisterende interessentene.
SAFe er basert på flere grunnleggende verdier.
Samkjøring
- Hvert Scrum-team må ha en felles forståelse av visjonen, strategien og det endelige målet de arbeider mot.
- Strategien må knyttes sammen på tvers av teamene for å sikre en koordinert utførelse.
- Kommunikasjonen med teamene må foregå på et felles språk som er lett å forstå.
- Det må kontinuerlig kontrolleres at alle team forstår målene og visjonen.
- Teamene må være kundesentrerte og forstå hvem kundene er og hva de trenger. Strategien bør oppdateres for å gjenspeile dette.
Åpenhet
- Skap et miljø der alle kan yte sitt beste uten mangel på tillit.
- Kommuniser argumenter og fakta åpent. Vær direkte og ærlig, og ikke hold tilbake viktig informasjon fra teamene.
- Feil må oppdages raskt og ses på som læringsmuligheter. Hvis noe ikke fungerer, erkjenn det raskt og lær av det. Juster strategien basert på dette.
- Visualiser arbeidet for å skape bedre forståelse for alle involverte.
- Sørg for enkel tilgang til nødvendig informasjon.
Respekt for enkeltpersoner
- Understrek viktigheten av å behandle mennesker som individer. Unngå å se på dem som ressurser.
- Verdsatt mangfoldet i menneskers meninger. Oppmuntre til ærlige tilbakemeldinger.
- Støtt personlig vekst og utvikling gjennom veiledning og coaching.
- Anse kunden som den som bruker arbeidet ditt.
- Bygg varige partnerskap både innenfor og utenfor teamene.
Kontinuerlig forbedring
- Skap et miljø der problemløsning motiverer teamene.
- Reflekter over forrige uke og identifiser hva som kan gjøres bedre neste gang.
- Bruk fakta som det viktigste argumentet for forbedring.
- Gi tid og rom for innovasjon. Gi teamene muligheten til å eksperimentere og prøve ut nye veier, selv om de ikke er de sikreste.
SAFe tilfører et lag av samarbeid og kommunikasjon til skalerte Agile systemer. Det erstatter ikke de individuelle Scrum Team Sprint-aktivitetene som utføres i dag.
En viktig del av SAFe er Agile Release Train (ART). Dette er et stabilt, langsiktig team av Scrum-team (vanligvis opptil 12 separate team) som regelmessig leverer nye funksjoner etter hver sprintutgivelse. De utvikler, leverer og støtter en eller flere løsninger innenfor en arbeidsflyt.
Kilde: scaledagileframework.com
Roller innen SAFe
SAFe er avhengig av mennesker med ulike ansvarsområder. Det er avgjørende at alle forstår og følger sine forventede roller for å sikre en vellykket implementering av rammeverket. Det er derfor viktig å forstå hvilke roller som finnes og hva deres formål er.
#1. Smidig team
Smidige team er tverrfaglige, noe som betyr at de har kompetansen til å dekke hele området de arbeider med. De er selvorganiserende enheter som definerer, utvikler, tester, distribuerer og leverer verdiøkninger.
Hvert smidige team har de nødvendige ferdighetene for å utføre den avtalte oppgaven. Teamet implementerer dette i trinn hver sprint på en forutsigbar måte. Forutsigbarhet er avgjørende fordi det først da er mulig for teamet å forplikte seg til konkrete mål til en bestemt tid. Kommunikasjon og levering er de viktige verdiene som teamet kontinuerlig jobber med å forbedre.
Det smidige teamet er en sentral deltaker i Program Increment (PI) planleggingsmøter for å lage historier og planlegge dem innenfor Sprints. Til slutt forplikter de seg til sine egne PI-mål.
Scrum Master veileder det smidige teamet og tilrettelegger teammøter. De fjerner hindringer og beskytter teamet mot ekstern påvirkning. De deltar også på Scrum-møter som en del av ART.
Produkteieren (PO) er et annet sentralt medlem av teamet. PO er kundens talsperson og har direkte innflytelse på historiene og prioriteringen av dem. PO kommuniserer med andre PO-er for å definere og prioritere historier i teamets backlog.
#2. Produktledelse
Produktledelsen er over scrum-teamene og sørger for samkjøring mellom teamene. Deres ansvarsområder er følgende:
- Sikre at forretningsmålene nås ved å sørge for at utviklingsteamene skaper gjennomførbare og bærekraftige produkter og løsninger.
- Forstå kundenes behov og sikre at produktene ferdigstilles i tråd med kundens perspektiv.
- Sørge for at det alltid er nok ferdigdefinerte funksjoner i backloggen.
- Støtte arbeidsflyten gjennom programstyring og inn i programets backlog.
- Bestemme omfanget av neste programtilvekst ved å prioritere funksjonene som teamene har utviklet. Produktledelsen har det endelige ansvaret 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 har ansvaret for følgende:
- Etablere og vedlikeholde Architectural Runway slik at nye funksjoner kan bruke de teknologiske aktivererne.
- Delta aktivt i Program Increment Planning. Være til stede under systemdemoer på slutten av hvert programtrinn.
- Samarbeide med smidige team for å implementere nye arkitekturaktiverere. Dette er nødvendig for at teamene skal kunne utvikle nye funksjoner.
- Hjelpe 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 utvikler en arkitektonisk rullebane. Dette innebærer en definisjon av teknologiske muligheter som er klare til å brukes av de funksjonene som er definert av de respektive teamene.
#4. Bedriftseiere / Interessenter
Disse teamene er utenfor Scrum-teamene, men de spiller fortsatt en viktig rolle i SAFe-rammeverket gjennom alle trinnene av utførelsen.
Før PI-planlegging:
- Gi innspill til aktiviteter for backlogjustering.
- Delta i Pre-PI-planlegging etter behov.
- Sikre at forretningsmålene blir forstått og akseptert av sentrale interessenter, 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 samkjøringen mellom forretnings- og utvikling, ettersom prioriteringer og omfang uunngåelig endres.
- Bidra til å validere definisjonen av Minimum Viable Products (MVP) for Program Epics, og veilede beslutningen om å fortsette eller endre kurs 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 markedsvurderinger.
#5. Release Train Engineer (RTE)
RTE organiserer aktivitetene til menneskene og teamene i ART. Dette er rollen som Scrum Master for hele programmet. Deres hovedoppgaver er følgende:
- Administrere og optimalisere flyten av verdi gjennom ART.
- Etablere og kommunisere årlige kalendere for sprint og programtilvekster (PI-er).
- Være moderator for PI-planleggingsmøter.
- Organisere team og hjelpe dem med å lage et sammendrag av deres identifiserte PI-mål. Overføre teamenes mål til de overordnede PI-planens mål.
- Samle teamene for å kommunisere og løse risikoer og avhengigheter.
- Koble produktledelse, produkteiere og andre eksterne interessenter sammen for å samkjøre partene etter deres felles strategi.
- Organisere Inspect and Adapt-verksteder med mål om kontinuerlig å forbedre eksisterende prosesser og aktiviteter.
- Evaluere gjeldende modenhetsnivå for den smidige metodikken som brukes av teamene, og definere oppfølgende handlingspunkter for å forbedre teamene videre.
#6. Ledelse
Ledelsen definerer strategien for programmet og gir teamene alle de verktøyene og den støtten som er nødvendig for å gjennomføre sitt arbeid. Til syvende og sist definerer de systemet der resten av teamene opererer. Derfor er det viktig å ha en ledergruppe som gir teamet et klart formål og en god verdidefinisjon. Deres viktigste ansvarsområder er følgende:
- Lede gjennom eksempel.
- Anvende en veksttankegang.
- Fremheve verdiene og prinsippene til SAFe.
- Utvikle mennesker.
- Lede endringen.
- Fremme psykologisk trygghet.
Program Increment (PI) Planlegging
PI-planlegging er en hendelse som varer i to til tre dager og har som mål å skape forståelse for arbeidet og forplikte seg til det for den kommende programtilveksten. Dette kan for eksempel være perioden for neste kvartal.
Produktstyring har ansvaret for prioriteringen av funksjonene som er identifisert under PI-planleggingen. Smidige team har ansvaret for kapasitetsplanlegging, historieskaping, estimering og forpliktelse til PI-målene.
PI-planlegging er en viktig del av SAFe. Hvis man ikke gjennomfører PI-planlegging, betyr det i praksis at man ikke følger SAFe.
PI-prosess
Kilde: scaledagileframework.com
PI-planleggingen starter med at ulike typer informasjon samles. Hver arbeidsflyt vil samle inn sine behov og ideer om hva de ønsker å bygge videre på for sine produkter. Deretter presenteres dette som en inngang til PI:
- De 10 viktigste funksjonene som skal implementeres neste gang,
- ART Backlog med klare epics eller funksjoner,
- Produkteierens visjon.
Diskusjonen starter mellom de ulike arbeidsflytene. Hver av dem presenterer sine visjoner og funksjoner. De fremhever hva som er viktig å implementere videre og hva de trenger for å lykkes. Dette kan innebære ulike aspekter:
- Aktivering levert av andre arbeidsflyter for å tillate dem å fortsette med sine funksjoner.
- Avhengighet av andre arbeidsflyter og behovet for å prioritere rekkefølge.
- Aktuelle problemer i systemet som må fikses først for å fortsette.
- Bemanningstutfordringer for laget. Det kan mangle flere nøkkelroller i teamet som er nødvendige for å implementere de funksjonene som kreves.
- Budsjettbegrensninger som hindrer arbeidsflyten i å utføre visjonen innen den gitte tidsrammen.
- Eventuelle andre risikoer, problemer, antagelser eller avhengigheter som teamet gjenkjenner, og som krever en bredere diskusjon med resten av SAFe-teamene for å samkjøre seg mot et felles mål.
PI gjennomgang
Selve PI-planleggingen er ofte delt opp i flere dager, vanligvis to til tre dager, der agendaen kan være som følger:
Dag 1
- Diskuter redegjørelsen for virksomheten og viktige kommende mål som danner det overordnede programets visjon og strategi. Ledelsen har ansvaret for denne delen og kommuniserer tydelig til teamet.
- Plasser alle funksjonene fra arbeidsflytene på bordet og prioriter dem i tråd med den felles visjonen.
- Gå gjennom den arkitektoniske visjonen og definer de viktigste målene for utviklingskravene. Fremhev de tekniske utfordringene og bli enige om å løse hindringer på tvers av teamene.
Dag 2
- Forklar planleggingsprosessen i detalj for teamene. Skisser de forventede resultatene når PI er avsluttet.
- Gjør teamutbrudd for første gang under planleggingen. Teamets mål er å lage utkast til planer og identifisere hindringer og risikoer.
- Når utbruddet er ferdig, skal lagene presentere og gå gjennom utkastet til planene de har laget foran de andre lagene.
- Det neste trinnet er ledelsens gjennomgang av planene. De gir veiledning til problemløsningstiltak som skal følge. Justeringer i planene gjøres basert på utfordringer, risikoer og hindringer.
Dag 3
- Start dagen med planleggingsjusteringer som nå er i tråd med ledelsens møte fra dagen før.
- Lagene skal utvikle de endelige planene og avgrense risikoer og hindringer. Bedriftseiere vil tilordne forretningsverdi til teammålene.
- Deretter presenterer lagene de endelige planene for alle deltakere.
- De gjenværende risikoene på programnivå diskuteres, og ROAM (Resolved, Owned, Accepted, Mitigated) risikoinformasjon brukes.
- Lag stemmer for sin tillit til resultatene av programtilvekstplanleggingen.
- Hvis stemmene er for lave eller den generelle tilliten fortsatt er lav, foretas ytterligere planlegging.
- Etter PI-forpliktelsen planlegger RTE en retrospektiv for lagene. Der diskuteres hvordan planleggingen gikk og hva som kan forbedres til neste runde. Ledelsen informerer om veien videre og gir de siste instruksjonene.
PI-resultat
Det endelige resultatet av PI-planleggingen er en liste over funksjoner som er planlagt fullført i henhold til sprints innen den neste PI-perioden. Alle kjente avhengigheter har en nøyaktig plan for hvordan de skal løses, slik at progresjonen for funksjonene ikke blokkeres.
Lagene forplikter seg til sine mål og omfang. Hvis det er flere mål som ikke nødvendigvis er en del av den forpliktende listen, behandles de som ikke-forpliktende mål. Disse kan fortsatt bli løst hvis tid og ressurser tillater det.
Teamene dokumenterer og sporer alle risikoer ved programmet og vil ha en nøyaktig plan for hvordan de skal håndteres.
Teamene vil også fange opp alle ideene de fikk i sine retrospektive møter og markere dem som læring for neste PI-planleggingsøkt.
Når det gjelder de spesifikke forventningene til teamene, er det noen konkrete punkter:
- Teamene forplikter seg til mål med forretningsverdi.
- Lagene beregner sin kapasitet per sprint for å bedre estimere gjennomførbarheten av veikartinnholdet.
- De tar også hensyn til den faktiske belastningen per sprint.
- Historiene legges inn i de konkrete sprintene til hver arbeidsflyt basert på den tilgjengelige kapasiteten.
- Lagene stemmer for tillit til PI-planen og innholdet som skal leveres.
Konklusjon
Selv om det kan være vanskelig å se klart for seg etter å ha lest all informasjonen ovenfor, kan det nevnes at det å transformere en stor organisasjon til SAFe er en ekstremt krevende oppgave. I noen tilfeller kan det virke som en umulig oppgave. Selv om man tar i bruk noen av de grunnleggende prinsippene, krever det vanligvis mange gjentakelser før man trygt kan si at man har implementert SAFe.
Ofte vil en slik overgang utfordre noen tradisjonelle hierarkiske prinsipper og regler som ikke forsvinner selv om man prøver hardt. Man kan gjennomføre omfattende PI-planlegging med resultater man har tillit til. Men hva betyr det egentlig hvis teamene ikke fungerer i tråd med de riktige smidige metodene?
Det er ikke rom for hybrider her. Enten er man fullt engasjert med de riktige prosessene, menneskene og tankesettet, eller så er man ikke med, hvis bare ett av metodikkens aspekter ikke er oppfylt.
Før man vurderer en SAFe-implementering, er det viktig å være klar over at man allerede mestrer prinsippene og arbeidsmetodene for Agile-team. Ikke bare fra et lederperspektiv, men ved å la teamene gi tilbakemeldinger. Resultatene kan overraske.
Etter dette kan man undersøke ressurser for å lære mer om smidig sertifisering.
Var denne artikkelen til hjelp?
Takk for din tilbakemelding!