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.


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.


Zaprojektuj feedback loop tak, aby jak najszybciej wykrywać błędy w tworzonym oprogramowaniu

✋ Kontekst

Wyróżnić tu trzeba dwa konteksty pętli zwrotnych (chociaż przeplatają się one ze sobą). Pierwszy, o którym mówi przytoczony hint to kontekst techniczny. Stwierdzeniem, które każdy pewnie słyszał jest, że im błąd zidentyfikujemy później, tym jego naprawa będzie droższa. Błąd szeroko rozumiany, dlatego, że z jednej strony może być to kwestia nie działającego oprogramowania, kiedy użytkownicy nie mogą skorzystać z jakieś funkcji. A drugiej strony, błąd często rozumiany jest przez „zgłaszającego” jako brak jakieś funkcji, która miała być (z tym zagadnieniem wiąże się dłuższa opowieść, dotycząca „przepychanek” między zleceniodawcą a dostawcą).
Drugim zagadnieniem jest pętla informacji zwrotnych na poziomie personalnym. Rozmowy ze współpracownikami, przełożonym dostarczają bardzo cennych wskazówek, jak moje zachowania są odbierane i jakie są oczekiwania. Może to wydarzać w wielu sytuacjach, począwszy od uczestniczenia w procesie pracy (czyli np. realizuje pair programming i dostaję informację zwrotną na poziomie technicznym - ogólnie mówiąc - jaki jest mój kod, oraz na poziomie personalnym - jak się ze mną współpracuje), po luźne rozmowy przy kawie.


Reestymuj zadania, kiedy zmniejszy się poziom chaosu w projekcie

✋ Kontekst

Estymacja (szacowanie) zadań jest procesem z natury niedoskonałym.
Kiedy zespół estymuje zadania (czy to w sposób klasyczny czy relatywny - zobacz również artykuły z portalu agile247.pl), wynik jest daleki od tego, co osiągnie na koniec projektu (w książce są linki do konkretnych badań tego zagadnienia).
Zazwyczaj zadania są niedoszacowane. Powoduje to określone ryzyka, klienci są niezadowoleni, zespół jest zdemotywowany.
Jednym ze sposobów zmniejszenia niepewności określenia estymat (albo inaczej - określenia rzeczywistej daty skończenia pracy), jest szacowanie powtórne.
Bazując na moich (naszych) doświadczeniach rekomenduję Wam, aby dokonywać powtórnego szacowania złożoności / pracochłonności zadań po pewnym czasie, np. po 1 czy 2 miesiącach. Takie podejście zapewni przybliżenie się do prawidłowych estymat, ponieważ zespół będzie już więcej wiedział o domenie (technicznej czy produktowej), w której się porusza.


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?


Od czasu do czasu sięgnij po podstawy - zapoznanie się z nimi da Ci nowe spojrzenie na realizowane tematy

✋ Kontekst

Nawet będąc doświadczoną osobą, która pomaga zespołowi (czy to w roli AC, czy lidera, czy też w innych rolach), warto czasami sięgnąć po podstawy - Scrum Guide, Manifest Agile, itp. Dają one powtórnie inspirację do przemyślenia tego, co się obecnie dzieje w zespole / organizacji- czy na przykład zawsze pracujemy tak, aby działające oprogramowanie było ważniejsze od szczegółowej dokumentacji?