Skip to content

Samoorganizacja się sama nie organizuje

Jeśli jesteś Scrum Masterem lub Agile Coachem i ktoś pyta Cię o opinie na jakiś zwinny temat, najczęstszą odpowiedzią jest “To zależy” lub “Zostaw to zespołowi”. Ta druga kwestia jest szczególnie ciekawa – jaka magia musi zadziałać, aby grupa ludzi zaczęła samodzielnie podejmować decyzje i organizować swoją pracę? Czy samoorganizacja jest w ogóle możliwa?

Organizacja zespołów to temat bardzo rozległy, dziś postanowiłam skupić się tylko na pewnym wycinku mówiącym o samoorganizacji. Pominę więc dojrzałość zespołu, motywację, dysfunkcje i inne podobne tematy. Skupię się natomiast na koncepcji trójkąta samoorganizacji, opisanego przez Andiego Brandt’a.

Czego potrzebuje samoorganizacja?

Jako uczestnik lub organizator warsztatu mogliście doświadczyć ciekawego zjawiska podczas dzielenia osób na grupy. Wyobraźmy sobie na przykład szkolenie z zagadnień dotyczących Scruma. Na poczatku mówimy uczestnikom, że będą pracowali w mniejszych zespołach. Określamy, że w każdej grupie musi się znaleźć przynajmniej jeden Product Owner oraz osoba ze specjalizacją testera. Wystarczy do tego dołożyć jakieś krótkie ograniczenie czasowe, na przykład minutę, a po upływie tego czasu uczestnicy są odpowiednio podzieleni. Magia? Nie, po prostu standardowy przykład samoorganizacji.

Wyznaczenie celu, kilku prostych i jasno zdefiniowanych reguł oraz jakiegoś rodzaju napięcia lub nawet presji powoduje, że grupa ludzi potrafi samodzielnie go osiągnąć. Może to mieć miejsce zarówno podczas podziału na grupy przed szkoleniem, jak i budowaniem zespołów scrumowych w firmie. Czy ludzie sami nie mogą podjąć decyzji, jak je utworzyć?

Takie podejście do sprawy ma jedną zdecydowaną przewagę – ludzie będą czuli, że konsekwencje ich decyzji należą do nich. W przypadku niepowodzenia unikniemy obarczenia odpowiedzialnością osoby decyzyjnej, na przykład managera. W przypadku sukcesu także wychodzimy lepiej, bo należy on do zespołu, a nie do kogoś, kto kazał im podzielić się odpowiedni sposób.

Samoorganizacja drużyny piłkarskiej

Wyobraźmy sobie sytuację, w której wpuszczamy na boisko dwie jedenastoosobowe drużyny i mówimy im, żeby zrobiły coś ciekawego. Zaczną grać w piłkę nożną, czy może wymyślą jakiś inny rodzaj gry? Czy obie drużyny będą postępowały według tych samych zasad? A może w ogólne nie zaczną grać, tylko zaczną się opalać?

Jeśli obie drużyny mają świadomość tego, że za chwilę mają rozpocząć mecz piłki nożnej, w większości wypadków zawodnicy postawią sobie za cel wygranie spotkania. Reguły gry są jasno określone, a ich przestrzeganie nadzorowane przez sędziego. Przed meczem na pewno wraz z trenerem ustalili też odpowiednią taktykę. Gdy tylko sędzia rozpocznie mecz, obie drużyny mają tyle samo czasu na realizację swojego celu.

To, jakie decyzję będą podejmowali zawodnicy w trakcie meczu, jest uwarunkowane właśnie przez cel, zasady oraz presję (w tym wypadku czasu). Plany sprzed meczu mogą się diametralnie zmienić z powodu straconej bramki lub kontuzji jednego z zawodników. Członkowie drużyny będą się musieli sami zreorganizować, trener może w tym tylko pomóc.

Przykład z meczem piłki nożnej jest oczywiście bardzo uproszczony. Aby lepiej zobrazować poszczególne aspekty samoorganizacji, skupię się więc na moim obszarze zainteresowań, czyli zespołach scrumowych. 

Cel

Które z zagadnień opisanych w Scrum Guide pojawiają się w nim najczęściej? Spotkanie, estymacja, a może planowanie? Tak, występują dość często, ale jednym z najważniejszych jest Cel Sprintu (ang. Sprint Goal).

To właśnie ten element nadaje sens pracy zespołowi deweloperskiemu. Bez niego każda z osób zajmuje się po prostu swoimi zadaniami, nie osiągając przez to pełnej wydajności. Ukończenie wszystkich zadań w sprincie to cel mocno naciągany. Powinien to być widoczny przyrost, nad którym może pracować całość zespołu, lub przynajmniej jego większość.

To właśnie ten element wyznacza kierunek i umożliwia samoorganizację w zespole. Członkowie muszą bowiem wyraźnie widzieć, gdzie powinni się znaleźć na koniec sprintu.

Zasady

Bez jakichkolwiek zasad niezwykle ciężko się zorganizować. Każdy będzie działał na własną rękę i osiągnięcie Celu Sprintu może okazać się niemożliwe. Oczywiście nie chodzi tu o szczegółowe procedury, definiujące pożądane zachowanie w najróżniejszych sytuacjach. Chodzi tu bardziej o ramy postępowania, które będą pokazywały zespołowi jakiś kierunek.

Scrum Guide określa całkiem sporo reguł, organizując pracę zespołu. Wymienia filary oraz wartości, na których oparte są wszystkie zasady, definiuje role, spotkania oraz artefakty. Dodatkowo zespoły definiują swoje własne reguły, jak na przykład zasady code review lub Definition of Done. Wszystko to ma za zadanie stworzyć odpowiednie środowisko pracy, w którym każda osoba rozumie poszczególne elementy tak samo i może dążyć do osiągnięcia celu. 

Napięcie lub presja

Członkowie jednego z zespołów, w którym miałem przyjemność kiedyś pracować, powiedzieli mi, że chcą zmienić Kanban na Scrum, bo “brakuje im bata”. Nie słyszeliśmy wtedy o Kanban Cadences, dlatego faktycznie było trudno o zachowanie odpowiedniego rytmu, uwarunkowanego końcem iteracji. W końcu po zakończeniu sprintu trzeba pokazać przyrost, czyli działające oprogramowanie, na które czekają nasi klienci. W przypadku Kanbanu tego nie mieliśmy.

Właśnie ta presja zbliżającego się nieuchronnie Przeglądu Sprintu powoduje, że zespół będzie bardziej skłonny do samoorganizacji. W zależności od zmieniających się warunków będzie musiał skorygować swoje plany oraz organizować się w inny sposób. Jeśli na przykład odkryte zostaną jakieś zależności lub potrzeba uzyskania dodatkowych informacji od zewnętrznych osób, dzięki presji czasu zespół powinien z większym zaangażowaniem próbować rozwiązać problem.

Podsumowanie

Jak więc widać samoorganizacja wymaga pewnego rodzaju wsparcia, przynajmniej na początku. Bez wspólnego celu, jasno określonych zasad oraz pewnego rodzaju napięcia ciężko będzie z grupy ludzi stworzyć dobrze zorganizowany zespół, zdolny do podejmowania szybkich i trafnych decyzji w krótkim czasie. Warto o tym pamiętać, jeśli myślimy o wydajnych zespołach, a nie tylko o grupach ludzi, dostarczających od czasu do czasu jakieś funkcjonalności.

Published inAgile

Be First to Comment

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *