Get Agile #2 | Jurgen De Smet | Descaling Organization

Tomek Wykowski: Certyfikowany Trener Scrum, właściciel firmy ProCognita

Mieliśmy rozmawiać o pracy w dużych organizacjach, ale powiedziałeś, że pomagasz kadrze kierowniczej w upraszczaniu ich organizacji. Na czym to polega?

Jurgen De Smet: Certyfikowany Trener LeSS z ponad 20-letnim doświadczeniem we wdrażaniu Scrum, z ponad 10-letnim doświadczeniem we wdrażaniu LeSS, współzałożyciel firmy Co-Learning.

Organizacje napotykając problemy stosują szybkie poprawki. Szybkie poprawki oznaczają dodawanie nowych procesów lub reguł do już istniejącego zestawu, aby zapobiec pojawianiu się konkretnych problemów. Na przykład, jeśli wystąpił problem podczas wdrażania systemu na produkcję co mocno zakłóciło to środowisko, szybka naprawa może brzmieć: „Zainicjujmy jakiś dodatkowy krok między stworzeniem oprogramowania a instalacją abyśmy mieli pewność, że problem się nie powtórzy”. Najprawdopodobniej za tą pracę będą odpowiedzialni inni ludzie, więc powstanie kolejny dział. Wiele z tych szybkich poprawek zostaje zastosowanych z powodu presji czasu lub jakiejś wyimaginowanej presji i zaczyna tworzyć skomplikowaną strukturę. Agile wymaga prostych struktur i szybkiego podejmowania decyzji, więc jeśli naprawdę chcesz czerpać korzyści z wdrożenia Agile, oznacza to, że musimy uprościć organizację poprzez zmniejszenie złożoności. To ogromnie spowalnia organizację, zwłaszcza jeśli chodzi o otrzymywanie prawdziwych informacji zwrotnych na temat tego, co organizacja chce wprowadzić na rynek. Czy rozwiązanie jest wartościowe czy nie? Nie wiemy. Skomplikowana struktura i długie cykle sprzężenia zwrotnego zwiększają ryzyko tworzenia rzeczy, które mogą się nawet nie udać.

Jakie napotykasz problemy w upraszaczniu organizacji?

To pytanie ma wiele różnych aspektów. Po pierwsze, chciałbym wspomnieć o prawach Craiga Larmana, które mówią, że „organizacje pośrednio nie chcą zmieniać stanowisk menedżerów pierwszego szczebla, słabych struktur i stanowisk specjalistycznych”. Tak więc, domyślnie, chcemy, żeby tak pozostało. Wiele organizacji zaczyna stosować praktyki Agile, używają terminologii Agile, ale nie zmieniają rzeczywistego zachowania. Jeśli tak naprawdę nie odnoszą się do prawdziwej przyczyny swoich problemów, nie są elastyczne i zwinne.

Nowe etykiety na starych rzeczach?

Lub unikanie prawdziwych zmian, które są potrzebne. Nie korzystają z kultury Agile, tak jak to jest zamierzone. Poza tym musimy naprawdę zejść na poziom zespołu, dotknąć brudu i nieszczęścia, które nawarstwiły się przez lata z powodu presji – posprzątajmy to. Zmiana struktur organizacyjnych, nowe role, oczekiwania na papierze są łatwe, mają natychmiastowe zastosowanie, ale zachowania się nie zmieniają. Firmy zapominają o jednym z głównych aspektów Agile czyli zwinności na poziomie organizacyjnym – sprawności technicznej. Monolity, kiepska architektura i jakość kodu, które mieli w przeszłości. Wiele technicznych spraw powraca. Podobnie jak zależności. Nie postrzegam zależności jako problemu, to tylko okazja do poprawy, pozbycia się ich. Większość zależności wynika ze złych decyzji architektonicznych lub struktury organizacyjnej. Nad obydwoma musimy pracować jednocześnie. W tym miejscu organizacje błędnie interpretują wiele rzeczy. Pracują nad jednym, ale nie nad drugim, a potem napotykają ograniczenia.

Jak rozpocząć transformację?

