SAFe Case Studies: Notatki dotyczące transformacji z terenu

Ten artykuł jest częścią trzecią serii skalowania Agile firmy Toptal, mającej na celu pokierowanie kierownikami projektów w ich wysiłkach na rzecz rozbudowy zespołów. Koniecznie przeczytaj część pierwszą, „Porównanie 5 frameworków Agile Scaling: którego należy użyć?” oraz część druga, „Agile Scaling: SAFe Best Practices for Scrum Masters”.

Według 15th Annual State of Agile Report , 94% firm praktykuje w pewien sposób Agility. Ale badania sugerują również, że 90% organizacji zmaga się z wdrożeniem Agile w całym przedsiębiorstwie. Zazwyczaj jest to praca trenerów Agile, mistrzów Scrum i innych specjalistów od zarządzania projektami, aby prowadzić i organizować te wysiłki. Często pracują z zespołami lub działami, które są odporne na zmiany, w trudnej do zrozumienia kulturze firmy.

Podczas tego okrągłego stołu trzech kierowników projektów z Toptal omawia wyzwania związane z prowadzeniem transformacji Agile. Ponieważ ich rozwiązania są zgodne ze Scaled Agile Framework (SAFe), rozmawialiśmy również z Deanem Leffingwellem, twórcą SAFe. Ich zbiorowe spostrzeżenia ilustrują potrzebę przygotowania przez praktyków SAFe jasnej wizji tego, czym jest zwinność, oraz planu przywództwa, który może przyciągnąć oporne zespoły.

BEZPIECZNE ROZMOWY Z TWÓRCĄ STRUKTURY

SAFe, framework sformalizowany przez Scaled Agile, powstał dopiero w 2014 roku. Ale dla Leffingwella prace rozpoczęły się, gdy po raz pierwszy zetknął się z zespołami Agile na początku 2000 roku. Jako metodolog tworzenia oprogramowania był pod wrażeniem wyników praktyk Agile w zespołach programistów i natychmiast zaczął badać, w jaki sposób sposób myślenia można zastosować w całej firmie. Jeśli zespół Agile może osiągnąć wyniki, co może wyprodukować zespół zgranych zespołów Agile? Jak można wykorzystać praktyki Agile w projektach transformacji na pełną skalę w krajowych lub międzynarodowych firmach? Jak mówi Leffingwell: „Uwielbiam tworzenie oprogramowania. Uwielbiam Agile. Po prostu chcę, żeby było duże ”.

Od tamtej pory firmy dostrzegły zalety SAFe, w tym krótsze dostawy, wyższą jakość produktów, większą wydajność i bardziej zaangażowani pracownicy. Od 2021 r. ponad jedna trzecia organizacji na całym świecie korzystała z SAFe, a wśród jego najważniejszych aspektów są wspólne procesy i ujednolicony język, który zapewnia. Na przykład, jeśli jeden zespół sądzi, że sprint trwa dwa tygodnie, a inny myśli, że trwa 30 dni, tworzy to, co Leffingwell opisuje jako „problem z wieżą Babel”. Zespołom trudno jest dyskutować, jakie funkcje dodać, jeśli nie mogą nawet dojść do porozumienia, co oznacza „funkcja”. „Potrzebujesz ludzi pracujących w sposób wspólny, jeśli chcesz budować duże rozwiązania”, mówi. „W naszej branży nie ma terminu, który nie byłby przeładowany, jak „iteracja”, „sprint” lub „zaległości”. To nie jest pomocne, jeśli próbujesz pracować ponad granicami zespołu i regionu”.

Zwinne historie sukcesu

