Blog - Cztery role w Scrum

Scrum powstał jako prosty framework (rama) do wykorzystania przy okazji tworzenia, dostarczania i utrzymywania złożonych produktów. Wspominaliśmy już o tym, że Scrum jest przedstawicielem metodyk zwinnych, chociaż zdecydowanie powinniśmy w stosunku do niego unikać słowa “metodologia”.

Wszyscy entuzjaści Scruma, a nawet jego twórcy, od zawsze powtarzają “Scrum jest bardzo prosty do wytłumaczenia i bardzo trudny do wdrożenia”. Intencją autorów tej metodyki było to, żeby był to bardzo ogólny przepis, możliwy do zastosowania w prawie każdej sytuacji i organizacji.

Jednak im coś jest prostsze, tym więcej niejasności pojawia się wokół detali.

W zależności od interpretacji, Scrum składa się z czterech lub pięciu wydarzeń, trzech artefaktów i trzech lub nawet pięciu ról. Jeśli chodzi o wydarzenia, to niektórzy sam Sprint traktują jako klamrę spinającą pozostałe elementy, a nie prawdziwe „wydarzenie”.

W przypadku ról, nazwane w Podręczniku Scrum są: Scrum Team, Scrum Master, Product Owner i Development Team. Niektórzy uznają, że Scrum Team to nie rola, a inni zaś dodają do tej listy Developera. Ten ostatni jednak nie jest nigdzie nazwany i słowo to w Scrum Guide po prostu nie występuje, zamiast niego mamy do czynienia z “profesjonalistami” (ang. professionals).

Ale zacznijmy od początku.

Scrum powstał po to, aby dostarczać złożone produkty. Skoro są one złożone, to tym samym jasne jest, że pracy nie może wykonać tylko jedna osoba. Potrzebny jest zespół, który poradzi sobie z każdym zadaniem. Taki zespół w Scrum jest nazwany Scrum Team (Zespołem Scrumowym).

Zespół Scrumowy jest samoorganizujący się i kross-funkcjonalny. To z kolei oznacza, że nikt nie mówi mu w jaki sposób ma on wykonywać swoją pracę, ani jak się organizować. “Kross-funkcjonalność” to nic innego jak posiadanie wszystkich umiejętności niezbędnych do wykonania całej zleconej pracy. To ważne, bo nie znaczy to wcale, że każdy członek zespołu musi mieć pełnię kompetencji. Takową ma cały Scrum Team.

Jeżeli zaś chodzi o skład osobowy, to Podręcznik Scrum wyraźnie mówi, że Scrum Team składa się z: Właściciela Produktu (ang. Product Owner), Scrum Mastera i Zespołu Deweloperskiego (ang. Development Team). Mówiąc inaczej, Zespół Scrumowy to nazwa całej grupy zadaniowej. I być może to jest powód, dla którego nie jest on traktowany przez niektórych jako pełnoprawna rola.

Kim więc są osoby wchodzące w skład Scrum Team?

Product Owner, zwany w skrócie PO, to rola odpowiedzialna za wartość dostarczanego produktu. Niektórzy mówią, że odpowiada on za wymagania, ale to spojrzenie dokładnie w przeciwną stronę. Właściciel Produktu nie patrzy co klient chce, ale na czym może skorzystać.

Właściciel Produktu jest niejako przedstawicielem klienta (odbiorcy) w zespole i stara się zrobić wszystko, żeby wykonywana praca przyniosła jak najwięcej korzyści. Wymaga to bardzo dobrej znajomości potrzeb klienta i to na rozmowach z nim i z innymi interesariuszami PO spędza najwięcej czasu. Ale nie może on zapomnieć o reszcie zespołu.

Product Owner jest właścicielem artefaktu nazwanego Product Backlog, czyli zbioru wszystkich wymagań. To jego obowiązkiem jest utrzymywanie w nim porządku, priorytezowanie poszczególnych elementów i zapewnianie odpowiedniego poziomu zrozumienia wśród pozostałych osób. Oczywiście w tej pracy może wspierać się innymi osobami, ale w dalszym ciągu jest to jego odpowiedzialność.

Warto podkreślić, że PO to jedna osoba, a nie komitet. Nie da się współdzielić tej roli z inną osobą, bo problemy pojawią się w sytuacji, w której trzeba będzie ustalić co jest najważniejsze. Jedna osoba nie ma z tym kłopotu.

Wspomnieliśmy już, że w Scrum Guide ani razu nie pada słowo Developer. Zamiast tego, członkowie Development Team określani są mianem profesjonalistów. Wykonują oni pracę, tworząc co Sprint potencjalnie wdrażalny przyrost produktu. A mówiąc prościej – realizują wymagania i dostarczają coś gotowego do użycia i wartościowego.

