W Scrum Guide opisane są jasne ramy postępowania odpowiadające na za sukces ich właściwego wykorzystywania. Wdrażając poprawnie wszystkich opisanych w nim filarów, zdarzeń, wartości i ról powinniśmy móc powiedzieć: Pracujemy w Scrum i to działa! Często jednak tak się nie dzieje, o czym pisała Basia w innym poście. Jedną z recept na to, żeby przeciwdziałać złym modelom jest umiejętne poznanie każdego z elementów opisanych w Przewodniku. Po wyjaśnieniu idei artefaktów Scruma, dziś chciałabym z Wami rozpocząć przygodę pt „Role w Scrum”.
Ile jest ról i która z nich jest najważniejsza?
Trzy role w Scrum to: Właściciel Produktu, Zespół Deweloperski oraz Scrum Master, które wspólnie tworzą Zespół Scrumowy. Każda z ról ma swoje odpowiedzialności, zadania do spełnienia, zachowania do przestrzegania. Ich pełne realizowanie jest niezbędne do tego, żeby móc powiedzieć, że odgrywa się swoją rolę z sukcesem.
Która z ról jest najważniejsza? Pewnie są tacy co odpowiedzą na to pytanie wskazując jedną konkretną rolę. Jednak taka odpowiedź, z mojego punktu widzenia, nie jest poprawna. Czy sama wizja i wymagania pozwolą ujrzeć produktowi światło dzienne? Nie! Potrzebny jest zespół specjalistów, który przekształci wspomniane wymagania w działający produkt. Jak zadbać o to żeby te dwie role w Scrum ze sobą współpracowały? Potrzebna jest osoba, która czuwa, edukuje i wspiera cały proces pracy w środowisku empirycznym. Jak więc widzicie każda z ról jest potrzebna i żadna nie jest ważniejsza od drugiej. Tylko dzięki wzajemnej kooperacji Zespół Scrumowy może wspólnie odnieść sukces. Jak wyglądają obowiązki przypisane do poszczególnych ról? Przejdźmy do krótkiego omówienia każdej z nich.
Właściciel Produktu
Wizjoner, kreator, maksymalizator wartości. Właściciela Produktu można opisywać wieloma epitetami czy przypisywać mu różne odpowiedzialności, jednak najważniejszą z nich jest wspomniana maksymalizacja wartości produktu i pracy Zespołu Deweloperskiego. To on zarządza Backlogiem Produktu, czyli decyduje o kolejności wykonywanej pracy, zapewnia, że Zespół Deweloperski rozumie elementy Backlogu Produktu w wymaganym stopniu. Jest za to wszystko odpowiedzialny, co nie znaczy, że nie może zlecić tych zadań Zespołowi Deweloperskiemu lub innym osobom. Wbrew powszechnemu mitowi „Właściciel Produktu musi rozpisywać Backlog Produktu”, może on poprosić Zespół by opisał w tym, czy w innym narzędziu wymagania, które on im przekazał. Jednak ostateczna weryfikacja i odpowiedzialność za to co Zespół zrealizuje spoczywa na jego barkach. Właściciel Produktu zawsze jest jeden, więc gdy ktoś chce coś zmienić w priorytetach musi skonsultować to właśnie z nim. Nikt, w ramach całej organizacji, nie powinien podważać jego zdania.
Zespół Deweloperski
Tester, Programista, Designer i kto jeszcze? Nic bardziej mylnego! Zespół Deweloperski cechuje się tym, że posiada grono ekspertów, którzy wspólnie są w stanie w ciągu sprintu dostarczyć Przyrost, potencjalnie gotowy do wydania. Nie wyróżnia się w nim nazw ról, bez względu na charakter wykonywanej pracy. Ideą działania w małych grupach (rekomendowane 3-9 osób) jest ułatwienie samoorganizacji i zminimalizowanie pętli informacji zwrotnej. Inaczej mówiąc w mniejszych zespołach łatwiej się porozumieć i ustalić plan pracy. Zespół Deweloperski omawia taki plan codziennie w ramach Daily Scrum, gdzie skupia się na kolejnych krokach, które mogą przybliżyć go do osiągnięcia Celu Sprintu. Wspólnie pracują nad Backlogiem Sprintu, którym samodzielnie zarządzają, oczywiście zgodnie z ustalonymi priorytetami.
Scrum Master
Scrum Master jest rolą, która pojawiła się w przewodniku w procesie ewolucji jego istnienia. Z początku Ken Schwaber i Jeff Sutherland wyróżniali rolę klasycznego Product Managera, pomijając zarówno Właściciela Produktu jak i Scrum Mastera. Kiedy po raz pierwszy na łamach Scrum Guide pojawił się Scrum Master (SM) jego odpowiedzialności różniły się od tych powszechnie znanych obecnie. To co na pewno nie uległo zmianie to konieczność znajomości zasad ale i ich świetnego zrozumienia. obry Scrum Master nigdy nie powinien się zastanawiać jakie wydarzenia mamy w Scrum. To tak jak z tabliczką mnożenia, nawet obudzony w środku nocy powinieneś móc ją wyrecytować. Same „wykucie na blachę” nie gwarantuje jednak bycia dobrym SMem. Zrozumienie zasad to długa droga, którą najlepiej podążać przez ciągłą praktykę.
Swoją przygodę można zacząć na wiele sposobów my polecamy zacząć oczywiście od Scrum Guide i zdobycia certyfikatu potwierdzającego wiedzę teoretyczną. Szczegółowo o roli Scrum Mastera opowiedziałam w artykule “Kim jest i co robi Scrum Master”.
Podsumowanie
Każda z ról ma swoje odpowiedzialności, które musi spełniać by cały Zespół Scrumowy mógł powiedzieć: tak, robimy to dobrze. Znajomość podstaw jest bowiem kluczem do zaczęcia we właściwy sposób swojej przygody w pracy w zwinnym środowisku. Aby dowiedzieć się więcej o każdej z ról sprawdź nasze poprzednie i kolejne wpisy!
Sprawdź: Fakty i mity dotyczące odpowiedzialności w Scrum Team
Sprawdź nasze ostanie wpisy:
