Daily Scrum trwa nie więcej niż piętnaście minut i odbywa się zawsze w tym samym miejscu i o tej samej porze, żeby ograniczać niepotrzebną złożoność. Biorą w nim udział wszyscy Developerzy pracujący wspólnie nad Produktem oraz – opcjonalnie – Scrum Master. Głównym celem tego Wydarzenia Scruma jest zaplanowanie zadań, na których realizacji będą się koncentrować w danym dniu.

Daily Scrum – omówione zagadnienia:

  1. Wprowadzenie
  2. Formuła Daily Scrum
  3. Problemy z Daily Scrum i metoda 5W
  4. Podsumowanie

Wprowadzenie

Daily Scrum to najkrótsze i najczęstsze z Wydarzeń Scruma, których przegląd znajdziesz w osobnym artykule.. Zadaniem Developerów uczestniczących w Daily Scrum jest szybkie wyznaczenie celów pracy na najbliższe 24 godziny. Dzięki temu każdy z nich wie, nad czym pracują inni i w jaki sposób zmierzają do wspólnego osiągnięcia Celu Sprintu.

Formuła Daily Scrum

Nie istnieje jedna właściwa formuła Daily Scrum. Każdy Zespół Developerski wypracowuje działający dla niego format spotkania. Istnieją jednak ogólne ramy ułatwiające jego przeprowadzanie.

Dobrze przeprowadzony powinien dawać każdemu z uczestników możliwość odpowiedzi na dwa pytania:

Jakie jest najważniejsze zadanie, które wykonam dzisiaj?

Jakie są przeszkody na drodze do realizacji tego zadania?

Jednak zadanie ich wprost nie jest obowiązkową formułą. Są to przykładowe pytania określające oś spotkania. Daily Scrum ma służyć poprawieniu komunikacji w Zespole Developerskim, priorytetyzacji zadań i zmniejszeniu ryzyka zastojów w pracy (bottlenecks).

Daily Scrum jest wydarzeniem odpowiadającym Daily Standup w innych metodach Agile. I często przebiega bardzo podobnie do niego – chociaż oficjalny Przewodnik po Scrumie nie wymaga od Developerów stania podczas tego krótkiego Wydarzenia. Bardzo często jego uczestnicy po prostu stają podczas rozmowy w nieformalnej grupie.

Choć może się wydawać że 15 minut dziennie to dużo jak na omówienie codziennych zadań, z praktyki wynika, że takie właśnie spotkanie najlepiej wpływa na efektywność Zespołu Developerskiego. Dzięki częstej i regularnej aktualizacji celów i zobowiązań wszyscy Developerzy skupiają się na priorytetowych zadaniach oraz stawiają wyżej płynny postęp prac zespołowych nad indywidualnymi rezultatami.

Problemy z Daily Scrum i metoda 5W

Jednym z problemów związanych z Daily Scrum jest przeciąganie przez Developerów czasu spotkania. W takim przypadku warto wprowadzić zasadę zapisywania na tablicy – fizycznej bądź wirtualnej – problematycznych kwestii, które nie są kluczowe dla Daily Scrum, ale są istotne dla Zespołu. W ten sposób będzie można wrócić do problemów, które zostały do omówienia podczas nieformalnych rozmów w ciągu dnia. A także, jeśli to potrzebne, podczas Sprint Retrospective, który szerzej opiszemy w osobnym artykule.

Innym problemem często pojawiającym się podczas Daily Scrums jest przekształcenie ich w spotkania podsumowujące poprzedni dzień pracy. Developerzy koncentrują się wówczas na omawianiu osiągniętych już rezultatów. Nie jest to dobra praktyka. Co prawda bieżąca orientacja Developerów w stanie zaawansowania prac prowadzących do realizacji Celu Sprintu jest bardzo istotna. Jednak poświęcanie Daily Scrum już zrealizowanym zadaniom nie sprzyja efektywności.

Pytania pomocnicze

Jeśli Zespół nie czerpie korzyści z Daily Scrum, Scrum Master może pomóc Developerom zidentyfikować problemy obserwując spotkanie pod kątem odpowiedzi na następujące pytania:

OBSZAR PROBLEMOWY PYTANIE
Rozumienie Celu Sprintu Czy Cel Sprintu jest jasny dla Developerów?
Uczestnictwo w spotkaniu Czy każdy z Developerów ma możliwość swobodnej wypowiedzi?/td>
Wzajemny szacunek Czy Developerzy słuchają siebie nawzajem?
Współpraca zespołowa Czy Developerzy pomagają sobie nawzajem?
Zaangażowanie w rozwiązywanie problemów Czy Developerzy proponują różne sposoby rozwiązania pojawiających się problemów?

5 Whys

