Skalowanie Agile: Frameworki i wskazówki eksperta

Podsumowanie
Gdy organizacje zdają sobie sprawę, że zwinna praca może ogromnie wpływać na time-to-market, satysfakcję klientów i zaangażowanie pracowników – wśród wielu innych aspektów – zaczynają myśleć o skalowaniu zwinności.

Panuje błędne przekonanie, że jeśli jesteś dużą organizacją, potrzebujesz podejścia do skalowania. Niekoniecznie jest to prawdą, ponieważ skalowanie jest przede wszystkim istotne dla przypadków, gdy produkt jest zbyt duży, by mógł go rozwijać mały zespół.

Jak dzielić produkty i czy w ogóle skalować – to prawdopodobnie ważniejsze pytania niż to, jaki framework do skalowania wybrać. Niestety zbyt mało organizacji zadaje te pytania – być może z powodu dużego nacisku frameworków skalowania ze strony konsultantów.

Jeśli organizacja musi skalować, istnieje wiele frameworków do wyboru, wśród nich SAFe, LeSS, Scrum@Scale i kilka innych. Żaden z tych frameworków nie powinien być jednak stosowany „z pudełka".

Jesteśmy głęboko przekonani, że organizacje powinny czerpać inspirację z tych frameworków, ale zamiast je kopiować, powinny kierować się zestawem zasad takich jak decentralizacja podejmowania decyzji, lean thinking i empiryzm wraz z ciągłym doskonaleniem.

Aby każdy rodzaj zmiany mógł odnieść sukces – w tym skalowanie zwinnych sposobów pracy – niezbędne jest, by menedżerowie dostosowali swoje podejście do pracy. Dla większości z nich oznacza to przejście od pracy w organizacji do pracy nad organizacją.

Głównym celem staje się upełnomocnianie (umożliwianie podejmowania decyzji) i enabling (budowanie kompetencji do podejmowania decyzji) zespołów i osób. Aby to się udało, menedżerowie/liderzy muszą zacząć zmieniać struktury, polityki i metryki swojej organizacji, a także systematycznie rozwijać swoje zespoły i ich członków.

Wprowadzenie do skalowania zwinnych sposobów pracy

W niemal każdym warsztacie, który prowadzę, uczestnicy pytają mnie, jak skalować Scrum lub zwinne zespoły. Powodem jest to, że w ich organizacjach rzadko pracuje zaledwie 10 osób – zwykle jest ich znacznie więcej.

Wielu z nich pochodzi z dużych korporacji – z sektora finansowego, motoryzacyjnego, farmaceutycznego czy medtech. W wielu dużych korporacjach mają duże produkty, np. samochód, przy którym pracuje wiele, czyli setki osób.

Błędne przekonanie polega na tym, że duża liczba osób automatycznie skutkuje potrzebą podejścia do skalowania. Tak nie musi być. Organizacja może mieć wiele osób i wiele zespołów, ale dopóki każdy z tych zespołów pracuje nad indywidualnym produktem, niekoniecznie musi skalować – przynajmniej w tradycyjnym znaczeniu, w jakim używamy tego terminu.

Co oznacza skalowanie agile?

Skalowanie agile staje się istotne, gdy nad tym samym produktem pracuje więcej niż jeden zespół. Warto to podkreślić: wiele zespołów pracuje nad tym samym produktem. Aby więc stwierdzić, czy potrzebujesz podejścia do skalowania, należy najpierw przyjrzeć się definicji produktu.

Jak można zdefiniować produkt?

Istnieje wiele sposobów podejścia do tego. Jednym jest perspektywa klienta. Co moi klienci uważają za produkt, tzn. za co są gotowi zapłacić, np. Microsoft Office?

Inna perspektywa jest bardziej wewnętrzna: jakie są różne komponenty produktu, które możemy rozwijać w dużej mierze niezależnie, np. Microsoft Excel lub funkcje w Excelu.

