Hva har teamutvikling og Scrum of Scrums til felles? De handler om vekst og optimalisering av team. I utgangspunktet bør teamet være optimalt utviklet før jeg skalerer agile metoder. Du kan finne ut når et team er optimalt utviklet her eller i våre Bloggartikkel.
Hva er Scrum of Scrums?
Scrum of Scrums er en måte å skalere Scrum på tvers av mange team og, der det er hensiktsmessig, Trains. Andre metoder er for eksempel SAFe, LeSS eller Nexus.
Scrum av Scrums er spesielt vellykket når alle medlemmene i Scrum-teamet jobber mot et felles mål, stoler på og respekterer hverandre og drar lasset sammen. Dette krever teamutvikling på forhånd.
Dommen
"Liten nok til å være kvikk og stor nok til å få viktige oppgaver gjort i en sprint"
du kanskje kjenner til. Så når er det riktige tidspunktet for å skalere opp? Hva er den optimale teamstørrelsen, og hva må du tenke på når du utvikler et team? Finnes det en anbefaling for teamutvikling?
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.
Først historien om Scrum av Scrums
Jeff Sutherland og Ken Schwaber var på utkikk etter en metode som gjorde det mulig å jobbe agilt med flere team. Det var viktig at ikke alle jobbet alene, men at alle jobbet sammen på en koordinert måte. Det var en milepæl innen smidig utvikling. Jeff Sutherland har også skrevet en bok om dette. "Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies".som ble utgitt i 2001.
Scrum of Scrums og de smidige metodenes skalerbarhet har fått stadig større aksept siden den gang. Man kan imidlertid si at covid-19-pandemien trolig har gitt det største løftet for smidig utvikling –, i hvert fall når det gjelder anvendelse på andre områder enn programvareutvikling. I prinsippet kan smidige metoder alltid brukes når krav og teknologier er komplekse. De Stacey Matrix og den Cynefin-rammeverket hjelpe deg med å klassifisere dem. På Scrum@Scale-veiledning finner du all informasjon om skalering.
Som et tips bør du bare skalere når det enkelte teamet fungerer godt sammen og er velfungerende. Hvis du allerede har problemer med Scrum på individuelt teamnivå, bør du ikke skalere. Her er min anbefaling for teamutvikling: Utvikle teamet først og løs problemene før du begynner å skalere.
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 🙂. 
Formålet med Scrum of Scrums
Scrum of Scrum er den første logiske utvidelsen av Scrum når man går fra smidighet i teamet til smidighet i hele selskapet. En avgjørende forutsetning for skalering er riktig teamsammensetning. Følgende spørsmål bør besvares:
- Hvem jobber i hvilken posisjon i teamet?
- Hvem samarbeider med hvem?
- Hvem harmonerer spesielt godt sammen?
- Hvem har hvilken rolle?
Vi har funnet ut at rolleklarhet spiller en svært viktig rolle. Forresten: Hvis du vil vite hvilke virkemidler du kan bruke for å skape innovasjon i et team, kan du ta en titt på denne artikkelen. Video an. Team trenger også alltid nok tid og rom til å utvikle seg. Her kan du også laste ned Tuckman's Fasemodell for teamutvikling for å bli kjent med hverandre:
- Forming (inngangs- og oppdagelsesfasen),
- Storming (tvist- og argumentasjonsfasen)
- Normering (Regulerings- og konvensjonsfasen)
- Opptreden (arbeids- og prestasjonsfasen).
Kilde: Tuckmans fasemodell for teamutvikling
Målet er å koordinere mindre, smidige og selvstendige team som er fullt fokusert på kundenes behov og ønsker. Temaet kundesentrering kan være her liker også å se nærmere på det. Derfor bør du alltid gå til Kundereise av kunden din. Bare vær kunden din og begynn å endre perspektiv. I praksis er det dessverre fortsatt slik at kundene ofte må tilpasse seg prosessene i det samarbeidende selskapet. Det gjelder særlig i offentlige virksomheter, men også i enkelte større selskaper eller konsern. Det er imidlertid ikke tanken bak Scrum.
"Vekst" er ikke det samme som "skalering".
Dominic Price skriver i "Disse fem feilslutningene vil gjøre deg mer innovativ." om de 5 feilslutningene du bør bryte med for å bli mer innovativ.
- "Vekst" er ikke det samme som "skalering".
- "Transformasjon" er ikke det samme som "evolusjon".
- "Forstyrrende" er ikke det samme som "forstyrret".
- "Oppmøtetid" er ikke det samme som "initiativ".
- "Outputs" er ikke det samme som "Outcomes".
For å oppsummere betyr dette: effektivitet er bra, effektivitet er bedre. Vær alltid oppmerksom på effektiviteten.
Erfaringsmessig kan vi si at jo flere som jobber med det samme problemet, desto vanskeligere er det å komme frem til en løsning. Spesielt hvis det dreier seg om tverrfunksjonelle, selvstendige teammedlemmer. Løsningen for team som blir større, er imidlertid skalering. Den Scrum-veiledning gir et grunnlag for team og bedrifter som trenger støtte på dette området. Skalering av Scrum utover individuelle team krever imidlertid en annen tilnærming. Scrum of Scrums-teknikken (SoS-teknologi).
Kilde: RFC-profesjonelle
Struktur og prosess for Scrum of Scrums
Scrum of Scrums teamstruktur
Kommunikasjon er alfa og omega i den smidige verdenen og nøkkelen til suksess. Kommunikasjonskanalene kan fort bli dårligere jo større teamet er. Informasjon kommer feil eller ikke i det hele tatt. Før eller siden går dette også ut over tilliten i teamet, det oppstår en mangel på nærhet, og det blir vanskeligere å forfølge et felles mål.
Målet er å utvikle teamet på en slik måte at alle hindringer er fjernet (Scrum Master), og det er i teamets Flyt fungerer. I teorien kan et "perfekt team" med optimale prestasjoner, i henhold til Forskning utført av Hackman og Vidmar på 4,6 personer. For små team er kanskje ikke tilstrekkelig til å løse et problem. For store team kan på sin side føre til at personlige relasjoner og smidighet i forhold til kundens handlekraft og interesser blir skadelidende.
I noen tilfeller krever det en deling av teamet. Men pass på, det er noen ting du må ta hensyn til her. Du griper inn i et allerede etablert system. Kompetansen mellom teamene må fordeles på en balansert måte, fungerende grensesnitt må omdefineres og oppgaver omfordeles eller omdefineres. Uventede avhengigheter og nye flaskehalser kan forsinke prosessen som helhet. Også her er det viktig å kommunisere åpent og gi teamet tid og rom. Tålmodighet og justering på de riktige stedene er også svært viktig.
Scrum-of-Scrums-teknikken krever koordinering når det dannes flere team. Følgende diagram viser én mulighet:
Kilde: Atlassian
Andre roller i Scrum of Scrums
Chief Product Owner: Chief Product Owner er ansvarlig for den overordnede visjonen for produktet. Han prioriterer produktets backlog og er grensesnittet og talerøret mot kunden.
Scrum of Scrums Master: Han bidrar kontinuerlig til å øke effektiviteten i Scrum of Scrums. Han fokuserer på fremdrift og hindringer som er synlige for de andre teamene, og gir teamet mulighet til å utføre oppgavene sine. Han skal også Tjenende leder kalt.
Scrum of Scrums-møte
Teammedlemmene utnevner en person til å delta på Scrum of Scrums-møtet på vegne av Scrum-teamet. Avhengig av hvor fokuset ligger i prosjektet, kan teamet alltid utnevne en annen representant. Som regel utnevnes den personen som er nærmest temaet. Hvis fokuset er på brukeropplevelse, bør det sendes en representant som er kjent med dette. Hvis fokuset er på testing, bør representanten komme fra testområdet. I noen tilfeller, hvis SOS-teamet blir for lite, kan det være lurt å ha med to representanter per team på møtet. Ofte vil Scrum Master da følge den personen som teamet utpeker. Hvis arbeidet i Scrum of Scrums-møtene koordineres i et møte på et høyere nivå, kalles dette et Scrum of Scrums-møte.
Hyppighet og tidsramme fra Scrum of Scrum-møter
Teamet bestemmer selv hyppigheten av Scrum of Scrum-møtene. For enkelhets skyld holder vi oss til retningslinjene for Scrum of Scrum, som finner sted daglig og vanligvis varer i maksimalt 15 minutter..
Avhengig av størrelse og antall team er det imidlertid ofte snakk om lengre møter som ikke finner sted så ofte. For eksempel 2 til 3 ganger i uken. I motsetning til i det daglige møtet løses problemer som oppstår i Scrum of Scrums-møtet, om mulig direkte, eller de tas i det minste opp. Problemene som oppstår i dette møtet, er svært store og kan raskt berøre mer enn 100 personer.
Agenda for et møte
Kilde: Unsplash
En god agenda for et Scrum of Scrums-møte er agendaen for et Scrum of Scrums-møte. Daglige Scrums veldig like. Siden Scrum of Scrums-møtet ikke finner sted hver dag i praksis, og siden hver person representerer hele teamet sitt i møtet, blir spørsmålene besvart på en litt annen måte:
- Hva har teamet ditt oppnådd siden sist vi møttes?
- Hva skal teamet ditt ha gjort innen neste møte?
- Finnes det hindringer som gjør teamets arbeid vanskelig?
- Kan noe av det laget ditt gjør komme i veien for et annet lag?
Det siste spørsmålet handler i stor grad om prosessen og mulige konsekvenser for andre team. Det kan være svært nyttig å ta stilling til dette spørsmålet. Man vurderer flere scenarier på forhånd for å skape et smidig samarbeid. Det er her silotenkningen så å si brytes ned. Svaret på det siste spørsmålet er spesielt viktig, fordi det er avgjørende at representantene videreformidler funnene til sine egne team.
I tillegg til å svare på spørsmål gir møtet også tid og rom for å diskutere og ta opp eventuelle spørsmål, problemer eller utfordringer som har oppstått tidligere. I møtet dokumenteres fremdriften, og det skapes en felles forståelse. Løsninger og tiltak registreres slik at de kan følges opp.
For å holde seg på et saklig og nøytralt nivå i møtet, nevnes ingen navn i diskusjonene. Lengden på temaene er også tydelig avgrenset fra viktigheten av temaene. Målet er å skape et objektivt syn fra metanivået, men likevel endre perspektivene.
Konklusjon
Scrum of Scrums er derfor en god måte å skalere på hvis dere allerede jobber med Scrum og ønsker å utvikle dere i retning av Enterprise Agility. Hvis du vil lære mer om Scrum Master Performance Evaluation, kan du også ta en titt på denne artikkelen an.
Scrum of Scrums og SAFe – er to forskjellige konsepter.
Scrum of Scrums, SAFe og LeSS er alle forskjellige rammeverk for smidig skalering, med ulike tilnærminger til implementering av lederskap og utarbeidelse av et veikart. Hvis du vil lære mer om de andre konseptene, anbefaler jeg at du leser blogginnleggene våre om SAFe og LeSS å lese.
