Scientific Agile

Dzisiaj będzie o motywacji, a szczególnie o tym, jaki jest obecny stan wiedzy na jej temat i co praktycznego z niego wynika. Zanim zagłębimy się w wyniki moich badań, chcę przedstawić w zarysie teorię, do której się będę odnosić.

Teoria autodeterminacji stworzona przez Ryana i Deciego (Self-Determination Theory) opisuje motywację oraz czynniki, które wpływają na powstawanie różnych jej rodzajów. Badania prowadzone na całym świecie mówią o jej wpływie na wydajność, satysfakcję czy rozwiązywanie złożonych problemów. Motywacja jest przez autorów opisana na continuum, od motywacji kontrolowanej tylko przez czynniki zewnętrzne do takiej, która jest wyłącznie wewnętrzna. Wyróżnione są po kolei następujące rodzaje motywacji:

• Motywacja zewnętrzna – czyli działanie w celu uzyskania nagrody (może nią być też pochwała) lub uniknięcia kary (dezaprobaty, krytyki); aby taki rodzaj motywacji działał, konieczna jest ciągła obecność motywatora, czyli na przykład uczniowie rozwiązują zadania, tylko jak nauczyciel patrzy, albo pracownicy pracują tylko dlatego, że im za to płacą.
• Uwewnętrzniona motywacja zewnętrzna – czyli działanie, aby uniknąć poczucia winy lub wstydu; mimo, że te uczucia są wewnętrzne, to jednak powstają w wyniku uczenia się i dostosowania do zewnętrznych oczekiwań; badacze ten i poprzedni rodzaj motywacji uważają za motywację kontrolowaną (przez czynniki zewnętrzne).
• Motywacja wynikająca ze zrozumienia celu, czyli działanie jest podejmowane i kontynuowane dlatego, że rozumiemy, że jest ono ważne, że dana czynność jest komuś potrzebna; dla nas samych nie jest to istotne, ale akceptujemy powody, dla których trzeba to zrobić;
• Motywacja oparta na zgodności celu z własnymi wartościami i postawami; dane działanie jest dla nas ważne, utożsamiamy je z tym, jak chcemy postępować; jest zbieżne z naszymi celami; ten i poprzedni rodzaj to motywacje autonomiczne.

Wszystkie cztery wymienione do tej pory rodzaje motywacji pochodzą pierwotnie z zewnątrz, różny jest tylko stopień, w jakim zostaną przyjęte za własne. Istnieje jeszcze motywacja wewnętrzna, czyli taka, kiedy robimy coś dla przyjemności jaką nam to sprawia.

Aby to lepiej zrozumieć, wyobraźmy sobie następującą sytuację: mamy firmę, w której stosuje się jakiś specyficzny rodzaj testów. Do firmy przychodzi nowy pracownik. W pierwszym dniu pracy dowiaduje się, że będzie musiał pisać takie testy. Chcąc uniknąć dezaprobaty (albo chcąc zyskać akceptację), zacznie je pisać (pierwszy rodzaj motywacji – zewnętrzna). Jeśli będzie pracował z zespołem, w którym wszyscy piszą te testy, to po pewnym czasie będzie to robił, bo czułby się nieswojo, gdyby ich nie napisał (drugi rodzaj – unikanie poczucia winy bądź wstydu). Jeśli jednak będą zaspokojone potrzeby określone w teorii autodeterminacji, to po pewnym czasie będzie rozumiał, dlaczego te testy są istotne i będzie przekonany do ich pisania (trzeci rodzaj – zrozumienie ważności). Jeśli te potrzeby będą zaspokojone w odpowiednim stopniu, to na koniec nasz pracownik będzie sam orędownikiem pisania tych testów i ich tworzenie będzie uważał za coś, co jest zgodnie z jego wartościami i tym, jak chce tworzyć oprogramowanie (czwarty rodzaj – zgodność z własnymi celami i postawami).

Opisany proces, to uwewnętrznianie pierwotnie zewnętrznych wymagań, prowadzące do ich przyjęcia za własne. Istnieje jeszcze motywacja wewnętrzna – to działanie dla samego działania, robienie czegoś, co nam sprawia przyjemność. Na przykładzie naszego pracownika może to być wymyślanie architektury, które jest dla niego atrakcyjne i za które chętnie będzie się brał sam z siebie.

