Zespół Scrum (ang. Scrum Team) to niewielki zespół ludzi, wśród których jest jeden Product Owner, jeden Scrum Master oraz kilku Developerów. Pamiętać należy, że nie są to stanowiska, funkcje lub role w Zespole, ale odpowiedzialności – każda z nich jest kluczowa dla efektywności i skuteczności działania całego Zespołu i uzupełniają się one wzajemnie. Zazwyczaj wielkość całego Zespołu nie przekracza dziesięciu osób.

Dopuszczalne jest łączenie wielu odpowiedzialności przez jedną osobę. Może to być korzystne w przypadku Scrum Mastera, będącego jednocześnie Developerem, zwłaszcza w porównaniu do całkowicie „nietechnicznego” Scrum Mastera, który zupełnie nie rozumie problemów developerskich. Często jednak wywiązanie się z różnych odpowiedzialności zaczyna być trudne, np. Product Owner, poświęcający dużo czasu interesariuszom, może okazać się mało przydatnym Developerem (albo odwrotnie: skupi się na developmencie, zaniedbując interesariuszy). Rozważając przyjęcie na siebie więcej niż jednej odpowiedzialności warto zastanowić się, czy w ten sposób nie zaczniemy mieć problemu z jedną z Wartości Scrum jaką jest skupienie.

Cały Zespół Scrum odpowiada za częste i regularne dostarczanie wartościowego produktu, co przekłada się na wspomniane wcześniej odpowiedzialności Deweloperów, Product Ownera i Scrum Mastera. W działaniu Zespół Scrum kieruje się Celem Produktu, który określa aktualny kierunek rozwoju produktu, i z którego wynika zawartość Backlogu Produktu.

Zespół Scrum jest wszechstronny (ang. cross-functional) w stopniu umożliwiającym mu zbudowanie działającego produktu nadającego się do użytku. Jest to również Zespół samoorganizujący się, co oznacza, że jego członkowie samodzielnie decydują o tym jakie działania podejmą, kto je podejmie, kiedy i w jaki sposób je wykona. To oznacza, że każdy w Zespole jest managerem: zarządza swoją pracą tak, by wywiązać się z wziętej na siebie odpowiedzialności. W Zespole nie ma zdefiniowanej hierarchii – żadna z osób biorących na siebie jedną z odpowiedzialności nie staje się przez to przełożonym pozostałych członków Zespołu.

Developerzy

Developerzy (ang. Developers) to osoby odpowiedzialne za wytworzenie co Sprint kompletnego, gotowego do użycia produktu. Wnoszą do Zespołu kompetencje niezbędne do zbudowania takiego produktu (wytworzenia Przyrostu, który spełnia kryteria Definicji Ukończenia). Dzięki temu Zespół jest wszechstronny (ang. cross-functional) i jest w stanie dostarczać wartość poprzez realizację poszczególnych elementów Backlogu Produktu.

W Scrumie nie jest niezbędne, by każdy z Developerów był w stanie wykonać dowolny rodzaj pracy. Wszechstronność oznacza, że Developerzy mają w sumie dość kompetencji, by – łącząc swą wiedzę, umiejętności i wysiłki – wytwarzać regularnie, w każdym Sprincie, działający i nadający się do użycia produkt. Dzięki pracy zespołowej możliwe jest skuteczniejsze i szybsze rozwiązywanie złożonych problemów. Pomiędzy Developerami nie ma żadnej hierarchii, nie tworzą oni podzespołów

w ramach Zespołu Scrum,  ani żadnych innych struktur. Nie mają zdefiniowanych ról (np. tester, analityk czy programista). Są po prostu Developerami. Jeśli Product Owner albo Scrum Master uczestniczy w budowaniu produktu, staje się również Developerem,.

Scrum Master

Scrum Master to osoba odpowiedzialna za proces oraz efektywność działania całego Zespołu Scrum. Ma dbać o to, by Scrum był prawidłowo zrozumiany i stosowany zarówno w samym Zespole jak i w organizacji. Scrum Master odpowiada również za produktywność Zespołu, jego zaangażowanie i dba o Zespół, pomagając mu w rozwiązywaniu problemów i usuwaniu przeszkód (w metodyce nazywanych impediments) oraz wspomagając jego umiejętność samozarządzania. Nie jest jednak kierownikiem Zespołu ani liderem technicznym, nie może bezpośrednio polecać członkom Zespołu wykonania takiej czy innej pracy, karać ich czy nagradzać ani określać jaką funkcję będą pełnić w Zespole. Sposób działania Scrum Mastera jest często określany jako servant leadership, co można przetłumaczyć jako „wspierające przywództwo”. Można też powiedzieć, że Scrum Master to leader świadczący usługi na rzecz innych (ang. leader who serves).

