Specifika för Agile-teamets arbete i SAFe jämfört med Scrum i praktiken

Efter publiceringen bland vänner av den första artikeln om Burn Down Chart, var den första frågan i kommentarerna: "Det skulle vara intressant att veta mer om er erfarenhet av SAFe". Därför kommer jag i den här artikeln att försöka belysa specifika för arbetet i SAFe jämfört med Scrum i vår praktik. Jag gör absolut inte anspråk på att vara den slutgiltiga sanningen och kommer att vara tacksam för alla rättelser och förtydliganden från kollegor.

Först listar jag punktvis det viktigaste som skiljer arbetet i SAFe från SCRUM, enligt min mening.

• Increment i Scrum och Program Increment i SAFe
• ART - Agile Release Train
• Antal samverkande team
• PIPE
• SOS
• PO - inte ägare av verksamheten
• RTE
• Den femte sprinten för utbildning
• System Demo

Increment i Scrum och Program Increment i SAFe. Egentligen är det olika termer, men det är lätt att blanda ihop dem eftersom ingen hos oss använder termen Program Increment, alla säger bara Increment - och det är redan en annan term, som används i SCRUM. Men i stort sett är de ganska lika sett till innebörd, enligt min mening. Increment i SCRUM - är i princip den aktuella produkten + de planerade historierna för sprinten i utfört tillstånd (som klarat teamets DOD ). Program Increment - är det tidsintervall under vilket tåget (Agile Release Train) levererar inkrementellt värde till produktion. I fråga om längd är det hos oss 4 sprintar på 2 veckor för utveckling och en sprint för utbildning.

Agile Release Train - är ett team av team som arbetar med ett enda värdeflöde. Vi kallar det helt enkelt tåget, men enligt ramverket är det korrekta namnet "Solution". I vårt fall följs inte denna regel fullt ut och teamen arbetar ofta med olika produkter ur teknisk synvinkel, eftersom de flesta affärsfunktioner implementeras komplext och berör flera produkter. Det är den tekniska sidan. Men jag är säker på att någon betraktar alla it-system som ett enda företagsprodukt och att det kanske till och med är mer korrekt.

Antal samverkande team är hos oss i SAFe betydligt fler, sammanlagt rekommenderas upp till 125 personer i ett tåg. Vi har 3 tåg och inte i varje följs denna regel, det finns tåg med fler än 125 personer. SCRUM beskriver inte hur man samverkar med andra team, så vitt jag vet, till skillnad från SAFe, där det finns mycket tydliga rekommendationer om detta. Den mest framträdande artefakten för detta, enligt min mening, är Program Board.

På den visas kopplingarna mellan tågets team och genom att diskutera den hålls de veckovisa mötena Scrum Of Scrums (SOS) hos oss.

Ungefär var 2,5:e månad (var 5:e sprint) inträffar händelsen PIPE - Programm Increment Planning Event. Det är när alla distribuerade team samlas i en och samma sal i 2 dagar och planerar sitt arbete för de kommande 2,5 månaderna. Under denna händelse uppstår artefakter som till exempel Program board, på vilken alla teamens beroenden mellan varandra för varje tåg visas, ovan har jag redan visat hur den ser ut. Scrum Masterns uppgift för varje team vid denna händelse är att facilitera identifieringen av maximalt antal beroenden, sedan om möjligt ta bort dem (genom att till exempel överföra kompetens muntligt från team till team eller genom att flytta ett beroende från ett team till ett annat, så att teamet självständigt kan implementera sin funktion utan att vara beroende av någon). I praktiken är det så det går till hos oss. Först dekomponeras funktionerna till User Story, User Stories fördelas över 4 sprintar. Funktionerna placeras på Program Board och beroenden från andra team läggs in i den mån de finns. Under händelsen diskuteras och korrigeras detta.

SOS - Scrum Of Scrum. Denna händelse äger rum en gång i veckan för varje tåg separat. Scrum Masters för alla tågets team samlas online, tågets Program Board visas och statusen för alla beroenden och funktioner för det specifika tågets team diskuteras. I princip behövs denna händelse för centraliserad synkronisering av teamen inom tåget. Ungefär som en standup, men en gång i veckan och inte för teamet, utan för Scrum Masters.

