Skalere Agil – Sådan kommer du i gang

By Majken Vildrik Thougaard | 15. marts 2020 | Comments 0 Comment

At skalere agil er et emne der synes at poppe op flere og flere steder. PÅ IT-konferencer, blandt ledelsen og når HR starter med at rekruttere en ny medarbejder. Men det at skalere agil er ikke bare én specifik og veldefineret ting der skal gøres. Der findes en længere liste af agile skaleringsrammeværk, kombinationer af rammeværk og metoder opbygget inde i organisationer. Og ja, det har stor betydning hvordan du starter med at skalere agil.

Skalere Agil - nøglen er at starte rigtigt — Skalere Agil – nøglen er at starte rigtigt

Skalere agil – at starte bedst muligt med at skalere agil er nøglen til succes med den skalerede agile rejse.

Skalere agil er et område at færdigheder der kan tillæres, ligesom addition i matematik i folkeskolens små klasser. Men mens addition er entydigt defineret og følger logiske regler (2 + 3 = 5, altid), er det at skalere agil hverken entydigt defineret eller følger en logik, som addition.

Inden vi fordyber os i at skalere agil, ser vi først på hvad agil er.

Agil

Ordet agil er ikke nyt og bruges almindeligt i sproget. Ok, måske mere almindeligt på engelsk end på dansk (omend det faktisk kommer fra latin agilis).

Ifølge Den Danske Ordbog ordnet.dk, har ordet agil følgende betydning og oprindelse

OPRINDELSE fra latin agilis, afledt af agere ‘bevæge, handle’

hurtig, let og smidig i sine bevægelser SPROGBRUG sjældent

SYNONYMER bevægelig, adræt

I relation til udvikling af IT-løsninger er et mere udbredt udgangspunkt det agile manifest

Rækken af agile teknikker er lang, men de mest udbredte er Scrum, Kanban og XP, om end flere anvendes i Danmark. Helt overordnet kan man sige at hvis et produkt udvikles agilt, er der kun et team der arbejder på det, om end der naturligvis er undtagelser.

Ligesom der er flere måder at organisere arbejdet agilt (fx om det er organiseret omkring en iteration eller ikke), er der tilsvarende flere måder at skalere agil udvikling.

En helt central forskel til agil på team niveau, er at mere end et team arbejder med det samme produkt. Om det så er 5-8 teams, 25 teams eller 1000 teams der arbejder med samme produkt, afhænger af selve produktets definition. Ved bredere produktdefinitioner er der typiske flere teams der arbejder på samme produkt, hvilket giver mulighed for at håndtere synergier og afhængigheder indenfor produktets domæne. Smalle produktdefinitioner medfører typisk at der er flere produkter i organisationen.

Vi vil nu bevæge os videre ind i det at skalere agil, og de væsentlige skalerede agile rammeværk. Med væsentlige rammeværk til at skalere agil, følger vi listen over hvad de danske organisationer bruger, som afdækket af VILMA Consulting i undersøgelsen du kan læse mere om her.

Hvilke niveauer er der ved at skalere agil

En helt central forskel mellem agil for et (eller få) team(s) og det at skalere agil, er der kun er et niveau når vi taler agil på team-niveau. Der er ikke en porteføljestyring ‘ovenpå’ eller ‘omkring’ teamet. Med andre ord, er det den direkte kontakt mellem stakeholdere og Product Owner der bidrager til indholdet i teamets Product Backlog. Eftersom hvert produkt udvikles af ét team, vil eventuel koordinering mellem teams være koordinering mellem produkter og ikke indenfor et produkt. I det følgende kalder vi dette agil på team-niveau.

Når vi i stedet ser på skaleret agil organisering, bliver koordinering indenfor produktet nødvendig, eftersom flere teams trækker opgaver fra den samme Product Backlog der dækker produktet. Denne Product Backlog dækker opgaver til flere teams, og repræsenterer derfor et højere niveau. Det hyppigste er at se at opgaver for en gruppe på 4-8 teams samlet på denne Product Backlog, men eksempler på grupper med både 10 og 11 teams findes.

Denne gruppering kan gentages for derved at skabe endnu et niveau og derved kan vi se organiseringer med 3, 4, eller endnu flere niveauer for at skalere agil i en organisation. Dette er opstillet herunder.

Niveau 1: Teams (fx 5 teams)
Niveau 2: Gruppe af teams (fx 5 x 5 teams = 25 teams)
Niveau 3: Gruppe af niveau 2-grupper (fx 5 x 25 teams = 125 teams)
Niveau 4: Gruppe af niveau 3-grupper (fx 5 x 125 teams = 625 teams)
Niveau 5: Gruppe af niveau 4-grupper (fx 5 x 625 teams = 3,125 teams)
etc.