Nie stoi nigdy w świetle jupiterów, wycofuje się, pozwala innym działać, obserwuje sytuację. Czasami o coś zapyta, choć wcale nie po to, by się czegoś samemu dowiedzieć, ale po to, by zapytanym uświadomić, że coś być może im umknęło. Gdy trzeba, wytłumaczy, skąd w Scrumie są takie a nie inne zasady i czemu służą poszczególne elementy tej metody. Często pomaga w prowadzeniu spotkań, choć nie jako moderator – raczej jako facylitator wspierający moderatora. Bardzo rzadko, w sytuacji kryzysowej, coś faktycznie Developerom lub Product Ownerowi zarekomenduje lub będzie się czegoś domagał.

Scrum Master powinien zapewniać, że Scrum jest rozumiany i stosowany. Wymieniona jest tam lista usług, które Scrum Master świadczy dla Developerów, Product Ownera i organizacji. Niektóre z tych zadań są bardzo konkretne, na przykład facylitacja zdarzeń Scrumowych czy usuwanie przeszkód, które utrudniają Zespołowi dostarczanie działającego produktu.

Sposób działania Scrum Mastera zależy od organizacji, w której funkcjonuje i od dojrzałości Zespołu. Na początku, gdy Agile i Scrum są nowością dla organizacji, a Zespół dopiero się formuje, Scrum Master może istotnie mieć pełne ręce roboty. Będzie walczył z ograniczającymi Developerów procedurami, organizował sale na spotkania, prezentował w praktyce niezbędne narzędzia i techniki, uczył Scruma (nie tylko Zespół, ale też managerów i wszystkich, którzy tego będą potrzebować).

Cały czas musi jednak pamiętać, że jego zadaniem nie jest uzależnienie Zespołu od omnipotentnego Scrum Mastera, który jak buldożer spycha wszystko z drogi Zespołu zanim jeszcze w ogóle coś stanie się problemem. Chodzi o coś dokładnie odwrotnego.

Product Owner

Product Owner to osoba odpowiedzialna za wartość produktu i pracy Developerów. Innymi słowy Product Owner odpowiada za to, by produkt był wartościowy a praca Developerów przeznaczona jedynie na rzeczy tę wartość podnoszące. Tak więc to Product Owner decyduje o kształcie produktu, odpowiada za to, czy produkt jest sensowny i dobrze pasujący do wymagań użytkowników/klientów, czy też nie.

Product Owner realizuje swoją misję przede wszystkim poprzez zarządzanie Backlogiem Produktu (a więc wymaganiami) oraz pracę z interesariuszami jak i Developerami. Ponieważ w Scrum decydowanie o kolejności realizacji zmian w produkcie odbywa się poprzez Backlog Produktu, Product Owner jest osobą, która ma ostatnie słowo co do kolejności elementów Backlogu. To jest najważniejsza, niezbywalna odpowiedzialność Product Ownera. Pozostałe działania potocznie z nią wiązane – pisanie wymagań, negocjowanie z interesariuszami czy projektowanie rozwiązań – albo nie są jej częścią albo też mogą być przez Product Ownera delegowane do Developerów lub innych osób.

Product Owner nie musi więc być analitykiem biznesowym, nie musi też koniecznie rozumieć dogłębnie tajników programowania. Musi natomiast rozumieć produkt i rynek, w którym on operuje, świetnie znać organizację i jej sytuację. Wszystko to jest mu niezbędne, by wiedzieć co jest w danej chwili dla produktu dobre, jakie zmiany w nim są potrzebne – a jakie nie. Zależnie od kontekstu produktu (przedsięwzięcia) sposób działania Product Ownera może być bliższy roli tradycyjnego Project Managera albo Product Managera.

Product Owner odpowiada wreszcie za komunikowanie takich informacji jak plany wydań, spodziewany zakres funkcjonalności w wydaniach itp. Innymi słowy, to Product Owner odpowiada na pytania w rodzaju „kiedy będzie funkcja X?” albo „co będzie w produkcie w następnym wydaniu?”.