Czym jest Scrum@Scale?

Przyznaję, że kiedy pierwszy raz przeczytałem o Scrum at Scale nie zrozumiałem o co chodzi. Przeczytanie Przewodnika po Scrum@Scale nie pomogło. Nowe nazwy i diagramy tylko bardziej skomplikowały sprawę. Scrum of Scrums of Scrums? Jednak kiedy posłuchałem jak opowiada o tym sam autor — Jeff Sutherland, wszystko stało się proste. Postaram się opisać o co chodzi w prostych słowach.

Definicja Scrum@Scale

Scrum@Scale to 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. Scrum@Scale radykalnie upraszcza skalowanie poprzez wykorzystanie Scruma do skalowania Scruma.” [definicja z przewodnika S@S]

Jak to można wytłumaczyć prościej? Prawidłowo zastosowany Scrum pozwala na osiągnięcie dwa razy więcej dwa razy szybciej, Jednak przy dużej ilości zespołów i transformacji Agile zazwyczaj obserwujemy raczej spadek produktywności pojedynczego zespołu i pojedynczego developera. Scrum at Scale pozwala na organizację pracy wielu zespołów w ramach wielu produktów i efektywnie zorganizować całe przedsiębiorstwo bez utraty produktywności. Wszystkie zespoły pracują zgodnie z frameworkiem Scrum. To znaczy, że jesteśmy w stanie zmienić strukturę organizacji i przejść transformację do Agile.

Scrum@Scale proponuje patrzeć na każdy zespół jak na członka zespołu. W ten sposób powstaje Zespół Zespołów, który jest Zespołem Scrumowym. Taki zespół potrzebuje Product Ownera i Scrum Mastera. Teraz możemy mieć do pięciu Product Ownerów i Scrum Masterów. Product Ownerzy i Scrum Masterzy tworzą własne zespoły. To za dużo dla Zespołu Scrumowego, bo przecież może być tylko jeden Product Owner i Scrum Master. Z zespołu Product Ownerów musimy wyłonić jednego Product Ownera dla całego Zespołu Zespołów. Nazywamy go Chief Product Owner. Z kolei Scrum Master dla całości wyłoniony z zespołu Scrum Masterów to Scrum of Scrums Master.

Ta sama logika jest stosowana na kolejnych poziomach. Łączymy zatem kolejne piątki Zespołów Zespołów i otrzymujemy Zespół Zespołów Zespołów. 5x5x5 = 125 developerów.

Można powiedzieć, że skalujemy strukturę rekurencyjnie, albo jak fraktale. Struktury na każdym poziomie wyglądają identycznie. W ten sposób można skalować struktury w nieskończoność zachowując taką samą dynamikę. Ile poziomów potrzeba? To zależy od ilości zespołów. W Scrum mamy limit 3–9 członków Zespołu Developerskiego, w Scrum@Scale sugerowany limit to 5. Zatem, również w zespole zespołów może być maksymalnie 5 zespołów. Taki sposób skalowania tworzy architekturę niezależną od skali — architekturę bezskalową. Tworząc kolejne zespoły zespołów w końcu organizujemy całe działy organizacji i dochodzimy do poziomu zarządu. Architektura bezskalowa pozwala na skalowanie bez utraty produktywności poszczególnych zespołów. Podobne rozwiązania znane są w systemach biologicznych i budowaniu procesorów komputerowych.

via GIPHY

Dwa razy więcej, dwa razy szybciej w skali

W Scrumie mamy dwie siły działania pozwalające na osiąganie dwa razy więcej dwa razy szybciej. Jak można sprawić, żeby Zespół Developerski dostarczał więcej i miał większe Velocity? Poprzez usuwanie przeszkód na jego drodze. A kto jest odpowiedzialny za usuwanie przeszkód? Scrum Master. Jak sprawić, żeby Zespół Deweloperski dostarczał więcej wartości? Poprzez odpowiednie zarządzanie Product Backlog. A to oczywiście praca dla Product Ownera. Dlatego, również w Scrum@Scale potrzebujemy zapewnić usuwanie przeszkód przez Scrum Mastera i zarządzanie Product Backlog przez Product Ownera na wszystkich poziomach. Cykle Scrum Mastera i Product Ownera stanowią komponenty Scrum@Scale.