Skłonienie wszystkich w firmie do przyjęcia jednolitego sposobu mówienia o pracy i wykonywania jej jest trudnym zadaniem, nawet jeśli istnieje pilna potrzeba zmian. W korporacjach o ugruntowanej pozycji może być trudniej. Leffingwell wyjaśnia: „Patrzysz na największe firmy na świecie, które zarabiają dużo pieniędzy, świetnie sobie radzą i konkurują – i muszą się zmienić. Cóż, pytanie do nich brzmi: dlaczego mieliby? Każdy z przedstawionych tutaj kierowników projektów z Toptal napotkał takie pytania podczas własnych działań związanych ze skalowaniem i każdy znalazł swój własny sposób na przepracowanie swoich transformacji Agile przy użyciu SAFe.

Demonstrowanie wartości

Alvaro Villena, kierownik projektu Toptal w Santiago w Chile, niedawno zakończył przejście SAFe do portfela rozwijającego platformę międzybranżową. „Pierwszym kamieniem milowym w moim przejściu było przeprowadzenie warsztatu strumienia wartości”, mówi. Mówiąc prościej, warsztaty dotyczące strumienia wartości to spotkanie inauguracyjne mające na celu zidentyfikowanie całego procesu biznesowego od koncepcji po dostawę oraz wszystkich etapów, użytkowników, systemów i punktów bólu pomiędzy nimi.

Pozyskanie przedstawicieli całego przedsiębiorstwa do warsztatu pomogło Villenie zrozumieć kulturę firmy i jej przeszkody. „Zanim wdrożyliśmy warsztat, istniała struktura, w której jedna firma miała swój zespół, inna firma miała swój zespół, a następna firma miała swój zespół — te trzy nie rozmawiały ze sobą”.

Villena odkryła, że ​​chociaż wszystkie zespoły mają podobne problemy, nie było współpracy w zakresie rozwiązań. Na przykład, chociaż każda firma w portfolio dostarczała produkty, tylko jedna opracowała system śledzenia. Nie było powodu, dla którego wszyscy nie mogliby z niego korzystać, poza tym, że nikt nie podzielił się tą wiedzą. Gdy warsztaty sprawiły, że zaczęli mówić, wiedza zaczęła płynąć między zespołami, firmami i właścicielami produktów. „Tego rodzaju rozmowa była naprawdę mocna dla programu. To był dobry punkt wyjścia” – mówi Villena. Kiedy DevOps, projekt i produkt wiedzą, co robią inne zespoły, widzą, że w firmie istnieją rozwiązania, z których mogą korzystać. „Zaczynają pytać: 'Jak mogę to mieć?' I właśnie wtedy wkraczasz i mówisz: „Podążaj za tym procesem”.

„Nikt nie chce zmian, dopóki nie dowie się dlaczego. Więc zaczynasz od wyjaśnienia i dajesz im lepszą przyszłość”. Dean Leffingwell, twórca SAFe

Leffingwell wie, że zespoły czasami są odporne. „Nikt nie chce zmian, dopóki nie dowie się dlaczego”, mówi Toptalowi. „Więc zaczynasz od wyjaśnienia i dajesz im lepszą przyszłość”. Danie zespołom wglądu w to, o ile bardziej mogą być wydajniejsze, jest potężnym narzędziem do przywództwa zmian.

Nawet jeśli wszyscy są entuzjastycznie na pokładzie, nadal należy spodziewać się kamienistych startów. Na przykład zespoły przyzwyczajone do tradycyjnego tworzenia Waterfall i dużych wydań mogą mieć problem z przejściem do bardziej iteracyjnego i zwinnego procesu rozwoju, nawet jeśli dostrzegają w tym wartość. „Pierwszy przyrost programu, który zrobiliśmy, był rodzajem katastrofy dla zespołów” — mówi Villena. „I wiedzieliśmy, że tak będzie; powiedzieliśmy klientowi, aby spodziewał się, że pierwsze trzy miesiące mogą być trudne.” Aby to zrekompensować, zbudował jednorazową tygodniową iterację pod koniec pierwszego przyrostu programu (PI), w której zespoły mogły ocenić swoje postępy. Zorganizował sprint poświęcony wyłącznie usprawnieniom i ocenom procesów, które wykraczałyby poza zwykłą kontrolę i adaptację. Uznał za przydatne, aby zastosować podejście Agile nie tylko do produktu, ale także do zmiany biznesowej, poświęcając czas na cofnięcie się, zobaczenie, co zadziałało, a co nie, i odpowiednie dostosowanie.

