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

Anty-wzorce w Scrumie

Anty-wzorce w Scrumie

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ń, 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.

Źródło zdjęcia: https://flic.kr/p/61KvuL

Komentarze do wpisu: “Antywzorce w Scrumie – czego unikać? Część 1: Daily Scrum

  1. Dzięki Jacku za ten wpis. Do #3: Zespół raportuje status prac do ściany. Członkowie zespołu stoją w linii ewentualnie w półkolu i mówią do ściany (chyba jakieś znaczenie ma fakt, że na ścianie wisi tablica z postitami). Dokumentacja zdjęciowa na życzenie.

    • Jacek Wieczorek

      Dzięki T. za komentarz. Ściana jako „odbiorca raportu”, interesujące. Przynajmniej nie zadaje pytań i można szybciej skończyć Daily 😉

      • Ja osobiście nie jestem tak jednoznacznie negatywnie nastawiona do ” raportowania do ściany”. Fakt, wolałabym by zespół rozmawiał ze sobą i aktywnie układał plan, ale w niektórych przypadkach dobrze przygotowany dashboard ( zawierający takie pomoce jak burndown i jasno określone taski) powoduje, że zespół obserwuje na nim postęp pracy i czeka na zwizualizowanie postępu. Co za tym idzie czasami trudno jest odwrócić się tyłem do czegoś co cię bardzo interesuje i gdzie oznaczasz sobie postęp prac:)

  2. Pytanie do #1 co jeśli na naszej tablicy jest bardzo dużo tasków bo zadania są rozdrobnione? Iteracja po takiej tablicy zajęłaby pewnie z godzinkę.

    • Jacek Wieczorek

      Zakładając, że Sprint Backlog jest ułożony zgodnie z priorytetami biznesowymi (na górze – zadania najważniejsze, na dole – najmniej istotne), można omówić tylko kilka najważniejszych zadań, zaczynając od góry tablicy. Może to zadziałać przy założeniu, że zespół stosuje jakąś formę swarming’u (http://agilecoaching.pl/swarming-technika-dla-zespolu-pomagajaca-konczyc-zadania/), przez co liczba zadań w toku (WIP) jest znacząco ograniczona.

      Pozostaje pytanie, jak bardzo szczegółowo omawiane są zadania (może zbyt szczegółowo?) oraz czy rozdrobnienie zadań nie jest zbyt duże. W pierwszym przypadku część tematów, które są mocno niskopoziomowe, można omówić po Daily Scrumie, w drugim przypadku można zastanowić się, czy konieczne jest aż tak mocno niskopoziomowe dzielenie zadań.

  3. Hej
    A ja mam pytanie czy konieczne jest na tablicy scrumowej, umieszczanie tasków, czy nie wystarcza US? Taski, są narzędziem stricte należącym do zespołu DEV i PO czy SM mogą ich nie rozumieć. PO jest zainteresowany kiedy US osiąga status done, oczywiście na podstawie def of done.

  4. Jacek Wieczorek

    Cześć Kuba,

    przeoczyłem Twój komentarz wcześniej.

    Odpowiadając na Twoje pytanie, pozostawiłbym tę decyzję Zespołowi Deweloperskiemu. Doświadczyłem pracy w obydwóch konfiguracjach i obie mogą okazać się wartościowe dla zespołu. Natomiast z perspektywy PO poziom US faktycznie najczęściej jest wystarczający.

  5. Cześć
    Bardzo dobre wskazówki jak sobie radzić z daily. Ale mam jedną wątpliwość. W #3 piszesz o problemie kiedy z tym, że zespół raportuje do Właściciela Produktu. Rozumiem, ze nie uważasz, że antywzorcem jest udział PO w daily?
    Ja widzę wartość z obecności PO ale Scrum guide wyraźnie mówi tym, że to zdarzenie jest tylko dla zespołu developerskiego.

    • Jacek Wieczorek

      Michał, dzięki za Twój komentarz.

      Obecność PO na Codziennym Scrumie może przybrać różną formę i od tego zależy moja ocena jego obecności.

      Jeżeli PO przychodzi na daily w celu odpytania o postęp prac, oczekuje statusu i generalnie zawłaszcza to spotkanie, aby zrealizować swoje potrzeby, to owszem – uważam to za poważny antywzorzec. Takie zachowanie powoduje bowiem, że to co powinno się zadziać na tym spotkaniu (synchronizacja wewnątrz Zespołu Deweloperskiego, aktualizacja planu na najbliższe 24h, wyciąganie problemów na powierzchnię), może nie mieć miejsca. Zwykle takie sytuacje mają miejsce w firmach, które bądź od niedawna pracują w Scrumie albo zrozumienie Scruma jest na niskim poziomie, co prowadzi do tzw. kultu cargo – czyli „robimy daily, bo tak mówi Scrum Guide”, ale dzieje się to bez zrozumienia celu tego spotkania.

      Jeśli jednak PO bierze udział w tym spotkaniu nie wpływając negatywnie na jego przebieg, to nie widzę w tym nic złego. Zwykle zespoły dogadują się PO co do formy obecności. Ustalając przykładowo, że PO czeka, aż zespół omówi wszystko, co dla nich ważne i dopiero wtedy włącza się w dyskusję. W innych przypadkach Zespół Deweloperski może w trakcie spotkania zapytać PO o jakąś informację, która pomoże im zaplanować najbliższy dzień. Pozwala to uniknąć sytuacji, w której potrzebna jest decyzja lub dane od PO, a tego aktualnie nie ma przy zespole.

      Podsumowując: ocena tej sytuacji zależy od postawy zarówno Zespołu Deweloperskiego jak i Product Ownera.

        • Dzięki Jaga za podzielenie się linkiem, zainteresował mnie Twój punkt widzenia. Spojrzę z tej perspektywy na Codzienne Scrumy przy najbliższej okazji.


Dodaj komentarz

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

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x