Strzeż się SAFe (Scaled Agile Framework for Enterprise), Unholy Incarnation of Darkness

… a może nie.

Jeśli wolisz SAFe mówić za siebie, możesz użyć łącze powyżej. Istnieją setki stron dokumentacji, godziny filmów, 15 różnych kursów szkoleniowych i nie tylko. Jeśli to brzmi trochę za dużo, zrobię co w mojej mocy, aby wyjaśnić, jak działa SAFe, gdy przejdę przez każdy punkt.

Na najwyższym poziomie, zwanym „Portfolio”, SAFe popiera finansowanie na czas nieokreślony „strumieni wartości” – które zwykle reprezentują produkt, linię produktów lub typ klienta. Jednak funkcja Lean Portfolio Management (LPM), która kontroluje finansowanie (prawdopodobnie te same osoby, które wcześniej były odpowiedzialne za budżety projektów kaskadowych), mają wyłączne uprawnienia do zatwierdzania, które Epiki Portfela (duże inicjatywy) zostaną przeniesione do każdego strumienia. Epopeje nie są wyjaśnieniami problemu, który należy rozwiązać. Są to gotowe pomysły, jak najlepiej rozwiązać te problemy.

Od razu widać oznaki starej szkoły postrzegania zespołów jako funkcji „dostarczania”, a nie funkcji strategicznej. myśliciele poziomu wymyślają pomysły, a wykonawcy niskiego poziomu realizują te pomysły. Ignorowana jest możliwość, że osoby najbliższe pracy mogą być najlepiej przygotowane do podejmowania decyzji na jej temat. Ucieczka od tego błędnego sposobu myślenia jest głównym celem myślenia Agile, które SAFe nie udaje się zdalnie.

Podobny problem pojawia się ponownie, gdy spojrzymy na nieco niższy poziom.

SAFe gromadzi małe zespoły produktowe (często zespoły Scrum) w „Agile Release Trains ”- grupy zespołów z dodatkową warstwą ról zarządczych obejmujących każdą grupę na tak zwanym„ poziomie programu ”.

Ogólnie te role utrudniają autonomię zespołów. Dodają nieproporcjonalnie dodatkowe koszty związane z procesem i komunikacją z wartością, którą zapewniają.

Te role obejmują menedżera produktu (PM), S. ystem Architect (SA) i Release Train Engineer (RTE).

SA i PM definiują i dzielą większe elementy pracy (często odziedziczone z powyższego procesu portfolio), a następnie przekazują je do zespoły.

Właściciel Produktu i zespół mogą teoretycznie być w stanie nadać priorytet innym, mniejszym elementom pracy w stosunku do pracy im narzuconej, ale te wysiłki mają ograniczoną widoczność i wsparcie z góry. Pojawi się naturalna presja, aby traktować pracę pochodzącą z najwyższego punktu jako najważniejszą – nawet jeśli każdy członek zespołu uważa, że inne elementy będą bardziej wartościowe. Z tego powodu rola właściciela produktu ogranicza się do pisania historii i sprawdzania kryteriów akceptacji, zamiast być pojedynczym punktem odpowiedzialnym za kierownictwo produktu, co było pierwotnym zamiarem dla tej roli.

Architekt systemu nie jest w stanie zbliżyć się do rzeczywistych prac inżynierskich, więc plan architektoniczny, który przekazują, może być oderwany od realności dzieła. Tego rodzaju role były cechą charakterystyczną dużych projektów kaskadowych z wyprzedzeniem i są dobrze zachowane w SAFe.

Release Train Engineers definiują spójny proces i kadencję między zespołami oraz wykonują wiele zadań operacyjnych. Ostatecznie pozostawia to mniej miejsca dla poszczególnych zespołów na modyfikowanie, ulepszanie lub eksperymentowanie z własnymi praktykami w jakikolwiek sposób, który odbiega od ustalonych standardów.

Czasami wszystkie te problemy są powtarzane ponownie, dodając „Duży Poziom rozwiązania ”- grupy grup zespołów pełniących analogiczne role do tych na poziomie programu, ale obejmujących składy Release Trains. Kiedy to nastąpi, te same problemy będą się prawdopodobnie powtarzać, ale wydaje się, że poziom rozwiązania jest rzadziej wprowadzany.

