Gdy zaczynałyśmy prowadzić bloga popełniłam post o rolach w Scrum Teamie. Dziś, po ostatniej aktualizacji Scrum Guide’a z listopada 2020, post ten również wymaga pewnych zmian. Autorzy Przewodnika, Ken i Jeff, postanowili go przeredagować w ten sposób by jeszcze bardziej wzbudzić poczucie zespołowości w Scrum Teamie. Nazwy ról w historii Scruma przeszły już niejedną zmianę, więc i te nie dziwią, zwłaszcza jeżeli skupimy się na ich celu. Zamiast ról mamy odpowiedzialności, które jasno definiują zakres naszych zadań. Co dzięki temu zyskujemy? Między innymi brak podziału na my – oni i wyróżniana podzespołów. Wciąż jednak podział ten budzi sporo niedomówień. Aby je wyjaśnić prześledzimy wspólnie odpowiedzialności Product Ownera, Developerów i Scrum Mastera i zdemaskujemy popularne antywzorce, które im towarzyszą.
Product Owner
Fakt: Odpowiedzialnością Product Ownera jest szerzenie zrozumiałej wizji i Celu Produktu.
Product Owner jest nazywany maksymalizatorem wartości, bo to za jego sprawą realizowana jest misja Sprintu, czyli przekształcanie pomysłów we wspomnianą wartość. Co się pod tym kryje? Zbieranie, przekazywanie i priorytetyzacja wymagań w taki sposób aby Scrum Team realizował wizję produktu, zgodnie z potrzebami użytkowników i interesariuszy. Odpowiedzialność tą powinna pełnić zawsze jedna osoba, a jej zdanie nie powinno być podważane.
Mit: Product Owner musi rozpisywać Product Backlog
Wiele razy słyszałam “PO nie rozpisuje PBI, nie możemy więc pracować”. Jest to niestety bardzo popularne niezrozumienie odpowiedzialności Product Ownera. Przekazywanie i priorytetyzacja Product Backlogu nie musi się odbywać za pomocą tworzenia i ustalania priorytetów ticketów w Jirze! Wystarczy, że PO w jasny sposób opisze nam co mamy zrobić, czy to słownie czy to pisemnie. Nie musi przy tym tworzyć PBI, a tym bardziej w postaci zadań w Jirze. Brak takiej konieczności nie zwalnia go oczywiście z odpowiedzialności weryfikacji, czy jego słowa zostały dobrze zrozumiane i wdrożone.
Mit: Product Owner nie musi uczestniczyć w Sprint Retrospective
Zapisując ten punkt mam niemały uśmiech na twarzy, a to dlatego, że kiedyś sama często praktykowałam takie podejście. Bo tak było łatwiej. Product Owner był w innej strefie czasowej. Spotkania na odległość i w późnych godzinach nie wydawały mi się zbyt efektywne. Do tego dochodziła bariera językowa, czy niechęć Development Teamu do dzielenia się ich problemami z PO. Czytając to może macie ciarki na plecach, tyle błędów w jednym micie. Ja mam. Mieliśmy wtedy pod-zespół w Scrum Teamie (stąd celowo przywołałam Development Team), brakowało nam zaufania i poczucia zespołowości, czy transparentności nie tyle co w zakresie realizowanych PBI, ale całej pracy. Gdy to sobie uświadomiłam zaczęłam małymi krokami wprowadzać pewne usprawnienia. Dziś już nie wyobrażam sobie Sprint Retrospective bez jakiejkolwiek z odpowiedzialności Scrum Teamu. Każdy z zespołu powinien mieć czas i przestrzeń na przedyskutowanie potencjalnych usprawnień czy celebrowanie wspólnych sukcesów.
Developerzy
Fakt: Developerzy są odpowiedzialni za przekształcanie Product Backlog Itemów w działający Increment
Developerzy powinni posiadać wszelkie potrzebne kompetencje do przekształcenia wizji w działający produkt. To znaczy, że powinni umieć stworzyć ten produkt i zadbać o jego jakość. Elementy Product Backlogu, które znajdują się w Sprincie powinny być realizowane z należytą starannością i z eksperckim podejściem. To Developerzy, po uzgodnieniu Celu Sprintu i zakresu prac do bieżącej iteracji decydują w “jaki” sposób zamienią PBIs w Increment i w jakiej kolejności tego dokonają, by osiągnąć postawiony cel. Co ważne Developerzy nie deklarują się na wykonanie wszystkich zadań w Sprincie, a na osiągnięcie Celu Sprintu i składających się na niego PBIs zgodnie z Definicją Ukończenia.
Mit: Developer nie może być Scrum Masterem
Jedna osoba w Scrum Team może mieć więcej niż jedną odpowiedzialność. Dotyczy to nie tylko Developerów, ale także Scrum Mastera czy Product Ownera. Oznacza to, że Developer może być jednocześnie PO lub SM, i odwrotnie. Jak to może działać w praktyce? To zależy:).
Gdy budujemy mały produkt, i nasz zespół składa się z trzech osób, można by powiedzieć, że wskazane jest by odpowiedzialności były współdzielone. Szalenie ważne jest tutaj niemieszanie kompetencji i odpowiedzialności. Co mam na myśli? Będąc jednocześnie PO i Developerem muszę pamiętać, że jako ten pierwszy jestem odpowiedzialny za przekazanie tego “co” ma być zrobione, a nie “jak” to przekształcić w wartość. Znam przypadki, kiedy to pomieszanie tych dwóch odpowiedzialności, właśnie poprzez zapomnienie o tej regule, nie przynosiło zbyt dobrego skutku. Jako Developer muszę współpracować z innymi Developerami tak, aby sposób jaki wybierzemy do przekształcenia PBI w Increment był jak najefektywniejszy, a nie przekazywać to “co” ma być zrobione.
Mit: Developer jest odpowiedzialny tylko za pisanie kodu
Tutaj znowu uśmiech maluje się na mojej twarzy, a to dlatego, że z tym popularnym mitem przychodzi mi wciąż walczyć na co dzień. “Wypchnąłem moje zmiany, teraz to już Kasia musi to przetestować, ja swoje zrobiłem”. Albo “Nie wiem co mam zrobić, PO nie opisał dobrze tego w zadaniu, to ja dalej nie koduje”. Znacie to? Słowo Developer nie określa programisty, a osobę budującą produkt. W Scrum Team wszyscy jesteśmy odpowiedzialni za wytworzenie działającego Incrementu, wszyscy jesteśmy Developerami. Nie powinniśmy więc przerzucać się odpowiedzialnościami, a działać jako jedność w symbiozie budując wartościowy produkt. Nasza Kasia zachorowała i co teraz? Nikt nie przetestuje zmian? PO nie opisał kryteriów w akceptacji, czy będziemy czekać aż dopisze te kilka punktów? Komunikacja jest kluczem do rozwiązania tych potencjalnych blokerów czy nieporozumień.
Scrum Master
Fakt: Odpowiedzialny jest za szerzenie i zrozumienie przez Scrum Team idei i pryncypiów Scruma
Jak nie Scrum Master to kto? SM powinien być skarbnicą wiedzy o frameworku, znać go od podszewki i reprezentować sobą jego wartości. Jest on odpowiedzialny za to, żeby wszyscy rozumieli “tego Scruma” w ten sam, zgodny z definicją, sposób. Oczywiście nie mam tu na myśli mówienia “na stronie siódmej przewodnika napisane jest, że Daily Scrum trwa 15 minut”, a edukację przez praktyczne i pragmatyczne podejście do tematu. Na skupieniu się na celu zarówno każdego z wydarzeń jak i całej pracy w Scrum i szerzenie tej wiedzy m.in. przez dawanie odpowiedniego przykładu poprzez przestrzeganie i podążanie za wartościami Scrumowymi.
Mit: Scrum Master może pracować tylko z jednym zespołem
Jest to również popularny mit. Scrum Guide nie definiuje z jak wieloma Scrum Teamami powinien współdziałać Scrum Master. Teoretycznie więc może to być jeden lub dziesięć zespołów. W praktyce, to wszystko oczywiście zależy! Jednym z aspektów, które mogą mieć wpływ na to jak bardzo SM jest potrzebny w zespole jest jego dojrzałość. Im zespół dłużej i lepiej zna pryncypia Scruma, tym teoretycznie Scrum Master jest mniej potrzebny. Prawdopodobnie wtedy będzie mógł pracować z dwoma lub trzema zespołami. Z mojego doświadczenia wynika, że najlepsze efekty otrzymują się pracując z jednym, góra dwoma zespołami.
Mit: Scrum Master musi facylitować wydarzenia Scrumowe
Tak, to też jest mit:). Scrum Master może zostać poproszony o prowadzenie czy facylitację wydarzeń Scrumowych, nie jest to jednak jego odpowiedzialnością. Już widzę wasze zdziwienie na twarzy. Jak to? To kto prowadzi Sprint Retrospective jak nie ma SM? Zespół:). Ideą małych Scrum Teamów jest efektywna komunikacja, jeżeli nie potrafią nie dogadać w sprawie facylitacji spotkania, to może czas pomyśleć o przeorganizowaniu zespołów na mniejsze? Sprint Retrospective może być facylitowane przez każdego członka zespołu.
Podsumowanie
Faktów i mitów na temat pracy w Scrum jest cała masa. W powyższym zestawieniu skupiłam się tylko na tych związanych z odpowiedzialnościami w Scrum Team, chcąc pokazać z czym warto się nie zgadzać i walczyć na co dzień. Jeżeli jesteś Developerem, pamiętaj, że nie samym kodowaniem człowiek żyje. Jeżeli jesteś Scrum Masterem, pamiętaj jak Cię widzą tak rysuje się im obraz Scruma, świeć więc przykładem. Nie próbuj też wspomagać dziesięciu zespołów, jeden czy dwa to dobra liczba. I nie, nie jest to związane z Twoim większym lub mniejszym doświadczeniem. Jeżeli natomiast jesteś Product Ownerem to wiedz, że nie musisz rozpisywać każdego PBI, ale za to koniecznie musisz aktywnie uczestniczyć w Sprint Retrospective. Mimo podziału na odpowiedzialności wspólnie jako zespół jesteśmy zobligowani za tworzenie wartościowego Incrementu.
Sprawdź nasze poprzednie wpisy:
