Artykuł
Wpływ frameworków do skalowania zwinności na strukturę organizacji
Frameworki i sposoby skalowania zwinności
Zwinne organizacje | Blog o agile | Maj 2021
Dostrzegając korzyści z pracy zwinnej pojedynczych zespołów, organizacje zaczęły rozszerzać zwinność na pozostałe jednostki biznesowe. Pojawiła się naturalna potrzeba skalowania zwinności, jednak żaden z istniejących zwinnych sposobów pracy (Scrum, Kanban, XP, Crystal czy DSDM) nie pozwolił zaadresować problemu koordynacji wielu zespołów. Zaczęto więc tworzyć frameworki do skalowania: LesS, SAFe, Nexus, Scrum@Scale, natomiast do uzwinniania struktury często wykorzystuje się model Spotify. Czym się one różnią i jak wpływają na strukturę organizacji oraz jej procesy?
Przesuń stronę do:
- LeSS, Nexus, SAFe i Scrum@Scale – sposoby skalowania zwinności
- Model Spotify – dlaczego nie jest frameworkiem?
- Jak skalowanie zwinności wpływa na strukturę?
- Podsumowanie
LeSS, Nexus, SAFe i Scrum@Scale – sposoby skalowania zwinności
Large-Scale Scrum (LeSS) został stworzony przez Craiga Larmana i Basa Vodde w celu skalowania frameworku Scrum w stosunku do kilku zespołów. Wyróżnia się LeSS Large, który jest podstawową odmianą metody, stosowaną wobec dwóch do maksymalnie ośmiu zespołów, oraz LeSS Huge, który jest wykorzystywany w przypadku, gdy ich liczba przekracza 8. Poza rolami typowymi dla Scruma, LeSS Huge dodaje funkcję Obszarowego Właściciela Produktu (ang. Area Product Owner), czuwającego nad obszarem wymagań, które są ze sobą powiązane z punktu widzenia potrzeb klienta. Nad implementacją wymagań w ramach obszaru pracuje od 4 do 8 zespołów. Więcej o LeSS pisaliśmy w tym artykule.
Nexus to metoda wypracowana przez Scrum.org i stworzona przez Kena Schwabera. Słowo nexus oznacza ważny łącznik pomiędzy elementami systemu lub grupami rzeczy. Framework służy bowiem połączeniu pracy wielu zespołów (od trzech do dziewięciu), które mają za zadanie stworzyć jeden wspólny produkt. Ma eliminować występujące współzależności, ułatwiać synchronizację pracy oraz koordynację. Żeby to osiągnąć, oprócz podstawowych ról Scrumowych została dodana nowa – Zespół Integracyjny Nexusa (ang. Nexus Integration Team). Jest on odpowiedzialny za coaching i mentoring pozostałych pracowników w zakresie stosowania odpowiednich technik i narzędzi, które pozwolą zintegrować komponenty, wytworzone osobno przez każdy zespół. Służą w pewnym sensie do wystandaryzowania sposobu pracy w aspekcie technicznym.
Scrum at Scale (Scrum@Scale) jest metodą zarządzania zespołami, pracującymi zgodnie ze Scrumem. Został stworzony przez Jeffa Sutherlanda i jego firmę Scrum Inc. Wspólnie stworzyli społeczność, w której reprezentanci różnych przedsiębiorstw na świecie mogą dzielić się wzorcami wypracowanymi podczas rozszerzania podejścia zwinnego na inne obszary organizacji. Scrum at Scale wykorzystuje bazową budowę Zespołu Scrumowego, którą przenosi na kolejne szczeble organizacji. Wyróżnia się trzy następujące poziomy:
Poziom zespołu – jest to pojedynczy Zespół Scrumowy, złożony ze Scrum Mastera, Właściciela Produktu oraz Zespołu Deweloperskiego. Funkcjonuje zgodnie z zasadami zawartymi w Scrum Guide.
Poziom Scrum of Scrums (SoS) – jest to struktura złożona z kilku Zespołów Scrumowych, które wspólnie muszą dostarczyć wartość klientowi. W skład SoS wchodzą także Chief Product Owner oraz Scrum of Scrums Master. SoS ma swoje dedykowane wydarzenia: Pielęgnację Backlogu, Retrospekcję oraz Scaled Daily Scrum.
Poziom Executive – tutaj swoje miejsce ma Executive Action Team, który jest odpowiedzialny za zwinną transformację organizacji, koordynację zwinnej jednostki biznesowej oraz synchronizację jej współzależności z niezwinnymi częściami przedsiębiorstwa. Na tym poziomie znajduje się również Executive Meta Scrum, który ma za zadanie odpowiadać za kontakt zwinnej jednostki z interesariuszami. Jedynym wydarzeniem dedykowanym tym zespołom, o którym wspomina Scrum@Scale Guide, jest Meta Scrum Event.
W zależności od tego, który poziom zostaje zastosowany przez firmę, kompleksowość tego rozwiązania wzrasta.
Twórcą SAFe (Scaled Agile Framewok) jest Dean Leffingwell, który opisał koncepcję w 2011 r. w książce “Agile Software Requirements”. Spośród omawianych dotychczas sposobów skalowania zwinności, nie koncentruje się jedynie na Scrumie. SAFe łączy różne podejścia (Scrum, Kanban, Extreme Programming, Lean), pozwalając na odpowiednie dostosowanie zarządzania do organizacji, projektu i otoczenia. Budowa SAFe oparta jest o zwinne wytwarzanie, myślenie systemowe, tworzenie produktu w duchu Lean oraz metodykę DevOps. SAFe, oprócz ról charakterystycznych dla Scrum, wprowadza dodatkowo 8 nowych funkcji w trzech z siedmiu obszarów kompetencji:
- Dostarczanie rozwiązań biznesowych (ang. Enterprise Solution Delivery): Solution Architect; Solution Manager; Solution Train Engineer.
- Dostarczanie zwinnego produktu (ang. Agile Product Delivery): System Architect; Product Manager; Release Train Engineer.
- Zarządzanie portfolio projektów w duchu Lean (ang. Lean Portfolio Management): Epic Owner; Enterprise Architect.
SAFe jest najbardziej kompleksowym podejściem, które obejmuje zagadnienia nie tylko związane z pracą zespołów, ale także łączenia wierzchołka decyzyjnego z poziomem operacyjnym, formułowania strategii i przekładania jej na konkretne działania oraz budżetowanie.
W związku z tym, wprowadza określoną strukturę, umożliwiając realizowanie zwinności w 4 wymiarach:
- Poziom Zespołu (ang. Essential SAFe) - najmniej złożona implementacja;
- Poziom Rozwiązania (ang. Large Solution SAFe);
- Poziom Portfolio (ang. Portfolio SAFe);
- Poziom Organizacji (ang. Full SAFe) - wprowadzenie zwinności w całej organizacji; podejście integrujące pozostałe trzy poziomy.
To, który z frameworków do skalowania zwinności organizacja chce wdrożyć, zależy od wybranej przez nią strategii transformacji, co z kolei wpływa na zmiany konieczne do przeprowadzenia w docelowej strukturze organizacyjnej.
Model Spotify – dlaczego nie jest frameworkiem?
Sposób funkcjonowania firmy Spotify oraz struktura zostały opisane w 2012 r. przez Henrika Kniberga oraz Andersa Ivarssona w artykule Scalling Agile @ Spotify with Tribes, Squads, Chapters & Guilds. Filozofia kryjąca się za modelem ma następujące przesłanie: zespół tworzący wartość dla klienta powinien funkcjonować jak start-up, mając zwiększoną autonomię i decyzyjność oraz pełnię odpowiedzialności za swój produkt. Struktura w modelu przypomina macierzową, jednak o odmiennym charakterze. Wymiar pionowy skupia się na dostarczeniu wartości klientowi, zaś wymiar horyzontalny na dzieleniu się wiedzą i narzędziami.
Przeczytaj więcej na ten temat w tekście: Plemiona, rozdziały i składy, czyli struktura organizacyjna wspierająca zwinność.
W modelu Spotify wyodrębnia się następujące jednostki organizacyjne:
- Squad – to pojedynczy, samoorganizujący się zespół, który musi posiadać wszystkie niezbędne kompetencje do dostarczenia wartości biznesowej.
- Tribe – to grupa squadów powiązanych tematycznie wokół danego obszaru biznesowego. Nie powinna ona liczyć więcej niż 100 osób. Wyróżnia się tutaj rolę Tribe Leadera, który jest odpowiedzialny za zapewnienie właściwego środowiska pracy.
- Chapter – skupia osoby pełniące podobne funkcje w różnych squadach w ramach jednego tribe’u (np. testerzy, analitycy), gwarantując standaryzację umiejętności pomiędzy autonomicznymi jednostkami. Chapter Lead pełni rolę menedżera liniowego dla pozostałych osób, co wiąże się z takimi funkcjami jak decydowanie o wynagrodzeniu czy wsparcie rozwoju.
- Guild – są to społeczności osób z całej organizacji (nie ogranicza się do wybranego tribe’u), które mają podobne zainteresowania, ale niekoniecznie te same umiejętności. Przynależność do gildii ma charakter nieformalny – każdy może dołączyć w dowolnym momencie, jak również opuścić grupę.

