Czym właściwie jest samoorganizujący się zespół? Jak go utworzyć? I dlaczego tak ważne jest tworzenie środowiska Agile?

Zespół samoorganizujący się nie zależy od menedżera, nie czeka na przydzielenie pracy. Potrafi odnaleźć się w swoim środowisku, wziąć zadania, zarządzić związanymi z nimi obowiązkami i terminami. Oczywiście taki zespół to coś więcej niż samo przydzielenie sobie pracy i ukończenie jej. Samoorganizujące się zespoły biorą również odpowiedzialność za wybór najbardziej efektywnego i wydajnego sposobu wykonania zadania. Regularnie szukają sposobów na ulepszenie się poprzez eksperymenty.

W takiej strukturze pracy zespoły muszą mieć wysokie poczucie własności i odpowiedzialności. Co równie ważne, muszą często komunikować się i ufać możliwościom wszystkich członków zespołu.

Warto zauważyć, że zespoły takie nie wymagają menedżera do przypisywania zadań, jednak w początkowym okresie formowania „siebie” potrzebują mentora, który może pomóc rozwijać im swoje umiejętności samoorganizacji.

Co może napędzić zespół do samoorganizacji:

– motywacja

– innowacyjne i kreatywne środowisko

– nauka, uczą się na błędach i sukcesach

– budowanie poczucia wartości i odpowiedzialności za wspólny przyrost produktu.

Zdolność zespołu do samodzielnego organizowania się wokół celów (które otrzymał lub sam ustalił) ma zasadnicze znaczenie dla wszystkich zwinnych metodologii, w tym Scrum. 

Jedno z założeń manifestu programowania zwinnego mówi: „Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samoorganizujących się zespołów.”

Jest jedna ważna kwestia. Samoorganizujące się zespoły nie powinny być tworzone losowo. Tak wiem, często warunki w organizacji pokażą nam, że musimy zbudować zespół z takich jednostek jakie mamy, jednak idealnie było by stworzyć zespół według odpowiedznich kryteriów. O tym poniżej.

W ramach decydowania, jak najlepiej osiągnąć cel, niektóre zespoły mogą zdecydować, że wszystkie kluczowe decyzje techniczne będą podejmowane przez jedną osobę w zespole (jednak musi być to decyzja wszystkich).

Inne zespoły zdecydują się podzielić odpowiedzialność za decyzje techniczne między siebie biorąc pod uwagę umiejętności poszczególnych członków zespołu, np: ekspert od baz danych MsSQL podejmuje decyzje nad rozwiązaniami dotyczącymi tych właśnie baz danych. Natomiast osoba będąca dobrym programistą np. .net daje rozwiązania od strony programowania.

Jeszcze inne zespoły mogą zdecydować, że każdy, kto pracuje nad daną funkcjonalnością, podejmuje decyzję, ale ma obowiązek podzielić się wynikami swojej pracy i eksperymentów z zespołem.

Nie każdy zwinny zespół będzie samoorganizować się w ten sam sposób.

Istnieją dwa kluczowe punkty:

•          Po pierwsze, nie każdy zwinny zespół zdecyduje się zorganizować się w ten sam sposób, i to jest OK.

•          Po drugie, wykorzystanie zbiorowej wiedzy zespołu na ogół doprowadzi do lepszego sposobu organizowania się wokół pracy niż poleganie wyłącznie na wiedzy jednego jednej osoby, np. leadera zespołu.

Zaletą przydzielenia zespołowi przestrzeni do samodzielnego organizowania się nie jest to, że zespół znajdzie optymalny sposób na ułożenie swojej pracy, sposób który menedżer mógł przegapić. Pozwalając zespołowi na samoorganizacje, zachęca się go do pełnego posiadania wiedzy na temat problemu jaki ma rozwiązać.

Czy naprawdę możemy oczekiwać, że agile teams samoorganizują się?

Dobrą praktyką budowania samoorganizujących się zespołów powinno być łączenie ze sobą osób których kompetencje przenikają się. Nie możemy po prostu połączyć ośmiu przypadkowych osób, powiedzieć im, aby się samoorganizowali i oczekiwali, że wyniknie z tego coś dobrego”. Gdy połączymy ośmiu przypadkowych ludzi to jak mamy oczekiwać wyników, zwinny zespół nie powinien być losową kolekcją ludzi. W idealnej rzeczywistości osoby, które w organizacji odpowiedzialne za budowanie zespołu do projektu Scrumowego powinny poświęcić wiele wysiłku na dobór osób, które będą tworzyć zespół. 

Podstawowe założenia metodyki Scrum wywodzą̨ się̨ z prac prof. Hirotaka Takeuchi i Ikujiro Nonaka będących wynikiem studiów procesów wytwórczych przeprowadzonych w dużych koncernach. Tam też zostały opisane cechy, które bardzo wiele mówią o samoorganizujących się zespołach. Więcej szczegółów na ten temat w tym artykule: https://www.akademiascrum.pl/2020/02/scrum-jak-to-sie-zaczelo/

Jedną z tych cech jest „Subtelna kontrola” wymienia decyzje kadrowe jako kluczową odpowiedzialność za zarządzanie. Wybór odpowiednich osób dla zespołu projektowego podczas monitorowania zmian dynamiki grupy i dodawanie lub usuwanie członków zespołu, gdy jest to konieczne. Członkowie zespołu są dobierani starannie i przemyślanie, analizowane są różne osobowości, aby sprawdzić, czy się dogadają.

Aby pozyskać odpowiednich ludzi w zespole Agile należy uwzględnić potrzebne nam zakresy wiedzy w danym zespole. Ważne jest aby w zespole cross-funkcjonalnym, były wszystkie umiejętności niezbędne by przejść od pomysłu do wdrożonej funkcji. Wszystkie umiejętności powinny mieć swoch reprezentantów wśród członków zespołu. Początkowo może to oznaczać, że rozmiar zespołu jest nieco większy niż oczekiwano, jednak z czasem osoby z zespołu Scrum nauczą się niektórych umiejętności posiadanych przez ich współpracowników. Jest to naturalny wynik bycia w zespole Scrum. Ponieważ niektórzy członkowie zespołu rozwiną szersze umiejętności, inne osoby mogą zostać przeniesione do nowych zespołów.

Poziomy umiejętności technicznych w zespołach agile mogą być różne. Nie każdy jest ekspertem w każdym zakresie wiedzy. Z zastrzeżeniem rozważań dotyczących wielkości zespołu, należy dążyć do zrównoważenia poziomu umiejętności w zespole. 

Tak jak staramy się zrównoważyć umiejętności techniczne, powinniśmy dążyć do równowagi między tymi, którzy mają głęboką wiedzę na temat dziedziny, w której pracują, lub problemu, który starają się rozwiązać.

Nie oznacza to, że mamy możliwość zebrania zespołu w całości ekspertów domeny. Powinniśmy raczej wziąć pod uwagę długoterminowe cele naszej organizacji. Jednym z tych celów jest prawdopodobnie gromadzenie wiedzy o domenie w całej organizacji. Jeśli umieścimy samych expertów w dziedzinie domen w jednym zespole, będziemy mieć trudności z osiągnięciem celu.

Trzeba zukaj różnorodności w zespołach agile. Różnorodność może oznaczać wiele różnych rzeczy np. to, jak ludzie myślą o problemach, jak podejmują decyzje, ile informacji potrzebują przed podjęciem decyzji itd.

Potrzeba czasu, aby członkowie zespołu agile nauczyli się dobrze współpracować. Budując taki zespół warto zwrócić uwagę czy członkowie zespołu razem ze sobą już współpracowali i czy były z tego efekty. Należy zastanowić się, jak długo członkowie będą mogli współpracować ze sobą, zanim niektórzy lub wszyscy zostaną wezwani do innych obowiązków (innych niż praca w zespole Scrumowym).

Jest klika niebezpiecznych zachowań w samoorganizujących się zespołach na które trzeba zwrócić uwagę.

Czasem jedna dominująca osobowość podejmuje wszystkie decyzje. Samoorganizacja oznacza, że wszyscy wspólnie starają się przedstawić rozwiązanie, wyszukać je. Nie może jedna osoba rzucić decyzją, zanim zespół będzie miał szansę omówić problem.

Jeśli to zaczyna występować, taka osoba powinna być poinformowana, o tym że to nie tędy droga. Niech wie, że nawet w sytuacjach, w których może wiedzieć wszystko i uważać się za „boga” powinna czasami powstrzymać się od wyrażania swojej opinii, zanim inni będą mieli szansę wyrazić swoje myśli.

Można zapytać tą osobę, czy uważa, że zespół podjąłby właściwą decyzję, gdyby przedstawiła swoje myśli jako opinię, a nie jako niepodważalną decyzję.

Członkowie zespołu powinni rozwijać się, aby mogli podejmować właściwe decyzje w sprawie swoich kolejnych projektów.

Drugim częstym problemem może być sytuacja, w której zespół jest zbyt pasywny, aby zorganizować siebie i zamiast patrzeć na siebie i projekt, patrzy na Scrum Mastera lub Managera i czeka, aby ich prowadził za rączkę i podjął ważne decyzje za nich.

Jeśli tak się dzieje, trzeba upewnić się, że członkowie zespołu wiedzą, że zadaniem Scrum Mastera jest wspieranie ich, a nie podejmowanie decyzji za nich.

Należy jednak szukać sposobów angażowania innych, nie podejmując decyzji we wszystkich przypadkach i problemach.

Trzecim problemem jest to, że członkowie zespołu są zbyt młodzi, mają za mało doświadczenia, aby się zorganizować. Lepiej jak członkowie zespołu mają wystarczająco dużo doświadczenia, aby zbudować oprogramowanie, prawdopodobnie mają wystarczająco dużo wiedzy, aby dowiedzieć się, jak się zorganizować. Jeśli nie, dobrze jest zapewnić zespołowi szkolenia lub coaching.

Ważne jest, aby sprawować „subtelną kontrolę nad zespołem”, w której należy ułożyć zespół, nakierować go na dobre tory, aby umiał określić swój cel. Dać zespołowi przestrzeń w organizacji do działania. To pozwoli zespołowi, uczyć się, rozwijać, samodzielnie organizować i układać swoją codzienną pracę.