Cykl Scrum Mastera i Product Ownera

Ocena stanu tych komponentów pomaga organizacji zrozumieć jakie obszary transformacji wymagają większej uwagi w danym momencie. Dzięki zbudowaniu unikalnej, własnej mapy transformacji w oparciu o komponenty Scrum@Scale, zyskujemy unikalne podejście do Transformacji Agile w danej organizacji. To zupełne przeciwieństwo podejść proponujących strategię “to samo dla wszystkich”.

Nexus i LeSS pozwalają na zorganizowanie pracy wielu zespołów nad jednym produktem. W przypadku wielu produktów zaczynają się schody. Scrum@Scale pozwala korzystać ze Scruma do pracy nad wieloma produktami. W kontekście jednego produktu praca zespołów wygląda bardzo podobnie jak w Nexusie i to nie jest przypadek.

Scrum do poziomu zarządu

Rola Scrum Mastera jest skalowana przez przez wszystkie poziomy aż na końcu powstaje zespół Scrum Masterów dla całej organizacji. Ten zespół składa się z ludzi odpowiednio umocowanych w organizacji do usuwania przeszkód. Taki zespół nazywa się Executive Action Team. Każdy zespół odbywa spotkanie Daily Scrum. Zespoły zespołów odbywają spotkania Scaled Daily Scrum. I na końcu EAT odbywa codziennie spotkanie służące usuwaniu przeszkód, niwelowaniu zależności pomiędzy zespołami i koordynacji współpracy z nie-zwinnymi częściami organizacji. Spotkanie EAT jest ostatnim przystankiem dla dowolnego impedimentu, który nie został usunięty na niższych poziomach.

Product Owner Team najwyższego poziomu (Executive MetaScrum team) spotyka się z kierownictwem najwyższego szczebla i interesariuszami na spotkaniu Executive MetaScrum Event, gdzie tworzony jest i zarządzany Product Backlog dla całej organizacji. Na takim spotkaniu ustalane są produkty i priorytety na kolejny okres. W tym momencie może też nastąpić restrukturyzacja zespołów pod nowe produkty. Znowu, bardzo istotne jest, żeby w takim spotkaniu uczestniczyły odpowiednio umocowane osoby, które realnie mogą podjąć takie decyzje.

Dlaczego Scrum@Scale?

Pierwszym argumentem jest wyżej wspomniany sposób skalowania bez utraty produktywności. Kolejną zaletą Scrum@Scale jest zbudowanie zdrowych organizacji poprzez stworzenie kultury opartej na wartościach Scrum w empirycznym otoczeniu. Scrum@Scale zmienia strukturę organizacji, tworzy nowy system operacyjny, a to pozwala na faktyczną zmianę kultury. Zmiana kultury jest kluczowa do stworzenia Zwinnej Organizacji. Agile to głównie sposób myślenia (mindset).

Scrum@Scale adresuje również często pomijany aspekt zaangażowania zarządu w transformację. Bez odpowiedniego zaangażowania zarządu gruntowne zmiany są nie możliwe. W wielu organizacjach przechodzących transformację następuje starcie pomiędzy tradycyjnym podejściem do zarządzania od góry hierarchicznej organizacji i zwinnym podejściem od dołu. Scrum Masterzy i Produkt Ownerzy tracą czas na nieproduktywne rozwiązywanie sztucznych problemów, omijanie biurokracji i nie dostają potrzebnego wsparcia. W Scrum@Scale dowolny impediment i decyzja biznesowa mogą dotrzeć do zarządu w ciągu 1,5 godziny.

Scrum@Scale powoduje stosowanie prostego frameworku scrumowego na wszystkich poziomach organizacji i w ten sposób ogranicza biurokrację i niweluje potrzebę łączenia dodatkowych metod ze Scrumem.

Zobacz filmy na temat Scrum@Scale