Jakiś czas temu, w jednym z artykułów, pisaliśmy o procesie doskonalenia Backlogu, aby sobie przypomnieć nasze wywody i skorzystać z checklisty. Dziś zajmiemy się konkretnym spotkaniem, lub jak kto woli ceremonią, a mianowicie Daily Scrum.
O ile mówiąc o pielęgnacji Backlogu myślimy o procesie, który może przybrać różną formę realizacji, o tyle Daily jest już konkretnie zdefiniowanym spotkaniem odbywającym się z założenia w stałych cyklach.
To moment, w którym Zespół Deweloperski mówi sobie, gdzie jest i w jakim miejscu planuje być podczas następnego Daily. Takie małe planowanie, pomagające złapać wspólny kierunek, aby jak najlepiej spożytkować nadchodzący czas i przybliżyć się do realizacji celu, który wyznaczyliśmy sobie na Planowaniu Sprintu.
Zasady dobrego Daily
Jeszcze na początku naszej drogi związanej z wdrażaniem Scruma i próbami przekazania tego, dlaczego tak, a nie inaczej, opracowaliśmy kilka zasad dobrego Daily. Zasady te fajne wdrożyły się w codzienne życie naszych Zespołów i zaczęły przynosić pierwsze pozytywne efekty.
Przytaczamy je poniżej:
- Spotykamy się o stałej godzinie i w tym samym miejscu, bo sprzyja to tworzeniu się dobrego rytmu pracy Zespołu.
- Obecni są wszyscy członkowie Zespołu Deweloperskiego – w przypadku zaplanowanej nieobecności (np. urlopu) pozostałe osoby znają stan prac.
- PO może uczestniczyć w spotkaniu tylko na wyraźne zaproszenie Zespołu (obecnie w większości naszych Zespołów tak właśnie jest, więcej o tym znajdziecie w artykule Praca Scrum Mastera z Product Ownerami – część III).
- Jesteśmy punktualni – szanujemy swój czas.
- Nie jest istotne, czy stoimy, leżymy, czy chodzimy na rękach. Ważne, że słuchamy siebie nawzajem i bierzemy aktywny udział.
- Każdy jest przygotowany, wie co zrobił wczoraj, co planuje zrobić dziś i nie zastanawia się nad tym na spotkaniu.
- Tablica prezentująca Backlog Sprintu (elektroniczna, analogowa) jest aktualna przed spotkaniem.
- Jesteśmy absolutnie szczerzy względem siebie.
- Mówimy, co “zrobiliśmy”, a nie co “robiliśmy” wczoraj i co planujemy “zrobić”, a nie “robić” dzisiaj. W przypadku większych prac informujemy o postępach w ich realizacji.
- Rozmawiamy ze sobą, jeśli widzimy, że jest jakiś problem.
- Szczegóły techniczne zostawiamy na później (np. po Daily), omawiając je wyłącznie w gronie zainteresowanych.
- Wszystkie zadania traktujemy jako własność Zespołu, a nie poszczególnych osób – nie ma “moich zadań”, są tylko zadania i cele Zespołu.
- Mówimy do członków Zespołu Deweloperskiego, a nie do innych osób obecnych na Daily (w tym Scrum Mastera) – to nie jest spotkanie “statusowe”.
- Po spotkaniu każdy wie, jaki jest plan prac Zespołu na najbliższy dzień.
Raz lepiej, raz gorzej
Nasz świat nie stoi w miejscu. Jesteśmy częścią ciągłych zmian, zarówno pod kątem tego w jakiej rzeczywistości pracujemy, jak i w jakim składzie. Z czasem stosowanie niektórych z tych wytycznych w Zespołach uległo dewaloryzacji. Zdarzało się, że Zespół przechodził w tryb traktowania Daily jako statusu, który trzeba odbębnić i który wcale nie jest dla nich, a dla Scrum Mastera, bo się uparł, albo dla Product Ownera, bo chce wiedzieć, gdzie jesteśmy, a JIRA jest nieaktualna. Bywało, że dochodziło do opowiadania niekończących się historii (bo trzeba powiedzieć jak najwięcej), podczas których połowa Zespołu odpływała w myśli o włączonych żelazkach, przepisie na chipsy z jarmużu czy zimnym piwku 😉
Innym razem niektórzy wdawali się w rozbudowane dyskusje, przykładowi dwaj współdyskutanci wchodzili w takie szczegóły, że pozostali uczestnicy spotkania znów kończyli na chipsach z jarmużu. Czasem niektóre osoby popadały w inną skrajność i swoją wypowiedź do Zespołu zamykały w jednym haśle, bo przecież jest mało czasu, pali się, a w sumie to inni albo wiedzą, albo zdecydowanie powinni wiedzieć, co mają na myśli.
Dlatego jakiś czas później wróciliśmy do tematu w naszym wewnętrznym Lessons Learned (kilka słów więcej o tej formie wymiany wiedzy pod adresem). W nim przypomnieliśmy o podstawach, ale też próbowaliśmy pójść o krok dalej i uwydatnić jeszcze bardziej wartości płynące z tego spotkania, aby uczestnicy rzeczywiście poczuli jego sens, a nie tylko stosowali wyuczone formułki.
Czy to działa?
Pierwszym krokiem jest, jak ze wszystkim, uświadomienie sobie potrzeby. Od czasu do czasu warto się przyjrzeć praktykom, które są wykonywane już rutynowo, i zastanowić się, czy nie zgubiliśmy ich sensu. Formuła spotkania zależy od Zespołu, o ile widzimy, że skutecznie wspiera planowanie i synchronizacje prac w sprincie. Nikt nie musi stać, ale dobrze byłoby, aby każdy widział twarz osoby, która do niego mówi i poświęcał jej należytą uwagę.
This is JIRA!
Aby uniknąć syndromu statusu, warto na bieżąco aktualizować JIRĘ (lub inne narzędzie, którego używamy). Niech będzie jedno miejsce, w którym w każdej chwili ktokolwiek, kto jest tym zainteresowany, może zobaczyć jaki jest aktualny stan prac w Zespole.
Ręce do góry
Znanym standardem jest przenoszenie dyskusji technicznych lub dyskusji o konkretnych problemach na koniec spotkania, tak aby go nie rozbijać i umożliwić osobom niezainteresowanym bezpośrednio tematem udanie się do innych obowiązków. Ale jak przerwać czyjś wywód, lub – co jeszcze trudniejsze – dyskusję kilku osób? Można umówić się w Zespole, że dla dobra spotkania, każdy uczestnik może dyskusję przerwać, chociażby hasłem “Do brzegu”. Możemy skorzystać z metody podnoszenia rąk: w momencie, gdy któryś z uczestników uważa, że za bardzo odpływamy od tematu, podnosi rękę (lub dwie) do góry. Każdy Zespół może sobie ustalić swój sposób “dbania o nieodpływanie”.
Gdy już uda się nam opanować trzymanie się sedna spotkania, może się niestety zdarzyć, że poruszone jedynie hasłowo problemy lub szczegóły tematów technicznych nam umkną i po spotkaniu, zamiast do nich wrócić w okrojonym składzie, po prostu się rozejdziemy, zapominając o nich. Metodą na uniknięcie tej sytuacji jest spisywanie sobie na posticie/ścianie/tablicy tematów, które powinny po spotkaniu mieć swój dalszy ciąg.
Kultura w komunikacji
A co, jeśli naszym problemem jest właśnie przekrzykiwanie się, przerywanie w środku zdania, uniemożliwianie zabrania głosu? Wtedy można wprowadzić totem, przedmiot, który wskazuje na to, kto ma w danym momencie prawo głosu. Zwykle jest to maskotka.
Ale dobrą metodą mogą być też odpowiednio wyklikane filtry w JIRA z imionami wszystkich osób w Zespole i prowadzenie Daily przy ich użyciu. Przy okazji wypowiedzi każdej osoby zawężamy widok Backlogu Sprintu do jej zadań.
Myślenie dobrymi pytaniami
Jeśli Daily wciąż utrzymuje formułę odpowiedzi na konkretne pytania, to aby utrzymać właściwy jego cel, można przeformułować pytania, na które poszczególne osoby z Zespołu sobie odpowiadają. W przewodniku po Scrumie znajdziecie obecnie następujące propozycje:
- 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?
Istotną zmianą jest tu czas przeszły dokonany – „zrobiłem”, nie „robiłem”.
Przestań zaczynać, zacznij kończyć!
Jeśli natomiast problemem jest to, że Zespół ma masę rozgrzebanych zadań, a bardzo niewiele zakończonych, możemy spróbować prowadzić Daily przez pryzmat stanu zadań a nie konkretnego człowieka. Zacznijmy omawiać nasz stan od kolumny po prawej stronie (done – jeśli zmiana procesu miała miejsce w czasie od ostatniego Daily) i zastanówmy się wspólnie z Zespołem nad tym, co możemy zrobić, aby jak najwięcej wymagań tam trafiło.
Jakiejkolwiek z metod nie chcielibyśmy spróbować, pamiętajmy o tym, że Daily to spotkanie należące do Zespołu. Warto zaszczepiać w ludziach świadomość, tego że to, jak zostanie wykorzystane, robi różnicę i zależy tylko od nich.
Oczywiście, ile Zespołów, tyle sytuacji. Każdy indywidualnie lub wraz ze swoim Zespołem może zastanowić się nad tym, czy Daily jest tym, czym powinno być. Jeśli nie zawsze tak jest, to dobry moment, aby zadać sobie pytanie: jak tego uniknąć? Jak sprawić, aby Daily rzeczywiście było wartościowe i spełniało swój cel?
