Antywzorce w Scrumie – czego unikać? Część 1: Daily Scrum

Artykuł ten jest początkiem serii kilku kolejnych wpisów, których celem jest wskazanie zachowań, które można określić jako anty-wzorce w kontekście frameworka Scrum. Na łamach agile247.pl przybliżę, jakich zachowań unikać w codziennej pracy, wytłumaczę ich negatywny wpływ na proces deweloperski oraz zaproponuję alternatywne działania, które zwykle okazują się przynosić wartość dla zespołu. Na łamach cyklu przedstawię moje subiektywne TOP5 anty-wzorców dla każdego Zdarzenia Scrumowego. Zaczynam dzisiaj od Daily Scruma.

Czym jest anty-wzorzec? Jest to zachowanie w Zespole Scrumowym, które pozornie wygląda niegroźnie, jednak zazwyczaj w konsekwencji wpływa negatywnie na pracę zespołu. Zachowania te wynikają najczęściej z niezrozumienia wartości oraz zasad stojących za Scrumem, co w konsekwencji może prowadzić do ślepego kopiowania popularnych praktyk, bez zrozumienia celu, w jakim je realizujemy.

Daily Scrum: anty-wzorzec #1

Po czym poznać? Członkowie Zespołu Deweloperskiego traktują Daily Scrum jako spotkanie, którego celem jest odpowiedź na 3 pytania wskazywane przez Scrum Guide, czyli:



  • Co zrobiłem wczoraj, co pomogło Zespołowi Deweloperskiemu przybliżyć się do osiągnięcia Celu Sprintu?

  • Co zrobię dzisiaj, co pomoże Zespołowi Deweloperskiemu przybliżyć się do osiągnięcia Celu Sprintu?

  • Czy widzę jakiekolwiek przeszkody mogące uniemożliwić mi lub Zespołowi Deweloperskiemu osiągnięcie Celu Sprintu?

Jakie są konsekwencje? Samo udzielenie odpowiedzi, nieważne, czy bardzo ogólnej, czy szczegółowej, niekoniecznie prowadzi do pożądanej synchronizacji informacji wewnątrz zespołu oraz przygotowania planu pracy na najbliższe 24h. Jeżeli padną wyłącznie suche odpowiedzi, bez zastanowienia się, jak informacje te wpływają na trwający Sprint, Daily Scrum stanie się wyłącznie spotkaniem statusowym, co traktuję jako kolejny anty-wzorzec. Często taka formuła spotkania odciąga uwagę od zadań, skupiając uwagę uczestników na poszczególnych członkach Zespołu Deweloperskiego, a nie to jest celem tego spotkania.

Co można zrobić inaczej? Dwa poniższe podejścia pozwalają odciągnąć uwagę od “3 pytań” i pomagają w przesunięciu ciężaru spotkania w stronę faktycznego planowania trwającego Sprintu:

  • iteracja po elementach Sprint Backlogu: przebieg spotkania oraz kolejność wypowiedzi członków Zespołu Deweloperskiego może zależeć od kolejności zadań w Sprint Backlogu. Technika ta polega na omawianiu każdego zadania po kolei, przez co każdy, kto przyczynił się do konkretnego zadania, przekazuje informacje synchronizacyjne wyłącznie w kontekście omawianego tematu. Kiedy konkretne zadanie jest już omówione i wiemy, co będzie się z nim działo w ciągu najbliższych 24h, przechodzimy do kolejnego zadania. Czynność powtarzamy aż do momentu, w którym wszystkie zadania są już omówione.

  • iteracja “od tyłu”, po krokach w procesie: podobnie jak w przypadku iteracji po elementach Sprint Backlogu, tylko tym razem kolejność omawianych zadań wynika z ich aktualnego statusu w procesie. Przykładowo, jeśli proces w zespole składa się z 5 kroków (np. “Do zrobienia”, “W trakcie”, “Code review”, “Testy”, “Zakończone”), zaczynamy spotkanie od omówienia zadania, które jest najbliżej osiągnięcia stanu “Zakończone” i dyskutujemy, co zostało zrobione oraz co pozostało do zrobienia w kontekście wspomnianego zadania. Ewentualne problemy szybko wypływają na powierzchnię i mogą zostać zaadresowane. Niewątpliwym plusem tego podejścia jest skupienie zespołu na kończeniu zadań (kiedy robienie mniej znaczy więcej – o limitowaniu pracy w toku), co powoduje, że Product Owner może odebrać zadanie, nie czekając na koniec Sprintu i zadecydować o jego ewentualnym wdrożeniu produkcyjnym.

Daily Scrum: anty-wzorzec #2

Po czym poznać? Członkowie Zespołu Deweloperskiego nie śledzą postępu prac podczas spotkania Daily Scrum.

Jakie są konsekwencje? Jeżeli zespół nie wie, ile zaplanowanej pracy zostało dotychczas wykonanej, trudno mu zaplanować nadchodzące 24h. Pewne zadania mogły zostać wykonane szybciej, inne być może okazały się bardziej złożone w stosunku do tego, co zespół myślał, prognozując zakres zbliżającego się Sprintu. To powoduje, że ryzyko nie jest kontrolowane na bieżąco, co może doprowadzić do kłopotów w Sprincie.

Co można zrobić inaczej? Poniżej dwie proste techniki, pozwalające na śledzenie postępu prac podczas Daily Scrum.

  • wizualizowanie pracy na tablicy scrumowej: dobrze przygotowana tablica pozwala na bardzo szybką ocenę aktualnej sytuacji w Sprincie. Zwykle tablica odzwierciedla informacje takie jak: fazy procesu, skład osobowy zespołu, typy realizowanych zadań, ryzyka czy problemy blokujące postęp prac. Tablice mogą funkcjonować zarówno “offline” (przymocowane do ściany, flipcharty), jak i “online” (narzędzia elektroniczne, np. JIRA czy Trello)

  • korzystanie z wykresów spalania (ang. burn-down chart): wykresy tego typu pokazują ilość pracy zaplanowanej na określony okres czasu (np. Sprint lub release) oraz ilość pracy, która pozostała do wykonania. Rzut oka na tego typu wykres pozwala określić, czy zespół realizuje zadania szybciej, niż prognozował, czy z jakichś powodów wolniej. Uzbrojony w taką wiedzę zespół może odpowiednio zareagować.

Daily Scrum: anty-wzorzec #3

Po czym poznać? Członkowie Zespołu Deweloperskiego raportują stan Sprintu do Scrum Mastera / Product Ownera / klienta / managera lub innego “odbiorcy”.

Jakie są konsekwencje? Zazwyczaj działanie takie prowadzi do wypaczenia roli Daily Scruma w kontekście codziennej pracy zespołu. Zespół skupia się na skrupulatnym opowiedzeniu, czym się zajmował wczoraj i czym będzie zajmował się dzisiaj, zamiast planować pracę, która pozostała do zrealizowania w Sprincie. Zazwyczaj jest to połączone z utrzymywaniem kontaktu wzrokowego z osobą, do której raportuje lub uwidacznia się poprzez fizyczne ustawienie Zespołu Deweloperskiego w stosunku do odbiorcy tego komunikatu (np. zespół po jednej stronie pokoju, “odbiorca” po drugiej). W gorszym wariancie tego anty-wzorca, “odbiorca” sam odpytuje zespół o status poszczególnych zdań, w zasadzie prowadząc te spotkanie.

Co można zrobić inaczej? Dwie proste techniki:

  • usunąć “odbiorcę” z pola widzenia zespołu: Daily Scrum to spotkanie dla Zespołu Deweloperskiego i to zespół sam w sobie jest odbiorcą treści, która powstaje podczas tego spotkania. Zazwyczaj konieczne jest przeprowadzenie rozmowy z “odbiorcą”, wytłumaczenie mu celu tego spotkania oraz przedstawienie długofalowych konsekwencji jego zachowania. Jednym z rozwiązań może być fizyczne przesunięcie delikwenta poza grupę (tak aby nie stał w centrum rozmowy), co naturalnie spowoduje, że zostanie niejako “pominięty” podczas spotkania. Bywa, że “odbiornik” dostaje czas antenowy na sam koniec, kiedy zespół wykona zasadniczą część spotkania na własną rękę.

  • pokazać modelowe spotkanie: ciekawym rozwiązaniem jest pokazanie “odbiorcy” Daily Scruma w innym, modelowym zespole. Pozwala to uciąć ewentualne spekulacje na zasadzie “to nie zadziała”, “a jak by to miało wyglądać”, itp. Po spotkaniu warto przeprowadzić rozmowę o tym, kto co zaobserwował.

Daily Scrum: anty-wzorzec #4

Po czym poznać? Członkowie Zespołu Deweloperskiego dyskutują o tym, co robili i będą robić, zamiast mówić o tym co zrobili i co zrobią w ciągu najbliższego dnia. W najgorszym przypadku istnieją zadania, które ciągną się cały Sprint.

Jakie są konsekwencje? Istnieje ryzyko, że zadania faktycznie zajmują lub zajmą więcej czasu, niż planował zespół. Może to doprowadzić do obniżenia przewidywalności zespołu i wpłynąć na plany produktowe Product Ownera.

Co można zrobić inaczej? Zazwyczaj problem leży w wielkości zadań, które wykonywane są w Sprincie. Co możemy zrobić?

  • podzielić elementy Product Backlogu na mniejsze części: to w praktyce całkiem proste podejście, wymaga podstawowej wiedzy dotyczącej różnych sposób dzielenia wymagań. Polega na dzieleniu elementów Product Backlogu na mniejsze kawałki, co powoduje, że Zespół Deweloperski jest w stanie zrealizować je szybciej. “Efektem ubocznym” dzielenia wymagań mogą być dyskusje na temat tego, które wymagania naprawdę przynoszą wartość, a które są przesadnie rozbudowane.

  • ustalić maksymalny rozmiar zadania, które trafia do Sprintu: w wielu zespołach spotkałem się z praktyką, polegającą na określeniu maksymalnego rozmiaru zadania (np. 13 punktów), po przekroczeniu którego, zespół decyduje się podzielić zadanie na mniejsze części. Wartość, która jest sygnałem ostrzegawczym dla zespołu, ustalana jest empirycznie na podstawie historii niezrealizowanych zadań, które przerosły możliwości zespołu.

Daily Scrum: anty-wzorzec #5

Po czym poznać? Podczas Daily Scruma zespół nie aktualizuje planu wykonania Sprintu. Odbywa się rozmowa pomiędzy członkami zespołu, jednak nie wpływa to na faktyczny, taktyczny plan działań w nadchodzącym dniu. Być może w ogólnie nie powstał taki plan podczas Planowania Sprintu.

Jakie są konsekwencje? Dokonywana jest inspekcja postępu prac, po której nie następuje adaptacja. Niezaktualizowany plan prac powoduje, że zespół oddala się od rzeczywistość i może podejmować błędne decyzje na podstawie nieaktualnych danych.

Co można zrobić inaczej? Poniżej dwa sprawdzone sposoby radzenia sobie w wyżej wymienionym problemem:

  • przygotować plan wykonania Sprintu: druga część Planowania Sprintu to odpowiedni moment, aby przygotować taki plan. Może on obejmować takie zagadnienia jak:

    • kolejność wykonywania zadań,
    • zależności wewnętrzne/zewnętrzne,
    • ustalenie, kto wykonuje które zadania oraz w którym momencie Sprintu,
    • aktualne kompetencje w zespole,
    • dostępność członków zespołu.

Oczywiście trudno zaplanować wszystko precyzyjnie z góry na cały Sprint do przodu, jednak warto pamiętać, że taki plan możemy (i powinniśmy!) aktualizować w dowolnym momencie Sprintu, jeśli dostrzegamy taką potrzebę.

  • traktować plan jako radiator informacyjny: nawet najlepszy plan, schowany do szuflady, może okazać się nieprzydatny. To co można zrobić w zamian, to spowodować, że stanie się on widoczny i dostępny dla wszystkich. Można umieścić go na tablicy scrumowej zespołu, co sprawi, że będzie widoczony w przestrzeni teamu, a wówczas bardzo łatwo można do niego nawiązać rozmową w dowolnym momencie Sprintu.

Podsumowanie

Jak widać, bardzo łatwo zamienić Daily Scrum w nieużyteczne spotkanie, które zespół może podsumować jako “stratę czasu”. Z drugiej strony, istnieje całkiem dużo podejść, które pozwalają przywrócić wartość temu zdarzeniu. A jakie anty-wzorce są największym wrogiem Codziennego Scruma z Waszej perspektywy? Koniecznie dajcie znać w komentarzach.

Chcesz przeczytać więcej?

Powyższy artykuł to mały wycinek mojej książki “Labirynty Scruma”, której premierę planuję w okolicy połowy 2017 roku. Opisuję w niej sprawdzone, praktyczne sposoby na najczęstsze pułapki w Scrumie. Zapisz się na mój newsletter – dla subskrybentów planuję przedpremierowy fragment książki oraz dodatkowe materiały.

 

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x