Perspektywa, którą przyjmuje wiele organizacji, nie jest ani jedną, ani drugą. Znacznie chętniej patrzą na różne architektoniczne elementy produktu i dzielą zespoły na tej podstawie. Takie podejście prowadzi zazwyczaj do silosów i wielu zależności między zespołami.

Druga opcja może w wielu przypadkach skutkować wieloma małymi zespołami pracującymi w dużej mierze niezależnie, więc formalny podejście do skalowania nie będzie potrzebne. Ale nawet gdyby było potrzebne, koordynacja poszczególnych zespołów i pracy cross-teamowej jest o wiele łatwiejsza, gdy granice produktów są jasno zdefiniowane.

Jak skalujemy?

Dalej w tym artykule podsumujemy najczęstsze podejścia do skalowania. Ale zanim do tego dojdziemy, chcielibyśmy ocenić kwestię, jak skalować i jakie zasady mogą pomóc nam skalować lepiej.

Każdy zwinny zespół, np. Scrum Team, ma trzy odrębne odpowiedzialności: Co budujemy? Jak to budujemy (technicznie)? Jak współpracujemy (metodologia)? Największą różnicą między różnymi podejściami do skalowania jest to, czy skalują całą jednostkę, czyli Scrum Team ze wszystkimi jego odpowiedzialnościami, czy skalują tylko odpowiedzialności Jak.

To rozróżnienie jest ważne, bo bezpośrednio odnosi się do jednej z kluczowych zasad zwinności, jaką jest decentralizacja podejmowania decyzji do miejsca, gdzie odbywa się praca i interakcja z klientem. Jest też ważne, bo determinuje, ile nowych ról jest tworzonych i jaką rolę pełni przywództwo poza tymi zespołami.

Jakie istnieją typy frameworków do skalowania agile?

Istnieje wiele sposobów skalowania zwinnego wytwarzania w organizacji. Żadne z tych podejść nie obejmuje w całości tego, jak powinna być zorganizowana organizacja. Zazwyczaj dotyczą jedynie jednostki wytwarzania produktów w organizacji.

Wszystkie jednostki wspierające w organizacji, takie jak Finanse, Prawo, HR, Zakupy, nie są objęte żadnym frameworkiem skalowania. Choć niektórzy – w tym konsultanci, którzy sprzedają te frameworki – twierdzą, że tak jest, to naprawdę nie jest prawdą.

W poniższej sekcji zamierzamy podzielić się ogólnym przeglądem najczęściej używanych frameworków skalowania. Należy jednak pamiętać, że „najczęściej używany" nie oznacza „najlepszy". Jesteśmy głęboko przekonani, że każdy z tych frameworków ma pewne wyraźne zalety, ale też istotne wady.

Lepsze niż zwykłe skopiowanie jednego z frameworków jest zrozumienie kluczowych zasad skalowania zwinnego wytwarzania i stworzenie w organizacji czegoś, co stale ewoluuje w oparciu o regularne i częste inspekcje i adaptacje. Każda organizacja jest wyjątkowa pod względem kultury i wyzwań… twój sposób pracy powinien to odzwierciedlać.

Scaled Agile Framework (SAFe)

Scaled Agile Framework – znany również jako SAFe – to prawdopodobnie najlepiej udokumentowany framework do skalowania zwinności. Został stworzony przez Deana Leffingwella i jest regularnie aktualizowany.

SAFe jest też prawdopodobnie najbardziej preskryptywny ze wszystkich frameworków skalowania. Być może dlatego wiele dużych organizacji rozpoczyna swoją podróż skalowania właśnie od SAFe. Jak wspomniano wcześniej, nie oznacza to koniecznie, że SAFe powinno być frameworkiem z wyboru. Właściwie jeszcze nie widziałem udanej implementacji SAFe.

SAFe przyjmuje perspektywę team-of-teams, którą określa jako Agile Release Train (ART). ART opiera się na wielu Scrum lub Kanban lub innych zwinnych zespołach. Na poziomie zespołu są Product Ownerzy, Scrum Masterzy i deweloperzy. Na poziomie ART istnieją podobne role o nazwach Product Management, Release Train Engineer (RTE) i System Architect/Engineer.

