Kluczowe elementy samoorganizacji
Samoorganizacja fascynuje mnie od wielu lat. Staram się obserwować wszelkie jej przejawy w grupach i zespołach aby wyciągać kluczowe wspólne elementy do tego, aby mogła zaistnieć. Mając te elementy łatwiej mi później użyć ‘mocy’ samoorganizacji do rozwiązywania kompleksowych problemów. Bo przecież o to w tym wszystkim chodzi - nie aby mieć samoorganizację dla samej siebie (chociaż jest ona zgodna z moimi wartościami), ale aby lepiej radzić sobie z wyzwaniami stawianymi przed firmami, grupami czy innymi organizacjami.
Za przykład zastosowania tych kluczowych elementów posłuży mi procesu podziału zespołów w polskim oddziale pewnej firmy.
Wraz z rozwojem firmy, do polskiego oddziału zatrudnionych zostało w krótkim czasie 10 osób, co stanowiło ok. 40% wzrost osób na pokładzie. Wraz z pozostałymi Scrum Masterami zastanawialiśmy się jak podejść do tego wyzwania.
Zaczęliśmy oczywiście rozważać pewne opcje: dodać osoby do istniejących zespołów, stworzyć nowe zespoły z nowych osób, poprosić nieformalnych liderów o rozpisanie zespołów na nowo, etc. W pewnym momencie zdaliśmy sobie sprawę, że żadne rozwiązanie ‘top-down’ nie będzie możliwe - to ludzie w naszych zespołach posiadają wiedzę potrzebną do tego aby się efektywnie dostosować do nowej sytuacji, nie my. Zaczęliśmy więc kombinować jak stworzyć odpowiednie warunki do tego, aby zmiany w zespołach mogły być przeprowadzone przez same zespoły.
Cel
W pierwszej kolejności określiliśmy co jest naszym głównym celem przy tworzeniu się nowych zespołów w naszym oddziale. Doszliśmy do wniosku, że chcemy stworzyć silne zespoły, które będą przejmowały nowe obszary odpowiedzialności produktowej w organizacji. Dzięki temu będziemy mieli szansę na dalszy rozwój naszej lokacji, kolejne zespoły w przyszłości oraz większy wpływ na to w jaki sposób rozwijamy nasze produkty. Dodatkowym celem było to, aby ludzie znaleźli dla siebie obszar (zespół, część produktu, typ pracy), w który będą mogli się zaangażować i w którym będzie im się dobrze pracowało.
Mając te 2 cele założyliśmy, że będą one wystarczająco motywujące dla całej naszej grupy aby podzielić się mając zarówno własne jak i grupowe (biznesowe) dobro na uwadze.
Ramy
Nadmiar opcji i brak ograniczeń wcale nie czyni nas bardziej szczęśliwymi. Opowiadał już o tym Barry Schwartz w “The paradox of choice”. Z mojego doświadczenia wynika, że kiedy nie znamy ograniczeń (procesu, budżetu, zakresu decyzyjności, etc.), większość z nas będzie obawiać się podjęcia decyzji - wycofa się i będzie czekać co zrobi reszta (lub akceptowani przez daną osobę liderzy). Tylko niewielka część osób powie sobie “hurra, mogę wszystko!” i zacznie działać. Mówiłem kiedyś o tym problemie (i jak go rozwiązać) na ABE - filmik tutaj.
W naszym eksperymencie z podziałem zespołów stworzyliśmy następujące ramy:
- Zespoły muszą być małe - 5 osób + SM + PO -> aby zachować zwinność, ograniczyć straty w komunikacji
- Mamy mieć na koniec 6 zespołów (zamiast obecnych 4) -> wynika to z punktu wyżej
- Każdy zespół (jeszcze bez osób) miał już określony obszar, w którym będzie pracować, Scrum Mastera i Product Ownera -> aby ludzie wiedzieli mniej więcej co będą robić w danym zespole (domenowo)
- W zespole nie może się znaleźć więcej niż 2 nowoprzyjęte osoby -> aby efektywnie przeprowadzić onboarding nowych osób i jednocześnie zmniejszyć negatywny wpływ na prędkość
- Min. 1 tester per zespół
Proces podziału
Mając zarówno cele jak i ramy dla całej akcji, skonstruowaliśmy excela z informacjami oraz miejscem aby wpisać się do swojego wybranego zespołu. Napisaliśmy komunikat na slacku, daliśmy 2 dni na uzupełnienie excela i ustawiliśmy spotkanie ‘podsumowujące’ na koniec. Efekt przeszedł nasze najśmielsze oczekiwania. Sam podział zajął ok 3h zamiast przewidzianych przeze mnie 3 dni. Patrzyliśmy zafascynowani jak ludzie dyskutują i przypisują się do zespołów. Podsumowanie zrobiliśmy jeszcze tego samego dnia (na spotkaniu już niczego nie zmienialiśmy).
Dzięki szybkiemu podziałowi na 6 zespołów (z oryginalnych 4), mogliśmy od razu jako Scrum Masterzy zacząć wspomagać proces grupowy, formowanie się i ustalanie wspólnych zasad współpracy. Dzięki małym zespołom zachowaliśmy zwinność działania, a biznes zyskał możliwość bardziej szczegółowego średnioterminowego planowania przez większa granularność w budżetowaniu rozwoju określonego obszaru produktu. Prawie każdy zespół otrzymał nowe osoby, więc onboarding przebiegał efektywnie (zarówno od strony wiedzy domenowej jak i przekazywania kultury pracy).
Czego się nauczyliśmy?
Że samoorganizacja działa 🙂 A tak naprawdę to, czego nam zabrakło, to określenia metryk. Sprawdziliśmy co prawda burn-up chart dla dużego release'u (i pokazał wzrost prędkości), ale oprócz korelacji nic innego nie można z tego wyciągnąć - a jak wiemy, korelacja to nie to samo co przyczyna. Dopiero po tym eksperymencie wprowadziliśmy tzw. Team Health Check, gdzie ankietą będziemy regularnie badać pewne obszary pracy zespołów aby sprawdzać między innymi one się zmieniają pod wpływem globalnych działań. Ale to już temat na oddzielny artykuł.
Podsumowanie
Aby samoorganizacja zadziałała, należy moim zdaniem dostarczyć zespołowi dwie podstawowe rzeczy: cel oraz ramy działania. Jedno bez drugiego nie wystarczy. Mając sam cel pogrążymy się w niepewności bo nie będziemy wiedzieć co możemy, a czego nie aby go osiągnąć. Mając same ramy będziemy wiedzieli jak działać, ale nie będzie żadnego ukierunkowania naszych poczynań, co może doprowadzić do zmarnowania czasu i pieniędzy.
Dopiero mając oba elementy można skorzystać z siły zespołowej inteligencji i uzyskać lepsze rozwiązanie i w krótszym czasie niż gdybyśmy samemu się zabrali za rozwiązywanie tego problemu.
Jeśli chcecie dowiedzieć się więcej o budowaniu samoorganizujących się zespołów, zapraszam do oglądnięcia wystąpienia Izabeli Krupy (z moim udziałem) - tutaj.