Opublikowano: 05.02.2014

SAFe, może i bezpiecznie, ale mało Agile

SAFe, może i bezpiecznie, ale mało Agile

Scrum określa zasady pracy dla jednego, kilkuosobowego zespołu deweloperskiego. Jednak coraz więcej projektów Agile jest prowadzonych przez kilkadziesiąt, kilkaset, a nawet kilka tysięcy ludzi. Ponieważ reguły komunikacji w Scrumie nie pozwalają nam skalować zespołów w nieskończoność (czyli upychać w nich więcej i więcej ludzi), pojawia się potrzeba skalowania poprzez wprowadzenie wielu zespołów. Dlatego firmy poszukują rozwiązań pozwalających na komunikacje, zarządzanie i efektywne wprowadzenie zmian w takim środowisku. Ostatnio coraz więcej szumu robi się dookoła Scaled Agile Framework albo SAFe. Zacząłem nawet dostawać pytania dotyczące wyłącznie tego frameworku. Czyli nawet nie „chcemy skalować swoją implementację Agile” a „chcemy SAFe”. Była więc najwyższa pora aby zasięgnąć języka i dowiedzieć się coś więcej na ten temat.

Skalowanie Zwinności

Zanim jednak popatrzymy na SAFe, ustalmy co to znaczy, że framework jest Agile. Dla mnie wymaga to posiadania trzech cech. Po pierwsze, musi opierać się na wartościach i zasadach opisanych w Manifeście Agile. Po drugie, musi być zależny od kontekstu organizacji. Po trzecie wreszcie, musi pozwalać na ciągłe doskonalenie.

Pierwszy wymóg gwarantuje, że wprowadzone rozwiązanie będzie się skupiało na tym, co w tworzeniu oprogramowania najważniejsze, czyli częstym dodawaniem wartości dla klienta. Uzyskamy to poprzez koncentrację na czterech wartościach i dwunastu zasadach opisanych w manifeście. Tym samym położymy nacisk na uczestnikach projektu i zapewnieniu komunikacji między nimi oraz umożliwieniu proaktywnego dostosowywania produktu i procesów do zmieniającej się sytuacji. Inaczej mówiąc Agile, niezależnie od skali, oznacza sposób myślenia, a nie zestaw praktyk. Czyli „jestem Agile”, a nie „robię Agile”.

Drugi wymóg zaręcza, że stosowane rozwiązanie będzie dopasowane do warunków konkretnej firmy. Inne oczekiwania ma przecież instytucja finansowa integrująca różne produkty (np. banki i firmy ubezpieczeniowe), inne koncern medyczny podlegający różnym normom bezpieczeństwa, inny telekom korzystający z zaawansowanych technologii, inny wreszcie firma tworząca głównie rozwiązania webowe. Każda z nich ma inne potrzeby i inne trudności. To co w jednym środowisku nie stanowi żadnego problemu, w innym może być poważnym wyzwaniem. Na przykład firmy webowe są w stanie wypuszczać zmiany w oprogramowaniu nawet kilka razy dziennie (np. Facebook), natomiast jest to bardzo trudne w przemyśle motoryzacyjnym i nie ma wartości biznesowej w przypadku tworzenia gier.

Ostatni wymóg zapewnia wreszcie, że wprowadzona struktura nie jest ostateczna i organizacja będzie ciągle poszukiwała lepszych rozwiązań, dostosowując je do zmieniającego się otoczenia. Poszczególne zespoły powinny same dobierać procesy i narzędzia pozwalające najskuteczniej adresować stawiane przed nimi problemy. Powinny też ciągle podnosić sobie poprzeczkę, poprawiając procesy i dążąc do coraz trudniejszych celów. Również cała firma musi definiować i usprawniać strukturę organizacji, wspierając tym samym zespoły w realizacji ich celów.

Diabeł tkwi w szczegółach

Model SAFe bazuje na wybranych praktykach Agile, między innymi Scrumie i Kanbanie. Samo korzystanie z praktyk Zwinnych, nie przesądza jednak o byciu Agile. Można mieć codzienne spotkania, używać planning pokera, zdefiniować iteracje i dalej nie być w stanie reagować na potrzeby klientów, prowadzić projekt kaskadowo i zarządzać zespołami z pozycji władzy i kontroli. 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. A przecież to oni, nie procesy i narzędzia, są odpowiedzialni za dostarczanie rozwiązań klientowi. Czyli ludzie i ich interakcje, nad procesy i narzędzia.

SAFe, dzięki dość dużej szczegółowości oraz dostępności certyfikowanych konsultantów daje zarządzającym przyjemne uczucie, że jest łatwy do wdrożenia. Po co skupiać się na największych wyzwaniach, które Scrum wyciąga na światło dzienne, kiedy można bezpiecznie wdrożyć SAFe. Sukces zostaje osiągnięty, nagrody przyznane. To, że wciąż nie rozwiązaliśmy naszych problemów i to, że ludzie postępują według procesów i praktyk SAFe a nie według wartości Agile, wydaje się nie być zauważane. Nic więc dziwnego, że SAFe jest krytykowany przez wielu ekspertów Agile, wliczając w to Kena Schwabera, współtwórcy Scruma oraz Davida Andersona, ojca Kanbana. Przy czym, w przypadku Kena, słowo krytyka, wydaje się być wręcz eufemizmem. Zarzuca on, że SAFe żeruje na sukcesie Agile, skupiając się jednak na procesach, nie ludziach, a więc łamie pierwszą wartość Agile. David dla odmiany zauważa, że zebranie w jednym miejscu grupy działających technik nie gwarantuje, że cały zbiór też będzie działać. To tak, jakby przebadać każdą część samolotu odrzutowego osobno i na końcu obwieścić, że samolot jest całkowicie bezpieczny. Inni autorzy, którzy spotkali się z SAFem zarzucają mu też między innymi rozmycie Definicji Gotowości Produkcyjnej (Definition-of-Done) poprzez dodanie fazy „stabilizacji”, wprowadzenie Proxy Product Ownerów, czy ograniczenie zespołów deweloperskich do programistów i testerów, bez uwzględnienia pozostałych odpowiedzialności (architektury, UX, czy integracji).

