Specyfika pracy zespołu Agile w SAFe względem Scrum w praktyce

Po publikacji wśród znajomych pierwszego artykułu o Burn Down Chart, w komentarzach pierwsze pytanie, jakie zostało zadane: "Ciekawie byłoby dowiedzieć się więcej o waszym doświadczeniu z SAFe". Dlatego w tym artykule postaram się przybliżyć specyfikę pracy w SAFe względem Scrum na naszej praktyce. Z pewnością nie roszczę sobie prawa do prawdy pierwszej instancji i będę wdzięczny za wszelkie poprawki i uściślenia ze strony kolegów.

Najpierw wymienię tezowo najważniejsze rzeczy, które moim zdaniem odróżniają pracę w SAFe od SCRUM.

• Increment w Scrum i Program Increment w SAFe
• ART - Agile Release Train
• Liczba współpracujących zespołów
• PIPE
• SOS
• PO - nie jest właścicielem biznesu
• RTE
• Piąty sprint na naukę
• System Demo

Increment w Scrum i Program Increment w SAFe. W rzeczywistości to różne terminy, ale łatwo się w nich pogubić, ponieważ nikt u nas nie używa terminu Program Increment, wszyscy mówią po prostu Increment - a to już inny termin, który jest używany w SCRUM. Ale ogólnie, moim zdaniem, są one dość podobne pod względem sensu. Increment w SCRUM - to w istocie bieżący produkt + zaplanowane historie na sprint w stanie wykonanym (przeszły DOD zespołu). Program Increment - to przedział czasowy, w ciągu którego pociąg (Agile Release Train) dostarcza przyrostową wartość do produkcji. U nas pod względem długości to 4 sprinty po 2 tygodnie na rozwój i jeden sprint na naukę.

Agile Release Train - to zespół zespołów pracujących nad jednym strumieniem tworzenia wartości. Nazywamy to po prostu pociągiem, ale zgodnie z frameworkiem poprawnie nazywa się to "Solution". W naszym przypadku ta zasada nie jest w pełni przestrzegana i zespoły często pracują nad różnymi produktami z technicznego punktu widzenia, ponieważ większość funkcji biznesowych jest realizowana kompleksowo i dotyczy kilku produktów. To od strony technicznej. Ale jestem pewien, że ktoś uważa wszystkie systemy IT za jeden produkt firmy i być może tak jest nawet poprawniej.

Liczba współpracujących zespołów u nas w SAFe jest znacznie większa, w sumie zaleca się do 125 osób w jednym pociągu. U nas są 3 pociągi i nie w każdym ta zasada jest przestrzegana, są pociągi z liczbą ponad 125 osób. SCRUM nie opisuje, jak współpracować z innymi zespołami, o ile mi wiadomo, w przeciwieństwie do SAFe, gdzie są bardzo jasne zalecenia w tym zakresie. Najbardziej wyraźnym, moim zdaniem, artefaktem do tego jest Program Board.

Pokazuje on powiązania między zespołami pociągu i omawiając go, odbywają się u nas cotygodniowe wydarzenia Scrum Of Scrums (SOS).

Mniej więcej co 2,5 miesiąca (co 5 sprintów) odbywa się wydarzenie PIPE - Programm Increment Planning Event. To wtedy wszystkie rozproszone zespoły zbierają się w jednej sali na 2 dni i planują swoje prace na kolejne 2,5 miesiąca. W trakcie tego wydarzenia pojawiają się takie artefakty jak na przykład Program board, na którym pokazywane są wszystkie zależności zespołów między sobą dla każdego z pociągów, powyżej już pokazałem, jak on wygląda. Zadaniem Scrum Mastera każdego zespołu na tym wydarzeniu jest facylitacja ujawniania maksymalnej liczby zależności, a następnie w miarę możliwości ich usuwanie (poprzez przekazanie kompetencji ustnie, na przykład, od zespołu do zespołu lub poprzez przejęcie zależności od jednego zespołu przez inny, aby zespół mógł autonomicznie zrealizować swoją funkcję, nie zależąc od nikogo). W praktyce u nas tak to właśnie przebiega. Najpierw dekomponuje się funkcje na User Story, User Story rozdziela się na 4 sprinty. Funkcje umieszcza się na Program Board i ustala się zależności od innych zespołów, jakie są. W trakcie wydarzenia jest to omawiane, korygowane.

