Samoorganizacja to słowo, które równie często co kross-funkcjonalność potrafi być wykorzystane przeciwko zespołom. Nie daj się naciąć, na podróbę samoorganizacji!
Proces Scrum został zaktualizowany wraz z opublikowaniem nowej wersji Scrum Guide w listopadzie 2020. Poniższy wpis uwzględnia zmiany wprowadzone w Podręczniku Scrum.
Granice samoorganizacji
Samoorganizacja w ujęciu IT to co innego niż samoporządkowanie. Te ostatnie oznacza samoistne tworzenie zorganizowanych struktur w układach złożonych. „Nasza” samoorganizacja powinna być rozumiana znacznie bardziej przyziemnie, jako samodzielna organizacja swojej pracy.
„Pełna samoorganizacja” nie ma szans zaistnieć w przyrodzie. Jeśli każdy będzie patrzył tylko i wyłącznie na czubek swojego nosa, to w rezultacie dostaniemy chaos. Muszą istnieć jakieś struktury w ramach których będziemy się samoorganizować, a i my zwykle pracujemy przynajmniej w małych zespołach.
W przypadku projektów i organizacji pewne granice są oczywiste: godziny i miejsce pracy, organizacja na poziomie zespołów, struktura firmy, wizja i cele, a także podmiot naszej działalności. Nie da się ukryć, że dołączamy do firmy czy projektu, żeby wspierać czyjeś zamiary i realizować jego plany.
Realizacja planów innych osób wcale nie wyklucza realizacji naszych własnych. Ale jeśli chcemy poczuć, że mamy całkowity wpływ na wszystkie decyzje jakie podejmujemy i samemu wyznaczać kierunek rozwoju, to my otwieramy działalność i zatrudnimy ludzi, którzy będą nas w tym wspierać.
Odpowiedzialność zespołu
Skoro dołączyliśmy do jakiegoś zespołu, żeby realizować wizję właściciela, to automatycznie zabiera nam to trochę wolności. Jak pogodzić zależność przełożony-podwładny z samoorganizacją? Na pewno pomoże nam w tym agile mindset, ale najważniejsze będzie tu zaufanie.
Bez zaufania będziemy jedynie realizować polecenia przełożonego i wykonywać przydzielone nam zadania. Jeżeli nie pozwolimy wziąć zespołom odpowiedzialności za swoje czyny, to nie stworzymy miejsca na kreatywność ani na żadne „zwinne podejście”.
Sam zespół również powinien być odpowiedzialny. Przede wszystkim za najlepsze wykonanie pracy przy danych warunkach i w danym czasie. Ale zespół będzie również odpowiedzialny za budowę środowiska niezbędnego do wykonania powyższego.
Im więcej jesteśmy w stanie wziąć odpowiedzialności, tym bardziej powinniśmy być w stanie zorganizować się sami. Oczywiście, przy założeniu, że nasz kredyt zaufania jest pełen. A to znaczy, że za porażki wynikające z agile’owych eksperymentów nikomu nawet nie wpadnie do głowy nas karać.
Mikromanagement, a samoorganizacja
Im bardziej przełożony bądź management ingeruje w sposób organizacji pracy zespołu, tym bardziej pokazuje, jak bardzo im nie ufa. W najgorszym wypadku mówi im nie tylko co i jak mają robić, ale też jak mają między sobą współpracować. To czysty absurd, bo osoba, która nie jest członkiem zespołu nie ma „skin in the game” i nie powinna podejmować decyzji w sprawie organizacji pracy.
Jakże cudownie byłoby, gdybyśmy obok backlogu dostali nieograniczony kredyt zaufania i polecenie „zrealizujcie to, tak jak potraficie najlepiej”?
– Jak oni to robią?
– Nie mam pojęcia, nie patrzę im na ręce.
Niestety, każdy backlog się zmienia i potrzebna jest nie tylko informacja o aktualnych priorytetach. W celu utworzenia wartościowego produktu, wszyscy zaangażowani muszą wiedzieć dla kogo i po co robią daną funkcjonalność. Oznacza to, że „co” zwykle jest zdefiniowane, ale „jak” pozostaje już zupełnie pod kontrolą zespołów.
W praktyce, zarówno osoby realizujące wymagania, jak i te odpowiedzialne za kierunek rozwoju całości muszą ściśle ze sobą współpracować. Przykładem takiej współpracy jest Scrum Team, gdzie z jednej strony PO decyduje o wizji, ale wszyscy jego członkowie mają wpływ zarówno na „co” i „jak”, a także na sam proces wytwórczy.
Samoorganizacja w Scrum
Czy samoorganizacja nie stoi trochę w sprzeczności ze Scrumem? Temat stał się bardziej skomplikowany w związku ze zmianami w Scrum Guide 2020. Wcześniej faktycznie w podręczniku Scrum używane było słowo „self-organization”:
„Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. (…) No one (…) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.” – Scrum Guide 2017
Po nowemu używane jest słowo samozarządzanie. Napisaliśmy cały tekst wyjaśniający różnice pomiędzy tymi dwoma terminami. W skrócie, ten drugi termin ogranicza się do „wewnętrznego decydowania o tym co kto robi, kiedy i jak”. Z jednej strony mamy więc ramę w postaci metodyki, która mówi nam o rolach, wydarzeniach i artefaktach. Z drugiej zaś, przy okazji omawiania samozarządzania wielokrotnie zaznaczane są jej granice.
Nie da się ukryć, że Product Owner jest, nomen omen, właścicielem tworzonego produktu. To on ustala wizję i wraz z zespołem wypracowuje najbardziej wartościową kolejność realizowanych zadań. I tyle! Cała reszta, od sposobu realizacji, do wewnętrznej organizacji pracy w ramach Sprintu, to domena Development Teamu.
Co jeszcze nie znaczy, że mogą oni robić co im się żywnie podoba. Istnieją dobre praktyki i wymagania związane z organizacją pracy w danym miejscu, które mają zapobiec powstawaniu wspomnianego już chaosu. Wyznaczają one granice samoorganizacji, które zespół i tak może przesuwać.
To już jednak temat eskalacji, o którym opowiemy następnym razem.
