Jak zwiększać motywację zespołów – przemyślenia po „”Drive” Dana Pinka

Okładka książki "Drive" Dana Pinka

Jedna z zasad kryjących się za Manifestem Agile, mówi: “Twórz projekty wokół zmotywowanych osób. Daj im środowisko i wsparcie, którego potrzebują i ufaj im, ze wykonają swoją pracę.” W momencie, w którym przygotowywałem ten artykuł, zdałem sobie sprawę, jak ten pozornie oczywisty zapis jest głęboki i wielowymiarowy – zahacza bowiem jednocześnie o tak rozległe obszary, jak motywacja, środowisko pracy, wsparcie oraz zaufanie w kontekście zespołów deweloperskich. I pomimo, iż właściwie każdy z tych tematów mógłby być osią dla oddzielnych publikacji, dziś skupię się na pierwszym z nich – mianowicie na motywacji.

Zanim przeczytałem w całości “Drive” Dana Pinka kilkukrotnie, w różnych okolicznościach, spotkałem się z nagraniami video, w których Dan opowiada o swoich przemyśleniach dotyczących tego, co tak naprawdę nas napędza do działań. W końcu sięgnąłem do źródła i muszę przyznać, że to jedna z najciekawszych pozycji, jaką przeczytałem w ciągu ostatnich miesięcy. To, na czym chciałbym się dzisiaj skupić, to pokazanie, jak wiedza dotycząca motywacji ma się do realiów funkcjonowania zespołów scrumowych.

Słowem wstępu – autor zauważa, że istnieje rozdźwięk pomiędzy tym, co o kwestii motywacji mówi nauka, a tym, jakie decyzje podejmują organizacje, kiedy przychodzi do “zwiększenia motywacji pracowników”. Wszechobecnie stosowana metoda zewnętrznej motywacji, tj. kija i marchewki, w której groźby (kij) wymieszane są z korzyściami (marchewka) nie dość, że zazwyczaj nie działa, to na dodatek może wywołać odwrotny efekt – zamiast spodziewanej motywacji i wzrostu zaangażowania, pojawia się demotywacja i spadek kreatywności.

Dan jest zdania, że to, na czym powinniśmy się skupić, to zwiększanie wewnętrznej motywacji, a to powoduje, że musimy zmienić sposób, w jaki myślimy o motywowaniu. Definiuje trzy filary, które wpływają na zwiększenie wewnętrznej motywacji, mianowicie: autonomiamistrzostwo oraz poczucie celu. Wszystkie trzy filary opisałem poniżej.

Autonomia

Zakłada, że ludzie chcą mieć wolność podejmowania decyzji. Wolność tę można rozpatrywać na trzech poziomach:

  • zadań (czyli co robimy)
  • czasu (czyli kiedy coś robimy)
  • techniki (czyli jak coś robimy)

Poniżej przedstawiłem przykładowe sytuacje w Zespołach Scrumowych, które wspierają lub obniżają autonomię:

Wspieranie autonomiiObniżanie autonomii
– angażowanie Zespołu Deweloperskiego w rozwój produktu, na przykład poprzez otwarte pytanie o jego zdanie, odczucia oraz pomysły podczas Sprint Review czy spotkań typu Refinement

– podczas spotkań typu Refinement rozmawianie z zespołem na poziomie celu, a nie sztywnego zakresu

– bezkontekstowe przekazywanie Zespołowi Deweloperskiemu zadań do realizacji

– utrzymywanie skupienia na poziomie zadań (small picture), zamiast na poziomie produktu (big picture)

– umożliwianie Zespołowi Deweloperskiemu podejmowania decyzji, kiedy wykonają pracę, na przykład umożliwiając pracę w trakcie Sprintu w dowolnie wybranych godzinach

– pozostawienie decyzji o formie oraz czasie przeprowadzenia zdarzeń scrumowych Zespołowi Deweloperskiemu

– ustalanie sztywnych ram czasowych, w trakcie których Zespół Deweloperski ma realizować Sprint, na przykład pomiędzy 8:00 a 16:00