Co ciekawe, autorem SAFe jest Dean Leffingwell, ojciec RUPa (Rational Unified Process). Biorąc pod uwagę, że jedną z głównych przyczyn stworzenia Manifestu Agile, była rebelia przeciwko narzucaniu RUPa i podejścia kaskadowego, to można powiedzieć, że historia zatacza koło. Być może wkrótce potrzebne będzie kolejne spotkanie w Snowbird, żeby wspólnie przeciwdziałać SAFe.

Czy jest alternatywa?

Wygląda na to, że jeżeli nie można być Agile, to zawsze można uzyskać certyfikat SAFe. Na dodatek, dzięki dobremu marketingowi SAFe wydaje się być jedynym rozwiązaniem dostępnym dla firm pragnących skorzystać z doświadczeń innych. Na szczęście tak nie jest. W ProCognicie, wspierając naszych klientów, poszukujemy innych rozwiązań skalowania Agile. Przeprowadzamy organizacje przez zmiany bazując na modelu LeSS (Large Scale Scrum), opracowanym przez Claiga Larmana i Basa Vodde. LeSS został z sukcesem wdrożony w wielu firmach. W praktyce sprawdził się nawet przy 1 500 osobach pracujących w siedmiu lokalizacjach na całym świecie. Nie jest on jednak tak sformalizowany jak SAFe. Opiera się na wartościach Agile i zakłada podejście prób i błędów, tak aby struktury, procesy i narzędzia zostały dostosowane do potrzeb organizacji, zespołu i projektu. Dlatego coachowie Agile pomagają firmom i zespołom zidentyfikować ich potrzeby i dobrać odpowiednie metody pracy. Nie narzucamy naszych rozwiązań, ale wspólnie z organizacją poszukujemy technik potrzebnych do efektywnego skalowania i skutecznej komunikacji. Pozwala nam to ograniczyć ilość procesów i zapewnić zwinny rozwój produktu poprzez ewoluującą architekturę (Emerging Architecture). Przede wszystkim jednak skupiamy się na samym procesie zmiany i jego uczestnikach: wytłumaczeniu potrzeby, zapewnieniu poczucia bezpieczeństwa i uzyskaniu ich aprobaty oraz wsparcia. Tym samym nowy model nie jest narzucany odgórnie, jest natomiast rozwijany przy współudziale wszystkich pracowników w oparciu o wartości Agile i Lean.

Referencje

Podobne

Komentarze (4)

  • Lukasz
    23.07.2017 - 21:34
    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.scaledagileframe... nieco dokładniej w Lean-Agile Mindset (http://www.scaledagileframe... a już bardzo szczegółowo w SAFe Lean-Agile Principles (http://www.scaledagileframe.... 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.scaledagileframe....
    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.
  • Tomek
    24.07.2017 - 21:14
    Łukasz,
    Wielkie dzięki za komentarz.

    Moje obserwacje bazuje na mojej znajomości Agile, a także tym czym Agile nie jest. Dodatkowo wspieram się opiniami z dyskusji prowadzonymi z wieloma autorytetami Agile, w tym współautorów Agile Manifesto (takim jak Ron Jeffries), którym nieznajomości Agile nie można raczej zarzucić.

    Prawdą jest, że SAFe stosuje słownictwo Agilowe, Leanowe i Scrumowe, co jednak nie oznacza, że jest Agile, Lean i zgodny ze Scrum. Podam kilka przykładów, żeby nie brzmiało to gołosłownie:
    - 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.
    - Lean bazuje na obniżeniu ilości pracy w toku (WIP). SAFe ma sporą ilość kolejek w postaci rożnych Rejestrów (Backlogów).
    - W Scrumie Product Owner jest odpowiedzialny za produkt widziany oczami klienta. Product Owner w SAFe jest najczęściej odpowiedzialny za komponent.

    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.
  • Lukasz
    24.07.2017 - 22:47
    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 ja na http://www.scaledagileframe... można wyświetlić jeden z 4 jego wariantów, a nie tylko wersję full lub prawie full). 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.

    “- 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.scaledagileframe...

    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.scaledagileframe... 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.
  • Tomasz Wykowski
    04.12.2018 - 12:03
    Łukasz,
    wczoraj odkryłem, że przy przejściu na nowy system komentarzy znikneły Twoje uwagi.
    Więc je przywróciliśmy.
    Chociaż dalej się z nimi nie zgadzam :) Zmiana nazewnictwa w starym, niedziałającym systemie nie powoduje zmian zachowań. Dopiero nowa struktura może doprowadzić do pożądanych rezultatów. Czyli firmy, która potrafi się skupić na tym, co dla niej w tym momencie najważniejsze. Ale to temat na kilka artykułów, a nie komentarz.
    Tomek

Dodaj komentarz