Tematem, który niezmiennie rodzi mnóstwo pytań, jest skalowanie metod zwinnych, a w szczególności Scruma. Ten framework opisuje bowiem zasady, jakimi kierować powinien się niewielki Zespół, który wytwarza produkt z wykorzystaniem empirycznej kontroli nad procesem. Nie do końca odpowiada to na potrzeby szeregu organizacji rozwijających produkty bardzo duże, nad którymi równocześnie pracują dziesiątki ludzi, podzielonych na wiele Zespołów. Stąd też potrzeba uzupełnienia Scruma dodatkowymi elementami, zasadami i praktykami, jeśli ma być do tego użyty.
Z pomocą przychodzą ochoczo twórcy metod skalowania Scruma. Najstarszą jest LeSS, podobny do niego jest młodszy Nexus, a nieco inne podejście proponują twórcy Scrum@Scale. Wszystkie one definiują dodatkowe zdarzenia, czasami wprowadzają nowe artefakty, uzupełniają definicje odpowiedzialności albo wręcz wprowadzają nowe role do procesu. Wszystko po to, aby poradzić sobie z sytuacją, gdy Zespołów Scrum pracujących nad jednym produktem jest wiele.
Kiedy zaczyna się skalowanie?
Jeśli nad jednym produktem pracują dwa Zespoły, to nie musi to automatycznie oznaczać konieczności skalowania Scruma. Wciąż jest możliwe przeprowadzenie Planowania Sprintu w ten sposób, że całe Zespoły wspólnie podzielą się zawartością Backlogu Produktu, a potem osobno ustalą sposób realizacji poszczególnych elementów. Bez trudu da się wspólnie prowadzić pielęgnację Backlogu Produktu. Trudności nie sprawi wspólny Przegląd Sprintu, można niektóre Retrospekcje Sprintów robić razem, raczej nie będzie też potrzeby wprowadzania dodatkowych spotkań koordynacyjnych, bo wystarczą zwykle Daily Scrumy.
Od biedy przy trzech Zespołach też da się to jeszcze zrobić, jeśli nie są one zbyt liczne. Gdy ludzi jest sporo albo rośnie liczba Zespołów, skalowania nie da się uniknąć, jeśli wszyscy pracują nad jednym produktem. Nie da się bowiem efektywnie realizować zdarzeń Scrum z udziałem kilkudziesięciu osób, więc pojawią się dodatkowe zdarzenia, w których biorą udział przedstawiciele Zespołów.
Kluczowy problem przy skalowaniu
Rozwój produktu przez wiele Zespołów naraz skutkuje powstawaniem zależności pomiędzy tym, czym się poszczególne Zespoły zajmują. Są to zależności zarówno techniczne, jak i funkcjonalne. Obrazowo mówiąc, jeśli kolejność realizacji zmian w produkcie będzie niewłaściwa albo sposób ich wykonania nie zostanie uzgodniony, całość nie będzie działać albo prac w ogóle nie uda się ukończyć.
Skalowanie jest więc sztuką identyfikowania zależności i ich ograniczania lub eliminowania poprzez takie planowanie prac, żeby uzyskać możliwie największą swobodę pracy dla każdego Zespołu.
Ma to oczywistą konsekwencję, jaką jest ograniczenie swobody decyzyjnej Product Ownera, który musi uwzględniać znane zależności przy porządkowaniu Backlogu Produktu. Mniej oczywistym skutkiem istnienia zależności jest spadek zdolności do reagowania na potrzebę adaptacji planów, bo często trzeba odłożyć ją w czasie ze względu na konieczność rozwiązania problemu zależności.
A i to nie wszystko. Im więcej zależności, tym mniej przewidywalny staje się proces, bo do istniejącej złożoności rozwiązywanych problemów dołączają skutki pojawiania się zależności, których nie udało się zawczasu zidentyfikować. Zdarza się też, że problemy z ukończeniem prac przez jeden Zespół uniemożliwiają dostarczenie czegokolwiek przez pozostałe Zespoły.
Niewątpliwie spada też przejrzystość, co dobrze widać na przykładzie Backlogu Produktu, który musi w jakiejś formie informować o zidentyfikowanych zależnościach i sposobie ich rozwikływania. Im zależności więcej, tym trudniej to zrobić i niemal zawsze kończy się to wprowadzeniem dodatkowych diagramów lub narzędzi, które funkcjonują obok Backlogu Produktu.
W praktyce skalowanie zawsze prowadzi do upośledzenia empirycznej kontroli nad procesem, niezależnie od zapewnień twórców metod takich jak LeSS czy Scrum@Scale, że da się tego uniknąć.
Lek czy trucizna?
Organizacja chcąca użyć Scruma do rozwoju naprawdę dużego produktu może wypracować własne podejście, aczkolwiek to wymaga czasu i środków na eksperymentowanie, więc zdarza się stosunkowo rzadko. Zdecydowanie łatwiej sięgnąć po jedną z wymienionych powyżej metod skalowania, więc większość wybiera właśnie tę drogę.
I tu do beczki miodu musi wpaść łyżka dziegciu. Samo istnienie gotowych metod stanowi sugestię, że skalowanie Scruma jest czymś zwyczajnym. Fakt, że tak wiele organizacji z nich korzysta, dodatkowo wzmacnia poczucie, że skalowanie jest standardem, że po prostu tak się buduje duże produkty i jest to najlepszy sposób postępowania.
Efektem może być rezygnacja z poszukiwania sposobu na uniknięcie skalowania poprzez sensowną dekompozycję produktu na niezależne od siebie rozwiązania stanowiące spójną, ale luźnie powiązaną całość.
A do beczki z modem trzeba dolać jeszcze całe wiadro dziegciu: żadna z metod nie zawiera mechanizmów, które prowadziłyby jej użytkowników do ograniczenia lub wyeliminowania potrzeby skalowania. Inaczej mówiąc, pomagają lepiej radzić sobie z zależnościami, ale nie prowadzą do ich zniknięcia.
Dlatego najlepsza rada, jaką można dać komuś, kto rozważa pracę w skalowanym Scrumie, brzmi tak: nie rób tego, a jeśli musisz, szukaj sposobu, żeby to zmienić. Nexus, LeSS czy Scrum@Scale w tym nie pomogą.
Nie tylko zależności
Oczywiście wraz ze wzrostem liczby osób (i tym samym Zespołów) pracujących z jednym produktem, pojawiają się też inne problemy.
Najprościej poradzić sobie z potrzebą integracji równolegle realizowanych zmian w jedną spójną całość nadającą się do użycia. Istnieją narzędzia i praktyki developerskie, których można tu użyć. Jeśli Zespoły tego nie potrafią, powinny zainwestować w rozwój niezbędnych kompetencji, bo alternatywą będzie marnowanie czasu na trwające tygodniami integracje, wydawanie nowych wersji produktu raz na kwartał lub co pół roku i trudność z przewidywaniem, co i kiedy uda się wytworzyć.
Nieco trudniejsze jest organizowanie zdarzeń Scrum tak, żeby zachowały sens i wartość. Jakoś trzeba ustalić, który Zespół czym się zajmie, konieczne okaże się koordynowanie Sprintów, by interesariusze nie pogubili się w tym, kiedy odbywa się Przegląd Sprintu. Każda z metod skalowania podpowiada zasady, jakimi można się przy tym kierować i na szczęście nie wymaga to łamania zasad obowiązujących w Scrumie.
Największy kłopot sprawia zarządzanie Backlogiem Produktu, bo zaczyna być on bardzo rozbudowany, a tempo, w jakim podejmowane są z niego poszczególne elementy do Sprintów, jest wysokie. Przy czym kłopot ten nie jest spowodowany samymi kwestiami organizacyjnymi i narzędziowymi, ale możliwościami Product Ownera, by za tym wszystkim nadążyć i nie utracić kontroli nad rozwojem produktu.
Jeden a może wielu Product Ownerów?
W Scrumie nie ma wątpliwości, że Product Owner produktu ma być dokładnie jeden. Dzięki temu jasne jest, kto podejmuje decyzje odnośnie do Celu Produktu, zawartości Backlogu Produktu, wreszcie tego, co robić, a czego nie robić. Nie ma rozmywania odpowiedzialności ani oczekiwania na to, aż się jakiś komitet ważnych ludzi dogada.
Do tego jeden Product Owner może być częścią Zespołu Scrum nie tylko formalnie, ale praktycznie, bo spędza z pozostałymi ludźmi w nim dość czasu, by zbudować dobrze działające relacje. To sprzyja zaangażowaniu, zapewnieniu przejrzystości, eliminuje wiele nieporozumień.
A jeśli Zespołów Scrum jest dziesięć i wszystkie budują ten sam produkt? Trzymając się zasad Scruma, Product Owner nadal powinien być jeden. Czy jednak będzie w stanie wywiązać się ze wziętej na siebie odpowiedzialności? Czy zdoła poświęcić wystarczający czas każdemu Zespołowi? Prawie na pewno nie.
Dlatego metody skalowania (z chlubnym wyjątkiem Nexusa) proponują podział odpowiedzialności za produkt pomiędzy wielu Product Ownerów i ustanowienie jednego z nich głównym, podejmującym kluczowe decyzje oraz koordynującemu pracę pozostałych. W parze z tym idzie najczęściej podział jednego Backlogu Produktu na kilka oddzielnych, opisujących obszary, za które odpowiadają poszczególni Product Ownerzy.
Takie rozwiązanie może być użyte zarówno przy tzw. skalowaniu horyzontalnym, gdzie wspomniane obszary funkcjonują na jednym poziomie i wzajemnie się uzupełniają, albo tzw. skalowaniu wertykalnym, w którym obszary te (a zatem Backlogi i Product Ownerzy) ułożone są w jakąś hierarchię.
Nie-Scrum?
Czy po rozmnożeniu Product Ownera lub Backlogu Produktu to wciąż jeszcze prawidłowo używany Scrum? Cóż, nie, i mam nadzieję, że to nie budzi wątpliwości. Mówiąc wprost, Scrum@Scale i LeSS to niezależne frameworki, a nie uzupełnienie Scruma dodatkowymi elementami lub praktykami. O ile zmiana wydaje się niewielka, jest w istocie bardzo duża, bo dotyka kluczowej odpowiedzialności w Scrumie.
Przecież to Product Owner ma zadbać o wskazanie, co Developerzy mają zrobić w produkcie, by przynieść korzyści interesariuszom. Scrum, jak cały Agile, jest sztuką wybierania tego, co warto zrealizować, a więc i maksymalizacji liczby rzeczy, które nie zostaną zrobione, bo szkoda na nie cennego czasu. Im mniej efektywne będzie działanie Product Ownera, tym większe ryzyko, że interesariusze otrzymają mało wartościowy albo wręcz bezużyteczny produkt.
Praprzyczyna problemu
Z jakiego powodu mnóstwo organizacji buduje bardzo złożone i duże produkty, nad którymi pracować muszą naraz dziesiątki, jeśli nie setki ludzi? Możliwe są dwa scenariusze, które do tego prowadzą.
Pierwszy: niewielki produkt rozrasta się z czasem, powoli przybywa ludzi w Zespole (a potem Zespołach), aż skalowanie staje się nieuchronne.
Drugi: organizacja intencjonalnie zaczyna budować rozwiązanie bardzo rozległe, uznając to za dobry pomysł lub konieczność.
W obu przypadkach można mówić o błędach decyzyjnych Product Ownera lub kogoś, kto sprawuje władzę nad produktem w momencie, w którym wciąż można względnie łatwo dokonać dekompozycji na kilka mniejszych produktów luźno ze sobą powiązanych. Czasem wynika to z braku umiejętności myślenia perspektywicznego (poważna wada, jak na Product Ownera), bywa emanacją obaw o utratę władzy, albo jest przejawem niezdrowej ambicji („ja nie dam rady?!”).
Inaczej mówiąc, budowanie ogromnych produktów nie jest nigdy nieuchronne, jest zawsze kwestią wyboru. Wszystkie konsekwencje są tego pochodną. Dobrze byłoby nigdy takiego wyboru nie dokonać.
Stało się, trzeba skalować – jak?
Cóż, wracamy do punktu wyjścia, czyli trzeba sięgnąć po jedną z gotowych metod albo wypracować własną. Przy czym bardzo mocno zachęcam, żeby szukać sposobu na wyeliminowanie potrzeby skalowania, albo przynajmniej poluzowania zależności w jakiś sposób np. oparty o praktyki i narzędzia developerskie.
Natomiast jeśli ma to być Scrum, Product Owner powinien być jeden, nawet jeśli Scrum@Scale czy LeSS podpowiadają inne rozwiązanie. A jeśli produkt rozrósł się tak, że już nie jest w stanie zapanować nad nim jeden Product Owner przy pomocy jednego Backlogu Produktu, produkt ten trzeba albo uprościć, albo podzielić na kilka mniejszych.
A bardziej po ludzku: sięgajmy po metody skalowania, jeśli już musimy, bo ułatwią one pracę Zespołów. Nie skalujmy natomiast odpowiedzialności Product Ownera. Jeśli pojawia się taka konieczność, to sygnał, że produkt jest po prostu za duży, by można nadal unikać jego podziału.
Skalowanie odpowiedzialności Product Ownera to nic innego, jak próba rozwiązania nierozwiązywalnego problemu: skoro jedna osoba nie ogarnia całości, upieramy się, by rozmnożyć tę osobę, zamiast ograniczyć rozległość tego, co będzie musiała rozumieć i czym ma skutecznie zarządzać. A wtedy do istniejących już trudności dokłada się kolejna: jak koordynować działanie wielu Product Ownerów, aby zapobiec chaosowi? Przy czym wciąż każdy z nich będzie musiał rozumieć całość produktu, bo bez tego się nie dogadają. Zamiast jednej osoby, która przestała ogarniać zbyt duży produkt, będzie tych osób kilka.
Można więc powiedzieć, że skalowanie odpowiedzialności Product Ownera jest w istocie skalowaniem problemu, który próbujemy rozwiązać. Wszystkie trudności pozostaną, a to, że boryka się z nimi więcej niż jedna osoba, nie tylko nie pomoże, ale spowoduje nowe problemy.
Dlatego nie warto tego robić i gdy produkt staje się za duży, rozsądniej jest podzielić go produkt na dwie lub nawet kilka części.
Podział zamiast hierarchii
Z pozoru taka dekompozycja niczym nie różni się od ustanowienia wielu Product Ownerów dla jednego produktu i wprowadzenia kilku Backlogów zamiast jednego. Niemniej rozwiązanie to ma kilka zalet.
Po pierwsze, istnienie kilku produktów pozwoli Zespołom na wytwarzanie niezależnych Przyrostów, które mają realną wartość dla interesariuszy. To daje większą swobodę Developerom i pozwala na częste wdrażanie niewielkich zmian, zwłaszcza jeśli ograniczone są one do jednego z produktów.
Po drugie, podział wymusi przebudowanie istniejących rozwiązań tak, by pojawiły się klarowne granice między powstałymi dzięki temu produktami. Ich istnienie i konieczność zapewnienia możliwości niezależnego rozwoju zmusi Zespoły do szukania skutecznego sposobu na eliminowanie lub przynajmniej ograniczenie konieczności ścisłego koordynowania prac. Inaczej mówiąc, zamiast skupiać się na jak najlepszym skalowaniu, ludzie dążyć będą do unikania takiej konieczności.
Po trzecie: podział produktu na dwie lub kilka niezależnych części wymaga zidentyfikowania, co ma wartość samo w sobie, więc daje szansę na pozbycie się wszystkiego, co nie jest potrzebne. W ten sposób dodatkowo redukuje się skalę całego przedsięwzięcia, a tym samym powodowane nią problemy.
Po czwarte, każdy wydzielony produkt będzie miał własnego w pełni decyzyjnego Product Ownera, który jest w stanie w pełni zrozumieć to, czym zarządza. Tak, będą oni musieli ściśle ze sobą współpracować, ale zbędny okaże się główny Product Owner, bo odpowiadać będą za wartość produktu wprost przed interesariuszami. A to, że będą faktycznymi decydentami, sprzyja zbudowaniu dobrych relacji z Zespołem, którego częścią będą. Lub z Zespołami, jeśli będzie ich dwa albo trzy.
I wreszcie po piąte: im lepiej zdefiniowany jest produkt, tym większą motywację mają rozwijający go ludzie. Jeśli produkt jest jeden, ale za to ogromny, wprowadzanie w nim różnych obszarów logicznych i tworzenie jakichś pseudo-Backlogów utrudnia zrozumienie całości, a ciężko robić dobrze coś, czego się nie rozumie, nie mówiąc już o zaangażowaniu w taką pracę.
To wszystko oznacza, że jeśli już musi być kilku Product Ownerów i kilka Backlogów Produktu, zdecydowanie lepiej zrobić to w myśl zasad Scruma, a nie frameworków podpowiadających, jak go skalować. Zamiast skalować Scruma, lepiej podzielić produkt. Artefaktów i ludzi może będzie tyle samo, ale przejrzystość i możliwości efektywnej współpracy wzrosną. No, i Scrum pozostanie Scrumem, a choć to nie wydaje się kluczowe, jest ważne, bo łamiąc jedną zasadę, szybko można zacząć ignorować pozostałe.
Jak dokonać podziału?
Łatwo napisać o dekompozycji dużego produktu na kilka mniejszych, zdecydowanie trudniej ją przeprowadzić. Nie twierdzę, że to proste ani że istnieje jakaś magiczna metoda, którą można się przy tym posłużyć. Mogę natomiast podać przykłady podziałów zupełnie nieudanych oraz takich, dzięki którym Zespoły odzyskały możliwość efektywnego działania. Zajmę się tym, ale już w jednym z kolejnych artykułów, który opublikuję wkrótce.