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

Forestil dig, at du har 3 agile teams, der arbejder efter Scrum, og du nu ønsker at skalere - Scrum er ikke længere nok. Hvad er næste skridt? Der findes forskellige frameworks til dette, herunder SAFe Nexus og mange andre. I dag ser vi nærmere på LeSS.

LeSS er SCRUM (definition)

Den LeSS-rammeværk forsøger så enkelt som muligt at anvende principperne og idealerne fra Scrum i en større virksomhedskontekst gennem definerede regler og retningslinjer. På grund af sin enkelhed har LeSS fået definitionen eller betegnelsen som et “knapt tilstrækkeligt” framework - men det skal ikke ses i et negativt lys.

7 Fordele ved LeSS-frameworket

Det grundlæggende fokus i LeSS er ikke at skabe endnu en ny ramme. I stedet anvendes Scrum-principperne i mange teams.

Nogle af de fordele, der følger med LeSS kan opnås, er:

1. Lavere implementeringsomkostninger ved at implementere praksisser, som teams allerede bruger i Scrum
2. En produktejersom forstår rammerne og principperne og derefter bygger bro mellem forretningen og de tekniske teams.
3. For den levering af et produkt, vil færre mennesker nødvendigt. LeSS tilføjer ikke eksponentielt flere roller og overhead.
4. Den tilbyder en Fuld produktvisning i fokusområdet
5. Den Holdene er i direkte kontakt med kunden og andre interessenter 
6. Løbende forbedringer faciliteres gennem regelmæssige retros og andre møder, som er grundlæggende processer i Agilen-manifestet.
7. For mange organisationer kan LeSS-tilgangen til skalering af Scrum-teams være det næste logiske skridt på vejen til agil skalering.

Hvordan er LeSS struktureret? En definition

Large Scale Scrum er pr. definition bygget på principper, rammer, retningslinjer og eksperimenter. Illustrationen (kilde: LeSS’ hjemmeside) viser det. Lad os forklare det med et eksempel: 

Principper: Team X udvikler en mobiltelefon. Princippet om at agere transparent er vigtigt for dem. Derfor arbejder de transparent og afholder regelmæssige daglige møder. Derudover ønsker de at finde ud af, præcis hvor de materialer, der er vigtige for mobiltelefonproduktionen, kommer fra - for senere at kunne formidle dette transparent til kunderne. Transparens hele vejen igennem.

rammebetingelser: Samtidig arbejder de løbende på at skabe de rammebetingelser, der gør SCRUM-frameworket ideelt med de agile værdier prædefinerer: Åbenhed, mod, respekt, fokus og engagement.

Vejledende principper: Vejledende principper for udvikling er produktvisionen, de tekniske krav til produktet, men også den måde, man arbejder sammen på i teamet.

Eksperimenter: Når der opstår usikkerhed, er vi i eksperimentområdet, hvor det handler om at teste og afprøve ting. For eksempel hvis vi vil udvikle en ny funktion eller nå ud til en helt ny målgruppe. (Kilde: LeSS’ hjemmeside)

De 10 LeSS-principper

LeSS defineret 10 Principper. De hjælper med - hvis vi holder os til vores eksempel - at udvikle en mobiltelefon, der bedst afspejler kundens værdier og forestillinger. Her er en liste over de 10 principper i et overblik:

1. Scrum i stor skala er Scrum: Mobiltelefonen kan ikke kun udvikles af ét, men af flere teams, så kunden bliver tilfreds, og udviklingstiden er rimelig.
2. Empirisk proceskontrol: Baseret på kortsigtede erfaringer bliver mobiltelefonens individuelle funktioner løbende tilpasset og revideret.
3. Gennemsigtighed: Vores Team X beslutter sig for at dele ugentlige teammål åbent på deres interne platform fra nu af. Det hjælper enormt med at forstå, hvad alle rent faktisk arbejder på.
4. Mere med mindre: Dybest set bør man eksperimentere med nye ideer og lære af dem, før man etablerer inerte regler og dermed tilføjer “ballast”.
5. Fokus på hele produktet: Teams har en endnu større tendens til at suboptimere deres mål, end enkeltpersoner har. Derfor er den største udfordring for teams at integrere deres arbejde i et produkt. “Formålet” med hele produktet bør derfor være så klart som muligt. Teamene og individerne får dermed mulighed for selv at definere passende delmål efter behov.
6. Kunden i centrum: Kun teams, der arbejder direkte med kunden, kan maksimere den reelle værdi af produktet. Desværre har organisationer en tendens til at afbryde forbindelsen mellem teams og kunder, så snart de begynder at vokse. For at modvirke dette bliver kunderne regelmæssigt inviteret med til teammøder for at give feedback.
7. Kontinuerlig forbedring mod perfektion: LeSS er en dybtgående forandring for mange organisationer. Bemærk, at dette ikke automatisk betyder en forbedring. LeSS gør det muligt for organisationen at starte med at blive bedre - og derefter bør man kontinuerligt optimere. LeSS er en proces!
8. Lean-tænkning: LeSS lægger først og fremmest vægt på at se stedet for selve begivenheden (Gemba), læringskonceptet i tre faser ShuHaRi (Shu = efterligne, Ha = variere, Ri = definere dine egne regler) og respekt for mennesker.
9. Systemtænkning: Alle handlinger, ændringer og forbedringer skal altid tænkes systemisk eller systemkonformt for at nå målene. Eksempel: Hvis jeg i et team teoretisk set tilbyder økonomiske bonusser - hvad betyder det for andre teams (dvs. for resten af det organisatoriske system)?
10. Køteori: Den grundlæggende idé er, at vi i softwareverdenen opbygger en masse usynlige køer (f.eks. kravdokumenter, uprøvet software) og næsten ikke bekymrer os om den optimale behandling af disse køer. Vidste du for eksempel, at når udnyttelsen af en ressource stiger fra 50% til 90%, bliver ventetiden på nye opgaver ikke bare fordoblet, men mangedoblet? Så definer WIP-grænser (work-in-progress), undgå multitasking og store arbejdspakker. 

LeSS-rammerne

LeSS tilbyder to konfigurationer: Grundlæggende LeSS for To til otte hold (10 til 50 personer) og LeSS Kæmpe for Mere end otte hold (50 til 6.000 mennesker og mere).

Kilde: Less.works

Det anbefales at starte med Basic LeSS for at eksperimentere, få erfaring og feedback, før man går direkte videre til LeSS Huge. Der er to foreslåede tilgange til at introducere LeSS Huge:

• Start med ét kravområde ad gangen inden for det større produkt, og fokusér kun på det i starten.
• Eller gradvist udvide teamets arbejdsområde, definitionen af Done og produktdefinitionen.

På denne måde kan en virksomhed opbygge teamerfaring med LeSS, ekspandere i et produktområde, opnå de første succeser - og dermed opnå ledelsesmæssig støtte, før LeSS skaleres i hele virksomheden.

I øvrigt, en kort bemærkning i forbindelse med agil transformation: Vil du være sikker på, at I aktuelt prioriterer de rigtige ting i jeres agile transformation? 

Så tag vores modenhedstest for jeres agile transformation - det tager kun 3 minutter. Du får endda et benchmark baseret på over tre hundrede andre deltagere. Se knappen 🙂

Roller og planlægning i LeSS

Basic LeSS fokuserer på teamet og de vigtigste Scrum-roller:

1. Scrum Product Owner, som er ansvarlig for produktets vision og retning.
2. Scrum-udviklingsteams med ansvar for produktskabelse og -levering
3. Scrum Master, som støtter teamet i løbende forbedringer.
4. Lederens rolle, og hvordan han/hun støtter teamet i at fjerne forhindringer eller “hindringer” for løbende forbedringer og selvstændighed (udvidelse til SCRUM).

