Efektywne skalowanie zwinnych zespołów

Misją Dean’a Leffingwell’a, twórcy jednej ze zwinnych metodyk Scaled Agile Framework (SAFe), jest tworzenie doskonałego oprogramowania, które czyni świat lepszym miejscem. Opracowana przez niego metodyka SAFe pozwala na skalowanie prac zespołów zwinnych w dużych organizacjach, w których dziesiątki deweloperów pracują nad rozwojem jednego produktu lub projektu. SAFe przewiduje podział organizacji na 4 poziomy: zespół, program, duże rozwiązanie oraz portfolio, których koordynacja została szczegółowo opisane w SAFe. O praktycznych aspektach pracy w metodologii SAFe rozmawiamy z Haraldem Steinbornem i Liangiem Que z niemieckiej praktyki Deloitte.

Harald Steinborn posiada ponad 17 lat doświadczenia w branży consultingowej i z powodzeniem dostarczał kompleksowe programy transformacji zwinnych. Regularnie pracuje z międzynarodowymi i rozproszonymi zespołami, które wspiera jako trener oraz Agile Coach. Harald jest certyfikowanym Scrum Masterem, posiada certyfikację SAFe Agilist, SAFe Program Consultant. Tworzy również społeczność Agile w obszarze usług finansowych w Niemczech.

Liang Que ma ponad 10 letnie doświadczenie w zarządzaniu i doradztwie IT. Jest menedżerem linii usługowej Financial Services Business Transformation, obsługując organizacje z sektora bankowego w zakresie transformacji IT. Posiada certyfikację SAFe Program Consultant, regularnie świadczy usługi doradcze, jak i prowadzi szkolenia w zakresie skalowania Agile w dużych organizacjach.

Artur Kożuch: Statystycznie, Scaled Agile Framework (SAFe) to najpopularniejsza metoda, która jest wykorzystywana do skalowania i koordynacji prac zwinnych zespołów. Z czego wynika tak duże zainteresowanie SAFe współczesnych organizacji?

Harald Steinborn: SAFe zapewnia bardzo rozbudowane i dobrze udokumentowane podejście do skalowania Agile w całej organizacji. Framework zawiera również jasną mapę drogową implementacji i odpowiednie działania szkoleniowe, które będą wspierać transformację. Ponadto, SAFe łączy poziom portfolio (lub strategiczny), z programem oraz poziomem zespołu, dodając kilka dobrych praktyk zarządzania i utrzymując niektóre tradycyjne role zarządcze na swoim stanowisku, np. kierownika portfela. W ten sposób wprowadza ramy, które pozwalają na zwinne zarządzanie portfelem – co jest nowe i istotne – oraz jednocześnie przekazuje zalecenia dotyczące sposobu organizacji pracy wokół strumieni wartości -Value Streams. Tak więc to ustrukturyzowane podejście jest jednym z powodów, dla których SAFe można uznać za "model referencyjny" dla rynku.

AK: SAFe to złożona metoda, która podzielona jest na kilka warstw: zespół, program, duże rozwiązania oraz portfolio. Mnogość ról, ceremonii, artefaktów czyni framework trudnym do zrozumienia. Czy przekonanie kadry kierowniczej do korzystania SAFe stanowi wyzwanie? Jak powinno się z nimi o tym rozmawiać?

Harald Steinborn: Z mojego doświadczenia wynika, że wiele organizacji, które chcą zaimplementować SAFe, ma już doświadczenie w zakresie zwinnych metodyk. Często znany jest im Scrum, a odpowiednie role, artefakty i ceremonie są stosowane na poziomie zespołów. Dla całkowitej transformacji Agile wewnątrz organizacji korzystając z metody SAFe rekomenduje poniższe kroki:

