Agil deskalering — start forlæns

I 2002 blev jeg introduceret til Extreme Programming. Jeg var dengang en del af et fantastisk godt team hos Danske Bank. Teamet blev suppleret af et par eksterne konsulenter, hvoraf især den ene levede og åndede Extreme Programming. Han åbnede mine øjne for agile, som siden har været et fundament for mig. Det er jeg ham stadig taknemmelig for i dag.

Dengang var der måske 40–50 agile missionærer på verdensplan. Det var dem, man lænede sig op ad. Det var på rigtig mange måder en bottom-up-approach. Det var teams, der i bedste selvorganiserende stil fandt ud af, at agile var skabt til dem. Det var en modreaktion til Rational Unified Process (/RUP), der dengang havde “management hotness”.

Fast forward til i dag. Agile er blevet en hel industri for sig selv, som RUP var dengang. En top-down-approach er den mest udbredte og rigtig mange virksomheder har igangsat agile transformationer.

Skalering vs. deskalering

Det betyder også, at der er opstået nogle nye spørgsmål og behov. Et af de hyppigste spørgsmål er: “Hvordan skalerer vi?”. De senere år er der gradvist kommet flere svar på det spørgsmål, eksempelvis LeSS, Nexus, Scrum@Scale, SAFe, Dad. Agile skalering har “management hotness”.

Svaret på spørgsmålet burde dog som udgangspunkt være et modspørgsmål “Har I forsøgt at deskalere?”.

Skalering handler om at håndtere afhængigheder, både hvad angår produkt, teknologi, mennesker og rammer. Ofte leder det desværre rettere til administration af afhængigheder, hvilket medfører dyrkelse af afhængigheder.

Deskalering handler om kontinuerligt at eliminere afhængigheder. Eksempelvis et teams afhængighed til andre. Her kunne man eksempelvis undersøge: “Er I organiseret korrekt i forhold til jeres produkter og produktstrømme”, “Har I klart definerede løse koblinger og snitflader” eller “Er I et cross-functional team?”.

Deskalering er proces-refaktorering.

Skalering kan blive nødvendigt, men først når man har deskaleret efter alle kunstens regler.

Skalering er helt pragmatisk nødvendigt, når man når det tipping point, hvor det tidsmæssige overhead, der er i forbindelse med ad-hoc håndtering af en afhængighed, som ikke kan elimineres, overgår det overhead, der altid er forbundet med at indføre en ny praktik. Overheadet kan måles i tid, men også manglende fleksibilitet og ja — agilitet.

“Scrum of <indsæt-agil-praktik-her>”

Man kan finde gode skaleringspraktikker i tidligere omtalte frameworks. Mange af dem kan skrives på formlen “Scrum of <indsæt-agil-praktik-her>”. Med det refererer jeg tilbage til de “gamle dage”. Hvis man dengang havde behov for skalering var der et svar: “Scrum of Scrums” eller “Scrum of Daily Scrum” om man vil. Scrum of Scrums løste behovet for at koordinere mellem flere teams med samme mål.

Hvis man i dag dechifrere de nytilkomne frameworks kan rigtigt mange af praktikkerne sættes på samme formel. Et enkelt eksempel herpå er “Scrum of <Sprint Retrospective>“ også kaldet “Inspect & Adapt Workshop” eller “Nexus Sprint Retrospective” eller “Joint Retrospective”. Du kan selv fortsætte øvelsen med de øvrige 10 praktikker i Scrum. Den er faktisk sjov og kan bidrage til et bedre overblik, idet øvelsen afmonterer diverse skaleringsframeworks.

“Hvilken skaleringspraktik skal man så vælge hvornår?”. Tja… skaleringspraktikkerne har det samme formål som deres mindre søskende (dvs. praktikkerne i eksempelvis Scrum). Så praktisk erfaring med disse i ét team er nok en fordel. Så start der.

Agile er baseret på en empirisk procesmodel. Skaleret agile er stadig agile.

Opsummeret er min tilgang til skalering altså følgende:

• Start småt og deskalér afhængigheder som gjaldt det livet
• Scrum udstiller på grusomste vis disse afhængigheder
• Indfør kun en skaleringspraktik hvis overheadet er mindre end den tidsmæssige ad-hoc håndtering af en afhængighed
• Undgå frameworkforvirring. Vælg rette praktik udfra formlen “Scrum of <indsæt-agil-praktik-her>”

Hvis det ender med, at I bruger et komplet skaleringsframework, er det nok rigtigt, men lad nu være med at starte baglæns.

Agile opstod som en modreaktion til RUP. Teams begyndte at arbejde agilt, fordi det virkede, og fordi RUP ikke hjalp dem. I dag har skaleringsframework overtaget RUP’s plads. Modsvaret er nådesløs deskalering og stadig agile.

‍

‍Vil du vide mere om agile? Kom med Backstage!
Hold dig opdateret med den nyeste viden inden for agile og digital produktudvikling. Tilmeld dig 👉🏻 syndicate.dk/backstage

‍