Daily to kluczowy element pracy w Scrumie. Wydarzenie służy zaplanowaniu pracy Zespołu Deweloperskiego, na najbliższe 24h. Jak w to wpisuje się rola Product Ownera?
Są dwa główne scenariusze, które mogą się zrealizować w wyniku udziału Product Ownera na Daily. Najpierw jednak poznaj zespół “Żółte Kaczuszki”. Właśnie realizują spory projekt utworzenia serii Landing Page’ów, promujących markę, SEO-friendly itd. Michał to ich nowy Product Owner i zastanawia się, czy brać udział w Daily. Ma mętlik w głowie. W poprzedniej pracy nie brał udziału w tym wydarzeniu, bo to było “spotkanie tylko dla programistów” i nie mógł, mimo że czuł, iż się może przydać.
Zanim się zdecydujecie na rozwiązanie, warto poznać te dwa scenariusze. To modele, może być ich tyle, ile Zespołów na świecie, ale na bazie tych dwóch można wyobrazić sobie potencjalne korzyści i pułapki.
Scenariusz nr 1 – Product Owner chce ‘zarządzać’
Daily rozpoczyna się pozornie tak jak w wielu innych zespołach – deweloperzy odpowiadają na zestaw trzech pytań, synchronizują się itd. Jednak przy kolejnym z deweloperów, Michał zaczyna wywierać presję: “Dlaczego to tyle trwa? Dział sprzedaży potrzebuje tego na wczoraj ”. Następnie rzuca “Jacek, zostaw tę historyjkę, Małgosia ją za Ciebie przejmie, bo szybciej to zrealizuje, a Ty weź tę”. Na koniec wciska swoje “nie traćmy czasu na refaktoring, testy też są mało istotne, to przecież prosta rzecz”.
Co tu widzimy? Product Owner próbuje wywierać presję na zespole i nim zarządzać. Układa Zespołowi pracę – kolejność oraz metody. A przecież to deweloperzy najlepiej wiedzą, jak przekształcić historyjkę w działającą funkcjonalność. Mamy tu do czynienia z PO, który nie rozumie swojej roli i rozkładu odpowiedzialności. Fajnie, że chce się angażować, ale jednak nie może robić tego w taki sposób.
Wiele Zespołów unika udziału PO na Daily właśnie dlatego, że obawiają się ingerowania w sposób pracy itp. Boją się też pokazać problemy, blokery, słabości – nie wiedzą, jaka będzie reakcja, do czego doprowadzi. Chcą być niezależni w ramach Sprintów, bo wiedzą, że są fachowcami w swojej dziedzinie i skoro na Planowaniu umówili się na dowiezienie jakiegoś zestawu historyjek, to będą wiedzieli, jak to zrobić. Tymczasem presja powoduje, że się zamykają, szybko raportują, aby mieć to z głowy, a rzeczywista synchronizacja odbywa się po Daily 🤔 Na pewno nie jest to atmosfera sprzyjająca zaufaniu i transparentności.
Ja się pytam: gdzie jest Scrum Master?
Częścią Zespołu Scrumowego jest Scrum Master. Co powinien zrobić w takiej sytuacji? Pokazać / opowiedzieć, jak może wyglądać dobre Daily, całemu Zespołowi Scrumowemu. Jeśli rzecz się nie zmieni, to wyprosić Produt Ownera.
Daily służy przede wszystkim Deweloperom, a nie Product Ownerowi. Uczestnictwo PO w tym wydarzeniu to dobra praktyka, ale ma być nakierowana na pomoc Zespołowi w realizacji celu wydarzenia, a nie na zarządzanie.
Ogarnięcie tego to robota dla Scrum Mastera.
Scenariusz nr 2 – Product Owner chce pomóc
Michał usiadł sobie nieco z boku i uważnie słuchał. Udało mu się usłyszeć, że Jacek nie może skończyć historyjki, bo “zapomnieliśmy o jednym widoku” i nie wie do końca, jak mógłby wyglądać ten widok, a poza tym i tak “potrzebne są mu pliki .svg z ikonami, które miała dostarczyć agencja zewnętrzna”. Michał zadeklarował, że wyciągnie od agencji potrzebne pliki w ciągu 4 godzin.
Małgosia natomiast zauważyła podczas realizacji zadania, że jego cel może zostać osiągnięty nieco prostszym sposobem, ale oznaczałoby to delikatną zmianę kryteriów akceptacyjnych – Michał szybko się na to zgodził. Na koniec Daily, PO dorzucił, że “marketing rusza dzisiaj o 11 z zapowiadaną kampanią reklamową usługi X, do której przygotowaliście ostatnio landing page z testami A/B, zobaczymy, jak one zagrają”.
Ten scenariusz wygląda już zdecydowanie lepiej, prawda? Widać w nim współpracę i chęć ciśnięcia tematów do przodu. W ciągu 15 minut Zespół ogarnął sobie plan i zaadresował problemy.
A co na to Scrum Guide?
Zawsze gdy pada pytanie w stylu “Jak to należy robić w Scrumie?” można zerknąć do naszego Przewodnika. Scrum Guide nam podpowiada, m.in. że:
“The Daily Scrum is a 15-minute time-boxed event for the Development Team.The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours.”
Ponadto:
“The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.”
Powyższe cytaty pochodzą z aktualnej, w dniu pisania, wersji tekstu. W poprzedniej wersji nie było tego drugiego fragmentu, był inny:
“The Scrum Master enforces the rule that only Development Team members participate in The Daily Scrum.”
Niektórzy odczytywali go jako zakaz wchodzenia PO na Daily. Jednak czynny udział (ang. “participate”) to coś innego niż samo uczęszczanie (ang. “attend”) – wydaje mi się, że nawet na testach certyfikacyjnych Scrum.org, było to rozróżnione i jedna z odpowiedzi wymagała zrozumienia tego rozróżnienia. Schwaber i Sutherland postanowili chyba tę kwestię wyjaśnić – zapewne ze względu na coraz powszechniejszą praktykę udziału Właścicieli Produktów w Codziennym Scrumie, która przynosi wielu zespołom dużo wartości. Zatem z najnowszego tekstu Scrum Guide’a nie powinny wynikać już żadne wątpliwości – PO może brać udział w Daily.
Product Owner na Daily – tak, tak, tak
Jestem zdania, że to dobra praktyka, gdy Product Owner przychodzi na Daily. Widzę z tego bardzo dużo korzyści:
- Deweloperzy mogą poprosić o szybką odpowiedź i błyskawicznie ją uwzględnić w swoim planie na daną historyjkę
- PO osłuchuje się ze słownictwem i z czasem rozumie coraz więcej aspektów technicznych, co daje mu jeszcze większe możliwości komunikacyjne na przyszłość
- PO, widząc problemy w realizacji Celu Sprintu, może łatwiej przygotować się do komunikacji z interesariuszami (np. będą opóźnienia, trzeba przełożyć kampanię)
- kolejne relacje, kolejne wymiany słów i czas spędzany razem, sprzyjają nawiązywaniu więzi i PO może pokazać, że też jest integralną częścią zespołu i mu zależy na osiąganiu celu itd.
Oczywiście powyższe zakłada, że zespół jest otwarty, a przede wszystkim PO rozumie, w jaki sposób może pozytywnie przyczynić się do pracy w Sprincie. Gdyby próbował zarządzać, to skłaniałbym się ku opcji “Daily tylko dla Deweloperów”. Po wcześniejszych próbach edukacji i pchania w pozytywną stronę.
Product Owner to integralna część Zespołu Scrumowego. Jego pozytywny wkład w Daily, pomoże działać Zespołowi rzeczywiście jak jeden organizm.
✍️ O poprawność językową zadbała Edytornia.pl
Wykorzystane grafiki: Giphy, Rawpixel oraz Freepik
6 odpowiedzi na “Product Owner na Daily? Tak, tak, tak!”
hej Anna, przede wszystkim, dziękuję, że poświęciłaś tyle czasu, aby napisać te komentarze. To dla mnie bardzo wartościowe!
Tak jak zauważyłaś, w aktualnym Scrum Guide napisano: „The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.” Disrupt oznacza przeszkadzanie, zakłócanie. Nie oznacza zatem, że nikt, oprócz deweloperów, się nie może odezwać i ma siedzieć cicho w kąciku, jak to zasugerowałaś. Oznacza, że ma nie zakłócać wewnętrznego spotkania Deweloperów. Jaki byłby w ogóle sens przyjścia na takie wydarzenie kogokolwiek jeśli nic nie może powiedzieć? W Twoich odpowiedziach wyczytuję, że skupiasz się na negatywnych konsekwencjach udziału PO w Daily. Zgodzę się, że zagrożenia istnieją i o tym napisałem. Ale co jeśli jednak proponowane przeze mnie podejście zadziała i poprawi pracę? Czy podana przeze mnie scenka nie pokazuje, że może być to OK?
Zwróć proszę także uwagę na fakt, że przy okazji publikowania nowego Scrum Guidea, Jeff zaznaczał, że są zespoły, które robiły to wcześniej inaczej niż „zalecane w starej wersji przewodnika” i robiły to z sukcesem. Chodzi o to, że sam Scrum Guide się zmienia, zgodnie z praktykami zespołów na całym świecie (inspect & adapt). Jest cała masa sposobów na dobre daily, a wg mnie istotne jest czy dany sposób po prostu działa. Ciągle widzę jak PO potrafi pomóc deweloperom, więc wspieram takie praktyki. Gdy PO rozwala Daily to go wypraszam. Zamykanie się na nowe rozwiązania nie jest dobre. Uczono mnie, że w agile chodzi m.in. o empiryzm i sprawdzanie różnych sposobów. Jeśli na koniec dnia sprowadza się to do „robisz to niezgodnie z zasadami, nie nazywaj tego Scrumem” to nie mam z tym problemu :)
I jeszcze co do egzaminów certyfikujących: „wydaje mi się, że nawet na testach certyfikacyjnych Scrum.org, było to rozróżnione i jedna z odpowiedzi wymagała zrozumienia tego rozróżnienia.” – wręcz przeciwnie, zarówno PSM1, jak i PSM2 oraz PSM3 nastawione są na wybranie odpowiedzi, że optymalna sytuacja to taka, kiedy PO nie ma. O ile przy PSM1 i PSM2 należy zaznaczyć to w teście wyboru, o tyle na PSM3 jest wręcz pytanie o zagrożenia wynikające z obecności PO na Daily, na zasadzie – w jaki sposób Scrum Master może pracować z zespołem i PO, żeby wytłumaczyć im, że PO na Daily nie jest najlepszym pomysłem.
Osobiście spotkałam się z pytaniem:
The Scrum Master realizes that Product Owner attends all Daily Scrums and asks Team Members about their tasks and gives them directions for the following day. What should the Scrum Master do?
A. It’s wrong, the Product Owner should not attend Daily Scrum
B. It’s wrong, the Product Owner should not speak in Daily Scrum
C. It’s OK, the Product Owner can do this
D. It’s OK, it’s recommended for the Product Owner to give direction,
natomiast jest to pytanie pojawiające się w różnych podręcznikach i kursach, nieprzygotowywanych / niezatwierdzanych przez Scrum.org. Na egzaminie (żadnym spośród Scrum.orgowych) takiego pytania nie ma.
I może jeszcze tylko odniesienie do Scrum Guide’a.
Wersja obowiązująca do listopada 2017 zawierała zapis: „The Scrum Master enforces the rule that ONLY Development Team members participate in the Daily Scrum.” – co zdecydowanie wyklucza udział PO czy kogokolwiek innego. W listopadzie 2017 zapis został zmieniony na: „The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they DO NOT DISRUPT the meeting.”, co sprawia, że odtąd PO może sobie po cichutku stać w kąciku i słuchać – dopóki nie zaczyna partycypować w dyskusji. Nie ma więc mowy o jakimkolwiek „pozytywnym wkładzie PO w Daily”.
Rozumiem, że Autor może nie zgadzać się ze Scrum Guidem, pytanie tylko, czy promując zasady niezgodne z frameworkiem, artykuł nadal ma związek ze Scrumem.
„Daily służy przede wszystkim Deweloperom, a nie Product Ownerowi. ” – nie, nie przede wszystkim. Po prostu TYLKO im, zaś Product Owner obecny na Daily to patologia a nie „dobra praktyka”. Scrum Guide przy okazji opisu Daily słowa nie poświęca roli Product Ownera; zaczyna od zdania „The Daily Scrum is a 15-minute time-boxed event for the Development Team.”, uzupełniając to zdanie o konkrety w kolejnych akapitach, które jednak istnienie PO nadal z premedytacją przemilczają.
Jeśli deweloperzy potrzebują doprecyzowania treści Product Backlog Itemu „zaciągniętego” do Sprint Backlogu podczas Planningu (ewentualnie PO chce się z własnej, nieprzymuszonej woli taką wiedzą podzielić), to jest to aktywność zwana „refinementem” i niewiele wspólnego ma z Daily.
Podsumowując – na wszystko jest odpowiednie miejsce i czas, a potrzeby związane z kooperacją na linii PO-DevTeam (rozmowa o zakresie prac, doprecyzowywanie wymagań, składanie „raportu” o progresie, czy budowanie pozytywnej relacji) powinny być realizowane w innej przestrzeni.
No – to u nas wszystko jest zupełnie odwrotnie ;D
Myślisz, że warto to zmienić? Może jest szansa? Czasem się wydaje, że coś nie wypali, ale wystarczy zapytać / poprosić i się udaje…hm? ;-D