• Po pierwsze, musimy dostosować się do kierownictwa aby zrozumieć, dlaczego chcą korzystać z SAFe i jakie problemy próbują rozwiązać np. skuteczne wdrożenie dużej platformy IT. 
• Utworzenie koalicji na rzecz zmian ma kluczowe znaczenie dla powodzenia procesu wprowadzania zmian w organizacji. W związku z tym konieczne jest przeszkolenie zespołu kierowniczego i innych agentów zmian w zakresie SAFe, ponieważ to oni muszą przewodzić zmianom. Muszą zrozumieć podstawową koncepcję obejmującą zasady i praktyki Lean Agile, zwinny sposób myślenia oraz mapę drogową implementacji SAFe. 
• Należy również podkreślić fakt, że sama transformacja SAFe jest podróżą, która zawsze będzie wymagała czasu. Transformacja do SAFe powinna być zaplanowana jako podejście stopniowe, dostosowane do szybkości i potrzeb organizacji, ponieważ nigdy nie nastąpi to z dnia na dzień. 
• Na koniec należy podkreślić podstawową ideę SAFe: role, artefakty i ceremonie, które znamy z Scrum, które są stosowane na poziomie zespołu (np. Scrum Master, DevTeam, Product Owner, Sprint Planning, tablice Kanban) będą powtarzane na poziomie programu, dużego rozwiązania i portfolio. Dodatkowo wprowadzony zostanie zestaw spotkań koordynacyjnych, takich jak spotkanie Program Increment Planning (PI), dodatkowe zespoły i koncepcje, aby efektywnie i sprawnie zarządzać zwinną organizacją.

AK: Organizacja spotkań planistycznych PI wymaga zgromadzenia członków wszystkich zespołów deweloperskich w jednym miejscu raz na 10 tygodni. Tak duże przedsięwzięcie jest drogie. Jak można zmierzyć, czy to się opłaca? Jakie są najważniejsze korzyści, które przynosi PI Planning?

Harald Steinborn: Tak, organizacja spotkań PI jest złożona i kosztowna. Ponadto, pierwsze planowanie w firmie może przebiegać chaotycznie. Jednakże, trzeba tego doświadczyć w praktyce tak, jak każdej innej ceremonii Scrum. Jest to bardzo istotne 2-dniowe spotkanie. Wszyscy spotykają się, aktywnie uczestniczą, biorą udział w debatach i planach. Wizja produktu jest wspólna, podkreślane są zależności pomiędzy zespołami deweloperskimi. Pod koniec pierwszego dnia uczestnicy mogą udać się na imprezy sieciowe, które posiadają charakter integracyjny (zwłaszcza dla zespołów rozproszonych).

Tak, to spotkanie jest kosztowne. Niemniej jednak poziom aktywnego zaangażowania uczestników jest bardzo wysoki, a spotkania PI odgrywają ważną rolę w budowaniu zespołu. Nie posiadam liczbowych danych takich jak ROI z prowadzenia spotkań PI. Jednak brak spotkań PI okaże się dużo droższy: komunikacja i dostosowanie komunikatów, dzielenie się wspólną wizją, tworzenie sieci i zespołów, planowanie i identyfikacja zależności będzie bardziej złożona i kosztowna, zwłaszcza w przypadku tworzenia produktów obejmujących wiele zespołów w wielu miejscach (geograficznych). Biorąc pod uwagę pozytywny wpływ na wydajność, dostosowanie i budowanie zespołu, istnieje wiele korzyści z prowadzenia spotkań PI. Wyobraź sobie, że kadra kierownicza firmy, która określa cele strategiczne i zespół rozwojowy, który wdraża rozwiązanie, spotkają się ze sobą twarzą w twarz. Jak często dzieje się to w tradycyjnych organizacjach?

AK: Jaką obecnie rolę odgrywa architektura w zwinnych organizacjach, które korzystają z SAFe? Nie uważasz, że jest ona niedoceniana?

Liang Que: Tak, rzeczywiście, zwinne metody takie jak Scrum nie koncentrują się zbytnio na istocie architektury, ponieważ mały zespół, który posiada dobre umiejętności w zakresie inżynierii oprogramowania z umiejętnościami architektonicznymi, jest często uważany za "wystarczająco dobry". Z mojego punktu widzenia architektura odgrywa kluczową rolę i działa, jako podstawa dla rozwoju produktu w skalowalnej, zwinnej organizacji. Jest jak tory dla pociągu, który bez nich nigdzie nie pojedzie. Bez architektury, ogólna jakość systemu będzie w tarapatach, wymagania poza funkcjonalne (NFR) będą tylko na papierze, a wiele innych różnorodnych kwestii pojawi się bardzo późno. Rola architektury ma kluczowe znaczenie dla prawie każdego dużego zwinnego projektu.

AK: Czy pracując w Agile potrzebujemy architektury, aby odnieść sukces?

Liang Que: Pracując w Agile zdecydowanie potrzebujemy architektury, przynajmniej z perspektywy jakości produktu. Jeśli rozejrzymy się dookoła i cofniemy się do wielu wcześniejszych projektów, to możemy zauważyć, że organizacje często przyjmowały następujące, odważne założenia:

