Jak efektywnie skalować metodyki zwinne?

W osiemnastym odcinku podcastu „Zwinne organizacje” Paweł Tomkiel i Artur Kożuch z rozmawiają o skalowaniu metod zwinnych. O tym, czym jest ich skalowanie, o metodykach i frameworkach oraz o tym, kto w organizacji powinien być inicjatorem rozmów na ten temat.

Transkrypcja podcastu:

Paweł: Podejście zwinne zazwyczaj jest używane na poziomie pojedynczego zespołu. Dzisiaj porozmawiamy o tym, jak metody skalowania pozwalają zarządzić zależnościami pomiędzy wieloma zespołami.

Paweł: Cześć, nazywam się Paweł Tomkiel.

Artur: I Artur Kozuch.

Paweł: Jesteśmy konsultantami w Delloite Digital. W dzisiejszym odcinku razem z Arturem będziemy chcieli porozmawiać chyba głównie o metodykach, o frameworkach do wyskalowania podejścia zwinnego na całą organizację. I Artur, gdybyśmy mogli od tego zacząć, czym właściwie jest skalowanie metod zwinnych?

Artur: W przewodniku po najpopularniejszej zwinnej metodzie możemy znaleźć taką informację, że Scrum jest lekki, łatwy do zrozumienia i trudny do opanowania. Z moich obserwacji wynika, że największe komplikacje pojawiają się wtedy, gdy wychodzimy poza te ramy opisane w Scrum Guide. Przykładem może być, kiedy kilka zespołów pracuje nad stworzeniem jednego produktu i pojawiają się pomiędzy nimi jakieś zależności i one mogą być różnej natury, na przykład technologicznej. I gdybym mógł posłużyć się jakimś przykładem, to takie zależności technologiczne to na przykład praca nad powiązanymi funkcjonalnościami takiego większego, złożonego produktu.

Paweł: Dokładnie.

Artur: Korzystanie z jednej bazy danych czy wspólnych środowisk deweloperskich. Oczywiście typów zależności możemy wyróżnić znacznie więcej. Bardzo często w różnych organizacjach spotykamy się z takimi zależnościami zasobowymi, że nasz zespół produktowy potrzebuje kontaktować się z różnego rodzaju ekspertami zewnętrznymi, na przykład z prawnikami, ekspertami od compliance, RODO, którzy nie stanowią na stałe części zespołu produktowego.

Paweł: Czasem to są graficy, czasem to jest user experience.

Artur: Dla mnie to są bardziej takie zależności kompetencyjne, gdzie nie mamy wystarczającej liczby na przykład grafików albo projektantów UX, UI, żeby oni po prostu byli w każdym zespole. I my te kompetencje eksperckie musimy wtedy po prostu dzielić pomiędzy różne zespoły, co naturalnie też jest jakiegoś rodzaju zależnością. I taki ostatni rodzaj zależności, który przychodzi mi teraz na myśl, to są zależności biznesowe, które przekładają się bezpośrednio na priorytetyzację funkcjonalności w backlogach poszczególnych zespołów. I wracając do samego Twojego pytania, to tak jak miałbym powiedzieć jednym zdaniem, skalowanie metod zwinnych pozwala na efektywne zarządzanie tymi przytoczonymi przeze mnie przed chwilą zależnościami i tym samym pozwala też minimalizować ryzyko podczas budowy złożonych produktów.

Paweł: No to powiedziałeś w takim razie, czym jest skalowanie metod zwinnych, a kto w organizacji i jakie organizacje powinny w ogóle myśleć o skalowaniu metod zwinnych, kto powinien być inicjatorem takich rozmów o tym, czy już musimy się skalować?

Artur: Bardzo dobre pytanie. Jeżeli chodzi o rolę organizacyjną lub jednostkę, która zazwyczaj inicjuje podjęcie w ogóle tematu o frameworku do skalowania, to moim zdaniem to zależy od sytuacji, w której organizacja aktualnie się znajduje. Z mojego doświadczenia wynika, że organizacje, które przechodzą przez transformację cyfrową, mają ten element układanki już przemyślany na etapie strategii. W przypadku takich dużych, międzynarodowych jednostek to inicjatywa często wychodzi ze strony centrali, która przygotowuje taki zestaw rekomendacji w globalnym Agile Center of Excellence i dzieli się nim z krajami członkowskimi. Dla organizacji działających lokalnie inicjatywa może wychodzić równie dobrze po stronie zespołów deweloperskich, Scrum Mastera, Agile Coacha, lokalnego Center of Excellence, jak i PMO.

