Agile Scaling: SAFe Best Practices for Scrum Masters

Ten artykuł jest częścią drugiej serii skalowania Agile firmy Toptal, mającej na celu pokierowanie kierownikami projektów w ich wysiłkach na rzecz rozbudowy zespołów. Przeczytaj pierwszą część, „Porównano 5 frameworków Agile Scaling Framework: którego należy użyć?” aby uzyskać szczegółowy przegląd najpopularniejszych opcji.

W miarę jak produkty rosną i stają się bardziej złożone, rozwijają się również zespoły, które je produkują. Kiedy nadchodzi czas na skalowanie, wiele firm przechodzi ze Scrum do Scaled Agile Framework (SAFe), systemu wdrażanego na poziomie przedsiębiorstwa i umożliwiającego firmom zarządzanie wieloma złożonymi produktami, które wymagają rozwoju zespołów zespołów.

Mistrz Scrum przechodzący do frameworka SAFe wkroczy do środowiska, które jest jednocześnie znajome i nowe. Artefakty, role i ceremonie oparte są na Scrumie. Jednak działanie na większą skalę wiąże się z pewnymi dodatkowymi obowiązkami, szczególnie dla mistrzów Scrum, którzy decydują się na przejście na rolę inżyniera pociągu wydania (RTE), co jest wspólną trajektorią. RTE działa jako Scrum master całego zestawu wydań. Zamiast kierować zespołem Scrumowym składającym się z dziewięciu do 11 osób, RTE stają się sługami-liderami zespołów zespołów obejmujących wiele działów i organizują wydarzenia o większym rozmiarze i zakresie.

Podstawy: Scrum do SAFe

SAFe pozwala firmie stosować podejścia, wartości i zasady Agile w wielu zespołach. Powstały „zespół zespołów” jest znany jako Agile Release Train (ART). Poszczególne zespoły nadal zatrudniają Scrum mastera do prowadzenia działalności jak zwykle, podczas gdy rolę podobną do Scrummastera w ART pełni RTE. RTE stosuje ogólne mechanizmy i zarządzanie Scrum, ale na poziomie organizacyjnym, a nie zespołowym. Inne tradycyjne role i artefakty Scrum na poziomie zespołu również się odpowiednio zmieniają. Na przykład „właściciel produktu” ART zostaje menedżerem produktu; „backlog produktu” staje się backlogiem programu; „backlog sprintu” to backlog iteracji; a „przyrost produktu” jest teraz przyrostem programu (PI).

Istnieją cztery konfiguracje SAFe — Essential, Large Solution, Portfolio i Full — a ta, z której korzystasz, zależy od tego, w jakim stopniu Twoja firma stosuje tę platformę. Konfiguracje umożliwiają wdrażanie na wielu poziomach, od kilku współpracujących zespołów po pełną integrację portfela i elastyczność biznesową w całym przedsiębiorstwie. Jednak na każdym poziomie celem pozostaje skalowanie praktyk Agile i Scrum, a nie ich zastępowanie.

Scrum Masters w SAFe

Scrum masterzy pracujący w ramach SAFe na poziomie zespołu przekonają się, że ich praca nie różni się znacząco. Pozostaną sługą-liderem zespołu Agile, odpowiedzialnym za coaching i edukację, usuwanie przeszkód i wspieranie środowiska, w którym członkowie zespołu czują się bezpiecznie, aby osiągać najlepsze wyniki i stale się doskonalić.

Pojawią się jednak nowe obowiązki. Mistrz SAFe Scrum wspiera RTE w zdarzeniu planowania PI i realizacji programu oraz reprezentuje swój zespół na spotkaniach synchronizacji ART. Gdy istnieją przeszkody, których zespół nie jest w stanie usunąć, mistrz Scrum eskaluje je do RTE.

Mistrz Scrum, który zdecyduje się zostać RTE, przekona się, że jego rola wymaga zdecydowanie więcej rozważań. ART może obejmować zespoły, które są dla Ciebie nowe lub nowe w Agile, takie jak analiza biznesowa, sprzęt lub zgodność. A ponieważ wyższe konfiguracje SAFe obejmują operacje programowe lub portfelowe, kierownictwo będzie bezpośrednio i regularnie zaangażowane w sposób, w jaki nie byłoby to w Scrumie, upewniając się, że wszystko jest zgodne z celami na poziomie przedsiębiorstwa i/lub portfela.

