• Home
  • Blog
  • Korzyści i wyzwania w Scrumie – ponad 10 lat doświadczenia w RST

ORGANIZACJA

26.03.2021 - Przeczytasz w 7 min.

Korzyści i wyzwania w Scrumie – ponad 10 lat doświadczenia w RST

26.03.2021 - Przeczytasz w 7 min.

Przeczytaj o naszych pierwszych doświadczeniach z metodyką Scrum, kiedy i jak postanowiliśmy go wdrożyć w RST, jakim wyzwaniom musieliśmy stawić czoła oraz co było kluczowe w tym procesie z punktu widzenia całej organizacji. Poniższy wywiad powstał na podstawie odcinka „Drive with IT – 10 lat SCRUMa w RST”, którego gościem był Łukasz Osiadły. Zobacz, jak to wszystko się zaczęło.

RST Software - SCRUM - korzyści i wyzwania

Wdrożenie Scruma w RST 

Kiedy dołączyłem do naszej organizacji, uruchomiony był już pierwszy sprint w jednym z testowych zespołów. Firma zdecydowała się na ten krok ze względu na uciążliwą i trudną procedurę wdrażania usprawnień oraz nowych poprawek do projektów. Wówczas więcej czasu poświęcaliśmy na sprawdzanie dokumentacji, składanie podpisów na aneksach oraz dbanie o przybicie przysłowiowej „pieczątki”, zamiast skupiać się przede wszystkim na działającym oprogramowaniu.

To wtedy zarząd firmy postanowił, że musimy coś zmienić. Dziesięć lat temu Scrum oraz inne podejścia były już znane. Zaryzykowaliśmy i przeszliśmy na podejście zwinne, próbując przeprowadzić pewnego rodzaju rewolucję. Innymi słowy, ponad 10 lat temu realizowaliśmy pierwsze sprinty w zwinnym podejściu, korzystając z frameworka jakim jest Scrum.

Jeśli chcesz dowiedzieć się więcej, obejrzyj odcinek z serii Drive with IT:

Jakie były Wasze pierwsze doświadczenia ze Scrumem? 

Począwszy od zespołów, nie wszyscy byli pozytywnie nastawieni do nowego. Ludzie bali się, jak przed każdą zmianą. Można to było odczuć zarówno w zespołach, jak i w całej organizacji. By zrozumieć te obawy, postawmy się na chwilę w roli developera – dostajemy wytyczne, wykonujemy wyłącznie te zadania, które uwzględnia specyfika zamówienia, nic ponad to.

Nie jest to działanie oparte o potrzebę, nie ma tutaj dodatkowej inicjatywy (jak w zwinnych metodykach). Developer dostaje ticket i go realizuje wg projektu. Z pewnością znajdą się osoby, dla których takie rozwiązanie okaże się wygodne.

Scrum, a praca zespołu developerskiego

Opowiem o tym, jak zaczynaliśmy, ponieważ do teraz sporo rzeczy uległo zmianom. Na samym początku 2-3 zespoły odpowiadały za daną domenę. Mieliśmy wyspecjalizowany team odpowiedzialny za daną część systemu. Kolejnym krokiem było poszerzenie wiedzy, tak żeby zespoły wiedziały, czym w ogóle jest Scrum. Obecnie da się zauważyć, że firmy chcą wdrażać Scrum, ale niechętnie w niego inwestują. My mieliśmy wtedy świadomość tego, że musimy coś poświęcić. Nie mówimy o kilku, tylko o kilkudziesięciu osobach, które przeszły szkolenie. Tego typu rewolucje wymagają zaangażowania całej organizacji. 

Przez długi czas byliśmy wspierani w tej zwinnej transformacji. Kolejnym etapem była codzienna praca. Wyodrębniliśmy rolę Scrum Mastera, która do dzisiaj przez wielu jest niezrozumiała – wiele osób nie wie, czym Scrum Master tak właściwie się zajmuje. Jest to bardzo obszerna rola o szerokich kompetencjach i na początku ich zakres jest trudny do wytłumaczenia, zwłaszcza jeśli w oczywisty sposób nie wynikają z nich wymierne korzyści.