Paweł: Czyli albo top down, albo buttom up, czyli z różnych części organizacji może wychodzić ta inicjatywa do samego wyskalowania, tak?

Artur: Dokładnie, przynajmniej to są moje obserwacje. Wydaje mi się, że tutaj ile byśmy zebrali ekspertów, Agile Coachów, osób, które mają przyjemność poznawać różne organizacje, to ta opinia mogłaby być inna.

Paweł: No dobra, to teraz słuchaj, gdybyśmy sobie wyobrazili taką organizację, w której powiedzmy, że dwa zespoły deweloperskie działają zwinnie, mają mnóstwo tych zależności, zależności technologiczne są chyba największym blokerem z organizacjach, które wytwarzają w jakikolwiek sposób oprogramowanie, to kiedy taka organizacja powinna się zainteresować jakby tematem skalowania zwinności? Czy wtedy, kiedy ktoś z deweloperów powie, czy właśnie, tak jak powiedziałeś, że ze strategii powinno już wynikać, że chcemy mieć przeskalowany model zwinności, jakby jak taka organizacja, która działa teraz i funkcjonuje w miarę dobrze, jak ma podjąć decyzję, że to już jest czas, żeby zmienić model funkcjonowania, skalować metodyki zwinne?

Artur: Spotkałem się już kilkukrotnie z taką sytuacją, kiedy liczba zależności pomiędzy zespołami była na tyle niska, że zespoły były w stanie poradzić sobie samodzielnie i nie stosowały, a przynajmniej z nazwy nie stosowały żadnego takiego konkretnego frameworka. Często Scrum Masterzy są w stanie zaproponować takie rozwiązanie, które stanowi jedynie element całej układanki, ale może się sprawdzić w tej określonej sytuacji. Prowadzenie frameworka w całości jest taką dużą inwestycją, zazwyczaj trzeba powołać dodatkowe role, zorganizować spotkania, które pochłaniają czas wielu osób. Pojawia nam się koszt alternatywny w postaci godzin, które moglibyśmy poświęcić na pisanie linii kodu, tworzenie makiet, zarządzanie backlogiem czy rozmów z klientami końcowymi naszego produktu. Moim zdaniem o frameworku do skalowania powinniśmy myśleć przede wszystkim w trzech przypadkach. Po pierwsze, gdy samoorganizujące się zespoły nie mają możliwości albo nie są w stanie się dogadać między sobą i potrzebują takiej warstwy governance’owej, która będzie ponad nimi.

Paweł: Okej, czyli kiedy liczba zależności już przekracza możliwości samego zespołu do ich ogarnięcia, tak?

Artur: Można tak powiedzieć.

Paweł: Drugi powód?

Artur: Gdy realizujemy program, który składa się z wielu wzajemnie powiązanych inicjatyw i od samego początku wiadomo, że te zależności będą. Struktury organizacyjne zazwyczaj składają się, na przykład, z business unitów, tribe’ów, co przyjęło się z tego modelu Spotify’owego, ze strumieni wartości, ta nomenklatura bardzo różni się pomiędzy organizacjami. I zauważyłem, że pojawiają się też takie zależności na poziomie na przykład całego tribe’u. Jeżeli nie wiecie, czym jest tribe, to można to porównać do departamentów w organizacji. To jest taka dosyć duża jednostka organizacyjna, która zazwyczaj ma powiedzmy około stu osób, mają swojego lidera i lidera technicznego, i mają określone cele do zrealizowania, i określoną personę. To jest taki byt w organizacji. W tym modelu bardzo często, przynajmniej ja to obserwuję, pomiędzy tribe’ami pojawiają się zależności na poziomie zarówno projektów, jak i budowy produktów, oraz realizacji takich dużych, złożonych inicjatyw. I tymi zależnościami również w jakiś sposób trzeba zarządzić. I po trzecie, obserwuję też często w organizacjach, że istnieje taka potrzeba kontroli i planowania budżetu, planowania tego, co będzie w przyszłości. Przyjęcie frameworku do skalowania albo zaprojektowanie tego, który będzie, jak to się ładnie mówi po angielsku, taylor fit dla danej organizacji, pozwala lepiej planować funkcjonalności, tworzyć potencjalne mapy drogowe dla zespołów. Mamy taką większą przewidywalność, która zazwyczaj w korporacjach jest po prostu oczekiwana od zespołów zwinnych.

