„Zet” na Daily Scrum

Daily Scrum to wbrew pozorom – obok retrospektywy – chyba najtrudniejsze ze spotkań Scrumowych. Źle przeprowadzane jest podłożem wszelkich problemów trapiących zespół – od braku realizacji planowanych wymagań, poprzez typowo indywidualne podejście deweloperów do pracy, aż do poczucia bezsensu pracowania w Scrumie.

To tu najczęściej na jaw wychodzą problemy związane z dyscypliną zespołu (punktualność, obecność), istniejącą w zespole hierarchią/źle rozumianą rolą Scrum Mastera (spowiedź/raport do wybranej osoby, na którą wszyscy kierują swój wzrok, albo odpytywanie innych przez “ważniaka”),  brakiem zespołowości (statusy na tablicy – pal licho czy elektronicznej czy “analogowej” – nieadekwatne do rzeczywistości; postawa “ja wiem co robię, co to obchodzi innych” ) czy może przede wszystkim – rozumieniem Scruma i sensu jego wykorzystania (nazywanie spotkania “stand-upem” i wymuszanie pozycji stojącej; mechaniczne odpowiadanie na trzy pytania z przewodnika z obowiązkowym “problemów brak”; odbębnianie spotkania żeby mieć je z głowy albo z drugiej strony – wydłużanie go w nieskończoność dyskusjami o technikaliach).

Wszystkie te problemy mają swe korzenie w niezrozumieniu idei, celu tego spotkania, które służyć ma przede wszystkim synchronizacji działań i zaplanowaniu najbliższego dnia pracy oraz zidentyfikowaniu problemów zagrażających realizacji zaplanowanych zadań. I każdy z nich zasługuje na osobne omówienie, którego pewnie dokonamy w naszym samouczku albo w kolejnych wpisach w blogu. Tutaj bardzo krótko chciałbym skupić Waszą uwagę na jeden z najczęściej popełnianych błędów, który jednocześnie wydaje się najprostszy do wyeliminowania.

Jak Polska długa i szeroka, tak najczęściej spotykanym przeze mnie schematem wypowiedzi poszczególnych osób na Daily Scrum jest wczoraj robiłem X, a dzisiaj dalej będę to robił. Tudzież wczoraj robiłem C, a dzisiaj będę robił . I nikomu to nie przeszkadza. Wszyscy kiwają głowami (że niby słuchają), z koksem jedzie następna osoba i po 4 minutach spotkanie skończone, można wrócić do Facebooka, wróć Joe Monstera, pardon, programowania.

Tymczasem co wnosi taka informacja dla zespołu? Wiemy, że deweloper Jarosław Pyton przepisywał wczoraj moduł umów i dziś będzie to kontynuował, a Monika Perlowska wczoraj pracowała nad parserem dokumentów księgowych, a dzisiaj zajmie się przyspieszeniem jego działania. Ale kiedy skończą, co dokładnie robili, na jakim etapie są ich prace, czy widzą jakieś zagrożenia – tego już się nie dowiemy. Wszyscy w zespole zadowalają się ogólnikami i udają, że jest ok.

Problem polega na brakującej literze “zet” w pytaniach, jakie zadają sobie członkowie zespołu. Na tym, że powinniśmy mówić co “Zrobiliśmy”, a nie “robiliśmy” wczoraj oraz co “Zrobimy”, a nie “robimy” dziś. Tylko takie informacje pozwolą całemu zespołowi zaobserwować postęp prac i uzyskać stan rzeczywisty zamiast ogólników.

A zatem, Jarosław P. przepisał wczoraj silnik odpowiadający za dodawanie danych kontrahentów do umów, a na dziś planuje zrobić obsługę specyficznych klauzul związanych z umowami o dzieło. Z kolei deweloperka Perlowska wczoraj pisała silnik wyrażeń regularnych dla parsera dokumentów księgowych, a dziś planuje rozpoznać temat problemów z cachem SQL przy zapytaniach do modułu łączącego się z API programu Automatyczny Księgowy. Lepiej?

Najczęstsza w tym momencie reakcja, to “nie chcemy zanudzać technikaliami” albo “to są zbytnie szczegóły, kogo to obchodzi”. Nic bardziej mylnego. Nie chodzi tu o wchodzenie w techniczne konkrety naszej pracy i tego co robiliśmy z wskazaniem plików, klas i metod, nad którymi pracowaliśmy. Chodzi o bardziej precyzyjną wypowiedź, a przede wszystkim wskazanie co “Zrobiłem” wczoraj, co poszło do przodu, gdzie jest progres. O jednoznaczne wskazanie, co jest już skończone, na jakim jesteśmy etapie. Tak, miłym efektem ubocznym jest to, że tak postawione pytanie nie pozwala skryć się leserom, którzy kolejni dzień przebimbali, a na Daily wykpią się wypowiedzią a’la: kontynuuje prace nad X. Oczywiście, w dobrze pracującym zespole, nikt nie ma problemu, żeby się przyznać, że miał akurat słabszy dzień i niewiele zrobił. A zespół przyjmie to normalnie, o ile jest to wyjątkiem, a nie regułą.

Szczerość jest tu kluczem, a dodanie “z” wybitnie jej sprzyja.

Codzienne Scrumy poprawiają komunikację, eliminują inne spotkania, identyfikują i usuwają przeszkody, sprzyjają szybkiemu podejmowaniu decyzji i podnoszą poziom wiedzy Zespołu Deweloperskiego – głosi Przewodnik po Scrumie. A i owszem, ale tylko, jeśli mówimy o tym co Zrobiliśmy i co planujemy Zrobić.

#DailyScrum