Blog

Na każdym szkoleniu dotyczącym Scruma, czy to certyfikowanym (PSM, PSPO), czy naszym autorskim (Scrum Master Toolbox®, Product Owner Toolbox®) pojawia się niezmiennie pytanie o to, które role można łączyć. Oczywiście bycie tylko Developerm, Product Ownerem lub Scrum Masterem jest rozwiązaniem optymalnym, ale często w organizacjach łączenie ról jest nieuniknione. Takim typowym połączeniem jest Developero-Scrum Master, dużo rzadziej zdarza się Developero-Product Owner. Na szczęście do wyjątków należą osoby, które próbują być jednocześnie Scrum Masterem i Product Ownerem.

Czy wolno mi być Scrum Masterem i Product Ownerem w tym samym zespole?

Urok definicji Scruma polega na tym, że zawiera on zestaw elementów i reguł, jakie te elementy ze sobą wiążą tak, aby możliwe było rozwiązywanie złożonych problemów z wykorzystaniem empiryzmu. To oznacza, że Scrum Guide w praktyce niczego nie zakazuje, bo nie jest to konieczne. Jeśli przeczytamy ową definicję metody ze zrozumieniem i zaczniemy praktycznie korzystać ze Scruma, pewne rzeczy będą w naturalny sposób niemożliwe i nie ma potrzeby ich zakazywać.

Dlatego też bycie jednocześnie Scrum Masterem i Product Ownerem zakazane nie jest, ale też nie oznacza to wcale, że role te da się połączyć.

Product Owner za mało czasu spędza z Developerami, by być skutecznym Scrum Masterem

Pierwszy, najbardziej podstawowy powód: Product Owner z racji obowiązków związanych z tą rolą spędza dużo czasu poza zespołem, rozmawiając z interesariuszami, klientami, często biorąc udział w politycznych rozgrywkach wewnątrz organizacji (niestety takie są realia pracy Product Ownera w dużych korporacjach). Do tego konieczne jest śledzenie trendów na rynku i dbanie o to, by rozwój produktu odpowiadał bieżącym potrzebom – a te nieustannie się zmieniają. To angażuje Product Ownera w działania poza zespołem na tyle intensywnie, że nie ma on z reguły szans na obserwowanie dynamiki wewnątrz Zespołu Developerskiego.

Z drugiej strony podstawowym narzędziem, jakiego używa Scrum Master jest obserwacja, zadawanie pytań, aktywne nic-nierobienie (czyli pełna gotowość do działania, ale powstrzymywanie się od niego, aby dać możliwość działania Developerom). Aby zachować zdolność do działania, Scrum Master musi spędzać z zespołem stosunkowo dużo czasu, na pewno więcej, niż skuteczny Product Owner będzie w stanie realnie na to poświęcić.

Próba łączenia tych ról prowadzi niezmiennie do jednego z trzech fatalnych scenariuszy: zespół nie ma efektywnego Scrum Mastera, albo produkt i interesariusze są zaniedbywani, albo (co dzieje się najczęściej) i rola Scrum Mastera, i Product Ownera jest mało efektywna.

Różne odpowiedzialności ciężko ze sobą pogodzić

Należy pamiętać, że w Scrumie każda rola ma ściśle określoną odpowiedzialność (ang. accountability), które są rozłączne, ale powodują, że role się wzajemnie uzupełniają. Rozdzielenie odpowiedzialności nie wynika z ustawienia ról w Scrumie w jakiejś kontrze lub nieustannym konflikcie, mówimy tu co najwyżej o konstruktywnej różnicy zdań, pozwalającej wybrać najlepsze (w danej sytuacji) rozwiązanie, uwzględniające potrzeby każdej z ról (a wynikające z ich odpowiedzialności).

Nie da się dokonywać analizy sytuacji i myśleć o możliwych rozwiązaniach i działaniach jeśli jednocześnie próbuje się patrzeć na nią z różnych perspektyw, a to byłoby wymagane, gdyby jedna i ta sama osoba była zarówno Product Ownerem, jak i Scrum Masterem.