Paweł: Tak, czyli tutaj dochodzimy do tego głównego konfliktu, gdzie Scrum opiera się na doświadczeniu, żeby przewidywać troszeczkę przyszłość, ale jakby to przewidywanie przyszłości każdy wie, że nie zawsze nam wychodzi jako ludziom.

Artur: No oczywiście, problemy zaczynają się tam, gdzie mamy organizację z budżetowaniem rocznym i ona musi sobie po prostu w budżecie przewidzieć realizację tych wszystkich inicjatyw.

Paweł: Temat planowania rocznego poruszaliśmy w jednym z poprzednich odcinków, również tam odsyłam, „Zwinne organizacje” na stronie deloitte.com. Ale chyba jakby nie zniwelujemy tej konieczności połączenia budżetowania rocznego, bo mamy inwestorów, bo mamy właścicieli firm, którzy chcą znać plan, więc ta zwinność jest zazwyczaj ograniczona. Im większa organizacja, tym więcej będzie tego narzutu niezwinnego, ale jest on po prostu konieczny. Większe organizacje nie są w stanie funkcjonować tak zwinnie, jak małe startupy. No dobra, Artur, a gdybyśmy teraz mieli przejść do konkretów, jakie frameworki skalowania są teraz na rynku, jakie są używane przez organizacje, jakie są najpopularniejsze, co możesz o tym powiedzieć?

Artur: Oficjalne i najpopularniejsze metody do praktykowania Agile na szeroką skalę to SAFe, LeSS oraz Nexus.

Paweł: To tak jak wymieniłeś te frameworki, czym się od siebie różnią, który służy do czego i kiedy organizacja powinna wybrać SAFe’a, kiedy LeSS’a, kiedy Nexusa?

Artur: Bardzo dobre i bardzo trudne pytanie, bo odpowiedź na nie nie jest jednoznaczna.

Paweł: SAFe wydaje się być najpopularniejszy, jeżeli chodzi o rynek finansowy, na którym jako Deloitte najwięcej działamy.

Artur: Zgadzam się, z tego co obserwuję, najwięcej organizacji wykorzystuje częściowo, albo stara się inspirować SAFem, jeżeli chodzi o skalowanie metod zwinnych, tylko SAFe też jest podejściem najtrudniejszym, najbardziej złożonym i wymagającym najwięcej inwestycji. Wynika to z faktu, że sam poziom skomplikowania tego frameworka jest duży, ciężko jest go komuś wytłumaczyć. Szkolenie, takie bardzo podstawowe jest drogie, trwa długo, wprowadza bardzo dużo nowych ról w organizacji, dużo dodatkowych spotkań. I pojawia się nam też ten koszt alternatywny, o którym rozmawialiśmy wcześniej. I wydaje mi się, że niektóre organizacje, które porywają się na tego SAFe-a nie potrzebują go tak naprawdę i dałyby sobie radę z jakąś dużo prostszą metodą do skalowania metodyk zwinnych.

Paweł: W rozmowie z Jurgenem Appelo właśnie mówiliśmy o tym, że SAFe może być właściwy dla organizacji, ale na pewno nie jest taki, który każda organizacja może wziąć i wdrożyć. Jeżeli dobrze kojarzę SAFe, gdybyśmy chcieli streścić go w książce, to ta książka miałaby kilkaset stron, żeby wyjaśnić same zasady tego frameworka.

Artur: Ja tutaj naszym słuchaczom bardzo polecam wejść na stronę SAFe’a, tam jest taki klikalny obrazek, gdzie można zobaczyć każdy element i przeczytać jego opis. Na pewno SAFe ma w sobie bardzo dużo przemyślanych rozwiązań, różnego rodzaju technik, pryncypiów, które są dobre i które możemy spróbować wykorzystać w swojej organizacji i stworzyć coś pod nasze potrzeby.

Paweł: Czyli wyciągnąć jakieś takie pojedyncze elementy.

Artur: Nie chcę jednoznacznie rekomendować, że wyciąganie elementów z różnego rodzaju frameworków przyniesie nam oczekiwane korzyści. Zazwyczaj osoby, które zajmują się wdrażaniem danego frameworka, specjalizują się w nim, są szkoleniowcami, nie rekomendują brania wybranych części. To tak, jakbyśmy wzięli sobie jedynie wybrane elementy ze Scruma, które nam odpowiadają. I od lat się mówi o tym, że po prostu Scrum, który nie jest aplikowany w całości, nie działa tak, jak to jest oczekiwane.