Co najważniejsze, Zespół Deweloperski jest zostawiony samemu sobie. To znaczy, nikt mu nie mówi w jaki sposób ma realizować elementy Backlogu Produktu, które dostarcza im Product Owner.

Członkowie zespołu są zdolni do wykonania stawianych przez nimi zadań w sposób kreatywny. Aby nie zabijać tej kreatywności, działają w pełni samodzielnie.

Development Team to jedyna rola grupowa. Podręcznik Scrum zaleca, aby Zespół Deweloperski miał od 3 do 9 osób. Biorąc pod uwagę, że czasami Scrum Master też jest jednocześnie członkiem Development Teamu to cały Scrum Team będzie liczył od 4 do 11 osób.

Sam Development Team składa się z indywidualności, ale w żaden sposób nie są oni nazwani. Nie ma “ról zespołowych”, nie powinno się też tworzyć żadnych podgrup w ramach jednego Zespołu Deweloperskiego. Wszystko to razem ma zapewnić działanie wszystkich osób jak jednego organizmu.

Oczywiście nie znaczy to, że w ramach Development Teamu nie będzie osób, które mają swoje obszary zainteresowań i specjalności. Chodzi jednak o to, aby unikać przypisywania poszczególnych zadań do określonych osób. Nie powinno mieć miejsca obwinianie kogoś o niezrealizowanie części wymagania. To nie ta osoba zawiodła, ale zawiódł cały Development Team.

Scrum Master to chyba najbardziej “tajemnicza” rola w Scrum. Product Owner kontaktuje się z klientem, zbiera jego potrzeby i na ich podstawie buduje backlog, który z kolei relizuje Development Team. Ten podział odpowiedzialności jest prostu. Product Owner to “jak dostarczyć maksimum wartości dla klienta”, a Development Team “jak najefektywniej dostarczyć poszczególne fragmenty tejże ‘wartości’”. A Scrum Master?

Scrum Master, mówiąc krótko, jest odpowiedzialny za promowanie i wspieranie Scruma. Pomaga on wszystkim zrozumieć jego zasady, założenia i korzyści płynące z działania w określony sposób. Kiedyś spotkaliśmy się z określeniem “strażnik Scruma”, ale w naszym odczuciu jest to zbyt bierne stwierdzenie. Bo to nie tak, że SM pilnuje, żeby nie było odstępstw od zasad opisanych w Scrum Guide. On aktywnie dba o to, by wszyscy działali w określony sposób.

Wspiera więc Zespół Deweloperski, dbając o to by działał według określonych reguł i rozumiał korzyści płynące ze Scruma.

Wspiera w budowaniu ich kross-funkcjonalności i samoorganizacji, pomaga im rozwiązywać problemy, facylituje spotkania w ramach potrzeb i wskazuje sposoby na zapewnienie wysokiej wartości wytwarzanych produktów.

Scrum Master działa także ręka w rękę z Product Ownerem i pomaga mu w zarządzaniu backlogiem, a także upewnia się, że wszyscy tak samo rozumieją informacje w nim zawarte. Nie można też zapomnieć o tym, że Scrum Master uczy organizację interakcji z Zespołem Scrumowym i tłumaczy, które z nich są pomocne, a które nie. Promuje i szerzy wiedzę o Scrumie gdzie się tylko da i współpracuje z innymi SM-ami na rzecz zwiększania efektywności Scruma.

To piękne slogany i tak naprawdę trudno jest ściśle zdefiniować pracę SM-a. Posiłkując się analogią – tak jak Development Team niczym silnik spala paliwo dostarczone przez Product Ownera, tak Scrum Master będzie olejem. Niby nie jest niezbędny, ale gdy go zabraknie, to daleko nie pojedziemy.

Słowem podsumowania: w Scrumie zasadniczą jednostką organizacyjną jest Zespół Scrumowy czyli Scrum Team. Składa się on z jednego Product Ownera, jednego Scrum Mastera oraz Zespołu Deweloperskiego liczącego od 3 do 9 osób. Każda z tych ról ma ściśle określony zakres odpowiedzialności, które opisuje Scrum Guide.

Bardzo łatwo jest zacząć pracować w Scrumie. Wystarczy przypisać osoby do poszczególnych ról, zapoznać je ze Scrum Guidem i ruszyć do przodu. Tylko, że Scrum w dalszym ciągu pozostaje bardzo trudny do wdrożenia. Warto więc zapoznać wszystkich z praktycznymi aspektami tej metodyki.