Łączenie ról w Scrumie

Łączenie ról w Scrumie – poznaj kilka możliwych kombinacji – ich plusów i minusów oraz zagrożeń, jakie mogą wynikać z wypełniania obowiązków dla dwóch stanowisk jednocześnie. Czy Product Owner powinien być jednocześnie Scrum Masterem? Jakie konsekwencje może mieć bycie członkiem Zespołu Developerskiego przy jednoczesnym pełnieniu innej roli? O tym w 35. odcinku podcastu Porządny Agile.

Zobacz wersję wideo:

Dodatkowe materiały

• Współpraca Scrum Mastera z Product Ownerem

TRANSKRYPCJA

Kuba: Dzisiaj porozmawiamy na temat łączenia ról w Scrumie. Odcinek w sumie agendę ma bardzo prostą, ponieważ najpierw opowiemy Tobie o konkretnych kombinacjach łączenia ról i zagrożeń, jakie z tego mogą wynikać. I w drugiej części odcinka opowiemy o tym, jak do tego podejść – co można zrobić z tym w praktyce. Skupimy się konkretnie na łączeniu ról w Scrumie, więc porozmawiamy tylko o roli Product Ownera, Scrum Mastera i Zespołu Developerskiego. Zastanawialiśmy się chwilę z Jackiem na temat możliwych innych kombinacji, ale stwierdziliśmy, że wyłączymy je z zakresu tego nagrania.

Jacek: Pewne ważne takie zastrzeżenie na początku tego odcinka jest takie, że te wszystkie historie, które przytoczymy, one mają bardzo różny kontekst i mamy przypadki też takie, które będą przeczyć temu, co powiemy w tym odcinku. Doszliśmy z Kubą do wniosku, że bardzo dużo zależy od talentu konkretnej osoby, która takie role łączy i chcielibyśmy, żebyś przez ten pryzmat spojrzał bądź spojrzała na ten konkretny odcinek.

Kuba: Innymi słowy – wiemy, że są pojedyncze przypadki, które przeczą temu, co powiemy, natomiast my spróbowaliśmy czerpać na bazie naszych doświadczeń w pracy z zespołami i spróbować wyciągnąć coś, co jest w przybliżeniu zazwyczaj prawdziwe, ale nie zawsze prawdziwe.

To przejdźmy do konkretnych kombinacji łączeń ról i i ich zagrożeń. Zaczniemy od tego, co wydaje nam się, że jest najczęstszym przypadkiem łączenia roli, czyli łączenie roli Scrum Mastera i członka Zespołu Developerskiego czy Scrum Mastera i Zespołu Developerskiego.

Jacek: Tak, i każdą taką kombinację przedstawimy w plusach i w minusach – z naszej perspektywy, na bazie naszych doświadczeń. I jeśli mówimy o tej perspektywie łączenia Scrum Mastera i członka Zespołu Developerskiego, to z mojej perspektywy najpoważniejszym zagrożeniem jest to, że bardzo łatwo jest zatracić perspektywę pracy jako Scrum Master i skupić się bardzo mocno na procesie wytwarzania. I bardzo często takie sytuacje widzę w praktyce, gdzie członek Zespołu Developerskiego, angażując się w pomaganie zespołowi w realizacji Celu Sprintu, no, traci z pola widzenia obowiązki Scrum Mastera, no i po prostu zaprzestaje ich wykonywania, jako że pełne skupienie przeznacza na to, żeby po prostu wspierać zespół w tym, żeby jakieś tam założenie odnośnie do pracy na konkretny Sprint zostały zrealizowane.

Kuba: Podobnym minusem do tego, co mówisz, mniej z perspektywy skupienia, a bardziej z perspektywy braku czasu jest, no właśnie, brak możliwości realizowania tej roli Scrum Mastera po prostu czasowo. „Chcę się skupiać, chcę mieć perspektywy różne, tylko po prostu kalendarz ma skończoną ilość godzin, ja mam skończoną ilość sił dziennie czy w tygodniu, no i po prostu nie mam czasu, żeby pełnić tę rolę łączoną, rolę Scrum Mastera i Developera jednocześnie, muszę wybierać, pomiędzy Celem Sprintu, między rozwiązywaniem jakichś impedimentów, pracą w community scrummasterskich w firmie, swoim rozwojem – to wszystko powoduje, że mam trudne wybory, wybieram tylko te rzeczy, które są absolutnie niezbędne do przetrwania zespołu. Że tak powiem, żyję z dnia na dzień, a takie jakieś bardziej angażujące mnie czasowo rzeczy zostają po prostu odłożone na potem, albo w ogóle są nierealizowane”.

Jacek: Innym minusem, który dostrzegamy, jest to, że rozwijanie się w roli Scrum Mastera czy rozwijanie się w jakiejkolwiek innej roli członka Zespołu Developerskiego – niezależnie, czy to jest programista, analityk, marketingowiec, prawnik – po prostu zajmuje czas. I automatycznie chcąc wejść tak na poważnie w pełnienie roli Scrum Mastera, no to otwieramy sobie dwie ścieżki rozwoju, które są właściwie jakby… nieskończone. Zawsze można być lepszym, zawsze można wiedzieć więcej, zawsze można doświadczyć większej ilości sytuacji i przykładów, no i po prostu dla mnie to jest jakaś taka ścieżka pewnego kompromisu, no bo doba ma ograniczoną ilość godzin, no i z pewnych rzeczy na 100% będziemy musieli zrezygnować – albo z tej naszej takiej pierwotnej funkcji członka Zespołu Developerskiego, albo z roli Scrum Mastera i jest to bolesny wybór, a w konsekwencji powoduje, że nie będziemy tak doskonali w tych swoich rolach, jak moglibyśmy być, gdybyśmy mieli tylko jedną rolę na głowie, a nie dwie.

