Hvad har teamudvikling og Scrum of Scrums til fælles? De beskæftiger sig med vækst og optimering af teams. Før jeg skalerer agile metoder, skal teamet grundlæggende være optimalt udviklet. Du kan finde ud af, hvornår et team er optimalt udviklet her eller i vores Blogartikel.
Hvad er Scrum of Scrums?
Scrum of Scrums er en måde at skalere Scrum på tværs af mange teams og, hvor det er relevant, Trains. Andre metoder er for eksempel SAFe, LeSS eller Nexus.
Scrum af Scrums er særligt vellykket, når alle Scrum-teamets medlemmer arbejder mod et fælles mål, stoler på og respekterer hinanden og trækker på samme hammel. Det kræver teamudvikling på forhånd.
Dommen
"Lille nok til at være adræt og stor nok til at få vigtige opgaver udført i en sprint"
du måske kender. Så hvornår er det rigtige tidspunkt at skalere op? Hvad er den optimale teamstørrelse, og hvad skal du overveje, når du udvikler et team? Findes der en anbefaling til teamudvikling?
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.
Først historien om Scrum of Scrums
Jeff Sutherland og Ken Schwaber ledte efter en metode, der kunne gøre det muligt at arbejde agilt med flere teams. Det vigtige her var, at ikke alle arbejder for sig selv, men at alle arbejder sammen på en koordineret måde. Det var en milepæl inden for agil udvikling. Jeff Sutherland har også skrevet en bog om det. "Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies".som udkom i 2001.
Scrum of Scrums og de agile metoders skalerbarhed er blevet mere og mere accepteret siden da. Man kan dog sige, at COVID-19-pandemien nok har givet det største skub til agil udvikling – i det mindste til anvendelse inden for andre områder end softwareudvikling. I princippet kan agile metoder altid anvendes, når krav og teknologier er komplekse. Den Stacey Matrix og den Cynefin-rammeværk hjælpe dig med at klassificere. På Scrum@Scale-vejledning finder du alle oplysninger om skalering.
Som et tip bør du kun skalere, når dit individuelle team arbejder godt sammen og fungerer. Hvis du allerede har problemer med Scrum på det individuelle teamniveau, bør du ikke skalere. Min anbefaling til teamudvikling her: Udvikl teamet først og løs dets problemer, før du begynder at skalere.
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 🙂 
Formålet med Scrum of Scrums
Scrum of Scrum er den første logiske udvidelse af Scrum, når man går fra agilitet i teamet til agilitet i en hel virksomhed. En afgørende forudsætning for skalering er den rigtige teamsammensætning. Følgende spørgsmål bør besvares:
- Hvem arbejder i hvilken position i teamet?
- Hvem arbejder sammen med hvem?
- Hvem harmonerer særligt godt sammen?
- Hvem har hvilken rolle?
Vi har fundet ud af, at rolleklarhed spiller en meget afgørende rolle. Forresten: Hvis du vil vide, hvilke løftestænger du kan bruge til at skabe innovation i et team, så se her Video an. Teams har også altid brug for tid og plads til at udvikle sig. Her kan du også downloade Tuckmans Fasemodel til teamudvikling at lære hinanden at kende:
- Formning (indgangs- og opdagelsesfase),
- Stormen (tvist- og argumentationsfase)
- Normering (Regulerings- og konventionsfasen)
- Udførelse (arbejds- og præstationsfase).
Kilde: Tuckmans fasemodel for teamudvikling
Målet er at koordinere mindre, smidige og selvstændige teams, der er fuldt fokuserede på kundernes behov og ønsker. Emnet kundecentrering kan være her også gerne se mere detaljeret på det. Derfor bør du altid gå til Kunderejsen af din kunde. Bare vær din kunde og start et perspektivskifte. I praksis er kunderne desværre stadig ret ofte nødt til at tilpasse sig den samarbejdende virksomheds processer. Især i offentlige myndigheder, men også i nogle større virksomheder eller selskaber. Men det er ikke ideen med Scrum.
"Vækst" er ikke det samme som "skalering".
Dominic Price skriver i "Aflæring af disse fem fejlslutninger vil gøre dig mere innovativ" om de 5 fejlslutninger, du bør frigøre dig fra for at blive mere innovativ.
- "Vækst" er ikke det samme som "skalering".
- "Transformation" er ikke det samme som "evolution".
- "Foruroligende" er ikke det samme som "forstyrret".
- "Tilstedeværelsestid" er ikke det samme som "initiativ".
- "Outputs" er ikke det samme som "Outcomes".
Kort sagt betyder det: Effektivitet er godt, effektivitet er bedre. Vær altid opmærksom på effektiviteten.
Af erfaring kan vi sige: Jo flere mennesker, der arbejder på det samme problem, jo sværere er det at finde en løsning. Især hvis de er tværfunktionelle, selvstændige teammedlemmer. Men løsningen for teams, der bliver større, er skalering. Den Scrum-guide giver et fundament for teams og virksomheder, der har brug for støtte på dette område. Skalering af Scrum ud over individuelle teams kræver dog en anden tilgang. Scrum of Scrums-teknikken (SoS-teknologi).
Kilde: RFC professionelle
Struktur og proces i Scrum of Scrums
Scrum of Scrums teamstruktur
Kommunikation er alfa og omega i den agile verden og nøglen til succes. Kommunikationskanalerne kan hurtigt lide skade, jo større teamet er. Information kommer forkert eller slet ikke frem. Før eller siden påvirker det også tilliden i teamet, der opstår en mangel på nærhed, og det bliver mere udfordrende at forfølge et fælles mål.
Målet er at udvikle teamet på en sådan måde, at alle forhindringer er fjernet (Scrum Master), og det er i Flow fungerer. I teorien kan et "perfekt team" med optimal præstation i henhold til Forskning af Hackman og Vidmar på 4,6 personer. For små teams er måske ikke tilstrækkelige til at løse et problem. Til gengæld lider personlige relationer og smidighed i forhold til klientens handlekraft og interesser under for store teams.
I nogle tilfælde kræver det en opdeling af teamet. Men pas på, der er nogle ting, du skal overveje her. Du griber ind i et allerede etableret system. Kompetencerne mellem teamene skal fordeles på en afbalanceret måde, fungerende grænseflader skal omdefineres, og opgaver skal omfordeles eller omdefineres. Uventede afhængigheder og nyopståede flaskehalse kan forsinke processen som helhed. Også her er det vigtigt at kommunikere åbent og give teamet tid og plads. Tålmodighed og tilpasning på de rigtige steder er også meget vigtigt.
Scrum-of-Scrums-teknikken kræver koordinering, når der dannes flere teams. Det følgende diagram viser en mulighed:
Kilde: Atlassian
Andre roller i Scrum of Scrums
Chief Product Owner: Chief Product Owner er ansvarlig for den overordnede vision for produktet. Han prioriterer produktets backlog og er grænsefladen og talerøret til kunden.
Scrum of Scrums Master: Han bidrager permanent til en højere effektivitet i Scrum of Scrums. Han fokuserer på fremskridt og forhindringer, der er synlige for andre teams, styrker og støtter teamet i at udføre deres opgaver. Han vil også Tjenende leder kaldet.
Scrum of Scrums-møde
Teammedlemmerne udpeger en person til at deltage i Scrum of Scrums-mødet på vegne af Scrum-teamet. Afhængigt af hvor fokus ligger i projektet, kan teamet altid udpege en anden repræsentant. Som regel udpeges den person, der er tættest på emnet. Hvis fokus er på brugeroplevelsen, skal der sendes en repræsentant, som er fortrolig med dette. Hvis fokus er på test, bør repræsentanten komme fra testområdet. I nogle tilfælde, hvis SOS-teamet bliver for lille, kan det være tilrådeligt at have to repræsentanter pr. team til at deltage i mødet. Ofte vil Scrum Masteren så ledsage den person, der er udpeget af teamet. Hvis arbejdet på Scrum of Scrums-møderne koordineres på et møde på et højere niveau, kaldes det et Scrum of Scrums-møde.
Hyppighed og tidsramme fra Scrum af Scrum-møder
Teamet bestemmer hyppigheden af Scrum of Scrum-møderne. For enkelhedens skyld holder vi os til retningslinjerne for de daglige møder, som finder sted dagligt og normalt varer maksimalt 15 minutter..
Afhængigt af størrelsen og antallet af teams er det dog ofte længere møder, der ikke finder sted så ofte. For eksempel 2 til 3 gange om ugen. I modsætning til det daglige møde bliver problemer, der opstår på Scrum of Scrums-mødet, løst direkte, hvis det er muligt, eller i det mindste adresseret. Problemer, der opstår på dette møde, er meget betydelige problemer og kan hurtigt påvirke mere end 100 mennesker.
Dagsorden til et møde
Kilde: Unsplash
En god dagsorden for et Scrum of Scrums-møde er dagsordenen for et Daglige scrums meget ens. Da Scrum of Scrums-mødet ikke finder sted hver dag i praksis, og da hver person repræsenterer hele sit team på mødet, bliver spørgsmålene besvaret på en lidt anden måde:
- Hvad har dit team opnået, siden vi sidst så hinanden?
- Hvad vil dit team have gjort inden næste møde?
- Er der forhindringer, der gør teamets arbejde vanskeligt?
- Kan noget af det, dit hold gør, komme i vejen for et andet hold?
Det sidste spørgsmål her handler i høj grad om processen og den mulige indvirkning på andre teams. Det kan være meget nyttigt at adressere dette spørgsmål. Det overvejer flere scenarier på forhånd for at skabe et gnidningsfrit samarbejde. Det er her, silotænkningen praktisk talt nedbrydes. Svaret på det sidste spørgsmål er særligt vigtigt, fordi det er bydende nødvendigt, at repræsentanterne videregiver resultaterne til deres egne teams.
Ud over at besvare spørgsmål giver mødet også tid og plads til at diskutere og tage fat på eventuelle spørgsmål, problemer eller udfordringer, der er opstået tidligere. På mødet dokumenteres fremskridt, og der skabes en fælles forståelse. Løsninger og handlinger registreres, så der kan følges op på dem.
For at forblive på et faktuelt og neutralt niveau i mødet, nævnes der ingen navne i diskussionerne. Emnernes længde er også klart afgrænset fra emnernes vigtighed. Målet er at skabe et objektivt syn fra metaniveauet, men stadig at ændre perspektiver.
Konklusion
Så Scrum of Scrums er en god måde at skalere på, hvis du allerede arbejder med Scrum og ønsker at bevæge dig i retning af enterprise agility. Hvis du vil vide mere om Scrum Master Performance Evaluation, kan du også tage et kig på denne artikel an.
Scrum of Scrums og SAFe – - to forskellige koncepter
Scrum of Scrums, SAFe og LeSS er alle forskellige rammer for agil skalering, med forskellige tilgange til implementering af lederskab og opbygning af en køreplan. Hvis du vil lære mere om de andre koncepter, anbefaler jeg, at du læser vores blogindlæg om SAFe og LeSS at læse.
