- Brawa na Sprint Review — 06/09/2024
- Kanban — Jak zacząć? — 30/08/2024
- Definicja Ukończenia kontra Kryteria Akceptacji — 26/08/2024
Skalowanie Scrum — jak zacząć?
Skalowanie Agile i Skalowanie Scrum już kilka lat temu były bardzo gorącym tematem na konferencjach zagranicą. Jest to spowodowane tym, że coraz większe firmy chciały wykorzystać podejście Agile do dużych większych inicjatyw. Wydaje się logiczne, że jeżeli teraz uruchamiany projekty na 50 i więcej osób, to w ramach transformacji do Agile powinniśmy robić to zwinnie. Na przykład BMW wykorzystuje Scrum do budowy autonomicznego samochodu, nad którym pracuje 1500 osób.
Potrzebujemy zatem sposobu na pracę dużej ilości osób w Agile, na przykład sposób na poukładanie pracy ośmiu zespołów w Scrum. Dzisiaj prosto z półki do wyboru mamy Nexus, LeSS, SAFe, Scrum at Scale i model Spotify. Nie musimy już wymyślać koła od nowa. Niezależnie od wyboru frameworka trzeba się zastanowić czy skalowanie ma sens w danym przypadku i trzeba się do tego bardzo dobrze przygotować, żeby nie zmarnować czasu kilkudziesięciu albo kilkuset osób oraz, żeby nie wypalać budżetu bez sensu. Prześledźmy kilka aspektów skalowania w odniesieniu do Scrum. Czyli w kontekście próby uruchomienia Nexus, LeSS lub Scrum at Scale.
Dobry powód do skalowania Scrum
Myślę, że pierwsze pytanie, które trzeba sobie zadać, to “Czym dla mnie jest skalowanie?”. Trzeba tutaj rozróżnić dwa aspekty, które mogą kryć się pod tym pojęciem. Chcemy przestawić cała organizację lub jej część na pracę zgodną z Agile, czy chcemy ustrukturyzować pracę większej ilości zespołów nad jednym produktem? To pierwsze to tak naprawdę transformacja do Agile, to drugie to skalowanie Scrum. Skalowanie Scrum zawsze oznacza pracę większej ilości zespołów nad jednym produktem.
Czy masz jeden konkretny, duży produkt, który wymaga równoległej pracy wielu zespołów? Przetransformowanie dużego projektu albo dużego programu na skalowany Scrum może oznaczać, że będzie więcej mniejszych zależnych od siebie produktów a nie jeden duży.
Drugie bardzo ważne pytanie brzmi Po co chcesz się skalować?. Czego oczekujesz od zwiększenia ilości zespołów? Niektórzy uważają, ze jest to naturalna droga zwiększenia dojrzałości implementacji Scrum. Wychodzi nam scrum, więc powinniśmy iść w skalowanie. To nie jest ani logiczny, ani dobry powód. Jeśli nie potrzebujesz przyspieszać, jeśli produkt nie rozrasta się bardzo szybko, zostań przy Scrum na poziomie zespołu i nie zwiększaj złożoności. Dokładanie zespołów powoduje zwiększenie złożoności pracy i tworzy potrzebę zarządzenia dodatkową złożonością przez framework skalowania.
Czy zależy Ci na szybszym albo bardziej pewnym osiągnięciu konkretnej daty? Czy funkcjonalności w różnych obszarach produktu muszą być dostarczane razem równocześnie? Output zespołów mierzony przez Velocity nie rośnie proporcjonalnie do ilości zespołów. Dlaczego użyłem tutaj słowa output a nie produktywność? Bo na razie nie rozmawiamy o tym na ile praca zespołów jest wartościowa, tylko o tym ile elementów Done możemy mieć na koniec Sprintu.
Tutaj ma zastosowanie ta sama zasada jak w przypadku zwiększania ilości osób w zespole. Dziewięć zespołów nie dostarczy dziewięć razy więcej w tym samym czasie. Zależności i komunikacja pomiędzy zespołami spowodują, że niedość, że output nie będzie rosnąć prostoliniowo, to w pewnym momencie może zacząć nawet spadać. Znane są przypadki gdzie zmniejszenie ilości osób zaangażowanych w pracę spowodowało zwiększenie wydajności. Jest wiele sposobów na zwiększenie wydajności, produktywności, wartości dostarczanej przez pojedynczy zespół pracujący w Scrum.
Obojętnie jaki jest Twój powód do skalowania, dobrą praktyką jest wiedzieć co chcesz osiągnąć i umieć to zmierzyć. Wtedy będziesz widzieć czy dokładanie zespołów ma sens i czy w ogóle jest opłacalne. Skalowanie to zwiększe kosztu, trzeba więc sprawdzić czy to oznacza też zwiększenie przychodu albo zmniejszenie ryzyka biznesowego.
Strategia Skalowania Scrum
Ile zespołów potrzebujesz? Jeśli potrzebujesz dwóch lub trzech zespołów Scrum, to może nie potrzebujesz korzystać z dodatkowego frameworka. Pamiętaj, że frameworki skalowania do dodatkowy narzut procesowy. Może wystarczy wspólna definicja Done, dobrze zarządzany Product Backlog i synchronizacja między zespołami w trakcie Sprintu? W skalowaniu Scrum obowiązuje zasada Może być tylko jeden, która pomaga uspójnić pracę. Może przy trzech nie warto sięgać po framework? Czy chcesz zacząć z jednym, z kilkoma, czy z wszystkimi zespołami na raz? Oczywiście rozpoczęcie pracy z wszystkimi zespołami na raz jest najmniej optymalne, bo powoduje największą złożoność i chaos organizacyjny od razu na starcie. Bardzo szybko system będzie dążył do lokalnej optymalizacji i tworzył kolejne trudne do rozwiązania później dysfunkcje, byle praca jakoś szła do przodu.
Lepszym rozwiązaniem jest wystartowanie z mniejszą ilością zespołów, stworzenie spójnego systemu, wypracowanie podstawowych praktyk i stopniowe dokładanie zespołów. Łatwiej też wtedy zaobserwować czy skalowanie daje nam korzyści, których oczekujemy.
Weźmy za przykład popularne przeszkody, które można zaobserwować w wielu organizacjach. Product Owner nie ma czasu dla zespołu. Co stanie się, kiedy zwiększysz ilość zespołów? Będzie miał jeszcze mniej czasu i zespoły będą marnowały Sprinty. Środowiska testowe są niestabilne. Co stanie się, kiedy zwiększysz ilość zespołów? Środowiska będą jeszcze bardziej niestabilne. Mamy za mało osób z określoną kompetencją i przez to są przydzielone do dwóch zespołów w niepełnym wymiarze czasu. Co stanie się, kiedy zwiększysz ilość zespołów? Takie osoby bedą przydzielone do jeszcze większej ilości zespołów i przez efekt przełączania kontekstu ich osobista produktywność bardziej zbliży się do zera. Mamy zależności zewnętrzne (typowa zależność to wspólna szyna danych). Co stanie się, kiedy zwiększysz ilość zespołów? Jeszcze więcej elementów będzie czekało jeszcze dłużej na rozwiązanie zależności zewnętrznych. Brak decyzyjności, długie oczekiwanie na decyzje? Sam się domyślisz.
Najpierw dobry Scrum, póżniej skalowanie
Skalowanie Scrum może zwiększyć output z zespołów, ale to co na pewno zwiększy, to rozmiar Twoich problemów z implementacją Scrum. Jeśli teraz masz zidentyfikowane, nie rozwiązane przeszkody (impedimenty), to skalowanie spowoduje jedynie zwiększenie problemów, które powodują. Jeśli pojedynczy zespół nie jest w stanie dostarczyć Done przyrostu co Sprint, to zwiększenie ilości zespołów zwiększy szanse na to, że nigdy nie będziesz miał stabilnej, działającej wersji. Jeśli organizacja nie rozumie Scrum i nie jest zwinna to praca większej ilości zespołów będzie jeszcze trudniejsza. Na ile Twoja implementacja Scrum jest dobra?
Dobre zrozumienie produktu
Zrozumienie produktu w Zespole Deweloperskim jest niezwykle ważne i równie nie zrozumiałe w wielu organizacjach. Podejście, że Developer to programista, który ma zakodować to, co mu analityk podsunie nie sprawdza się w Scrum. Developer powinien rozumieć produkt, umieć go zaprojektować i zbudować. Na ile Zespoły Developerskie rozumieją co budują?
Kiedy mamy więcej Zespołów Deweloperskich wiedza o produkcie może stać się wąskim gardłem. Jeśli przy każdej User Story będą pojawiały się pytania do Product Ownera, to skalowanie się nie uda. Jeśli teraz 9 osób musi chodzić co chwile (o ile ma taką inicjatywę) do Product Ownera, to wyobraź sobie ponad 30 osób chodzących to niego z różnymi pytaniami. Product Owner nie będzie miał czasu na nic innego. Gdzie zarządzanie Product Backlog, gdzie współpraca z interesariuszami?
Product Owner powinień mieć jasną wizję, znać dobrze cele biznesowe, które chce osiągnąć i umieć przekazywać tą informację do zespołów. Zespoły powinny wracać z pytaniami “Mamy dwie opcje, którą wolisz? Mamy taką propozycję, czy to jest ok”
Architektura i Infrastruktura wspierająca skalowanie Scrum
Kluczem do sukcesu i jednocześnie najlepszym wskaźnikiem czy skalowanie działa jest zintegrowany produkt. Czy masz środowisko, na którym Zespoły Deweloperskie mogą się integrować kiedy chcą? Potrzebna jest architektura, która umożliwia niezależną pracę na wielu obszarach sytemu. Dobrą praktyką jest korzystanie z mikroserwisów, co jest trudniejsze niż się wydaje. Ale to już temat na innego posta. Możliwe, że potrzebne będzie podejście umożliwiające wydawanie niepełnych funkcjonalności w stanie wyłączonym, albo testy A/B. Jedynym dobrym sposobem sprawdzenia jak nam idzie jest zintegrowanie tego co poszczególne zespoły zbudowały. Można powiedzieć, że bez ciągłej integracji nie da się robić skalowania. Może potrzebne będzie testowanie wielu wersji, wiele niezależnych środowisk dla zespołów? Amazon, Azure, prywatna chmura?
Czy znasz tą sytuację, kiedy zatrudniasz ludzi, przychodzą do pracy i czekają na wejściówki, laptopy i dostępy przez kilka tygodni? 50 osób na ławce czekających na infrastrukturę to duża strata pieniędzy.
Czy zespoły pracujące nad jednym produktem będą kolokowane — siedziały razem? Masz taką przestrzeń?
Silne Definition of Done
Transparencja związana nieodzownie ze scrum jest czasem bardzo brutalna. Mówisz, że robisz dobre postępy? Pokaż Przyrost Produktu. Przyrost Produktu musi być ukończony zgodnie z Definition of Done. Definition of Done powinna reprezentować stan gotowy do wdrożenia. Jeśli nie możesz osiągnąć potencjalnie gotowego do wdrożenia stanu, stwórz Product Backlog Items na tą pracę i zrób ją kiedy będziesz chciał się wdrożyć. Czy masz silną Definition of Done, której przestrzegasz?
Przy integracji produktu przez wielu zespołów Definition of Done jest niezwykle ważna. Złożoność pracy wzrasta i jeśli nie jesteśmy w stanie powiedzieć, czy mamy Done, zintegrowany Przyrost Produktu, to nic nie wiemy. Jakość produktu jest tak niska jak najniższa Definition of Done. Mamy ogromne ryzyko narastającego długu technicznego i pracy undone. Odkładanie tej pracy na później nie jest dobrym pomysłem, bo doprowadzimy szybko do stanu, w którym nic nie będzie działało i trzeba będzie przepisać całość produktu. Stworzenie zespołu odpowiedzialnego za integrowanie pracy dziewięciu innych zespołów nie jest dobrym rozwiązaniem. Taki zespół szybko stanie się wąskim gardłem a Cycle Time poszybuje do góry. Zespoły idące do przodu też niechętnie wracają do poprawiania czegoś co oddali Sprint, dwa Sprinty temu. Trzeba integrować, testować na bieżąco i trzymać się jednej, wspólnej Definition o Done.
Mierniki Skalowania Scrum
Po czym poznasz czy Skalowanie Scrum przynosi odpowiednie efekty? Jeśli masz nieograniczony budżet, to możesz pozwolić sobie na wiele rzeczy. Jeśli nie, lepiej mierzyć i wiedzieć jak idzie. Czy skalowanie się opłaca? Ile zespołów to maksimum? Kiedy możemy się wdrożyć? Kiedy i ile zarabiamy na produkcie? Jaki mamy time to market? Ile wartości dostarczamy? Jaki mamy poziom jakości? Jak szybko reagujemy na błędy? Jak wygląda Product Backlog — rośnie, maleje, ilość zmian?
Podsumowanie
Skalowanie Scrum to nie zawsze dobre wyjście. Mamy Nexus, LeSS, Scrum at Scale do wyboru. Zanim zaczniesz skalować, sprawdź kilka rzeczy.
- Czym dla mnie jest skalowanie?
- Po co chcesz się skalować?
- Czy masz jeden konkretny, duży produkt, który wymaga równoległej pracy wielu zespołów?
- Ile zespołów potrzebujesz?
- Czy chcesz zacząć z jednym, z kilkoma, czy z wszystkimi zespołami na raz?
- Na ile Twoja implementacja Scrum jest dobra?
- Na ile Zespoły Develperskie rozumieją co budują?
- Czy masz środowisko, na którym Zespoły Deweloperskie mogą się integrować kiedy chcą?
- Czy masz silną Definition of Done, której przestrzegasz?
- Po czym poznasz czy Skalowanie Scrum przynosi odpowiednie efekty?
Trackbacks/Pingbacks