RST Software Masters - Scrum Master

Opiekun procesu – Scrum Master

To była dla nas duża zmiana, coś całkiem nowego. Nikt nie garnął się do objęcia tego stanowiska, a sama funkcja czasami łączyła w sobie obowiązki developera oraz Scrum Mastera. Zaczęliśmy od tego, że na potrzebę danego sprintu wyznaczaliśmy jedną osobę, która pełniła obie te role. Na samym początku działaliśmy podręcznikowo, wdrażaliśmy wydarzenia i artefakty, żeby nasze działania miały ręce i nogi. Począwszy od spotkań, takich jak daily, planowania, retrospektyw, uczyliśmy się zwinnego podejścia, a nasz Scrum Master czuwał nad tym, aby wszystko odbywało się tak, jak należy.

Następnym krokiem było doświadczenie. Byliśmy bardzo otwarci, proces był stale udoskonalany, cały czas się uczyliśmy. Opracowywaliśmy sprawdzone metody, techniki, podejścia i uczyliśmy się na własnych błędach; nie przeprowadzaliśmy już rewolucji, tylko rozwijaliśmy się. Dołączali do nas nowi pracownicy, zespół rozrósł się do liczby 7-8 osób (podręcznik Scrum wspomina maksymalną liczbę 9 osób, ale poprzestaliśmy na 7-8, ponieważ w tamtej chwili była to dla nas już duża liczba). Kiedy doszliśmy do zespołu liczącego 8 osób, którego członkowie uczyli się od siebie nawzajem, rozbijaliśmy go na dwa mniejsze, które dzieliły się zdobytą wiedzą z pozostałymi osobami w organizacji. Nasz rozwój żartobliwie nazywam „rozwojem przez pączkowanie”.

Wytwarzanie oprogramowania, a zespół developerski – wyzwania

Gdybym miał wskazać na jeden problem, to powiedziałbym, że jest to relacja na linii zespół developerski – PO (czyli biznes). Mówiąc najogólniej chodzi o trudność w zrozumieniu idei, według której to, co wytwarzamy, musi odpowiadać zamówieniu klienta. Podejrzewam, że większość myśli, że problem leży w tym, że zespół developerski nie jest w stanie czegoś wykonać. Na podstawie swojego doświadczenia uważam, że jest całkowicie odwrotnie. Istnieje wiele podejść do realizacji zadania; możemy pracować przy użyciu starych technologii lub zainwestować w coś nowego i dedykowanego. Wachlarz możliwości jest ogromny, zwłaszcza jeśli uwzględnimy fakt, że przez ostatnich 10 lat technologie bardzo się rozwinęły. Nie powiedziałbym, że współpraca z klientem jest problemem, ale zdecydowanie stanowi ona wyzwanie.

Jak wyglądały pierwsze Sprint Review zespołów?

Wspominam to bardzo dobrze. Chciałbym jeszcze raz zaznaczyć, że organizacja dała nam dużo swobody i obdarzyła nas zaufaniem, dzięki którym mogliśmy rozwijać się w tej zwinności. Scrum Guide trafnie podsumowuje, że Sprint Review to spotkanie, podczas którego mamy przedstawić interesariuszom „working software increment”, czyli działający kawałek oprogramowania, które zostało zamówione. Na tym spotkaniu, jak pamiętam, obecni byli wszyscy zainteresowani i trwało książkowe 2h w 2 tygodniowych iteracjach.

