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.


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.


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.


Pokazuj problem, zawsze . "No problem is a problem"

✋ Kontekst

Jednym z największych wyzwań w pracy zespołu deweloperskiego jest umiejętne zarządzanie problemami. Mam na myśli z jednej strony przygotowanie się na ich wystąpienie, z drugiej pokazanie ich.

🔸 Przygotowanie się na ich wystąpienie to nic innego jak opracowanie procedur związanych z ich obsługą. Dobrą analogią, opisaną również w książce jest drużyna piłkarska. Jednym z problemów, który może wystąpić w trakcie meczu jest otrzymanie przez bramkarza czerwonej kartki i konieczność opuszczenia przez niego boiska. Drużyna jest zawsze na taką sytuację przygotowana - wie z góry, kto ma zająć jego miejsce w bramce.

🔸 Drugim aspektem jest pokazanie problemu. Trudno zarządzać daną „sprawą”, kiedy nawet nie wiemy czy ona istnieje. Dlatego tak ważne jest, aby każdy problem ujrzał światło dzienne. Może to być na przykład rzecz, która wystąpiła przy realizacji zadania z bieżącej iteracji. Zwróćmy na to uwagę przy omawianiu zadań na Daily (https://lnkd.in/epzFCXH)


Zrób z zespołem próbny przebieg Review, tzw. dry run

✋ Kontekst

Często obserwuję, że Podsumowanie Sprintu zawiera w sobie chaos - poszczególne osoby nie wiedzą jaka jest kolejność prezentacji, nie są przygotowane, gubią się.

Najprostszym sposobem aby temu zapobiec, jest zrobienie próbnego przebiegu (tzw. dry run.)

Zespół na dzień na Review, nad którym prawdopodobnie będą osoby spoza zespołu, robi próbny jego przebieg. W ten sposób zespół jest bardziej pewny siebie w trakcie samego wydarzenia, jak również podonosi wiarę w siebie.