Forestill deg at du har 3 agile team som jobber i henhold til Scrum, og nå ønsker du å skalere – Scrum er ikke lenger nok. Hva er neste skritt? Det finnes ulike rammeverk for dette, blant annet SAFeNexus og mange andre. I dag ser vi nærmere på LeSS.
LeSS er SCRUM (definisjon)
Den LeSS-rammeverk forsøker å anvende prinsippene og idealene i Scrum i en stor bedriftskontekst så enkelt som mulig gjennom definerte regler og retningslinjer. På grunn av sin enkelhet har LeSS fått definisjonen eller merkelappen "knapt tilstrekkelig" –, men dette er ikke negativt ment.
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:
- Lavere implementeringskostnader ved å implementere praksiser som teamene allerede bruker i Scrum.
- En produkteiersom forstår rammeverket og prinsippene og deretter bygger bro mellom virksomheten og de tekniske teamene.
- I forbindelse med levering av et produkt, vil færre mennesker nødvendig. LeSS tilfører ikke eksponentielt flere roller og merarbeid.
- Den tilbyr en full produktvisning i fokusområdet
- Den Teamene er i direkte kontakt med kunden og andre interessenter
- Kontinuerlige forbedringer tilrettelegges gjennom regelmessige retrosamtaler og andre møter, som er grunnleggende prosesser i Agilen-manifestet.
- 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. Prinsippet om åpenhet er viktig for dem. Derfor jobber de åpent og lager regelmessige dagbøker. På den annen side ønsker de å finne ut nøyaktig hvor materialene som er viktige for produksjonen av mobiltelefonen kommer fra, slik at de senere kan kommunisere dette åpent til kundene sine. Åpenhet tvers igjennom.
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 – hvis vi holder oss til vårt eksempel – med å utvikle en mobiltelefon som passer best mulig til kundens verdier og ideer. Her er en oversikt over de 10 prinsippene:
- 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.
- Empirisk prosesskontroll: Basert på kortsiktige erfaringer tilpasses og revideres de enkelte funksjonene i mobiltelefonen kontinuerlig.
- Å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.
- 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".
- 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.
- 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.
- Kontinuerlig forbedring mot perfeksjon: LeSS er en dyptgripende endring for mange organisasjoner. Merk at det ikke automatisk betyr forbedring. LeSS gjør det mulig for organisasjonen å begynne å bli bedre –, og deretter bør man kontinuerlig optimalisere. LeSS er en prosess!
- 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.
- Systemtenkning: Alle handlinger, endringer og forbedringer bør alltid tenkes systemisk eller i samsvar med systemet for å nå målene. Et eksempel: Hvis jeg teoretisk sett tilbyr økonomiske bonuser i ett team –, hva betyr det for andre team (dvs. for resten av organisasjonssystemet)?
- 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 et selskap bygge opp et team som har erfaring med LeSS, ekspandere på ett produktområde, oppnå innledende suksess – og dermed få støtte fra ledelsen før LeSS skaleres i hele selskapet.
Forresten, en liten bemerkning i forbindelse med smidig transformasjon: Ønsker du å forsikre deg om at du for øyeblikket er de riktige prioriteringene i din agile Forvandling?
Ta deretter vår modenhetssjekk for din smidige transformasjon – tar bare 3 minutter. Du får til og med en benchmark basert på over tre hundre andre deltakere. Se knappen 🙂.
Roller og planlegging i LeSS
Basic LeSS fokuserer på teamet og de viktigste Scrum-rollene:
- Scrum Product Owner, som er ansvarlig for produktets visjon og retning.
- Scrum-utviklingsteamene som er ansvarlige for produktutvikling og -levering
- Scrum Master, som støtter teamet i arbeidet med kontinuerlig forbedring.
- 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:
- LeSS Huge Regional Product Owner støtter Product Owners og er avgjørende for å koble forretningskrav (økonomi osv.) med utviklingsteamene.
- Area Product Owner spesialiserer seg på kundeorienterte oppgaver og fungerer som produkteier for produktorienterte funksjonsteam.
De fleste Agile-bussene kjører rundt i sirkler....
og behandle overfladiske symptomer. Det er på tide å bruke psykologi – for å oppnå en bærekraftig holdningsendring.
"Hvorfor tar det meg noen ganger flere timer å forberede et enkelt tilbakeblikk?"
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
- Opprettelse av Epics –, dvs. gruppering av store matchende emner; i vårt eksempel vil dette være sammenslåingen av sprintene fra design- og brukervennlighetsteamet.
- Avklaring og besvarelse av åpne spørsmål: Alle bør ha samme forståelse av produktet og ideene til kunden og kollegene.
- 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 storskala Scrum anbefales det noen ganger å gjennomføre en "retro of retros", dvs. på tvers av mange team.
Scrum i stor skala – Scrum Master Ratio
Hvor mange team bør en Scrum Master ha? Det kan argumenteres for at én Scrum Master per team er det beste – selv om dette også er et Ulemper har. Som regel i stor skala er forholdet mellom Scrum Master 1:1 og 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®.
- Organisasjon: LeSS fokuserer på å forenkle organisasjonsstrukturen ved å være fleksibel og tilpasningsdyktig.
- Roller: SAFe har flere roller (noen sier mer "overhead" av denne grunn), inkludert Release Train Engineer (RTE), Solution Train Engineer (STE) og Epic Owners.
- 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
En vellykket implementering av Scrum i stor skala krever at man bryter med hevdvunne antakelser og endrer bedriftsstrukturen – med alt det eksplosive potensialet på "sjefsnivå" og "tap av ansikt" som en tilsvarende endring innebærer.
Utgangspunktet er derfor at alle erklærer seg klare for denne endringen – se også Modell for endringsledelse ifølge Kotter eller vår artikkel om Agile veikart for transformasjon.
Skap en attraktiv visjon for arbeidet mot – og sett i gang mange endringsprosjekter samtidig, i en eksperimentell ånd.
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.
I LeSS er det ikke noe endringsinitiativ, så det finnes ingen endringsledere. I LeSS skjer endring 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
Videre vekst i den smidige organisasjonen krever omstilling på alle nivåer. Senest nå må initiativtakeren til endringen involvere ledelsen. Alle nivåer mellom teamene og toppledelsen utfordres –, og organisasjonsstrukturen blir svært slank. Dette er sannsynligvis 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.