Kuba: Ale to, co mówisz jako minus, jest jednocześnie takim pragmatycznym, możliwym plusem – zwłaszcza z perspektywy rozpoczynania kariery np. w specjalizowaniu się w roli Scrum Mastera. No, w tą rolę często wchodzą osoby, które wcześniej pełniły jakąś kompetencję techniczną w zespole, np. programista, tester czy analityk – i często te osoby dopiero zaczynając w roli Scrum Mastera, jeszcze nie wiedzą, czy sprawdzą się, czy im się to będzie podobać, czasem też mają ochotę po prostu dalej konsekwentnie trzymać się tej specjalizacji technicznej, no i to jest jednocześnie minus, ale ja widzę to też jako trochę plus, że jako Scrum Master, zwłaszcza początkujący, może nie musimy od razu podejmować zobowiązania na 100%, że „Tak, będę od tej pory już tylko Scrum Masterem, porzucam kompletnie swoją specjalizację testerską” – no i przynajmniej przez jakiś czas ta łączona rola może pozwolić posmakować scrummasterowania, ale jednocześnie nie porzucić kompletnie tej ścieżki do tej pory technicznej czy eksperckiej.

Jacek: No i takim jeszcze jednym plusem jest to, że kiedy ta rola Scrum Mastera i członka Zespołu Developerskiego jest łączona, no, jest mniejsza szansa, że Scrum Master „odlepi” się od zespołu czy odpłynie, zacznie żyć swoim życiem, zacznie mieć jakieś takie porady, które nie do końca już mają styczność z rzeczywistością, tak więc na pewno to łączenie roli w tym kontekście może być pomocne o tyle, że po prostu Scrum Master będzie blisko tych prawdziwych problemów, prawdziwej pracy, no i – co więcej – będzie je po prostu rozumiał – albo poprzez posiadanie odpowiedniej wiedzy, albo poprzez bardzo bliskie współpracowanie z resztą teamu, no i po prostu bycie na bieżąco w temacie wszelkiego rodzaju niuansów, problemów, usterek, rzeczy, które nie działają.

Kuba: Przejdźmy zatem do drugiej z możliwych kombinacji – o tym, co z tym zrobić, z tymi zagrożeniami czy minusami, które wymieniliśmy – opowiemy w drugiej części odcinka, a teraz przejdźmy do kolejnej kombinacji. Product Owner i Scrum Master. Też naszym zdaniem dosyć popularny temat łączenia tych ról – nie zawsze w oczywisty sposób do wykonania. Głównie widzimy minusy – zacznij, Jacek, od pierwszego.

Jacek: Tak, jeśli chodzi o minusy łączenia Product Ownera i Scrum Mastera, z mojej perspektywy – bycie Product Ownerem to jest, mówiąc po staropolsku, full-time job, czyli praca na pełen etat. W momencie, kiedy chcemy zrealizować tą rolę Product Ownera, która jest bardzo szeroka i oczywiście też kontekstowo, jeśli chodzi o organizację, no to po prostu tej przestrzeni na to, żeby jeszcze do tego dokładać jakieś czynności związane z rolą Scrum Mastera, no, tego czasu po prostu nie będzie zbyt wiele. Jeśli spojrzysz na tą rolę Product Ownera szeroko, no to to jest i kontakt z użytkownikami, i wszelkiego rodzaju badania, testy, kontakt ze stakeholderami, praca nad Backlogiem Produktu i tak dalej – można byłoby dalej iść głębiej i wymieniać… schodzić na poziom poszczególnych zadań, no to – z mojej perspektywy – po prostu takie głębokie, „na poważnie” wejście w rolę Product Ownera, no, po prostu „zjada” etat – i to lekko. Na bazie moich doświadczeń, jakby… nie ma już przestrzeni, żeby wejść sensownie, świadomie, z wartością dla zespołu w rolę Scrum Mastera.

Kuba: I to zwłaszcza tak, jak o tym opowiadasz, to taki Product Owner rozumiany o wiele szerzej niż osoba, która zajmuje się Backlogiem i „Scrum Guide” to tak opisuje, ale też patrząc z perspektywy takiej biznesowej, no to taki Product Owner, bardziej Product Manager, osoba naprawdę autentycznie odpowiedzialna za cały produkt end-to-end, wszystkie jego aspekty – no to to może być tak, że ta rola Product Ownera to nie jest tylko praca z Zespołem Scrumowym, ale to jest też po prostu opieka nad pewnym produktem i to będzie się wymykało poszczególnym zapisom z „Przewodnika po Scrumie”, ale po prostu nikt inny lepiej niż Product Owner tego nie zrobi i wtedy ta rola Scrum Mastera jest – w przypadku tak łączonej osoby – ta rola Scrum Mastera jest tylko i wyłącznie sprowadzona do obecności na spotkaniach, być może prowadzeniu tego spotkania, ale kompletnie nie przypomina to roli Scrum Mastera.