Oznacza to, że SAFe skaluje całą jednostkę Scrum Teamu łącznie z odpowiedzialnościami Co, które spoczywają wtedy na Product Managemencie. Rodzi to poważne wyzwania, bo Product Owner w SAFe nie jest tym samym co Product Owner w Scrum. Product Owner w SAFe to głównie osoba, która uszczegóławia Backlog na poziomie zespołu – czego już właściwie nie można nazywać Product Backlogiem.

Jedną z kluczowych zalet SAFe jest to, że organizacje wykazują mniejszy opór przy przejściu na SAFe niż przy jakimkolwiek innym frameworku – przynajmniej takie mam doświadczenie. To może być dobre, bo prowadzi do tego, że organizacje robią pierwszy krok w kierunku zmiany. Może też być złe, jeśli uważają, że implementacja SAFe jest już celem.

Jedną z najważniejszych rzeczy do zapamiętania jest to, że im bardziej podejście do skalowania jest podobne do obecnej struktury organizacyjnej, polityk i metryk, tym mniej doprowadzi do osiągnięcia innych wyników. Wdrożenie SAFe jest więc prawdopodobnie łatwiejsze niż wdrożenie niektórych innych frameworków, ale najprawdopodobniej też nie przybliży cię do osiągnięcia celów.

Large Scale Scrum (LeSS)

Large Scale Scrum – znany również jako LeSS – to kolejne często stosowane podejście do skalowania. LeSS zostało stworzone przez Craiga Larmana i Basa Voddego. Obaj są bardzo doświadczonymi osobami i myślicielami systemowymi. Obaj mają też wyraźne opinie.

W porównaniu z SAFe, LeSS skaluje jedynie części Jak Scrum Teamu, czyli deweloperów i w pewnym stopniu Scrum Mastera. LeSS w swojej najprostszej formie nie tworzy hierarchii Product Ownerów. Oznacza to, że Product Owner w LeSS jest naprawdę Product Ownerem (w rozumieniu Scruma) i pracuje z wieloma zespołami, by osiągać cele produktu.

W oparciu o tę definicję Product Owner w LeSS potrzebuje bardzo dojrzałych zespołów. Dojrzałych w rozumieniu klienta, dojrzałych w rozumieniu, jak rozkładać elementy Product Backlogu, i dojrzałych pod względem bliskiej współpracy z interesariuszami.

W porównaniu z nieskalowanym Scrum Teamem, gdzie zazwyczaj Product Owner wykonuje większość Product Backlog Refinementu, interakcji z klientem i zarządzania interesariuszami, w LeSS nie byłoby wystarczająco czasu dla jednej osoby, by robić to dla wszystkich jej zespołów.

Jako duży fan piłki nożnej (soccer) często używam analogii z tego świata w rozmowach z klientami. Wdrożenie LeSS jest jak gra w Lidze Mistrzów. Nie powinien tego robić ktoś, kto nie zademonstrował już świetnej implementacji Scruma.

W porównaniu z SAFe, LeSS usuwa wiele biurokracji dużych organizacji, a wraz z nią wiele warstw zarządzania. Dla wielu osób samo patrzenie na to wydaje się niekomfortowe, nie mówiąc o stosowaniu.

Wdrożenie LeSS nie jest łatwe i w porównaniu z tym, co twierdzą inne frameworki, LeSS prawdopodobnie wymaga największej zmiany w sposobie, w jaki menedżerowie przewodzą, a także wymaga największego skupienia, energii i czasu w rozwijaniu ludzi. Przejście od zespołów komponentowych do zespołów funkcjonalnych to tylko jeden z wielu przykładów.