Rysunek 1. Źródło: A. Ivarsson, H. Kniberg, Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds, Oct 2012, s. 1.
Wyróżnia się również rolę System Owner, czyli osoby odpowiedzialnej za architekturę danego systemu oraz koordynację integracji poszczególnych komponentów tworzonych przez squady. Zazwyczaj jest to dodatkowa funkcja pełniona przez członka zespołu, wykonywana jako dodatek do pracy wytwórczej i nie zajmuje więcej niż 10% czasu.
Model Spotify nie uznaje się za framework, ponieważ jest to opisany sposób funkcjonowania konkretnej firmy – może się okazać, że w przypadku innej organizacji będzie on nieefektywny. Dlatego podstawą do określenia właściwego kształtu zwinnego przedsiębiorstwa powinna być jego diagnoza.
Framework | Maksymalna liczba zespołów | Charakter zespołów | Dodatkowe role |
---|---|---|---|
LeSS | Large – do 8 zespołów; Huge – powyżej 8 zespołów |
Pracują nad jednym lub wieloma produktami | Obszarowy Właściciel Produktu |
Nexus | 9 | Pracują nad jednym produktem | Zespół Integracyjny Nexusa |
Scrum@Scale | Nieograniczona | Pracują nad wieloma produktami | Chief Product Owner, Scrum of Scrums Master, Executive Action Team, Executive Meta Scrum |
SAFe | Nieograniczona | Pracują nad wieloma produktami | Solution Architect, Solution Manager, Solution Train Engineer, System Architect, Product Manager, Release Train Engineer, Epic Owner, Enterprise Architect |
Model Spotify | Nieograniczona | Pracują nad wieloma produktami | Tribe Leader, Chapter Lead, System Owner |
Jak skalowanie zwinności wpływa na strukturę?
W przypadku koordynacji niewielkiej liczby zespołów i ludzi, których zakres prac jest ograniczony, wybrane metodyki (Large-Scale Scrum, Nexus) nie wpływają znacząco na strukturę i systemy całej organizacji. Dodając jednak role Właściciela Produktu, Obszarowych Właścicieli Produktu czy Scrum Mastera, przedsiębiorstwa stają w obliczu wyzwania, gdzie w strukturze organizacyjnej umieścić wybrane funkcje? Czy są to stanowiska menedżerskie? Jakie relacje liniowe zachodzą pomiędzy wspomnianymi funkcjami a osobami wykonującymi pracę? Czy powinno ustalać się formalne zasady komunikacji (np. zasada drogi służbowej) pomiędzy poszczególnymi rolami? Poza modelem Spotify (rola Chapter Leada) i LeSS Huge (relacja Właściciel Produktu – Obszarowy Właściciel Produktu) żadna z metod nie określa liniowych zależności. Wnioski płynące z analizy metodyk zorientowanych zespołowo mają również częściowe przełożenie na modele skalowania zwinności, obejmujące całą organizację (Scrum at Scale, Scaled Agile Framework). Scrum at Scale oraz SAFe stwarzają hierarchiczne poziomy: Executive, Scrum of Scrums oraz Zespołu, a także Full SAFe, Portfolio, Rozwiązania i Essential SAFe. Ponownie jednak twórcy nie wskazują, w jaki sposób należy rozwiązać kwestie liniowego zarządzania. W przypadku LeSS Huge wspomniane zwierzchnictwo zachodzi w kwestiach merytorycznych w zakresie koncepcji i specyfikacji projektowanego produktu. Brak doprecyzowania liniowych zależności wynika po części z manifestu agile, który wskazuje na współpracę oraz wzajemne uzgodnienia jako podstawowe mechanizmy koordynacyjne. Z praktyki wynika jednak, że pewne zależności liniowe pomiędzy rolami są tworzone. Innym rozwiązaniem aplikowanym przez firmy jest dodawanie stanowisk managerów liniowych obok ról przewidzianych w danych metodykach. Niesie to jednak ze sobą konsekwencje w postaci rozproszonego rozkazodawstwa, kosztów pracy oraz konfliktów kompetencyjnych. O tym, jak prawidłowo ukształtować strukturę, przeczytacie w artykule: „Kształtowanie kultury wspierającej organizacyjną zwinność”.
Podsumowanie
Skalowanie zwinności w organizacji wiąże się z koniecznością wprowadzenia dodatkowych ról. Ich ilość oraz umiejscowienie w strukturze zależy od tego, ile jednostek biznesowych zostanie objętych nowym sposobem pracy oraz jaki framework zostanie wybrany, by koordynować pracę wielu zespołów.
Źródła:
K. Kaczor, Scrum i nie tylko. Teoria i praktyka w metodach agile
C. Larman, B. Vodde, Large-Scale Scrum. Zwinne zarządzanie dużym projektem z LeSS
J. Sutherland, Przewodnik po Scrum@Scale
H. Kniberg, A. Ivarsson, Scalling Agile @ Spotify with Tribes, Squads, Chapters & Guilds
Artykuł jest fragmentem pracy magisterskiej pt. „Bariery i wyzwania zwinnej transformacji w banku” autorstwa Aleksandry Korzunowicz.