Dziś ciekawostka – pytanie, które na naszych szkoleniach pojawia się zadziwiająco często. „Czy trzeba czekać na retrospektywę, żeby zgłosić jakieś utrudnienia?” Jego wariantem jest też „Czy muszę czekać na następny Daily Scrum, żeby zgłosić bloker?”
W oczekiwaniu na retro
Odpowiadając jednym zdaniem: absolutnie nie musimy czekać na jakiekolwiek wydarzenie Scrum, żeby zaproponować usprawnienie albo zgłosić problem czy bloker. Pamiętajmy, że „cały ten agile” to przede wszystkim ładnie opakowany zdrowy rozsądek. A skoro tak, to w chwilach zwątpienia, kierujmy się właśnie nim.
Oczywiste jest, że jeżeli napotkamy na jakiś problem, to nie będziemy dusić go w sobie aż do kolejnego Sprint Retrospective. Powiemy o nim od razu, bo może się okazać, że żadnego kłopotu tak naprawdę w ogóle nie ma! Jeżeli porozmawiamy o nim wewnątrz Scrum Team, możemy się dowiedzieć, że ktoś już ma gotowe rozwiązanie. Czasami zaś od ręki znajdziemy je wspólnie.
Problemy z narzędziami, środowiskiem pracy czy techniką i technologią to często są rzeczy, które możemy załatwić od ręki. Jeżeli temperatura w naszym pokoju jest zbyt niska lub zbyt wysoka, nie zwlekajmy z regulacją ustawień klimatyzacji do „po retro”. To dość absurdalny przykład, ale czasami możemy mieć tendencję do zapisywania sobie naszych bolączek gdzieś na boku, żeby porozmawiać o nich wtedy, kiedy wydaje nam się, że jest na nie czas.
Rozmawiajmy ze sobą jak najczęściej, a większość „kwestii otwartych” nigdy nie urośnie do takiej rangi, żebyśmy spędzili na nich pół retro. Wtedy unikniemy też sesji narzekania na koniec Sprintu, bo problemy rozwiążemy wcześniej. A w ramach naszego ulubionego wydarzenia będziemy mogli zająć się usprawnieniami i dobrymi praktykami.
Zamiast nieustannie gasić pożary, wykorzystajmy wydarzenia do tego, żeby uczynić nasz Scrum niepalnym.
Blokery poza Daily Scrum
Z jakiegoś powodu przyjęło się, że to na Daily Scrum zgłaszane są „blokery”, czyli sytuacje w których coś lub ktoś uniemożliwia nam pracę. Być może wynika to z jednego ze „słynnych trzech pytań”, które mówiło o przeszkodach, które powstrzymują nas (lub Zespół Deweloperski) przed osiągnięciem Celu Sprintu.
Z Daily sytuacja wygląda dokładnie tak samo, jak z naszymi przemyśleniami kierowanymi na retro. Im wcześniej damy znać, że jakiś problem istnieje, tym większa szansa, że ktoś znajdzie jego rozwiązanie. I wtedy nie dotrwa on do następnego Daily!
Wyobraźmy sobie sytuację, w której jeden z programistów napotyka na problem ze środowiskiem. Po aktualizacji kodu okazuje się, że nie da się zbudować kolejnej wersji aplikacji, a co za tym idzie – nie da się pracować. Można cofnąć się o kilka wersji, ale jeżeli potrzebujemy jakichś nowych funkcjonalności, nie jest to rozwiązanie idealne.
Problem jest prosty i częsty, możemy rozwiązać go na własną rękę. Ale dlaczego nie zapytać czy ktoś inny już się z nim nie uporał? Dlaczego mamy sami przez to przechodzić, skoro możemy skorzystać z patcha przygotowanego przez kogoś innego?
Przy tej okazji warto też podkreślić, że nie czekamy z podzieleniem się informacją o takim babolu do kolejnego Daily. Mówimy o tym od razu i to wszystkim, którzy mogą ten problem napotkać. Jaki sens miałoby zwlekanie? Gdzie wtedy transparentność?
Kaizen
Japońskie słowo „kaizen” oznacza tylko i wyłącznie „ulepszanie” czy „doskonalenie”. W kontekście agile’owym zwykle rozumiane jest jako „ciągłe doskonalenie”, czyli dobrze znany nam Continuous Improvement. I tak też zwykle „kaizen” jest sprzedawany – jako nieustanny proces doskonalenia.
Usprawnić możemy zarówno rzeczy małe, jak i duże. I chociaż „lepsze jest wrogiem dobrego”, to na pewno zawsze znajdziemy jakieś rzeczy, które nie mogą obrócić się przeciwko nam. Po prostu spróbujmy, czy w inny sposób nie będzie lepiej. Przeprowadźmy zwinny eksperyment.
Nie czekajmy na jakieś „momenty, w których możemy zgłosić usprawnienia czy poruszyć problemy”! Jeżeli widzimy, że zmiana konfiguracji używanego narzędzia (czytaj: Jira) ułatwi wszystkim pracę, zróbmy to od ręki.
Po co więc w Scrumie występują wspomniane w tym tekście wydarzenia, skoro wszystko możemy załatwić z marszu? Nie każdy zespół wpadnie na rewolucyjny pomysł, żeby w regularnych odstępach czasu rozmawiać o procesie wytwórczym i co iteracja szukać usprawnień (retro), bądź żeby planować kolejny dzień pracy i synchronizować się w kontekście wspólnych zadań (Daily).
Ponadto, nie wszystkie problemy są proste. Szczególnie widać to na retro, gdzie przeważnie poruszamy kwestie procesowe. Zwykle nie wystarczy zmienić jednej prostej rzeczy, tylko musimy zastanowić się nad organizacją pracy, relacji, procesów i tak dalej. Ale znów – lepiej przyjść na retro wiedząc, o czym będziemy rozmawiać.
Pamiętajmy więc, że nie musimy czekać na żaden specjalny „moment”, żeby zoptymalizować naszego Scruma. Mamy taką możliwość przez cały czas trwania Sprintu, a zdefiniowane w Scrum Guide wydarzenia są tylko momentami wyróżnionymi. Do dzieła!
