Niektórym pomysł na zestawienie ról PO i SM może wydawać się nieprawdopodobny. Inni stwierdzą, że są to dwie przeciwstawne role. A kolejni porównają ich do Batmana i Supermana. My jak zwykle mamy swoje zdanie. Dziś pojedynek Product Owner kontra Scrum Master.
Pytanie od publiczności
Na większości szkoleń prędzej czy później pada oczekiwane przez nas pytanie: Czy Product Owner może być jednocześnie Scrum Masterem? Może. Podstawa programowa, czyli Scrum Guide, nie zawiera ani jednego słowa, które zabraniałoby pełnienie tych funkcji jednocześnie. A jeśli coś nie jest zabronione, to jest dozwolone. Parafrazując reklamę znanego producenta oprogramowania – impossible is nothing.
Bo przecież tak jak (w teorii) można łączyć funkcje Product Ownera i Scrum Mastera, tak samo można łączyć inne role w naszym zespole. Mam tu na myśli np. jednoczesne bycie SM-em i członkiem Zespołu Deweloperskiego. Nie jest to łatwe, ale założę się, że często mieliście do czynienia z taką sytuacją. W niektórych organizacjach jest to nawet najbardziej popularny sposób na radzenie sobie z faktem, że SM to tylko koszt. Co więcej, doświadczony Scrum Master często świetnie wykorzysta fakt, że zespół traktuje go jak „swojego”.
A jak to naprawdę jest z łączeniem ról PO i SM?
PO kontra SM
Łączenie ze sobą roli PO i SM na pewno nie jest łatwe, żeby nie napisać, że jest niemożliwe. Obie te scrumowe role mają bardzo konkretny, rozłączny zestaw odpowiedzialności.
Product Owner odpowiedzialny jest za maksymalizowanie wartości inkrementu dostarczanej interesariuszowi. Czy to oznacza, że będzie naciskał na wykonanie maksymalnej ilości pracy i osiągnięcie 200% normy? I tak, i nie. Mądry Product Owner znajdzie balans między ilością wykonanej pracy, a wartością produktu. Przede wszystkim będzie rozumiał, że dążenie za wszelką cenę do realizacji całego backlogu jest po prostu nieopłacalne.
Scrum Master, jak doskonale wiemy, odpowiedzialny jest za praktyczne wykorzystanie metodyki i dbanie o to, by była ona stosowana dobrze i efektywnie. Dodatkowo zakres jego odpowiedzialności zawiera, między innymi, ochronę zespołu przed nadmiernie ambitnym Product Ownerem. SM może sygnalizować przeładowanie Backlogu Sprintu, być ciałem doradczym na Planowaniu Sprintu i bronić zespół przed wrzutkami.
Już na pierwszy rzut oka widać, że są to dwie, wzajemnie wykluczające się role. Nie dziwi fakt, że łącząc je w jednej osobie otrzymujemy przepis na schizofrenię. A nawet w najlepszym przypadku czeka nas ciężka praca nad skutecznym podziałem obowiązków i zachowaniu odpowiedniego balansu.
Praktyka bez rozdwojenia jaźni
W mojej kilkuletniej „zwinnej” karierze tylko raz widziałem sytuację, w którejś ktoś łączył role PO i SM w jednej osobie. Można powiedzieć, że bohaterem tej sytuacji był nasz bardzo dobry znajomy, bo byłem to ja we własnej osobie. Mogę więc wszystkich uspokoić, że dzisiejsze rozważanie nie są czysto teoretyczne.
Jak było? Dziwnie. Jako doświadczony i zwinny specjalista, zdawałem sobie sprawę z trudnej sytuacji, w której się znalazłem. Ale na szczęście nie byłem w niej sam. W codziennych obowiązkach pomagał mi w tym tak samo doświadczony i zwinny Zespół Deweloperski. Doskonale rozumiał on sytuację i wspierał mnie w moich scrummasterskich obowiązkach. Można więc powiedzieć, że rolę SM pełniliśmy zbiorowo. I znów, przecież tego też Scrum Guide nie zabrania. To Product Owner musi być jedną osobą.
Tyle moje osobiste doświadczenia, które mogły przecież być zupełnie inne, gdyby tylko zespół nie udzielił mi wsparcia. Czy jestem w stanie powiedzieć teraz, która z ról wygrałaby w moim wewnętrznym pojedynku PO kontra SM? Nie wiem. Na szczęście nie musiałem się o tym przekonywać, bo po bardzo szybko z zespołu wyłonił się świetny Scrum Master.
Byłem uratowany.
Co nie jest zabronione…
Co pokazała ta sytuacja? Jakie powinniśmy z niej wyciągnąć wnioski? Da się.
Ale stwierdzenie „da się” wcale nie jest rekomendacją. Co więcej, wydaje mi się, że nasz mały scrumowy sukces osiągnęliśmy wtedy zupełnie przypadkowo. Zawdzięczaliśmy go głównie naszemu doświadczeniu, odpowiedzialności i wspólnemu dążeniu do realizacji wizji i celu. I zadziało się to pomimo (a nie „dzięki”) łączeniu przeze mnie roli PO i SM-a.
Nie wiem, jakie są Wasze osobiste doświadczenia z łączeniem ról Product Ownera i Scrum Mastera, ale nasza rekomendacja jest jasna – nie idźcie tą drogą. Oczywiście, w sytuacji, w której nie ma Scrum Mastera, a jest nam bezwzględnie potrzebny, postawmy na to rozwiązanie jeżeli absolutnie nie mamy innych możliwości. Nie jest ono idealne, ale cel w tym przypadku uświęci środki.
Koniecznie jednak postarajmy się, aby Scrum Master pojawił się tak szybko, jak to tylko możliwe. Nie ma znaczenia, czy będzie on jednym z członków zespołu czy zatrudnionym z zewnątrz specjalistą. Unikajmy jednak jak ognia sytuacji, w której łatka SM zostaje przyszyta do Product Ownera i zostaje z nim na stałe z powodu oszczędności. W końcu „SM to tylko koszt”, nieprawdaż?
O tym co się dalej i w jakim kierunku pójdzie cała organizacja przy takim podejściu pisaliśmy w poście o Broken Window Theory. W skrócie: to się nie skończy dobrze.
Swego czasu temat mnie intrygował, właśnie ze względu na różnego rodzaju pomysły „optymalizacji” zespołów scrumowych.
Pytanie należałoby może zadać inaczej – czy łączenie roli PO i SM w ramach jednej osoby jest dobre dla Scruma?
Najbardziej podstawową i najbardziej oczywistą wydaje się być, że perspektywy PO i SM są różne. PO „chce” aby jak najwięcej jak najważniejszych elementów Backlogu zostało dowiezionych. SM „chce” aby działo się to zgodnie z regułami Scruma i jako adwokat Scruma, a przez to również samego zespołu developerskiego, dba aby zakusy PO nie przekroczyły ram scruma. I tu pojawia się pytanie czy dobre dla Scruma jest aby rozbieżne poglądy reprezentowała ta sama osoba czyli nasz PO+SM? Czy to będzie efektywne?
Takich przykładów można by mnożyć. Jednak wskazałbym jeszcze jeden – mianowicie wywodzące się manifestu Agile a mianowicie „Ludzi i interakcje”. To ludzie i interakcje budują Scruma, w tym różne poglądy i możliwość ich wyartykułowania, konieczność wypracowania kompromisu, uwzględnienie różnych za i przeciw, itd. Liczba interakcji jest zależna od liczby osób, a nie od liczby ról. Lekceważąc rolę SM lub upychając ją w osobie PO, to o jakim poziomie interakcji PO – SM – DEVs możemy w ogóle mówić?
Przy okazji. W początkowych wizjach Scruma nie było roli Scrum Mastera. Był tylko „Product Manager” i „Development Teams”. Rola Scrum Mastera pojawiła się później. Być może twórcy Scruma zorientowali się, że dwubiegunowa sytuacja nie jest dla procesu dobra. Być może zorientowali się, że potrzebny jest niezależny arbiter Scruma czyli nasz Scrum Master, aby proces był efektywny? Czy w takim przypadku zakładali, że arbiter ten będzie tą samą osobą co „zlecający” Product Manager / Product Owner? Czy mozna być „sędzią we własnej sprawie?”
W mojej prywatnej ocenie, pełnienie przez tą samą osobę ról PO i SM jest jednym z najgorszych naruszeń zasad procesu scrumowego. Ale jak ktoś chce takie podejście nazywać Scrumem, to niech sobie nazywa. Scrum Guide mu tego nie zabroni…