Stosuj system pull

✋ Kontekst

Wyróżniamy dwa systemy - push i pull. Proces nazywany push to nic innego, jak realizowanie zadań w takiej liczbie, na ile pozwalają Twoje umijętności przy jednoczesnym nie oglądaniu się na pozostałe kroki. „Krok procesu” realizuje maksymalną ilość pracy. Najlepszym i zarazem najprostszym przykładem, obrazującym pracę w systemie push jest zespół deweloperski - programista koduje zadania nie oglądając się na testera, który zazwyczaj nie jest w stanie wszystkich zadań sprawdzić.
Natomiast w systemie pull praca wygląda inaczej. Posługując się przytoczonym już przykładem zespołu deweloperskiego, programista tworzy taką liczbę gotowych do przetestowania zadań, którą tester może obsłużyć. Innym słowy w systemie pull praca ma charakter ciągniony. Tester, będący w procesie za programistą pobiera od niego gotowe zadanie, kiedy skończy bieżące i dopiero wówczas programista zaczyna tworzyć kolejne.
Oba procesy dobrze wyjaśnia podczas ćwiczenia Klaus Leopold - https://www.youtube.com/watch?v=iIc9ttGurUo&t.
Mimo, że system pull wydaje się nieintuicyjny z punktu widzenia liczby „przerobionych” zadań, oraz z mojego doświadczenia - ekstremalnie trudny do implementacji, przynosi on szereg korzyści. Najważniejszymi dla mnie to brak spadku efektywności przy równoczesnym podniesieniu zadowolenia w zespole, poprzez „posiadanie” przez członków zespołu większej ilości czasu (który może być skonsumowany np. na slack time - https://kanbanzone.com/2019/slack-time/).


Dobry Refinement wymaga prowadzenia go przez moderatora, osobę wyznaczoną z zespołu

✋ Kontekst

Pracując z różnymi zespołami, bardzo często trafiamy na sytuację, kiedy nie wiadomo kto prowadzi spotkanie.
Skutki braku moderatora na spotkaniach zespołu są poważne. Nie realizowana agenda, brak wniosków ze spotkania, „uciekanie” uczestników w tematy poboczne, brak lub nie trzymanie się time-boxów. W efekcie stwierdzenie przez większość uczestników (albo wszystkich), że spotkanie było nie efektywne. Są to tylko niektóre elementy, które mogą wystąpić, kiedy na spotkaniu nie ma osoby, która dba o jego przebieg. I nie musi ona spotkaniu przewodzić (wręcz nie powinna), ale zadania związane z mitygacją / eliminacją powyższych wad, powinny być przez nią realizowane.

Wskazany hit znajduje się w rozdziale dotyczącym Refinementu, jednak kwestia moderatora dotyczy wszystkich spotkań zespołu.


Zaprojektuj feedback loop tak, aby jak najszybciej wykrywać błędy w tworzonym oprogramowaniu

✋ Kontekst

Wyróżnić tu trzeba dwa konteksty pętli zwrotnych (chociaż przeplatają się one ze sobą). Pierwszy, o którym mówi przytoczony hint to kontekst techniczny. Stwierdzeniem, które każdy pewnie słyszał jest, że im błąd zidentyfikujemy później, tym jego naprawa będzie droższa. Błąd szeroko rozumiany, dlatego, że z jednej strony może być to kwestia nie działającego oprogramowania, kiedy użytkownicy nie mogą skorzystać z jakieś funkcji. A drugiej strony, błąd często rozumiany jest przez „zgłaszającego” jako brak jakieś funkcji, która miała być (z tym zagadnieniem wiąże się dłuższa opowieść, dotycząca „przepychanek” między zleceniodawcą a dostawcą).
Drugim zagadnieniem jest pętla informacji zwrotnych na poziomie personalnym. Rozmowy ze współpracownikami, przełożonym dostarczają bardzo cennych wskazówek, jak moje zachowania są odbierane i jakie są oczekiwania. Może to wydarzać w wielu sytuacjach, począwszy od uczestniczenia w procesie pracy (czyli np. realizuje pair programming i dostaję informację zwrotną na poziomie technicznym - ogólnie mówiąc - jaki jest mój kod, oraz na poziomie personalnym - jak się ze mną współpracuje), po luźne rozmowy przy kawie.


Reestymuj zadania, kiedy zmniejszy się poziom chaosu w projekcie

✋ Kontekst

Estymacja (szacowanie) zadań jest procesem z natury niedoskonałym.
Kiedy zespół estymuje zadania (czy to w sposób klasyczny czy relatywny - zobacz również artykuły z portalu agile247.pl), wynik jest daleki od tego, co osiągnie na koniec projektu (w książce są linki do konkretnych badań tego zagadnienia).
Zazwyczaj zadania są niedoszacowane. Powoduje to określone ryzyka, klienci są niezadowoleni, zespół jest zdemotywowany.
Jednym ze sposobów zmniejszenia niepewności określenia estymat (albo inaczej - określenia rzeczywistej daty skończenia pracy), jest szacowanie powtórne.
Bazując na moich (naszych) doświadczeniach rekomenduję Wam, aby dokonywać powtórnego szacowania złożoności / pracochłonności zadań po pewnym czasie, np. po 1 czy 2 miesiącach. Takie podejście zapewni przybliżenie się do prawidłowych estymat, ponieważ zespół będzie już więcej wiedział o domenie (technicznej czy produktowej), w której się porusza.


Nie czekaj z omówieniem problemu do Retrospektywy - wykorzystaj Daily

✋ Kontekst

Część problemów, na które napotyka zespół może, a wręcz powinna być omówiona wcześniej. Jeżeli pracujemy w iteracjach, to czasami do kolejnej Retrospektywy:

- możemy zapomnieć o problemie,

- może on już się zdezaktualizuje.

Jakie jeszcze widzicie problemy w odkładaniu rozmowy o zauważonej niedogodności? A może przeciwnie do omawianej wskazówki - zespół powinien, tylko na wydarzeniu do tego przeznaczonym rozmawiać o problemach?


Od czasu do czasu sięgnij po podstawy - zapoznanie się z nimi da Ci nowe spojrzenie na realizowane tematy

✋ Kontekst

Nawet będąc doświadczoną osobą, która pomaga zespołowi (czy to w roli AC, czy lidera, czy też w innych rolach), warto czasami sięgnąć po podstawy - Scrum Guide, Manifest Agile, itp. Dają one powtórnie inspirację do przemyślenia tego, co się obecnie dzieje w zespole / organizacji- czy na przykład zawsze pracujemy tak, aby działające oprogramowanie było ważniejsze od szczegółowej dokumentacji?


Podziel wypracowane na Retrospektywie akcje na długo i krótko trwające

✋ Kontekst

Zespoły na Retrospektywie wypracowują akcje do podjęcia. Niektóre z tych akcji/zadań są do zrobienia relatywnie szybko (np. zastowowanie przez wszystkich w zespole, a nie tylko niektórych jakiegoś przykładowego narzędzia deweloperskiego, albo stosowanie się przez cały zespół do DoD), inne mogą trwać dłużej (albo nawet długo). Przykładem może być np. stwierdzenie przez zespół, że "musimy być bardziej asertywni". Taką akcję warto również przeglądać, jednak nie co Retrospektywę, ale ustalić sobie: - kiedy do niej znowu sięgniemy (kiedy zrobimy, jako zespół jej przegląd), - kto będzie odpowiedzialny nie za realizację tego zadania, ale za przypomnienie o nim w odpowiednim momencie.


Pokazuj problem, zawsze . "No problem is a problem"

✋ Kontekst

Jednym z największych wyzwań w pracy zespołu deweloperskiego jest umiejętne zarządzanie problemami. Mam na myśli z jednej strony przygotowanie się na ich wystąpienie, z drugiej pokazanie ich.

🔸 Przygotowanie się na ich wystąpienie to nic innego jak opracowanie procedur związanych z ich obsługą. Dobrą analogią, opisaną również w książce jest drużyna piłkarska. Jednym z problemów, który może wystąpić w trakcie meczu jest otrzymanie przez bramkarza czerwonej kartki i konieczność opuszczenia przez niego boiska. Drużyna jest zawsze na taką sytuację przygotowana - wie z góry, kto ma zająć jego miejsce w bramce.

🔸 Drugim aspektem jest pokazanie problemu. Trudno zarządzać daną „sprawą”, kiedy nawet nie wiemy czy ona istnieje. Dlatego tak ważne jest, aby każdy problem ujrzał światło dzienne. Może to być na przykład rzecz, która wystąpiła przy realizacji zadania z bieżącej iteracji. Zwróćmy na to uwagę przy omawianiu zadań na Daily (https://lnkd.in/epzFCXH)


Zrób z zespołem próbny przebieg Review, tzw. dry run

✋ Kontekst

Często obserwuję, że Podsumowanie Sprintu zawiera w sobie chaos - poszczególne osoby nie wiedzą jaka jest kolejność prezentacji, nie są przygotowane, gubią się.

Najprostszym sposobem aby temu zapobiec, jest zrobienie próbnego przebiegu (tzw. dry run.)

Zespół na dzień na Review, nad którym prawdopodobnie będą osoby spoza zespołu, robi próbny jego przebieg. W ten sposób zespół jest bardziej pewny siebie w trakcie samego wydarzenia, jak również podonosi wiarę w siebie.