← Eseje

Praktyka wykorzystania indywidualnego rankingu każdego członka zespołu w kontekście Scrum i SAFe

W tym artykule planuję opowiedzieć, jak w swojej praktyce obliczamy i stosujemy indywidualny ranking każdego członka zespołu w Scrum w procesie pracy według frameworka SAFe. Blog osobisty.

5 min czytania
Praktyka wykorzystania indywidualnego rankingu każdego członka zespołu w kontekście Scrum i SAFe

W tym artykule planuję opowiedzieć, jak w swojej praktyce stosujemy indywidualny ranking każdego członka zespołu w Scrum w procesie pracy według frameworka SAFe

Prawdopodobnie wielu zgodzi się z tym, że (zwłaszcza w Rosji) ludzie dość często starają się pracować (dostarczać końcowy produkt w ramach swoich kompetencji lub poprzez zdobywanie nowych) mniej i zarabiać więcej. Wraz z rozmiarem firmy możliwości dla tego, jak się wydaje, rosną wprost proporcjonalnie. Z tym z reguły pracują różni okołoHR-owcy, którzy na wszelkie sposoby próbują budować właściwy system motywacji. Tutaj też OKR-y i tak dalej. Ogólnie wydaje się, że to wszystko jest ukierunkowane na zrównoważenie obciążenia każdego wewnątrz korporacji i komfort wszystkich zainteresowanych grup osób/zespołów korporacji. W tym artykule podzielę się metryką, którą sam wymyśliłem i stosuję w zespole. Pozwala ona, jak mi się wydaje, uzupełnić wysiłki HR-owców i OKR-ów w zrównoważeniu obciążenia wewnątrz jednego konkretnego zespołu lub odpowiednio zobaczyć brak równowagi. Co więcej, może ona również skalować się na zespół zespołów, nie widzę w tym szczególnego problemu.

Tak więc, jako Scrum Master widzę czasem dość wyraźnie, że obciążenie w zespole nie jest zrównoważone, ktoś pracuje za dwóch, ktoś nie robi nic (to skrajne formy i, oczywiście, poważny problem, ale ta metryka pokazuje nie tylko skrajne formy). Przydarzyła mi się taka sytuacja i zastanawiałem się, jaka metryka mogłaby wyraźnie uwypuklić ten problem. W rezultacie przełożyło się to na indywidualny ranking każdego członka zespołu.

Zanim opiszę samą metrykę, chciałbym również zaznaczyć jedną bardzo ważną, moim zdaniem, ideę. Obecnie jestem jej absolutnie pewien.

Metryki powinny być budowane na podstawie tych danych, które i tak otrzymujecie. Uzyskanie jakiejkolwiek metryki nie powinno zmuszać zespołu do systematycznego spędzania więcej czasu i dostosowywania swojego procesu dostarczania wartości do samej metryki. Szczegółowiej o tym postaram się opowiedzieć w jednym z kolejnych artykułów.

