Denne siden er automatisk oversatt. Bytt til engelsk for en bedre leseopplevelse.

Bytt til engelsk
Christine
Christine

Scrum i stor skala (LeSS): En oversikt og sammenligning

Se for deg at du har 3 agile team som jobber etter Scrum og ønsker å skalere – Scrum er ikke lenger nok. Hva skjer videre? Det finnes ulike rammeverk for dette, blant annet SAFe Nexus og mange andre. I dag ser vi nærmere på LeSS.

LeSS er SCRUM (definisjon)

Den LeSS-rammeverk forsøker å anvende prinsippene og idealene til Scrum i en stor bedriftskontekst så enkelt som mulig ved hjelp av definerte regler og retningslinjer. På grunn av sin enkelhet har LeSS fått definisjonen, eller merkelappen, «knapt tilstrekkelig» rammeverk – men dette er ikke ment å sette det i et negativt lys.

7 Fordeler med LeSS-rammeverket

Det grunnleggende fokuset i LeSS er ikke å skape enda et nytt rammeverk. I stedet brukes Scrum-prinsippene i mange team.

Noen av fordelene som følger med LeSS kan oppnås er:

  1. Lavere implementeringskostnader ved å implementere praksiser som teamene allerede bruker i Scrum.
  2. En produkteiersom forstår rammeverket og prinsippene og deretter bygger bro mellom virksomheten og de tekniske teamene.
  3. I forbindelse med levering av et produkt, vil færre mennesker nødvendig. LeSS tilfører ikke eksponentielt flere roller og merarbeid.
  4. Den tilbyr en full produktvisning i fokusområdet
  5. Den Teamene er i direkte kontakt med kunden og andre interessenter 
  6. Kontinuerlige forbedringer tilrettelegges gjennom regelmessige retrosamtaler og andre møter, som er grunnleggende prosesser i Agilen-manifestet.
  7. For mange organisasjoner kan LeSS-tilnærmingen til skalering av Scrum-team være en fordel det neste logiske steget på veien mot smidig skalering..

Før vi går i dybden, en liten notis. Vi hadde nylig 11 internasjonale agile eksperter som gjester i et webinar – om et spørsmål: Hvordan skalerer man agile metoder på riktig måte?

Resultatet er dette fantastiske videoopptaket (engelsk), som blant annet tar for seg følgende spørsmål:

  • Er det bedre å starte nedenfra og opp eller ovenfra og ned?
  • Hvordan får man ledere til å enes om en felles visjon?
  • Hvordan velge riktig agilt rammeverk –, og hvorfor er det egentlig ikke så viktig?

Min varmeste anbefaling: Ta en titt! Det tar relativt lang tid, men det er verdt hvert minutt.

Hvordan er LeSS strukturert? En definisjon

Large Scale Scrum bygger per definisjon på prinsipper, rammeverk, retningslinjer og eksperimenter. Illustrasjonen (kilde: LeSS’ nettsted) viser det. La oss forklare dette med et eksempel: 

Prinsipper: Team X utvikler en mobiltelefon. Det er viktig for dem å opptre transparent. Derfor jobber de transparent og har regelmessige daily stand-ups. I tillegg ønsker de å finne ut nøyaktig hvor materialene som er viktige for mobilproduksjonen kommer fra – for senere å kunne informere kundene om dette på en transparent måte. Transparens tvers igjennom altså.

rammebetingelser: Samtidig jobber de kontinuerlig med å skape de rammebetingelsene som gjør SCRUM-rammeverket ideelt sammen med smidige verdier predefinerer: Åpenhet, mot, respekt, fokus og engasjement.

Veiledende prinsipper: Veiledende prinsipper for utviklingen er produktvisjonen, de tekniske kravene til produktet, men også måten vi jobber sammen på i teamet.

Eksperimenter: Når det oppstår usikkerhet, befinner vi oss i eksperimentområdet, der det handler om å teste og prøve ut ting. For eksempel hvis vi ønsker å utvikle en ny funksjon eller nå en helt ny målgruppe. (Kilde: LeSS’ nettsted)

De 10 LeSS-prinsippene

