Samozarządzający się Zespół Scrum

W Scrumie podejścia takie jak samozarządzanie i samoorganizacja odgrywają kluczową rolę w efektywności zespołów. Te dwa terminy, choć często używane zamiennie, mają różne znaczenia i implikacje dla autonomii zespołów. Poniżej przyjrzymy się bliżej tym koncepcjom i ich zastosowaniu w praktyce.

Zespoły Samoorganizujące się

Co to są Zespoły Samoorganizujące się?

Zespoły samoorganizujące się mają zdolność do samodzielnego strukturyzowania i organizowania swojego działania bez zewnętrznej kontroli. Struktura, procesy i role w takich zespołach powstają organicznie na podstawie potrzeb i interakcji członków zespołu. W samoorganizujących zespołach potrzebna jest ciągła i szeroka komunikacja. W ramach takich zespołów powstają kreatywne rozwiązania złożonych problemów.

Cechy Zespołów Samoorganizujących się

• Autonomiczne podejście do pracy: Zespoły same określają swoje przepływy pracy i praktyki.
• Dynamika ról: Role i odpowiedzialności mogą ewoluować dynamicznie w zależności od potrzeb zespołu.
• Decyzje wewnętrzne: Procesy decyzyjne często wyłaniają się z samego zespołu.
• Adaptacyjność: Zespoły te są zazwyczaj bardzo elastyczne i zdolne do szybkiego dostosowywania się do zmian.
• Kreatywność: Powstają unikalne rozwiązania, często inne od oryginalnego pomysłu.

Samoorganizacja w Scrumie

Pierwszy raz pojęcie samoorganizacji w Scrum Guide pojawiło się od razu w pierwszej w wersji z 2009 roku. Ta wersja przewodnika jest bardziej obszerna niż najnowsza i więcej wyjaśnia. Zobaczmy co mówi o samoorganizacji.

“A new Team often first realizes that it will either sink or swim as a Team, not individually, in this meeting. The Team realizes that it must rely on itself. As it realizes this, it starts to self-organize to take on the characteristics and behavior of a real Team.”

Scrum Guide 2009

Sink or swim oznacza, że zespół albo nauczy się współpracować albo polegnie jako zespół. Założenie, że presja czasu doprowadzi do wytworzenia się procesów w zespole, jest jednym z kamieni węgielnych Scruma zaczerpniętych z artykułu The New New Product Development Game.

Zespół, który ma postawiony przed sobą jasny cel, przejdzie przez fazy “ktoś nam powie, co robić”, “nikt nam nie mówi, co robić”, “sami to musimy zorganizować”. Oczywiście pod warunkiem, że w zespole posiadamy wszystkie kompetencje do wykonania pracy (cross-functional) i ludzie są zmotywowani do wykonania pracy. Zespół zacznie brać na siebie odpowiedzialność za osiągnięcie celu i zaplanuje pracę w Sprincie.

To, co odróżnia grupę indywidualności od zespołu, to przede wszystkim wspólny cel do zrealizowania. W wersji Scrum Guide z 2017 roku mamy wyraźnie napisane, że zespół skupia się na Celu Sprintu.

“Każdego dnia Sprintu samoorganizujący się Zespół Deweloperski powinien wiedzieć, jak będzie przebiegała dalsza współpraca, by możliwe było osiągnięcie Celu Sprintu i stworzenie przed końcem Sprintu oczekiwanego Przyrostu.“
Scrum Guide 2017 polski

Developerzy sami organizują się wokół Celu Sprintu

“The Team self-organizes to assign and undertake the work in the Sprint Backlog, either during the Sprint Planning meeting or just-in-time during the Sprint.”

Zespół organizuje swoją pracę na bieżąco w trakcie Sprintu. Just-in-time to oczywiste odniesienie do Lean Management.

“Teams are also self-organizing. No one – not even the ScrumMaster – tells the Team how to turn Product Backlog into increments of shippable functionality. The Team figures this out on its own. Each Team member applies his or her expertise to all of the problems. The synergy that results improves the entire Team’s overall efficiency and effectiveness.”

Każdy jest tak samo odpowiedzialny za rozwiązywanie problemów i wykonywanie pracy, niezależnie od posiadanych umiejętności.  Dlatego ważne jest, żeby w Scrumie nie pojawiały się dodatkowe nazwy ról i stanowisk wśród developerów. Taki sposób organizacji wpływa na poprawę skuteczności w osiągania celów i wydajności procesu. Nikt nie narzuca rozwiązań i planu pracy Developerom.

Daily Scrum stwarza presję i daje okazję do zaplanowania kolejnego dnia pracy. Oczywiście można rozmawiać i planować w dowolnym momencie poza wymaganymi wydarzeniami.

Skąd pojawił się Cel Sprintu? Został ustalony pomiędzy Developerami a Product Ownerem. Jednak pomysł na Cel Sprintu i większy od niego Cel Produktu, plan na rozwój produktu, potrzebne elementy (zakres) są odpowiedzialnością Product Ownera. Developerzy nie mogą zdecydować samodzielnie, nad czym będą pracowali.

Skąd bierze się samoorganizacja?

Samoorganizacja jest naturalnym zjawiskiem. Jednak warto zauważyć, że potrzebuje pewnych warunków do zaistnienia. Jak można zauważyć powyżej, ważne są dwa czynniki. Jest jakaś presja, która tworzy potrzebę samoorganizacji. Jest pewien cel, w kierunku którego zespół się organizuje.

Doświadczamy samoorganizacji na co, dzień chociaż nie zdajemy sobie z tego sprawy. Dobrym przykładem jest chociażby ruch uliczny. Powiedzmy, że chcesz odebrać dziecko z przedszkola. Musisz zdążyć na konkretną godzinę (presja) i pokonać pewna trasę. Zakładasz jakiś czas na pokonanie trasy i ruszasz w drogę. Na drodze są inni uczestnicy ruchu, którzy chcą osiągnąć własny cel. Może się okazać, że droga jest zablokowana, są rowerzyści na drodze albo po prostu jest spowolnienie ruchu. Co teraz? Ty i inni kierowcy planujecie, jak jechać dalej w sposób jak najbardziej sprawny. W takim razie może pojedziesz po chodniku? Może przejedziesz przez skrzyżowanie bez zatrzymania? A może jak zwiększysz prędkość w środku miasta do 120 km/h, to zdążysz na czas? Zakładam, że tego nie zrobisz. Dlaczego? Ponieważ w ruchu drogowym obowiązują nas zasady kodeksu. Mamy narzucone ramy postępowania.

Czy zespół pracujący w Scrumie też ma jakieś narzucone ramy postępowania? Oczywiście. Scrum framework to inaczej ramy postępowania. Musimy trzymać się zasad opisanych w przewodniku. W każdej organizacji mamy też pewne standardy i polityki. Ich też nie możemy ignorować czy łamać. Scrum Master pilnuje przestrzegania ram.

Samoorganizacja pojawia się gdy mamy 3 czynniki: cel, presję i ramy postępowania.

Zespoły Samozarządzające się

Co to są Zespoły Samozarządzające się?

Zespoły samozarządzające się działają z wysokim stopniem autonomii, podejmując decyzje niezależnie od tradycyjnej hierarchii zarządzania. Samozarządzanie jest kluczowe dla wzmacniania zespołów, co pozwala im działać szybciej. Zespoły samozarządzające biorą pełną odpowiedzialność za rezultaty swojej pracy.

Cechy Zespołów Samozarządzających się

• Samodzielne podejmowanie decyzji: Zespoły są upoważnione do podejmowania decyzji dotyczących swojej pracy, harmonogramów i zasobów.
• Jasna struktura odpowiedzialności: Istnieje wyraźna struktura, kto jest za co odpowiedzialny, ale role te są zarządzane przez sam zespół.
• Wewnętrzna odpowiedzialność: Zespoły są odpowiedzialne same przed sobą za wyniki swojej pracy. Przed resztą organizacji odpowiadają za rezultaty swojej pracy.
• Większa odpowiedzialność i autonomia: Samozarządzanie obejmuje również decyzje, jakie cele chce osiągnąć zespół.
• Samoorganizacja w ramach wykonywanej pracy

Samozarządzanie w Scrumie

Pojęcie samozarządzania pojawia się w Scrum Guide w wersji z 2020 roku.

“Scrum Teamy są interdyscyplinarne, co oznacza, że ich członkowie mają wszystkie umiejętności potrzebne do wytwarzania wartości co Sprint. Są także zespołami samozarządzającymi, co oznacza, że samodzielnie podejmują decyzję o tym, kto będzie wykonywał określone zadania, kiedy i jak.“
Scrum Guide 2020 polski

Niestety w powyższym fragmencie trudno dopatrzyć się różnicy pomiędzy samoorganizacją i samozarządzaniem. Trzeba dopatrzyć się tego, że wcześniej była mowa o samoorganizacji w zakresie jak wykonać pracę (who and how), a teraz jest też mowa o tym, co zrobić (what?). To, co można szybciej zauważyć, to odniesienie do Scrum Team zamiast Development Team. I to jest bardzo ważna zmiana. Zniknął Development Team. Jedyny zespół w Scrum Guide to Scrum Team.

Scrum Team składa się z Product Ownera, Scrum Mastera i Developerów. Wcześniej mówiliśmy o samoorganizacji w ramach planowania pracy u Developerów. Do tego dokładamy dbanie o przestrzeganie ram (Scrum Master) i decyzję, czym powinien zająć się zespół (Product Owner). Teraz w sumie Scrum Team decyduje o tym, czym się zająć i jakie są ramy ich działalności. Więc jest to zespół samozarządzający.

Kiedy Product Owner jest odpowiednio umocowany w organizacji i może wziąć odpowiedzialność za rozwój i utrzymanie produktu w pełni, wtedy Scrum Team rzeczywiście funkcjonuje jako samodzielna jednostka.

Kiedy Scrum Master może usuwać przeszkody w organizacji albo je eskalować do rozwiązania, a zespół i organizacja działają zwinnie z minimalnym wsparciem, wtedy Scrum Team rzeczywiście funkcjonuje jako samodzielna jednostka.

Korzyści z Samozarządzających się Zespołów

Zaangażowanie Ludzi

Samozarządzanie umocowuje zespoły w organizacji, co sprawia, że czują się bardziej zaangażowane i odpowiedzialne za swoją pracę. Wewnętrzna motywacja członków zespołów jest w pełni wykorzystana.

Wykorzystanie potencjału ludzi

Kreatywność członków zespołów jest w pełni wykorzystana. Powstają kreatywne rozwiązania, które inaczej nie mogłyby powstać. Zespół rzadko zgłasza problemy, bo większość mogą rozwiązać sami.

Szybsze Działanie

Zespoły, które mają pełną kontrolę nad swoimi działaniami, są w stanie podejmować szybkie decyzje i działać dynamicznie, co prowadzi do szybszego wprowadzania produktów na rynek. Takie zespoły nie muszą czekać na decyzję, ani prosić o pozwolenie. Zespoły samozarządzające są też bliżej klienta.

Zespoły samozarzadzające się są w stanie przełączyć się na inny temat, cel, produkt szybciej. Nie potrzebują tyle przygotowania i takiej ilości wsadu jak zespoły tradycyjne, żeby zacząć pracę.

Czy każda organizacja może wdrożyć samozarządzające się zespoły?

Nie każda organizacja jest gotowa na samozarządzające się zespoły. Wymaga to kultury zaufania, otwartości i wsparcia dla autonomii pracowników. Wyzwania obejmują konieczność zmiany kultury organizacyjnej, zapewnienie odpowiedniego wsparcia i zasobów oraz rozwijanie umiejętności samodzielnego zarządzania wśród członków zespołu.

Jeżeli w tej chwili organizacja jest typowo hierarchiczna ze stylem zarządzania Command and Control, to potrzeba dużo pracy z kadrą zarządzającą, żeby przejść na samodzielne zespoły. Albo zmiana musi zacząć się od zarządu, albo maksymalnie osiągniemy bańki takich zespołów w organizacji z hybrydowym modelem zarządzania.

Trzeba wprowadzić jasną delegację odpowiedzialności, a nie zadań. Potrzebny jest servant leadership. Ktoś musi dostarczać zasoby, usuwać przeszkody i dbać o dobrostan zespołu (jeśli tego nie robi sam zespół). W takich zespołach będzie duże tempo pracy i dużo problemów do rozwiązania. Konflikty mogą zatem pojawiać się częściej niż w tradycyjnych zespołach. Może też pojawić się unikanie trudnych decyzji albo paraliż decyzyjny. Management musi to facylitować.

Oczywiście trzeba pamiętać, że od strony zespołów też mogą występować problemy. Potrzebujemy ludzi z motywacją wewnętrzną i dużą dyscypliną. Zespoły muszą wziąć odpowiedzialność. Nie każdy człowiek i zespół będzie chciał to zrobić. Są ludzie, którzy wolą, jak manager bierze odpowiedzialność i popycha pracę do przodu.

Zespoły samoorganizujące w niektórych firmach mogą być już dużą zmianą, w innych przystankiem na drodze do samozarządzania.

Podsumowanie

Zrozumienie różnic między samoorganizującymi się a samozarządzającymi się zespołami jest kluczowe dla tworzenia efektywnych i autonomicznych zespołów w ramach Scrum. Prawidłowe wykorzystanie tych koncepcji z pewnością pozwoli czerpać więcej korzyści z pracy w Scrumie. Samozarządzające zespoły prowadzą do większej elastyczności, innowacyjności i produktywności w organizacjach, jednocześnie skracając czas wprowadzenia produktu na rynek. To dokładnie jest zwinność biznesowa, na której zależy każdej organizacji.