PO (Produktägare) - inte ägare av verksamheten. Det finns en Product Manager - han arbetar med Business Owner för motsvarande affärsområden och fördelar i princip funktionerna till Produktägarna. Produktägaren arbetar redan direkt i teamet - delar upp funktionerna i User Stories (i vårt fall tillsammans med teamet) och delar inte alltid upp dem, men vi gör ständiga framsteg i den riktningen.

RTE (Release Train Engineer - tågförare. Scrum Master för Scrum Masters. Genomför SOS-evenemang för sitt tåg. Samverkar med Product Manager på feature-nivå. Faciliterar PIPE.

Den femte sprinten för lärande - ja, till skillnad från Scrum har teamet här en hel sprint i slutet av inkrementet avsatt för lärande. Vi använder det i praktiken i första hand för att delta i interna utbildningar, bland annat inom SAFe, men inte bara. Privata kurser och meetups försöker vi planera in på den här tiden när det är möjligt. Vi har också utvecklare som breddar sin kompetens under den femte sprinten, så att det finns möjlighet att täcka upp för någon annans kompetens i teamet (backa upp vid behov).

System Demo. Som ett resultat av PIPE har varje team en lista med mål för inkrementet och vart och ett av dessa mål har bedömts av tågets Business Owner på en 10-gradig skala. Detta kallas Business Value. Målen delas in i huvudsakliga och utökade. Huvudsakliga mål är mål där teamet inte ser några risker att uppnå dem. Utökade är mål med risker för att uppnå dem. Alla mål är obligatoriska och arbetsvolymen planeras för alla mål. På System Demo godkänner Business Owner resultaten av arbetet för inkrementet. Anta att ett team hade 3 huvudsakliga mål med bedömningarna 10, 6, 8 och 2 utökade med bedömningarna 10, 3. Låt oss föreställa oss att Business Owner satte följande bedömningar: 8, 6, 4, 2, 0. Nu kan man beräkna procentandelen uppnådda mål: 100% utgörs av den ursprungliga summan poäng för de huvudsakliga målen, i vårt fall är det 10+6+8=24. Uppnådda poäng räknas med hänsyn till de utökade målen (dvs. 20 av 24 uppnådde teamet), dvs. som ett resultat blir procentandelen uppnådda mål för teamet (20*100)/24 = 83,3%. Ett normalt resultat anses vara att uppnå mellan 80% och 100%.

I allt annat arbetar vi enligt SCRUM. Nåja, eller nästan i allt :) Vad gäller vår erfarenhet: jag kan säga att, från min synvinkel, är utvecklingen uppenbar. Under ett års arbete har teamen vuxit kraftigt, blivit självorganiserande, några team har visserligen fallit samman, men även i det kan man se en viss utveckling. Det finns fortfarande utrymme att växa.

Kommentarer från kollegor på facebook

«Zjenja, hej! Kul att du skriver, bra jobbat! Jag ska bara rätta lite angående tågen - de samlas inte kring produkten, utan kring värdeflödet. Och inom detaljhandeln har vi ur SAFe-synpunkt inte ett tåg, utan en Solution. Bara för att underlätta kommunikationen och förenkla förståelsen fortsätter vi att kalla det tåg)»

– Konstantin Voronin (representant för projektkontoret på Ingosstrach)

«Nå, och kanske någon noterar att ur SAFe-synpunkt sker målbedömningen på I&A; (där SD ingår som en del, men inte är direkt kopplat till bedömningen) och själva SD bör äga rum varje sprint (efter teamens demos). Men vi är ännu långt ifrån det, så vi kallar medvetet allt som det står i din artikel)»

– Konstantin Voronin (representant för projektkontoret på Ingosstrach)

«Zjenja, fortsätt snälla, det är mycket användbart!»

– Aleksej Ionov (Certifierad SAFe-tränare)