LeSS definert 10 Prinsipper. De hjelper til med å – hvis vi fortsetter med eksemplet vårt – utvikle en mobiltelefon som best samsvarer med kundens verdier og ideer. Nedenfor følger en oversikt over de 10 prinsippene:

  1. Scrum i stor skala er Scrum: Mobiltelefonen kan ikke bare utvikles av ett, men av flere team, slik at kunden blir fornøyd og utviklingstiden blir rimelig.
  2. Empirisk prosesskontroll: Basert på kortsiktige erfaringer tilpasses og revideres de enkelte funksjonene i mobiltelefonen kontinuerlig.
  3. Åpenhet: Team X bestemmer seg for å dele de ukentlige teammålene åpent på den interne plattformen fra nå av. Dette gjør det lettere å forstå hva alle faktisk jobber med.
  4. Mer med mindre: I utgangspunktet bør man eksperimentere med nye ideer og lære av dem før man etablerer inerte regler og dermed tilfører “ballast”.
  5. Fokus på hele produktet: Team har en enda større tendens til å suboptimalisere målene sine enn enkeltpersoner. Den største utfordringen for teamene er derfor å integrere arbeidet i et produkt. “Formålet” med hele produktet bør derfor være så tydelig som mulig. Teamene og enkeltpersonene får dermed mulighet til selv å definere passende delmål etter behov.
  6. Kunden i sentrum: Bare team som jobber direkte med kunden, kan maksimere den reelle verdien av produktet. Dessverre har organisasjoner en tendens til å koble teamene fra kunden så snart de begynner å vokse. For å motvirke dette blir kundene regelmessig invitert til teammøter for å gi tilbakemeldinger.
  7. Kontinuerlig forbedring mot perfeksjon: LeSS er en dyptgripende endring for mange organisasjoner. Vær oppmerksom på at dette ikke automatisk betyr en forbedring. LeSS gjør det mulig for organisasjonen å begynne å bli bedre – og fra da av bør man kontinuerlig fortsette å optimalisere. LeSS er en prosess!
  8. Lean-tenkning: LeSS legger først og fremst vekt på å se stedet for selve hendelsen (Gemba), og læringskonseptet i tre faser ShuHaRi (Shu = etterligne, Ha = variere, Ri = definere egne regler) og respekt for mennesker.
  9. Systemtenkning: Alle handlinger, endringer og forbedringer bør alltid tenkes systemisk eller systemkonformt for å oppnå målene. Eksempel: Hvis jeg i et team teoretisk sett tilbyr økonomiske bonuser – hva betyr det for andre team (det vil si for resten av organisasjonssystemet)?
  10. Køteori: Grunntanken er at vi i programvareverdenen bygger opp mange usynlige køer (f.eks. kravdokumenter og uprøvd programvare) og knapt bryr oss om hvordan disse køene skal behandles optimalt. Visste du for eksempel at når utnyttelsen av en ressurs øker fra 50% til 90%, vil ventetiden for nye oppgaver ikke bare dobles, men mangedobles? Så definer grenser for pågående arbeid (WIP), unngå multitasking og store arbeidspakker. 

LeSS-rammeverkene

LeSS tilbyr to konfigurasjoner: Grunnleggende LeSS for To til åtte lag (10 til 50 personer) og LeSS Huge for Flere enn åtte lag (50 til 6 000 personer og mer).

Kilde: Less.works

Det anbefales å starte med Basic LeSS for å eksperimentere, få erfaring og tilbakemeldinger før man går direkte til LeSS Huge. Det er to foreslåtte fremgangsmåter for å introdusere LeSS Huge:

  • Begynn med ett kravområde om gangen innenfor det større produktet, og fokuser kun på det i begynnelsen.
  • Eller gradvis utvide teamets arbeidsomfang, definisjonen av ferdig og produktdefinisjonen.

På denne måten kan en bedrift bygge teamerfaring med LeSS, ekspandere i et produktområde, oppnå de første suksessene – og dermed få ledelsesstøtte før LeSS skaleres i hele bedriften.

Forresten, en kort merknad i sammenheng med agil transformasjon: Vil du være sikker på at dere for øyeblikket prioriterer riktig i deres agile transformasjon? 

