Dziś ponownie poruszamy temat codziennego, co najwyżej piętnastominutowego spotkania. Mowa oczywiście o Daily, a tym razem – o obecności na nim Product Ownera.
Dla kogo jest Daily?
Można by odnieść wrażenie, że ostatnio uparłem się na Daily Scrum. Po ostatnim #nomoredaily, dziś ponownie zajmujemy się tym palącym tematem. Bo kto z nas nie spotkał się z sytuacją, w której nagle, ni z tego, ni z owego na Daily pojawia się Product Owner? A może to normalna praktyka? Po co Product Owner na Daily Scrum?
Sprawa wydaje się być prosta. Według Scrum Guide Daily Scrum jest dla Zespołu. Ale nie dla Scrum Team, a tego deweloperskiego. I tylko dla niego! To zespół ma zaplanować najbliższe osiem godzin pracy do następnego Daily. Przecież to zespół wymienia między sobą informacje na temat aktualnego stanu prac i on identyfikuje przeszkody, które uniemożliwiają mu pracę. Skoro jest to spotkanie dla zespołu, to dlaczego pojawia się na nim Product Owner?
Nie chciałbym, abyście zrozumieli mnie źle. Nie odbieram nikomu możliwości pojawienia się na spotkaniu. Ale mam wrażenie, że twórcy metodyki dokładnie ją przemyśleli i definiując codzienne spotkanie celowo nie zaprosili na nie Product Ownera. Zresztą nie tylko jego nie ma na tym spotkaniu!
Dlaczego nie mogę tam być?
Szukając powodów, dla których Product Ownera nie powinno być na Daily muszę odnieść się do naszego doświadczenia. Scrum Guide nie określa tych powodów. Wspomina jedynie, że jest to „spotkanie wewnętrzne Development Teamu”, a jeśli pojawiają się nań inne osoby „Scrum Master upewnia się, że nie zaburzają one przebiegu spotkania”.
Nasze doświadczenie jasno pokazuje, że obecność PO na Daily zaburza to spotkanie. Nie wiadomo dlaczego, ludzie nagle zaczynają mówić właśnie do PO. Mam też wrażenie, że kończy się wówczas transparentność naszego przekazu. W końcu Product Owner to osoba odpowiednio umocowana w organizacji, na pewno nie jest więc równorzędnym pracownikiem.
Przychodząc na Daily Scrum Product Owner robi to w konkretnym celu. Nie ferowałbym opinii, że przychodzi na nie po to, aby dopilnować co robi zespół i czy na pewno pracuje we właściwym tempie. Choć czasem może mieć miejsce i taka sytuacja, nie należy ona do częstych.
PO pojawia się też na tym wydarzeniu z powodu próśb zespołu i/lub braku informacji o aktualnym statusie prac. Te dwie potrzeby można jednak załatwić w zupełnie inny sposób. Taki, który nie przeszkodzi zespołowi organizować spotkania w swoim gronie i czerpać z niego określonych korzyści.
Potrzeba informacji
Informacja jest na wagę złota. Product Owner na Daily Scrum pojawia się najczęściej właśnie po to, aby uzyskać lub zaspokoić potrzebę informacji. Oznacza to, że Scrum Team mierzy się z problemem komunikacji. Podchodząc do zagadnienia praktycznie, PO powinien wiedzieć, na jakim etapie realizacji elementów Backlogu Produktu zaplanowanych do realizacji w Sprincie jest Zespół Deweloperski. Czy musi się to odbywać właśnie na Daily? Zdaje się, że dobrze opisuje to przewodnik po Scrum:
„W dowolnym momencie powinno być możliwe podsumowanie całej pozostającej do wykonania pracy. Właściciel Produktu dokonuje takiego podsumowania przynajmniej podczas każdego Przeglądu Sprintu.”
W dowolnym momencie, przynajmniej raz na Sprint podczas Sprint Review – oto receptura na zbieranie informacji o zaawansowaniu naszych prac. Czy musimy więc dokonywać tego na Daily? Wydaje się, że nie. Zostawmy to wydarzenie zespołowi, niech korzysta z niego najlepiej jak potrafi.
Przyjrzymy się teraz drugiej z opisywanych wyżej przyczyn obecności PO na Daily – potrzebie wyjaśnienia zakresu prac zespołowi. Jako argument „za” słyszymy często, że skoro możemy skrócić drogę do informacji o wymaganiu i uzyskać ją podczas Daily, to dlaczego nie skorzystać z tej możliwości?
O jednej przyczynie, czyli „raportowaniu do PO”, napisałem już wyżej. Druga związane jest z brakiem ważnego elementu naszego procesu. Bardziej spostrzegawczy zauważyli naszą fascynację Refinementem. Uważamy go za absolutną podstawę zwinnego działania.
Potrzeba uzyskania informacji o wymaganiu na Daily świadczy o tym, że Refinement się nie odbył lub sposób jego przeprowadzenia nie doprowadził do osiągnięcia jego celu. W dalszym ciągu nie wiemy, co jest do zrobienia! Zamiast więc zapraszać na Daily Product Ownera i rozmawiać szczątkowo o wymaganiach (mamy przecież tylko 15 minut), poprawmy nasz Refinement! Korzyści zauważymy nie tylko na Daily.
Product Owner na Daily Scrum
Product Owner na Daily? Mam nadzieję, że każdy jest już w stanie odpowiedzieć sobie na to pytanie. Nie mogę napisać twardo „Nie”, bo przyczyn, dla których Właściciel Produktu przychodzi na codzienne spotkanie może być więcej. Wskazaliśmy najpopularniejsze z nich, opisaliśmy również co się może stać, jeśli jednak będzie on obecny. Jak zawsze każdy przypadek będzie inny i każdy wymaga indywidualnego podejścia.
Chciałbym jednak, abyśmy rozpoczęli proces stopniowej eliminacji Product Ownera z Daily. Dokonajmy analizy, dlaczego przychodzi na spotkanie, sprawdźmy, czy i jakie informacje z niego uzyskuje on, a jakie zespół. Zaplanujmy akcje, które finalnie spowodują, że nie będzie musiał być on obecny. Oddajmy Daily zespołom!
Brak PO na codziennym Daily to możliwość otwartej i szczerej rozmowy o tym, co dla zespołu jest najważniejsze. Czy możemy sobie pozwolić na nie wykorzystanie tej szansy?