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ń.


Każda zmiana składu zespołu wymaga rewizji zawartego wcześniej kontraktu

✋ Kontekst
Zespoły Deweloperskie nie są stałe. Ktoś odchodzi, ktoś przychodzi. Jest to sytuacja normalna, która jednak wpływa na jego funkcjonowanie.

Nowa osoba ma swoje oczekiwania i odpowiedzialności. Może także zmienić sposób pracy tego Zespołu. Dlatego przy każdej zmianie składu, Zespół powinien sięgnąć do wcześniej przedyskutowanego kontraktu, omówić go szczegółowo i zmienić go, jeżeli pojawienie się nowej osoby tego wymaga (zwłaszcza Lidera lub Product Ownera / Product Managera). Umożliwi to bardziej płynne zaaklimatyzowania się nowego członka w sposobie pracy i utrzymanie efektywności Zespołu.


Zaplanuj cykliczny „powrót” do wypracowanych w trakcie spotkania / warsztatów rzeczy. Cyklicznie omawiaj je z uczestnikami.

✋ Kontekst

Bardzo często obserwuję, że warsztaty dotyczące pogłębienia tematu, wypracowania rekomendacji i akcji, kończą się na samym „evencie”.
Bardzo rzadko się zdarza, że wypracowane rzeczy są dalej omawiane - jak idzie ich wdrożenie.
Przygotowałem prosty schemat, który obrazuje, jakie powinien wyglądać proces dotyczący szukania odpowiedzi na różne kwestie / poszukiwania odpowiedzi na pytania.

 

 


Cyklicznie sprawdzaj poziom zadowolenia zespołu

✋ Kontekst

Susan Fowler mówi między innymi o relacyjności, która jest elementem budowania motywacji. Za relacyjnością stoi oczywiście zadowolenie. Im jesteśmy bardziej zadowoleni (z relacji, z procesu pracy, z zdań, które realizujemy), tym jesteśmy bardziej efektywni i skuteczni.
Jakiś czas temu napisałem artykuł o happiness index (metrics; czyli mierze zadowolenia), w którym wskazałem dwa konkretne modele - Kniberga (crisp.se) i Jo Justice’a (wikispeed).
Jednak najważniejsze, jak dla mnie nie jest samo pozyskiwanie danych (mierzenie). Jest nim element „egzekucji”. Wartości, które członkowie zespołu wskazują są tylko drogą do pokazania elementów życia zawodowego, które ich „bolą”. Pokazanie, transparentne co się dzieje ze zgłoszonymi przez nich kwestiami jest kluczowe.
Jeżeli prosimy kogoś, aby „ocenił” sytuację i podał powody takiej, a nie innej oceny (albo inaczej - co można zrobić, aby ocena była jeszcze wyższa), to w sposób naturalny ta osoba oczekuje, że wymienione przez nią kwestie będą realizowane w sposób (dla niej?) jawny - w każdej chwili może zobaczyć, jaki jest ich stan i co jest planowane.
Podejście takie daje organizacji (i każdemu jej poziomowi) bieżącą informację, jaki jest poziom zadowolenia pracowników i co powinno zostać zrealizowane, aby ten poziom poprawić.


Przeprowadź zespół do fazy Performing - dostaniesz efektywnie działającą drużynę.

✋ Kontekst
Scrum Guide mówi o interdyscyplinarnych i samoorganizujących się zespołach.
Podejściem do uzyskania samoorganizacji zespołu jest zrozumienie, gdzie on się teraz znajduje i „pomoc” (ze strony Lidera, SMa) zespołowi w dojściu do fazy Performig (wg cyklu Tuckmana). Zamiast puszczać zespół swobodnie i tylko obserwować, co się będzie działo, możemy postępować tak, aby dostarczać mu niezbędne „rzeczy” w trakcie jego „docierania się” - wypracowanie kontraktu zespołowego, jasne zdefiniowanie reguł, umożliwienie przez poszczególnych członków zespołu poszukania wspólnych zainteresowań czy wartości (wspólnego „mianownika”), stopniowe wycofywanie się Lidera / SMa, stwarzanie przestrzeni do pokazywania różnic w zespole, doprowadzenie do akceptacji tych różnic przez poszczególne osoby.