W takim gronie byliśmy w stanie zdecydować, że kontynuowanie czegoś nie ma sensu. Robiliśmy wtedy krok w bok i szukaliśmy nowych możliwości osiągnięcia określonego celu (specjalnie nie używam sformułowania „krok w tył”). Podjęcie takiej decyzji byłoby niemożliwe przy podejściu kaskadowym, ponieważ pracując w tym drugim za późno dowiedzielibyśmy się, że coś nie działa. Odwaga do wprowadzania zmian jest nieodzowną częścią podejścia zwinnego i trzeba mieć tego dużą świadomość.

Scrum – samodoskonalenie się zespołu, produktu oraz procesu 

Mówiąc bez ogródek, jest to zdecydowanie długi proces. Nie ma złotego środka, czy trzech kroków, których postawienie sprawi, że staniemy się samoorganizującą się firmą. Gdybym miał wskazać narzędzia niezbędne do osiągnięcia tego celu, to pierwszym z nich jest świadomość i jej budowanie. Dopiero w dalszej kolejności skupiłbym się na zespołach, choć nie jest to zbyt popularne podejście. Zespół bez wsparcia całej organizacji nie jest w stanie być zwinny; natrafia na przeszkody, których pokonanie jest możliwe jedynie przy udziale całej organizacji. Często tego typu problem staje się przyczyną ogromnej frustracji, ponieważ ludzie mają chęci i pomysł, którego realizację ostatecznie uniemożliwia przeszkoda napotkana na obranej wcześniej drodze – to jest strzał w kolano dla organizacji, a przecież nie o to w tym wszystkim chodzi.

Jak wyglądałoby to w idealnym świecie? Biznes przychodzi do nas z potrzebą, którą precyzyjnie przedstawia i dysponuje zestawem ciekawych faktów – cała zwinność polega bowiem na tym, że działamy w oparciu o fakty; podchodzimy do tematu empirycznie i jesteśmy pewni wyłącznie tego, czego doświadczyliśmy. Product Owner (PO) jest przygotowany, przeprowadził już badanie rynku i nowych tematów, które chciałby wdrożyć i przetestować. Tym samym angażuje cały zespół, obdarzając go zaufaniem.

Słowa Steve’a Jobsa wydają się tu odpowiednie:

„To bez sensu zatrudniać mądrych ludzi, by potem mówić im co mają robić. My zatrudniamy mądrych ludzi po to, aby to oni mówili nam co mamy robić”

PO powinien określić potrzeby i precyzyjnie je opisać, dając zespołowi możliwość wybrania najlepszej ze ścieżek prowadzących do określonego celu. Taka autonomia w działaniu jest niezbędna z punktu widzenia wewnętrznej motywacji zespołu i jeśli zależy nam na tym, żeby ludziom „się chciało”, żeby żyli dla danego zadania i żeby współtworzyli rozwiązania, zamiast ograniczać się do ich odtwarzania.

Wyzwanie dla biznesu – zaufanie i czekanie na efekty pracy 

Z punktu widzenia biznesu nie jest łatwo zaufać wykonawcy i oddać stery w oczekiwaniu na efekty pracy. Przykładem tego jest nasze doświadczenie, będące historią wzlotów i upadków. Co zrobić, żeby współpraca układała się w sposób bezpieczny, by wszyscy byli zaangażowani? Trzeba budować relacje. Oczywiście nikt nie odda nam całego projektu – wydaje mi się, że to nierealne.

A jak możemy budować relacje? Wróćmy na chwilę do korzeni, czyli naszego „working software” – oddajmy klientowi coś, coś co spełnia swoje zadanie. Stwórzmy jak najszybciej działający element systemu, który wykreuje pierwsze wartości i korzyści. W ten sposób biznes będzie zajmował się biznesem, a developerzy będą szczęśliwi, ponieważ ich projekt wejdzie do użytku i zacznie przynosić pierwsze owoce.

A może Scrum nie jest odpowiedni dla naszej firmy?

