Ciekawe

Kolejne porównanie agile vs waterfall. Tym razem z przymróżeniem oka.

Temat wałkowany był już wiele razy, na różne sposoby. Myślę jednak, że warto poświęcić cztery minuty z haczykiem na obejrzenie kolejnego filmiku z tej kategorii, w którym swoimi spostrzeżeniami dzieli się Gary Straughan. Miło się to ogląda. Autor wie, czym jest opowiadanie historii, a jego porównanie realizacji projektu do znanej szkolnej zabawy jest czymś świeżym i na swój sposób uroczym.

Link do filmiku “What is Agile? Agile Explained… with a PENCIL!“:

Gary porusza ten aspekt zwinności w realizacji projektów, który mówi o dochodzeniu do celu małymi krokami. Kolejne iteracje, mimo iż niewielkie, dostarczają już pewną wartość, a jednocześnie pozostawiają przestrzeń na szybkie korekty i adaptację. Oczywiście, że jest to ogromne uproszczenie i po raz kolejny próbuje się uczynić z waterfalla jakąś bezsensowną metodę dla bezmyślnych zombie, którzy nie potrafią wydzielić z dużego projektu używalnych produktów cząstkowych, etapów, czy prototypów, przynoszących wartość dla zamawiającego wcześniej niż z końcem projektu. Oczywiście, że jest jeszcze dużo możliwych scenariuszy między realizacją małymi iteracjami, a jedną wielką sekwencją kończącą się pojedynczym, obszernym wdrożeniem. Nie mniej jednak filmik jest sympatyczny, a porównanie obrazowe. Do różnych ludzi trafiają różne komunikaty i może dzięki temu porównaniu ideę zwinności chwyć ktoś, do kogo nie trafiają inne metafory.

Co porównanie agile vs waterfall ma wspólnego ze skalowaniem agile?

SAFe mówi o iteracyjności w wielu miejscach, a najbardziej wprost i obrazowo w Pryncypium 4: Buduj przyrostowo w ramach krótkich zintegrowanych cyklów uczenia się.

Zapraszamy na szkolenie

Szkolenie Leading SAFe®

W samej idei budowania rozwiązań przyrostowo SAFe nie odkrywa niczego nowego, zwraca natomiast uwagę na aspekt integracji przyrostów dostarczanych przez poszczególne zespoły, na wspólną, całościową ocenę efektów prac oraz wspólnym wyciąganiu wniosków i wdrażaniu korekt .

SAFe jest duży i złożony, przez co przez wielu uważany za mało zwinny. Niesłusznie.

Przeczytałem artykuł, z którym nie potrafię się zgodzić… i wtedy zaczęło ;]

Chodzi o ten tekst, w którym autor, ewidentnie preferujący LeSS w kontekście frameworków skalujących agile, wygłasza parę opinii, które stoją mocno w sprzeczności z moimi obserwacjami odnośnie skalowania agile:

https://procognita.pl/post/safe-moze-i-bezpiecznie-ale-malo-agile-136/

Niestety nie uda się już przeczytać całości dialogu, bo autor usunął komentarze (mój i swój). No cóż, jego blog, może robić z nim co chce, co jednak dziwi mnie nieco, bo dyskusja odbywała się w kulturalnym tonie, a autor nawet podziękował za mój komentarz. W powody usunięcia nie wnikam, ale szkoda by mi było jakby ta dyskusja umknęła, bo zawiera trochę informacji, które mogą się przydać tym, którzy poszukują rozwiązań. Dlatego wrzucam ją tutaj. Skąd przytaczane cytaty, skoro komentarze zostały usunięte? Pisząc swój komentarz zapisałem jednak kiedyś kopię roboczą na dysku, a dodatkowo napisałem o tej dyskusji artykuł na LinkedIn.

Mój pierwszy komentarz do artykułu

Szanowny Autorze,

Pisanie o Scaled Agile Framework w następujący sposób:

„SAFe skupia się na zdefiniowaniu procesów i struktury organizacji nie biorąc pod uwagę ani powyższych trzech wymagań odnośnie bycia Agile, ani najważniejszego czynnika w tworzeniu oprogramowania, czyli ludzi.”

świadczy niestety o nieznajomości tego framework’a, albo świadomym wprowadzaniu czytelników w błąd. Bardzo ważną cechą SAFe’a jest właśnie to, że oprócz procesów, ról i narzędzi, ogromną wagę przykłada on do nastawienia Lean i Agile, co jest odzwierciedlone na bardzo ogólnym poziomie w Core Values http://www.scaledagileframework.com/safe-core-values/ nieco dokładniej w Lean-Agile Mindset http://www.scaledagileframework.com/lean-agile-mindset, a już bardzo szczegółowo w SAFe Lean-Agile Principles http://www.scaledagileframework.com/safe-lean-agile-principles/. Jest tam mowa o podejściu Agile,  Lean i bardzo dużo o ludziach tworzących produkty (patrz np. pryncypia: 8. Unlock the intrinsic motivation of knowledge workers oraz 9. Decentralize decision-making). Kultura Lean i Agile to siła napędowa SAFe’a, który adresowany jest całym organizacjom, zatem w założeniu musi bazować na powszechnym rozumieniu i stosowaniu tych zasad. Więcej o roli liderów można przeczytać w części Lea-Agile Leaders (http://www.scaledagileframework.com/lean-agile-leaders/).
To jak ważne w SAFe jest całe wspomniane przeze mnie zaplecze myślowe widać między innymi w akredytowanych programach szkoleniowych – niezależnie od tego czy szkolenie dedykowane jest liderom, Scrum Masterom, Product Managerom/Ownerom czy zespołom deweloperskim, Lean-Agile Mindset i Lean-Agile Principles stanowią znaczną ich część.