Da kan du ta vår modenhetssjekk for deres agile transformasjon – det tar bare 3 minutter. Du får til og med et benchmark basert på de over tre hundre andre deltakerne. Se knapp 🙂

Roller og planlegging i LeSS

Basic LeSS fokuserer på teamet og de viktigste Scrum-rollene:

  1. Scrum Product Owner, som er ansvarlig for produktets visjon og retning.
  2. Scrum-utviklingsteamene som er ansvarlige for produktutvikling og -levering
  3. Scrum Master, som støtter teamet i arbeidet med kontinuerlig forbedring.
  4. Lederens rolle og hvordan han/hun støtter teamet i å fjerne hindringer for kontinuerlig forbedring og autonomi (utvidelse av SCRUM).

Huge LeSS utfyller Basic LeSS med følgende roller:

  1. LeSS Huge Regional Product Owner støtter Product Owners og er avgjørende for å koble forretningskrav (økonomi osv.) med utviklingsteamene.
  2. Area Product Owner spesialiserer seg på kundeorienterte oppgaver og fungerer som produkteier for produktorienterte funksjonsteam.

Møter i LeSS

Den Forbedring av produktkøen (PBR) Møte

PBR-møtene utvider sprintplanleggingen på tvers av fokusområder gjennom en rekke parallelle LeSS-sprintgjennomføringer. Disse møtene er nødvendige i hver sprint for å forstå, diskutere og forbedre elementer og forberede fremtidige sprinter. De viktigste aktivitetene i PBR-møtene er 

  1. Oppretting av epics – altså gruppering av store, sammenhengende temaområder; i vårt eksempel ville det være sammenslåingen av sprintene fra Design & Usability Team
  2. Avklaring og besvarelse av åpne spørsmål: Alle bør ha samme forståelse av produktet og ideene til kunden og kollegene.
  3. Estimering av størrelsen på brukerhistorien, risikoer og avhengigheter: Quasi utledning og detaljplanlegging av de enkelte temaene.

Den Sprint-gjennomgang

Tilsvarer Scrum: Sprint review er et møte på slutten av en sprint for å vurdere arbeidet som er gjort i forhold til sprintmålet. Dette handler om selve produktet. Fremgangen synliggjøres, og nye innsatsområder identifiseres. Det gjør fremdriften i forhold til produktet og målet transparent.

Den Tilbakeblikk 

I likhet med Scrum: Retrospektivet er et møte som handler om teamets samarbeid. Det handler om å forbedre samarbeidet i teamet og dermed om å forbedre prosesser og innhold. Det handler også om samspillet mellom de enkelte utviklerne, Scrum Master-arbeidet og kommunikasjonen med produkteieren. Dette gjør retrospektivet til en viktig del av en kontinuerlig forbedringsprosess (KVP).

I Large Scale Scrum anbefales det delvis å gjennomføre en «Retro of Retros» – altså overordnet på tvers av mange team.

Large Scale Scrum – Scrum Master-ratio

Hvor mange team bør en Scrum Master ha? Man kan argumentere for at en Scrum Master per team er best – selv om dette også Ulemper har. Som regel ligger Large Scale Scrum Master-ratioen på 1:1 til 1:3 – en Scrum Master har ett til maksimalt tre team.

Når er Large Scale Scrum LeSS den riktige Agile-metoden?

Large Scale Scrum kan brukes hvis du allerede jobber med SCRUM og ønsker å skalere Scrum. Men også for å finne balansen mellom selvorganisering og regler. 

Bas Vodde sa en gang at han og Craig Larman mener at LeSS er en veldig god tilnærming fordi den treffer balansepunktet mellom så mye veiledning som nødvendig og så lite som mulig. 

På samme måte som Scrum er det bare et prosessrammeverk som kan utformes svært individuelt og variert av teamene som bruker det. Dette argumentet virker plausibelt og skiller faktisk Large Scale Scrum (LeSS) fra andre skaleringsrammeverk.

Illustrasjon: Sweet Spot 

Sammenligning: Scrum i stor skala versus Scrum

