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:
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.
Przewodnik Scrum:
- Słowniczek podstawowych terminów Scrum
- Czym jest Scrum?
- Wartości Scruma
- Jak wdrożyć Scrum w swojej firmie?
- Scrum Team - czym jest i jak działa?
- Kim jest Product Owner?
- Kim jest Scrum Master?
- Najczęstsze błędy popełniane przez Product Ownera
- Cechy dobrego Scrum Mastera
- Najczęstsze błędy popełnianie przez Scrum Mastera
- Współpraca Scrum Mastera z Product Ownerem
- Jakie statystyki i metryki powinien śledzić Scrum Master?
- Zespół Developerski w Scrumie
- Najczęstsze błędy popełniane przez Developerów
- Artefakty Scruma
- Skalowanie Scruma
- Co to jest Backlog Sprintu?
- Co to jest Backlog Produktu?
- Czym są User Stories?
- INVEST, czyli jak stworzyć dobre User Story
- Najczęstsze błędy popełniane przy pisaniu User Story
- Kryteria Akceptacji User Story
- Estymacja i Story Points w Scrum
- Jak działa Planning Poker?
- Team Estimation Game jako alternatywa dla Planning Pokera
- Czym jest Przyrost w Scrum?
- Czym jest Sprint w Scrum?
- Wydarzenia w Scrum
- Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
- Co to jest wykres spalania (Burndown Chart)?
- Jak tworzyć i jak interpretować wykres spalania?
- Zalety i wady wykresu spalania
- Tablice Kanban w Scrum i Scrumban
- Prędkość Zespołu Deweloperskiego
- Daily Scrum
- Sprint Planning
- Sprint Review
- Co to jest Retrospekcja Sprintu?
- Częste błędy w czasie Retrospekcji
- Jak przeprowadzić pielęgnację backlogu produktu?
- Gdzie zdobyć wiedzę i doświadczenie w Scrum?