Blog

Na każdym szkoleniu dotyczącym Scruma pojawia się niezmiennie pytanie o to, które odpowiedzialności można łączyć. Oczywiście bycie tylko Developerem, Product Ownerem lub Scrum Masterem jest rozwiązaniem optymalnym, ale często w organizacjach łączenie odpowiedzialności jest nieuniknione. Takim typowym połączeniem jest Developero-Scrum Master, dużo rzadziej zdarza się Developero-Product Owner. Do wyjątków należą osoby, które próbują być jednocześnie Scrum Masterem i Product Ownerem.

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

Urok definicji Scruma polega na tym, że znajduje się w niej jedynie opis elementów metody i wiążących ich zasad. Scrum Guide w praktyce niczego nie nakazuje, nie ma też w nim żadnych zakazów. Twórcy metody wyszli z założenia, że jej użytkownicy, rozumiejąc obowiązujące zasady, sami dojdą do tego, co muszą robić, a czego robić nie powinni. Nie ma więc potrzeby czegokolwiek nakazywać lub zakazywać.

Dlatego też bycie jednocześnie Scrum Masterem i Product Ownerem zakazane nie jest, ale też nie oznacza to wcale, że odpowiedzialności te da się łą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 swych obowiązków spędza dużo czasu poza Zespołem, rozmawiając z interesariuszami (użytkownikami, klientami, inwestorami itd.) 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 użytkowników – 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 sposobu pracy Developerów.

Z drugiej strony podstawowym narzędziem, jakiego używa Scrum Master, są obserwacja, zadawanie pytań, aktywne nicnierobienie (czyli pełna gotowość do działania, ale powstrzymywanie się od niego, aby dać możliwość działania Product Ownerowi i Developerom). Aby zachować zdolność do reagowania, Scrum Master musi spędzać z Zespołem sporo czasu – na pewno więcej, niż Product Owner będzie w stanie realnie na to poświęcić.

Próba łączenia tych odpowiedzialności prowadzi niezmiennie do jednego z trzech fatalnych scenariuszy:

1. Zespół nie ma efektywnego Scrum Mastera,
2. albo produkt i interesariusze są zaniedbywani,
3. albo (co dzieje się najczęściej) działanie zarówno Scrum Mastera, jak i Product Ownera, jest mało skuteczne.

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

Należy pamiętać, że w Scrumie zdefiniowane są trzy odpowiedzialności (ang. accountabilities): Developera, Scrum Mastera lub Product Ownera. Są one rozłączne, ale wzajemnie się uzupełniają. Członkowie Zespołu nigdy nie powinni się znaleźć w konflikcie interesów lub personalnym z powodu wywiązywania się z podjętych zobowiązań – jeśli do tego dojdzie, źródłem nie są wymogi definicji Scruma, ale sposób postępowania konkretnych osób. Postępowania zapewne niewłaściwego, skoro doprowadza do złych relacji w Zespole.

Natomiast normalną i wręcz oczekiwaną sytuacją będzie inny rodzaj konfliktu, jakim jest konstruktywna różnica zdań. Dzięki niej ujawniane zostają różne punkty widzenia i pojawia się dyskusja, której efektem jest wybór takiego czy innego sposobu postępowania Zespołu jako całości. Pojawianie się tej formy konfliktu nie jest objawem ścierania się odpowiedzialności, ale wynikiem dążenia do wywiązania się z nich. Perspektywa Developerów, Product Ownera i Scrum Mastera różni się, ale dążą oni do jednego celu, jakim jest dostarczenie interesariuszom wartościowego produktu.

Co stanie się, gdy Scrum Masterem i Product Ownerem będzie ta sama osoba? Jedna z perspektyw, z których każda jest bezcenna dla Zespołu, może zupełnie zaniknąć. Najlepiej zobrazować to na przykładzie.

Przyjmijmy, że trzeba coś zrealizować w produkcie na bardzo nieodległą 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 ma zapewnić, że wszyscy działać będą empirycznie – a więc przede wszystkim, że zachowana zostanie przejrzystość i nikt nie pokusi się o zbudowanie produktu, który tylko pozornie jest ukończony.

W jaki sposób Product Owner będący też Scrum Masterem ma jednocześnie naciskać na Developerów, by dostarczyli jak najwięcej w krótkim czasie (to odpowiedzialność Product Ownera) i uczyć ich asertywności niezbędnej do powiedzenia, że nie wszystko jest możliwe (to odpowiedzialność Scrum Mastera)? Nawet zaawansowania schizofrenia nie pomoże, bo chorujący na nią nie potrafią być na raz dwoma swymi osobowościami, ani nie potrafią w świadomy sposób szybko się między nimi przełączać.

Łatwo domyślić się, że w opisanej sytuacji Product Owner zapomni na moment, iż jest też Scrum Masterem. A to oznaczało będzie, że Scrum Master znika z Zespołu w momencie, gdy może być naprawdę potrzebny.

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 tego potrzeba – zrozumienia samej metody Scrum. 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 odpowiedzialności łączy jedna osoba, 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 takiemu Product Ownerowi liczyć na wymianę opinii z kimś, kto na bieżący development i plany rozwoju produktu patrzy z nieco innej perspektywy i mógłby pomóc w zagalopowaniu się w niewłaściwą stronę. Owszem, mogą to zrobić również Developerzy, ale skupiają się oni przede wszystkim na wytwarzaniu produktu (budowaniu kolejnych Przyrostów), 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 rozszerzyć przestrzeń, w której Developerzy mają autonomię i mogą samodzielnie zarządzać swą pracą. Zabiega też o wzmocnienie pozycji Product Ownera, jeśli z jakiegoś powodu jest ona słaba. To wymaga czasu i specyficznych umiejętności, które nie każdy posiada.

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 interesie produktu jest, by to się działo, ale niekoniecznie będzie miał czas się tym zająć. Ba, może nawet nie mieć świadomości istnienia takich problemów, bo pracując intensywnie z interesariuszami, niekoniecznie ma możliwość wniknąć głębiej w to, jak pracują Developerzy.

Oni sami zaś mają ograniczony czas na wędrówki od jednego do drugiego decydenta w organizacji, by uzyskać niezbędne wsparcie czy usunąć jakieś ograniczenie, które spowalnia postęp prac w Sprincie. Jasne, robią to, ale nie mogą robić przede wszystkim tego, bo jednak ich zasadniczą odpowiedzialnością jest wykreować produkt pozwalający osiągnąć przyjęty Cel Sprintu. Dlatego mają prawo liczyć na pomoc ze strony Scrum Mastera.

Bardzo wątpliwe, czy będą mogli liczyć na takie wsparcie, jeśli Scrum Master będzie jednocześnie Product Ownerem. Osoba ta stanie przecież często przed iście diabelską alternatywą, zmuszona do wyboru, które obowiązki zaniedbywać.

Jeśli już trzeba łączyć odpowiedzialności…

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

Z kronikarskiego obowiązku dodam, że twórcy Scruma rozważali wprowadzenie zakazu bycia jednocześnie Scrum Masterem i Product Ownerem (z powodów wspomnianych powyżej), lecz ostatecznie tego nie zrobili. Znają bowiem osoby, które potrafią to zrobić bez zaszkodzenia Zespołom i produktom, za jakie odpowiadają. Nie powinno to być jednak podstawą do twierdzenia, że w takim razie wszędzie indziej takie łączenie odpowiedzialności też zadziała dobrze.