Scrum Team, czyli Zespół Scrumowy do zadań specjalnych 

Scrum Team, czyli Zespół Scrumowy, to podstawowa jednostka w Scrum. Jest to ten zespół, bez którego Scrum nie może istnieć i bez którego nie powstaną żadne efekty naszej pracy, czyli Przyrost. Czym jest Scrum Team?

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.

Co to Scrum Team?

Scrum scrumem, ale robota rzadko kiedy robi się sama. Aby przekuć elementy Backlogu Produktu zaplanowane do realizacji w Sprincie na potencjalnie wdrażalny inkrement musimy mieć zespół – Scrum Team.

Zespół Scrumowy (ang. Scrum Team) jest podstawową komórką organizacyjną w Scrum. Jest samozarządzającym się i kross-funkcjonalnym ciałem dostarczającym produkt iteracyjnie i przyrostowo, tworząc i wykorzystując okazje do częstego zbierania informacji zwrotnych.

W najprostszych możliwych słowach i zgodnie z definicją ze Scrum Guide’a, Scrum Team to po prostu określenie na zbiór trzech odpowiedzialności:

„W skład Scrum Teamu wchodzi jeden Scrum Master, jeden Product Owner oraz Developerzy.” – Scrum Guide

I tyle. Według Scrum Guide, aby Zespół Scrumowy zaistniał i był w stanie dostarczać potencjalnie wdrażalne Przyrosty muszą zaistnieć w nim 3 wymienione wyżej odpowiedzialności. Z praktyki mogę powiedzieć, że jest to liczba całkowicie wystarczająca pod warunkiem, że są to odpowiedni ludzie na odpowiednich miejscach.

Scrum Team kontra Deweloperzy

Warto w tym miejscu zaznaczyć jedną z najbardziej fundamentalnych rzeczy – Scrum Team to nie tylko Deweloperzy! W Zespole Scrumowym mamy także Product Ownera i Scrum Mastera, natomiast Deweloperzy to określenie na te osoby, które własnymi rękami tworzą przyrost. W szczególności widzimy to podczas Daily Scrum Meeting, gdzie w ramach tego wydarzenia spotykają się tylko Deweloperzy, a nie cały Scrum Team.

Scrum Team to Product Owner, Scrum Master oraz Dewloperzy. Kiedyś Scrum Guide wyraźnie mówił o wielkości tego zespołu, ale teraz znajdziemy tylko zalecenie, żeby nasz Scrum Team powinien być mały. Typowo mówi się tu o 10 osobach lub mniej. Z drugiej strony ma być ich wystarczająco dużo, aby udawało nam się wytworzyć wartościową pracę w ramach jednego Sprintu. O idealnej wielkości zespołu mamy osobny tekst…

Podkreślmy to jeszcze raz: Scrum Team jest odpowiedzialny za wszystko, co jest związane z rozwojem i dostarczaniem danego produktu. Powinien zawierać wszystkie wymagane kompetencje. I to cały Scrum Team jest odpowiedzialny za rezultaty swojej pracy. Występujemy jako zespół, pracujemy jako zespół i nie ma tu miejsca na „ja swoje zrobiłem, ale się nie udało”.

Kompetencje i kross-funkcjonalność

Aby brać czynny udział w Product Backlog Refinemencie, szacować wymagania i realizować je podczas Sprintu, zespół musi posiadać do tego odpowiednie kompetencje. Scrum Guide pisze o nich w następujący sposób:

„Zespoły międzyfunkcjonalne posiadają wszelkie kompetencje niezbędne do ukończenia pracy, nie będąc zależnymi od osób nienależących do zespołu.” – Scrum Guide 2017

„Scrum Teamy są interdyscyplinarne, co oznacza, że ich członkowie mają wszystkie umiejętności
potrzebne do wytwarzania wartości co Sprint.” – Scrum Guide 2020

Powyższe definicje są często utożsamiane z koniecznością posiadania wszystkich kompetencji przez każdego z członków Zespołu Scrumowego. Nic bardziej mylnego. Musimy jedynie zadbać, aby zespół jako całość posiadał wiedzę i umiejętności niezbędne do realizacji Backlogu Sprintu. Oznacza to, że musimy w nim posiadać ludzi, którzy będą w stanie ukończyć realizację wymagania od A do Z.

Natomiast nie znaczy to tego, że w składzie Zespołu Scrumowego są wyłącznie osoby, które znają się na wszystkich dziedzinach tworzonego systemu. Nie ma nic złego w byciu lokalnym ekspertem w ramach Scrum Team. Warto jednak zadbać o redundancję umiejętności, tak aby nie potknąć się o bus factor.

Tu warto dodać, że Scrum Guide podkreśla, że „Scrum Team nie dzieli się na podzespoły, nie obowiązuje w nim hierarchia”. W praktyce bywa z tym różnie, ale jest to ideał w kierunku którego warto iść.

Umocowanie Scrum Team

Niezwykle ważne z punktu widzenia metodyki jest umocowanie Zespołu Scrumowego (ang. empowering). Umocowanie Scrum Team ma umożliwić osobom w nim pracującym (Deweloperom, Scrum Masterowi i Product Ownerowi) na samodzielną pracę.

Oczywiście może zdarzyć się sytuacja, w której Scrum Team nie będzie posiadał wiedzy w zakresie realizowanej funkcjonalności lub będzie potrzebował dodatkowych informacji. Z pomocą przyjdą wtedy osoby występujące w projekcie w roli interesariusza, których zadaniem jest dostarczenie brakujących lub wymagających wyjaśnienia wymagań.

Zespół Scrumowy nie potrzebuje nadzorcy, a tym bardziej osoby, która weryfikowała będzie postęp pracy i porównywała go z założonym na początku projektu wykresem Gantta. Z kolei Deweloperzy w oparciu o swoją wiedzę i doświadczenie prognozują co będą chcieli dowieźć na koniec Sprintu.

Zespół Scrumowy powinien być przede wszystkim umocowany do określania priorytetów realizowania Product Backlogu, wyboru kolejności ich realizacji i do samodzielnego wybrania sposobu ich realizacji.

Na koniec każdego Sprintu nie są ważne indywidualne wyniki albo fakt, że ktoś ukończył wszystkie swoje zadania. Miarą sukcesu w tym przypadku będzie zadowolenie klienta na którego rzecz pracujemy.  Dlatego tak ważne jest, aby zespół czuł się odpowiedzialny za całą swoją pracę – od początku do końca. Efekt ten osiągniemy właściwie go namaszczając.

Zakresy odpowiedzialności

Każda z ról w ramach Scrum Team ma określony zakres odpowiedzialności. Nie ma w tym nic złego i nic „mało zwinnego”. Zatrudniając osobę na stanowisku Product Ownera czy Scrum Mastera oczekujemy innych kompetencji i umiejętności, niż zatrudniając osobę na stanowisko Dewelopera.

Nic nie stoi na przeszkodzie, aby programista czy tester pracowali w tej samej iteracji nad przekształcaniem elementów Backlogu Sprintu w działające oprogramowanie i jednocześnie pełnili rolę Scrum Mastera. Scrum Guide nie widzi nawet przeciwwskazań do jednoczesnego pełnienia roli Product Ownera oraz Scrum Mastera. My, ze względu na troskę o zdrowie psychiczne takiej osoby zdecydowanie tego nie polecamy.

Jeśli więc czujesz się na siłach, aby pełnić w ramach Scrum Team różne role i czujesz do tego powołanie, nie zastanawiaj się nad tym długo – po prostu to zrób. Uważaj jednak, aby żadne z Twoich obowiązków na tym nie ucierpiało.

Zespół Scrumowy

Zespół, niezależnie czy mówimy o tworzeniu oprogramowania czy np. wyścigach Formuły 1, to grupa ludzi pracująca nad osiągnięciem wspólnego celu. Różnicują je powody, dla których powstały i wizja, do której dążą. Pisaliśmy o tym w tekście „Co stanowi zespół?„.

W przypadku metodyki zwinnej, jaką jest Scrum, celem zespołu jest iteracyjne dostarczanie kolejnych Przyrostów produktu. Do tego zespół został powołany i to leży w zakresie jego odpowiedzialności. Tylko tyle, lub aż tyle, jak powiedzą niektórzy.

Pisząc ten artykuł celowo nie skupiałem się na żadnej z ról. Tylko wspólna praca wszystkich członków Zespołu Scrumowego zaowocuje sukcesem. Nie ma tutaj znaczenia, czy jesteś Product Ownerem, Scrum Masterem czy Deweloperem. Wszyscy macie jeden, wspólny cel i wszyscy gracie do jednej bramki.

Nie ma też znaczenia, jakie stanowisko w ramach zespołu zajmujesz, ponieważ nie istnieje coś takiego jak hierarchia w Scrum. Każdy z nas ma określone zadania do wykonania. Wykonując je najlepiej jak potrafimy, ciągniemy projekt w stronę, której wszyscy oczekujemy – w stronę sukcesu.

Więcej o zespołach możecie przeczytać w tekście o idealnej wielkości zespołu i o tym co stanowi zespół.