Drugi minus, o jakim pomyśleliśmy – też dla nas bardzo istotny – to jeśli nie mamy oddzielonego od siebie Product Ownera i Scrum Mastera, to po prostu ta pojedyncza osoba, która te dwie role łączy w sobie, nie ma drugiej pary oczu, nie ma skrzydłowego, na którego może liczyć – czy to poprzez podzielenie się jakoś obowiązkami w ramach współpracy na spotkaniach czy na warsztatach czy też w pracy z interesariuszami – wszystkie te rzeczy bardzo dogłębnie poruszyliśmy w odcinku jedenastym, na temat tego, jak Scrum Master może współpracować z Product Ownerem, więc tutaj nie chcemy tego powtarzać, ale na pewno jest masa rzeczy, które w takiej fajnie współpracującej parze mogą robić Product Owner i Scrum Master, no a jeśli jest to pojedyncza osoba, to kompletnie gubimy okazje czy korzyści z takiej współpracy.

Jacek: Pewnym minusem jest też to, że zarówno Scrum Master, jak i Product Owner – co do zasady – tak na bardzo wysokim poziomie mają jednak różną optykę pracy. W dużym uproszczeniu – Product Owner, chcielibyśmy, żeby skupił się na maksymalizacji wartości produktu i podejmował słuszne decyzje produktowe, natomiast, co do zasady, Scrum Master, jest bliżej samego procesu i dbania o to, żeby wykorzystanie Scruma czy zwinności w organizacji, no, przebiegało po prostu w sposób sensowny. No, stąd te dwie perspektywy, znów, one są bardzo czasochłonne. Z drugiej strony łączenie roli może powodować, że, przykładowo, Product Owner może nie mieć nikogo, kto go zastopuje w jakichś tam dążeniach, żeby np. dopchnąć kolanem zakres Sprintu czy przydusić zespół, przymusić do czegoś, tak więc takie zdrowe spojrzenie kogoś z boku też na to, żeby… jeśli umówiliśmy się na pracę w Scrumie, no to żeby to była praca w Scrumie, a nie w jakimś dziwnym tworze, który tak naprawdę nie wiadomo do czego ma doprowadzić – jest wartościowa i jest pomocna.

Kuba: No, odwracając też tą sytuację przez przykład scrummasterski, no to znam Scrum Masterów, którzy trochę za bardzo się przechylają na tą stronę, żeby było dobrze w zespole, żeby fajny proces, żeby to wszystko fajnie funkcjonowało – i w tej całej „fajności” gdzieś tam gubimy np. to, żeby jednak jak najwyższa wartość biznesowa była dostarczana przez zespół – i tutaj obie strony mogą się wzajemnie balansować, a może nawet tak w brzegowych przypadkach po prostu do pionu z powrotem sprowadzać, że: „Słuchajcie, ale jednak dostarczajmy wartość”, „Słuchajcie, ale jednak róbmy to sensownym procesem”. Scrum Master jest managerem procesu, Product Owner managerem produktu, wartości biznesowej z tego wynikającej, no i to są rzeczy, które mogą od czasu do czasu być ze sobą w sprzeczności.

To przejdźmy do plusów, bo tutaj nie ma co kryć, że przez chwilę się zastanowiliśmy, czy tu w ogóle jest jakakolwiek symetria czy te role w ogóle mają sens jako role łączone – długo ich szukaliśmy, ale jest taka perspektywa, o której czasami słyszę czy czasem nawet ją widzę u niektórych Product Ownerów, że jest jednak korzyść w tym, żeby mieć kompletną odpowiedzialność za zespół, zgrupowanej w jednej osobie. Być może nazwalibyśmy to nawet taką korzyścią z dyktatury, ale faktycznie taki turbo Product Ownero/Scrum Master, taki samodzielny lider zespołu po prostu jest w pełni odpowiedzialny za to, co robi – to on decyduje, jakie decyzje podejmuje, nikt się tu nie wtrąca, nikt nie zadaje głupich coachingowych pytań, nikt mnie nie stopuje – po prostu jak odpowiadam za rezultaty w produkcie, to też mam pełną władzę nad zespołem. I to nie wiem czy wystarczająco obiektywnie to mówię, bo być może przemawia przeze mnie lekka ironia, ale znam osoby, które wprost mówią, że jednak potrzebowałyby takiej kompletnej władzy, żeby móc też całkowicie odpowiadać za to, co później w tym produkcie się dzieje.

Jakiś komentarz może z twojej strony?

Jacek: No to tak, jak powiedziałeś, długo szukaliśmy plusów i ja też sobie wyobrażam sytuację – tak mając przed oczami różne kombinacje zespołów, różne setupy i też jakieś takie też zdrowe podejście do tego, że ktoś może się tylko inspirować pewnymi pojęciami, no to wyobrażam sobie, że taki… ja bym to powiedział, taki „lider”, który ciągnie zespół na wielu płaszczyznach, zależy mu, chce, żeby spotkania były efektywne, ale też zależy mu, żeby zespół się usprawniał, jednocześnie jest dobry produktowo, może często nawet nieświadomie łączyć te role. W sensie: znam paru PM-ów, którzy lepiej lub gorzej wchodzili w taki setup, gdzie i trochę odpowiadali bardziej za produkt, niż tak klasycznie jako Project Manager, no a jednocześnie zależało im autentycznie na tym, żeby zespół też czuł się dobrze i żeby pracował efektywnie, no więc też, bardziej świadomie lub mniej wchodzi w pewne jakieś takie role czy używali pewnych narzędzi scrummasterskich, tak więc ta dyktatura no to… dla kogoś to może być taki piękny sen, że: „Ooo, tu jest jakaś szansa, żeby te dwie rzeczy połączyć” – no, raczej… to tak nazwaliśmy roboczo i chyba tak bym po prostu do tego podszedł, z pewnym takim przymrużeniem oka, no ale też nie chcieliśmy być ślepi na to, że czasem po prostu takie konfiguracje spotykamy.