Hvis hvert team består af 6 personer i gennemsnit, vil niveau 4 svare til 3.750 personer, mens niveau 5 vil rumme 18.750 personer, såfremt antallet af teams er som i eksemplet herover.

Rammeværk til at skalere agil

Der er grundlæggende tre måder at skalere agil på i en organisation; 1) implementer et veldefineret rammeværk til at skalere agil. 2) Definér jeres egen måde at skalere agil på. Og sidst men ikke mindst, 3) skab en hybrid af de to foregående. I Danmark har vi eksempler på alle tre måder at takle udfordringen, som beskrevet i artiklen Skalerede Agile Organisationer i Danmark 2019, som du kan læse her https://www.vilma-consulting.dk/da/artikler/.

De mest udbredte rammeværk til at skalere agil, er SAFe, Nexus, Scrum@Scale og LeSS, som alle er fremkommet mellem 2011 og 2018. Vi vil herfra fokusere på disse.

Nexus

Nexus blev udviklet af Ken Schwaber (medskaber af Scrum) sammen med en gruppe hos Scrum Inc. Nexus rammeværket har været til rådighed siden 2015.

Nexus er en videreudvikling af of Scrum, og er skabt ved at gentage de mekanismerne i Scrum for flere teams og på to niveauer i organisationen. Med andre ord er Nexus baseret på at, mekanismerne der virker for et team, kan virke for en gruppe af teams.

Kort fortalt virker rammeværket til at skalere agil ved at have op til 8 teams i en ”Nexus” (gruppe af teams), hvor de alle arbejder ud fra den samme Product Backlog med kun en Product Owner til alle teams. Team medlemmer fra alle teams deltager i klargøring af backlog emner (refinement). Alle teams leverer et samlet og integreret klar-til-kunden produktudvidelse (shipable product increment), der fremvises til den fælles Nexus Sprint Review. For løbende af inspicere og forbedre, holder teamet dagligt møde (Daily Standup) efter at Nexus’en har holdt et dagligt møde (Nexus Daily Standup) og dertil inspektionsmøder (Retrospective) efter hvert sprint på både team- og Nexus-niveau.

Nexus rammeværket til at skalere agil. — Gengivet fra Scrum.org med accept. Materialet kan findes her (engelsk)
https://www.scrum.org/resources/online-nexus-guide. Copyright Scrum.org.

Nexus kan anvendes for 2 niveauer (team + grupper af teams), mens Nexus+ kan anvendes for 3 niveauer, ved at kombinere flere parallelle Nexus-er.

Den struktur der anvendes til at skalere agil i et rammeværk er designet til at optimere for en udvalgt parameter. I dette tilfælde er Nexus designet til at optimere for realiseret værdi. Med andre ord er formålet med at anvende Nexus til at skalere agil, at maksimere den realiserede værdi via den klar-til-kunden produktudvidelse der er resultatet af iterationen.

Scrum@Scale

Scrum@Scale blev udviklet af Jeff Sutherland (medskaber af Scrum). Scrum@Scale rammeværket har været til rådighed siden 2018.

Scrum@Scale er en videreudvikling af Scrum, og er skabt ved at gentage de mekanismerne i Scrum for flere teams og på flere niveauer i organisationen. Med andre ord er Scrum@Scale baseret på at, de mekanismer der virker for et team, kan virke for en gruppe af teams og hele vejen op til C-level i en organisation.

Kort fortalt virker rammeværket ved at have op til 5 teams i en gruppe (team of teams). Hvert team har deres egen Product Owner og Product Backlog, hvor opgaver flyder fra Product Backloggen for team-of-teams (niveau 2) til teamets Product Backloggen (niveau 1). Team medlemmer deltager i klargøring af opgaver (refinement) på team niveau.

På hvert niveau er der mindst en Product Owner med sin Product Backlog. Konkret er der en Product Owner (PO) for hvert team (niveau 1), en Chief Product Owner (CPO) for hvert team-of-teams (niveau 2), en Chief Chief Product Owner (CCPO) for hvert Team-of-Team-of-team (Level 3) etc. Og dertil er der for hver Product Owner (PO, CPO, CCPO etc) en Product Backlog.

Alle Product Ownere arbejder i Product Owner cirklen fra strategisk vision (fra højeste niveau) til prioriteret Product Backlog på alle niveauer klar til teamets sprint planlægning (Sprint Planning). Derved sikres til enhver tid, konsistens fra visionen til hvert teams prioriterede backlog.