Huge LeSS supplerer Basic LeSS med følgende roller:

1. LeSS Huge Regional Product Owner støtter Product Owners og er afgørende for at forbinde forretningskrav (økonomi osv.) med udviklingsteams.
2. Area Product Owner er specialiseret i kundeorienterede opgaver og fungerer som produktejer for produktorienterede feature teams.

PBR-møder udvider sprintplanlægningen på tværs af fokusområder gennem en række parallelle LeSS-sprintudførelser. Den løbende kadence af disse møder er nødvendig i hvert sprint for at forstå, diskutere og forfine elementer og forberede sig på fremtidige sprints. De vigtigste aktiviteter på PBR-møder er: 

1. Oprettelse af epics - altså klyngedannelse af store, sammenhængende emneområder; i vores eksempel ville det være sammenlægningen af sprints fra design- og usability-teamet
2. Afklaring og besvarelse af åbne spørgsmål: Alle bør have den samme forståelse af produktet og af kundens og kollegernes ideer.
3. Estimering af størrelsen på user story, risici, afhængigheder: Quasi udledning og detaljeret planlægning af de enkelte emner

Den Sprint-gennemgang

Svarer til Scrum: Sprint review er et møde i slutningen af et sprint, hvor man vurderer det udførte arbejde i forhold til sprintmålet. Det handler om selve produktet. Fremskridt synliggøres, og nye indsatsområder identificeres. Det gør fremskridtene i forhold til produktet og målet gennemsigtige.

Den Tilbageblik 

I lighed med Scrum: Retrospektivet er et møde, der handler om teamets samarbejde. Det handler om at forbedre samarbejdet i teamet og dermed om at forbedre processer og indhold. Det handler også om interaktionen mellem de enkelte udviklere, Scrum Masterens arbejde og kommunikationen med Product Owner. Det gør retrospektivet til en vigtig del af en kontinuerlig forbedringsproces (CIP).

I Large Scale Scrum anbefales det delvist at gennemføre en “Retro of Retros” - altså overordnet på tværs af mange teams.

Large Scale Scrum - Scrum Master Ratio

Hvor mange teams bør en Scrum Master have? Man kan argumentere for, at en Scrum Master pr. team er bedst - selvom dette også Ulemper har. Som regel ligger Large Scale Scrum Master Ratio på 1:1 til 1:3 - en Scrum Master har et til maksimalt tre teams.

Hvornår er Large Scale Scrum LeSS den rigtige Agile-metode?

Large Scale Scrum kan bruges, hvis man allerede arbejder med SCRUM og ønsker at skalere Scrum. Men også for at finde balancen mellem selvorganisering og regler. 

Bas Vodde sagde engang, at han og Craig Larman mener, at LeSS er en rigtig god tilgang, fordi den rammer plet mellem så meget vejledning som nødvendigt og så lidt som muligt. 

Ligesom Scrum selv er det kun en procesramme, der stadig kan designes meget individuelt og forskelligt af de teams, der bruger den. Dette argument virker plausibelt og adskiller faktisk Large Scale Scrum (LeSS) fra nogle andre skaleringsrammer.

Illustration: Det søde sted 

Sammenligning: Scrum i stor skala versus Scrum

LeSS bygger på Scrum for at understøtte brugen af det i en bredere sammenhæng og for at skalere det på tværs af større organisationer og ud over det enkelte team. Så der er ikke noget enten eller-spørgsmål. LeSS er en udvidelse af SCRUM. Så for at introducere LeSS har du altid brug for SCRUM. Det giver mening at introducere SCRUM først og derefter skifte til LeSS.

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

Selvom LeSS bliver mere og mere populært i virksomheder med store softwareudviklingsteams, har andre skalerede agile frameworks som Scrum of Scrums eller Scrum @ Scale også fået større betydning. Et af de førende frameworks er Skaleret Agile-rammeværk® (SAFe).