Tak, było wiele takich momentów. To taki anty-pattern. Wdrożenie Scruma jest bardzo trudne – niech nikt nie myśli sobie, że wystarczy przeczytać dwa razy 18 stron Scrum Guide’a, bo przecież tam nie ma nic trudnego do zrozumienia, i gotowe. Każdy, kto myśli, że wystarczy przestrzegać ceremonii, robić wszystko według podręcznika, jest w błędzie. Cała walka o to, żeby biznes zrozumiał, że warto w to zainwestować – w spotkania, role, budowanie świadomych PO – jest bardzo żmudnym procesem. Potrzeba dużo więcej wysiłku, konieczne jest wdrożenie wartości w kulturze organizacyjnej, na których będziemy się opierać. 

Jakie wartości są kluczowe we wdrażaniu Scruma?

Przede wszystkim odwaga (do zmian, prób, ponoszenia błędów), szacunek (dla rozwiązań, innych ludzi i odmiennych pomysłów) oraz zaangażowanie (jedna osoba w drużynie nie wygra meczu, jeśli wszyscy nie są zaangażowani) – tylko w ten sposób możemy być innowacyjni. Jesteśmy zwinni i otwarci na różne rozwiązania. 

Oczywiście nie byliśmy tacy od początku; nawet kilka lat temu nie widzieliśmy świata poza Scrumem. Dzisiaj na nowo mierzymy się z SAFe (ang. Scaled Agile Framework), który narzuca bardzo dużo elementów, wydarzeń, ról i artefaktów, które mają nam pomóc w skalowaniu Scruma, zwinnego podejścia, na więcej niż jedną organizację, więcej niż jeden zespół, żeby można było tym sensownie zarządzać. Teraz nad 1 produktem pracuje 28 zespołów z różnych organizacji. Są to zespoły developerskie liczące około 5 osób. Mamy oczywiście różne warstwy, warstwę portfolio, warstwę program i warstwę team czyli zespół. Czy w ogóle warto sięgać po Agile? Przeczytaj Agile Guide dla biznesu – bezpłatny e-book.

Cały framework mówi nam, że na poziomie programu potrzebujemy innych zespołów, takich jak solution teamy, które zajmowałyby się całością. Wiele tematów, z którymi się mierzymy, jest crossowych. Chodzi o to, żeby zespoły były nadal domenowe, żeby robiły to, w czym czują się najlepiej, ale zakładamy, że te same tematy będą przechodziły przez wszystkie zespoły. Trzeba wszystko tak koordynować, aby efektem końcowym był nasz „working software” i żeby „increment” był produkowany nie przez jeden zespół, a przez 28 współpracujących ze sobą zespołów, niezależnych lub zależnych od siebie. Według metodologii Safe, Nexus oraz Less jest to praca na poziomie zależności.

Pobierz bezpłatny whitepaper i dowiedz się więcej

Agile Guide dla biznesu - RST Software

Raport

Agile Guide dla biznesu

Pobierz

Dziękujemy

E-book trafi do Twojej skrzynki mailowej w ciągu kilku minut.

Powrót

Ocena artykułu

Udostępnij

Łukasz Osiadły-RST Software

Łukasz Osiadły

Process Leader

Z branżą IT związany od kilkunastu lat. Zdobył doświadczenie pełniąc rolę Web Developera, GUI Designera, Front-end Developera oraz Scrum Mastera. Z sukcesem wspiera transformacje agile’owe na poziomie zespołów i managementu. Wspiera organizację w efektywnym tworzeniu wartościowych produktów. Skoncentrowany na wczesnym obniżaniu ryzyka i szybkim dostarczaniu wartości dla klienta.

Nasz serwis internetowy używa plików cookies do prawidłowego działania strony. Korzystanie z serwisu bez zmiany ustawień dla plików cookies oznacza, że będą one zapisywane w pamięci urządzenia. Ustawienia te można zmieniać w przeglądarce internetowej. Więcej informacji udostępniamy w Polityce plików cookies.