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

Jak wyglądają „Prawdziwe Przypadki Scrumowe”?

Rzadko widzę na rynku warsztaty oparte o case studies, a prywatnie uwielbiam brać w nich udział jako uczestnik. Od zeszłego roku prowadzę taką właśnie formułę pod nazwą „Prawdziwe Przypadki Scrumowe” a w czerwcu realizuję ten sam materiał w formie zdalnych warsztatów.

W przypadku takiego szkolenia trochę trudniej opowiedzieć jakie konkretne rzeczy wyniesie dany uczestnik, bo nie ma predefiniowanej agendy z perspektywy konkretnych technik czy modeli. Zamiast tego wprowadzam uczestników w świat realnych historii zespołów scrumowych i na tej bazie dyskutujemy o możliwościach oraz dzielimy się praktykami. W tym wpisie opowiem, w jakim schemacie pracujemy na szkoleniu.

Czytaj dalej Jak wyglądają „Prawdziwe Przypadki Scrumowe”?

Przekleństwo świadomości

Parę lat temu na Agile Coach Campie zaproponowałem jedną z sesji na temat, który nazwałem „przekleństwem świadomości”. Mam tu na myśli pułapkę, w jaką mogą Cię wprowadzić Twoje doświadczenia i Twoja znajomość różnych procesów, technik, praktyk i zjawisk, jakie zachodzą w zespołach zwinnych. Wszystkie te rzeczy powodują, że widzisz więcej, niż widzi najbardziej świadoma spośród osób z tego zespołu. Brzmi dobrze, więc dlaczego nazywam to przekleństwem? Łatwo w przypadku Agile Coacha wpaść w pychę, przekonanie, że wiemy lepiej. Myślimy: „ten zespół w ogóle nie umie ze sobą rozmawiać”.

Czytaj dalej Przekleństwo świadomości

Co mi dało to, że występuję publicznie?

Spotykam się czasem z takim podejrzliwym pytaniem „po co występuję”, albo „dlaczego występuję”. Przecież to jest wysiłek przygotowania się, stres i często też dopasowywanie swoich planów osobistych pod jakieś konkretne wydarzenie. To poświęcanie czasu wolnego, ale jednokrotnie też wręcz jest wydatek osobisty, gdy trzeba pojechać do jakiegoś innego miasta.

Czytaj dalej Co mi dało to, że występuję publicznie?

Jak pracować nad samoświadomością w pracy SMa i AC?

Gdy prowadziłem kiedyś rekrutację na Agile Coacha, przygotowałem treść ogłoszenia, które koniec końców nie ujrzało światła dziennego. Sposób jego tworzenia i zarys jego treści opisałem tu na blogu , pod którym w komentarzu PiMa napisał, że to ogłoszenie dotarłoby do osób o dużej samoświadomości. I właśnie samoświadomość, to jest jedna z tych rzeczy, które są dla mnie krytyczną cechą Agile Coacha czy Scrum Mastera.

Czytaj dalej Jak pracować nad samoświadomością w pracy SMa i AC?

Co dalej po Agile Coachu?

Kiedyś odbyłem bardzo ważną i bardzo szczerą rozmowę na temat ścieżki kariery Scrum Mastera i Agile Coacha. O ścieżce rozwoju samego AC jeszcze trochę opowiem pewnie w innych wpisach, przytaczając swoją historię, ale bardzo trafnie zostało mi zadane pytanie. „Dobrze, ale co dalej jak już będę tym Agile Coachem? A jak już będę naprawdę dobrym Agile Coachem, to co dalej? Co dalej mnie czeka w karierze? Czy jest coś jeszcze co można robić oprócz bycia dobrym Agile Coachem?”

Czytaj dalej Co dalej po Agile Coachu?

Historyjka o radości i wytrwałości sprzed kilku lat

Ważną zdolnością osoby, która wspiera zmianę całej organizacji, jest wytrwałość. O swojej wytrwałości mógłbym pewnie napisać książkę albo przynajmniej jej rozdział i zarys fundamentów wytrwałości zapisałem we wpisie jakiś czas temu. Ten wpis, to transkrypcja pewnego nagrania sprzed 3 lat, gdy jeszcze funkcjonowałem jako Lead Agile Coach w mBanku. Na świeżo, na gorąco, na podstawie bieżących wydarzeń w transformacji, zrobiłem sobie głosową notatkę dla samego siebie o tym, że warto czekać. Jak dobre wino, nagranie nabrało dla mnie głębi smaku po czasie, więc postanowiłem się nim podzielić w postaci tekstu (przyznam, trochę zredagowanego, by wydobyć więcej konkretu spod emocji).

Czytaj dalej Historyjka o radości i wytrwałości sprzed kilku lat

Istotność ciągłego kontaktu Agile Coacha z zespołami

Jednym z trybów, o których wspominałem w obszarach pracy Agile Coacha było współpracowanie z zespołem i wspólne rozwiązywanie problemów. Ten temat ma jeszcze jeden ważny aspekt, który zostawiłem na osobny wpis, a który ma znaczenie przy transformacji organizacji. Agile Coach, który odnosi sukcesy i jest angażowany w ważne zmiany w firmie może nieświadomie zacząć być nieobecny w zespołach. Jest on bardzo ważny przy sukcesie całej transformacji, ale uważam, że nie może odciąć się od pracy przy zespołach. Szczególnie niebezpiecznie robi się, gdy Agile Coach potrafi być kimś kto zaczyna gwiazdorzyć. Jest postrzegany jako ktoś, kto to uczestniczy w jakichś tajemnych i dziwnych spotkaniach dla wybranych. Jest bardzo skupiony na samym sobie i swojej rozpoznawalności wewnątrz firmy i na zewnątrz. Podobnie niebezpiecznie się robi, gdy gwiazdorstwo pokazuje cały zespół AC.

Czytaj dalej Istotność ciągłego kontaktu Agile Coacha z zespołami

Mogę zostać Twoim mentorem

Pisałem jakiś czas temu o mentoringu oraz moich mentorach. Od dawna chodził też za mną temat publicznego zadeklarowania możliwości bycia mentorem. Ten wpis to swego rodzaju forma oferty, którą mam do zaoferowania agilowcom chcącym podnieść swoje kompetencje czy rozwiązać trudny problem. Szczególnie ciepło myślę o osobach, które borykają się z trudną sytuacją w związku z epidemią – osoby, które muszą szukać pracy, albo ich firma czy zespół przeżywają bardzo duże kłopoty.

Do tej pory nigdy nie przemyślałem dokładnie jak mógłbym taki mentoring zareklamować. Mając kilkunastoletni staż pracy, setki godzin szkoleń już wiem to o sobie, że mogę też być takim mentorem dla innych. Dlatego zapraszam Was do kontaktu ze mną również w tej formule dopasowanej do dzisiejszych czasów – w postaci spotkania online.

Czytaj dalej Mogę zostać Twoim mentorem

Moje fundamenty wytrwałości

Co sprawia, że nie tracę „wiary”, że wytrwale propaguję zwinność w firmach, w których jestem? Dostałem od jednego z czytelników bloga dłuższego maila (dziękuję za niego również w tych częściach, których tu nie publikuję!). Moja odpowiedź jest na tyle generalna, a pytanie na tyle dobre, że dzielę się nią poniżej, przerywając długą ciszę na blogu.

[Czytelnik]: Już jakiś czas temu dostrzegłem, że daje za wygraną, poddaje się i nie walczę, o to żeby było lepiej. Miałeś kiedyś podobne doświadczenia, w których traciłeś wiarę w to co robisz?

Czytaj dalej Moje fundamenty wytrwałości