Pułapka Water – Scrum – Falla
Częstym problemem dużych organizacji jest zastosowanie Scruma na samym dole i zostawienie starej, sztywnej i nieefektywnej struktury powyżej zespołów. Innym ryzykiem jest, że idee Scruma zostaną gdzieś po drodze rozmyte lub porzucone pod hasłem „praktyczności” i „dostosowania Agile do naszego kontekstu” (zobacz też na prawa Larmana). Dzieje się tak na przykład w przypadku SAFe, który skleja olbrzymią ilość różnych praktyk Agilowych, w tym Scruma, z nadzieją, że razem zadziałają. Jednocześnie, żeby nie burzyć obowiązującego porządku firmy, rozmiękcza je dostosowując do istniejącej sytuacji. I tak Product Ownerzy nie mają władzy nad własnym produktem, bo właścicielem wizji i mapy drogowej staje się Product Manager. Inny przykład – zespoły niby pracują w iteracjach, ale muszą „zakomitować” się na trzymiesięczny release. Takie podejście może trochę pomóc mocno skostniałej organizacji, niegotowej jeszcze na zmianę. Jednak najczęściej nie adresuje największych problemów jakie mają duże firmy. Tym samym organizacje kończą z „Water-Scrum-Fallem”, gdzie Scrum jest wciśnięty pomiędzy stare, predykcyjne procesy.
Wyzwania dużej skali
Scrum jest trudny, a jego skalowanie podnosi poprzeczkę jeszcze wyżej. Dlatego podstawowa obserwacja jest taka, że nie możesz skalować czegoś, czego jeszcze nie opanowałeś. Jeżeli Twoja organizacja nie potrafi wykorzystać Scruma na poziomie zespołu to Scrum dla wielu zespołów tym bardziej się nie uda. Wszystkie nieefektywności, które stanowią problem przy jednym zespole okażą się katastrofalne przy rozbudowie modelu. To największy problem organizacji, które z jednej strony nie bardzo chcą się zmieniać a z drugiej strony oczekują rezultatów na wczoraj. Transformacja zajmuje czas i często wymaga podważenia dotychczasowych założeń. Skalowanie Scruma należy zacząć od stworzenia stabilnej kultury. Trzeba zawsze mieć z tyłu głowy wartości i zasad Agile i Scrum. Analizować jakie problemy Scrum rozwiązuje, w jaki sposób to robi i jak można to przenieść na dużą skalę.
1. Działający produkt dostarczany co iterację
Podstawową zasadą Scruma jest dostarczanie ukończonego inkrementu (zgodnego z DoD) na koniec każdego Sprintu. Inaczej mówiąc niezależnie od ilości zespołów muszą one mieć wspólne DoD i razem upewnić się, że produkt spełnia DoD co iteracje. Z mojego doświadczenia jest to często największe wyzwanie z uwagi na kod “spaghetti”, dziesiątki technologii, brak praktyk inżynieryjnych (takich jak ciągła integracja czy automatyczne testy) i niedoświadczonych inżynierów zatrudnianych na krótki okres czasu poprzez zewnętrzną agencję. To wszystko tworzy wielką tykającą bombę zegarową, którą bardzo trudno doprowadzić do Releasu. Dlatego wydanie kolejnej wersji najczęściej wiąże się z heroicznym wysiłkiem kilku doświadczonych inżynierów z wewnątrz organizacji i wieloma nieprzespanymi nocami.
Dlatego przechodząc do większej skali Scruma musisz uczynić spłatę długu technicznego, usprawnienie praktyk inżynieryjnych i poszerzenie umiejętności Twoich inżynierów swoim priorytetem.
2. Jedna osoba decyduje o kierunku rozwoju produktu
Drugim wyzwaniem jest własność produktu. Jeżeli chcemy skalować Scruma to Product Owner musi mieć wizję i kierując się nią podejmować decyzje na temat tego nad czym pracujemy w danym momencie. Ja osobiście mam jeden bardzo prosty test na to czy ktoś jest PO. Zadaję pytanie, czy może on odmówić dostarczenia jakiejś funkcjonalności. W większości przypadków odpowiedź brzmi „NIE”, co oznacza, że mamy do czynienia z analitykiem, który tylko przetwarza czyjeś wymagania (zarządu, project managera, prawdziwego PO) na format stosowany w danej organizacji.
Jeżeli masz jeden produkt (z punktu widzenia użytkownika, nie managerów Twojej organizacji) to powinien być tylko jeden PO.
3. Zespoły są w stanie dostarczyć działający produkt
Kolejnym wyzwaniem jest stworzenie cross-funkcjonalnych i cross-komponentowych zespołów, które są w stanie rozwijać produkt zgodnie z priorytetami PO. W wielu organizacjach istniejące ścieżki kariery promują wąską specjalizację co powoduje powstawanie olbrzymiej ilości różnych ról. I tak z jednej strony firmy te chcą tworzyć zespoły, z drugiej strony boją się im oddać władzę zostawiając rzesze koordynatorów i specjalistów, takich jak analitycy, project managerowie, czy architekci.
Dlatego skalując zwróć uwagę na wszystkie odpowiedzialności, które są poza nowo tworzonymi zespołami. Najczęściej tam znajdziesz obrońców starego porządku, tłumaczących dlaczego ich departament nie może działać w Scrumie.
Co potrzeba do skalowania?
Wprowadzenie Scruma na poziomie jednego zespołu to często kwestia kilku miesięcy czy nawet roku. Transformacja dużej organizacji to najczęściej inwestycja liczona w latach a może i dekadach. Dlatego do takiej zmiany potrzebujesz wsparcia zarówno z góry organizacji jak i z dołu. I bardzo dużo cierpliwości, dawki optymizmu i szczypty wiary.
Nie skaluj, deskaluj
Jeśli opanowałeś już Scrum i musisz teraz zmierzyć się z ogromem problemu masz wybór spośród kilku metodyk. Na naszym blogu wkrótce znajdziesz więcej szczegółów o nich. Możesz też stworzyć własny, unikalny i dostosowany do twoich potrzeb proces. Ale zanim się sięgniesz po dowolną z metod zadaj sobie pytanie: “Czy faktycznie muszę skalować”. Jak dotąd najskuteczniejszą metodą dostarczania zwinnie produktów jest deskalowanie organizacji, a to może Wam zaoferować Large Scale Scrum, czyli LeSS.
Jeżeli zainteresował Cię ten artykuł zobacz również na modele skalowania Scruma.