Alle teams leverer et integreret klar-til-kunden produktudvidelse, der demonstreres til teamets Sprint Review ved iterationens afslutning. For løbende af inspicere og forbedre, holder teamet dagligt møde (Daily Standup) efterfulgt af Scrum-of-Scrums (niveau 2), Scrum-of-Scrum-of-Scrum (niveau 3) og gennem alle niveauer op til øverste niveau. Som eksempel vil en organisation med 3.750 personer afholde 4 standup møde á 15 minutter (60 minutter ialt) for at eskalere problemer fra team til øverste niveau.

Ydermere afholdes inspektionsmøder (Retrospective) efter hvert sprint på team-niveau.

Gengivet fra Scrumatscale.com med accept. Materialet kan findes her (engelsk) https://www.scrumatscale.com. Copyright Scrum Inc, Scruminc.com

Scrum@Scale virker i princippet for et vilkårligt antal niveauer fra 2 og opefter.

Den struktur der anvendes til at skalere agil i et rammeværk er designet til at optimere for en udvalgt parameter. I dette tilfælde er Scrum@Scale designet til at optimere for realiseret værdi. Med andre ord er formålet med at anvende Scrum@Scale til at skalere agil, at maksimere den realiserede værdi via den klar-til-kunden produktudvidelse der er resultatet af iterationen.

LeSS (Large Scale Scrum)

LeSS (Large Scale Scrum) blev udvikle t af Craig Larman og Bas Wodde og rammeværket er offentliggjort i 2014. LeSS er en videreudvikling af de strukturer der virker for teams i Scrum, kombineret med organisations design, systemisk design og principper fra Lean.

Udgangspunktet for LeSS er at reducere organisationens kompleksitet (de-skalere organisationen), forud for at organisationen skaleres. Derved reduceres mængden af kompleksitet, interne bindinger og afhængigheder, som derved ydermere bidrager til at den skalerede agile organisation bliver mindre kompleks.

LeSS er centreret omkring en Product Owner der har det fulde ansvar. Fra ide til klar-til-kunden produkt, arbejder Product Owner og teamet på ideen, mens relevante stakeholdere kaster lys over relevante detaljer. Helt konkret betyder det at teamet er langt mere involveret i klargøringsprocessen (refinement) fra første ide til at opgaven er klar til at trække ind i sprintet.

Alle teams leverer et samlet integreret klar-til-kunden produkt, som bliver demonstreret på det fælles Sprint Review, der afslutter sprintet.

For løbende af inspicere og forbedre, holder teamet dagligt møde (Daily Standup) og teams koordinerer med andre teams løbende og efter behov. Dertil afholdes inspektionsmøder (Retrospective) efter hvert sprint for både team (Niveau 1) og team-of-team (niveau 2).

Gengivet fra LeSS.works med accept. Materialet kan findes her (engelsk) https://less.works/. Copyright LeSS.works

LeSS er opbygget omkring de to niveauer team og gruppe af teams, mens LeSS Huge kan anvendes til at indeholde tre niveauer (Niveau 1 – 3), der fortsat er underlagt en fuldt ansvarlig Product Owner med en samlet Product Backlog.

Den struktur der anvendes til at skalere agil i et rammeværk, er designet til at optimere for en udvalgt parameter. Det skalerede agile rammeværk LeSS, er mere fleksibelt, da organisationen reorganiseres, designes og LeSS derfor kan optimere efter den ønskede parameter, fx realiseret værdi, beskæftigelse til alle (business), fortrolighed (secrecy) eller anden relevant parameter.

SAFe (Scaled Agile Framework)

SAFe Scaled Agile Framework, blev udviklet af Dean Leffingwell og var det første offentligt tilgængelige rammeværk til at skalere agil, da det blev offentliggjort i 2011. Den nuværende version 5.0 er frigivet i 2020. SAFe kombinerer Lean og agile principper i et sæt lean-agile principper der er en del af fundamentet. SAFe er det eneste af rammeværkerne der implementerer det at skalere agil på både team niveau (Niveau 1) og gruppe af teams niveau (Niveau 2) parallelt.

SAFe starter med organisationens porteføljelag og Lean Portfolio Management, hvor målet er at have en trimmet organisation (lean enterprise) med klare beskrivelser af roller og ansvar. SAFe er ikke direkte linket til Scrum eller Kanban, da alle teams selv frit kan vælge arbejdsmetode, så længe de er kompatible med faste kadence der er fælles for gruppen af teams. Kadencen er oftest fastsat som 2-ugers sprints, sammensat i en længere planlægningshorisont (PI) på fem 2-ugers sprints. Der planlægges i SAFe både for sprint (sprint planning) og laves klar forventningsdannelser for PI’en (PI Planning).