– brak możliwości pracy zdalnej

– odgórne (Product Owner, klient, organizacja) narzucenie godzin zdarzeń scrumowych dla Zespołu Deweloperskiego

– pozostawianie decyzji dotyczącej technicznej realizacji zadań (jak?) Zespołowi Deweloperskiemu, definiując wyłącznie co ma zostać wykonane (co?)– przygotowywanie Zespołowi Deweloperskiemu precyzyjnie zdefiniowanych, rozległych wymagań, które same w sobie definują rozwiązanie techniczne problemu, nie pozostawiając miejsca na kreatywność
– Zespół Deweloperski decyduje samodzielnie, kto wykonuje które zadania– lider zespołu (naturalny lub formalnie umocowany) decyduje, kto wykonuje które zadania

Mistrzostwo

Zakłada, że ludzie chcą się rozwijać w obszarach, które są dla nich ważne. Aby było to możliwe, musi wystąpić zaangażowanie w pracę, którą na co dzień wykonujemy. Ważny jest taki dobór trudności zadań, aby można było osiągnąć tzw. “flow” – czyli zadania nie mogą być ani zbyt proste, ani z byt trudne. Dan definiuje trzy zasady, związane z osiąganiem mistrzostwa:

  • to stan umysłu – koniecznie jest uświadomienie sobie, że zdolności, które mamy, możemy w nieskończoność rozwijać
  • to ciężka praca – wymagająca wysiłku, charakteru oraz ciągłej praktyki
  • to asymptota – nie jest możliwe osiągnięcie pełnego mistrzostwa, możemy się wyłącznie do niego przybliżać, co jednocześnie jest nęcące, jak i frustrujące.

Poniżej przedstawiłem przykładowe sytuacje w Zespołach Scrumowych, które wzmacniają lub obniżają mistrzostwo:

Wspieranie mistrzostwaOsłabianie mistrzostwa
– elementy Product Backloga Zespołu Deweloperskiego nie są ani zbyt proste, ani zbyt łatwe– elementy Product Backloga są zbyt proste dla Zespołu Deweloperskiego- elementy Product Backloga są zbyt trudne dla Zespołu Deweloperskiego
– Zespół Deweloperski jest zaangażowany w rozwój produktu – podpowiada kierunki rozwoju czy konkretne rozwiązania– Zespół Deweloperski nie jest zaangażowany w rozwój produktu, wykonuje po prostu zadania, które przynosi do zespołu Product Owner
– Zespół Deweloperski może samodzielnie wybierać technologie, które pozwolą na efektywny rozwój produktu– Product Owner narzuca technologię, blokuje wykorzystywanie najnowszych bibliotek oraz frameworków
– Zespół Deweloperski posiada “slack time” w trakcie Sprintu, który pozwala im na rozwój własnych kompetencji– Zespół Deweloperski jest pod presją realizowania w Sprincie zadań na granicy ich możliwości; zespół znajduje się w „trybie przetrwania

 Poczucie celu

Zakłada, że ludzie chcą uczestniczyć w rozwijaniu czegoś więcej, niż tylko samego siebie.

Poniżej przedstawiłem przykładowe sytuacje w Zespołach Scrumowych, które wzmacniają lub obniżają poczucie celu:

Wspieranie poczucia celuOsłabianie poczucia celu
– Zespół Deweloperski podczas Sprint Review rozmawia z interesariuszami o dalszym rozwoju produktu– Sprint Review to “demo”, Zespół Deweloperski pokazuje zadania, które zrealizował, nie przeprowadzając dyskusji o kolejnych krokach rozwoju produktu
– Podczas Daily Scruma Zespół Deweloperski głównie skupia się na dyskusji dotyczącej realizacji Celu Sprintu– Podczas Daily Scruma Zespół Deweloperski odpowiada bezrefleksyjnie na “3 pytania” (co zrobiłeś… / co zrobisz … / czy masz blokady) – właściwa dyskusja o Celu Sprintu nie odbywa się
– Zespół Deweloperski wie, dlaczego, po co i dla kogo rozwija produkt– Zespół Deweloperski bezkontekstowo rozwiązuje zadania, nie rozumiejąc kontekstu produktu
– Zespół Deweloperski rozwija produkt, który sprawia, że życie ludzkie jest łatwiejsze lub przyjemniejsze– Zespół Deweloperski rozwija mało ambitny produkt, głównie po to, aby zarobić pieniądze

