Happiness metrics (pol. “metryki zadowolenia”, chociaż będę dalej używał nazwy angielskiej, ponieważ polskie tłumaczenie chyba nie oddaje tego, co chciałbym Wam tym postem przekazać) to temat, który pojawia się w wielu wpisach oraz badaniach okołoscrumowych. Rzecz w tym, aby zmierzyć, jak bardzo nasi pracownicy są zadowoleni, albo wręcz w drugą stronę, jak bardzo są niezadowoleni i co im przeszkadza w poprawieniu samopoczucia.
Podejścia
Przeglądając wpisy Henrika Kniberga oraz Jeffa Sutherlanda dotyczące tego zagadnienia, doszedłem do wniosku, że można generalnie wyodrębnić dwa podejścia.
Podejście pierwsze to wersja Sutherlanda, czyli podejście bardziej inżynierskie, twarde. Happiness metrics jest tu elementem zwiększania efektywności zespołu, co w konsekwencji prowadzi do zwiększenia ROI (zwrot z inwestycji) mierzonego jako koszt zespołu do zwrotu z jego pracy w kontekście dostarczanej wartości biznesowej.
Podoba mi się, że Jeff (nota bene miałem z nim kiedyś okazję o tym porozmawiać) podchodzi do tego jako elementu frameworka scruma, który pozwala nam realizować kaizen.
Cytując jego samego: „We decided to use the introduction of the Happiness Metric as the Retrospective for the previous sprint”.
Nic innego jak wykorzystanie poszukiwania zadowolenia pracowników, aby znaleźć problemy, które zespół męczą. Na jego blogu można znaleźć cały scenariusz użycia metody, składający się z 4 punktów, a w którym wykorzystujemy cztery podstawowe pytania:
1. Na skali 1-5 określ, “jak czujesz się myśląc o organizacji” oraz w drugim pytaniu na tej samej skali określ, “jak czujesz się myśląc o swojej pracy w tej organizacji”.
Każdy członek zespołu na osobnych kartkach wpisuje swoje liczby i przykleja je do ściany.
2. W drugim kroku znajdujemy rzeczy, które mogą pomóc zespołowi poczuć się lepiej. Robimy to poprzez zadanie kolejnych dwóch pytań – “co mogłoby sprawić, że poczujesz się lepiej” – odpowiednio w organizacji jak i w wykonywanej na jej rzecz pracy.
Listę, która się pojawiła, oczywiście musimy zrealizować, najlepiej zgodnie z duchem podejścia, że warto brać na sprint nie więcej niż jedno usprawnienie. Wybieramy więc zatem jedno najbardziej istotne i próbujemy je w nadchodzącym sprincie zrealizować.
Zaletą tego podejścia jest fakt, że poza znalezieniem usprawnień otrzymujemy równocześnie dane do mierzenia happiness metrics, czyli zrobienia wykresu, który pokaże, jak bardzo zespół jest zadowolony z otoczenia i z własnej pracy.
Drugie podejście zostało opisane przez Kniberga. Dla mnie jest ono bardzie “miękkie”, ponieważ dotyczy samopoczucia konsultantów, czyli pracowników CRISP. Tam wyjście od mierzenia satysfakcji pracowników ma doprowadzić w konsekwencji do większego zadowolenia klientów, co oczywiście może bezpośrednio przełożyć się na wynik firmy. CRISP używa nieco zmienionej formy pytań Jeffa, brzmiących mniej więcej tak:
1. Jak bardzo jesteś szczęśliwy w organizacji?
2. Co sprawia, że czujesz się teraz dobrze?
3. Co sprawia, że czujesz się teraz źle?
4. Co może podnieść Twój happiness index? (innymi słowy co spowoduje, że będziesz bardziej zadowolony)
Henrik opisuje to podejście jako kluczowe w prowadzeniu całej firmy. Tak naprawdę mniej istotne są tu wyniki finansowe, a ważniejsze zadowolenie pracowników, ponieważ jak pisałem wcześniej, to najprawdobodobniej przełoży się w końcu na lepsze wyniki finansowe.
Gdzie jeszcze możemy znaleźć happiness metrics?
Temat happiness index oczywiście nie kończy się na Sutherlandzie i Knibergu. Tak naprawdę pogłębiając temat możemy dojść do bardziej psychologicznego podejścia do szczęścia ludzi i jego wpływu na nas samych, jak i na otoczenie. W poście Jeffa znajdziecie też wiele odwołań do innych artykułów w tym temacie, m.in. do Harvard Business Review. Zanim jednak przejdę do podsumowania własnych doświadczeń związanych z happiness metrics, chciałem Wam jeszcze wspomnieć o dwóch interesujących “miejscach”, w których wskaźnik ten zastosowano.
Pierwszym z nich jest wikispeed, gdzie podobnie jak u Jeffa zespół w trakcie retrospektywy skupia się na szczęściu. Jak opowiada Joe Justice, w trakcie retrospektywy każdy z członków zespołu ma 30 sek., aby zagłosować w skali od 1-10 (10 to maximum) i powiedzieć dlaczego tak, a nie inaczej się czuje (a dokładniej: każdy ma ocenić na ile był w stanie być produktywną częścią zespołu w mijającym sprincie – “ability to be productive part of the team”). Jednocześnie każdy proponuje usprawnienie, które może podnieść jego happiness index. Zespół na końcu retrospektywy głosuje i wybiera na nadchodzący sprint to z zaproponowanych usprawnień, które uzyskało najwięcej głosów.
Drugim podejściem do happiness metrics/index jest podejście zupełnie niezwiązane z produkcją oprogramowania. Podejście, które ma być zrealizowane w skali makro, na poziomie całego kraju. Piszę o Bhutanie, miejscu w którym cytując dobrewiadomosci.net.pl: “Od 1971 r. władze Bhutanu odrzuciły założenie, że podstawowym miernikiem rozwoju kraju jest Produkt Krajowy Brutto. Zamiast niego zaproponowano zupełnie inne podejście do rozwoju, mierzące dobrobyt poprzez poziom szczęścia. Wskaźnik GNH (z ang. Gross National Happiness, w wolnym tłumaczeniu: ”szczęście narodowe brutto”) wyznacza właśnie poziom szczęścia, a także zdrowia (zarówno fizycznego, jak duchowego i społecznego) i czystości środowiska naturalnego. Przez wiele lat założenie to – że poczucie szczęścia powinno być ważniejsze niż wzrost gospodarczy – traktowane było na świecie jako dziwactwo. Dziś, w świecie upadających systemów finansowych, wielkich nierówności społecznych i niszczenia środowiska na wielka skalę, podejście zaproponowane przez ten mały buddyjski kraj budzi coraz większe zainteresowanie.”
Zainteresowanych odsyłam do całego artykułu, który znajdziecie tutaj.
Moje doświadczenia
Jakiś czas temu zacząłem mierzyć poziom zadowolenia członków zespołów w jednym z serwisów, dla którego pracowałem… I szybko przestałem. Gdy przestałem ludzi pytać o cyfrę odzwierciedlającą ich zadowolenie z pracy i zdjąłem wykres z wizualizacją happiness index, nikt praktycznie tego nie zauważył. To uświadomiło mi problem – robiłem to bez wyjaśnienia sobie i zespołowi, po co to mierzymy. Jak wspomniałem powyżej, Jeff i Henrik bardzo jasno wskazywali, jaki jest cel mierzenia zadowolenia pracowników. Ja o tym zapomniałem.
Przy okazji mierzenia zadowolenia wrzuciłem na jeden wykres inne zdarzenia, takie jak czas poświęcony na realizację celu sprintu oraz kwestię marnowania czasu. Wyniki możecie zobaczyć na załączonym wykresie.
Resumując
Niezależnie od wersji (Jeff vs Kniberg, o ile w ogóle można tak powiedzieć) ważne z mojego doświadczenia jest, by:
– nie zapomnieć o wizualizacji,
– wskazane przez członków zespołu usprawnienia mogły się stać elementami impediment backlogu Scrum Mastera i/lub wejść jako usprawnienie np. do sprint backlogu (najlepiej jedno!),
– na starcie pokazać zespołowi ograniczenia a raczej ich brak tak, aby generowali tyle pomysłów ile tylko im przychodzi do głowy- od kanapy po continous deployment,
– (i chyba najważniejsze) wytłumaczyć zainteresowanym, po co to robimy.