Porównanie 5 frameworków Agile Scaling: którego należy użyć?

Wyobraź sobie: na początku projektu tworzysz jeden, skuteczny, wielofunkcyjny zespół osób zaangażowanych w osiąganie celów produktowych. Aby poprawić wydajność, upewnij się, że zespół jest biegły w Agile. Zapotrzebowanie na produkt rośnie, rosnące wymagania i poszerzający się backlog. Ty i inni interesariusze zdajecie sobie sprawę, że zespół musi być skalowany. Brzmi znajomo?

Skalowanie pozwala wielu zespołom współpracować ze sobą, aby zachować sprawność. Jeśli jest więcej pracy do wykonania, niż Twój zespół jest w stanie obsłużyć w rozsądnym czasie, nadszedł czas na skalowanie. Aby to zrobić, musisz jednak wybrać odpowiedni framework, a jest ich kilka. Źle wybierz, a wdrożenie może się nie powieść, zaburzając produktywność i powodując znaczne reperkusje finansowe.

Struktura najlepiej dopasowana do Twojego zespołu będzie się różnić w zależności od takich czynników, jak dostępne finansowanie, podejście organizacyjne i złożoność produktu.

Kiedy należy skalować?

Istnieje kilka kluczowych kryteriów, które należy spełnić, zanim rozważysz skalowanie:

Czy możesz zarządzać rozwojem tylko w jednym zespole?

Wdrażanie skalowanych frameworków Agile może być złożone i czasochłonne, więc nie skaluj, jeśli nie musisz. Kiedy obciążenie Twojego zespołu przewyższa jego możliwości, konieczne jest skalowanie.

Czy Twój zespół jest zwinny?

Być może najważniejszym kryterium jest biegłość Twojego zespołu w podejściach Agile. Jeśli Twój zespół nie ma doświadczenia w Agile, skalowanie spowoduje więcej problemów.

Czy praktyki rozwoju Twojego zespołu wymagają poprawy?

Jeśli praktyki inżynierskie Twojego zespołu nie są skuteczne, skalowanie może nie przynieść oczekiwanych rezultatów. Praktyki, takie jak prawidłowa implementacja DevOps i potok CI/CD, mają kluczowe znaczenie dla spójności między zespołami. Ponadto bez standardowego zapewnienia jakości testowanie nowych funkcji może być trudne.

Czy Twój zespół dostarcza zintegrowane przyrosty?

Skalowanie polega na integracji wielu zespołów współpracujących nad tym samym produktem, gdzie każdy zespół tworzy funkcje, które ze sobą współpracują. Poniższa tabela przedstawia cztery możliwe konfiguracje zespołów i produktów. Zauważ, że tylko jeden wymaga skalowania.

Wybór modelu skalowania

Do wyboru jest wiele frameworków do skalowania Agile, ale skupimy się na pięciu najczęściej używanych rozwiązaniach: Scaled Agile Framework (SAFe), Nexus, Large-Scale Scrum (LeSS), Scrum@Scale i Disciplined Agile (DA) . Uważam, że są to najskuteczniejsze frameworki i można je zastosować w wielu scenariuszach i organizacjach. Poniższe sekcje wyposażą Cię w informacje potrzebne do dokonania najlepszego wyboru dla Twojego unikalnego kontekstu skalowania.

1. Scaled Agile Framework (SAFe)

SAFe to najpopularniejszy framework do skalowania Agile. Badanie z 2021 r. wykazało, że 37% praktyków Agile korzysta z niego, głównie ze względu na jego liczne konfiguracje, z których wszystkie koncentrują się na strumieniach wartości i mają dobrze zdefiniowane wytyczne i procedury.

Ponieważ SAFe służy do dostarczania złożonych rozwiązań, które wymagają więcej niż 50 osób, organizuje zespoły w zwinne pociągi wydania (ART). Aby zsynchronizować zespoły w ART, SAFe wykorzystuje iteracje przyrostu programu — podobne do sprintów Scrum — a każda iteracja trwa zwykle od 8 do 12 tygodni. Takie podejście pozwala menedżerom produktów na skupienie się na ogólnych celach i sprawne nadzorowanie złożonej mapy drogowej produktu bez wprowadzania nadmiernych zmian.