SAFe (często) jest dostarczane w pakiecie z Rally – DALSZE ograniczenie autonomii zespołu

SAFe jest często pakietem związanym z oprogramowaniem do zarządzania projektami Rally. Rally to rodzaj oprogramowania, którego można się spodziewać firma wykorzystująca SAFe do tworzenia – jest przeładowana funkcjami, nieostra, zagmatwana, niestabilna, a co za tym idzie, trudna do nauczenia się i używania.

Wartość korzyści z przyjęcia Rally jako lidera polega na tym, że będą w stanie zobaczyć raportowanie, które daje im prosty, ujednolicony obraz th Postęp i problemy w całym przedsiębiorstwie.

Oczywiście oznacza to, że wszyscy w przedsiębiorstwie nie tylko muszą korzystać z Rally, ale także muszą z niego korzystać w konsekwentny sposób. Ponownie, można to osiągnąć tylko poprzez dyktowanie odgórne. Rajd i sposób, w jaki myśli o pracy, są narzucane wszystkim zespołom, niezależnie od ich preferencji, kontekstu czy akceptacji. Faktyczne zebranie wszystkich informacji wymaga niewiarygodnych kosztów szacowania i śledzenia, które spowalniają wszystko i mogą być niezwykle uciążliwe w wykonywaniu pracy.

Ponadto raportowanie na najwyższym poziomie nie jest nawet szczególnie przydatne. Skupia się na rzeczach śledzonych przez Rally – wskaźnikach, takich jak ilość dostarczonych punktów fabularnych (dosłownie zmyślonych) lub ilość usuniętych błędów (okropna miara „jakości produktu”).Jeśli kierownictwo zignoruje te statystyki, dodany przez nich narzut będzie na nic. Jeśli uda im się osiągnąć wskaźniki, statystyki zostaną sfałszowane, aby zespoły wyglądały dobrze i zostały same. Szacunki będą przesadzone, małe fragmenty pracy będą przesadzone, co może łatwo doprowadzić do załamania zaufania.

SAFe przyjmuje najgorsze możliwe podejście do zarządzania zależnościami

A zależność to sytuacja, w której zespół musi poczekać, aż coś zostanie zrobione w innym miejscu, zanim będzie mógł ukończyć własną pracę. SAFe opiera się na podejściu wstecznym, że zależności są niezmiennym faktem życia, który należy zaakceptować i zarządzać nim. Czasami nawet określa je jako strategiczną przewagę. W rzeczywistości, gdy myślisz o uzależnieniach jako o czymś złym – które należy minimalizować przy każdej okazji – może się okazać, że tych możliwości jest mnóstwo, a ich wykorzystanie przynosi przede wszystkim korzyści. Oto tylko kilka sugestii, które SAFe nie podkreśla lub całkowicie ignoruje:

1. Zachęcaj do kultury pozyskiwania wewnętrznego, w której jeden zespół może przekazywać pracę do kodu innego zespołu bez konieczności polegania na nich poza akceptowanie połączenia
2. Ułatw członkom zespołu tymczasową lub stałą zamianę zespołów, gdy ma to sens
3. Skoncentruj się na zatrudnianiu, organizowaniu i szkoleniu zespołów, aby sprostać ich własnym potrzebom bez pomocy z zewnątrz

SAFe decyduje się na zarządzanie zależnościami poprzez zwiększenie nacisku na planowanie, proces, hierarchię i standaryzację. Jak można się było spodziewać, prowadzi to do wielu spotkań, które kolidują z możliwością wykonania pracy. Narzuca to podejście poprzez uniwersalny roll-out, który od razu wpływa na całą organizację. Nie rozważa się, które obszary mogłyby być samodzielne bez dodatkowej uciążliwej struktury.

SAFe jest nadmiernie zorientowany na planowanie

Główną cechą SAFe jest idea ~ 10 tygodni Przyrosty programu (PI). Możesz myśleć o takich rodzajach jak ogromne sprinty, które zawierają wszystkie twoje normalne sprinty.

Każdy PI zaczyna się od wydarzenia planowania PI, które trwa około dwóch dni. Planowanie PI wymaga również działań z wyprzedzeniem i po planowaniu na poziomie Programu.