Mam nadzieję, że ten przykład wyjaśnia różnicę pomiędzy poszczególnymi rodzajami motywacji. Najczęściej praca złożona, wymagająca intelektualnie, polegająca na pracy koncepcyjnej (a taka jest praca Zespołów Scrumowych) składa się zarówno z rzeczy, które są przyjemnością, jak i takich, które są nużące, trudne albo po prostu nieciekawe. Dlatego ważne jest, żeby mieć motywację wewnętrzną, która pozwala brać się z entuzjazmem za niektóre czynności, ale potrzebna jest też autonomiczna motywacja zewnętrzna, czyli zrozumienie celu, albo (najlepiej) zgodność tego celu z własnymi dążeniami. Tylko połączenie dwóch rodzajów motywacji pozwala robić wytrwale zarówno rzeczy przyjemne, jak i te mniej pociągające, a potrzebne.

Zgodnie z teorią autodeterminacji, o tym, na ile wymagania zewnętrzne mogą być przyjęte jako własne, decyduje zaspokojenie trzech potrzeb:

• Kompetencji (na powyższym przykładzie – musimy umieć pisać te testy, robić to z łatwością i dobrym rezultatem, rozumieć ich znaczenie, wiedzieć, dlaczego zostały wybrane oraz wiedzieć, jakie są konsekwencje ich niestosowania).
• Relacji – to, na ile będziemy przyjmowali wymagania zależy od tego, kto je wprowadza. Jeśli identyfikujemy się z zespołem, z którym pracujemy, to łatwo przejmiemy jego standardy za własne; jeśli mamy dobre relacje z przełożonym, to szybciej będziemy akceptowali jego wymagania (nawet, jeśli na początku nie jesteśmy do nich przekonani).
• Autonomii – jest niezbędna, żeby jakieś wymagania przyjąć za swoje. Jeśli nie mamy wyboru, jesteśmy do czegoś zmuszani, to nie ma mowy o tym, żebyśmy akceptowali dany standard jako własny. Z badań wynika, że dopiero przy autonomii wyboru ludzie zaczynają mieć autonomiczne rodzaje motywacji.

Motywacja kontrolowana (nagrody, kary, współzawodnictwo) lub taka oparta na poczuciu winy bądź wstydu może być chwilowo użyteczna przy wykonywaniu niewymagających intelektualnie, rutynowych działań. Jednak nawet wtedy skutkuje wypaleniem, większą absencją w pracy i większą rotacją pracowników. W przypadku pracy umysłowej jej konsekwencje są prawie wyłącznie negatywne – spadek zaangażowania, mniejsza kreatywność, mniejsza wytrwałość, mniejsza wydajność, większa ilość błędów (oraz oczywiście – wszystkie wymienione przed chwilą konsekwencje). Co więcej, brak autonomii powoduje, że wydajność przestaje mieć przełożenie na satysfakcję. Ludzie będą pracować, ale nie będą mieli z tego satysfakcji! Większość z nas zna sytuację (jeśli nie z własnego doświadczenia, to z opowieści znajomych), kiedy nie byliśmy się w stanie utożsamiać z projektem, który wykonywaliśmy, uważaliśmy wykonywane zadania za bezsensowne i gdyby nie to, że trzeba spłacić kredyt (albo z dowolnego innego powodu), to byśmy najchętniej rzucili tę pracę jeszcze tego samego dnia. Czuliśmy tak, mimo że w innych warunkach część zadań mogłaby nam sprawić przyjemność albo moglibyśmy być zadowoleni z ich wykonania. Najczęściej taki efekt występuje właśnie wtedy, kiedy jest wysoki poziom motywacji kontrolowanej, a niski autonomicznej.

W dzisiejszym artykule chcę pokazać kolejne wyniki związane z Daily, tym razem dotyczące różnych rodzajów motywacji. Następnie wyjaśnię, jakie wnioski można z tego wyciągnąć, oraz co można zrobić praktycznie na poziomie Zespołu Deweloperskiego. W kolejnych artykułach będę opisywała motywację pod względem wydajności zespołu oraz działań, jakie może podjąć Właściciel Produktu albo menedżer.

