Wprowadzenie efektywnych zespołów Scrum do struktury organizacyjnej to niełatwe zadanie, z którym wiele firm ma trudności. Jednak, gdy zarządzasz wieloma silnie zależnymi zespołami pracującymi nad jednym produktem lub w obrębie tego samego strumienia wartości, potrzebujesz czegoś o większym zasięgu.
Konieczne staje się zastosowanie frameworka, który skaluje metodologię Scrum na większą liczbę zespołów. Taki framework powinien dostarczać zespołom procedur i wytycznych, które umożliwią im wzajemną synchronizację, adaptację oraz utrzymać wspólny kierunek.
Często spotykane jest powstawanie zespołów typu „silos”, czyli autonomicznych grup Scrum, które koncentrują się na swoich lokalnych zadaniach, tracąc z oczu globalny cel programu. W tym kontekście Scaled Agile Framework (SAFe) staje się wartościowym rozwiązaniem.
Czym jest SAFe?
Źródło: Scaledagileframework.com
SAFe to podejście, które adaptuje zwinne metody i procesy do organizacji o hierarchicznej strukturze. Framework ten obejmuje warstwy strukturalne i proceduralne, ale zamiast je kopiować, tworzy równoległy system w sposób naturalny, zrozumiały dla większości interesariuszy.
SAFe opiera się na kilku fundamentalnych wartościach.
Spójność
- Każdy zespół Scrum musi rozumieć wizję, strategię oraz ostateczny cel.
- Należy połączyć strategie poszczególnych zespołów, kierując je ku wspólnym osiągnięciom.
- Komunikacja z zespołami powinna odbywać się przy użyciu jednolitego języka, który jest dla nich zrozumiały.
- Konieczne jest regularne sprawdzanie, czy zespoły rozumieją cele i wizję projektu.
- Zespoły powinny być zorientowane na klienta, rozumieć jego potrzeby i oczekiwania. Strategia powinna być odzwierciedleniem tych informacji.
Przejrzystość
- Należy stworzyć środowisko pracy, w którym każdy może działać efektywnie, bez obaw o brak zaufania.
- Komunikacja powinna być otwarta, oparta na argumentach i faktach. Bezpośredniość i szczerość, bez ukrywania istotnych informacji przed zespołami są kluczowe.
- Błędy powinny być traktowane jako okazja do nauki. Szybkie wyciąganie wniosków i adaptacja strategii są bardzo ważne.
- Praca powinna być wizualizowana, aby była zrozumiała dla wszystkich członków zespołu.
- Dostęp do potrzebnych informacji powinien być łatwy i szybki.
Szacunek dla ludzi
- Należy podkreślać ludzką wartość. Ludzie nie są zasobami.
- Różnorodność opinii i perspektyw jest cenna. Należy wspierać szczere wyrażanie myśli.
- Rozwój osobisty i zawodowy powinien być wspierany poprzez mentoring i coaching.
- Należy pamiętać, że to klient ostatecznie korzysta z wyników pracy.
- Należy budować trwałe relacje, zarówno w zespołach, jak i pomiędzy nimi.
Ciągłe doskonalenie
- Należy stworzyć środowisko, w którym rozwiązywanie problemów jest motywujące dla zespołów.
- Regularna analiza i wyciąganie wniosków z poprzednich działań jest kluczowe do ciągłego doskonalenia.
- Fakty powinny być podstawą do podejmowania decyzji o poprawie.
- Należy zapewnić czas i przestrzeń na innowacje. Zespoły powinny mieć możliwość eksperymentowania i testowania różnych podejść.
SAFe wprowadza warstwę współdziałania i komunikacji do skalowalnych systemów Agile. Nie zastępuje indywidualnych działań podejmowanych w ramach Sprintu Zespołu Scrumowego.
Kluczowym elementem SAFe jest Agile Release Train (ART). Jest to stały zespół zespołów Scrum (zazwyczaj do 12 mniejszych grup), które regularnie, po każdym sprincie, wprowadzają nowe funkcje. Zespoły ART wspólnie rozwijają, dostarczają i utrzymują jedno lub więcej rozwiązań w ramach strumienia wartości.
Źródło: Scaledagileframework.com
Role w SAFe
SAFe opiera się na zaangażowaniu osób o różnych zakresach obowiązków. Jasne określenie tych ról jest kluczowe dla sukcesu implementacji frameworka. Zrozumienie celu każdej z tych ról jest bardzo ważne.
#1. Zespół Agile
Zespoły Agile są wielofunkcyjne, co oznacza, że posiadają kompetencje w zakresie wszystkich działań, które realizują. Są również samoorganizujące się, odpowiedzialne za definiowanie, tworzenie, testowanie, wdrażanie i udostępnianie przyrostów wartości.
Każdy zespół Agile posiada zestaw umiejętności niezbędnych do realizacji uzgodnionego zakresu. Zespół pracuje nad tym zakresem, zwiększając wartość dostarczaną w każdym sprincie. Przewidywalność jest bardzo istotna, ponieważ pozwala zespołowi podejmować zobowiązania co do osiągnięcia konkretnych celów w danym czasie. Komunikacja i dostarczanie wartości to kluczowe aspekty, które zespół powinien nieustannie doskonalić.
Zespoły Agile biorą aktywny udział w sesjach Planowania Przyrostu Programu (PI), gdzie tworzą historyjki i planują je w ramach Sprintów. Zespoły zobowiązują się również do realizacji własnych celów PI.
Scrum Master szkoli zespół Agile i ułatwia organizację spotkań. Jego rolą jest usuwanie przeszkód oraz ochrona zespołu przed zakłóceniami zewnętrznymi. Scrum Master uczestniczy w spotkaniach Scrumowych w ramach ART.
Właściciel Produktu (PO) to kolejny ważny członek zespołu. PO reprezentuje głos klienta i ma bezpośredni wpływ na historie oraz ich priorytetyzację. PO komunikuje się z innymi PO w celu zdefiniowania i ustalenia priorytetów historyjek w backlogu zespołów.
#2. Zarządzanie Produktem
Zarządzanie Produktem ma na celu zapewnienie spójności działań pomiędzy różnymi zespołami Scrum. Do ich obowiązków należy:
- Realizacja celów biznesowych poprzez zapewnienie zespołom możliwości tworzenia wykonalnych i zrównoważonych produktów i rozwiązań.
- Zrozumienie potrzeb klienta i zapewnienie, że produkty są kompletne z perspektywy użytkownika.
- Dbanie o to, by w backlogu zawsze znajdowała się wystarczająca liczba gotowych funkcji.
- Wspieranie przepływu pracy przez tablice programowe i do backlogu programu.
- Określanie zakresu kolejnego przyrostu programu poprzez nadawanie priorytetów funkcjom opracowanym przez zespoły. Zarządzanie Produktem jest odpowiedzialne za zdefiniowanie kolejnego PI.
#3. Architekt Systemowy / Inżynieria
Zespół inżynierów analizuje i rozwija zakres historyjek w backlogu. Stanowią specjalistyczną część zespołu i odpowiadają za:
- Tworzenie i utrzymanie architektury, która umożliwia wykorzystanie nowych technologii do wdrażania nowych funkcji.
- Aktywny udział w planowaniu przyrostów programu. Obecność na demonstracjach systemu na koniec każdego przyrostu programu.
- Współpracę z zespołami Agile w celu wdrożenia nowych elementów architektury, które umożliwią zespołom tworzenie nowych funkcji.
- Pomoc zespołom Agile w definiowaniu rozwiązań projektowych i podejmowaniu decyzji na wysokim poziomie. Proponowanie alternatywnych rozwiązań i optymalnego podejścia do zadań w zespołach.
- Budowanie architektonicznego „pasa startowego”, czyli zbioru technologii, które umożliwiają wykorzystanie funkcji zdefiniowanych przez poszczególne zespoły.
#4. Właściciele Firm/Interesariusze
Właściciele Firm/Interesariusze to zespoły zewnętrzne w stosunku do zespołów Scrum, ale odgrywają kluczową rolę w SAFe na każdym etapie realizacji.
Przed planowaniem PI:
- Udzielanie wsparcia w udoskonalaniu backlogu.
- W razie potrzeby udział w planowaniu przed PI.
- Upewnianie się, że cele biznesowe są zrozumiałe i uzgodnione przez kluczowych interesariuszy, w tym RTE, kierownictwo produktu i architektów systemów.
Podczas planowania PI:
- Dostarczanie kontekstu biznesowego i wizji na nadchodzący PI.
- Udział w przeglądzie planu i przypisywanie wartości biznesowej celom zespołu PI.
- Udział w Przeglądzie Zarządzania i wsparcie w rozwiązywaniu problemów prowadzących do akceptacji Planu Ostatecznego.
Po planowaniu PI:
- Aktywny udział w utrzymaniu zgodności działań biznesowych i rozwoju, ponieważ priorytety i zakres mogą ulec zmianie.
- Pomoc w weryfikacji definicji minimalnych opłacalnych produktów (MVP) dla Program Epics i podejmowanie decyzji o kontynuacji lub zmianie kierunku, w oparciu o dostarczenie MVP.
- Udział w prezentacji systemu, aby zobaczyć postęp i podzielić się opinią.
- Udział w planowaniu sprintu i retrospektywach sprintu zespołu Agile, jeśli jest taka potrzeba.
- Udział w zarządzaniu wydaniami, koncentrując się na zakresie, jakości, opcjach wdrożenia i uwarunkowaniach rynkowych.
#5. Inżynier Pociągu Wydawniczego (RTE)
RTE koordynuje działania ludzi i zespołów w ramach ART. Pełni rolę Scrum Mastera na poziomie programu. Jego główne obowiązki to:
- Zarządzanie i optymalizacja przepływu wartości przez ART.
- Ustalanie i ogłaszanie rocznych kalendarzy Sprintów i Przyrostów Programu (PI).
- Moderowanie spotkań poświęconych planowaniu PI.
- Pomoc w organizacji zespołów i tworzeniu podsumowania celów PI. Przekładanie celów zespołów na ogólne cele planu PI.
- Łączenie zespołów w celu komunikowania i rozwiązywania problemów, ryzyk i zależności między zespołami.
- Łączenie kierownictwa produktu, właścicieli produktów i innych interesariuszy w celu dostosowania stron do wspólnej strategii.
- Organizacja warsztatów Inspect and Adapt, mających na celu ciągłe doskonalenie procesów.
- Ocena poziomu dojrzałości metodologii Agile w zespołach i definiowanie obszarów wymagających dalszych usprawnień.
#6. Przywództwo
Przywództwo określa strategię programu i zapewnia zespołom narzędzia i wsparcie niezbędne do pracy. Odpowiada za definiowanie systemu, w którym działa cała reszta. Kluczowe jest, by zespół zarządzający wyznaczał właściwy cel i definicję wartości. Ich podstawowe obowiązki to:
- Dawanie przykładu.
- Przyjęcie podejścia opartego na rozwoju.
- Podkreślanie wartości i zasad SAFe.
- Rozwijanie ludzi.
- Kierowanie zmianą.
- Dbanie o bezpieczeństwo psychiczne.
Planowanie Przyrostu Programu (PI)
Planowanie PI to wydarzenie trwające od dwóch do trzech dni, którego celem jest zaangażowanie się w pracę nad kolejną wersją programu. Czas trwania PI może odpowiadać np. okresowi kwartału.
Zarządzanie Produktem odpowiada za priorytetyzację funkcji zidentyfikowanych podczas planowania PI. Zespoły Agile samodzielnie planują działania, tworzą historyjki, dokonują oszacowań i podejmują zobowiązania w zakresie realizacji celów PI.
Planowanie PI jest kluczowe dla SAFe. Brak planowania PI oznacza, że w rzeczywistości nie stosujesz SAFe.
Proces PI
Źródło: Scaledagileframework.com
Planowanie PI rozpoczyna się od zebrania danych wejściowych. Każdy strumień pracy gromadzi potrzeby i pomysły na to, co chcieliby dalej budować dla swoich produktów. Dane te stanowią podstawę do planowania PI:
- 10 najważniejszych funkcji do wdrożenia.
- Backlog ART gotowy do przekształcenia w epiki lub funkcje.
- Wizja Właściciela Produktu.
Następuje dyskusja pomiędzy różnymi strumieniami pracy. Każdy przedstawia swoje wizje i pomysły. Podkreślają, co jest ważne do wdrożenia w następnej kolejności i czego potrzebują, aby osiągnąć sukces. Może to obejmować:
- Wsparcie innych strumieni pracy, aby umożliwić kontynuację funkcji.
- Zależność od innych strumieni pracy i konieczność priorytetyzacji działań.
- Problemy występujące w systemie, które należy rozwiązać w pierwszej kolejności.
- Wyzwania kadrowe. Potencjalny brak kluczowych ról w zespole, niezbędnych do wdrożenia określonych funkcji.
- Ograniczenia budżetowe uniemożliwiające realizację wizji w określonym czasie.
- Wszelkie inne ryzyka, problemy, założenia lub zależności, które zespół może rozpoznać i które wymagają dyskusji w szerszym gronie.
Przewodnik po PI
Planowanie PI zazwyczaj trwa od dwóch do trzech dni, a harmonogram może wyglądać następująco:
Dzień 1
- Omówienie kontekstu działalności i kluczowych celów, które tworzą wizję i strategię programu. Przywództwo prezentuje te informacje zespołowi.
- Umieszczenie wszystkich funkcji ze strumieni pracy na stole i nadanie im priorytetów zgodnie ze wspólną wizją.
- Przedstawienie wizji architektury i zdefiniowanie głównych celów wymagań programistycznych. Omówienie wyzwań technicznych i uzgodnienie rozwiązań w ramach zespołów.
Dzień 2
- Szczegółowe omówienie procesu planowania dla zespołów. Przedstawienie oczekiwanych rezultatów po zamknięciu PI.
- Podział na mniejsze zespoły w celu opracowania planów oraz zidentyfikowania przeszkód i zagrożeń.
- Prezentacja projektów planów innym zespołom w celu ich przeglądu.
- Przegląd planów przez kierownictwo. Udzielanie wskazówek dotyczących kolejnych działań, które pozwolą rozwiązać problemy. Wprowadzenie poprawek w planach, w oparciu o zidentyfikowane wyzwania, ryzyka i przeszkody.
Dzień 3
- Rozpoczęcie dnia od omówienia zmian w planowaniu, które wynikają z ustaleń z kierownictwem z dnia poprzedniego.
- Opracowanie finalnych planów przez zespoły oraz doprecyzowanie ryzyk i przeszkód. Przypisanie wartości biznesowej do celów zespołu przez właścicieli firm.
- Prezentacja finalnych planów przed całą publicznością.
- Omówienie pozostałych ryzyk na poziomie programu, stosując informacje o ryzyku ROAM (rozwiązane, posiadane, zaakceptowane, łagodzone).
- Zespoły głosują za poziomem zaufania w odniesieniu do wyników planowania przyrostów programu.
- W przypadku niskiej liczby głosów lub niskiego ogólnego zaufania, planowanie jest kontynuowane.
- Po Zobowiązaniu PI, RTE planuje retrospektywę dla zespołów, aby omówić przebieg planowania i elementy wymagające poprawy. Kierownictwo ustala kolejne kroki i przekazuje ostateczne instrukcje.
Wynik PI
Wynikiem planowania PI jest lista funkcji, które mają być ukończone w poszczególnych sprintach w nadchodzącym okresie PI. Wszystkie znane zależności są uwzględnione w planie, aby odblokować postęp prac.
Zespoły zobowiązują się do realizacji swoich celów i zakresów. Jeśli istnieją dodatkowe cele, które nie są uwzględnione na liście, traktowane są jako cele opcjonalne, realizowane, o ile pozwoli na to czas i zasoby.
Zespoły dokumentują i śledzą wszystkie ryzyka związane z programem, posiadając plan ich rozwiązania.
Zespoły zapisują również wszystkie pomysły z retrospektywy, które będą wykorzystane do nauki i doskonalenia w kolejnych sesjach planowania PI.
Jeśli chodzi o konkretne oczekiwania wobec zespołów, to obejmują one:
- Zobowiązanie do realizacji celów opartych na wartości biznesowej.
- Obliczenie swojej wydajności na sprint, aby lepiej oszacować wykonalność planu działania.
- Uwzględnienie rzeczywistego obciążenia na każdy sprint.
- Przenoszenie historyjek do konkretnych sprintów w ramach każdego strumienia pracy.
- Głosowanie za poziomem zaufania w odniesieniu do planu PI i zakresu prac.
Wniosek
Może nie być to oczywiste, ale transformacja dużej organizacji w oparciu o SAFe jest wyjątkowo wymagającym zadaniem. W niektórych sytuacjach może wydawać się wręcz niemożliwa. Nawet przy stosowaniu fundamentalnych zasad, potrzeba wielu iteracji, aby osiągnąć stan, w którym można stwierdzić, że organizacja stała się SAFe.
Często postęp jest spowalniany przez stare, hierarchiczne zasady, które trudno wyeliminować. Możliwe jest, że planowanie PI przyniesie konkretne rezultaty, ale co z tego, jeśli zespoły zarządzające przepływem pracy nie będą działać zgodnie z metodologią Agile?
W tym przypadku nie ma miejsca na półśrodki. Albo w pełni angażujesz się w projekt – mając właściwe procesy, ludzi i podejście, albo ponosisz porażkę, jeśli choć jeden z aspektów metodologii nie jest w pełni realizowany.
Zanim rozważysz wdrożenie SAFe, upewnij się, że zasady i metody pracy zespołów Agile są dobrze opanowane, nie tylko z perspektywy liderów, ale także z perspektywy samych zespołów. Wyniki mogą Cię zaskoczyć.
Przed podjęciem decyzji o wdrożeniu SAFe, warto przeanalizować materiały edukacyjne dotyczące certyfikacji Agile.
Czy ten artykuł był przydatny?
Dziękujemy za Twoją opinię!