Ja zaczynam się od poznania kontekstu. Nie wierzę w podejście „kopiuj i wklej”. Musisz zrozumieć, w jakiej dziedzinie biznesowej pracujesz, jakie są ograniczenia rynkowe, techniczne, architektoniczne, jak jest skonfigurowana aktualna współpraca i struktura organizacyjna, jakie są tam procesy. Musisz ocenić organizację z wielu różnych perspektyw. Wtedy zastanawiasz się co pasuje, co nie i od czego należy zacząć. To jest najważniejsze pytanie: od czego właściwie zaczynamy? Pierwszą rzeczą, której próbujemy, jest wykonanie pilotażu. W przeszłości szukałem obszaru o niezbyt wysokim priorytecie. Wówczas jeśli się nie uda, nie jest tak źle. Ale ponieważ wybieramy coś, co nie ma wysokiego priorytetu, nie zwracamy na siebie uwagi i zasługujemy na to, aby odnieść sukces. Obecnie szukam domen o dużym wpływie, w których możemy przeprowadzić weryfikację koncepcji. Wtedy, jeśli poprosimy ludzi biznesu i użytkowników o udział w Review, są zainteresowani i chętnie przychodzą. Jeśli nie jest to sprawa o wysokim priorytecie, użytkownicy biznesowi po prostu odmówią przyjścia. Mają prawo odmówić, ponieważ są ważniejsze rzeczy. Wtedy nie czerpiesz korzyści z nowego modelu pracy i wracasz z powrotem do starej struktury.

Czyli w obszarach o wysokim priorytecie masz wsparcie zarządu i łatwiej jest usunąć wszystkie te ograniczenia, o których wspomniałeś?

Myślę, że to jest kluczowe. Potrzebujesz wsparcia z góry, które pozwala na działania wolontariuszy od dołu. Zwykle pracujemy z wolontariuszami. Jeśli ludzie dobrowolnie zdecydują się być częścią zmiany, będą chcieli odnieść sukces, będą bardziej skłonni do korzystania z nowych praktyk i technik.

Jednym z bardzo popularnych podejść jest jednoczesne przeprowadzanie transformacji całej organizacji. Zatrudniasz konsultantów; przychodzą, a po jakimś czasie otrzymujesz nową strukturę i ogromny rachunek od konsultantów. Mówisz, że chcesz budować świadomość – znaleźć wolontariuszy, a nie tylko mówić ludziom, że mają pracują w innej strukturze.

Głównym powodem pracy z wolontariuszami i upewnienia się, że mamy wsparcie managementu, jest posiadanie odpowiednio dużego elementu układanki, aby pokazać wpływ na biznes w wystarczająco krótkim czasie. Aby wygenerować pewne zmiany w metrykach istotnych dla biznesu. Jeden zespół w dużej organizacji nie wywrze wpływu. Wolontariuszom zależy, aby zmiana się powiodła, więc zrobią wszystko aby wpływ zmiany był istotny. Jeśli potrafisz wywrzeć zauważalny wpływ, zdobywasz więcej mandatu – więcej uwagi ze strony kierownictwa. I wtedy organizacja decyduje czy poszerzyć definicję produktu z perspektywy LeSS, czy przejść do innych działów, które początkowo mogą nie być częścią zmiany.

Dlaczego więc nie cała firma jednocześnie?

Umiejętności, wiedza i zrozumienie systemu. Każda firma ma inny system, aspekty i inne ograniczenia rynkowe. Musisz być w stanie je zbadać. Ta sama firma, ale różne działy lub różne lokalizacje, nawet w tym samym kraju, będą miały inną dynamikę systemu. Najprawdopodobniej nie masz wystarczającego doświadczenia i umiejętności, aby od razu wesprzeć tego rodzaju ogromną zmianę. Inną rzeczą jest to, że wdrażając Agile, Scrum, LeSS uzyskujesz bardzo wysoki poziom przejrzystości. Widzisz więcej rzeczy, których nie spodziewałeś się zobaczyć. Więc jeśli zmieniasz całą firmę i nagle taki problem uderza Cię w twarz, to ludzie nie poświęcają czasu na odkrywanie lepszych sposobów pracy. Natychmiast wracają do starych struktur i to jest pułapka transformacji Agile. Możesz wziąć kawałek układanki jak zrobiliśmy to na przykładzie Base Company. Współpracujemy z Tech Mahindra, ogromną firmą konsultingową w ramach umowy projektowej w modelu CAPEX. Dodaliśmy aneks, aby wykluczyć z umowy jeden określony obszar, abyśmy mogli nad nim pracować. Stworzyliśmy coś w rodzaju małej czarnej plamki. Potem gdy stakeholderzy zobaczą, że w tym obszarze po zmianach jest o wiele lepiej, są otwarci na renegocjowanie pełnej umowy i ruszenie do przodu. Jeśli od razu chcesz zmienić wszystko, będzie to najprawdopodobniej zbyt ryzykowne. Tak więc, tworząc mały obszar, w którym możesz odkryć lepsze sposoby pracy w ich kontekście, dajesz sobie przestrzeń na spokojną naukę. Dajesz również możliwość rozwijania umiejętności coachingowych, Scrum Masterów lub Agile Coachów wewnątrz organizacji. Ludzie zbytnio polegają na zewnętrznych firmach doradczych.