W poprzednim artykule opisywałam wpływ autonomii na funkcjonowanie zespołu. Następnym krokiem w moich badaniach było sprawdzenie, czym się różnią zespoły, które lepiej rozumieją, jakie korzyści może im dawać Daily od tych, które osiągają z niego mniejsze profity. (Sposób oceny Daily i wprowadzenie do tych badań jest tutaj.) W tym celu podzieliłam zespoły na dwie grupy – nazwijmy je „Mniejsza korzyść z Daily” i „Większa korzyść z Daily”. Ponieważ skala pytania o dostrzeganą korzyść była od 1 do 6, to za punkt podziału przyjęłam 3,5. W pierwszej grupie były zespoły, których średnia była równa lub poniżej tej wartości, w drugiej te, których średnia była powyżej. Liczebność obu grup była zbliżona – 41 i 47 osób, w każdej było po 6 zespołów. Porównałam następnie osoby z tych grup testem T-Studenta pod względem motywacji autonomicznej i kontrolowanej.

Osoby z zespołów, które były w grupie „Mniejsza korzyść z Daily” miały znacząco wyższą średnią “Motywacja kontrolowana” przedstawioną w postaci amarantowych słupków (p=0,031; średnia grupy „Mniejsza korzyść z Daily” = 6,35; średnia grupy „Większa korzyść z Daily” = 5,47). Nie było istotnej statystycznie różnicy w poziomie motywacji autonomicznej (niebiekie słupki). Oznacza to, że te zespoły, które miały mniejszą motywację kontrolowaną lepiej rozumiały, jakie korzyści może przynieść Daily.

Wnioski, jakie można wyciągnąć z tych wyników są w 100% zgodnie z teorią – jeśli ktoś chce mieć zaangażowanych pracowników, którzy widzą sens w swojej pracy, to nie powinien podnosić im motywacji kontrolowanej! Będzie to powodowało obniżenie zaangażowania, ale też utrudniało dostrzeganie sensu w tym, co robią. Jak widać dotyczy to również zrozumienia procesu i dostrzegania wartości Daily.

Część ludzi, na których wywiera się presję, zacznie się zachowywać biernie, wykonując jedynie polecenia, część – odejdzie, jeśli będzie miała szansę. Zapamiętajmy więc, że obiecywania nagród, grożenia karami albo obwiniania członków zespołu, zachęcania ich do rywalizacji między sobą – należy unikać za wszelką cenę, jeśli zależy nam na świadomym i zaangażowanym zespole.

W tym wpisie nie chcę się bardziej nad tym rozwodzić, ale jest wiele badań (eksperymentalnych i prowadzonych w warunkach naturalnych) pokazujących, że zwiększenie motywacji kontrolowanej przy tego typu pracy, jaką wykonują Zespoły Scrumowe, prowadzi do pogorszenia wyników, zarówno pod względem zaangażowania, jak i jakości tego, co jest wytwarzane. Na końcu artykułu jest podana bibliografia.

Nie znaczy to, że nie należy ludzi odpowiednio wynagradzać. Oczywiście, pensja jest ważna, ale najlepiej jest płacić średnią stawkę albo trochę powyżej, a za to w inny sposób zadbać o zaangażowanie pracowników. Dla wielu Deweloperów znacznie bardziej motywujący jest dobry zespół, możliwość rozwoju, uczestniczenia w ciekawych projektach, poznawania nowych technologii, posiadania wpływu na sposób tworzenia Przyrostu i na pracę firmy. Patrząc przez perspektywę teorii autodeterminacji, jest to wspieranie autonomicznych typów motywacji poprzez zaspokojenie trzech potrzeb: relacji (zespół, relacje w firmie), kompetencji (rozwój, ciekawe projekty, nowe technologie) i autonomii (samoorganizacja Zespołu Scrumowego, wpływ na podejmowane decyzje).

Zdaję sobie sprawę z tego, że dotykam jednego z większych mitów funkcjonujących w świadomości społecznej. Powszechnie uważa się, że jeśli chce się kogoś zmotywować, to trzeba mu obiecać jakąś korzyść. Nie jest to prawdą. Osoby, których praca polega na znajdowaniu rozwiązań, najwydajniej pracują, jeśli mają wysoką motywację autonomiczną i niską kontrolowaną.