RTE jest odpowiedzialny za usuwanie przeszkód, które przekraczają możliwości pojedynczego zespołu. Komunikują się z interesariuszami i napędzają ciągłe doskonalenie na poziomie ART. RTE szkoli nie tylko zespoły, ale także liderów tych zespołów, pomagając na wszystkich poziomach ART w kierunku samoorganizacji i samozarządzania.

BEZPIECZNE WYDARZENIA

Tak jak mistrz Scrum ułatwia zdarzenia na poziomie zespołu, RTE ułatwia zdarzenia na poziomie ART — planowanie PI, synchronizację ART, demo systemu oraz inspekcję i adaptację. Jako RTE będziesz angażować się w szerszy wachlarz interesariuszy niż jako mistrz Scrum i zarządzać wieloma zespołami o sprzecznych zainteresowaniach. Na każdym wydarzeniu jest więcej – i bardziej zróżnicowanych – uczestników i musisz dostosować priorytety i uzyskać wpisowe do inicjatyw z dużym wyprzedzeniem.

Planowanie PI

Wydarzenie związane z planowaniem PI jest niezbędną ceremonią dla SAFe, gigantycznej dwudniowej sesji, która ma na celu wyrównanie celów wszystkich zespołów w ramach ART na następne 8 do 12 tygodni poprzez stworzenie planu PI. To jak wydarzenie planowania sprintu, ale obejmuje wiele sprintów w wielu zespołach.

Wejścia

• Wizja biznesowa
• Lista 10-15 najważniejszych funkcji do wdrożenia
• Szczegóły dotyczące zdolności każdego zespołu

Wyjścia

• Plan PI (plan dostawy na następne pięć do sześciu sprintów)
• Cele PI
• Lista potencjalnych zagrożeń

Ogólne wskazówki dotyczące wydarzenia PI Planning

• Uzyskaj wpisowe interesariuszy. Przed spotkaniem RTE powinny ustalić, kim są kluczowi interesariusze i podzielić się swoimi uwagami z grupą.
• Wyrównaj priorytety. Przed sesją zaplanuj całodniowe spotkanie z zespołem zarządzającym produktem, aby uzgodnić ogólny obraz tego, jakie funkcje powinny zostać dostarczone, a także przyszłe priorytety. Na wydarzeniu będzie wiele do wypracowania, jak ryzyka i zależności, i dobrze jest mieć podstawową umowę kierunkową.
• Odbywać próby! Planowanie PI to wielkie wydarzenie. Spędzenie dwóch pełnych dni na próbach może nie być przydatne, ale dwu- lub czterogodzinna sesja z liderami zespołów ART, która tworzy doświadczenie tak bliskie, jak to możliwe, bardzo pomoże. Stwórz uproszczoną wersję programu wydarzenia i udostępnij go przed próbą, aby trening mógł rozpocząć się w dobrze poinformowanym miejscu.
• Przygotuj się na pełzanie misji. Celem planowania PI jest dostarczenie długoterminowego planu w stosunkowo krótkim czasie. Czasami ludzie będą chcieli szczegółowo omówić wszystko, co nie jest celem imprezy. Wyjaśnij to liderom zespołów na próbie i podczas sesji; Przypomnij zespołom, że celem jest dostarczanie planów na wysokim poziomie i tworzenie wyrównania, a nie planowanie każdej minuty w ciągu najbliższych trzech miesięcy.
• Przygotuj informacje o zdolnościach zespołu. Poproś mistrzów Scrum o przedstawienie obliczeń wydajności na następne 8–12 tygodni. Spodziewaj się reakcji lub pytań; na przykład mistrz Scrum może nie wiedzieć dokładnie, ile nieobecności będzie miał jego zespół w ciągu najbliższych dwóch miesięcy. W takich przypadkach poproś o szacunki i bądź elastyczny, odpowiadając na ograniczenia przepustowości podczas samego PI.
• Podziel się planem planowania PI. Roześlij harmonogram co najmniej dwa tygodnie przed wydarzeniem i przygotuj się na odpowiedź na wiele pytań. Będzie wielu uczestników, a jeśli SAFe jest nowy dla Ciebie i Twojej firmy, to prawdopodobnie jest też nowy dla wielu innych członków zespołu. Z mojego doświadczenia wynika, że ​​przed drugim lub trzecim wydarzeniem planowania PI presja na moderatorów staje się znacznie mniej intensywna, ponieważ zespoły zapoznają się z wydarzeniem i wiedzą, czego się spodziewać.
• Bezpieczna obecność kierownictwa. Menedżerom lub menedżerom wyższego szczebla często trudno jest uczestniczyć w dwudniowym wydarzeniu, ale obecność kierownictwa jest koniecznością, aby zapewnić zgodność na wysokim szczeblu. Potwierdź ich obecność co najmniej dwa tygodnie przed planowaniem PI i zorganizuj wszelką pomoc, jakiej będą potrzebować. To samo dotyczy właścicieli firm, którzy muszą podpisać się na celach PI.

