Odpowiedzialność w samoorganizujących się zespołach

Agile opiera się nie tylko na słynnym manifeście, ale też na 12 zasadach, które mu towarzyszą. Jedna z tych zasad to: “najlepsza architektura, wymagania i designy są dziełem samoorganizujących się zespołów”. Oczywiście każdy chce mieć jak najlepszy produkt, dlatego podążając za zasadami Agile, na popularności zyskały samoorganizujące się zespoły.

Samo pojęcie samoorganizującego się zespołu nie jest niczym nowym, pojawiło się w literaturze w połowie XX wieku, jednak zaczął zyskiwać na popularności w latach 90., głównie w USA. Obecnie jest to bardzo często spotykany model pracy. Członkowie takich zespołów mają wpływ na planowanie i rozdzielanie pracy między sobą. Są też odpowiedzialni za wybranie najbardziej efektywnych metod do osiągnięcia celów i nie potrzebują do tego dokładnych wytycznych od managera.

Dziś skupmy się na jednym czynniku, który musi tu wystąpić, by całość miała sens - a mianowicie na odpowiedzialności. W samoorganizujących się zespołach występuje interesujący balans odpowiedzialności, różny od tradycyjnego modelu.

Hierarchia a samoorganizacja

W strukturze hierarchicznej mamy osoby podejmujące decyzje i osoby, które je wykonują. Zakres odpowiedzialności zwykle jest dość sztywno określony. W praktyce jednak okazuje się, że, szczególnie w dużych organizacjach, odpowiedzialność z biegiem czasu staje się coraz bardziej podzielona i rozmyta. Dzieje się tak szczególnie przy zmieniających się wymaganiach i potrzebach. Wprawne osoby mogą unikać wzięcia jakiejkolwiek odpowiedzialności przez lata. By tak się nie stało, trzeba by idealnie rozplanować całość na części, które nie wymagają kooperacji.

W modelu samoorganizującym się występuje odwrotne podejście. Zespołowi jest powierzana większa część, za którą będzie w pełni odpowiedzialny. Na początku zwykle nie wiadomo co i jak będzie robiła konkretna osoba. Oczekuje się, że grupa rozdzieli między sobą pracę i opracuje plan wykonania całości. By tak się stało, konieczna jest wewnętrzna kooperacja.

Odpowiedzialność zespołowa a indywidualna

W autonomicznych zespołach powinno powstać poczucie odpowiedzialności zespołowej. Nie ma to w żadnym wypadku związku z odpowiedzialnością rozmytą, bo to następstwo odpowiedzialności odczuwalnej indywidualnie, przez każdą osobę z zespołu.

Od takich zespołów usłyszysz nieraz, że za ten czy inny obszar odpowiada cały zespół. Jeżeli wszystko funkcjonuje prawidłowo, zobaczysz to również w przypadku niepowodzeń. Wtedy zespół nie będzie szukać winnych, a raczej zabierze się do poszukiwania problemu i rozwiązania dla niego, mobilizując przynajmniej część zespołu.

Właśnie o takim podejściu usłyszałem z pierwszej ręki w czasie wywiadów związanych z Top Tech Employer w Rockwell Automation. Dla specjalistów, z którymi rozmawiałem było oczywiste, że za design komponentów czy odpowiednie rozdzielenie pracy odpowiada cały zespół. Nie ma w takim systemie jednej osoby, która o tym autorytarnie decyduje. Tak samo jest w przypadku problemów. To nie jedna osoba “zawaliła”, ale też zespół, przez niedostateczne wsparcie.

Jeżeli mamy do czynienia z podejściem “on zepsuł, niech naprawia”, to prawdopodobnie odpowiedzialność zespołowa nie jest jeszcze na poziomie optymalnym dla zespołów autonomicznych. Jest to przejaw niedostatecznego zaufania do innych członków zespołu.

Zaufanie jest tu kluczowe - nie można zbudować wspólnej odpowiedzialności bez niego. Musimy ufać, że nasi koledzy i koleżanki mają dobre intencje, umiejętności (a jeżeli mają niewystarczające, to nam o tym powiedzą) i że wspomogą nas, jeżeli będzie taka potrzeba, tak samo, jak my wspomożemy ich.

