Zidentyfikuj blokera i wrzuć go jako zadanie do kolejnego Sprintu

✋ Kontekst

W czasie Retrospektywy czy innego wydarzenia w życiu Zespołu, które ma prowadzić do poszukiwania problemów, a przede wszystkim ich usprawnień, powstaje lista rzeczy do poprawy. Jest to dość oczywiste. Na kolejnym spotkaniu czasami Zespół sięga do tej listy i okazuje się, że zadania (może tylko ich część), są nie wykonane. Doświadczenie z obserwacji Zespołów podpowiada mi, że zazwyczaj przyczyną jest po prostu brak czasu.
Nie zawsze rozumiemy proces w którym jesteśmy. Z jednej strony, jako Zespół mamy do wykonania zadania rozwojowe (ubrane w OKR lub inne cele). Z drugiej strony mamy jako Zespół zadania z szeroko rozumianego maintenance’u (więcej - https://agile247.pl/maintenance-agile/). Z trzeciej strony są zadania, które wynikają z ~Retrospektywy. I te ostatnie mają zazwyczaj najniższy priorytet. A przecież wszyscy się z tym zgodzimy, że jeżeli nie będziemy usprawniać swojego procesu pracy, to zawsze będziemy mieli problemy (pewnie co raz większe).
Z innej perspektywy - zadania usprawniające proces pracy Zespołu są zadaniami, które wymagają nakładów (w postaci czasu). Często istnieje założenie, że usprawnienia realizują się w tzw. międzyczasie. Czyli osoba odpowiedzialna za daną akcję robi ją, kiedy ma czas wolny. Jeżeli to zderzymy z tym co napisałem wyżej okazuje się, że brak czasu jest prawdziwym i bardzo częstym uzasadniemiem dla nie zrobienia danej akcji (bo czasu po prostu nie ma).
Najprostszym rozwiązaniem jest wyciągnięcie tych zadań „spod stołu”. Pokażmy, że one są. Pokażmy, że one kosztują i traktujmy je równorzędnie z innymi typami zadań.


Nie czekaj z omówieniem problemu do Retrospektywy - wykorzystaj Daily

✋ Kontekst

Część problemów, na które napotyka zespół może, a wręcz powinna być omówiona wcześniej. Jeżeli pracujemy w iteracjach, to czasami do kolejnej Retrospektywy:

- możemy zapomnieć o problemie,

- może on już się zdezaktualizuje.

Jakie jeszcze widzicie problemy w odkładaniu rozmowy o zauważonej niedogodności? A może przeciwnie do omawianej wskazówki - zespół powinien, tylko na wydarzeniu do tego przeznaczonym rozmawiać o problemach?


Podziel wypracowane na Retrospektywie akcje na długo i krótko trwające

✋ Kontekst

Zespoły na Retrospektywie wypracowują akcje do podjęcia. Niektóre z tych akcji/zadań są do zrobienia relatywnie szybko (np. zastowowanie przez wszystkich w zespole, a nie tylko niektórych jakiegoś przykładowego narzędzia deweloperskiego, albo stosowanie się przez cały zespół do DoD), inne mogą trwać dłużej (albo nawet długo). Przykładem może być np. stwierdzenie przez zespół, że "musimy być bardziej asertywni". Taką akcję warto również przeglądać, jednak nie co Retrospektywę, ale ustalić sobie: - kiedy do niej znowu sięgniemy (kiedy zrobimy, jako zespół jej przegląd), - kto będzie odpowiedzialny nie za realizację tego zadania, ale za przypomnienie o nim w odpowiednim momencie.