Kuba: I powiedziałeś ważne stwierdzenie: czasem jest to nieświadome. My, analizując te kombinacje możliwych łączeń ról, zidentyfikowaliśmy sobie dwa różne możliwe przypadki łączenia roli Product Ownera i Sccrum Mastera. Jeden to przypadek taki przykładowo na starcie zespołu – zespół wybiera sobie Scrum Mastera, jakoś tak dochodzi do tego, że świadomie stwierdzają: „To niech Product Owner będzie naszym Scrum Masterem”. Intuicja wielu startujących zespołów taka właśnie jest, czy w tą stronę idzie, niezależnie od tego, że w „Scrum Guidzie” jest to mocno nierekomendowane połączenie, no to tak… jest ochota, żeby może dać też… zespół daje tą rolę Scrum Mastera Product Ownerowi, ale sporym zagrożeniem takiego łączenia jest też coś, co w praktyce spotykamy w zespołach, które może nie stosują Scruma rozumianego literalnie jako metodę, ale bardzo mocno się tym Scrumem inspirują – Scruma, w którym nie istnieje Scrum Master, jest tylko rola Product Ownera (jakoś nazwana, bo to jest Product Owner, Product Manager, może jakiś lider zespołu czy Kierownik Projektu) – i ta osoba pełni rolę Product Ownera i jednocześnie skoro mocno inspirują się Scrumem, to ktoś też np. musi prowadzić spotkania, ktoś odpowiada za proces, ktoś się po prostu do tego poczuwa i jakoś tak się nieświadomie dzieje, że tą rolę również czy te elementy czy szczątkowe fragmenty roli Scrum Mastera bierze również na siebie Product Owner. Więc to jest nie tylko przestroga przed tym, żeby patrzeć na to, czy ktoś formalnie jest Scrum Masterem i Product Ownerem w jednej osobie, ale też te przypadki, gdy ktoś jest Product Ownerem i nieświadomie bierze się na siebie elementy roli Scrum Mastera.

Jacek: Ostatnia kombinacja, którą chcemy przedstawić, to jest kombinacja Product Owner łączy rolę Product Ownera z byciem członkiem Zespołu Developerskiego – i tutaj generalnie bardzo wiele, w szczególności minusów, jest takich samych, jak dla tego kejsu, gdzie Scrum Master łączy się z rolą developera, natomiast taki dodatkowy minus z perspektywy łączenia roli PO i członka Teamu Developerskiego jest to, że trudno być może będzie pełnić rolę wymagającego Product Ownera dla zespołu, gdy sami jesteśmy częścią Zespołu Developerskiego. Wtedy bardziej wchodzimy w szczegóły – wydaje mi się, że to jest też kwestia trochę większej empatii, też pewnie takiego dopowiadania sobie, dlaczego pewne rzeczy nie zaszły, dlaczego pewne rzeczy się nie wydarzyły, no i taki brak, bym powiedział, takiej „suchej” oceny pozbawionej emocji, może powodować, że tą rolę po prostu będziemy pełnić mniej skutecznie.

Kuba: I to tak może źle zabrzmieć, jeśli mówimy tutaj o wymagającej roli, ale jednak są takie momenty, gdy to Product Owner może być trochę bardziej surowy, może jednak oczekiwać większej wartości – również od siebie, ale również od zespołu. Na przykład również reprezentować jednak tą perspektywę klienta czy biznesu, gdy zespół nie realizuje Celu Sprintu, gdy jest czas na trudną rozmowę na Retrospektywie, „Dlaczego tak się dzieje i że moglibyśmy się ogarnąć”. I oczywiście trochę trudniej wtedy jest, żebyśmy my wszyscy się ogarnęli, jeśli Product Owner też czuje, że w środku Sprintu wykonywał jakieś zadania i sam również w jakiś sposób tam zawiódł. Więc w praktyce czasami widzę, że takiemu wykonującemu zadania Product Ownerowi trochę łatwiej przychodzi wybaczanie, a trochę trudniej jest być takim, bym powiedział, surowym czy bardzo asertywnym, że jednak tutaj trzeba się wznieść trochę ponad samego siebie i skrytykować również czy może wymagać więcej od samego siebie.

Jacek: I ja chyba nawet tu bym się zatrzymał na chwilę i też powiedział też takim tekstem wprost, że dla mnie to jest absolutnie okej, że Product Owner jest wymagający w stosunku do zespołu, jednocześnie jest dla mnie okej, że Zespół Developerski jest wymagający w stosunku do Scrum Mastera i Product Ownera i że Scrum Master jest wymagający w stosunku do i PO i Zespołu Developerskiego. Jeżeli to jest wszystko w zdrowych ramach, na zasadzie jakiegoś kontraktu, umówienia się, że pewnej bylejakości nie akceptujemy, no to z mojej perspektywy jeśli to jest zdrowo dogadane, no to efekt może być tylko pozytywny. W sensie: mamy wobec siebie wysokie wymagania, robimy w wysokim standardzie i to po prostu ma jakąś tam określoną jakość, która dla wszystkich jest okej.