Po wstępnej identyfikacji problemu, skuteczną techniką ustalenia przyczyny jego powstania może być metoda 5 Why nazywana też 5 Whys lub 5W autorstwa Sakichi Toyody. Polega ona na zadaniu kilku z rzędu pytań „Dlaczego?”. Pozwala to zdiagnozować głębszą przyczynę problemu, a tym samym łatwiej go rozwiązać.

Przykładowo weźmy ostatnią pozycję z tabelki: problem pojawia się w obszarze zaangażowania w rozwiązywanie problemów przez Zespół Developerski. Pięć pytań może wyglądać następująco:

1 x WHY?

Q: Dlaczego Developerzy nie proponują różnych sposobów rozwiązania pojawiających się problemów?

A: Ponieważ Developer Harry zawsze jako pierwszy proponuje jedno rozwiązanie.

2 x WHY?

Q: Dlaczego Developer Harry zawsze jako pierwszy proponuje jedno rozwiązanie?

A: Ponieważ nikt inny nie zabiera głosu.

3 x WHY?

Q:Dlaczego nikt inny nie zabiera głosu?

A: Ponieważ inni Developerzy nie mają ochoty szukać lepszych rozwiązań.

4 x WHY?

Q: Dlaczego inni Developerzy nie mają ochoty szukać lepszych rozwiązań?

A: Ponieważ szukanie rozwiązań wymaga skupienia i łatwiej uznać rozwiązanie Harrego za wystarczająco dobre.

5 x WHY?

Q: Dlaczego uznali rozwiązanie Harrego za wystarczająco dobre?

A: Ponieważ nie są nagradzani za proponowanie alternatywnych rozwiązań, omówili już na początku spotkania swoje plany na dziś i myślą o rozpoczęciu pracy.

W takim przypadku problem braku zaangażowania w rozwiązywanie problemów można rozwiązać zmieniając porządek Daily Scrum i zaczynając od tego zagadnienia. Albo wymyślając system nagradzania najlepszego rozwiązania, na przykład wprowadzając symboliczną nagrodę dla autora największej ilości rozwiązań zaakceptowanych przez Zespół w danym Sprincie.

Podsumowanie

Daily Scrum to bardzo ważny element codziennej pracy Zespołu Developerskiego. Każdy Zespół musi jednak samodzielnie wypracować sobie optymalną formułę tego spotkania. Dobrze przeprowadzony Daily Scrum pozwala na bieżące wyznaczanie cząstkowych celów pozwalających na realizację Celu Sprintu. Umożliwia też szybkie diagnozowanie problemów komunikacyjnych oraz usprawnienie współpracy między Developerami.

Przeczytaj również: Sprint Planning

Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 35. Daily Scrum caroline becker avatar 1background

Autor: Karolina Berecka

Karolina, jako project menadżerka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przepływu pracy i optymalizacji procesów. Jej umiejętności organizacyjne i zdolność do pracy pod presją czasu sprawiają, że jest najlepszą osobą do zamieniania skomplikowanych projektów w rzeczywistość.

Przewodnik Scrum:

  1. Słowniczek podstawowych terminów Scrum
  2. Czym jest Scrum?
  3. Wartości Scruma
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Scrum Team - czym jest i jak działa?
  6. Kim jest Product Owner?
  7. Kim jest Scrum Master?
  8. Najczęstsze błędy popełniane przez Product Ownera
  9. Cechy dobrego Scrum Mastera
  10. Najczęstsze błędy popełnianie przez Scrum Mastera
  11. Współpraca Scrum Mastera z Product Ownerem
  12. Jakie statystyki i metryki powinien śledzić Scrum Master?
  13. Zespół Developerski w Scrumie
  14. Najczęstsze błędy popełniane przez Developerów
  15. Artefakty Scruma
  16. Skalowanie Scruma
  17. Co to jest Backlog Sprintu?
  18. Co to jest Backlog Produktu?
  19. Czym są User Stories?
  20. INVEST, czyli jak stworzyć dobre User Story
  21. Najczęstsze błędy popełniane przy pisaniu User Story
  22. Kryteria Akceptacji User Story
  23. Estymacja i Story Points w Scrum
  24. Jak działa Planning Poker?
  25. Team Estimation Game jako alternatywa dla Planning Pokera
  26. Czym jest Przyrost w Scrum?
  27. Czym jest Sprint w Scrum?
  28. Wydarzenia w Scrum
  29. Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
  30. Co to jest wykres spalania (Burndown Chart)?
  31. Jak tworzyć i jak interpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Prędkość Zespołu Deweloperskiego
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. Co to jest Retrospekcja Sprintu?
  39. Częste błędy w czasie Retrospekcji
  40. Jak przeprowadzić pielęgnację backlogu produktu?
  41. Gdzie zdobyć wiedzę i doświadczenie w Scrum?