SAFe jest oparty na frameworku Scrum, ale z kilkoma kluczowymi różnicami: adopcja SAFe odbywa się na poziomie przedsiębiorstwa, a nie na poziomie zespołu; i podczas gdy Scrum daje właścicielowi produktu wyłączną władzę nad ustalaniem priorytetów, SAFe zachęca do bardziej demokratycznego podejścia.

SAFe ma cztery poziomy wdrożenia:

Niezbędne BEZPIECZEŃSTWO

Essential SAFe jest podstawą SAFe i musi być opanowany przed przejściem do którejkolwiek z kolejnych konfiguracji. Wykorzystuje ustalone role Scrum, takie jak Scrum Master, Product Manager i Product Owner, a także wprowadza nową rolę: Release Train Engineer. Ta osoba działa jako sługa-lider i trener ART, prowadząc zespoły w celu dostosowania ich celów. W ART może być od pięciu do 12 zespołów, a każdy ART jest w stanie dostarczyć kompletne rozwiązanie.

Duże rozwiązanie

Ta konfiguracja znajduje się na szczycie Essential SAFe i wprowadza koncepcję zwaną „pociągiem rozwiązań”. Jest używany podczas tworzenia dużych i złożonych rozwiązań, które wymagają koordynacji wielu ART — potencjalnie setek, a nawet tysięcy osób — pracujących nad tym samym strumieniem wartości. Na przykład, jeśli pracujesz w firmie Microsoft i masz trzy oddzielne zespoły programujące programy Excel, Word i PowerPoint, wszystkie one przyczyniają się do tego samego strumienia wartości: Microsoft Office.

Teczka

Portfolio składa się z wielu ART pracujących nad różnymi strumieniami wartości. Kontynuując przykład Microsoft: oddzielne zespoły pracujące nad produktami Office, Skype lub Xbox firmy.

Pełne bezpieczeństwo

Ta konfiguracja łączy wszystkie warstwy — Essential, Large Solution i Portfolio — w celu koordynowania zarządzania zespołem w całym przedsiębiorstwie.

2. Nexus

Framework Nexus jest również oparty na Scrumie, ale jest lżejszy niż SAFe i wymaga jedynie niewielkich poprawek, które ułatwiają współpracę między trzema do dziewięciu zespołami. Wdrożenie Nexusa nie wymaga żadnych dodatkowych ról. Zamiast tego jeden przedstawiciel z każdego zespołu dołącza do centralnego zespołu integracyjnego, który dostosowuje pracę do jednego celu. Podobnie jak w Scrum, wszystkie zespoły spotykają się na sesji planowania sprintu, której wyniki tworzą wspólny backlog produktu. Aby sprawdzić postępy, każdy zespół organizuje codzienne spotkanie przypominające stand-up, a zespół integracyjny spotyka się również, aby zgłosić postępy swojego zespołu.

Podczas sprintu zespoły uczestniczą w sesji udoskonalania, aby ustalić priorytety i oszacować zaległości. Ponieważ złożoność zarządzania zaległościami rośnie wraz z liczbą zespołów, Nexus nakazuje sesje doskonalące. Zespoły zbierają się na przeglądy i retrospektywy po każdym sprincie.

3. Scrum na dużą skalę (LeSS)

LeSS jest prawie identyczny z Nexusem, ale ma niewielkie różnice, takie jak konwencje nazewnictwa i dodatkowe sesje planowania sprintu dla poszczególnych zespołów. Różni się również możliwością rozbudowy dzięki drugiej konfiguracji, LeSS Huge, która wspiera współpracę ponad ośmiu zespołów.

LeSS Huge przyjmuje zorientowane na klienta podejście do organizacji rozwoju. Aby efektywnie zarządzać pracą, właściciel produktu musi podzielić rejestr produktów wysokiego poziomu na mniejsze „zaległości obszaru” bardziej szczegółowych elementów, a następnie posortować je dalej — według obszarów wymagań.