Wygląda na to, że twoim celem jest bycie zbędnym w organizacji

Moim celem jest jak najszybsze wyjście z firmy, aby mogli polegać na własnych umiejętnościach. Jeśli chcą rosnąć, muszą szybko rozwijać swoje umiejętności. Nie staniesz się dobrym Scrum Masterem obserwując jak ktoś inny wykonuje pracę. Moim zadaniem jest dostarczyć zespołom niezbędne umiejętności, upewnić się, że ludzie zdobywają praktyki w zakresie poprawiania procesu i potrafią nauczyć tego innych. Jeśli firma musi polegać na zewnętrznych konsultantach, to jest dla mnie recepta na porażkę. Gdy tylko znikną zewnętrzne siły, zmiana upadnie i wróci do poprzedniego stanu.

Czy jest coś jeszcze, co musi się wydarzyć, aby transformacja zakończyła się sukcesem?

Coś, o czym już wspomnieliśmy, czyli praktyki inżynieryjne. Ich niewystarczający poziom staje się ograniczeniem. Na przykład, jeśli nadal utrzymujesz kod na gałęziach, które mają długi okres życia ludzie miesiącami nie mogą dotknąć tego samego kodu bo ryzykują piekło integracji. Takie praktyki są szkodliwe w środowisku Agile, w którym chcesz szybko uzyskać informacje zwrotne, sprawdzić, czy to, co tworzysz, ma prawdziwy wpływ na rynek. To jest obszar nad którym musimy pracować i nawet jeśli zrobimy mały krok, oznacza to również, że otaczające zespoły będą musiały zostać zaangażowane. Refaktoryzacja, środowiska kompilacyjne i wdrożeniowe to obszary, gdzie należy poprawiać poziom praktyk inżynieryjnych. Nie mówię, że muszą być perfekcyjne, ale potrzebny jest pewien poziom, który nie jest przeszkodą dla zwinności biznesowej.

Powiedziałeś: „w momencie, gdy podejmujemy niewłaściwą decyzję architektoniczną, otrzymujemy zbyt skomplikowany system”. Często słyszymy, że „nie możemy pozwolić, aby każdy zespół zmienił architekturę. Potrzebujemy jednego architekta który to spina.”.

Jeden architekt to niekoniecznie dobre podejście. Pracuję na środowiskach wielozespołowych. Mam dużą grupę ludzi, a architektura jest podstawową umiejętnością w zespołach. Nie mówię, że musi to być jedna osoba lub dwie osoby; to umiejętność w zespole. Jeśli pracujemy nad jednym obszarem, zespół musi rozumieć, w jaki sposób wpasowuje się on do pełnego produktu. W tym celu możesz zrobić warsztaty architektoniczne; na przykład Event Storming, ponieważ daje ci to zrozumienie domeny. Ludzie nagle rozumieją, że to jest rodzaj architektury, do której musimy dążyć wykonując małe kroki

Przenosimy obowiązki architektoniczne na zespół, ale jak przekonać architektów którzy podejmowali kiedyś wszystkie decyzje architektoniczne do podzielenia się “władzą”?

Jeśli pojawia się opór to znaczy, że nie mamy wystarczającego wsparcia z góry i musimy spróbować innego podejścia. Pierwszym krokiem jest zaproszenie architektów na sesje Refinementu, podczas których odkrywamy, jakie są wymagania funkcjonalne. a następnie budujemy równolegle obok siebie modele architektoniczne. Mogą oni wnieść swój wkład, mogą zabrać głos, podobnie jak członkowie zespołu. Dzięki współpracy zdobędziemy większe zaufanie. Kontynuując współpracę, będąc również częścią sesji Review , zaczną rozumieć jakie umiejętności mają zespoły w tym zakresie. Niektórzy z architektów czerpią z tego tak dużą satysfakcję że stają się częścią zespołów, a tak zaczynamy budować mosty. Myślę, że to jest kluczowe – budowanie mostów, pokazywanie ludziom, jaki duży wpływ mogą mieć, gdy są częścią zespołu.

Obserwujesz przemianę firmy. Kiedy wiesz, że nie cofnie się w momencie, gdy odejdziesz? Skąd wiesz, że możesz wyjść z organizacji?