Kuba: No, bardzo ważne zastrzeżenie. Jest pewien dodatkowy plus pełnienia roli Product Ownera i jednocześnie bycia członkiem Zespołu Developerskiego w pewnych specyficznych przypadkach, których w sumie – jak wyliczaliśmy sobie z Jackiem – to w naszej karierze spotkaliśmy już całkiem sporo. Często jest tak, że Product Owner ma pewną konkretną kompetencję, np. jest prawnikiem, marketingowcem, zna się na procesie produkcji – to wszystko powoduje, że też po prostu wnosi do zespołu konkretną kompetencję, którą może wykorzystać zespół w środku Sprintu. To jest albo uczestnictwo i wykonanie jakiejś pracy na jakichś warsztatach, ale też po prostu wzięcie jakiegoś zadania ze Sprint Backlogu i zrealizowanie go, dzięki czemu cały zespół po prostu jest w stanie przerobić trochę więcej. I to jest plus z perspektywy zespołu, ale też często sami Product Ownerzy, którzy biorą na siebie takie zadania, po prostu czują, że mogą po prostu pomóc, mogą to zrobić dobrze, mogą pomóc zespołowi wykonać jakieś zadanie, które być może nikt inny w zespole nie umie zrobić lub nie umie zrobić tego na tym poziomie merytorycznym

I ostatni taki punkt… nazwaliśmy go trochę „plusominus”, bo to jakby na dwoje babka wróżyła – często Product Ownerzy (bardzo sąsiednio do tego, co powiedziałem) często są bardzo zaangażowani, bardzo chcą pomagać, bardzo chcą się przyczynić do tego, że cały zespół zrealizuje jakiś cel czy zrealizuje całe jakieś większe przedsięwzięcie, no i z tego powodu angażują się nie tylko w rolę Product Ownera, ale też angażują się w rolę członka zespołu. Jaki to może mieć minus? No bo powiedziałem, że „plusominus”?

Jacek: No, jeżeli angażuje się w jakieś tam zadania, no to z mojej perspektywy jest duża szansa, że nie zrobi jakichś tam tematów ważniejszych dla zespołu niż to konkretne zadanie, czyli np. nie porozmawia z jakimiś stakeholderami, którzy są wysoko w hierarchii, no i w sumie tylko ta osoba mogłaby to zrobić, bo np. członkowie Zespołu Developerskiego nie czują, że mają relacje albo czasem wręcz tak strukturalnie się obawiają porozmawiać z kimś z poziomu czy dwa poziomy wyżej. No i… teraz, jak to położymy na szalę, to może się okazać, że to nieporozmawianie ze stakeholderem przyniesie więcej negatywnych skutków niż niezrobienie jakiegoś tam jednego pojedynczego zadania czy jakiejś pracy wynikającej z Backlogu Produktu, tak więc ten aspekt wydaje mi się taki jest tutaj najbardziej ryzykowny.

Kuba: No, tak inaczej to ujmując – za Product Ownera nikt inny nie zrobi tych pojedynczych zadań, a jest duża szansa, że te zadania w zespole po prostu zespół musi tak się zorganizować, żeby wziąć na siebie, czyli pojedyncze zadania są zastępowalne i zespół może je ogarnąć, ale pojedynczych zadań Product Ownera możliwe że już nikt inny za tą osobę nie zrobi.

Jacek: To zanim przejdziemy do takiego punktu, co można z tym zrobić w praktyce, to tak może jakbyśmy mieli, Kuba, podsumować. Jak ciebie ktoś się pyta, czy łączyć role, to jaka jest Twoja odpowiedź?

Kuba: To nie jest takie oczywiste, jakby… wyleczyłem się z takiego kategorycznego mówienia: „Nie, nie łączyć w ogóle”, natomiast bardzo mocno drążę, z czego wynika, że to łączenie ról miałoby mieć miejsce, czyli zrozumienie tych plusów i minusów i tej perspektywy osoby, która chce role łączyć i też jednak sugeruję, że są powody, dla którego zwłaszcza konkretnie w Scrumie te role są tak wyróżnione, te role są konkretnie nazwane i w dużej większości przypadków, które spotykałem, też którym asystowałem w trakcie ich pracy, jednak wychodzi to, że te role nie powinny być łączone, więc trochę przydługie, ale na pewno nie jestem fanem jakiegoś takiego kategorycznego TAK albo kategorycznego NIE, raczej doszedłem do tego, że pewne rzeczy wychodzą z czasem, ale w większości przypadków mi te role się nie łączą, w większości przypadków w dłuższym okresie raczej dochodzi do tego, że zwłaszcza rola Product Ownera i Scrum Mastera – jest specjalizowana osobno, traktowana jako właśnie, jak to powiedziałeś, staropolsko: full-time job, no i w tym trzeba się specjalizować, w tym trzeba się rozwijać, no i też jest co robić w tych rolach.

Jacek: No, z mojej perspektywy, jakbym miał to też tak jednym z daniem podsumować, to kiedy słyszę o łączeniu ról, to zapala mi się lampa pomarańczowa – co najmniej pomarańczowa – czyli wiem, że to może rodzić potencjalne ryzyka, natomiast z drugiej strony rzeczywistość, praktyka, to, co widzę dookoła, pokazuje, że czasem też nie mamy… czy ta osoba, która de facto tę rolę pełni, nie ma wpływu na to, żeby było inaczej, więc można w jakimś tam stopniu próbować te potencjalne ryzyka czy zagrożenia minimalizować, żeby po prostu w tych pewnych realiach, na które nie mamy wpływu, no, zrobić to połączenie najlepiej jak można, jeśli już musimy je robić.

Kuba: I to jest bardzo ważne zastrzeżenie, ono się świetnie wymyka takiej perspektywy czystej teorii, perspektywy pojedynczego Zespołu Scrumowego, że często problem łączenia ról nie jest jakąś prywatną decyzją czy pojedynczą decyzją pojedynczej osoby, że jeśli rozpatrujemy taki przypadek łączenia ról, gdy już on faktycznie ma miejsce w konkretnej firmie, do której np. my trafiamy czy my szkolimy w takiej firmie, no to to jest bardziej złożony problem, on często wynika z tego, jaką perspektywę ma manager, który ma swoją wizję na zespół. I jeśli manager podjął decyzję, że rola Product Ownera i Scrum Mastera będzie łączona w jednej osobie, to możliwe, że problem już jest zamknięty.

Jakie jeszcze mogą być przyczyny, że ta rola jest łączona?

Jacek: No, bardzo często to jest kwestia budżetu, czyli po prostu albo firmy nie stać na dodatkową osobną rolę, albo nie widzi na ten moment wartości z tego, żeby płacić za tą konkretną rolę, a w szczególności perspektywy np. pracy w Software Housie, no to może być tak, że w setupie, w którym to klient płaci za cały zespół, to może być sytuacja, w której klient nie zgodzi się na opłacanie np. oddzielnej roli jakiegoś tam Proxy Product Ownera czy oddzielnej roli Scrum Mastera, no i może użyć argumentu, że gdyby miał PM-a (Project Managera), to miałby to w jednej osobie, więc czasem tym takim czymś, co determinuje, że te role się łączą, jest po prostu brak budżetu.

Kuba: Ten brak budżetu może też wynikać z tego, że ktoś po prostu nie rozumie istotności roli. No, tutaj nam się najmocniej nasuwa właśnie konkretnie niezrozumienie roli Scrum Mastera. No, jeśli ktoś nie rozumie roli Scrum Mastera, to też może nie zrozumieć, dlaczego powinien za to zapłacić albo powinien na to dedykować konkretną osobę.

Jacek: No i w sumie jakby, no, rozumiem to podejście w jakimś sensie.

No i taki myślę jeszcze ostatni powód, dla którego te role być może się łączą, to też jest jakieś złe doświadczenia z przeszłości. No i tu znów w szczególności moje doświadczenia są takie, że spotykam organizacje, w których wcześniejsza współpraca z niedoskonałym Scrum Masterem powoduje, że ta furtka już jest zamknięta i ktoś mnie przekonuje, że: „Ale my już mieliśmy Scrum Masterów, to nie zadziałało”, czy tam „Mieliśmy Scrum Mastera, to nie była udana współpraca, nie wyszło”, no i… czasem moje argumenty, że to po prostu może był pech, a może takie zwykłe ludzkie niedopasowanie, no bo mam masę przykładów świetnej pracy wykonanej przez Scrum Masterów, po prostu „nie siada”, ktoś stracił zaufanie, ktoś nie widzi tego, może ma w ogóle inny pomysł na to, jak to poukładać, no i po prostu albo tej roli nie ma, albo właśnie jest jakoś tak dołączona tylko na zasadzie połączenia, dołączenia i nie ma dedykowanej osoby.

Kuba: Dobra, dość narzekania. Co możemy z tym zrobić? W zależności od tego, gdzie leży ta przyczyna, z której to łączenie ról mamy i chcielibyśmy coś z tym zrobić, czyli przyjmujemy założenie, że co najmniej jednej osobie to nie pasuje albo może my wiemy, że – czy jesteśmy wystarczająco przekonani tym odcinkiem – chcemy coś z tym zrobić. Co możemy jako zespół zrobić, żeby usprawnić tą sytuację, rozwiązać problem łączenia ról w Scrumie?

Jacek: Jasne. No, skoro jesteśmy w Scrumie, to skorzystajmy z czegoś, co dostajemy w pudełka – mamy instytucję Retrospektywy Sprintu, no i jest to miejsce, na którym można ten temat poruszyć, można ten temat „wyjąć na stół”, no i zastanowić się, co z tego wynika, że te role łączymy – ocenić to, spojrzeć na to z różnych perspektyw, po prostu poddać pod dyskusję ten aspekt, nazwijmy to, takiej naszej pracy procesowej, jakim są ustalone role, no i też zastanowić się, czy one są wypełniane czy nie są wypełniane, albo jakich problemów doświadczamy przez to, że te role są łączone. Zwykle zespoły są w stanie bardzo trafnie, precyzyjnie przywoływać przykłady, kiedy np. osoba będąca w roli Product Ownera i członka Zespołu Developerskiego zbyt mocno zanurzyła się w zadania developerskie, przez co jakiś tam aspekt produktowy – tak, jak mówiliśmy – którego nikt inny nie był w stanie „zaopiekować”, po prostu przepadł, został przegapiony, no i to prowadzi do jakichś konsekwencji. Tak więc, no, klasyczne Retro, jeżeli nie ma innej okazji, no to co najmniej na tym „bezpieczniku”, czyli Retrospektywie na końcu konkretnego Sprintu.