Jednak nie zawsze zespół ma wpływ na politykę zatrudniania firmy. Co więc można zrobić na poziomie Zespołu Scrumowego, aby zaspokoić potrzeby kompetencji, relacji i autonomii?

W przypadku autonomii jest to dosyć proste, szczególnie, jeśli rozumiemy jej wagę. Na poziomie codziennej pracy ważne jest, żeby istniała swoboda wyboru zadań do wykonania, czyli żeby każdy członek Zespołu mógł swobodnie decydować, jakim następnym zadaniem się zajmie. To wymaga, żeby w czasie Pielęgnowania Backlogu, a potem Planowania zadbać o kilka rzeczy.

Po pierwsze, wszyscy członkowie Zespołu muszą mieć taką samą wiedzę na temat ważności poszczególnych zadań, ich wzajemnej zależności oraz ich wpływu na dostarczany Przyrost. Jeśli tak będzie, to kolejność wyboru zadań do realizacji będzie wynikała z racjonalnych powodów. Jest jednak ważne, żeby akceptować to, że ktoś może chcieć robić zadania we własnym rytmie – na przykład jedno ciekawe, jedno nudne, albo najpierw trudne, a potem łatwe. O ile nie powoduje to negatywnych konsekwencji dla dostarczanego Przyrostu, Zespół powinien akceptować tego typu strategie. Świadomy zespół w sytuacji, kiedy nie można sobie pozwolić na taki sposób uprzyjemniania pracy, będzie to rozumiał i sam sobie narzuci ograniczenia, żeby najpierw zrobić najpilniejsze i najważniejsze zadania, nawet jeśli nie są zbyt przyjemne.

Po drugie, ważna jest swoboda wyboru sposobu realizacji zadania. Jeśli Zespół zadba o to, żeby wymagania były dobrze określone, przegada ze sobą możliwe podejścia do problemu, to każdy będzie mógł sam wybrać sposób realizacji. Najczęściej ten aspekt autonomii jest zaburzony w zespołach, w których istnieje “guru”, który narzuca innym, co i jak mają robić. Bardzo ważne jest, żeby takiej osobie wytłumaczyć negatywne konsekwencje tego, jak postępuje. Często pokazanie, że taka osoba może zadbać o ważne aspekty architektoniczne czy wydajnościowe podczas doprecyzowywania kryteriów akceptacji, pozwala uniknąć narzucania rozwiązań w czasie pracy w Sprincie. W przypadkach skrajnych, kiedy osoba jest niereformowalna i narzuca zespołowi swoje pomysły, warto zastanowić się nad zabraniem jej z zespołu. Znane mi przypadki wskazują, że wbrew obawom, następuje wtedy gwałtowny rozwój pozostałych członków zespołu i większe przejęcie przez nich odpowiedzialności za wytwarzany Przyrost, co skutkuje lepszymi wynikami. Zaś taka osoba, po odpowiednim przeszkoleniu, może być świetnym mentorem, uczącym wiele różnych Zespołów Scrumowych i dbającym o jakość na poziomie całej firmy.

W moich badaniach sprawdziłam korelacje pytania ze skali autonomii “Zawsze jestem uzależniony od decyzji kogoś innego”. Skala odpowiedzi była od 1 – “Zdecydowanie się zgadzam” do 5 – “Zdecydowanie się nie zgadzam”. Wynik korelacji z motywacją autonomiczną jest istotny statystycznie p = 0,0002 r Pearsona = 0,384 N = 90. Pokazuje to, że właśnie ta zależność od decyzji innych jest czynnikiem, który bardzo silnie wpływa na spostrzeganą autonomię, a przez to na motywację autonomiczną. Korelacja z motywacją kontrolowaną nie jest istotna statystycznie. Ten wynik uświadamia nam, że na poziomie zespołu konieczne jest zadbanie o swobodę podejmowania decyzji. Jak to można zrobić opisuję w ćwiczeniu na końcu artykułu.

(Na wykresie nie ma pierwszego słupka, dlatego, że spośród 90 osób biorących udział w badaniu nikt nie odpowiedział “Zdecydowanie zgadzam się”).