Zainteresowanych SAFe’m i skalowaniem Agile zapraszam do zapoznania się z materiałami źródłowymi i wyrobienie sobie własnego zdania.

Ten komentarz został opublikowany. Autor odniósł się do niego. Mój kolejny komentarz, ten poniższy, już nie nie został opublikowany, a dwa poprzednie usunięte, jak już wspomniałem.

Mój drugi komentarz do artykułu

Tomek,

Daleki jestem od zarzucenia komukolwiek nieznajomości Agile, ale jako praktyk SAFe (Release Train Engineer, osoba mocno zaangażowana we wdrażanie SAFe oraz trener) czuję się całkiem komfortowo w prostowaniu mylnych wyobrażeń o tym frameworku, nie krytykując przy tym innych podejść. Kiedy wyrażam opinie, to nie powielam opinii innych (żeby była jasność, nie zarzucam tego Tobie, piszę o sobie) tylko mówię o rzeczach, których doświadczyłem i mam co do nich osobiste zdanie. SAFe nie jest taką kobyłą jaką się wydaje na pierwszy rzut oka (choć nawet ten pierwszy rzut oka nie jest już taki straszny po tym jak na http://www.scaledagileframework.com/ można wyświetlić jeden z 4 jego wariantów, a nie tylko wersję full lub prawie full, jak to było wcześniej). Chciałbym parę mitów odczarować.

Faktem jest, że SAFe jest dużo obszerniejszy niż np. Scrum Guide, ale co się dziwić. To nie jest zbiór wytycznych odnośnie zarządzania zespołem, kilkoma zespołami, czy małym start-upem, ale dużymi rozwiązaniami, programami zwinnymi, całymi liniami produktowymi, a nawet portfelami programów. Nie doradza jak zarządzać małą ilością deweloperów i Product Ownerów, tylko małą armią ludzi tworzących razem produkty. Scrum Guide jest krótki i koncentruje się na atrakcyjnie brzmiących mechanizmach, szybko przyciąga uwagę, ale pozostawia ogromne pole do interpretacji, a nawet nadinterpretacji. Jako doświadczony trener na pewno nie raz spotkałeś się z tym, jak szybko ludzie ulegają mylnemu wyobrażeniu o swojej znajomości Scruma. Sami autorzy przyznają, że Scrum jest mały i lekki, ale cholernie trudny w prawdziwym zrozumieniu i implementacji. Pokorny człowiek doczyta, dopyta, podpatrzy ,ale sporo z nich uzna, że po przeczytaniu łatwo przyswajalnych parunastu stron wie na tyle, że może go używać. To powoduje wiele szkód. Ludzie potrafią takie bzdury wymyślać o Scrumie, będąc jednocześnie pewnymi swoich racji, że ręce odpadają. SAFe jest obszerniejszy w swoich core’owych materiałach, ale dzięki temu pozostawia mniej niedomówień. Daje więcej przykładów, głębiej rozkminia o wiele więcej mechanizmów niż Scrum, XP, czy inne nie-skalujące frameworki. Musi to robić, bo i nie wdrażają go pojedyncze zespoły, ale całe organizacje. Nie uważam, żeby przez to był cięższy, jest naprawdę lekki, ale w odniesieniu do dużo większych wyzwań.

Zapewniam Cię, że SAFe, to coś więcej niż słownictwo, wdrażam go na co dzień i widzę, które mechanizmy działają a nie są tylko pustymi hasłami.

Pozwól, że odniosę się do Twoich przykładów:

“- Metodyki Agile nazywane były lekkimi, żeby je odróżnić od ciężkich procesów RUP, CMM czy podejścia kaskadowego. SAFe może być lekki dla naprawdę dużych i skostniałych organizacji, natomiast dla wielu firm będzie zwiększał nakład procesowy i wzmacniał dysfunkcjonalne rozwiązania.”

No oczywiście, że tak. Skalujemy agile, kiedy mamy do czynienia z większej skali przedsięwzięciami, dla 2, 3, 4 zespołów to przerost formy nad treścią, ale dla zespołu zespołów składającego się ze 120 deweloperów, to praktycznie niezbędne minimum do ogarnięcia takiej skali złożoności. Zresztą to nie tylko o skalowanie potencjału deweloperskiego chodzi, ale także, a może przede wszystkim, o skalę zaangażowania jednostek i poziomów biznesowych. Dla IT, abstrahując od organizacji dysfunkcyjnych, Scrum to czasem naturalne środowisko, dla reszty organizacji, to wciąż najczęściej czarna magia. Scrum Guide nie mówi o tym jak wdrożyć kulturę agile w firmie, tylko jak zarządzać relatywnie małą ilością deweloperów.

Zapraszamy na szkolenie

Szkolenia SAFe

“- Lean bazuje na obniżeniu ilości pracy w toku (WIP). SAFe ma sporą ilość kolejek w postaci rożnych Rejestrów (Backlogów).”

Kanbany i backlogi znajdują się na każdym poziomie zarządzania SAFe, po jednym na poziom, żeby lepiej zarządzać przepływem wartości biznesowej i uzyskać transparentność planów. Zestawię to ze Scrumem, nie dlatego że mam coś do tej metody (wręcz przeciwnie), tylko dlatego, że jest on najpopularniejszym podejściem agile’owym. Scrum Guide bardzo mało mówi o tym co się dzieje z projektami i produktami zanim trafią do backlogów zespołów, więc to co się dzieje poza zespołami to czasem czarna magia, czasem partyzantka, czasem nieporozumienie, a najczęściej waterfall (do którego de facto też nic nie mam, a wręcz przeciwnie). SAFe mówi o zarządzaniu rozwojem produktów i całymi strumieniami wartości, wdraża agile i lean nie tam gdzie jest najłatwiej tylko tam gdzie najtrudniej, ale też tam gdzie wartość wdrożenia jest największa. Kanbany i backlogi na poziomie programu, czy portfela nie zwiększają pracy w toku, tylko uwidaczniają ją i pozwalają nią zarządzać, żeby zagadnienia nie wpadały do backlogów zespołów nie wiadomo skąd, tylko żeby od samego pomysłu były w organizacji widoczne i metodycznie przygotowywane. SAFe wyraźnie mówi o zmniejszaniu pracy w toku i redukcji zakresów przyrostów http://www.scaledagileframework.com/visualize-and-limit-wip-reduce-batch-sizes-and-manage-queue-lengths/ i tłumaczy jak to osiągnąć.

“- W Scrumie Product Owner jest odpowiedzialny za produkt widziany oczami klienta. Product Owner w SAFe jest najczęściej odpowiedzialny za komponent.”

Racja, ale na Produkt Ownerze świat się nie kończy. Ile tytułowanych Product Ownerów ma realny wpływ w swoich organizacjach i projektach na rozwój produktu? SAFe sięga wyżej, do wszystkich ludzi mających wpływ na kreowanie produktu, od wizji i strategii poprzez komponenty, do funkcjonalności i historyjek użytkownika. Rynek, segment, strategia, pricing, planowanie releasów, zarządzanie kluczowymi interesariuszami, zarządzania liniami biznesowymi… w dużych organizacjach to dużo za dużo dla jednego, paru czy nawet parunastu Produkt Ownerów funkcjonujących w płaskiej strukturze projektowej. Dlatego oprócz Product Ownera, jest Product Management, Solution Management, Epic Owners każdy zarządza produktem koncentrując się na swoim poziomie, ale jednocześnie ściśle ze sobą współpracują… dużo tego, trudno, lepiej dokładniej odwzorować rzeczywistość niż łudzić się że nazwanie kogoś Product Ownerem da mu właściwe przełożenia na kreowanie wartości biznesowej w organizacji.

Można z SAFem polemizować, sam krytykuję niektóre jego mechanizmy i niektóre rzeczy wdrażam po swojemu, nie wszędzie jest wdrażalny jeden do jednego, ale autorom nie można odmówić dokładnego przemyślenia i opisania podejścia zwinnego dla całych organizacji. Nie trywializują istotnych obszarów, nie pomijają trudnych aspektów.

Czy to czyni SAFe’a ciężkim i mało zwinnym? Dla zespołu, dwóch zespołów tak, dla tych co go wdrażali w dużych przedsięwzięciach i dużych organizacjach http://www.scaledagileframework.com/case-studies/ to zwinność zaadoptowana, by mierzyć się z dużymi wyzwaniami. Dużych przedsięwzięć nie zde-skalujesz, praca jest pracą i trzeba ją wykonać, ale możesz starać się wyskalować mechanizmy, które sprawdziły Ci się w małej skali.

Osobiście bardziej od skalowania wolę de-skalowanie przez zmniejszanie ilości sztucznych struktur, ról koordynacyjnych i zależności, a w zamian za to ciągłe dostarczanie produktu.

Natomiast w pełni się z Tobą zgadzam, że niezależnie od opinii autorytetów, warto czytać i mieć własne zdanie.

Może zastanawiasz się Czytelniku skąd u mnie taka determinacja do tej polemiki? W internecie łatwo jest wyrażać opinie, łatwo coś lub kogoś skrytykować, nawet coś o czym się bardziej słyszało, niż widziało to na własne oczy, a ludzie czytają i często wierzą, na słowo, przez co może zbyt szybko zniechęcą sią do rozwiązania, które może pomóc im w codziennej pracy.