Kuba: Jeśli łączenie ról to jest bardziej nasza własna decyzja i to taka decyzja na zasadzie: „Mnie się wydaje, że to połączenie jest całkiem w porządku i trochę nie wiem, jak mogłoby to wyglądać inaczej”, to ja najzwyczajniej w świecie namawiam do eksperymentu: „Spróbuj w następnym Sprincie zrobić to inaczej”. Na przykład jestem Scrum Masterem i w najbliższym Sprincie nie wezmę żadnych zadań ze Sprint Backlogu takich czysto developerskich, czy tych moich takich technicznych, którymi zajmowałem się do tej pory i zobaczymy wszyscy, jak będzie. Zobaczy zespół, zobaczy Product Owner, ja sam sprawdzę, jak to będzie, czy będzie mieć co robić, jak będzie wyglądało zachowanie zespołu, czy będę umiał współpracować z Product Ownerem. Jako Product Owner podobnie – mogę nie wziąć zadań z Backlogu, być może zmieńmy osobę w roli Scrum Mastera, jeśli któryś z członków Zespołu Developerskiego czuje, że mógłby dedykować się do tej roli, a ta inna osoba, która obecnie w tej roli łączonej Scrum Mastera siedzi, po prostu nie jest w stanie tego wykonać. Zapewne w każdym zespole znajdzie się jakaś taka konfiguracja eksperymentu – chociaż na jeden Sprint – świadomie powiedziane: „Na jeden Sprint, nie na zawsze, tylko teraz spróbujmy, porównajmy sytuację, zobaczmy, jak to będzie”. To jest popularna ścieżka, z tego, co obserwuję, wychodzenia z roli łączonego Scrum Mastera, czyli takie jakby offloadowanie sobie zadań, odpuszczanie kolejnych zadań i zobaczenie, czy zespół „uciąga” temat, również Product Ownerom coś takiego rekomenduję – jeśli mam jakiś element w Backlogu Sprintu, to może mogę z czegoś zrezygnować.

Jacek: Trzecim takim krokiem wartym rozważenia, jest porozmawianie o wzajemnych oczekiwaniach co do ról – i to jest bardzo prosta technika przeze mnie prywatnie wielokrotnie stosowana, gdzie sobie definiujemy przede wszystkim, jakie są oczekiwania w stosunku do każdej z trzech ról w Scrumie, jako takie ćwiczenie grupowe, umieszczamy to sobie na jakiejś tablicy – w dzisiejszych realiach pewnie bardziej wirtualnej – no i możemy sobie podyskutować, czy te oczekiwania są akceptowalne, są nieakceptowalne i też możemy sobie podjąć taką próbę oceny na jakiejś skali, w jakimś wymiarze – na ile te oczekiwania są na dzisiaj realizowane i być może nawet zakończyć to spotkanie z jakimś takim action planem, co każda z ról wykonuje na dzisiaj dobrze, a co można byłoby wykonywać jeszcze lepiej czy usprawnić. Tak więc taka formuła warsztatowa – przedyskutowanie tematu konkretnie skupiając się na oczekiwaniach co do każdej z ról w Scrumie.

Kuba: I czuję, że muszę dopowiedzieć jedną rzecz. Często to ćwiczenie – bo sam również je mocno rekomenduję i czasami nawet sam moderuję w jakichś kryzysowych sytuacjach – często to ćwiczenie pokazuje jedną rzecz, że np. Product Owner nie spodziewał się, jak dużo się od niego oczekuje tej roli productownerskiej, a za to być może też w ramach poczucia obowiązku czy zaangażowania, brał na siebie zadania, których w sumie – tak jak później wszyscy patrzą – to w ogóle nie oczekują czy nie liczą, czy nawet nie dostrzegają. Podobnie może być ze Scrum Masterem, że Scrum Master w poczuciu obowiązku bierze na siebie zadania developerskie, a np. zespół o wiele bardziej by oczekiwał uporządkowania jakichś impedimentów czy może po prostu dobrego procesu współpracy zespołu. I to często jest ćwiczenie, które otwiera oczy i porządkuje pewne rzeczy, wyprostowuje czy przesuwa do tego, powiedzmy, że „wzorca”.

Następnym punktem czy krokiem wartym rozważenia do tego, żeby wyjść z tej roli łączonej, już ugruntowany bardziej na poziomie całej organizacji czy może managera – czasami jest tak, że to manager nam mówi: „No, słuchaj, oczekuję od ciebie, że będziesz łączyć role”. Warto może zaatakować temat analitycznie – tutaj taki temat dosyć w sumie prosty z perspektywy pojedynczej osoby. Po prostu zanotujmy sobie rzeczy, które robimy, czasy, które na jakieś zadania poświęcamy i pokażmy to managerowi. Masz tutaj szerszy wątek, bo byłeś odbiorcą takiej sytuacji.

Jacek: Tak, byłem w sytuacji, w której byłem managerem zarówno Product Ownerów, jak i Scrum Masterów w jednej z organizacji i w pewnym momencie przyszedł do mnie Product Owner porozmawiać, który też z takiego… z pewnych ograniczeń wynikało to, że jednocześnie też pełni rolę Scrum Mastera i on mi bardzo fajnie przedstawił problem, na takiej zasadzie, że pokazał mi całą długą listę rzeczy, które robi jako Product Owner, pokazał mi całą długą listę rzeczy, które robi jako Scrum Master, a następnie, jakby, „narysował” mi – tak mówiąc metaforycznie – co by było, gdybym pomógł mu zdjąć tą rolę Scrum Mastera i narysował mi całe spektrum różnych bardzo – z perspektywy tamtych czasów – interesujących aktywności z klientem, które mógłby wykonać, gdyby po prostu miał na to czas. On tego czasu nie miał, bo praca Scrum Mastera zabiera mu ten cenny czas, no i to było dla mnie takie bardzo wartościowe ćwiczenie, które mi pokazało, co tracę, a co zyskuję – z jednej strony: super, że mam Scrum Mastera 2w1, natomiast z drugiej strony – minus tej sytuacji też był bardzo mocno wyraźny. I tak jak – co do zasady – to łączenie dla mnie, no, ma więcej ryzyk niż plusów, tak tutaj w szczególności doświadczyłem takiego bardzo fajnego – takiego, tak jak tutaj mówimy, takiego „liczbowego”, dobrze przygotowanego zestawienia, które po prostu jasno pokazywało i pomagało podjąć decyzję, czy to jest wystarczające, żeby to zmienić czy jest jak jest, ale na dzisiaj np. nie mamy na to wpływu, bo np. nie mam budżetu, żeby taką dodatkową rolę sprowadzić. Niemniej, takie podejście bazujące na faktach i też pokazujące, „co by było gdyby”, to myślę też była fajna część tego ćwiczenia. Była bardzo wartościowa.