Zaspokojenie potrzeb relacji, kompetencji i autonomii w Zespole

Samemu budowaniu relacji w Zespole będzie poświęcony osobny artykuł, dzisiaj chcę tylko wspomnieć o tym, co może zastosować zespół samodzielnie. Techniką, która bardzo się może przydać jest code review. Aby jednak przyniosło korzyść nie tylko w postaci lepszego kodu, ale również lepszych relacji, niezbędne jest, żeby było oparte o wzajemny szacunek i odbywało się zawsze na poziomie merytorycznym, nie schodziło na poziom personalny. Jeśli konieczne jest odrzucenie czyjegoś kodu albo zgłoszenie do niego krytycznych uwag, to trzeba to zawsze wyjaśniać, pokazując ewentualne negatywne konsekwencje oraz tłumacząc, dlaczego inne rozwiązania są lepsze.

Bardzo ważne jest też, żeby istniał łatwy sposób rozwiązywania ewentualnych kwestii spornych. Dobrym sposobem jest zaakceptowanie przez cały zespół “Rady Starszych” złożonej z osób spoza zespołu, która mogłaby rozstrzygać w sytuacjach konfliktowych. Powinny to być osoby (albo osoba), które cieszą się szacunkiem i zaufaniem całego Zespołu Deweloperskiego. Wtedy, w przypadku wystąpienia sytuacji spornej, można się odwołać do takiej “Rady Starszych” z prośbą o wyjaśnienie wątpliwości. Tego typu proste rozwiązanie nie tylko pozwala wychodzić z trudnych sytuacji, ale też często im zapobiega. Jeśli w “Radzie Starszych” są osoby cenione przez zespół, to większość Deweloperów będzie dbała o to, żeby dobrze wypaść, a tym samym będzie unikała niemerytorycznych konfliktów.

Poniżej opisałam ćwiczenie, które pozwala popatrzeć na autonomię i kompetencje poprzez pryzmat wysokiej jakości wytwarzanego Przyrostu. Często, jeśli w zespole są Juniorzy, na wiele sposobów kontroluje się ich albo narzuca im sposób tworzenia Przyrostu. Dobry zespół jednak umie to zrobić w sposób transparentny, tak aby pokazać Juniorowi, że uzyskanie większej swobody jest uzależnione od zdobycia większych kompetencji, a nie jest kwestią personalną.

Autonomia wymyślania i tworzenia rozwiązania nie oznacza jednak całkowitej dobrowolności. Każdy element Backlogu ma dostarczyć jakąś funkcję, której wymagania są znane i określone. Również dobre praktyki inżynierskie oraz ogólne wymagania projektu narzucają część Kryteriów Akceptacji albo elementów Definicji Ukończenia. Dlatego Zespół musi z jednej strony wspierać autonomię, a z drugiej zapewnić mechanizmy kontrolne, które pozwalają całemu Zespołowi mieć pewność, że jakość wytwarzanego Przyrostu jest wysoka oraz stabilna w czasie.

Sposoby, w jakie zespół sam siebie monitoruje mają na celu 1) zbudowanie świadomości, że “to co robię ktoś sprawdzi” – już sama transparencja powoduje większą staranność oraz 2) możliwość wychwycenia tych błędów, o których twórca nie pomyślał. Obie te rzeczy nie są związane z poziomem kompetencji, bo mylić się albo zapomnieć o czymś może absolutnie każdy, od zupełnego Juniora do doświadczonego Seniora.

Najpopularniejszymi sposobami monitorowania są opisane powyżej review kodu oraz testowanie przez inną osobę niż autor. Specjalnie nie piszę tutaj o dedykowanej roli testera, bo można to robić pomiędzy Deweloperami. Oczywiście nie dotyczy to tylko kodu – również UXowiec może poprosić innego członka zespołu o sprawdzenie, czy to, co przygotował jest zgodne z Kryteriami Akceptacji i Definicją Ukończenia. W jednym z ciekawszych zespołów, w jakim pracowałam review zapytania (raportu z bazy) było robione na rzutniku i uczestniczyli w nim wszyscy Deweloperzy. Koszt czasowy był duży, ale zysk w postaci zwiększania kompetencji (które były zróżnicowane), uwspólniania wiedzy domenowej i możliwości zastępowania się członków zespołu w przypadku absencji – był znacznie większy.

