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