A więc przykład konkretnego przypadku. Oczywiście używamy tablicy do przemieszczania User Stories po statusach od DOR (Definition Of Ready) do DOD (Definition Of Done). Mamy ją wirtualną (tzn. znajduje się w internecie pod linkiem. Zespół mamy również rozproszony i standupy odbywają się przez korporacyjny Skype właśnie z transmisją tablicy.

Członkowi zespołu wygodnie jest wpisać siebie jako uczestnika User Story, aby przy użyciu filtra po sobie można było szybko zostawić tylko te historie, w których uczestniczy w danym momencie (najczęściej tego filtra używamy na standupach).

Image

Tutaj również chciałbym dać wyjaśnienie: nie oznacza to, że dany członek zespołu nie może uczestniczyć w innych historiach (jeśli, na przykład, na standupie ktoś z członków zespołu poprosi o pomoc, może całkiem stać się uczestnikiem nowej historii lub odwrotnie, jeśli poczuje, że jego udział nie jest wymagany, może przestać być uczestnikiem jakiejkolwiek historii.

Tak więc, aby obliczyć ranking każdego członka zespołu, musimy spojrzeć, na ile SP wpływa każdy członek zespołu. W naszym przypadku Arkadij wpływa na 29 SP (historie 1, 2, 5, 6), Tatiana wpływa na 33 SP (uczestniczy we wszystkich historiach), Wasilij na 23 SP (historie 1, 3, 5, 6).

Zamknięte (wykonany DOD) u Arkadija 5 z 29 SP, u Tatiany 6 z 32 SP, u Wasilija 5 z 23. Z sortowaniem męczyłem się dość długo i doszedłem do takiego wzoru porównania dwóch członków zespołu (team[i] - jeden członek zespołu i team[j] - inny członek zespołu):

Image

Zgodnie z tym sortowaniem otrzymamy aktualny ranking członków zespołu w następującej postaci.

  • 1 miejsce. Wasilij (wykonano 5 z 23)
  • 2 miejsce. Arkadij (wykonano 5 z 29)
  • 3 miejsce. Tatiana (wykonano 6 z 32)

Teraz wygenerujmy wszystkie dane dotyczące sprintu. Wyobraźmy sobie, że sprint trwa 5 dni roboczych.

  • 1 dzień

    Image

    Image


    1 miejsce: Wasilij (spalone 0 z 23)
    2 miejsce: Arkadij (spalone 0 z 29)
    3 miejsce: Tatiana (spalone 0 z 32)
  • 2 dzień

    Image

    Image


    1 miejsce: Wasilij (spalone 0 z 23) dynamika(1->1)
    2 miejsce: Arkadij (spalone 0 z 29) dynamika(2->2)
    3 miejsce: Tatiana (spalone 0 z 32) dynamika(3->3)
  • 3 dzień

    Image

    Image


    1. miejsce: Wasilij (spalone 5 z 23) dynamika(1->1->1)
    2. miejsce: Arkadij (spalone 5 z 29) dynamika(2->2->2)
    3. miejsce: Tatiana (spalone 5 z 32) dynamika(3->3->3)
  • 4 dzień

    Image

    Image


    1. miejsce: Wasilij (spalone 8 z 23) dynamika(1->1->1->1)
    2. miejsce: Arkadij (spalone 8 z 29) dynamika(2->2->2->2)
    3. miejsce: Tatiana (spalone 9 z 32) dynamika(3->3->3->3)
  • 5 dzień

    Image

    Image


    1. miejsce: Wasilij (spalone 23 z 23) dynamika(1->1->1->1->1)
    2. miejsce: Tatiana (spalone 24 z 32) dynamika(3->3->3->3->2)
    3. miejsce: Arkadij (spalone 21 z 29) dynamika(2->2->2->2->3)

Tym samym, używając tej metryki można gromadzić osobiste statystyki każdego członka zespołu i pomagać mu wyciągać właściwe wnioski. Na przykład tutaj widzimy, że Wasilij bardzo rozsądnie zaplanował swój czas od samego początku (tzn. na planowaniu sprintu uzgodnił z zespołem taki zakres prac, który faktycznie wykonał). Ale jednocześnie, czy mógł jakoś pomóc innym członkom zespołu? Być może nie, ale warto zastanowić się nad tym pytaniem przed retrospektywą.

U Tatiany i Arkadija problem jest poważniejszy. Oczywiste jest, że od samego początku na planowaniu sprintu uzgodnili z zespołem udział we wszystkich historiach i faktycznie nie zdołali wywiązać się z zobowiązań. Nad przyczynami również warto zastanowić się przed retrospektywą. Być może warto planować mniej na siebie, być może rozwijać kompetencje, aby wyrabiać się ze wszystkim zaplanowanym, możliwe są też inne rozwiązania.

Tym samym możemy gromadzić statystyki nie tylko dla całego zespołu i nie tylko dla jednego sprintu, ale także dla konkretnych uczestników DEV TEAM za cały czas i wykorzystywać te informacje do ciągłego doskonalenia zespołu.

Na zakończenie chciałbym zwrócić szczególną uwagę na fakt, że przed użyciem tej metryki w zespole musi już być wystarczająco wysoki poziom zaufania u większości zespołu. Zalecałbym również kłaść duży nacisk na to, co jest pierwotne - brak nadgodzin i komfortowa działalność.

Skupiamy się na prawidłowym prognozowaniu wyniku, a nie na motywacji do pracy w nadgodzinach, aby zajmować 1. miejsce. Ostatecznie ta metryka ma na celu poprawę zdolności planowania każdego członka zespołu osobno.