Ćwiczenie retrospektywa autonomii w Zespole

Cel ćwiczenia:

• Określenie sposobów monitorowania, które mają na celu zapewnienie odpowiedniej jakości
• Określenie autonomii każdego członka Zespołu Deweloperskiego
• Określenie kompetencji potrzebnych do uzyskania większej autonomii
• Ustalenie planu zmian w sposobie pracy Zespołu
• Ustalenie planu zdobywania kompetencji, szczególnie tych wymagających współpracy z innymi członkami Zespołu.

Będą potrzebne:

• Tablica albo flipchart z kilkoma kartkami
• Mazaki
• Wydrukowane kartki, po jednej dla każdego członka zespołu (ewentualnie jakiś zapas na wszelki wypadek)
• Długopisy albo ołówki

Sposób wykonania:

Na początku należy określić, jakie mamy sposoby (potencjalnie, nie tylko te stosowane do tej pory) zapewnienia wysokiej jakości Przyrostu. Chodzi o sposoby sprawdzania, czy zostały uwzględnione wszystkie wymagania, zastosowane dobre praktyki inżynierskie, czy jest zapewniona zgodność z Definicją Ukończenia. Wszystkie te sposoby wypisujemy na tablicy albo flip charcie. Mogą to być zarówno opisane w artykule pomysły, jak też wszystkie inne rzeczy, które przychodzą do głowy Zespołowi.

Teraz czas na pracę indywidualną każdego członka Zespołu. Rozdajemy wydrukowane kartki i prosimy o wypełnienie pierwszej kolumny – “O jakich rzeczach mogę sam decydować?”. Dajemy na to Zespołowi 5 minut.

Następnie prosimy Deweloperów o odwrócenie kartki i wypełnienie kolumny “O jakich rzeczach nie mogę sam decydować?”. Na to również dajemy 5 minut. Jeśli Zespół woli, to można dać im 10 minut na obie te kolumny, bo dla niektórych wygodniejsze jest równoległe ich wypełnianie.

Kolejna część ćwiczenia polega na wspólnym uzupełnieniu przez Zespół kartek. Prosimy, aby się ktoś zgłosił na ochotnika i wspólnie, jako cały Zespół, uzupełniamy kolumnę “Jak sprawdzamy, czy uwzględniłem wszystko albo nie pomyliłem się?”. Ważne, żeby myśleć o tym z perspektywy tego, jak chcemy pracować, a nie tego, jak robiliśmy to do tej pory. Wykorzystujemy sposoby monitorowania, które wypisaliśmy sobie wcześniej na tablicy. Jeśli przyjdą nam jakieś dodatkowe pomysły do głowy, jak możemy sprawdzać jakość i użyteczność Przyrostu, to również dopisujemy je do kartki ze sposobami.

Po skończeniu wypełniania tabelki dla pierwszej osoby powtarzamy to ćwiczenie dla każdej kolejnej – powinno to iść coraz szybciej, bo wiele rzeczy będzie się powtarzać. Wynikiem jest:

1. świadomość Zespołu, jaka jest autonomia pracy (której często nie dostrzegają i nie doceniają)
2. konkretne pomysły na zapewnienie jakości przez Zespół Deweloperski.

Często takie ćwiczenie pozwala zmienić perspektywę i popatrzeć świeżym okiem na sposób pracy Zespołu, oraz znaleźć nowe pomysły na to, jak można współpracować.

Kiedy Zespół ukończy uzupełnianie pierwszej strony dla wszystkich członków zespołu, przechodzimy do drugiej strony. To również robimy całym Zespołem. Dla każdego punktu określamy, czego dana osoba powinna się nauczyć. Możemy tutaj wpisywać różnego typu rzeczy – zagadnienia do samodzielnego nauczenia się, webinaria, które można obejrzeć, książki albo artykuły do przeczytania, dokumenty, z jakimi trzeba się zapoznać, albo tematy, które wyjaśni inny członek zespołu.