Paweł: Tak, on już jest tak lekki, że bardziej się go nie da odchudzić.

Artur: Gdybyśmy jeszcze mogli wrócić na chwilę do SAFe’a. Wydaje mi się, że jest ciekawą propozycją dla organizacji, które mają taką dużą potrzebę kontroli, chcą mieć dużą przejrzystość tego, co jest wytwarzane w poszczególnych zespołach i chcą to widzieć zdecydowanie naprzód. To jest coś, czym według mnie różni się SAFe od LeSS’a. W LeSSie jest tak, że to podejście jest, według mnie oczywiście, najbliżej Scruma. Wszystkie ceremonie, eventy czy zdarzenia, jakkolwiek chcemy to nazywać, które są dodane do LeSS’a, są utrzymane w tych duchu zwinnym. W SAFe jest to na pewno różnie. I jeszcze taka jedna różnica, która przychodzi mi do głowy i wydaje mi się, że ona może być ciekawa zarówno dla Ciebie, jak i dla naszych słuchaczy, to to, że SAFe wymusza organizację takiego wydarzenia, które nazywa się PI Planning. To jest najciekawszy element tego SAFe’a, o którym najwięcej się rozmawia.  Jest to takie spotkanie, na którym w jednym miejscu zbieramy wszystkie osoby zaangażowane w budowę danego produktu. I tych osób może być naprawdę bardzo dużo. Zbieramy razem ze sobą produktowców, product ownerów, Scrum Masterów, deweloperów od najróżniejszych systemów i staramy się zaplanować tą pracę naprzód. I na czym polega trudność? Po pierwsze nie wiem jak wam, ale mi często zdarza się być na spotkaniach, gdzie ciężko jest utrzymać jakiś timing i agendę, nawet w ciągu piętnastu, dwudziestu minut, a PI Planning trwa dwa dni. Mamy tam bardzo dużo zespołów, bardzo dużo oczekiwań, interesariuszy i utrzymanie takiej struktury tego spotkania, żeby ono było efektywne i skończyło się pożądanym przez nas rezultatem, to jest nie lada wyzwanie i według mnie trzeba mieć w tym dużo doświadczenia, takiego sprytu, dobrych umiejętności fascytilacyjnych też, żeby to spotkanie przeprowadzić.

Paweł: To byłby ten element SAFe’a, który w sumie jest bardzo zwinny, bo polega na tym, żeby zebrać ludzi i kazać im się ze sobą dogadywać, nie? To jest ten element ludzki.

Artur: To jest bardzo ciekawe, że podczas PI Planningu zdarza się, że na jednej sali nagle spotykają się osoby, które nigdy wcześniej razem nie rozmawiały twarzą w twarz, tylko znają się z różnego rodzaju Teams’ów, Skype’ów, wideokonferencji i teraz, zwłaszcza podczas doby COVID-owej, ten problem może narastać i wraz z rosnącą popularnością pracy zdalnej ten PI Planning może być jeszcze taką ciekawszą okazją do tego, żeby poznać się po prostu na żywo.

Paweł: Jeżeli to nadal będzie legalne. Powiedziałeś bardzo ciekawą rzecz. Powiedziałeś, że SAFe jest dla tych organizacji, które chcą mieć kontrolę, chcą mieć widoczność planów naprzód. To czym w takim razie to się różni właśnie od LeSS’a i Nexusa? Czy to oznacza, że tam tracimy kontrolę, używając tych lżejszych frameworków?

Artur: Nie, po prostu w SAFe mamy więcej różnego rodzaju artefaktów, które są prowadzone w taki sposób top down. Możemy znać je nawet z różnych podejść kaskadowych i oczywiście nie mówię, że to złe, tylko ten SAFe bardziej pasuje do określonej kultury organizacyjnej, która nie skupia się tak bardzo na tym, żeby spłaszczać strukturę, żeby dawać dużo empowermentu, tylko bardziej skupia się na warstwie zarządczej, żeby wszystko działało jak taki trybik w dużej machinie.

Paweł: Czyli na przykład właśnie branża finansowa, tak? To byłby ten kierunek?

