Vad har teamutveckling och Scrum of Scrums gemensamt? De handlar om tillväxt och optimering av team. Innan jag skalar upp agila metoder bör teamet alltså vara optimalt utvecklat. Du kan se när ett team är optimalt utvecklat här eller i vår Bloggartikel.
Vad är Scrum of Scrums?
Scrum of Scrums är ett sätt att skala upp Scrum över många team och, i förekommande fall, Trains. Andra metoder är till exempel SAFe, LeSS eller Nexus.
Scrum av Scrums är särskilt framgångsrikt när alla Scrum-teamets medlemmar arbetar mot ett gemensamt mål, litar på och respekterar varandra och drar åt samma håll. Detta kräver att teamet utvecklas i förväg.
Domen
"Liten nog för att vara snabbfotad och stor nog för att få viktiga uppgifter gjorda i en sprint"
kanske du känner till. Så när är det rätt tid att skala upp? Vad är den optimala teamstorleken och vad behöver du tänka på när du utvecklar ett team? Finns det någon rekommendation för teamutveckling för detta?
Innan vi går djupare, en snabb kommentar. Vi hade nyligen 11 internationella agila experter som gäster i ett webinar – om en fråga: Hur skalar man agila metoder på rätt sätt?
Resultatet är denna fantastiska videoinspelning (engelska), som bland annat tar upp följande frågor:
- Är det bättre att börja nedifrån och upp eller uppifrån och ned?
- Hur får man ledare att enas om en gemensam vision?
- Hur väljer man rätt agile framework – och varför är det egentligen inte så viktigt?
Min varmaste rekommendation: Ta en titt! Det tar relativt lång tid, men det är värt varenda minut.
Först berättelsen om Scrum of Scrums
Jeff Sutherland och Ken Schwaber letade efter en metod som skulle göra det möjligt att arbeta agilt med flera team. Det viktiga här var att inte alla jobbar för sig själva, utan att alla jobbar tillsammans på ett koordinerat sätt. Det var en milstolpe inom agil utveckling. Jeff Sutherland skrev också boken om detta. "Agile Can Scale: Att uppfinna och återuppfinna SCRUM i fem företag".som utkom 2001.
Scrum of Scrums och de agila metodernas skalbarhet har fått allt större acceptans sedan dess. Man kan dock säga att covid-19-pandemin förmodligen har gett den största drivkraften till agil utveckling – åtminstone för dess tillämpning på andra områden än mjukvaruutveckling. I princip kan agila metoder alltid tillämpas när krav och teknik är komplexa. Den Stacey Matrix och Cynefin-ramverket hjälpa dig att klassificera dem. Vid Guide för Scrum@Scale hittar du all information om skalning.
Som ett tips bör du bara skala när ditt individuella team arbetar bra tillsammans och fungerar. Om du redan har problem med Scrum på den individuella teamnivån bör du inte skala. Min rekommendation för teamutveckling här: Utveckla teamet först och ta itu med dess problem innan du börjar skala.
Förresten, en snabb kommentar i samband med agil omvandling: Vill du se till att du för närvarande är rätt prioriteringar i din agila organisation Förvandling?
Ta sedan vår mognadskontroll för din agila transformation – tar bara 3 minuter. Du får även ett riktmärke baserat på över trehundra andra deltagare. Se knappen 🙂 . 
Syftet med Scrum of Scrums
Scrum of Scrum är den första logiska förlängningen av Scrum när man går från agilitet i teamet till agilitet i ett helt företag. En avgörande förutsättning för skalning är rätt teamsammansättning. Följande frågor bör besvaras:
- Vem arbetar på vilken position i teamet?
- Vem arbetar med vem?
- Vilka harmonierar särskilt bra tillsammans?
- Vem har vilken roll?
Vi har funnit att rollklarhet spelar en mycket avgörande roll. Förresten: Om du vill veta vilka hävstänger du kan använda för att skapa innovation i ett team, kolla in det här Video an. Team behöver också alltid tillräckligt med tid och utrymme för att utvecklas. Här kan du också ladda ner Tuckmans Fasmodell för teamutveckling för att lära känna varandra:
- Formning (inlednings- och utredningsfasen),
- Stormning (tvist- och argumentationsfasen)
- Normering (Reglerings- och konventionsfas)
- Utförande (arbets- och prestationsfas).
Källa: Tuckmans fasmodell för teamutveckling
Målet är att samordna mindre, smidiga och självständiga team som är helt fokuserade på kundernas behov och önskemål. Ämnet kundcentrering kan vara här också vill titta på det mer i detalj. Därför bör du alltid gå till Kundresan av din kund. Var bara din kund och påbörja en förändring av perspektivet. I praktiken är det tyvärr fortfarande ganska vanligt att kunder måste anpassa sig till det samarbetande företagets processer. Särskilt inom offentliga myndigheter, men även inom vissa större företag eller koncerner. Men det är inte det som är tanken med Scrum.
"Tillväxt" är inte detsamma som "skalning".
Dominic Price skriver i "Att lära sig dessa fem felaktigheter kommer att göra dig mer innovativ" om de 5 felslut du bör frigöra dig från för att bli mer innovativ.
- "Tillväxt" är inte detsamma som "skalning".
- "Transformation" är inte detsamma som "evolution
- "Störande" är inte samma sak som "störd".
- "Närvarotid" är inte detsamma som "initiativ
- "Outputs" är inte detsamma som "Outcomes".
Sammanfattningsvis betyder detta: effektivitet är bra, ändamålsenlighet är bättre. Var alltid uppmärksam på effektiviteten.
Av erfarenhet kan vi säga att ju fler som arbetar med samma problem, desto svårare är det att komma fram till en lösning. Särskilt om de är tvärfunktionella, autonoma teammedlemmar. Lösningen för team som blir allt större är dock skalning. Den Scrum-guide utgör en grund för team och företag som behöver stöd inom detta område. Att skala upp Scrum utöver enskilda team kräver dock ett annat tillvägagångssätt. Tekniken Scrum of Scrums (SoS-teknik).
Källa: Professionella inom RFC
Struktur och process för Scrum of Scrums
Scrum av Scrums teamstruktur
Kommunikation är A och O i den agila världen och nyckeln till framgång. Kommunikationskanalerna kan snabbt bli lidande ju större teamet är. Information kommer fram felaktigt eller inte alls. Förr eller senare påverkar detta också förtroendet för teamet, det saknas närhet och det blir mer utmanande att sträva mot ett gemensamt mål.
Målet är att utveckla teamet på ett sådant sätt att alla hinder undanröjs (Scrum Master) och det är i Flöde fungerar. I teorin är ett "perfekt team" med optimal prestanda, enligt Forskning av Hackman och Vidmar på 4,6 personer. För små team kanske inte räcker till för att lösa ett problem. Med för stora team blir i sin tur de personliga relationerna och smidigheten i förhållande till kundens handlingsförmåga och intressen lidande.
I vissa fall kräver det en uppdelning av teamet. Men se upp, det finns några saker att tänka på här. Du ingriper i ett redan etablerat system. Kompetenserna mellan teamen bör fördelas på ett balanserat sätt, fungerande gränssnitt måste omdefinieras och uppgifter omfördelas eller omdefinieras. Oväntade beroenden och nya flaskhalsar kan försena processen som helhet. Även här är det viktigt att kommunicera öppet och ge teamet tid och utrymme. Tålamod och anpassning på rätt ställen är också mycket viktigt.
Scrum-of-Scrums-tekniken kräver samordning när flera team bildas. Följande diagram visar en möjlighet:
Källa: Atlassian
Andra roller i Scrum of Scrums
Chefsproduktägaren: Chefsproduktägaren ansvarar för den övergripande visionen för produkten. Han prioriterar produktbackloggen och är gränssnittet och språkröret till kunden.
Scrum of Scrums Master: Han bidrar permanent till en högre effektivitet i Scrum of Scrums. Han fokuserar på framsteg och hinder som är synliga för andra team, stärker och stöder teamet i att fullgöra sina uppgifter. Han kommer också att Tjänande ledare kallad.
Möte om Scrum of Scrums
Teammedlemmarna utser en person som ska delta i Scrum of Scrums-mötet på uppdrag av Scrum-teamet. Beroende på var fokus ligger inom projektet kan teamet alltid utse en annan representant. I regel utses den person som är närmast ämnet. Om fokus ligger på användarupplevelse bör en representant skickas som är bekant med detta. Om fokus ligger på testning bör representanten komma från testområdet. I vissa fall, om SOS-teamet blir för litet, kan det vara lämpligt att låta två representanter per team delta i mötet. Ofta kommer då Scrum Mastern att följa med den person som teamet utsett. Om arbetet i Scrum of Scrums-mötena koordineras i ett möte på en högre nivå kallas detta ett Scrum of Scrums-möte.
Frekvens och tidsram från Scrum av Scrum-möten
Teamet bestämmer frekvensen för Scrum of Scrum-mötet. För enkelhetens skull håller vi oss till riktlinjerna för Scrum of Scrum, som äger rum dagligen och vanligtvis varar i högst 15 minuter..
Beroende på storlek och antal team handlar det dock ofta om längre möten som inte äger rum så ofta. Till exempel 2 till 3 gånger i veckan. Till skillnad från i det dagliga mötet löses problem som uppstår i Scrum of Scrums-mötet direkt om möjligt eller åtminstone adresseras. Problem som uppstår i detta möte är mycket betydande problem och kan snabbt påverka mer än 100 personer.
Dagordning för ett möte
Källa: Unsplash
En bra agenda för ett Scrum of Scrums-möte är agendan för ett Dagliga Scrums mycket lika. Eftersom Scrum of Scrums-mötet inte äger rum varje dag i praktiken och eftersom varje person representerar hela sitt team i mötet, besvaras frågorna på ett något annorlunda sätt:
- Vad har ditt team åstadkommit sedan vi sågs sist?
- Vad ska ditt team ha gjort till nästa möte?
- Finns det hinder som försvårar teamets arbete?
- Kan något som ditt team gör komma i vägen för ett annat team?
Den sista frågan här handlar mycket om processen och den möjliga påverkan på andra team. Att ta upp denna fråga kan vara till stor hjälp. Man överväger flera scenarier i förväg för att skapa ett smidigt samarbete. Det är här som silotänkandet praktiskt taget bryts ned. Svaret på den sista frågan är särskilt viktigt, eftersom det är absolut nödvändigt att representanterna vidarebefordrar resultaten till sina egna team.
Förutom att besvara frågor ger mötet också tid och utrymme för att diskutera och ta itu med eventuella frågor, problem eller utmaningar som har uppstått tidigare. Under mötet dokumenteras framstegen och en gemensam förståelse skapas. Lösningar och åtgärder registreras så att de kan följas upp.
För att hålla sig på en saklig och neutral nivå under mötet nämns inga namn i diskussionerna. Ämnenas längd är också tydligt avgränsad från ämnenas betydelse. Syftet är att skapa en objektiv bild från metanivå, men ändå att byta perspektiv.
Slutsats
Så Scrum of Scrums är ett bra sätt att skala om du redan arbetar med Scrum och vill gå vidare mot företagsagilitet. Om du vill veta mer om Scrum Master Performance Evaluation kan du också ta en titt på denna artikel an.
Scrum of Scrums och SAFe – två olika koncept
Scrum of Scrums, SAFe och LeSS är alla olika ramverk för agil skalning, med olika tillvägagångssätt för att implementera ledarskap och bygga en färdplan. Om du vill lära dig mer om de andra koncepten rekommenderar jag att du läser våra blogginlägg om SAFe och LeSS att läsa.