Po ustaleniu, jak można tę wiedzę i umiejętności zdobyć, czas na zdefiniowanie przez Zespół Deweloperski, jak to można zweryfikować. To również mogą być bardzo różne rzeczy, na przykład: “każdy Senior podczas review kodu stwierdzi, że stosujesz zdobytą wiedzę”, “twoje zapytanie będzie miało czas wykonywania mniejszy niż XXX”, “wewnętrzny audyt bezpieczeństwa zaakceptuje rozwiązanie”, i wszelkie inne konkretne miary, które przyjdą do głowy Zespołowi. Ważne jest, żeby było jasne, że ma to na celu zapewnienie dobrej jakości przez zespół i nie jest w żaden sposób kwestią uznaniową czy personalną.

Relacja między “umiesz” -> “możesz sam decydować” musi być absolutnie transparentna dla KAŻDEGO członka zespołu, a sposób zmierzenia tego musi być jawnie określony.

Najczęściej takie postawienie sprawy znacznie zwiększa motywację Juniorów, którym łatwiej jest teraz patrzeć na zdobywanie przez siebie umiejętności przez pryzmat stawania się pełnoprawnym, decyzyjnym członkiem Zespołu. Jednocześnie pokazuje to Seniorom, że czas poświęcany na naukę Juniorów jest skończony i w dłuższej perspektywie uczestniczą w rozwoju swojego partnera, od którego również będą się uczyć oraz będą nawzajem monitorować swoją pracę.

Aby ćwiczenie miało trwały rezultat należy na koniec podsumować obie części. Na poziomie Zespołu należy przekuć wnioski w konkretny plan ich wprowadzenia. Zmiany w sposobie pracy należy zaplanować na kolejne Sprinty oraz ustalić, kiedy Zespół sprawdzi, czy jest zadowolony z wprowadzonych zmian i wprowadzi ewentualne korekty (jak zawsze – Plan, Inspekcja i Adaptacja).

Na poziomie poszczególnych osób, dobrze jest ustalić kolejność zdobywania poszczególnych umiejętności, szczególnie tych, które wymagają czasu poświęcanego przez innych Deweloperów (jak zwykle pod tym pojęciem rozumiem każdego członka Zespołu innego niż Właściciel Produktu i Scrum Master). Generalnie dobrze jest, żeby rzeczy, które mogą wpłynąć na wydajność były przez Zespół planowane. Tego typu ćwiczenie, porządkujące pomysły na rozwijanie kompetencji, należy raz na kilka miesięcy powtarzać. Planowanie rozwoju w Zespole Deweloperskim ma ograniczony horyzont czasowy z uwagi na zmienne środowisko.

Na co zwrócić uwagę:

Mogą być takie zespoły, które mają pustą drugą kartkę – świadczy to o bardzo wysokiej autonomii i kompetencji w zespole. Jeśli tak jest, to świetnie. Wtedy główna korzyść z ćwiczenia jest na pierwszej stronie, zaś zamiast ćwiczenia z autonomii można zaproponować ćwiczenie typu macierz kompetencji (będzie opisane w kolejnych artykułach).

Może być też tak, że brak autonomii nie dotyczy spraw wewnętrznych zespołu, ale zewnętrznych. Jeśli jest dużo takich rzeczy (i nie wynikają one z “twardych wymagań” projektu), to należy sprawdzić w organizacji czy rzeczywiście tak jest. Pamiętam szkolenie, które prowadziłam dla dwóch zespołów z tego samego segmentu firmy. Jeden był przekonany, że mogą o pewnych rzeczach decydować i czuł się autonomiczny, drugi był przekonany, że jest znacznie mniej możliwości. Rozmowa pokazała, że wiele z ograniczeń, jakie utrudniały życie drugiemu zespołowi, nie było tak twardych, jak im się wydawało. Ale o zarządzaniu Zespołem będzie w następnym artykule.

Bibliografia

Deci, E. L., Olafsen, A. H., & Ryan, R. M. (2017). Self-determination theory in work organizations: The state of a science. Annual Review of Organizational Psychology and Organizational Behavior, 4, 19-43.

Gagné, M., & Deci, E. L. (2005). Self-determination theory and work motivation. Journal of Organizational Behavior, 26, 331-362.

Deci, E. L., & Ryan, R. M. (2000). The 'what’ and 'why’ of goal pursuits: Human needs and the self-determination of behavior. Psychological Inquiry, 11, 227-268.