Poczytajcie proszę, oprócz książki wywiad z Asią Gosk, psychologiem specjalizujących się w Analizie Transakcyjnej. Są w nim wskazane charakterystyki każdej z faz rozwoju zespołu i co możemy zrobić, aby doprowadzić do fazy Performing, czyli samoorganizacji.


Wykorzystaj Daily jako część Planowania

✋ Kontekst
Daily jest często postrzegane jako spotkanie, które ma na celu synchronizację zespołu deweloperskiego. Odpowiedzi na trzy popularne pytania (co zrobiłem, co będę robił, jakie mam przeszkody), nie dają jednak wsadu do jeszcze jednego, istotnego elementu Daily. Jest nim zaplanowanie prac.
Zespołom, z którymi pracuje często mówię, że Planowanie nie oznacza stworzenia Planu Sprintu na cały okres, ale tylko na najbliższe kilka dni. Dlaczego? Bo właśnie na Daily powinna nastąpić faza dalszego planowania prac, kiedy dany członek (członkowie) zespołu mają (już) „wolne moce przerobowe”. Wtedy to powinno nastąpić dalsze Planowanie - przypisanie kolejnych zadań ze Sprint Backlogu właśnie do tych osób.
Oczywiście są też inne elementy, którymi należy się zaopiekować na Daily, jak na przykład:
- Zmiana formuły Daily z „per osoba” (w której wspominam wyżej), na formułę „per zadanie” - będzie wtedy łatwiejsze Planowanie nowych zadań,
- Pair Programming - może zespół powinien przypisywać zadania nie do konkretnej osoby, ale do dwójki osób?
- Czy w formule „per osoba” mamy wystarczającą informację aby przejść do Planowania?
- Czy w formule „per zadanie”, każdy z członków zespołu zabiera głos i faktycznie realizuje zadania?
- Ile jest zadań realizowanych „pod stołem”, o których na Daily nie rozmawiamy?


Pokaż dług techniczny. Zaprojektuj wizualizację i umieść ją w miejscu dostępnym dla wszystkich

✋ Kontekst
Dług techniczny to hasło, które często pojawia się w dyskusjach zespołu. Jednak istnieje dużo poważniejsza konsekwencja długu niż tylko dyskusje na poziomie zespołu.
Chodzi mianowicie o „biznes”. Dług techniczny może powodować, że jako firma nie jesteśmy w stanie zwiększyć swoich przychodów. Jak? Poprzez brak wprowadzenia nowych funkcji do naszego produktu.
Wyobraźcie sobie sytuację, w której ktoś z „biznesu” wpada na genialny pomysł. Idzie z nim do zespołu i na Refinemencie zespół deweloperski dochodzi do wniosku, że aby to rozwiązanie / pomysł zaimplementować, należy poświęcić dużo więcej czasu niż początkowo zakładano. Należy przebudować połowę systemu…
„Biznes” jest zaskoczony, powstają obu stronne pretensje. A wystarczy pokazać ten dług i wyjaśnić, o co w nim chodzi.

Jest jeszcze jeden kontekst, o którym się prawie nie mówi. Dług techniczny kojarzy się z czymś negatywnym. Jednak nie zawsze tak jest. Dług techniczny może być dobry. Analogia, którą sugeruje @Ward Cunningham, mówi o zaciągnięciu pożyczki (wymiar finansowy; również naszego budżetu domowego). I jest to preferowane rozwiązanie, zwłaszcza na poziomie zarządzania finansami przedsiębiorstwa. Pożyczki stają się złe tylko wtedy, kiedy albo przesadzimy z ich liczbą, albo ich nie spłacamy. Dlatego też, jeżeli do długu podchodzimy na zasadzie sprawdzenia pewnej hipotezy, aby ją zweryfikować najszybciej jak się da i od razu zakładamy, że powstały dług zlikwidujemy (spłacimy), jest to podejście jak najbardziej zasadne i pożądane.


Skończ jedno zadanie, zanim weźmiesz się za następne - „Stop starting, start finishing”

✋ Kontekst

Ale patrząc na rzeczywistość, mało kto się do niego stosuje. Na pewno jest to trudne, ale może też wynika brak jego stosowania z braku uświadomienia sobie problemu. Gerald Weinberg w swojej książce „Quality Software Management: Systems Thinking”, pokazuje bardzo prostą zależność - na każde nowe zadanie zużywamy około 20% naszej efektywności. Na zapomnienie o poprzednim temacie, wgryzienie się w nowe zadanie. Prosto policzyć, że przy 5-6 zadaniach realizowanych w tym samym czasie nasza efektywność spada do zera.
Innym przykładem ilustrującym to zagadnienie jest prezentacja Henrika Kniberga z AgileByExample.
Dokładne widać, że jeżeli skupienie idzie w jedno zadanie, szybciej je potrafimy zakończyć. Oczywiście ma to swoje przełożenie, przede wszystkim na czas realizacji zadań, czyli idąc jeszcze głębiej na przychód firmy.


Stosuj system pull

✋ Kontekst

Wyróżniamy dwa systemy - push i pull. Proces nazywany push to nic innego, jak realizowanie zadań w takiej liczbie, na ile pozwalają Twoje umijętności przy jednoczesnym nie oglądaniu się na pozostałe kroki. „Krok procesu” realizuje maksymalną ilość pracy. Najlepszym i zarazem najprostszym przykładem, obrazującym pracę w systemie push jest zespół deweloperski - programista koduje zadania nie oglądając się na testera, który zazwyczaj nie jest w stanie wszystkich zadań sprawdzić.
Natomiast w systemie pull praca wygląda inaczej. Posługując się przytoczonym już przykładem zespołu deweloperskiego, programista tworzy taką liczbę gotowych do przetestowania zadań, którą tester może obsłużyć. Innym słowy w systemie pull praca ma charakter ciągniony. Tester, będący w procesie za programistą pobiera od niego gotowe zadanie, kiedy skończy bieżące i dopiero wówczas programista zaczyna tworzyć kolejne.
Oba procesy dobrze wyjaśnia podczas ćwiczenia Klaus Leopold - https://www.youtube.com/watch?v=iIc9ttGurUo&t.
Mimo, że system pull wydaje się nieintuicyjny z punktu widzenia liczby „przerobionych” zadań, oraz z mojego doświadczenia - ekstremalnie trudny do implementacji, przynosi on szereg korzyści. Najważniejszymi dla mnie to brak spadku efektywności przy równoczesnym podniesieniu zadowolenia w zespole, poprzez „posiadanie” przez członków zespołu większej ilości czasu (który może być skonsumowany np. na slack time - https://kanbanzone.com/2019/slack-time/).


Dobry Refinement wymaga prowadzenia go przez moderatora, osobę wyznaczoną z zespołu

✋ Kontekst

Pracując z różnymi zespołami, bardzo często trafiamy na sytuację, kiedy nie wiadomo kto prowadzi spotkanie.
Skutki braku moderatora na spotkaniach zespołu są poważne. Nie realizowana agenda, brak wniosków ze spotkania, „uciekanie” uczestników w tematy poboczne, brak lub nie trzymanie się time-boxów. W efekcie stwierdzenie przez większość uczestników (albo wszystkich), że spotkanie było nie efektywne. Są to tylko niektóre elementy, które mogą wystąpić, kiedy na spotkaniu nie ma osoby, która dba o jego przebieg. I nie musi ona spotkaniu przewodzić (wręcz nie powinna), ale zadania związane z mitygacją / eliminacją powyższych wad, powinny być przez nią realizowane.

Wskazany hit znajduje się w rozdziale dotyczącym Refinementu, jednak kwestia moderatora dotyczy wszystkich spotkań zespołu.