.st0{fill:#FFFFFF;}

Skalowanie Scruma dla początkujących 

 18 października, 2022

Artur Komendatskyi

Zakładam, że niemało naszych czytelników nie zna się na skalowaniu Scruma, ale większość przynajmniej coś o tym słyszało. Jeżeli Ty właśnie jesteś jednym z tych początkujących w temacie skalowania to przedstawiamy Ci post wprowadzający, który pomoże zrozumieć podstawy oraz wskaże dalszy kierunek nauki.

 

Czym jest Skalowanie Scruma?

Co to skalowanie Scruma i z czym to się je? Samo słowo „skalowanie” powinno nam podpowiadać, że chodzi o przeniesienie czegoś (w tym przypadku Scruma) na większy poziom. I właśnie. Według podręcznika Scrum w tym frameworku działamy w małych zespołach liczących typowo 10 osób lub mniej. A co, jeśli potrzebujemy więcej ludzi do tworzenia naszego produktu?

Możemy wyobrazić sobie, że podzielimy wtedy naszych Developerów na 2, albo nawet 3 zespoły. Nie ma w tym nic trudnego. A co jak mamy Produkt, tworzony przez kilkadziesiąt, a nawet kilkaset osób? Nie ma żadnego wyzwania w tym, żeby podzielić ich na 5 czy 10 zespołów, lecz jak Scrum Master lub Product Owner będzie w stanie wesprzeć taką ilość? Jak taka duża ilość ludzi ma wytwarzać jeden Przyrost? Czy Sprint Review będzie trwało 50 godzin, a Retrospektywa – 25? A jeżeli zatrudnimy więcej SM-ów i PO, to jak zrobimy porządek w tym całym przedsięwzięciu?

Za dużo pytań, za mało odpowiedzi. Jedną wskazówkę podaje nam legenda branży™ i jeden ze współtwórców Agile Manifesto Robert Martin vel „Wujek Bob”:

„W Agile’u zawsze chodziło o małe rzeczy tworzone przez małe zespoły. Duże rzeczy są tworzone przez połączone siły wielu małych zespołów” – „Czysty Agile”, R. Martin

 

Frameworki do skalowania Scruma

„Połączone siły wielu małych zespołów” jest ogólną zasadą, abstrakcją. Praktycznie jest nim cały Agile Manifesto. W realnym życiu potrzebujemy jednak jakichś konkretnych przepisów. I one istnieją – są to frameworki do skalowanie Scruma. Jest nich jednak za dużo, żeby omówić je wszystkie w jednym poście. Co więcej, każdy ma swoje zalety i wady. Dlatego skupię się na podstawach trzech najbardziej rozpowszechnionych. Są nimi Nexus, LeSS oraz… SAFe.

 

Nexus

Jest to najlepszy framework do rozpoczęcia własnej przygody ze skalowaniem Scruma. Jest to poszerzona wersja Scruma, stworzona przez tych samych ludzi. Ten framework daje nam podstawowy szkielet do skalowania. Nie zawiera on zbędnej teorii, czyli mówiąc po modnemu jest lightweight. Osoby, którzy już znają się na Scrumie potrafią opanować teorię Nexusa w kilka dni.

W tym modelu skalowania mamy do czynienia ze zbiorem od 2 do 9 zespołów Scrumowych. Ten zbiór nazywa się „Nexus”. Cały Nexus pracuje nad jednym Produktem z jednym Backlogiem. Dodatkowo mamy też Zespół Integracyjny, który odpowiada za integrację Przyrostów wszystkich zespołów tego zbioru w jeden spójny Przyrost. Nie musimy do tej drużyny oddzielnie kogoś zatrudniać – mogą to być inni członkowie Nexusa.

Każdy zespół w Nexusie ma swoje wewnętrzne Daily plus, a dodatkowo istnieje Nexus Daily które wspomaga integrację poszczególnych Przyrostów. Pozostałe wydarzenia są zawsze wspólne bądź łączone – jest to zasada, którą znajdziemy także w wielu innych frameworkach skalowania. Tutaj mamy do czynienia z Nexus Sprint Review, Nexus Sprint Planning oraz Nexus Retro. Tak samo są wspólne są Artefakty oraz osoba Product Ownera. Za to dla odmiany Scrum Masterów może być kilku.

Analogicznie do PSM, Scrum.org oferuje certyfikat Scaled Professional Scrum, który można uzyskać otrzymując przynajmniej 85% wyniku testu, który się składa z 40 pytań i kosztuje $250.

 

LeSS

Large Scale Scrum albo po prostu LeSS to framework do skalowania Scruma dla dużych oraz bardzo dużych produktów stworzony przez Craiga Larmana oraz Basa Vodde. Narzędzie to powstało na podstawie około 600 eksperymentów. Tak naprawdę są dwie wersję tego frameworku: LeSS – dla 2-8 zespołów oraz LeSS Huge dla większej ich liczby. Kluczowe dla obu wersji jest 10 zasad LeSS oraz Reguły Frameworku.

Wszystkie zespoły mają ten sam Sprint, a każde 2-3 zespołów dzieli między sobą Scrum Mastera. Podobnie jak w Nexusie, Sprint Review jest jedno dla wszystkich. Pozostałe wydarzenia zaś mogą odbywać się osobno. Każdy zespół prowadzi także swoje własne Daily. Jest jeden PO, który odpowiada za cały Produkt (brzmi podobnie do Nexusa?), ale ten Produkt może być podzielony na strefy (Areas), każda z których ma swojego PO (nieco na wzór proxy Product Ownerstwa).

Swoją znajomość tego frameworka można potwierdzić certyfikatem Certified LeSS Practicioner. Uzyskanie go musi być poprzedzone trzydniowym kursem. Certyfikat wymaga odnawiania co 2 lata.

 

SAFe

Trochę czuję się źle z tym, że piszę o tym na naszym blogu, ponieważ obiecywaliśmy, że tematy kontrowersyjne zostawiamy dla listy mailingowej. A SAFe jest tak bardzo kontrowersyjny. Mnóstwo SM-ów oraz Agile Coachów go nie lubi. Co więcej, wiele liderów branży twierdzi, że wcale nie jest on zwinny. Niemniej, jest on nie bez powodu rozpowszechniony. I mimo wszystkich jego wad potrafi rozwiązywać pewne problemy biznesowe – i jest to dla niektórych bardzo istotne.

Różnego rodzaju ScrumButy spotykamy najczęściej w dużych, sztywnych korporacjach. To, co (marnie) próbują osiągnąć te firmy – to uzyskać zalety Scruma za darmo, nie przestrzegając jego zasad, ani nie poświęcając się tak, jak on wymaga. I zazwyczaj nie mogą sobie pozwolić ani na te poświęcenie, ani na niezbędne zmiany. Niektóre branże, takie jak finanse międzynarodowe bądź opieka zdrowotna są obciążone przez regulacje państwowe. Niektóre z tych regulacji są sensowne, a inne nielogiczne i przestarzałe, ale z żadnych nie da się zrezygnować.

Dlatego bardzo często takie firmy adoptują SAFe-a, czyli Scaled Agile Framework. Sama już nazwa mówi, że jest to model skalowania Zwinności, a nie Scruma. Ten framework proponuje pewny kompromis pomiędzy Waterfallem, a Agilem dla ogromnych korporacji. Pozostają złożone hierarchie i skomplikowane procesy, pozostają także pewne współzależności, ale zespoły – przynajmniej w teorii – uzyskują dużo wolności do samozarządzania się na poziomie swojej codziennej pracy.

W SAFe zespoły są częścią Programu, które z kolei mogą być częścią Portfolio, więc zawsze pracujemy nad małą częścią ogromnego Przyrostu. Ten framework zgarnia aż 45% rynku modeli skalowania Zwinności! Jest też ogromny i dosyć złożony, co jest powodem, po pierwsze do krytyki go jako nie Agile’owego podejścia; po drugie, braku możliwości opisania jego zasad sensownie w ramach jednego postu. Jeżeli chcecie poczytać więcej o SAFe – dajcie znać w komentarzu.

 

Parę słów na koniec

Mam nadzieję, że teraz, drodzy czytelnicy, macie jakieś pojęcie… gdzie szukać więcej informacji o skalowaniu Scruma. Nie oszukujmy się – ten post miał na celu jedynie wskazanie trzech najbardziej popularnych metodyk. Z drugiej strony #białko też ma duże doświadczenie w skalowaniu zarówno Scruma, jak i zwinności. Przeprowadzamy też warsztaty oraz konsultacje indywidualne w tym zakresie. Polecamy się!

Artur Komendatskyi


6 lat doświadczenia w IT, PSM I-II, PAL I, starszy inżynier oprogramowania, Scrum Master zespołów zwinnych, Agile Leader

Your email address will not be published. Required fields are marked

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

  1. Cześć! Ja z chęcią chciałabym dowiedzieć się więcej o SAFe. Jestem z korporacji farmaceutycznej i też chcemy pracować w SCRUMie ale wymagania regulacyjne sa nie do podważenia.

  2. Hej, w końcu ktoś więcej zaczyna mówić o skalowalności a nie tylko "Scrumie na małą skalę". Chętnie poczytam i posłucham więcej o waszych przemyśleniach na temat SAFe oraz innych sposobów skalowania zwinności, zwłaszcza, że sam od niedawna mam okazję pracować w jednym z takich skalowalnych rozwiązań.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}