Skalowanie Scruma - Scrum@Scale

Scrum Team powinien składać się z maksymalnie dziesięciu osób. Co jednak zrobić w sytuacji gdy nad jednym projektem musi pracować większa grupa specjalistów? Albo jeśli organizacja chce w całości przejść na zwinny sposób zarządzania? Aby rozwiązać ten problem, twórcy Scrum zaproponowali Scrum@Scale. Jest to bezskalowa architektura umożliwiająca organizowanie całych zespołów według zasad Scruma.

Skalowanie Scruma – omówione zagadnienia:

Wprowadzenie
Scrum@Scale
Scrum of Scrums
Dalsze skalowanie i problemy Scrum@Scale
Podsumowanie

Wprowadzenie

W miarę jak organizacja rośnie, mogą pojawiać się coraz większe problemy z jej efektywnością. Są one spowodowane skomplikowaną strukturą wewnętrzną, utrudnionym podejmowaniem decyzji, czy wyznaczaniem kierunków działania. Dlatego firmy, które działają zwinnie na poziomie małych zespołów projektowych, często szukają możliwości ich skalowania.

W wielu organizacjach skalowanie Scruma nie jest potrzebne. Nawet jeśli działa w nich równocześnie wiele Scrum Teams, ich działanie nie musi być koordynowane. W organizacji działa wtedy po prostu wiele niezależnych Scrum Teams. Nie oznacza to jednak, że jest to Scrum wielozespołowy. Potrzeba skalowania pojawia się dopiero, jeśli większa część organizacji pracuje nad jednym produktem. Zaś działania wielu Scrum Teams wymagają synchronizacji.

Większość organizacji, które stosują zwinne metody zarządzania na dużą skalę wybiera model SAFe, czyli Scaled Agile Framework. Dziś przyjrzymy się jednak temu, jak skalowany jest Scrum. Według 15th State of Agile report, w 2021 roku drugim w kolejności wyborem jest bowiem Scrum@Scale.

Scrum@Scale

W 1996 roku twórcy Scruma, Jeff Sutherland i Ken Schwaber, pracowali nad dużym projektem. W trakcie jego realizacji borykali się z problemem synchronizacji mniejszych zespołów pracujących w Scrumie. Wymyślili wtedy sposób jego skalowania, który finalnie nazwali Scrum@Scale.

Analogicznie do oficjalnego Przewodnika po Scrumie powstał Przewodnik po Scrum@Scale, który definiuje ten sposób skalowania pracy jako:

Framework w ramach, którego sieci Zespołów Scrumowych działające zgodnie z Przewodnikiem po Scrumie mogą rozwiązywać złożone adaptacyjne problemy, kreatywnie dostarczając produkty o możliwie największej wartości.

Podstawowym założeniem Scrum@Scale jest prostota i wydajność. Dlatego jego działanie oparte jest o bezskalową architekturę. Innymi słowy, wykorzystuje on Scruma do skalowania Scruma. W ten sposób Scrum Team złożony z pojedynczych osób pełniących role Product Ownera, Scrum Mastera czy Developera staje się Scrum of Scrums: zespołem złożonym z zespołów.

Scrum of Scrums

Scrum of Scrums jest to Scrum Team, w którym znajdziemy osoby pełniące zwyczajne role Scrum. Jednak w związku z tym, że zadaniem Scrum of Scrums jest integracja wyników pracy kilku Scrum Teams, potrzebne są w nim dodatkowe role oraz grupy:

Product Owner Team– grupa Product Ownerów spotykająca się w celu uzgodnienia priorytetów i stworzenia spójnej wizji produktu
Chief Product Owner– może być Product Ownerem jednego ze Scrum Teams, albo osobą zajmującą się wyłącznie Scrum of Scrums
Scrum of Scrums Master – jego zadaniem jest praca nad efektywnością Scrum of Scrums.

Spotykają się oni na takich samych Wydarzeniach Scrumowych i używają zbliżonych Artefaktów.

Dalsze skalowanie i problemy Scrum@Scale

Bezskalowa architektura Scrum@Scale sprawia, że może on być skalowany nie tylko raz. Jeśli organizacji potrzebna jest koordynacja zespołów na jeszcze większą skalę, może zostać utworzony Scrum of Scrums of Scrums.

Skalowanie Scruma może jednak rodzić problemy. A także zwielokrotniać te, które pojawiały się w podstawowych Scrum Teams. Dlatego polecane jest dopracowanie szczegółów współpracy wewnątrz każdego Scrum Team przed rozpoczęciem wdrażania Scruma na szerszą skalę. Oraz podejmowanie decyzji o skalowaniu Scruma jedynie w przypadku doświadczonych zespołów, które dobrze znają i rozumieją sposób działania i wartości Scruma.

Podsumowanie

Skalowanie Scruma nie jest łatwym zadaniem. Wymaga od Scrum Teams bardzo sprawnego stosowania zasad Scruma i synchronizacji wykonywanych zadań z innymi Scrum Teams. Dlatego podstawowe pytanie, na jakie należy odpowiedzieć brzmi: Czy skalowanie jest potrzebne?. To, że w organizacji działa wiele Scrum Teams nie oznacza automatycznie, że ich koordynacja przyniesie lepsze wyniki.

Jeśli organizacja zdecyduje się na powiększanie Scruma, zyskuje bezskalową architekturę, która może być z powodzeniem powiększana dalej. Każdemu powiększeniu towarzyszy jednak zwiększenie poziomu skomplikowania, z którym muszą sobie radzić Product Owner Team, Chief Product Owner oraz Scrum of Scrums Master.

Zapoznaj się z kolejnym wpisem dotyczącym Scruma: Co to jest Backlog Sprintu?

Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autor: Karolina Berecka
Karolina, jako project menadżerka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przepływu pracy i optymalizacji procesów. Jej umiejętności organizacyjne i zdolność do pracy pod presją czasu sprawiają, że jest najlepszą osobą do zamieniania skomplikowanych projektów w rzeczywistość.

Zobacz wszystkie posty