„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).

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ć 🙂

Co jest groźnego w zespołach wsparcia i koordynacji?

W organizacjach, w których pracowałem i w tych, z którymi współpracuję jako konsultant, od czasu do czasu napotykam wzorzec organizacyjny zespołów wsparcia i koordynacji projektu. Zespół taki budowany jest w przypadku, gdy realizowane jest jakieś większe przedsięwzięcie (projekt, program), zaangażowanych jest co najmniej kilka zespołów i oczywiste jest dla kierownictwa firmy, że w takiej sytuacji „musi” być ktoś, kto „ogarnie całość” przedsięwzięcia. Mam tu na myśli organizacje, które są jeszcze w trakcie uczenia się podejścia zwinnego i nie ma w nich jeszcze zaufania albo kompetencji w skalowanym podejściu do zwinności. Powstaje funkcja albo grupa funkcji w stylu koordynatora czy kierownika projektu, jakieś role dodatkowego wsparcia zespołów (zapewnienia jakości, utrzymania architektury, spójności biznesowej). Z perspektywy zwinnego podejścia i konkretnych metod skalowania automatyczna reakcja niejednego agile coacha to sugestia, żeby kompletnie usunąć te dodatkowe funkcje. Sam też mam takie preferencje, ale w codziennej pracy z zespołami i menedżerami nie zawsze uda się przekonać do rozwiązań, które uznają za zbyt ryzykowne i niezgodne z ich intuicją. W tym wpisie zahaczę kilka powodów, dla których uważam takie pomysły za niebezpieczne z perspektywy zwinności i podpowiem kilka kierunków, jakimi można takie struktury usprawnić (metodą małych kroków i ewoluowania tych struktur we właściwszą stronę).

Czytaj dalej Co jest groźnego w zespołach wsparcia i koordynacji?

Refleksje po Agilii17

Wczoraj skończyła się Agilia’17, w której wziąłem udział jako uczestnik. Na agile247.pl na dniach wypuszczę poukładaną relację z najlepszych prezentacji, a w tym wpisie parę refleksji osobistych. Podobnie jak z Zarządzania Zespołami IT, wrzucam te przemyślenia kompletnie bez priorytetyzowania, świadomy że wychodzi z tego miszmasz o skalowaniu, roli agile coacha, transformacjach i korzystania z konferencji jako takich.

Czytaj dalej Refleksje po Agilii17