Der er mange ligheder mellem Large Scale Scrum og Scaled Agile Framework SAFe®. For eksempel starter begge med at skalere et Scrum-team og indarbejde principper som lean-tænkning, løbende forbedringer og kundefokus. 

3 Kerneforskelle mellem Large Scale Scrum og Scaled Agile Framework SAFe®.

1. Organisation: LeSS fokuserer på at forenkle den organisatoriske struktur ved at forblive fleksibel og tilpasningsdygtig.
2. Roller: SAFe har flere roller (nogle siger også mere “overhead” på grund af dette), herunder Release Train Engineer (RTE), Solution Train Engineer (STE) og Epic Owners.
3. Implementering: Scaled Agile-frameworket SAFe® indeholder processer, artefakter og organisatoriske ændringer, som nogle organisationer måske ikke er i stand til at indføre. Så du skal altid se på, hvilket framework der passer til dig og din organisation.

For en vellykket introduktion af Large Scale Scrum

Den succesfulde implementering af Large Scale Scrum kræver et brud med gamle antagelser og en ændring af virksomhedsstrukturen - med alt det eksplosive potentiale på “chefniveau” og det “ansigtstab”, som en sådan ændring medfører. 

Grundlaget er derfor, at alle erklærer sig villige til denne forandring - se også Model for forandringsledelse ifølge Kotter eller vores artikel om Køreplan for Agile-transformation .

Skab en attraktiv vision, som man arbejder hen imod - og start mange forandringsprojekter på én gang i form af eksperimenter. 

Når det oprindelige mål er nået, er forandringen overstået, og organisationen tilpasser sig en ny status quo, indtil den næste forandring er nært forestående. 

Denne klassiske tilgang svarer til de sekventielle og “Big Batch”-tilgang (se Figur) af softwareudvikling, hvor ændringer er en undtagelse, der styres strengt af kontrolorganer.

Ved LeSS-adoptioner er der intet change initiative, altså ingen changemanagere. I LeSS er forandringen kontinuerlig gennem eksperimenter og forbedringer - forandringen er status quo.

Hvad er trinene til en vellykket implementering?

1. at skifte, tilpasse eller ændre teamkulturen

Vi anbefaler, at man starter med et Scrum-team, indtil teamet og organisationen har fået tilstrækkelig erfaring med den nye, agile kultur, og de ansvarlige beslutningstagere igangsætter det næste skridt. Det reducerer også risikoen for en fejlagtig udvikling.

2. forbedre samarbejdet inden for holdene

Det skalerede arbejde med flere teams på et produkt kræver indførelsen af agile metoder. Praksisser, der gør det lettere for teams at koordinere med hinanden, er særligt vigtige. De første teams er stadig nødt til at eksperimentere meget som pionerer for resten af organisationen. 

Hvis teamene virkelig er afkoblet fra resten af organisationen, kan de gøre tilsvarende hurtige fremskridt i den. Det kan gøres hurtigere og med mindre risiko inden for en håndterbar ramme.

3. ændringer i virksomhedsstrukturen

Yderligere vækst i den agile organisation betyder en omstrukturering på alle niveauer. Senest nu skal initiativtageren til forandringen involvere ledelsen. Alle niveauer mellem teams og virksomhedsledelse bliver sat spørgsmålstegn ved - og organisationsstrukturen bliver meget slank. Dette er nok den mest “smertefulde” del af processen, især for ledelsen.

4. Skift i virksomhedskultur

Ved at anvende Scrum- og LeSS-rammeværkerne og passende agile praksisser i alle områder af virksomheden opnås en organisationsdækkende læring af den agile kultur. Processen går aldrig i stå, da der ikke findes nogen optimal agil organisation.

En Agile-overgang med Scrum, LeSS og LeSS Huge kræver en fremsynet strategi. Den bør derfor ledsages af passende rådgivning og træning.

Hvis du stadig er på udkig efter et passende retrobræt, kan vores artikel hjælpe dig med emnet: De bedste retroboards i sammenligning.