Scrum – 5 najczęstszych błędów w pracy ❌❌❌

Scrum

Czym jest Scrum? Z moich obserwacji, wielu początkujących programistów nie ma wystarczającego zrozumienia technik zwinnych, a w tym Scrum’a. Napiszę nawet więcej. Wielu programistów z dłuższym stażem ma doświadczenie, które rozmija się z głównymi wartościami cechującymi Scrum’a. Wydawać by się mogło, że kilkunastostronicowy przewodnik, wydany przez twórców tej metodologii powinien być łatwy do interpretacji
i aplikacji. Niestety, często tak nie jest.

Zarządzanie chaosem

Dlaczego zatem używać Scrum’a? Ogólnie, scrum pozwala zarządzać projektem
w środowisku, w którym wiedza o procesach związanych z wytworzeniem produktu jest niska, lub wręcz nie istnieje (innowacyjne podejście). Poprzez inspekcję i adaptację wyników prac w krótkich okresach nazywanych sprintami, otrzymujemy iteracyjny przyrost wartości oraz uzyskujemy wiedzę, która pozwoli na optymalizacje tego procesu. Takie podejście pomaga zredukować ryzyka związanez w.w. niewiadomymi i wytworzyć produkt najbardziej zbliżony oczekiwaniom.

Scrum nie działa… ☠

Można spotkać się z narzekaniem na Scrum’a. Zazwyczaj związane jest to
z wprowadzeniem metodyk zwinnych do środowiska, które nie mają zaplecza (Agile Coach, Scrum Master z doświadczeniem) lub nie rozumie celowości zmian. Odbiór
z prowadzenia całego cyklu zwinnego jest bardzo negatywny. Wiąże się to jednak
nie z tym, że Scrum tam nie działa 😱😱😱. Scrum jest metodologią, która nie lubi odstępstw od przyjętych reguł. Znaczy to mniej więcej tyle, że wprowadzenie Scrum’a uwydatnia elementy, które do tej pory działały źle i były zamaskowane w mechanizmach pracy zespołów produktowych.

Błąd #1 – pomijanie refinementu

Spotkałem się już z tym kilka razy w rozmowach z różnymi przedstawicielami branży IT. Przypominam o tym, że Scrum nie lubi odstępstw. Pamiętać należy również, że zazwyczaj pracujemy nad produktem, którego funkcjonowanie, kształt dopiero są określane (dużo niewiadomych).

Bez procesu nauki (refinement) wpadniemy w pułapkę niedoszacowania zadań
w sprincie. W wyniku tego niektóre (a może wszystkie) sprinty nie zakończą się tzw. przyrostem, który zadeklarowaliśmy na jego starcie. Pamiętajmy, że tylko oddając w pełni zrealizowany element, dostarczamy wartość. Częściowa realizacja oznacza porażkę
w danej iteracji.

Błąd #2 – po co mi ta retrospektywa??

Retrospektywa jest częścią drugiego obiegu związanego z inspekcją i adaptacją procesu wytwarzania produktu w Scrumie.

Brak retrospektywy powoduje, że w procesie wytwarzania, będziemy popełniali te same błędy. Na przykład, nierozwiązany problem komunikacji w zespole scrumowym, będzie cały czas działał jako hamulec rozwoju i demotywator dla poszczególnych jego członków.

Błąd #3 – brak transparencji

Poprawne działanie Scrum’a jest oparte o budowanie zaufania. Zarówno pomiędzy członkami zespołu, jak i zespołem i interesariuszami.

Jeżeli działania zespołu są niejasne dla klienta, czy też ogólnie rozumianego biznesu stojącego za produktem, to zapewne prędzej czy później decyzje wyżej wymienionych spowodują znaczną ingerencję w działania zespołu. Oznaki takiej ingerencji to na przykład, potrzeby tłumaczenia się z każdej decyzji, opóźnienia wydania decyzji, a nawet w skrajnych przypadkach tzw. mikro management. Wymienione problemy powodują drastyczne ograniczenie funkcjonowania zespołów scrumowych oraz uderzają w podstawę ich działania, samozarządzanie.

Patrząc z drugiej strony, brak planu, częste zmienianie decyzji bez tłumaczenia, tzw wrzutki z “boku” ze strony biznesu, powodują gwałtowne zmiany dynamiki pracy oraz problemy z planowaniem sprintów. W takich warunkach nie można liczyć, na dobre zrozumienie celu i jego skuteczną realizację przez zespół scrum’owy.

Błąd #4 – Scrum fragmentaryczny 🍕

Częsty przypadek wycinania ze Scrum’a tylko tych części, które nam się podobają, albo o których myślimy, że są wystarczające do poprawnego funkcjonowania.

Spotkałem się z opinią (błędną), że daily, planning i review wystarczą do skutecznego aplikowania Scruma w projekcie. Zazwyczaj wynika to, z mody na metody zwinne, które ktoś chce dopasować do istniejącego “ładu”. Okazuje się, że taki cząstkowy Scrum niby działa. Dzieje się tak, ponieważ to nie jest SCRUM. To jest atrapa, nakładka na istniejący system zarządzania, który jakoś działał i działa dalej. Nie usłyszałem natomiast, odpowiedzi na pytanie, jaką wartość taki twór dał w projekcie, poza tym, że można pochwalić się tzw. “zwinnością”.

Błąd #5 – backlog, nieuporządkowany worek na wszystko

Transparencja, o której już wspominałem, wymaga jasnego zdefiniowania, planu, zakresu prac i na najbliższą przyszłość. Do planowania zazwyczaj używamy jednego z dostępnych narzędzi, w którym wytworzymy listę zadań, backlog.

Problem pojawia się wtedy, gdy backlog projektu zaczyna być workiem na wszystkie pomysły oraz elementy “na później”. Taki backlog nie stanowi jasnego przekazu o tym,
co i jak mamy wykonać. Jest odzwierciedleniem ew życzeń i marzeń.
Wskutek takich praktyk coraz więcej elementów backlogu traci na swojej istotności.
Backlog natomiast zamienia się w długą listę pomysłów, których w większości nie da się, lub nie potrzeba realizować. Czytanie takiego backolg’u staje się nieprzyjemne, zniechęca zainteresowanych do jego przeglądania.

Backlog powinien przedstawiać, plan na działanie w najbliższych sprintach (np. 4-ech).
Na szczycie listy powinny się znajdować, elementy wybrane jako cele najbliższego sprintu, które są uszeregowane wg poziomu zrozumienia i gotowości do realizacji. Ponadto backlog powinien być zrozumiały i dostępnych dla wszystkich stron związanych z wytworzeniem produktu.

Podsumowanie

Pewnie znajdzie się jeszcze sporo innych problemów, z jakimi zetknięcie się (bądź zetknęliście się) w projektach Scrum’owych. Dla mnie lista powyższych wynika z częstości, z jaką spotykałem się z tymi tematami. Możliwe jednak, że przeoczyłem problem,
który wpływa negatywnie na Wasza pracę. Dajcie znać w komentarzach!


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *