Zaufanie w zespole scrumowym

Łukasz Tudzierz | | 22 marca 2019

Zaufanie jest fundamentem naszego życia społecznego, ważnym praktycznie w każdej jego dziedzinie. Jadąc samochodem, wierzymy, że inni będą przestrzegać zasad ruchu drogowego. Wchodząc w związek, ufamy, że druga osoba będzie dla nas wsparciem. Zostawiając dziecko w przedszkolu, wierzymy, że nie stanie mu się krzywda. A co z zaufaniem w miejscu pracy?

Zaufanie w miejscu pracy

Z raportu firmy doradczej EY „Globalne pokolenia 3.0. Badanie zaufania w miejscu pracy” opublikowanego w 2016 roku wynika, że mniej niż połowa pełnoetatowych pracowników ma zaufanie do swojego pracodawcy, przełożonego i kolegów.

Badanie EY, mimo że przeprowadzone na próbie międzynarodowej, możemy zaadaptować do warunków polskich. W kolejnym, tym razem krajowym badaniu CBOS z marca 2018 roku, przeczytamy: „Tylko nieco ponad jedna piąta badanych (22%) wychodzi z założenia, że większości ludzi można ufać, ponad trzy czwarte zaś (76%) wyznaje zasadę zachowywania daleko posuniętej ostrożności i podejrzliwości w stosunkach z innymi”. Nieco lepiej wygląda sytuacja w biznesie. 34% ankietowanych badania CBOS uważa, iż zaufanie do partnerów w interesach na ogół się opłaca, natomiast 37% twierdzi, że na ogół źle się ono kończy. 29% nie ma zdania.

Rezultaty powyższych badań nie napawają optymizmem. Wynika z nich bowiem, iż wedle ostrożnych szacunków prawie połowa pracowników nie ufa osobom, z którymi pracuje! Na konsekwencje wynikające z braku zaufania do przełożonego i kolegów nie trzeba długo czekać: spada zaangażowanie, zmniejsza się produktywność, zanikają pomysłowość i chęć wychodzenia z własnymi inicjatywami. Brak zaufania sprawia, że miejsce pracy zaczynamy postrzegać w kategoriach nieustannego zagrożenia czyhającego ze strony osób, które nas otaczają.

W tym artykule chciałbym skupić się na zaufaniu w miejscu pracy na przykładzie zespołów scrumowych, których byłem i jestem członkiem.

Odpowiedzialność w Scrumie

Scrum jako framework pracy stawia na podejście zespołowe i samoorganizację. Co to oznacza w praktyce? Odchodzimy od modelu, w którym wdrożenie rozwiązania wymaga długiego planowania, tworzenia tysięcy stron dokumentacji i stałego nadzoru project managera. W zespole scrumowym planujemy naszą pracę, dzieląc ją na krótsze, np. dwutygodniowe odcinki czasu, czyli tak zwane Sprinty. Daje nam to większą kontrolę i elastyczność, pozwala szybko dostrzegać zagrożenia i reagować na nie. Zamiast tworzyć obszerne dokumenty, tworzymy działające oprogramowanie.

W takim zespole nastawionym na samoorganizację kluczową rolę odgrywa poczucie odpowiedzialności. W Przewodniku po Scrumie czytamy: „Mimo iż pojedynczy członkowie zespołu deweloperskiego mogą posiadać wyspecjalizowane umiejętności i mogą skupiać się na konkretnych dziedzinach, odpowiedzialność za wykonywaną pracę ponosi cały zespół deweloperski”. Innymi słowy, w zespole deweloperskim panuje odpowiedzialność zbiorowa, a nie odpowiedzialność jednostek za wykonanie poszczególnych zadań. Sceptycy pomyślą zapewne: „Skoro nie ma jednej odpowiedzialnej osoby, nikt nie będzie poczuwał się do odpowiedzialności za wykonanie danego zadania. Jeśli w jakimkolwiek zespole (nie tylko deweloperskim) doświadczymy takiego odczucia rozmytej odpowiedzialności, może to oznaczać, że jesteśmy świadkami głębokich nieprawidłowości w jego funkcjonowaniu.

Zaufanie w Scrumie

