Scientific Agile

Często się spotykałam w swojej pracy z podejściem – „my robimy inaczej, ale to przecież nie jest ważne”. Jak wynika z poniższych badań, wiele elementów Scruma ma głębsze znaczenie, a ich zaniedbywanie odbija się na jakości pracy zespołów. Dzisiejszy wpis poświęcę Codziennemu Scrumowi, zwanemu często Daily. Nie traktuję Scrum Guide jak Biblii, ale ponieważ jest zbiorem empirycznie wypracowanych praktyk, to rzeczy w nim opisane są niezbędne, aby cały proces wytwarzania oprogramowania dobrze funkcjonował.

Jakie korzyści można czerpać z Daily?

W swoich badaniach zadawałam zespołom m.in. pytanie „Co jest dla Ciebie najważniejszą korzyścią z tej ceremonii?”. Otrzymałam w rezultacie krótkie opisy, które wymagały uporządkowania i ujednolicenia. Posiłkując się Scrum Guide zdecydowałam się na określenie poziomów dojrzałości Daily przedstawionych w tabeli poniżej.

Skala	Najczęstsze zwroty
0 – Brak możliwości przypisania odpowiedzi	Brak odpowiedzi lub odpowiedź niezrozumiała typu „asdfgh”. Były uznane za braki danych i nie miały wpływu na wyniki. Dla Daily były dwie takie odpowiedzi.
1 – Brak korzyści
2 – Status (co zostało zrobione)	Status, zrobione, postęp prac
3 – Co będę robił  (plany poszczególnych osób)	Co będę robił, teraźniejszość, prywatne plany
4 – Rozwiązywanie problemów, pomoc	Problemy, pomoc, blokery
5 – Ustalanie zależności, synchronizacja	Synchronizacja, zależności, powiązania, podział zadań
6 – Wspólne planowanie jak osiągnąć cel sprintu	Replanowanie, planowanie, cel, wspólne dążenie

Zależało mi na tym, żeby skala oddawała możliwe do osiągnięcia korzyści z Daily, ułożone w kolejności, która oddaje wzrost dojrzałości zespołu i Scruma.

2 – Minimalną korzyścią jest znajomość odpowiedzi na pierwsze pytanie, czyli „co zrobiłem wczoraj?”. Pozwala to zespołowi poznać aktualny stan prac, innymi słowy, przeprowadzić inspekcję na chwilę obecną. Jeśli jest to najważniejsza korzyść, jaką zespół ma z Daily, to istnieje duże prawdopodobieństwo, że nie funkcjonuje jak jeden mechanizm, tylko bardziej jak zbiór jednostek, z których każda stara się pokazać, że „jest w porządku”, bo zrobiła wczoraj to, co powinna lub czego od niej oczekiwano.

3 – Druga korzyść, jaką zespół może osiągnąć, to znajomość odpowiedzi na drugie pytanie, czyli „co zrobię dzisiaj?”. Pozwala to zaplanować własną pracę na najbliższy czas, pomaga zapobiegać prokrastynacji (odwlekaniu). Mając konkretne zadania do wykonania i określony, krótki czas (8 godzin) do następnego Daily, łatwiej jest się zabrać za pracę.

4 – Kolejny poziom to odpowiedź na trzecie pytanie – „Czy widzę jakiekolwiek przeszkody mogące uniemożliwić mi lub Zespołowi Deweloperskiemu osiągnięcie Celu Sprintu?”. Dzięki temu zespół może z wyprzedzeniem usuwać problemy tak, aby mniej wpływały na płynność pracy. Jest to też pierwszy poziom, na którym zespół współpracuje na Daily,  pomaga sobie, a nie tylko wzajemnie się informuje.

5 – Ten i następny poziom wynikają ze współpracy zespołowej. Ustalanie zależności i synchronizacja to takie zachowania, które pozwalają członkom zespołu świadomie współdziałać. Mam tutaj na myśli umawianie się na testowanie, review kodu, łączenie rzeczy robionych przez kilku członków zespołu. Jeśli jest to najważniejsza korzyść z Daily, to świadczy to o tym, że zespół docenia współpracę.

6 – To największa korzyść jaką zespół może uzyskać z Daily, czyli patrzenie na wykonane i planowane prace przez perspektywę tego, co w sprincie najważniejsze, czyli wartości dostarczanej dla klienta. To nie tylko postawa bardzo proaktywna i wskazująca na dużą odpowiedzialność zespołu, ale też na jego świadomość biznesową i zrozumienie potrzeb klienta.

Poniżej przedstawiony jest histogram pokazujący rozkład udzielanych odpowiedzi, czyli ile osób wskazało każdą z odpowiedzi.

Rozkład odpowiedzi w zespołach jest bardzo ciekawy. W dziesięciu zespołach, najniższą udzieloną odpowiedzią było 2, w pozostałych było to 3. Maksimum w dwóch zespołach to 4, w dwóch – 5, w ośmiu – 6. Odpowiedzi najwyższe (czyli 6) były udzielane przez Scrum Masterów w trzech przypadkach, przez deweloperów w czterech, przez dewelopera lub Scrum Mastera również w czterech (w pierwszej edycji badania role nie były rozróżniane).

Jest to o tyle interesujące, że w ramach zespołów występowały odpowiedzi skrajne (najniższe i najwyższe), czyli to, jak jest postrzegana korzyść z Daily, nie jest współdzielone przez zespół.

Liczebność próbki była za mała, żeby móc wyciągnąć wiarygodne wnioski, ale w trzech przypadkach deweloperzy udzielający najwyższej odpowiedzi pochodzili z zespołów, których Scrum Masterzy również udzielili odpowiedzi maksymalnej.

Pierwszym praktycznym wnioskiem, jaki się nasuwa, jest zadbanie o to, żeby to Scrum Masterzy dobrze rozumieli sens Daily. Dzięki temu są w stanie wytłumaczyć to zespołowi. Jeśli Scrum Master ma powierzchowną wiedzę i koncentruje się tylko na “mechanice” Daily, pilnując czasu i odpowiedzi na trzy pytania, zespół będzie się wolniej rozwijał i zmarnuje dużo czasu na “ponowne odkrywanie koła”. W tych obszarach, gdzie wypracowane są dobre praktyki nie warto się uczyć metodą prób i błędów, bo często zmniejsza to przyjemność z pracy i prowadzi do zniechęcenia zespołu.

Dla mnie jedną z ciekawszych obserwacji było to, że członkowie tego samego zespołu potrafili bardzo różnie rozumieć wartość dostarczaną przez Daily. Świadczy to o tym, że ciągłe rozmowy na temat celu zdarzeń scrumowych i wartości, jakich mogą one dostarczać są konieczne. Mimo, że często Scrum Masterowi albo bardziej doświadczonym członkom zespołu wydaje się oczywiste, jaki jest cel Daily, to wyniki wskazują na zupełnie co innego. W trzeciej części artykułu opisuję ćwiczenie, które może pomóc wyrównać tę wiedzę.

Przeprowadzana co jakiś czas inspekcja Daily wydaje się bardzo wskazana, a już zupełnie niezbędna w przypadku zmiany składu zespołu. O ile ludzie dosyć szybko przystosowują się do panujących zasad i zaczynają robić to, co reszta zespołu, to dobrze jest zadbać o to, żeby wiedzieli, po co to robią i jak ich wkład pomaga lub przeszkadza zespołowi. Ludzie mają różne doświadczenia ze Scrumem (często bardzo zdegenerowanym), więc dobrze jest, jak zespół (albo Scrum Master) wyjaśni nowej osobie przed każdym spotkaniem:

• jaki jest jego cel
• jakie dobre praktyki zostały do tej pory wypracowane
• jakie problemy rozwiązują.

Jeśli tego nie zrobimy może się zdarzyć, że nowa osoba będzie wycofana, bo nie będzie wiedziała, jak się zachować. Uczenie się przez obserwację innych jest dobre, ale nie może zastąpić jasno przekazanych informacji. Dodatkowo, mniej typowe sytuacje występują rzadko i nowy członek zespołu nie będzie wiedział, jak ma postąpić w takim przypadku. Druga możliwość jest taka, że nowa osoba jest przebojowa i będzie robiła rzeczy po swojemu, co może drażnić zespół i utrudniać integrację. Ciągłe zwracanie uwagi nie jest dla nikogo miłe, warto więc dbać o transparentne ustalenie, jakiego zachowania oczekujemy od siebie.

Wnioskując z odpowiedzi, Daily często ma charakter zdawania raportu na temat statusu zadań przed Właścicielem Produktu. Niestety nie pytałam się o to, kto uczestniczy w Daily, i trzeba to będzie koniecznie uwzględnić w następnych badaniach. Do kwestii uczestniczenia Właściciela Produktu w Daily odniosę się w następnym artykule, bo jest to często spotykany przypadek.

Pomysł na ćwiczenie dla Scrum Masterów

Cel ćwiczenia

• Lepsze zrozumienie procesów wytwarzania oprogramowania w Scrumie.
• Głębsze spojrzenie na trudności, z jakimi boryka się zespół.
• Lista problemów w organizacji, jakie należy rozwiązać.
• Zbiór obserwacji i pomysłów do przedyskutowania z zespołem.

Sposób wykonania

To ćwiczenie należy wykonać w gronie kilku Scrum Masterów. Jeśli nie ma takiej możliwości, to można je zrobić w grupie zainteresowanych osób. Najlepiej, jeśli należą do różnych zespołów, bo pozwala to uczyć się od siebie nawzajem i zobaczyć, jakie są konsekwencje różnych dysfunkcji albo jak inne zespoły rozwiązują te same problemy.

Ćwiczenie sugeruję rozpocząć od zapisywania przez każdą z osób je wykonujących, jakich korzyści jego zespół nie uzyskał z Daily. Najlepiej, żeby trwało to jeden lub dwa sprinty.

Mogą to być rzeczy typu:

• nie wykryta wcześniej zależność,
• brak czasu na wykonanie review kodu,
• zadanie, które utknęło w testach,
• trudność z połączeniem kodu pisanego przez dwie osoby,
• czekanie z rozpoczęciem prac (na kogoś, na informację, na środowisko),
• informacja, która nie dotarła do całego zespołu,
• utknięcie na problemie, o którym zespół dowiaduje się dopiero na Daily,

czyli wszystkie te rzeczy, które wynikają z organizacji pracy.

Następnie, w gronie osób zaangażowanych w ćwiczenie, każdy z tych problemów próbujemy powiązać z tymi elementami Scruma, które powinny zapewnić jego uniknięcie albo zminimalizowanie. Na przykład, nie wykryta wcześniej zależność może wskazywać na problem z Pielęgnacją Backlogu, czekanie na ukończenie pracy to prawdopodobnie problem z Planowaniem. Inne rzeczy mogą być związane z ogólnymi praktykami deweloperskimi albo projektowymi, takimi jak nieustalony sposób komunikacji czy zgłaszania problemów albo sposób realizacji review kodu.

Celem ćwiczenia jest głębsze zrozumienie, co jest potrzebne, aby zespół był w stanie płynnie i efektywnie pracować i jak to jest zapewniane w Scrumie. Ta świadomość pozwala dostrzegać benefity, jakich dostarcza dobre Daily i wyzwala w zespole chęć do dalszego rozwoju. Praktycznie każda dysfunkcja Daily wynika z innego problemu – albo w organizacji, albo w zespole, albo w samym procesie. Daily jest tylko papierkiem lakmusowym pokazującym, jak przebiega praca zespołu.

Wynikiem tego ćwiczenia jest wspólne rozrysowanie, gdzie każdy z problemów się zaczyna i jak wpływa na Daily. Przydatna może być tutaj technika 5Whys (https://pl.wikipedia.org/wiki/Metoda_5_why). Część problemów leży poza zespołem i należy ustalić konkretne działania mające je rozwiązać. Część jest wewnętrzna i wymaga zweryfikowania w zespole. Dzięki temu, że Scrum Master ma świadomość, co utrudnia pracę, może o tym porozmawiać z zespołem i WSPÓLNIE znaleźć najważniejsze obszary do zmiany.

Na co zwrócić uwagę?

Pierwsza uwaga dotyczy etyki pracy z ludźmi. Jeśli obserwujemy zespół i zapisujemy to, co ludzie robią, to trzeba wcześniej wyjaśnić jego członkom, co i dlaczego robimy. Bardzo często, gdy ludzie dowiadują się, że ich działanie będzie obserwowane, to chcą zrobić daną rzecz jak najlepiej. Jest to dobry moment, żeby porozmawiać z zespołem o tym, czym jest Daily, jaki ma cel i jakie korzyści może przynieść zespołowi oraz czym nie jest. Dopiero po takim wyjaśnieniu można zapisywać obserwacje. Można dać zespołowi kilka dni, żeby najpierw sam poprawił to, co uważa za konieczne. Należy też ustalić z zespołem, że wyniki ćwiczenia do nich wrócą i będą mogli je omówić i z nich skorzystać.

Przestrzegałabym tu bardzo przed postawą „ja już wiem, co robicie źle i macie to zaraz naprawić”. Jest możliwe, że problemy znalezione przez Scrum Mastera wcale nie są tymi, które są najważniejsze z punktu widzenia zespołu. Dlatego też potrzebna jest rozmowa i dowiedzenie się, jak to wygląda z ich strony. Głównym celem tego ćwiczenia jest podniesienie świadomości Scrum Mastera i lepsze zrozumienie przez niego Scruma, znalezienie obszarów do pracy w organizacji oraz ustalenie z zespołem, co i w jakiej kolejności chcą zmieniać.

Pomysł na retro „Co jest, a co może być korzyścią z Daily”.

Cel ćwiczenia

• Zobaczenie przez zespół, jak obecnie wygląda Daily.
• Zrozumienie, jakie jeszcze korzyści może im przynieść.
• Zrozumienie potrzeb poszczególnych członków zespołu.
• Zaplanowanie konkretnej zmiany do wprowadzenia.
• Lepsze zrozumienie procesu przez zespół.

Sposób wykonania

Rozdajemy zespołowi karteczki. Każdy członek zespołu zapisuje na jednej, jakie zespół ma obecnie korzyści z Daily, a na drugiej, jakie jeszcze chciałby mieć. Następnie, karteczki każdego typu staramy się uszeregować na skali korzyści z Daily, która została przedstawiona powyżej. W rezultacie powinniśmy otrzymać dwa obrazy – jeden przedstawiający stan obecny i drugi, pokazujący wiedzę i przekonania zespołu o stanie idealnym. Każdy może inaczej postrzegać obecną wartość Daily (wrócę do tego tematu w kolejnych wpisach). Jest możliwe, że sposób, w jaki zespół realizuje to spotkanie, powoduje, że niektórzy członkowie zespołu nie mają z niego większych profitów. Może to na przykład wynikać z przebojowości albo zaawansowania technicznego lub domenowego poszczególnych osób. Jest to dobry moment, żeby porozmawiać o tym, jaki jest głębszy sens tej ceremonii i dlaczego została wypracowana w taki, a nie inny sposób.

Po zrobieniu tej części powinniśmy mieć obraz tego, na ile Daily odpowiada potrzebom zespołu i przynosi mu wartość oraz zespół powinien zobaczyć, co jeszcze może osiągnąć. Uwspólniamy też zrozumienie samego procesu.

Druga część tego ćwiczenia polega na tym, żeby każdy członek zespołu powiedział, co by się musiało zmienić, żeby uznał, że wartość z Daily jest na poziomie maksymalnym. Wnioski z tego należy uporządkować i zapisać, aby można było do nich wrócić. Następnie zespół wybiera to, co chce wprowadzić jako zaplanowaną zmianę. Po jednym i następnie po kilku sprintach należy sprawdzić, czy zmiana się powiodła i czy jest wymagana dalsza adaptacja oraz, czy inne zapisane wnioski wymagają realizacji.

Ustalenia zespołu dotyczące komunikacji

Cel ćwiczenia

• Usprawnianie przepływu informacji.
• Ustalenie, kiedy i jak się informować o zmianach.
• Ustalenie, jak przejmować komunikację.
• Ustalenie, jak wiele czasu można spędzić nad problemem.
• Przejęcie przez zespół jako całość odpowiedzialności za komunikację.

Sposób realizacji

Należy wspólnie jako zespół ustalić i zapisać w widocznym miejscu:

• Z jakimi rzeczami nie czekamy do Daily, tylko od razu je zgłaszamy całemu zespołowi.
• Jak to robimy?
• Jak się komunikujemy z Właścicielem Produktu, szczególnie w ważnych i pilnych sprawach? Jak dbamy o to, żeby te ustalenia na bieżąco trafiały do wszystkich członków zespołu?
• Jak się komunikujemy z innymi osobami, zespołami, biznesem, klientem?
• Jak przekazujemy sobie odpowiedzialność za komunikację, kiedy któryś z członków zespołu idzie na zwolnienie albo urlop? Szczególnie dotyczy to sytuacji, kiedy jakiś rodzaj komunikacji jest zwyczajowo realizowany przez jedną osobę. Dobrze jest wypracować system, w którym jedna albo dwie osoby są w stanie łatwo przejąć dotychczasowe i przyszłe ustalenia.
• W jaki sposób parkujemy tematy do dalszego przegadania po Daily?
• O czym na Daily nie rozmawiamy?
• Czy ustalamy ograniczenia czasowe, jak dużo czasu można spędzić samotnie nad problemem? Wiele osób ma tendencję do siedzenia godzinami nad jakąś trudnością. Z punktu widzenia zespołu może to być nieopłacalne i lepiej jest, na przykład po godzinie, informować zespół, że się ugrzęzło. W wielu przypadkach samo opowiedzenie o problemie pozwala go rozwiązać. Buduje to też wspólną odpowiedzialność za dostarczenie Przyrostu i poczucie, że utknięcie nie jest związane z czyjąś wiedzą czy inteligencją, ale zdarza się każdemu. Tutaj należy zwrócić uwagę na różnice pomiędzy ludźmi – dla jednej osoby powiedzenie o tym, że się nie umie rozwiązać problemu jest banalne, dla drugiej może być nieprzyjemnym przeżyciem. Jeśli jednak wszyscy członkowie zespołu mówią otwarcie o problemach, na jakich utkneli, buduje to kulturę ciągłego uczenia się i wzajemnej akceptacji.  Dlatego tak ważne jest, aby zespół jako całość ustalił, że CHCE sobie pomagać w takich sytuacjach. Oczywiście dla wielu osób samodzielne rozwiązanie problemu jest przyjemnością (i o ile nie zagraża dowiezieniu sprintu) zespół raczej nie będzie przeciwko temu protestować. Ważne, żeby była to świadoma, uzgodniona w zespole decyzja.

Tego typu ustalenia dobrze jest raz na jakiś czas zrewidować, bo mogą wymagać aktualizacji. Każdy nowy projekt czy produkt będzie wymagał ponownego wypracowania najlepszych sposobów komunikacji. Również w przypadku zmiany składu zespołu należy wyjaśnić je nowej osobie. Powyższe ćwiczenie dotyczy nie tylko Scruma, ale również metod prowadzenia projektów, gdzie komunikacja jest uważana za jeden z ważniejszych elementów. W tym ćwiczeniu oba poziomy (zespołowy i projektowy) są połączone, aby zespół mógł traktować komunikację jako całość, jako niezbędny element wytwarzania oprogramowania i wiedział jak zadbać o jej jak najwyższą jakość. Tylko wtedy będzie mógł czerpać z niej jak najwięcej korzyści bez ponoszenia kosztów generowanych przez zagubione czy przekręcone informacje. Dobra komunikacja jest przede wszystkim łatwa i szybka oraz sformalizowana w jak najmniejszym stopniu.