„Kiedy zacząć skalować zwinność” to niewłaściwe pytanie

„Jak wyznaczyć granicę między tym co dostarczają pojedyncze, niezależne zespoły Scrum a kiedy musimy przestawić się na framework Nexus lub SAFe” – to pytanie mailowo zadał Paweł, jeden ze słuchaczy podcastu Porządny Agile. Moją mailową wymianę z Pawłem, za jego zgodą, postanowiłem wrzucić również na bloga.

Obawiam się, że zadane pytanie jest za mało otwarte. Już z góry zakłada, że istnieje granica, po której trzeba się przestawiać na frameworki skalowania. I tu jest podwójna pułapka.

Zacznę od tej prostszej – skalowanie zupełnie nie musi opierać się na frameworkach, a zwłaszcza nie na tak ciężkich jak SAFe. Wiele zespołów (również z moim udziałem) skalowało podejście zwinne zanim ktokolwiek umiał nazwać jakiś model (jak zaczynałem wiele lat temu, najlepszą rekomendacją, jaka była w obrocie szkoleniowym, było „zrób Scrum of Scrums”). Nie mając gotowców na rozwiązania skalowania, trzeba było sobie je samemu stworzyć, zachowując ducha zwinności w większych organizmach. Więc się kombinowało z hierarchią PO, jednym PO dla wielu zespołów, współdecydującymi PO. Dzieleniem zespołów na obszary, umawianiem się na konkretnie zakresy i interfejsy, próby ciągłej integracji albo próby połączenia dobrze zaplanowanych części rozwiązania tuż przed wdrożeniem. Pracę na jednym PBL i na wielu, pracę poprzez SoS PO, SoS Smów, SoS devów, SoS reprezentantów, communities architektów, gildie. Specjalnie wymieniłem wśród opcji rozwiązania, które dzisiaj raczej nie są rekomendowane przez oficjalne frameworki.

Wszystko działało i nie działało jednocześnie, jak mawia Alistair Cockburn. A potem „przemysł” zaczął to wszystko standaryzować, certyfikować, opisywać w modelu… Ja uważam, że tym samym niepotrzebnie zamyka się ścieżkę do eksperymentów z procesem i kształtowania praktyk, które są dopasowane do kontekstu tej konkretnej organizacji (jej specyfiki i jej dzisiejszych umiejętności pracy zwinnej).

Dzisiaj zdecydowanie zgadzam się ze schematem – „zacznij od dobrego jednego zespołu scrumowego” (i ironiczne jest to, że ugruntowałem sobie tą myśl na szkoleniu z Nexusa). Potem zobacz jak ten jeden zespół współpracowałby z drugim zespołem (lub jak by się zachował, gdyby urósł na tyle, że potrzebuje się podzielić). Rekomenduję skalowanie organiczne i ewolucyjne, bez spięcia się na to, że w międzyczasie ktoś trochę usztywni zasady działania albo chwilowo, w czyjejś opinii, odejdzie od Scruma lub jego idealnych wytycznych „jak to powinno się robić w skali”. Jeśli w tym wszystkim będzie funkcjonować Retrospektywa, będzie powstawał Przyrost najrzadziej co Sprint, będą działać SMi, cały czas będziemy się skupiać na próbie utrzymania reguł scrumowych (ich intencji a niekoniecznie literalnej linii interpretacji jednozespołowego Scruma), to w drodze takich eksperymentów zespoły skalujące dopracują się czegoś unikalnego i skutecznego (ciągle poprawiając wcześniejsze nieskuteczności).

Swoją drogą – jeśli potrzebujesz poprawić to, jak realizowane są Retrospektywy w twoim zespole, to polecam Twojej uwadze webinar Porządna Retrospektywa Sprintu mojego współautorstwa, który jest już w sprzedaży.

Podsumowując – frameworki do skalowania są ciekawe, mogą być inspiracją, która pokazuje na jak różne sposoby można rozwiązać poszczególne aspekty współpracy wielu zespołów i warto je znać (najlepiej wiele z nich). Taką samą inspiracją może być szukanie realnych case’ów skalowania z danych organizacji (będą one mniej „gładkie” w porównaniu do schematów skalowania danego autora, ale za to bardziej… prawdziwe). Najwięcej wartości widzę, by to wszystko jednak połączyć w eksperymentowanie i doskonalenie swojego własnego procesu.

Z drugą pułapką w pytaniu, o której myślę, będzie chyba trudniej z zaakceptowaniem. Za dużo razy widzę w organizacjach automatyzm w chęci skalowania, zamiast zastanowienia się nad tym, jak de-skalować (czyli realizować działania, które powodują, że skalowanie nie jest niezbędne). Wiele organizacji zbyt łatwo wpada w schemat – „dorzucajmy kolejne zespoły! intensyfikujmy działania!”, mając głównie przed oczami „urobek” / output (ilość np. wyprodukowanego kodu, wielkość zbudowanego systemu czy jego feature’ów), zamiast rzucić okiem na rezerwy, jakie są po stronie „rezultatu” / outcome’u (jak najwięcej wartości, uzyskiwanej sprytnymi, prostymi, przemyślanymi rozwiązaniami). Łatwiej dotrudnić kolejne zespoły (i często bezwiednie wpaść w pułapkę złożoności systemowej, która wynika ze skali) niż rozumieć klienta, porządnie priorytetyzować, mieć czystą wizję produktu, pielęgnować prostotę, robić mniejsze eksperymenty. I ograniczać skalę również poprzez dbałość o stronę techniczną oraz wysokie kompetencje posiadanej ekipy. W tym temacie polecam jako inspirację książkę „Rework”, która pokazuje alternatywne myślenie – jak można budować i utrzymać produkt w dużej skali bardzo niedużą grupą ludzi.

Podsumowując (nie ja to wymyśliłem, mi się to tylko potwierdza w moim doświadczeniu) – zanim zaczniesz skalować, wyczerp wszystkie możliwości, jakie są, by nie skalować. Te „wszystkie” możliwości to między innymi pojedynczy silny zespół produktowy, dobra priorytetyzacja celów, dobra praca produktowa całej drużyny, podejście iteracyjno-przyrostowe w stronę osiągania celu, duża dbałość o techniczny wymiar rozwiązania no i jeszcze strona „miękka” – mocne zgranie, zaangażowanie, komfort psychiczny całego zespołu. Dopiero po wyczerpaniu tych wszystkich pomysłów, odpowiedź na pytanie jest banalna – poszukaj swoich opcji na skalowanie gdy Zespół Scrumowy przekroczy ~10 osób. Z perspektywy całej organizacji, wiele różnych wariantów skalowania może być stosowanych w zależności od okoliczności.

Wiem, że mnóstwo osób pracuje w organizacjach, które od pierwszego dnia eksperymentu ze zwinnością mają skalowanie na kilkaset osób i to, co piszę, wydaje się niedopasowaniem do realiów – tylko ja też to samo bym w takiej dużej firmie robił. Zaczęcie od razu od skalowania, z wielkim frameworkiem, ma taką masę pułapek, że sam mimo swoich doświadczeń nie umiem ich nazwać wszystkich, wiem, że jeszcze ich nie znam.

PS. Ten wpis jest pokłosiem ważnych rozmów w przeszłości z Bartkiem Janowskim, którego zapamiętałem z hasła mniej więcej o takim brzmieniu „Jak pytasz, jak skalować, to już z góry założyłeś, że będziesz skalować, a tak być nie musi”. Po czym braliśmy się za wielopiętrowe dywagacje jak się za to skalowanie, w naszych ówczesnych realiach, zabrać 🙂