Forestil dig, at du har 3 agile teams, der arbejder i henhold til Scrum, og nu vil du skalere – Scrum er ikke længere nok. Hvad er det næste skridt? Der findes forskellige rammer for dette, herunder SAFeNexus og mange andre. I dag ser vi nærmere på LeSS.
LeSS er SCRUM (definition)
Den LeSS-rammeværk forsøger at anvende Scrums principper og idealer i en stor virksomhedssammenhæng så enkelt som muligt gennem definerede regler og retningslinjer. På grund af sin enkelhed er LeSS blevet defineret som en "knap nok tilstrækkelig" ramme –, men det er ikke for at sætte den 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:
- Lavere implementeringsomkostninger ved at implementere praksisser, som teams allerede bruger i Scrum
- En produktejersom forstår rammerne og principperne og derefter bygger bro mellem forretningen og de tekniske teams.
- For den levering af et produkt, vil færre mennesker nødvendigt. LeSS tilføjer ikke eksponentielt flere roller og overhead.
- Den tilbyder en Fuld produktvisning i fokusområdet
- Den Holdene er i direkte kontakt med kunden og andre interessenter
- Løbende forbedringer faciliteres gennem regelmæssige retros og andre møder, som er grundlæggende processer i Agilen-manifestet.
- For mange organisationer kan LeSS-tilgangen til skalering af Scrum-teams være det næste logiske skridt på vejen til agil skalering.
Før vi går i dybden, en hurtig bemærkning. Vi havde for nylig 11 internationale agile eksperter som gæster i et webinar – om et spørgsmål: Hvordan skalerer man agile metoder ordentligt?
Resultatet er denne fantastiske videooptagelse (engelsk), som bl.a. behandler følgende spørgsmål:
- Er det bedre at starte nedefra og op eller oppefra og ned?
- Hvordan får man ledere til at enes om en fælles vision?
- Hvordan vælger man det rigtige agile framework –, og hvorfor er det egentlig ikke så vigtigt?
Min varmeste anbefaling: Tag et kig! Det tager relativt lang tid, men det er hvert minut værd.
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 er ved at udvikle en mobiltelefon. Princippet om at handle gennemsigtigt er vigtigt for dem. Derfor arbejder de gennemsigtigt og laver regelmæssige dagbøger. På den anden side ønsker de at finde ud af, hvor præcis de materialer, der er vigtige for produktionen af mobiltelefonen, kommer fra, så de senere kan kommunikere dette gennemsigtigt til deres kunder. Gennemsigtighed 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 –, hvis vi bliver ved vores eksempel –, med at udvikle en mobiltelefon, der bedst muligt matcher kundens værdier og ideer. Her er listen over de 10 principper i et overblik:
- 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.
- Empirisk proceskontrol: Baseret på kortsigtede erfaringer bliver mobiltelefonens individuelle funktioner løbende tilpasset og revideret.
- 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å.
- 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".
- 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.
- 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.
- Kontinuerlig forbedring mod perfektion: LeSS er en dybtgående forandring for mange organisationer. Bemærk, at det ikke automatisk betyder forbedring. LeSS gør det muligt for organisationen at begynde at blive bedre –, og fra da af bør man løbende optimere. LeSS er en proces!
- 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.
- Systemtænkning: Alle handlinger, ændringer og forbedringer skal altid tænkes systemisk eller i overensstemmelse med systemet for at nå målene. Et eksempel: Hvis jeg teoretisk set tilbyder økonomiske bonusser i et team –, hvad betyder det så for andre teams (dvs. for resten af organisationssystemet)?
- 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, udvide inden for et produktområde, opnå indledende succes – og dermed modtage ledelsesstøtte, før LeSS skaleres i hele virksomheden.
Forresten, en hurtig bemærkning i forbindelse med agil transformation: Vil du sikre dig, at du i øjeblikket er de rigtige prioriteter i din agile Transformation?
Så tag vores modenhedstjek for din agile transformation – 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:
- Scrum Product Owner, som er ansvarlig for produktets vision og retning.
- Scrum-udviklingsteams med ansvar for produktskabelse og -levering
- Scrum Master, som støtter teamet i løbende forbedringer.
- 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:
- LeSS Huge Regional Product Owner støtter Product Owners og er afgørende for at forbinde forretningskrav (økonomi osv.) med udviklingsteams.
- Area Product Owner er specialiseret i kundeorienterede opgaver og fungerer som produktejer for produktorienterede feature teams.
De fleste Agile Coaches går rundt i cirkler ....
...og behandle overfladiske symptomer. Det er på tide at bruge psykologi – til en bæredygtig holdningsændring.
Møder i LeSS
Den Forbedring af Product Backlog (PBR) Møde
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:
- Oprettelse af Epics –, dvs. gruppering af store matchende emner; i vores eksempel ville dette være sammenlægningen af sprints fra Design & Usability Team.
- Afklaring og besvarelse af åbne spørgsmål: Alle bør have den samme forståelse af produktet og af kundens og kollegernes ideer.
- 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 Scrum i stor skala anbefales det nogle gange at udføre en "retro of retros", dvs. på tværs af mange teams.
Scrum i stor skala – Scrum Master Ratio
Hvor mange teams skal en Scrum Master have? Man kan argumentere for, at én Scrum Master pr. team er bedst –, selvom det også er Ulemper har. Som regel Scrum Master-forholdet i stor skala er 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®.
- Organisation: LeSS fokuserer på at forenkle den organisatoriske struktur ved at forblive fleksibel og tilpasningsdygtig.
- 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.
- 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
En vellykket implementering af Large Scale Scrum kræver, at man bryder med hævdvundne antagelser og ændrer virksomhedsstrukturen – med alt det eksplosive potentiale på "chefniveau" og "tab af ansigt", som en tilsvarende ændring medfører.
Udgangspunktet er derfor, at alle erklærer sig klar til denne forandring – se også Model for forandringsledelse ifølge Kotter eller vores artikel om Køreplan for Agile-transformation.
Skab en attraktiv vision om at arbejde hen imod –, og start mange forandringsprojekter på én gang i eksperimentets ånd.
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.
I LeSS-adoptioner er der ikke noget forandringsinitiativ, så der er ingen forandringsledere. I LeSS sker forandring løbende 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 omstrukturering på alle niveauer. Senest nu skal initiativtageren til forandringen involvere ledelsen. Alle niveauer mellem teams og topledelse bliver udfordret –, 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.