Zdecydowanie wartościowe jest to, że ludzie spotykają się osobiście w celu budowania relacji, dzielenia się informacjami i orientowania się w celach. Z drugiej strony, wykorzystanie tego ograniczonego okna czasowego do sporządzenia 10-tygodniowych planów konkretnych historyjek użytkownika w oparciu o predefiniowane funkcje, a następnie wymaganie zaangażowania w te plany jest znacznie mniej wartościowe.

Po zakończeniu planowania PI plany te tworzone są w oparciu o ograniczone zrozumienie i liczne założenia staną się przestarzałe, gdy tylko dowiemy się czegoś nowego. Zespoły będą ciągle rozdarte między trzymaniem się planu, którego się nauczyły, który nie ma sensu, a reorientacją oczekiwań z powodów, których ci nad nimi mogą nie być w stanie zrozumieć.

SAFe koncentruje się na głośności, nie wartość

W całym tym skupianiu się na metrykach wolumenu, szacowaniu i pracy w potoku, koncepcja tego, co jest naprawdę wartościowe lub udane, łatwo jest stracić. Często zakłada się, że więcej pracy wysłanej za drzwi musi być „wartościowe”, nawet jeśli doświadczenie z produktem faktycznie cierpi, a użytkownicy nie odnoszą korzyści z dodatkowych funkcji.

SAFe jest świadomy krytyki, że nie koncentruje się na wartościach i niedawno dodał do swojej dokumentacji „myślenie projektowe”, „zorientowanie na klienta” i inne koncepcje, aby to zrekompensować. Jak dotąd nie jestem przekonany, że wprowadza w swoim procesie jakiekolwiek znaczące zmiany, które faktycznie robią miejsce na te rzeczy , a przede wszystkim trudno je nawet zrozumieć.

Na przykład definicja „klientów” w SAFe pozostawia otwarte drzwi do zdefiniowania interesariuszy biznesowych lub tych, którzy finansują strumienie wartości, jako „klientów”. bardzo różni się od zmiany orientacji wszystkich (w tym osób udzielających finansowania) na potrzeby użytkowników końcowych faktycznie korzystających z oprogramowania, co jest podstawowym elementem myślenia projektowego.

SAFe jest niepotrzebnie skomplikowane

SAFe ma naturalną zaletę, która chroni to z krytyki; To jest tak skomplikowane, że trudno to w pełni pojąć. Pomimo dodatkowego czasu, który spędziłem na badaniu struktury, prawdopodobnie nadal coś mi się nie uda lub przeoczę kilka ważnych punktów. Jednak obfitość złożoności sama w sobie jest uzasadnionym problemem. SAFe ma tak wiele spotkań, punktów kontrolnych, wartości i metod, że praktycznie niemożliwe jest, aby wszyscy byli na tej samej stronie.

SAFe ogranicza retrospektywy i ciągłe doskonalenie

Role na poziomie programu i powyżej nie może uczestniczyć we wszystkich retrospektywach zespołu.Oznacza to, że retrospektywy nie będą bezpośrednio słyszane przez ludzi, którzy faktycznie mogą zmienić wiele z omawianych rzeczy.

Sposób, w jaki SAFe próbuje to zrekompensować, nie jest wystarczający.

Planowanie PI to jedyny czas, w którym wszyscy w pociągu wydającym mają gwarancję, że będą razem osobiście. Niestety zawiera krótką retrospektywę związaną tylko z sukcesem samego wydarzenia związanego z planowaniem.

SAFe zawiera zdarzenie „Sprawdź i dostosuj” pod koniec każdego PI, ale wydaje się, że jest prawie zaprojektowane do pominięcia w oparciu o o tym, jak trudno jest koordynować RTE. Po zorganizowaniu wydarzenie jest przygotowywane poprzez przegląd – oczywiście – wskaźników ilościowych z ostatniego PI. Dodatkowo tylko 30 minut wydarzenia jest przydzielane na faktyczną retrospektywę, podczas której problemy są ujawniane i uzgadniane Jeśli ten czas zostanie równo podzielony między wszystkich członków 100-osobowego Release Train, każdy uczestnik będzie miał około 18 sekund co ~ 10 tygodni na poruszenie problemów w kontekście, w którym mogą być faktycznie słyszane. p> SAFe zawiera również inne elementy, takie jak „karty oceny”, w których zespoły są poddawane szerszemu badaniu, ale polegają one głównie na potwierdzeniu, że praktyki SAFe są przestrzegane, a nie na tym, czy są one skuteczne.