Artur: Tak, zdecydowanie.

Paweł: Okej, a jak wybrać ten właściwy framework i dla kogo byłby lepszy LeSS, Nexus? Czy jesteśmy w stanie w ogóle powiedzieć, jak wybrać ten właściwy framework?

Artur: Wydaje mi się, że to przede wszystkim zależy od naszych oczekiwań. Jakie mamy potrzeby? Skąd te potrzeby wychodzą w organizacji? Dla kogo robimy ten framework? Czy ta potrzeba wychodzi od PMO, od zarządu, może od CIO, który po prostu chce mieć większą przewidywalność tego, co zostanie dostarczone i kiedy, więc na pewno tutaj bym się przede wszystkim pochylił nad tym pytaniem, dlaczego robimy te frameworki i czy na pewno chcemy inwestować tyle pieniędzy? I jeżeli tak, to rzeczywiście, jaki ma być tego efekt końcowy?  

Paweł: Okej, czyli to jest trochę to, co zawsze powtarza Jon Smart, że nie stajemy się zwinni dla samej zwinności, tylko na samym początku jest cel biznesowy, który możemy osiągnąć dzięki zwinności, tak?

Artur: Powinniśmy pamiętać o tym, że te metodyki zwinne to jest jedynie jakieś narzędzie, które pozwala nam osiągnąć te cele biznesowe, o których powiedziałeś. I podobnie powinniśmy podchodzić do skalowania. Nie powinniśmy wprowadzać tylko dlatego, że ładnie wyglądają czy że są modne, że przeczytaliśmy ciekawe artykuły w Internecie albo obejrzeliśmy nagrania z wideokonferencji, tylko one powinny rozwiązywać nasze konkretne problemy, które zwłaszcza znajdują się na poziomie zespołów deweloperskich.

Paweł: Tak, tutaj odsyłam jeszcze do jednego z naszych poprzednich odcinków, w którym omawialiśmy, kiedy podejście zwinne po prostu nie zadziała. To, Artur, jak możemy podsumować to, o czym dzisiaj sobie powiedzieliśmy?

Artur: Żeby podsumować naszą rozmowę w kilku zdaniach, metody skalowania Agile w dużych organizacjach mogą przynieść naprawdę mierzalne korzyści, tylko trzeba bardzo ostrożnie podchodzić do ich aplikacji. Musimy brać pod uwagę, że to jest pewnego rodzaju zmiana, która wiąże się oczywiście z aspektami zarządzania zmianą. Jest to też inwestycja, która ponosi ze sobą koszty, które są przeznaczane na szkolenia, na treningi. Jeżeli to jest SAFe, to sama organizacja PI Planningu, o którym przed chwilą rozmawialiśmy, jest niezwykle droga, ponieważ wymaga spotkania w jednym miejscu bardzo wielu osób, często wiąże się to z opłatami za hotele, wynajęcie sali, nagłośnienie, za sale do spotkań indywidualnych zespołów. Teraz oczywiście te PI Planningi są robione zdalnie w dobie COVID-owej, zobaczymy, co będzie w przyszłości. Ale nawet sam czas tych pracowników, którzy muszą poświęcić na tak duże spotkanie, jest po prostu duży. I musimy wiedzieć, co chcemy osiągnąć tymi metodami do skalowania i po co je tak naprawdę robimy. Jeżeli widzisz w swojej organizacji potrzebę, żeby zastosować wybraną metodę do skalowania Agile, nie wiesz którą, nie do końca rozumiesz jeszcze, czym one się różnią, ale widzisz, że bez nich dalej sobie nie poradzicie i potrzeba wam takiej warstwy zarządczej, to śmiało możecie się do nas odezwać. My z chęcią oczywiście pomożemy, możemy też podesłać jakieś linki, materiały, także nie wahajcie się z nami kontaktować.

Paweł: Tak, zapraszamy też na naszego bloga „Zwinne organizacje” na stronie deloitte.com. Odsyłam też do kilku poprzednich odcinków szczególnie do rozmowy z Jurgenem Appelo, do rozmów o tym, kiedy podejście zwinne jest wartościowe, a kiedy niekoniecznie. Jesteśmy ciekawi, co myślicie o tym odcinku. Dajcie nam znać, co byście chcieli jeszcze rozwinąć w kolejnych odcinkach. I do usłyszenia.

Artur: Do usłyszenie. Dziękuję bardzo, Paweł.