LeSS bygger videre på Scrum for å støtte bruken av Scrum i en bredere kontekst og skalere det på tvers av større organisasjoner og utover ett team. Det er altså ikke noe enten eller. LeSS er en utvidelse av SCRUM. Så for å innføre LeSS trenger du alltid SCRUM. Det er fornuftig å innføre SCRUM først og deretter gå over til LeSS.

Sammenligning: Large Scale Scrum versus Scaled Agile Framework SAFe®.

Selv om LeSS blir stadig mer populært i selskaper med store programvareutviklingsteam, har også andre skalerte agile rammeverk som Scrum of Scrums eller Scrum @ Scale blitt stadig viktigere. Et av de ledende rammeverkene er Skalert Agile-rammeverk® (SAFe).

Det er mange likheter mellom Large Scale Scrum og Scaled Agile-rammeverket SAFe®. Begge starter for eksempel med å skalere et Scrum-team og inkorporere prinsipper som lean-tenkning, kontinuerlig forbedring og kundefokus. 

3 Kjerneforskjeller mellom Large Scale Scrum og Scaled Agile Framework SAFe®.

  1. Organisasjon: LeSS fokuserer på å forenkle organisasjonsstrukturen ved å være fleksibel og tilpasningsdyktig.
  2. Roller: SAFe har flere roller (noen sier mer “overhead” av denne grunn), inkludert Release Train Engineer (RTE), Solution Train Engineer (STE) og Epic Owners.
  3. Implementering: Scaled Agile-rammeverket SAFe® inneholder prosesser, artefakter og organisatoriske endringer som noen organisasjoner kanskje ikke kan ta i bruk. Derfor må du alltid vurdere hvilket rammeverk som passer for deg og din organisasjon.

For en vellykket innføring av Scrum i stor skala

Vellykket innføring av Large Scale Scrum krever at man bryter med gamle antakelser og endrer bedriftsstrukturen – med alt det eksplosive potensialet på «sjefsnivå» og «ansiktstapet» som en tilsvarende endring medfører. 

Grunnlaget er derfor at alle er villige til å godta denne endringen – se også Modell for endringsledelse ifølge Kotter eller vår artikkel om Agile veikart for transformasjon .

Lag en attraktiv visjon som man jobber mot – og start mange endringsprosjekter samtidig, i betydningen eksperimentering. 

Når det opprinnelige målet er nådd, er endringen gjennomført, og organisasjonen tilpasser seg en ny status quo frem til neste endring er nært forestående. 

Denne klassiske tilnærmingen ligner på den sekvensielle og den “Big Batch”-tilnærming (se Figur 1) av programvareutvikling, der endringer er et unntak, strengt styrt av kontrollorganer.

Ved LeSS-adopsjoner er det ingen endringsinitiativ, altså ingen endringsledere. I LeSS er endringen kontinuerlig gjennom eksperimentering og forbedring – endringen er status quo.

Hva er trinnene for en vellykket implementering?

1. Endre, tilpasse eller forandre teamkulturen.

Vi anbefaler å starte med et Scrum-team først, inntil teamet og organisasjonen har fått tilstrekkelig erfaring med den nye, smidige kulturen og de ansvarlige beslutningstakerne tar initiativ til neste trinn. Dette reduserer også risikoen for en feilslått utvikling.

2. Forbedre samarbeidet innad i teamene

Det skalerte arbeidet med flere team på ett og samme produkt krever innføring av smidige metoder. Praksiser som gjør det enklere for teamene å koordinere seg med hverandre, er spesielt viktige. De første teamene må fortsatt eksperimentere mye som pionerer for resten av organisasjonen. 

Hvis teamene virkelig er frikoblet fra resten av organisasjonen, kan de gjøre tilsvarende raske fremskritt i den. Dette kan gjøres raskere og med mindre risiko innenfor håndterbare rammer.

3. endringer i selskapsstrukturen

Ytterligere vekst i den agile organisasjonen betyr en omstrukturering på alle nivåer. Senest nå må initiativtakeren til endringen involvere ledelsen. Alle nivåer mellom team og bedriftsledelse blir stilt spørsmål ved – og organisasjonsstrukturen blir svært slank. Dette er nok den «mest smertefulle» delen av prosessen, spesielt for ledelsen.