• Zwinny zespół posiada wystarczającą wiedzę architektoniczną i potrafi właściwie zarządzać złożonymi zależnościami;
• Właściciel produktu i Scrum Master dbają nie tylko o funkcje, ale także o jakość systemu;
• Dobra architektura będzie ewoluować od sprintu do sprintu sama w sobie, bez poświęcania jej szczególnej uwagi;
• Decyzja architektoniczna może zostać podjęta w późniejszym czasie, podczas gdy zwinny zespół najpierw wypróbowuje różne podejścia.

Oczywiście, ludzie lubią wierzyć w powyższe założenia, ale one nie znajdują odzwierciedlenia w prawdziwym życiu. W rzeczywistości sprawy toczą się po przeciwnej stronie, tzn. właściciel produktu i Scrum Master są w stanie zarządzać jedynie postępami we wdrażaniu backlogów, ale nie zdają sobie sprawy z jakości systemu. Doprowadza to do nieoptymalnej realizacji projektu w perspektywie zarówno krótko jak i długoterminowej, powodując rozwój złego produktu z perspektywy jego jakości.

Obecnie projekty stają się coraz bardziej złożone z technologicznego punktu widzenia. Dlatego nie będą udane, trwałe i stabilne, jeżeli nikt w organizacji nie będzie dbał o ogólną jakość systemu i całościowego obrazu sytuacji.

AK: W jaki sposób praca z SAFe wspiera przemyślaną i dojrzałą architekturę korporacyjną oraz codzienną pracę architektów?

Liang Que: SAFe w rzeczywistości dotyka warstwy architektury korporacyjnej z odległej perspektywy. Po pierwsze, nakreśla, w jaki sposób architekci korporacyjni powinni codziennie współpracować z innymi kluczowymi interesariuszami, wykorzystując tablice Kanban i backlog (zobacz: SAFe "Lean-Agile Portfolio Management"). Po drugie, podkreśla integrację indywidualnego architekta korporacyjnego z cyklem życia produktu, np. strumień wartości i zwinny pociąg wydania (z ang. „release train”), zakorzeniony jest w zespołach zamiast siedzieć na wieży z kości słoniowej. Architekt korporacyjny powinien aktywnie współpracować z zespołem zarządzającym projektem / rozwiązaniami, architektami systemów by określić podstawy i zapewnić ogólną jakość systemu dla zespołów.

Z mojego doświadczenia wynika, że jedyną brakującą częścią SAFe w tym zakresie jest skalowanie architekta korporacyjnego w celu wsparcia wielu portfeli. Dla przykładu: prowadzę projekt zarządzania architekturą korporacyjną dla międzynarodowej grupy motoryzacyjnej poziomu 1, pomagając im określić przyszłą architekturę współpracy i model zarządzania, nie tylko w zakresie wdrażania, ale również w fazach utrzymania. Może to być dobre rozwinięcie architektury korporacyjnej w SAFe.

AK: Czy jest możliwe, że scentralizowana architektura na najwyższym poziomie organizacji SAFe będzie stanowić wąskie gardło dla jej rozwoju?

Liang Que: Zależy to od złożoności organizacji i odpowiednich produktów. Może stanowić wąskie gardło przy stosowaniu założeń SAFe do małych projektów, ale nie poprzez stosowanie ich do dużych projektów lub na poziomie przedsiębiorstwa. Dobrą praktyką rozróżniania tych dwóch różnych scenariuszy jest zdefiniowanie warstw architektury z ekonomicznego punktu widzenia. Na przykład (a) warstwa makro architektury dla rozwiązań strategicznych z celami długoterminowymi oraz (b) warstwa mikro architektury dla rozwiązań taktycznych z celami średnio- i krótkoterminowymi. W przypadku (a) scentralizowanej funkcji architektury z kompetencjami strategicznymi, bardziej istotne są uprawnienia wdrożeniowe (na przykład wstrzymanie trwającego projektu) oraz zarządzanie interesariuszami projektu. W przypadku (b) bardziej istotna jest zdecentralizowana funkcja architektury z kompetencjami w zakresie projektowania, techniki i rozwiązywania problemów. Z mojego punktu widzenia, duża zwinna organizacja bardzo często łączy obie powyższe praktyki w celu uzyskania dobrej równowagi pomiędzy szybkością dostarczania i jakością!