ART Sync

Wydarzenie synchronizacji ART to cotygodniowe spotkanie, podczas którego RTE może uzyskać wgląd w postępy zespołów i zidentyfikować zagrożenia związane z programem i przeszkody. Chociaż nie jest to jedyna okazja dla RTE do oceny przeszkód i określenia, czy wymagają one eskalacji, jest to ważne wydarzenie, które zapewnia regularne miejsce do poruszania tych kwestii.

Wejścia

• Postępy zespołów
• Dziennik przeszkód
• Plan PI (w celu zidentyfikowania wszelkich większych odchyleń między planem a rzeczywistym postępem)

Wyjścia

• Eskalacje (jeśli wymagane)
• Decyzje o wszelkich zmianach w planie PI

Ogólne wskazówki dotyczące wydarzenia ART Sync

• Zachęcaj do regularnej komunikacji. Ponieważ synchronizacja ART odbywa się co tydzień, a nie codziennie, jak stand-upy Scrum, RTE powinno jasno dać do zrozumienia, że ​​zespoły mogą natychmiast zgłaszać pilne problemy i nie powinny czekać na następną synchronizację ART.
• Przygotuj się na dane. Poproś mistrzów Scrum i właścicieli produktów o przyniesienie wymiernych wskaźników postępu, takich jak spalanie lub skumulowany przepływ, w celu przeprowadzenia świadomej rozmowy na temat postępów.
• Wyjdź poza cotygodniowy przegląd statusu. Synchronizacja ART ma być wydarzeniem, w którym priorytety są wyrównane, a problemy rozwiązywane, a nie proste zameldowanie.

Demo systemu

Demo systemu ma na celu pokazanie pełnego zakresu prac wykonanych w poprzedniej iteracji. Podczas tego wydarzenia menedżer produktu i jego zespół pokazują właścicielom firm i innym interesariuszom zintegrowany postęp ART w jego obecnej formie.

Wejście

• Aktualny stan pracy na podstawie wyników wszystkich członków zespołu Agile w trakcie poprzedniej iteracji

Wyjścia

• Informacje zwrotne na temat przydatności systemu do określonego celu
• Zmiany w backlogu (jeśli są wymagane)

Ogólne wskazówki dotyczące wydarzenia demonstracyjnego systemu

• Odbywać próby! Poświęć od 30 do 45 minut co drugi tydzień na pracę z prezenterami, aby przygwoździć ich segmenty.
• Porzuć slajdy. Przedstaw rzeczywistą zintegrowaną pracę. Jeśli pracujesz nad oprogramowaniem, poproś prezenterów, aby pokazali zainteresowanym stronom działający przyrost produktu, a nie slajdy. Jeśli to możliwe, zademonstruj swój produkt w środowisku pomostowym. Chcesz, aby demo dokładnie przypominało wrażenia użytkownika końcowego. Jeśli nie jesteś w stanie zaprezentować zintegrowanego systemu co dwa tygodnie, spójrz na swój potok dostarczania i przeprowadź burzę mózgów z zespołami na temat sposobu przyjęcia kultury CI/CD i DevOps.
• Skoncentruj się na wartości biznesowej. Twoja prezentacja jest przeznaczona dla właścicieli firm i interesariuszy; podziel się tym, co dla nich najważniejsze.
• Skup się na opiniach. Informacje zwrotne od interesariuszy, które otrzymasz, będą ważne, ale to wydarzenie nie jest czasem na drastyczne zmiany w wizji produktu lub planie działania. Przygotuj się na skierowanie rozmowy z powrotem na informacje zwrotne na wysokim poziomie, które zespoły mogą później przekształcić w elementy działania.
• Niech to będzie krótkie. Interesariusze to zapracowani ludzie; spotkanie trwające od 45 do 60 minut zaowocuje częstszą i bardziej zaangażowaną frekwencją.
• Daj czas na pytania i odpowiedzi. Bądź przejrzysty w swoich odpowiedziach. Pamiętaj, że czasami najlepszą odpowiedzią jest „nie wiem, ale możemy się dowiedzieć”.

