Czy w pojedynku z Scrumem dyskusja o tym, co zostało zrobione wczoraj, powinna ograniczać się do zadań na tablicy lub całej wykonanej pracy?

Wiem, że zasady Scruma w codziennych pojedynkach mówią, że zespół powinien rozmawiać tylko o tym, co zrobili wczoraj, o tym, co robią dzisiaj io wszystkim, co ich blokuje. Nic więcej. Problem polega jednak na tym, że czasami programiści spędzają dzień, wykonując pracę nieistotną dla swoich zadań, a następnie rozmawiają o tym w ramach projektu. Tak zrobili wczoraj!

Z mojego doświadczenia wynika, że ​​bardziej efektywne jest rozmawianie o zadaniach na tablicy, utrzymywanie koncentracji na pojedynku i skupianie się na swoich zadaniach, przeglądanie ich oszacowań i codzienne śledzenie zapisów.

Czy można ograniczyć dyskusję do zadań na tablicy?

Zgodnie z treścią Przewodnika Scrum na temat codziennych pojedynków trzy pytania do dyskusji to:

• Co zrobiłem wczoraj, co pomogło zespołowi programistów osiągnąć cel Sprint?
• Co zrobię dzisiaj, aby pomóc zespołowi programistów osiągnąć cel Sprint?
• Czy widzę przeszkodę, która uniemożliwia mi lub zespołowi programistów osiągnięcie celu sprintu?

Wszystkie pytania koncentrują się wokół celu sprintu, a nie zadań na tablicy. Ponownie, zgodnie z przewodnikiem Scrum, cel sprintu jest tworzony w planowaniu sprintu i definiuje „cel, który zostanie osiągnięty w ramach sprintu poprzez wdrożenie Backlogu produktu, i dostarcza zespołowi programistycznemu wskazówek, dlaczego buduje Przyrost".

Wszystko, co robi twój zespół programistów, powinno idealnie pomóc zespołowi w osiągnięciu celu sprintu. Mogą to być nieplanowane działania, których nie ma na planszy, które musiały zostać wykonane, lub mogą to być rzeczy na niższym poziomie, które mogły zostać wzięte pod uwagę i oszacowane, ale na niższym poziomie niż przedmiot na planszy.

Powiedziałbym, żeby twój zespół mówił o wszystkim, co robili wczoraj. Jeśli mówią o rzeczach, które nie pomagają zespołowi w osiągnięciu celu sprintu, to ktoś powinien to poruszyć, zwłaszcza jeśli istnieją inne rzeczy, które mogłyby zrobić, które zbliżyły zespół do osiągnięcia celu sprintu.

Jednym wyjątkiem może być sytuacja, gdy osoba wspiera wiele zespołów Scrumowych. Podczas spotkania prawdopodobnie nie powinni rozmawiać o wszystkim, co zrobili wczoraj, ale o tym, co zrobili, aby wesprzeć zespół, który obecnie zajmuje pozycję.

Sprint Retrospective to doskonała okazja, aby porozmawiać o tym problemie z zespołem. Jest wiele pytań do rozważenia:

• Czy zespół nie jest zajęty przedmiotami związanymi z celem sprintu?
• Czy jest za dużo nieplanowanej pracy?
• Skąd pochodzi nieplanowana praca i kto ją autoryzuje?
• Dlaczego ludzie pracują nad rzeczami, których nie ma na tablicy?
• Czy powinniśmy pokazywać więcej szczegółów na tablicy, aby łatwiej wiązać rzeczy, które robisz z przedmiotami na tablicy?

Nie, powinieneś porozmawiać o tym, co zrobiłeś wczoraj.

Jeśli nie ma go na planszy, musisz wykonać jedną z następujących czynności:

• połóż to na tablicy,
• przestań to robić
• lub zmieniaj zespoły.

Najczęstszym, na przykład w przypadku nieplanowanej pracy w nagłych wypadkach, jest napisanie karty i przyklejenie jej do tablicy. Dzięki temu na końcu sprintu można zmierzyć prędkość i wyjaśnić, dlaczego cele sprintu nie zostały osiągnięte.

Członek zespołu pracujący nad rzeczami, których nie ma w sprincie, jest moim zdaniem jedną z głównych przyczyn niepowodzenia zwinnych adopcji. Najczęściej jest to programista skierowany do rozwiązywania problemów na żywo w innym projekcie.

Inną irytującą rzeczą w sprintach jest „premier mówi o spotkaniach dla innych projektów”. Moim zdaniem PM nie należy do zespołu Scrum, pełnią rolę Scruma „Product Owner”, a zatem są tam, aby odpowiadać na pytania, a nie zgłaszać postępy.