Myślę, że nigdy nie wiesz na pewno. Myślę, że bardziej odpowiednim pytaniem jest: jak możemy zapobiec powrotowi do starych struktur? W tym celu stosujemy specyficzne podejście coachingowe. Na początku pokazujemy jak robić pewne rzeczy robiąc to wspólnie z wewnątrz organizacji. To nie tylko coaching, bardziej mentoring. Potem zamieniamy się miejscami – osoba w organizacji przejmuje stery, a my siedzimy z tyłu. Jeśli więc sprawy idą w złym kierunku możemy interweniować. Jeśli wszystko jest w porządku wycofujemy się i obserwujemy z linii bocznej. Osoby w organizacji wówczas przekazują wiedzą kolejnym osobom mając pełne wsparcie zdalne. Robimy to za pośrednictwem Slacka gdzie naprawdę doświadczeni konsultanci udzielają szybkiej informacji zwrotnej. Mamy też cykliczne wideo-rozmowy. Taki model: „odchodzimy, ale tak naprawdę ciągle z wami jesteśmy”. Nadal jesteśmy z formalnymi i nieformalnymi liderami, którzy napędzają tę zmianę. Rok później nadal śledzimy postęp i rozumiemy, co się dzieje. Jeśli czujemy, że organizacja naprawdę sama idzie naprzód, stale się poprawia i widzimy, jak rozszerza się definicja produktu, nie dlatego, że to my zapewniamy większą przejrzystość, ale dlatego, że sami zapewniają przejrzystość i z niej korzystają to jest moment, w którym myślę: „w porządku, tak, to jest to”. To jest naprawdę trwała zmiana, która się nie skończy, ponieważ Agile nigdy się nie kończy. Pierwsze zdanie Agile Manifesto to: „Odkrywanie lepszych sposobów…”, więc ta praca nie ma końca.

Jakie masz rady dla ludzi którzy zmagają się z próbą przeprowadzenia transformacji w swoich organizacjach?

Pierwsze byłoby: zacznij czytać książki związane z praktykami inżynieryjnymi. ProCognita współpracuje z Gojko Adzic; jego Specification by Example czy Impact Mapping to świetne techniki. Przejdź od biznesu do aspektów technicznych. Przeczytaj książkę „Your Code as a Crime Scene”. Nawet dla osób nietechnicznych to bardzo przydatna książka. Moim zdaniem to, czego najbardziej brakuje w dzisiejszych transformacjach Agile, to szacunek do ludzi przebywających na tzw Gembie, pracujących z, prawdziwym kodzie. Lepsze zrozumienie technik tworzenia oprogramowania i architektury to najlepsza inwestycja.

Miałem nadzieję, że wspomnisz o myśleniu systemowym.

Wykorzystałem myślenie systemowe, aby dojść do wniosku, że umiejętności techniczne to, to czego najbardziej brakuje . Myślenie systemowe zapewni im zrozumienie, w jaki sposób jest kompetencje techniczne powiązane są z ich sprawnością biznesową. Chodzi o ludzi, struktury i procesy.

Czy widzisz jakieś zmiany w podejściu do transformacji lub jak zmieniają się organizacje w ciągu ostatnich 10 lat?

Dziesięć lat temu było to bardziej podejście oddolne, a dziś każdy chce być Agile. Ale tak naprawdę nie rozumieją tej koncepcji. Tak powstaje “teatr” Agile – firmy które zastosowały terminologię Scrum, ale zdecydowanie nie stosują Scrum tego podejścia zgodnie z przeznaczeniem. Niektóre wdrożenia Scruma nazywam „czystą torturą zespołową”. Myślę, że to największa zmiana. Myślę też, że jest to wyzwanie, które będzie bardzo trudne do przetrwania w społeczności Scrum. Jak możemy zachować prawdziwe znaczenie Scruma, kiedy ludziebez doświadczania, którzy nie rozumieją podstaw Scruma zaczynają tworzyć te “teatralne wdrozenia”? Zasadniczo widzimy Scrum Mastera jako starego lidera zespołu lub sekretarkę w najgorszym przypadku i to wszystko. Mam nadzieję, że LeSS (Large-scale Scrum) będzie bardziej przypominał eXtreme Programming – nie jest tak popularny jak inne frameworki, ale nadal istnieje i odnosi sukcesy, bo daje prawdziwe efekty, że będzie zestawem praktyk upraszczających organizację a nie metodą skalowania.