Sprawdź i dostosuj

Inspekcja i adaptacja to mega-retrospektywna sesja, która odbywa się pod koniec PI. Sesja podzielona jest na trzy części,

• Demo systemu PI: prezentacja całego zintegrowanego wyjścia PI. Jest podobny do głównego demo systemu, ale zamiast jednej iteracji, to wydarzenie prezentuje zintegrowaną pracę w całym PI.
• Pomiary ilościowe i jakościowe: okazja dla RTE do przedstawienia metryk zebranych w trakcie PI. Te metryki obejmują (ale nie ograniczają się do) szybkość pracy zespołu, akceptowane historyjki użytkownika, pokrycie testów jednostkowych lub otwarte defekty.
• Warsztat retrospektywny i rozwiązywania problemów: szansa dla uczestników na spojrzenie wstecz na PI, zastanowienie się nad tym, co zadziałało, a co nie, zidentyfikowanie problemów systemowych i zaproponowanie sposobów ich rozwiązania.

Wejścia

• Postępy zespołów
• Aktualny stan zintegrowanej pracy ART, w tym wszystkie dane wyjściowe przyrostu programu

Wyjście

• Lista potencjalnych ulepszeń

Ogólne wskazówki dotyczące inspekcji i adaptacji wydarzenia

• Poinformuj właścicieli firm z wyprzedzeniem. Przekaż co najmniej dwa tygodnie przed wydarzeniem. Spotkaj się z obecnymi menedżerami produktu i właścicielami firm przed sesją, aby dostosować prezentację wyników jakościowych.
• Zapewnij obecność starszych interesariuszy. Ich obecność jest najważniejsza na demo systemu PI, kiedy prezentujesz pracę zespołu i ewoluujący produkt. Wiele wskazówek dotyczących zwykłej demonstracji systemu ma tutaj zastosowanie: przećwicz wcześniej, unikaj slajdów prezentacji i prezentuj rzeczywiste wyniki.
• Unikaj obwiniania. W trakcie sesji upewnij się, że nikt nie czuje się zagrożony prezentowanymi danymi lub problemami zidentyfikowanymi w retrospekcji. Niektóre zespoły mogą czuć się zazdrosne lub bronić się, jeśli liczba innych zespołów jest wyższa, lub czuć się wyróżnione, jeśli problem pojawił się w ich zespole. Przyjmij kulturę całego zespołu, aby zapobiegać takim problemom.
• Skoncentruj się na kwestiach systematycznych. Staraj się nie przywiązywać zbytniej uwagi do sporadycznych problemów, zapewnij swojemu zespołowi przestrzeń potrzebną do burzy mózgów i puść wodze fantazji na temat proponowanych rozwiązań.
• Twórz praktyczne propozycje. Pod koniec wydarzenia powinieneś mieć elementy zaległości do wdrożenia przez zespoły. Identyfikacja problemów nie pomoże, jeśli nie podejmiesz kroków w celu ich rozwiązania.

Poniższa tabela porównuje wydarzenia SAFe z ich odpowiednikami w Scrum oraz opisuje częstotliwość i realizację ceremonii na poziomie przedsiębiorstwa:

Zwiększanie i skalowanie

Przejście od Scrum do SAFe może być onieśmielające. Działanie na większą skalę zawsze będzie stawiać nowe wyzwania i nowe sposoby myślenia o nawet najbardziej znanych praktykach. Jeśli zdecydujesz się zostać RTE, przekonasz się, że praca zależy głównie od umiejętności, które już posiadasz. RTE jest agentem zmiany i liderem-sługą, podobnie jak mistrz Scrum, a praca daje ci szansę pełnienia tej roli na poziomie przedsiębiorstwa, podnosząc swoje umiejętności wraz z produktami.