Tworzenie małych zwycięstw

Ważne jest, aby być przygotowanym na nieoczekiwane przeszkody w adopcji SAFe. Kilka lat temu kierownik projektu Toptal Miroslav Anicin w Belgradzie w Serbii przestawił firmę telekomunikacyjną na SAFe. Firma zleciła na zewnątrz cały rozwój oprogramowania. Włączenie zespołu poza siedzibą nie było szczególnie uciążliwym zadaniem — chodziło głównie o kwestie logistyczne. Jednak wysiłek ten stworzył nieprzewidziane wyzwania w transformacji samej firmy. „Szukałem kompetencji, których potrzebujemy w pociągu do wydania”, mówi. „I wszyscy ludzie, z których miałem do wyboru, pochodzili z marketingu, z działu prawnego, z produktów, z finansów – całkowicie pozbawiony nastawienia Agile ani nawet żadnego doświadczenia w Agile”.

Stało się oczywiste, że kierownictwo nie ma doświadczenia w obsłudze zespołów Agile. Rozproszone podejmowanie decyzji wymaga od menedżerów rezygnacji z pewnej kontroli, na co przywództwo może się sprzeciwić, jeśli nie mają doświadczenia z frameworkami Agile. Aby rozwiązać ten problem, Anicin musiał trenować oddolnie i odgórnie, trenując liderów wraz ze swoimi zespołami.

Takie przejście do bardziej zdecentralizowanego podejmowania decyzji wymaga „zmiany sposobu pracy z dowodzenia i kontroli, poprzez przywództwo-sługę, na tę wzmacniającą kulturę uczenia się i kulturę Agile – oraz zdolność do tolerowania błędów” – mówi Leffingwell.

Anicin rozpoczął proces stopniowego skalowania — z małymi projektami Agile wykonywanymi w ramach pojedynczych zespołów, a nie w ramach SAFe — aby poszczególne zespoły mogły zdobyć praktyczne doświadczenie. Projekty te musiały być nieistotne i na tyle małe, aby firma nie ucierpiała, gdyby coś poszło nie tak za pierwszym razem, ale na tyle przydatne, aby pokazać zespołowi, co można osiągnąć dzięki temu podejściu. Na przykład zespół marketingowy stworzył wewnętrzną kampanię marketingową, podczas której Anicin nauczył ich podstaw Scrum. Podobnie jak w przypadku warsztatu Villeny, te mniejsze projekty pokazują rzeczywistą wartość Agile, dzięki czemu członkowie zespołu i kierownictwo mogą dostrzec korzyści płynące z krótkich wydań i ciągłego doskonalenia przed przejściem na pełną skalę.

Zaspokajanie potrzeb swoich zespołów

Kiedy Imane Marouane, kierownik projektu Toptal z siedzibą w Paryżu, przeprowadziła transformację w dużej, międzynarodowej instytucji finansowej, wkroczyła w chaotyczne środowisko, w którym poszczególne zespoły wykonywały solidną pracę, ale nie podzielały wizji całej firmy. „Każdy zespół miał swój własny priorytet. Każdy menedżer produktu chciał, aby jego produkt został dostarczony jako pierwszy”.

Rozwiązanie SAFe dla tego problemu można znaleźć w modelu ważonego najkrótszego zadania (WSJF). WSJF zapewnia standard ustalania priorytetów pracy, więc kiedy nadszedł czas, aby zdecydować, jakie powinno być następne zadanie, pierwszy krok nie wiąże się z sporami o to, jak uszeregować ważność. W systemie Agile opartym na przepływach nie musisz martwić się dostarczaniem wszystkiego na raz, ponieważ, jak mówi Leffingwell, „najważniejszą rzeczą jest to, jaką pracę wykonać dalej. I jest to o wiele łatwiejsze pytanie niż jaka jest najcenniejsza praca”. SAFe zapewnia sposób rozwiązywania zależności między zespołami — uporządkowanie zadań ma kluczowe znaczenie dla tego wyniku.