Nie oznacza to, że LeSS jest zły. Gdybym musiał wybrać jeden z tych frameworków dla swojej organizacji lub klientów, wybrałbym prawdopodobnie LeSS. Ale LeSS wymaga też największego zaangażowania ze strony wyższego kierownictwa i najwięcej czasu na przygotowanie zespołów. Prawdopodobnie też przyniesie najbardziej znaczące wyniki.

Dla inicjatyw wytwarzania produktów wymagających więcej niż 8 zespołów, LeSS ma dedykowaną konfigurację o nazwie LeSS Huge. Jedyna różnica polega na tym, że LeSS skaluje teraz też rolę Product Ownera. Nadal jest jeden Product Owner, ale dla różnych obszarów istnieją tzw. Area Product Ownerzy.

Scrum@Scale

Scrum@Scale zostało stworzone przez Dr. Jeffa Sutherlanda, jednego ze współtwórców Scruma. Podobnie jak SAFe, Scrum@Scale skaluje całą jednostkę zespołu, czyli Co i Jak.

Poziom powyżej Scrum Teamu ma Chief Product Ownera i Scrum of Scrums Mastera. Istnieje cykl Product Ownera prowadzący do Executive Meta Scrum (EMS) i cykl Scrum Mastera prowadzący do Executive Action Team (EAT).

Podobnie jak LeSS, Scrum@Scale kładzie duży nacisk na decentralizację podejmowania decyzji do zespołów. Jeff Sutherland sam jest wielkim promotorem tego, by Product Owner był odpowiedzialny za tworzenie wartości dla klientów, a nie tylko za pracę nad Backlogiem.

Przewodnik Scrum@Scale całkiem dobrze dokumentuje, jak framework zasadniczo działa. Od czasu do czasu robi się nieco kryptyczny, ale fundamentem jest to, że Scrum@Scale to fraktalne podejście do skalowania działających Scrum Teamów. Dlatego też nie powinien być punktem wejścia dla żadnej organizacji. To właściwie można powiedzieć o wszystkich frameworkach skalowania.

Nexus

Nexus zostało stworzone przez drugiego współtwórcę Scruma, Kena Schwabersa. Jako framework wydaje się być bardzo bliskie LeSS, choć istnieje jedna wyraźna różnica: Nexus Integration Team. Poza tym Nexus – podobnie jak LeSS – skaluje przede wszystkim odpowiedzialności Jak, zachowując jednego Product Ownera.

Disciplined Agile Delivery (DAD)

Disciplined Agile Delivery – znane również jako DAD – zostało stworzone przez Scotta Amblera i Marka Linesa. Nie jestem ekspertem w DAD i – mimo pracy z wieloma organizacjami – nigdy nie widziałem jego zastosowania w prawdziwym życiu. Nie oznacza to, że DAD nie jest stosowany i że nie działa, oznacza jedynie, że ja go nie widziałem.

Model Spotify

To ciekawy przypadek. Główni ludzie stojący za Modelem Spotify – jednym z nich jest mój przyjaciel Henrik Kniberg – mówią, że nie ma Modelu Spotify. Mimo to wiele dużych firm konsultingowych sprzedaje to swoim klientom. Mówią o Tribes, Squadach i Gildach, choć większość z nich (właściwie wszyscy) nigdy nie postawiła nogi w Spotify, by zobaczyć, czy i jak ten „model" działa.

Model Spotify brzmi fajnie i cool – Spotify jest przecież fajną i cool firmą. Ale czy ten model skandynawskiego startupu streamingowego – nawet gdyby istniał – naprawdę pasuje do niemieckiej firmy telekomunikacyjnej, szwajcarskiego koncernu farmaceutycznego lub amerykackiego ubezpieczyciela? Osobiście bardzo w to wątpię.

Na szczęście nikt w Spotify nie twierdzi, że ten model można stosować powszechnie… właściwie nie twierdzą nawet, że działa w Spotify. Jeśli uważnie posłuchasz, co Henrik mówi w swoich filmach o kulturze inżynieryjnej Spotify, usłyszysz, jak mówi, że to wszystko brzmi wspaniale, ale w Spotify wciąż mają mnóstwo problemów i stale ulepszają sposób pracy. Nie ma więc jednego modelu w Spotify… są tylko migawki.