4. Endring i bedriftskulturen

Ved å bruke Scrum- og LeSS-rammeverkene og egnede smidige praksiser i alle deler av virksomheten, oppnår man en smidig kultur i hele organisasjonen. Prosessen stopper aldri opp, for det finnes ingen optimal smidig organisasjon.

En Agile-overgang med Scrum, LeSS og LeSS Huge krever en langsiktig strategi. Den bør derfor ledsages av passende rådgivning og opplæring.

Hvis du fortsatt er på utkikk etter et passende retrobrett, kan artikkelen vår hjelpe deg med emnet: De beste retrobrettene i sammenligning.

Blogg-kategori

Flere artikler om «Skalering av smidighet»

Se alle artikler i denne kategorien
Agil Spotify-modell: Squads, Tribes, Chapters & Guilds forklart

Agil Spotify-modell: Squads, Tribes, Chapters & Guilds forklart

Kort oversikt over Spotify-modellen: Hvordan Squads, Tribes, Chapters og Guilds skalerer smidighet, hvilke roller som er involvert og hva du bør være oppmerksom på når du implementerer.

Agility Health Radar: De 13 mest populære modellene for agile KPIer

Agility Health Radar: De 13 mest populære modellene for agile KPIer

Den amerikanske journalisten og forfatteren Prentice Mulford sa en gang: „Den som gjenkjenner et onde, har allerede nesten kurert det..“ Prentice Mulford Det er derfor ikke så rart at vi tar tempen...

Arbeidsavtaler: 10 eksempler, eksempler og maler

Arbeidsavtaler: 10 eksempler, eksempler og maler

Effektivt samarbeid i team er avgjørende for å lykkes, spesielt i forbindelse med smidige metoder som Scrum. Arbeidsavtaler spiller en avgjørende rolle når det gjelder å skape et tydelig rammeverk...

Scrum-masteren som tjenende leder: 8 tankevekkere

Scrum-masteren som tjenende leder: 8 tankevekkere

Som erfaren psykolog og Scrum Master forstår jeg utfordringene som teamledere står overfor i agile miljøer. Det er ingen enkel oppgave å finne balansen mellom smidighet og lederskap. I dette innleg...

Prestasjonsmål for produktsjefer: 5 tips og eksempler

Prestasjonsmål for produktsjefer: 5 tips og eksempler

Produktsjefer spiller en avgjørende rolle i utviklingen og markedsføringen av produkter. For å lykkes må de sette og følge opp klare resultatmål for produktsjefer. I denne artikkelen tar vi for oss...

Hva er en produkteier i Scaled Agile Framework SAFe? – Tall, data, fakta 

Hva er en produkteier i Scaled Agile Framework SAFe? – Tall, data, fakta 

Vi forklarer hva en Scaled Agile Framework (SAFe) Product Owner er, og introduserer deg for de seks ulike typene produkteiere.

Scrum - hva er det? Enkelt forklart!

Scrum - hva er det? Enkelt forklart!

Du vil gjerne jobbe smidig, men spør deg selv: Hva er egentlig Scrum? Vi forklarer det viktigste, slik at teamet ditt kan jobbe smidig på en vellykket måte!

Kombinere OKR og Scrum: Hvordan det fungerer (workshops, sprintmål og sykluser)

Kombinere OKR og Scrum: Hvordan det fungerer (workshops, sprintmål og sykluser)

Sowohl Scrum als auch OKR erfreuen sich als Frameworks in der agilen Community aktuell großer Beliebtheit. Scrum kommt eher aus der Welt der Softwareentwicklung, OKRs eher aus der Strategie. Aber l...

Agile i stor skala: En sammenligning av de 5 viktigste rammeverkene

Agile i stor skala: En sammenligning av de 5 viktigste rammeverkene

Agile-rammeverk hjelper bedrifter med å levere raskere og mer pålitelig til kundene. Det er ganske enkelt å implementere Agile i de enkelte teamene. Utfordringen er å implementere smidig arbeid i h...

Echometer Nyhetsbrev

Gå ikke glipp av oppdateringer om Echometer og få inspirasjon til smidig arbeid.