SOS - Scrum Of Scrum. To wydarzenie odbywa się raz w tygodniu dla każdego pociągu osobno. Scrum Masterzy wszystkich zespołów pociągu zbierają się online, transmitowany jest Program Board pociągu i omawiane są statusy wszystkich zależności i funkcji zespołów konkretnego pociągu. W istocie to wydarzenie jest potrzebne do scentralizowanej synchronizacji zespołów w obrębie pociągu. Coś w rodzaju standupu, ale raz w tygodniu i nie dla zespołu, a dla Scrum Masterów.

PO (Właściciel produktu) - nie jest właścicielem biznesu. Jest Product Manager - on pracuje z Bussiness Owner'ami odpowiednich kierunków biznesu i w istocie rozdaje funkcje Właścicielom produktu. Właściciel produktu pracuje już bezpośrednio w zespole - dzieli funkcje na User Stories (w naszym przypadku wspólnie z zespołem) i nie zawsze dzieli, ale stale się w tym kierunku rozwijamy.

RTE (Release Train Engineer - maszynista pociągu. Scrum Master Scrum Masterów. Prowadzi wydarzenia SOS swojego pociągu. Współpracuje z Product Managerem na poziomie funkcji. Facylituje PIPE.

Piąty sprint na naukę - tak, w odróżnieniu od Scruma, tutaj zespół ma wydzielony cały sprint na końcu przyrostu na naukę. Z reguły w praktyce wykorzystujemy go przede wszystkim na udział w szkoleniach wewnętrznych, w tym również z SAFe, ale nie tylko. Kursy prywatne i meetupy staramy się w miarę możliwości planować na ten czas. Mamy też deweloperów, którzy rozszerzają swój stack w ciągu 5. sprintu, aby była możliwość pokrycia czyichś kompetencji w zespole (zabezpieczenia w razie potrzeby).

System Demo. W wyniku PIPE każdy zespół ma listę celów na przyrost i każdy z tych celów jest oceniony przez Business Ownera pociągu w 10-stopniowej skali. Nazywa się to Business Value. Cele te dzielą się na główne i rozszerzone. Cele główne - to cele, w których zespół nie widzi żadnych ryzyk w osiągnięciu. Rozszerzone - to cele z ryzykami osiągnięcia. Wszystkie cele są obowiązkowe i zakres prac jest planowany pod wszystkie cele. Na System Demo Business Owner przyjmuje wyniki pracy za przyrost. Załóżmy, że zespół miał 3 cele główne z ocenami 10, 6, 8 i 2 rozszerzone z ocenami 10, 3. Wyobraźmy sobie, że Business Owner postawił odpowiednio oceny następujące: 8, 6, 4, 2, 0. Teraz można obliczyć procent osiągnięcia celów: za 100% bierze się początkową sumę punktów za cele główne, w naszym przypadku to 10+6+8=24. Osiągnięte punkty liczone są z uwzględnieniem rozszerzonych celów (tj. 20 z 24 zespół osiągnął), tj. w rezultacie procent osiągnięcia celów przez zespół będzie (20*100)/24 = 83,3%. Normalnym wynikiem jest osiągnięcie od 80% do 100%.

We wszystkim innym pracujemy według SCRUM. No, albo prawie we wszystkim :) Co do naszego doświadczenia: mogę powiedzieć, że z mojego punktu widzenia ewolucja jest oczywista. W ciągu roku pracy zespoły mocno urosły, stały się samoorganizujące się, niektóre zespoły, co prawda, się rozpadły, ale i w tym widać pewną ewolucję. Rosnąć też jest jeszcze gdzie.

Komentarze kolegów z facebooka

«Żenia, cześć! Super, że piszesz, brawo! Trochę poprawię o pociągach - zbierają się one nie wokół produktu, a wokół strumienia tworzenia wartości. A w retailu u nas z punktu widzenia SAFe nie pociąg, a Solution. Po prostu dla wygody komunikacji i uproszczenia zrozumienia, dalej nazywamy to pociągiem)»

– Konstantin Woronin (przedstawiciel biura projektowego Ingosstracha)

«No i może ktoś zauważy, że z punktu widzenia SAFe ocena celów odbywa się na I&A; (gdzie SD wchodzi jako część, ale bezpośrednio z oceną nie jest związany) a same SD powinny odbywać się co sprint (po demo zespołów). Ale my na razie jesteśmy od tego daleko, dlatego świadomie nazywamy wszystko tak, jak jest napisane u ciebie w artykule)»

– Konstantin Woronin (przedstawiciel biura projektowego Ingosstracha)

«Żenia, kontynuuj, proszę, bardzo przydatne!»

– Aleksiej Ionow (Certyfikowany trener SAFe)