Zespoły programistyczne powszechnie udowodniły, iż wdrożenie zwinnych frameworków, takich jak scrum i kanban, pozwala dostarczać rozwiązania klientom szybciej, z większą przewidywalnością oraz daje możliwość szybkiego reagowania na podstawie nowych informacji. Metodyka scrum w obrębie indywidualnego zespołu daje jasne korzyści, a jej wdrożenie jest stosunkowo łatwe. Prawdziwym wyzwaniem okazuje się rozszerzenie go w obrębie struktury w dużej organizacji. Innymi słowy, wdrażanie agile na dużą skalę.
SAFe
W chwili obecnej istnieje niewielka liczba metodologii agile dedykowanych dużym przedsiębiorstwom. Najpopularniejszymi rozwiązaniami są SAFe i Scrum of Scrums. Podejście SAFe tworzy wspólne środowisko dla zespołów agile oraz odgórnych procesów decyzyjnych. SAFe promuje podstawowe wartości upodmiotowienia i decentralizacji kontroli, ale nie całkowitą decentralizację. Tradycyjne modele scentralizowanego planowania programów i zarządzania mikrotechnicznego stały się przeszłością. Dodanie większej liczby osób do pracy przy tym samym zadaniu tylko utrudnia jego zrealizowanie. Ale jeżeli znajdziemy sposób, aby stać się bardziej skutecznym w miarę rozwoju, to jest to właśnie skalowanie.
Scrum of Scrums
Scrum of Scrum jest znacznie innym frameworkiem. Opiera się na pojęciu scrum – praktyce dzielenia rozwoju na niewielkie iteracje lub sprinty, dzięki czemu zespół może zadbać o jakość każdego aspektu pracy. Jednak gdy teamów scrumowych jest wiele, pojawia się potrzeba stworzenia zbiorowej ramy zarządzania, a tym właśnie jest Scrum of Scrums. Jest on szczególnie skuteczny, gdy wszyscy wysokowydajni(-e) członkowie(-inie) grup pracują nad wspólnym celem oraz mają wobec siebie zaufanie. Scrum of Scrums to skalowalna zwinna technika łączenia wielu zespołów w wydajną strukturę.
Scrum of Scrums – zasady skalowania
Przewodnik Scrum definiuje zasady implementacji metodologii scrum w niewielkich zespołach. Jej skalowanie wymaga innego podejścia. Odpowiedzią na tę potrzebę jest metodyka Scrum of Scrums – czasami określana jako SoS, która pomaga opracowywać i dostarczać złożone produkty poprzez przejrzystość, inspekcję i adaptację na dużą skalę. Zbyt małe lub duże zespoły mogą mieć problemy z dostarczaniem złożonych produktów. Podział dużego teamu na dwa lub trzy mniejsze, może pomóc w rozwijaniu osobistych relacji i utrzymaniu pożądanych wyników.
Metodyka scrum i jej wyzwania
Niezbędne jest zrównoważenie umiejętności jednostek, przedefiniowanie ustalonych interfejsów i staranne rozdzielenie obowiązków służbowych. Z czasem mogą wystąpić nieoczekiwane zależności i potencjalne nowe „wąskie gardła”, które spowalniają produkcję. Silny nacisk na retrospektywy i ustalanie priorytetów historii usprawnień pomoże przezwyciężyć te wyzwania.
Wirtualność SoS
Scrum of Scrums to wirtualny team składający się z delegatów z wbudowanymi łączami do pierwotnych zespołów dostarczających. W porównaniu z typowymi hierarchiami organizacyjnymi lub zespołami projektowymi te powiązane struktury redukują liczbę ścieżek komunikacji. Celem jest koordynacja mniejszych, niezależnych zespołów. Grupy stosujące Scrum of Scrums, nie tylko troszczą się o dostępność dostaw, ale zapewniają w pełni zintegrowany produkt na koniec każdego sprintu, czyli dostarczają wartość klientom. Nowo utworzony SoS stosuje niemal te same praktyki, uczestniczy w tych samych wydarzeniach i pełni te same role, co zespół scrumowy. Zdarza się, iż powodzenie projektu wymaga zaangażowania dodatkowych ról, takich jak architekci(-tki) lub liderzy(-ki) ds. zapewnienia jakości.
Scrum of Scrums Master
Stosunkowo nową rolą w strukturach projektowych jest Scrum of Scrums Master, który powinien skoncentrować się na postępach, zaległościach i utrudnieniach, również tych międzyzespołowych. Ustala on zatem priorytety, usuwa utrudnienia oraz stale optymalizuje SoS.
Metodyka scrum – dobre praktyki
Formując zespół Scrum w dużej korporacji, pamiętajmy o kilku złotych zasadach:
- Do zespołu Scrum nie powinniśmy wybierać wyłącznie osób, które będą dążyć do osiągnięcia sukcesu za wszelką cenę. gwałtownie okaże się, iż część mniejszych „żółtych flag” zostanie zbagatelizowana i wrócą jako ryzyka lub realne problemy.
- Zespół Scrum powinien być dedykowany w 100% do pracy w tym trybie pracy, więc nie nominujmy osób, które będą pracować jednoczenie w 5 innych projektach.
- Właściciel(-ka) produktu to krytyczna osoba dla sukcesu teamu, gdyż to on(a) musi określić potrzeby potencjalnych odbiorców i na tej podstawie stworzyć oraz wykreować produkt lub usługę.
- Upewnijmy się, iż Scrum Master(-ka) i Właściciel(-ka) produktu to dwie różne osoby. Każdy z nich ma inny cel i zakres. Właściciel(-ka) produktu bardziej skupia się na pracy z klientem, a Scrum Master(-ka) powinien(-na) skupić się koordynowaniu zadań wewnątrz Scrum teamu.
- Warto uzgodnić zbiorczą i indywidualną definicję wypełnionego celu, co pomoże członkom i członkiniom zespołu zapewnić większą przejrzystość wkładu w organizację czy zbudować wspólne wyobrażenie o tym, jak będzie wyglądać gotowy projekt.
- Powinniśmy bezwzględnie śledzić liczbę dni, podczas których jesteśmy czymś zablokowani. Scrum team powinien się koncentrować się na priorytetowym dostarczaniu wymagań, które mają najwięcej zależności, aby zmniejszyć ryzyko i umożliwić pracę innym zespołom.
Realnie o scrum w dużych organizacjach
Celem implementacji Scrum of Scrum w korporacjach jest zminimalizowanie ryzyka niedotrzymania terminów i minięcia się z celem. Metodyka scrum ta ma dawać poczucie kontroli i bezpieczeństwa zarządzającym działem/firmą/produktem. Niestety, bywa, iż sprinty planowane są zgodnie z terminem np. regulacyjnym czy biznesowym. Właściciel(ka) Produktu dyktuje, co zespół ma dostarczyć w kolejnym wdrożeniu, natomiast Scrum Master(ka) dba o ustalenie ról, zależności i dopilnowuje dotrzymywania terminów. Wytwarzanie systemu należy do zadań typu założonego i zawsze może pojawić się niespodziewane ryzyko. Scrum Masterzy(-ki) powinni skupić na wytwarzanej wartości, jeżeli to możliwe uprościć architekturę, dać więcej możliwości na elastyczne układanie pracy w strukturze.
Niejawne ograniczenia metodyki scrum
Metodyka scrum sama w sobie, niejawnie, wymaga bardzo doświadczonego zespołu. Dobrze się sprawdza w środowisku mieszanym. Zespół samych seniorów wcale nie jest najlepszy na dłuższą metę. Scrum w korporacji odbiega od tzw. projektów typu start up, z budżetem od inwestora i programistami kodującymi do czasu wyczerpania zasobów finansowych. Tymczasem w typowej korporacji mamy np. 200 kluczowych aplikacji i kombinacje ich zależności, znamy zakres i zwykle narzucony termin. Scrum team musi tymi zależnościami zarządzać oraz być odpowiednio wyskalowany, aby dotrzymywać terminów.
Recepta na metodykę scrum w korporacji
Sytuacja geopolityczna czy obecny kryzys energetyczny pokazują, iż adekwatnie nie ma czegoś takiego jak pewny zakres projektu. Odpowiednie zbudowany i wyskalowany zespół scrum pozwala osiągnąć – w teorii – nieskończoną wartościową elastyczność. jeżeli zespół nie ma odpowiednich kompetencji do programowania, żadna metodyka ich nie uratuje.
Nie ma adekwatnego sposobu na zwinne skalowanie. Jednak wiele organizacji odniosło wielki sukces, ewoluując swoje procesy, zespoły i kultury przy użyciu frameworków do skalowania zwinnego.