Wyobraźmy sobie przypadek taki: wiadomo, że trzeba coś zrealizować w produkcie na bardzo bliską datę, a problem jest technicznie trudny i na pewno sprawi problem Developerom. W takiej sytuacji Developerzy powinni zadbać o to, by nie zdegradować produktu (na przykład wprowadzając do niego w niekontrolowany sposób dług techniczny), Product Owner powinien zadbać o uzyskanie maksimum wartości możliwej do osiągnięcia w dostępnym czasie, a Scrum Master musi zapewnić, że wszyscy działać będą empirycznie – a więc przede wszystkim, że zachowana zostanie przejrzystość i decyzje będą oparte na tym, co wiadomo na pewno.

A teraz wyobraźmy sobie, że w opisanym scenariuszu Scrum Master i Product Owner to ta sama osoba. Jak ma jednocześnie naciskać na Developerów, by dostarczyli jak najwięcej (to potrzeba Product Ownera) i uczyć zespół asertywności niezbędnej do powiedzenia, że nie wszystko jest możliwe (to potrzeba Scrum Mastera)? Nawet zaawansowania schizofrenia nie pomoże, bo chorzy nie potrafią być na raz dwoma swymi osobowościami, ani nie potrafią w świadomy sposób szybko się między nimi przełączać.

W tym przykładzie pewnie wygrałaby potrzeba Product Ownera, bo jej spełnienie łatwo przekłada się na ocenę skuteczności jego pracy przez przełożonych. Ale istnieje duże ryzyko dramatycznego spadku przejrzystości w organizacji, gdyż Developerzy nie będą w stanie zrozumieć niespójnego przekazu od Scrum Mastero-Product Ownera.

Ciężko doradzać samemu sobie

Nikt nie jest alfą i omegą, stąd też jednym z obowiązków Scrum Mastera jest pomoc Product Ownerowi w zakresie stosowanych praktyk, ale też – jeśli potrzeba – zrozumienia samej metody. To implikuje, że Scrum Master sam musi mieć czas na zrozumienie frameworku, żeby móc później podzielić się swoją wiedzą z Developerami i Product Ownerem.

Jeśli obie role połączymy, Product Owner nie może liczyć na swojego Scrum Mastera… bo sam nim przecież jest. Jeśli czegoś nie wie, albo z czymś sobie nie radzi (bo brak mu doświadczenia), nikt mu nie pomoże. W szczególności ciężko liczyć na wymianę opinii z kimś, kto na bieżący development i plany rozwoju produktu patrzy z innej, niż Product Owner, perspektywy. Owszem, mogą to zrobić Developerzy, ale skupiają się oni przede wszystkim na wytwarzaniu produktu i technologii, a niekoniecznie na procesie i narzędziach potrzebnych Product Ownerowi.

Product Owner zajmuje się produktem, niekoniecznie organizacją

Scrum Master w miarę rozwoju zespołu zaczyna częściej pracować z całą organizacją, aby wykreować lepszą przestrzeń dla pracy Developerów ale też i rozwoju produktu. Product Owner skupia się przede wszystkim na produkcie, ciężko więc oczekiwać od niego, że będzie się angażował w usuwanie jakichś organizacyjnych niedociągnięć, które spowalniają development. Tak, w jego interesie jest, by to się działo, i ma to wartość dla niego, ale niekoniecznie będzie miał czas się tym zająć. Również Developerzy nie mogą przesadnie skupiać się na czynnościach, które nie są związane z budowaniem produktu w kolejnych sprintach – i stąd potrzeba istnienia tej trzeciej roli, Scrum Mastera.

Jeśli połączymy rolę Scrum Mastera i Product Ownera, praktycznie nie ma szans, by osoba obciążona takimi obowiązkami miała czas na cokolwiek, co nie dotyczy produktowego „tu i teraz”. Raz, że taki Scrum Master będzie potencjalnie mało skuteczny we wspieraniu rozwoju zespołu (więc wciąż gros pracy będzie potrzeba wykonać w zespole, a nie poza nim), dwa: najzwyczajniej braknie czasu na robienie czegoś, co nie jest absolutnie niezbędne w bieżącym developmencie. Tak wdrożony Scrum ma spore szanse kuleć, a poziom samoorganizacji i umiejętności usprawniania będą rozwijać się wolno.

Jeśli już trzeba łączyć role…

…to na pewno nie te dwie, bo jest to fizycznie niemożliwe. Developero-Scrum Master i Developero-Product Owner to też nienajlepsze rozwiązanie, ale to już temat na osobny artykuł.