SAFe degraduje koncepcje, które agreguje

Klucz częścią SAFe, której jeszcze nie poruszyłem, jest agregacja istniejących koncepcji, takich jak Scrum, Kanban, Lean Product, Lean UX i DevOP.

Jeśli nie jesteś zaznajomiony, proponuję zbadać każdą koncepcję niezależnie w czasie, a nie wszystkie naraz. Wiele z nich jest cennych, ale SAFe nie radzi sobie zbyt dobrze z ich syntezą i czasami może powodować zamieszanie. Przykład:

SAFe rutynowo opowiada się za tym, jak jego praktyki są zgodne z zasadami „Lean-Agile”. Sztuczka polega na tym, że „Lean-Agile” w rzeczywistości nie odnosi się do zasad „Lean” lub „Agile”.

Zamiast „Lean-Agile Principles” są wytworem własnego projektu SAFe. Ten nowy zestaw „zasad” wypacza koncepcje, które przyswaja. Na przykład strona poświęcona decentralizacji decyzji (najniżej ze wszystkich zasad) subtelnie podważa samą siebie, podkreślając znaczenie scentralizowania podejmowania decyzji w wielu przypadkach użycia. Inne wymienione zasady mają podobne problemy. Dla osoby, która zostanie wprowadzona do wszystkich tych informacji naraz, rzeczywiste znaczenie oryginalnych koncepcji może zostać utracone.

SAFe nie jest Agile

Do tej pory wiele sposobów SAFe jest niezgodne z nastawieniem Agile powinno być całkiem jasne. Jest ukierunkowany na plan, biurokratyczny, skomplikowany, zawiera wiele często niepotrzebnych procesów, pozbawia zespół autonomii i nie tylko.

Ale czy ma znaczenie, czy SAFe jest Agile, czy nie, kiedy naprawdę zależy nam na skuteczności ?

Tak. Tak.

Zasady zwinne są zasadami zwinnymi tylko dlatego, że zostały ogólnie uznane i uzgodnione jako skuteczne. To myślenie odbiło się echem w szerszej społeczności praktyków, dlatego początkowo ruch się rozwinął. Jeśli myślisz, że zwinność jest predyktorem efektywności (przekonanie, które prawdopodobnie kryje się za pewnym zainteresowaniem SAFe), to ma duże znaczenie, czy SAFe jest spójne z myśleniem Agile. Wprowadzanie ludzi w błąd co do tego, co kupują, jest czymś złym i nie można tego mówić.

A co ze wszystkimi studiami przypadków, w których wykazano, że SAFe zadziałało?

Na scaledagileframework.com znajduje się około 40 studiów przypadku dotyczących pomyślnego wdrożenia SAFe. Studia przypadków dotyczące awarii są ewidentnie nieobecne. W przeciwieństwie do akronimu, SAFe oznacza jednoczesne zmiany w ogromnym nowym procesie w ogromnym ekosystemie – ogromne ryzyko. O ile każda z tych 40 odnoszących sukcesy firm nie miała po 11 250 certyfikowanych praktyków SAFe, jest sporo firm, o których nie słyszeliśmy.

Poza tym nie przykładam zbytniej wagi do studiów przypadku, które tak robią istnieć. Nawet jeśli wskaźniki wolumenu, na których się skupiają, były naprawdę wartościowe, łatwo jest wybrać kilka statystyk, które sprawiają, że wydaje się, że wszystko poszło dobrze.

Aby skupić się na konkretnym przykładzie, spójrzmy na fragment ze studium przypadku wdrożenia SAFe w Fitbit:

W 2016 roku firma Fitbit wypuściła na rynek cztery nowe produkty, które zostały pozytywnie odebrane przez konsumentów i wysłał ponad 22 miliony urządzeń. Dostarczanie największej liczby produktów w ciągu roku wynika po części z zaangażowania firmy i sukcesu we wdrażaniu SAFe® (Scaled Agile Framework®) jako sposobu na skalowanie zespołu w celu dotrzymania docelowych terminów.

© Scaled Agile, Inc.

Oto cena akcji Fitbit z ostatnich pięciu lat:

Tak… 2016 wygląda na wspaniały rok dla Fitbit.