Full SAFe overblik. — Gengivet fra Scaledagileframework.com med accept. Materialet kan findes her (engelsk)
https://www.scaledagileframework.com. Copyright Scaledagile Inc

Overbliksbilledet for SAFe findes ikke kun som en, men i hele fire versioner, afhængig af størrelsen af organisationen. Ovenfor er vist den samlede version Full SAFe, der de dækker 4 niveauer (Niveau 1-4). Dertil findes versionen Essential SAFe for 2 niveauer (Niveau 1-2) og to versioner for tre niveauer (Niveau 1-3) Portfolio SAFe og Large Solution SAFe.

Den struktur der anvendes til at skalere agil i et rammeværk, er designet til at optimere for en udvalgt parameter. I dette tilfælde er SAFe designet til at optimere for Outcome. Med andre ord er formålet med at anvende SAFe til at skalere agil, at maksimere outcome via den klar-til-kunden produktudvidelse der er resultatet af iterationen.

Andre rammeværk

Udover de allerede nævnte rammeværk til at skalere agil, er der et antal organisationer der har ladet sig inspirere af den struktur der tidligere blev anvendt hos Spotify. Strukturen er ikke beskrevet i samme detaljeringsgrad som de ovenstående rammeværker, ligesom de personer der har bidraget til opbygningen af dem ikke anser dem for at være rammeværk. Deres måde at arbejde med skaleret agile r beskrevet i videoer fx denne og denne på YouTube.

De hybrider af andre skalerede agile rammeværk vi ser, kombinerer ofte en struktur for team niveauet med en eller flere strukturer på porteføljeniveauet. Der er ikke en klar opskrift for hybriderne, men flere af dem lader sig inspirere af Lean Portfolio Mangement.

Men hvilken måde til at skalere agil skal vi så vælge

Det er netop 100.000kr spørgsmålet vi ofte hører, når vi taler om at skalere agil. Men før vi kommer frem til at kunne besvare det, skal vi først identificere jeres mål med at skalere agil. Hvad er det I gerne vil opnå?

Når jeres mål er kendt, er I klar til at undersøge om 1) Skal/kan I de-skalere organisationen og opnå målet? 2) Skal/kan I starte med at indføre agile arbejdsgange på team niveau (Niveau 1) og opnå/komme nærmere målet? Sidst men ikke mindst, 3) Kan skaleret agil hjælpe jer med at opnå/komme nærmere målet?

På trods af de forholdsvist enkle spørgsmål, bør disse trin ikke udelades. På samme måde som I ikke ville springe over et trin i en modenhedsmodel.

Nu til svaret om hvilket skaleret agilt rammeværk I bør vælge. Og svaret er at det kommer an på jeres kontekst. Der findes desværre hverken universelt korrekte eller universelt forkerte rammeværk. Det rammeværk der er ”bedst” for jer, vil være det rammeværk der bedst bringer jer tættest på målet. Og målene er ikke ens på tværs af organisationer, landegrænser, brancher eller forretningsmodeller.

Anbefalinger

VILMA Consulting anbefaler at før I starter på en agile transformation, at afdække hvorfor I vil være en skaleret agil organisation. Hvad specifikt ønsker I at opnå (målet) ved at være en skaleret agil organisation, samt hvorvidt I kan de-skalere organisationen for at opnå målet.

Som det næste skridt, anbefaler vi at sammenligne 3-4 forskellige skalerede agile rammeværk, hvor I inddrager både risiko, omkostningsaspektet og dette menneskelige aspekt ved at gå igennem en transformation. Sammenligningen kan opstilles som en business case for hvert skaleret agilt rammeværk, hvorved sammenligning på tværs af rammeværk bliver understøttet.

Når I derefter er klar til at begynde den skalerede agile rejse, selve transformationen, er I samtidig blevet bedre klædt på til at lave den første backlog, transitions-backloggen. Denne prioriteres efter evnen til at bringe jer tættere på jeres mål.

Vi er i VILMA Consulting klar til at hjælpe jer med alle disse skridt. Og samtidig ønsker vi jer:

Held og lykke med at starte – eller fortsætte, jeres agile transformation!

Majken Vildrik Thougaard, Uafhængig Agile Specialist & Ejer af VILMA Consulting

PS: Hvis I har startet jeres skalerede agile transformation for et stykke tid siden, er der stadig god inspiration at hente fra de øvrige skalere agile rammeværk. Det kan fx være hvis I er interesseret i Continuous Learning…