Jak możesz skalować agile w swojej organizacji?

Współpracując z organizacjami, naszym celem jest pomoc w zrozumieniu, że choć mogą czerpać wiele spostrzeżeń i inspiracji z różnych frameworków skalowania, najważniejsze jest zrozumienie kilku podstawowych zasad skalowania zwinnego wytwarzania produktów, a następnie stałe rozwijanie organizacji w kierunku tych zasad.

Niektóre z kluczowych zasad, na które zwracamy uwagę, to następujące:
Nie skaluj, jeśli nie musisz – zanim zaczniesz myśleć o skalowaniu, sprawdź, czy możesz podzielić swój produkt w taki sposób, by małe jednostki mogły pracować nad nim niezależnie, co sprawi, że skalowanie będzie nieistotne
Każdy zespół i team-of-teams są zorganizowane tak, by idealnie dostarczały wartość klientom i były skoncentrowane na kliencie
Stosuj lean thinking – redukuj marnotrawstwo przez ograniczanie work-in-progress, rygorystyczne prototypowanie (discovery) i częste informacje zwrotne od klientów
Ciągle poprawiaj sposób pracy przez regularne i częste retrospektywy zespołowe i cross-teamowe
Decentralizuj podejmowanie decyzji tak bardzo, jak to możliwe, tworząc klarowność i rozwijając kompetencje w zespołach
Przyjmij niepewność i stwórz nastawienie empiryczne zarówno dla tego, Co jest budowane, jak i dla tego, Jak rzeczy są budowane

Ta lista nie jest w żadnym razie wyczerpująca. Ale jeśli organizacja i jej team liderski wezmą sobie te zasady do serca, widzieliśmy, jak ogromnie poprawiają zwinność organizacyjną, w tym satysfakcję klientów i zaangażowanie pracowników.

Co liderzy muszą wiedzieć o skalowaniu agile?

W zbyt wielu przypadkach widziałem liderów/menedżerów, którzy wierzą, że gdy organizacja przechodzi w kierunku zwinności, nie są już potrzebni. To jeden z powodów, dla których wielu menedżerów opiera się inicjatywom zmian organizacyjnych – strach przed utratą statusu lub nawet pracy.

Uważam, że żadna zmiana organizacyjna nie zajdzie bez zarządzania – zarówno wyższego, jak i średniego szczebla. To właśnie te grupy pracują nad organizacją, w odróżnieniu od wszystkich pozostałych, którzy pracują głównie w organizacji.

Sama organizacja jest jak produkt. Musi być rozwijana. Biorąc pod uwagę szybko zmieniające się środowisko większości organizacji, jestem głęboko przekonany, że każda organizacja – podobnie jak większość produktów – jest work in progress, tzn. musi być stale doskonalona. To jest zadanie menedżerów/liderów w organizacjach.

Dla większości liderów oznacza to, że ich praca znacząco się zmienia. Dla tych, którzy micromanagowali swoje zespoły, oznacza to upełnomocnianie i enabling zespołów, by podejmowały coraz więcej decyzji. Dla tych, którzy byli bezpośrednio zaangażowani w decyzje dotyczące produktu, oznacza to konieczność zdecydowania, czy chcą pozostać w roli skoncentrowanej na produkcie, czy przejść do roli w zakresie rozwoju organizacyjnego. W każdym przypadku większość menedżerów/liderów musi dostosować to, co robią i jak to robią, tzn. większość musi przejść przez osobistą podróż agile leadera.

W oparciu o nasze doświadczenie, naprawdę pomocne jest posiadanie modelu, który pomaga systematycznie strukturyzować osobistą podróż i przechodzić przez nią krok po kroku z pomocą świetnego coacha. Jeśli chcesz dowiedzieć się więcej, jak to może wyglądać, zajrzyj do naszej oferty Certified Agile Leadership.