Te obszary wymagań są zarządzane przez obszarowych właścicieli produktów (APO). APO specjalizują się w dziedzinach związanych z każdym obszarem i pracują z kilkoma zespołami nad rozwiązaniami dla swojego obszaru. Każde wymaganie przechowywane w backlogu należy tylko do jednego obszaru wymagań, a każdy obszar jest zarządzany przez tylko jednego APO. Właściciel produktu i APO tworzą wspólnie zespół odpowiedzialny za ustalanie priorytetów z uwzględnieniem całego produktu.

4. Scrum@Skala

Scrum@Scale jest rozszerzeniem Scrum i prawdopodobnie najłatwiejszym frameworkiem do opanowania i zrozumienia. Skaluje się od jednego zespołu do zespołu zespołów.

Podstawowym elementem frameworka jest Scrum of Scrums (SoS). Każdy zespół wybiera osobę, która będzie reprezentować go na spotkaniach SoS, które zwykle odbywają się codziennie po wystąpieniach poszczególnych zespołów. Celem każdego dnia spotkania SoS jest pomoc w koordynacji i komunikacji między zespołami oraz ułatwienie łatwego zarządzania wszelkimi zależnościami lub nakładaniem się.

Unikalne role w ramach tej struktury obejmują mistrza SoS, zasadniczo skalowaną wersję mistrza Scrum, oraz głównego właściciela produktu, który współpracuje z właścicielami produktów zespołowych, aby utworzyć wspólny backlog dla SoS.

Scrum@Scale jest mniej nakazowy niż inne frameworki, pozwalając organizacjom na skalowanie we własnym tempie. Jeśli liczba zespołów nadal rośnie, a spotkania SoS stają się zbyt duże, organizacje mogą eskalować ten framework do Scrum of Scrum of Scrums (SoSoS).

5. Zdyscyplinowana Agile (DA)

DA różni się od innych frameworków tym, że działa bardziej jako zestaw narzędzi, z którego możesz wybrać najbardziej odpowiednie strategie skalowania, niż sztywny framework z regułami, których musisz przestrzegać. Jest to oparta na kontekście hybryda różnych frameworków, w tym Scrum i Kanban, które można dostosować do potrzeb każdego projektu, skoncentrowana na zasadzie „Wybór jest dobry”. DA opiera się na założeniu, że każdy zespół i organizacja jest wyjątkowa pod względem wielkości, dystrybucji i domeny, a każdy członek zespołu jest również wyjątkowy, z własnymi umiejętnościami i doświadczeniem.

Może być stosowany na poziomie zespołu programistycznego lub w całym przedsiębiorstwie. W przypadku tych ostatnich zestaw narzędzi DA określa, jakie różne funkcje biznesowe – takie jak finanse, operacje IT i zarządzanie dostawcami – powinny dotyczyć, i przedstawia szereg opcji w tym zakresie.

DA wyróżnia trzy fazy projektu — inicjacja, budowa i przejście — a każda z nich obejmuje cele procesu zorientowane na realizację. Ponieważ ta struktura koncentruje się na pełnym cyklu życia dostarczania, a nie tylko na kompilacji, wprowadza więcej ról niż inne struktury. Główne role, które można znaleźć w każdym zespole DA, to interesariusz, członek zespołu, kierownik zespołu, właściciel produktu i właściciel architektury. Istnieje również pięć ról pomocniczych, często używanych tymczasowo w celu wspomagania skalowania: specjalista, ekspert dziedzinowy, ekspert techniczny, niezależny tester i integrator.

DA może być używany w połączeniu z innymi frameworkami, aby dalej skalować.

Wybieraj ostrożnie i skaluj powoli

Skalowanie zespołów Agile i bezproblemowa integracja ich pracy jest trudne, ale można to ułatwić, wybierając najlepszy framework. Skorzystaj z poniższego schematu blokowego jako pierwszego kroku w procesie podejmowania decyzji.

Jestem przekonany, że wśród przedstawionych tutaj znajdziesz platformę skalowania, która odpowiada doświadczeniu, podejściu, budżetowi i produktom Twojej organizacji. Bez względu na wybraną platformę ważne jest, aby nie spieszyć się — skalować stopniowo, aby zminimalizować zakłócenia i zaplanować zmiany z dużym wyprzedzeniem.

Czy wykorzystałeś te frameworki w swoich działaniach związanych ze skalowaniem? Opowiedz nam o swoich doświadczeniach w sekcji komentarzy.