Droga Marouane do rozwiązania zależności stała się niepewna: „Po dwóch sprintach, przed pierwszą inspekcją i adaptacją, zauważyliśmy, że niektóre zespoły nie przestrzegają naszego planu PI”. Zależności, które zostały zdefiniowane w planie PI, nie były przestrzegane, więc praca jednego zespołu nie mogła się rozpocząć, ponieważ wkład innego zespołu nie był gotowy.

„Ponieważ była to pierwsza iteracja, a zespoły nie były przyzwyczajone do tego rodzaju pracy, postanowiliśmy zorganizować dodatkową ceremonię — cotygodniowe spotkanie w celu omówienia postępów w zakresie zależności” — mówi Marouane. „Jedna osoba z każdego zespołu przyszła, aby zaktualizować postępy w swoich wkładach”. W ten sposób, jeśli Drużyna A powie, że nie jest w stanie dostarczyć, Drużyna B może wiedzieć z wyprzedzeniem i odpowiednio planować, zamiast czekać na wkłady, które nie zmaterializują się na początku sprintu.

Leffingwell głosi ostrożność podczas dokonywania tego rodzaju zmian w SAFe: „SAFe to system odpowiedzialności. … Możesz to dostosować, ale musisz być naprawdę ostrożny”. Chociaż struktura ma być elastyczna, zmiany mają tendencję do zapiekania się, jeśli nie zostaną ponownie ocenione. Konfiguracja Essential SAFe istnieje, aby upewnić się, że wszelkie zmiany spełniają podstawowe kryteria.

Dodatkowa ceremonia Marouane'a została ponownie włączona do drugiego PI, a do trzeciego została wycofana. Zespoły nie miały nic do zgłoszenia, co nie zostało już przekazane. Trochę dodatkowej elastyczności pozwoliło Marouane sprowadzić zespoły z powrotem na bardziej tradycyjną ścieżkę procesu. Odkryła, że ​​samo przejście wymaga podejścia Agile, aby jak najlepiej wykorzystać zespoły instytucji finansowej. Co ważne, zmiana, którą wprowadziła, poprzez zaangażowanie w ciągłe doskonalenie, ostatecznie służyła zasadom Lean-Agile, które są podstawą Essential SAFe. Jej rozwiązanie dało firmie ujednoliconą wizję, której jej brakowało, i umożliwiło zespołom wspólną pracę na rzecz tych samych priorytetów.

Dostosuj się do przyszłości

Każdy framework działający na dużą skalę będzie wiązał się z wyzwaniami. Ilość ruchomych części i sprzecznych interesów jest ogromna. Ale korzyści są równie duże, a dobrze przeprowadzona transformacja zapewni zespołom narzędzia, których potrzebują do pracy nad wspólnymi celami. Przeszkody, jakie napotkasz w implementacji na tak dużą skalę, będą nieprzewidywalne, a podejście Agile pomogło Villenie, Anicinowi i Marouane dostosować się do nieoczekiwanych wyzwań. W końcu po to właśnie jest ciągła dostawa: wzmacnianie procesu za pomocą narzędzi do dostosowywania się do nieprzewidzianych sytuacji.

Scaled Agile dostosowuje się również do nowych technologii i zmieniających się standardów branżowych, wprowadzając w razie potrzeby nowe narzędzia i możliwości. Każdy musi zachować zwinność i przygotować się na nieoczekiwane. „Nie mamy kryształowej kuli”, mówi Leffingwell. „Po prostu biegamy szybko, mocno prowadzimy i podążamy mocno – i piszemy tak szybko, jak potrafimy”.