Bez zaufania między ludźmi z teamu, prędzej zauważymy tworzenie się silosów wiedzy. Każdy będzie dbać o swój mały ogródek, swój kącik w projekcie i będzie się raczej martwić, żeby nikt nie popsuł jego części, zamiast dbać o całość i sukces całego przedsięwzięcia.

Jeżeli pojawi się wzajemne zaufanie, to będzie szansa na to, że pojawi się również odpowiedzialność zespołowa, która powstanie z odpowiedzialności, którą indywidualnie czuje każda osoba z zespołu. W takiej sytuacji każdy nadal odpowiada za swoją pracę, jakość swojego kodu, rzetelność testów, wymyślony design, jednak staje się to częścią większej części.

W podobnym tonie wypowiadali się specjaliści Rockwell Automation w czasie przeprowadzonych z nimi wywiadów. Pomimo tego, że zespół odpowiada za projekt jako całość, a zanim cokolwiek zostanie wypuszczone w świat, trafia jeszcze na dalsze testy, to odpowiedzialność się nie rozmywa. Wszystkie 5 osób, z którymi rozmwaiałem podkreślało, że nie czują, żeby to zwalniało ich z obowiązku przykładania się do pracy. To od każdej osoby zależy dobre imię zespołu, którego są częścią.

Efekty uboczne odpowiedzialności zespołowej

Pojawienie się odpowiedzialności zespołowej ma ciekawe efekty uboczne. Przede wszystkim członkowie teamu zaczynają więcej myśleć o tym, co jest dobre dla grupy, a nie tylko dla nich. To promuje określone zachowania i zniechęca do innych.

W samoorganizujących się zespołach najczęściej zachodzi samoistna rotacja przy określonych zadaniach i częściach systemu. Wynika to z prostej kalkulacji. Jeżeli jedna osoba stanie się ekspertem od jednego obszaru, to choroba lub odejście takiej osoby zakłóci pracę zespołu, a to się nie opłaca.

Promowana jest również kooperacja. Jeżeli wszyscy mają wziąć za coś odpowiedzialność, to przynajmniej powinni wiedzieć, na co się piszą. To stwarza okazję do współpracy i wykorzystania wiedzy wszystkich członków zespołu, by wymyślić jak najlepsze rozwiązanie. To właśnie z tego wynika zasada agile, o której wspominałem na początku. Już na etapie wymyślania koncepcji angażowane jest więcej osób, które mają ekspertyzę i to procentuje dalej.

Dodatkowo odpowiedzialność zespołowa jest powiązana z projektem lub produktem, a nie jego częścią. W takim wypadku pracownicy łatwiej uznają projekt lub produkt za swój własny. Po angielsku nazwalibyśmy to ownership. Poczucie własności ma bardzo wiele pozytywnych skutków. By wymienić tylko kilka - wpływa na bardziej przemyślane podejmowanie decyzji, lepszą komunikację (szczególnie w ważnych kwestiach), lepszą jakość pracy. Pomaga też przeciwstawić się przełożonemu, o ile ten nie ma racji. Oczywiście nie wszystkie skutki są tu pozytywne. Osoby, które odczuwają ownership, mają większą tendencję do odpowiadania na krytykę w sposób defensywny, niż konstruktywny. Niektóre osoby mają też tendencję, do przeciwstawiania się zmianom w takiej sytuacji.

Podsumowanie

Zespoły samoorganizujące się mają wiele zalet i bardzo duży potencjał. Jednak odblokowanie tego potencjału wymaga odpowiedniego wsparcia ze strony managera/project ownera/scrum mastera. Na przykładzie tylko jednego parametru związanego z tego typu zespołami widać, że pozytywne efekty nie są gwarantowane. Nie można też wykluczyć powstania pewnych negatywnych efektów. Pojawienie się zdrowej odpowiedzialności może jednak zmienić zespół w najlepszą możliwą wersję.