Bazując na moim doświadczeniu wyniesionym z pracy w zespołach scrumowych, jestem przekonany, że powierzenie odpowiedzialności za pracę zespołowi jest pożądane nie tylko ze względów motywacyjnych. Przede wszystkim dzięki takiej organizacji pracy otrzymamy produkt o znacznie większej wartości. Deweloper – czyli ekspert w swojej dziedzinie – zna plusy i minusy, zagrożenia i możliwości, jakie potencjalnie wiążą się z techniczną implementacją zadania. Także codzienna komunikacja z klientami, otwartość na problemy oraz szanse sprawia, iż pod koniec każdego Sprintu Product Owner otrzymuje w pełni działającą i funkcjonalną część aplikacji.

Filary Scruma

• Odwaga – wyobraźmy sobie, że deweloper pracuje nad przypisanym do niego zadaniem i w trakcie trwania Sprintu orientuje się, że brak mu wiedzy technicznej, aby je zrealizować. Zastanawia się, co zrobić: jak zdobyć wiedzę? A może zostać po godzinach, aby nie zawieść zespołu? Ma problem, lecz boi się przyznać, że potrzebuje wsparcia. Odwaga w zespole scrumowym to zatem także umiejętność powiedzenia na głos: potrzebuję pomocy. Aby ją uzyskać, niezbędna będzie kolejna wartość, czyli…
• Otwartość – bycie otwartym jest wpisane w model pracy zespołowej, nikt z nas nie jest przecież samotną wyspą. To otwartość na nowe rozwiązania, pomysły, zmianę toku myślenia. Może inny deweloper zaproponuje, by skomplikowane zadanie wykonać zupełnie inaczej? Otwartość to także świadomość zespołu, który zna swoje mocne i słabe strony. I co ważne – nie ukrywa tego przed sobą ani interesariuszami.
• Zaangażowanie – idąc dalej za naszym przykładem: skoro deweloper zdecydował się podzielić wątpliwościami z zespołem, a ten otwarcie zareagował chęcią niesienia pomocy, nie poprzestajemy na deklaracjach, lecz angażujemy się w rozwiązanie problemu: wspólnie – zarówno deweloper, jak i zespół scrumowy – robimy wszystko, co w naszej mocy, aby usunąć przeszkodę.
• Poszanowanie – aby zdobyć się na odwagę i otwarcie opowiedzieć o problematycznym zadaniu, deweloper musi mieć pewność, że zespół go nie zdyskredytuje, nie wyśmieje, lecz wesprze i zaangażuje się w wypracowanie rozwiązania. W zespołach scrumowych, gdzie komunikacja odgrywa kluczową rolę, szacunek jest absolutną podstawą. W codziennej komunikacji zdarzają się różnice zdań, pomysłów, czasem trzeba przeanalizować niepowodzenia. W takim modelu pracy konstruktywna krytyka i wzajemny szacunek są konieczne, by zbudować zaufanie.
• Skupienie – w pracy nad określonym problemem konieczne są skupienie i analiza priorytetów. W tej określonej sytuacji, chcąc pomóc deweloperowi, bierzemy pod uwagę inne zadania w Sprincie, nasze priorytety, słowem: podchodzimy do zadania zwinnie. Może warto zastanowić się nad jak najprostszym rozwiązaniem problemu, tak by nie ucierpiały inne cele Sprintu? Aby osiągnąć optymalne efekty, niezbędne tu będą synergia, skupienie i pomysły wielu osób – te zawsze dają lepsze efekty końcowe.

Korzyści

W codziennej mojej pracy jako Scrum Master obserwowałem wiele sytuacji i zauważyłem, iż osobista porażka przed zespołem, w którym się pracuje, jest wielokrotnie bardziej dotkliwa niż porażka przed klientem lub przełożonym. W Scrumie jesteśmy częścią zespołu, wspólnie pracujemy na najlepszy efekt. Przywołane wcześniej w artykule konsekwencje braku zaufania – czyli brak zaangażowania, pomysłowości, inicjatywy – mogą być destrukcyjne w skutkach dla zespołu pracującego w modelu scrumowym, gdzie stanowią tak naprawdę podstawę jego działania. Wracając do roli odpowiedzialności względem zespołu – to ona sprawia, że staramy się nie zawieść zaufania, jakim obdarzył nas zespół. Dążymy do wykonania pracy jak najlepiej. Z kolei na barkach liderów spoczywa odpowiedzialność za tworzenie atmosfery wzajemnego zaufania. Widząc przykład płynący z góry organizacji, łatwiej jest formować zespoły oparte na ufności, zaangażowaniu i wzajemnej pomocy.

Przeczytaj także: Dlaczego Sprinty bywają nieudane i Product Owner – bohater ostatniej akcji.