Kuba: I ostatnim krokiem, który czujemy, że możemy podpowiedzieć, chociaż on już będzie najmniej konkretny to to, że często ten temat łączenia ról, to jest po prostu bardzo mocny przykład na impedimnet organizacyjny, czyli jakąś przeszkodę, blokadę, jakąś niedoskonałość organizacji, której nie załatwi się po prostu jedną rozmową, jednym strzałem, jedną przekonywającą historią, tylko to jest coś, o co po prostu cały program wsparciowy, eksperymentalny czy taki po prostu polityczny trzeba zrealizować. I to zdecydowanie jest dobry przykład na test na Scrum Mastera. Tak trochę powiem przewrotnie, ale bardzo szanuję i bardzo cenię sobie tych Scrum Masterów, którzy sobie wywalczyli tą etatowość swojej roli jako Scrum Master. Pokazali na swoich przykładach i sami sobie to, jakby, jeszcze raz to powtórzę: wywalczyli z organizacji, żeby organizacja zaufała i dała tą rolę na full-time, na etat, no i też uzasadnione to jest w takiej sytuacji, że to jest taki przykład na to, jak Scrum Master może zmieniać całą organizację. No, nie ma tutaj niestety gotowych recept, bardziej chcemy pokazać, że to jest możliwe zagadnienie do załatwiania przez Scrum Mastera lub Scrum Masterów, może też przez liderów całej zmiany czy osoby, które pilotują wykorzystanie zwinności w firmie.

I na koniec jeszcze tak bardzo moja porada, zupełnie z innej „parafii”, a propos tego, co można zrobić z łączeniem ról. Bo może jest tak, że akurat w Twoim konkretnym kontekście – to, co mieliśmy zastrzeżenie na samym początku – takie łączenie ról po prostu działa. Łączysz to dobrze, nie ma z tym problemu, jakoś się da z tym żyć, nikt nie zgłasza żadnych zastrzeżeń. Może tak jest, może tak faktycznie to dobrze funkcjonuje – w takim razie nic z tym nie rób, zaakceptuj. To już nie będzie taki Scrum – zwłaszcza jeśli łączyć Product Ownera i Scrum Mastera – tu akurat „Przewodnik po Scrumie” wprost tego nie rekomenduje, ale może to u Ciebie działa.

Jacek: No ja też się zgodzę – tak, jak mi się zapalają lampki, tak po prostu są pewne sytuacje, gdy widzę, jak jakaś osoba bardzo umiejętnie operuje tymi „kapeluszami”, jest bardzo świadoma, dobrze rozumie też co te dwie role, które ma na sobie – niezależnie, jakie to są role – z czym one się łączą, co można robić, czego nie można robić. No i po prostu patrzę z boku na taką osobę, widzę, że radzi sobie wystarczająco dobrze, zespół też jest świadomy tych ograniczeń, no i po prostu idą do przodu, realizują kolejne jakieś tam tematy, „dowożą” produkt itd. No i mnie się lampka świeci, z boku manager jakiś na to patrzy, widzi wartość – też gdzieś tam w środku mnie jest jakaś taka reakcja pod tytułem „zostawmy to”. W sensie: być może, jak byśmy sobie ułożyli listę problemów organizacyjnych, to to nie jest coś, o co warto walczyć. Może są poważniejsze problemy, w stylu, nie wiem, jakieś niezrozumienie, czym jest zwinność albo jakieś kompletnie różne wyobrażenia na ten temat w organizacji, albo nie ma buy-inu po stronie Top Managementu – to są, myślę, grubsze tematy niż to, że książkowo patrząc, ktoś robi coś, co, powiedzmy, nie jest rekomendowane, a może robi to wystarczająco dobrze i faktycznie warto poszukać lepszych obszarów do przyłożenia dłoni niż ten konkretny kejs łączenia ról.

Kuba: Dobrze, to – podsumowując cały odcinek – opowiedzieliśmy trochę o łączeniach ról w Scrumie, o łączeniu roli Scrum Mastera i Development Teamu, o łączeniu roli Product Ownera i Scrum Mastera i Product Ownera i członka Zespołu Developerskiego – i podsunęliśmy kilka możliwych kroków praktycznych, jak można by spróbować z tematem zawalczyć, jeśli faktycznie ma to sens.

Jacek: Jako podsumowanie odcinka chcielibyśmy poprosić Cię, żebyś zastanowił bądź zastanowiła się, komu z Twoich znajomych na social mediach odsłuchanie tego odcinka przyniosłoby wartość. I chcielibyśmy Cię poprosić, żebyś oznaczył bądź oznaczyła te osoby w komentarzu pod odcinkiem na Facebooku, na LinkedInie albo na Twitterze. Dzięki temu pomoże nam to dotrzeć do osób, które do tej pory jeszcze nas nie słuchają.

Kuba: I to by było wszystko na dzisiaj.

Jacek: Dzięki, Kuba. I do usłyszenia…

Kuba: …wkrótce.