Podsumowanie

Oczywiście nie zawsze istnieje możliwość działania wyłącznie w sposób przedstawiony po lewej stronie tabelek (np. rozwój produktu dla klienta ze Stanów Zjednoczonych może ograniczać wachlarz godzin, w których odbywają się zdarzenia scrumowe), jeśli jednak rzeczywistość projektowa jest bliższa prawej stronie tabelki, to w mojej ocenie jest to niepokojący sygnał.

Bardzo łatwo dostrzec, że agile jest “kompatybilny” z podejściem, o którym opowiada Dan Pink. Na początku artykułu wspomniałem o Manifeście Agile – jego głębsza analiza, szczególnie 12 zasad zwinnego wytwarzania oprogramowania, pokazuje więcej punktów styku z teorią Dana, m.in. “najważniejsze dla nas jest zadowolenie Klienta” (poczucie celu) czy “najlepsze architektury, wymagania i projekty powstają w samoorganizujących się zespołach” (autonomia).

Całkiem podobnie wygląda to w Scrumie – samoorganizujące się zespoły (autonomia), nieustanna inspekcja oraz adaptacja procesu (mistrzostwo) czy skupienie na długofalowej wizji produktu (poczucie celu).

Nic więc dziwnego, że często mechaniczny, bezrefleksyjny “Scrum” po prostu nie działa tak, jak byśmy sobie życzyli. Dzieje się tak zarówno z powodu kiepskiej implementacji zasad frameworka, jak i z powodu dławienia motywacji u osób, które tworzą zespoły deweloperskie.

Zachęcam wszystkich, którzy na co dzień pracują z zespołami (członkowie zespołów, management) do zgłębienia wiedzy dotyczącej motywacji. “Drive” Dana Pinka wydaje się być doskonałą pozycją na start. Powodzenia!

Komentarze do wpisu: “Jak zwiększać motywację zespołów – przemyślenia po „”Drive” Dana Pinka

  1. W pewnej firmie :), podczas pracy nad dość dużym oprogramowaniem, team lider postanowił dać dużą autonomię zespołowi, łącznie z autozatwierdzaniem zadań. Doprowadziło to do załamania projektu i niedotrzymaniu podstawowej funkcjonalności – aplikacja nie potrafiła stworzyć najważniejszego raportu, będącego wynikiem wszystkich działań. W skrócie nic po drodze nie działało dobrze.
    Czego twoim zdaniem zabrakło?

    • Jacek Wieczorek

      Maciej – po Twoim opisie powiedziałbym, że zaproponowana autonomia była zbyt duża dla tego zespołu. Czego zabrakło? Niestety trudno ocenić po tym krótkim opisie – kompetencji? motywacji? odpowiedzialności? kontekstu biznesowego? Nie wiem, jak często dokonywaliście inspekcji postępu prac i czy były to inspekcje przeprowadzane przez dostatecznie świadome osoby – fakt, że zespół nie dostarcza wartości, powinien być zdiagnozowany wcześniej, np. poprzez cykliczne sesje, podczas których zespół prezentuje postęp prac stakeholderom.

    • Moim zdaniem zabrakło tutaj przede wszystkim wsparcia biznesowego, czyli:

      „– pozostawianie decyzji dotyczącej technicznej realizacji zadań (jak?) Zespołowi Deweloperskiemu, definiując wyłącznie co ma zostać wykonane (co?)”

      Zdrowego rozsądku chyba też zabrakło 😉

      @Jacek Wieczorek: przy okazji przeklejenia tego cytatu znalazłem literówkę „techniczej” 😉


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x