Teraz nie możemy tak naprawdę przypisać upadku Fitbit SAFe przyjęcie z ilością posiadanych przez nas informacji.Ale jeśli firma może tak mocno walczyć i nadal chwali przyjęcie SAFe jako poprawy reagowania na decyzje dotyczące produktów, zamierzam zmrużyć oczy jeszcze o kilka stopni, sprawdzając pozostałe studia przypadków.

Jest w porządku jako krok przejściowy, prawda?

Jeśli jesteś kimś, kto mógłby wysunąć ten argument, musisz pomyśleć, że SAFe musi zostać przeniesione. W tej kwestii się zgadzamy!

Aby dokonać tego przejścia, będziemy oczywiście musieli poświęcić trochę czasu na wskazanie części, które nie działają dobrze.

Czy to jest coś, co spędzasz dużo czasu?

Nawet jeśli tak jest, SAFe jest skonfigurowane w sposób uniemożliwiający rzeczywiste przejście. Autorytet, który oddaje w ręce kierownictwa, działa jako legitymizacja odgórnej mentalności kontrolnej. To słabo łączy się z brakującymi metodami ulepszania procesów, które już omówiliśmy. Uprawnienie do „dostosowywania” SAFe do odpowiedniego kontekstu jest w większości niedostępne dla rzeczywistych zespołów, które są najlepiej przygotowane do rozpoznania tego, co nie działa.

Nigdzie na mapie drogowej SAFe nie odnosi się do żadnego z jego podstawowe praktyki jako przejściowe. Jeśli jest to struktura przejściowa, to niezbyt dobrze radzi sobie z zapewnieniem jakiegokolwiek planu przejścia.

Skupienie się na certyfikatach również wpływa na elastyczność struktury . Jeśli spędzasz wiele godzin pracując nad uzyskaniem certyfikatu, certyfikat stanie się częścią Twojej własnej wartości. Przejście na coś, co mniej przypomina SAFe, może wydawać się, że zagraża tej wartości. Nie mogę winić nikogo za uzyskanie certyfikatu w rynek pracy gdzie certyfikaty mają znaczenie. Ale te osoby mają szczególny obowiązek zwracania uwagi na wady SAFe i możliwe sposoby poprawy lub odejścia od niego.

Te problemy są szeroko doświadczane.

Nie jestem sam w wyrażając wiele z tych krytycznych uwag – chociaż mam nadzieję, że poszedłem nieco dalej w łączeniu ich z konkretnymi praktykami w ramach. Jeśli szukasz potwierdzających zeznań, oto kilka:

Ken Schwaber, współtwórca Scruma, wyraził poważne obawy dotyczące SAFe już w 2013 roku.

Nicholas M. Chaillan , Dyrektor ds. Oprogramowania Sił Powietrznych Stanów Zjednoczonych, odradza „używanie sztywnych, normatywnych ram, takich jak Scaled Agile Framework (SAFe)”.

Steve Denning, współautor Forbes, w swoim artykule na temat „szczególnie niepokoju” woła SAFe za „szczególnie niepokojące” jak rozpoznać fałszywy Agile.

Marty Cagan z Silicon Valley Product Group wyjaśnia, w jaki sposób SAFe jest sprzeczne z nastawieniem firm z Doliny Krzemowej.

Bądź bezpieczny (nie SAFe)

Chociaż SAFe z pewnością spotkało się z dużą ilością krytyki Osobiście uważam, że ta krytyka mogła nie dotrzeć do szerokiego grona odbiorców poza określonymi kręgami online. Jest to szczególnie prawdopodobne, gdy weźmie się pod uwagę rosnącą liczbę firm, które każdego dnia przyjmują ten framework.

Dla wielu osób pomysł, że SAFe jest nie tak – lub że w ogóle jest sprzeczny z zasadami Agile – może być całkowicie nowatorski.

Zwiększona dyskusja skierowana do szerszej publiczności może prawdopodobnie pomóc. Mam nadzieję, że w przyszłości bardziej dotknę tego tematu i wyjaśnię, jakie są inne alternatywy.

Na razie nawet jeśli nie pracujesz w środowisku SAFe, nie jest to wymówka, by popadać w samozadowolenie . Obawy, które tutaj przedstawiłem, należy traktować jako szersze ostrzeżenie – nawet najbardziej rozsądne pomysły można łatwo dokooptować, zepsuć i zdezorientować, jeśli nie będziesz uważać.