4 marca 2018
Maciej Wilmiński
Product Owner na Daily?
W ostatnim czasie coraz szersze kręgi zatacza praktyka obecności Product Ownera na spotkaniu Daily Scrum. Ten trend wydaje się coraz mocniej zaznaczać w scrumowym świecie. Ba, dla wielu, szczególnie tych stawiających swe pierwsze kroki w zwinnym środowisku, wydaje się być czymś całkowicie naturalnym, standardowym. Czy to faktycznie dobry pomysł? Albo inaczej – czy jest w tym coś złego?
Sami twórcy Scruma, skąd wywodzi się wszakże taka formuła spotkania, na przestrzeni lat nieraz zmieniali zdanie w tej materii.
W pierwszej wersji Przewodnika po Scrumie wskazywali, że to spotkanie dla tych, którzy przekształcają elementy backlogu w przyrost. Oraz, że Scrum Master egzekwuje, że kurczaki (w ówczesnym rozumieniu – interesariusze, w tym Product Owner – przyp. M.W.) nie mają prawa się odzywać, ani wtrącać się w przebieg spotkania.
Później przekaz zradykalizował się i obecność Product Ownera wskazano jako aberrację, formułując jednoznacznie: Scrum Master egzekwuje zasadę, że tylko Zespół Deweloperski bierze udział w Daily Scrum. Co warto zaznaczyć, w Przewodniku po Scrumie tak mocne słowa to rzadkość, tak jak i tak silne prerogatywy dla Scrum Mastera.
Z kolei w najnowszej wersji Przewodnika, czytamy znów złagodzony przekaz, zbliżony do pierwotnego: Daily Scrum jest wewnętrznym spotkaniem Zespołu Deweloperskiego. Jeśli inne osoby są obecne, Scrum Master upewnia się, że nie zaburzają one jego przebiegu.
Już ta niekonsekwencja pokazuje nam, że odpowiedź na postawione w artykule pytanie nie jest jednoznaczna.
Wielu spośród agile’owych autorytetów popiera przeprowadzanie tego spotkania w pełnym składzie zespołu Scrumowego.
Roman Pichler w ciekawym artykule 4 Daily Scrum Tips for Product Owners rekomenduje obecność Product Ownera na co najmniej dwóch Daily w tygodniu. Ma to pomóc w zrozumieniu tego, co się dzieje w zespole i ewentualnie zapewnić mu potrzebne wsparcie (PO ma okazję “zatwierdzić” wykonane zadania, posłuchać z czym zmaga się zespół, rozwiązać bieżące problemy czy dokonać szybkiej analizy jakiegoś zadania z backlogu). Pichler wyraźnie podkreśla wszakże, że to spotkanie zespołu deweloperskiego i Product Owner powinien pozostać w cieniu, podkreśla także zagrożenie zmiany charakteru spotkania na statusowe.
Główne “zagrożenia”, problemy, płynące z obecności Product Ownera na tym spotkaniu są dość oczywiste. Wymieńmy je. Punkt pierwszy – wspomniany wyżej – ryzyko zmiany spotkania w typowy status, gdzie członkowie zespołu deweloperskiego składają Generalissimusowi raport z pola bitwy. Drugi – malowanie trawy na zielono lub mowa – trawa.
A zatem – brak należytej otwartości, ukrywanie rzeczywistej sytuacji w sprincie ze strony zespołu deweloperskiego za ogólnikami, czyli słynna odpowiedź statusowa, pytanego na każdym piętrze faceta spadającego z dziesiątej kondygnacji: na razie wszystko w porządku. Albo wręcz przeciwnie – rozbudowane wypowiedzi, sugerujące, jak wiele zostało zrobione. W obu przypadkach członkowie zespołu skupiają się na PO i przekazywaniu informacji jemu, a nie innym członkom zespołu.
I w końcu trzeci – nie trzymanie języka za zębami przez PO, próba wpływania na organizację pracy zespołu, wskazania czym się zająć w następnej kolejności, sugestie co do podziału prac, wywoływanie presji.
Efekt jest zawsze takie sam – spotkanie traci swój podstawowy cel, a, jak pisałem w innym artykule poświęconym Daily ma ono: służyć przede wszystkim synchronizacji działań i zaplanowaniu najbliższego dnia pracy oraz zidentyfikowaniu problemów zagrażających realizacji zaplanowanych zadań.
W większości przypadków wymienione wyżej problemy powinny być jednak dosyć proste do wyeliminowania. Ale sytuacje te mogą kryć głębsze, poważniejsze trudności. Traktowanie Product Ownera jako kogoś “ważniejszego”, strach przed nim, co gorsze może i brak zaufania. Albo dominacja Product Ownera nad zespołem, podporządkowanie go sobie i pozycjonowanie siebie w roli przywódcy stada. W tej sytuacji Daily po prostu odkrywa inne problemy. Odkręcenie tego, to wszystko robota dla Scrum Mastera, wymagająca większej lub mniejszej finezji.
Większość Product Ownerów z pewnością chętnie przyjmie zaproszenie na Daily. Będą na pewno zadowoleni, że na krótkim spotkaniu, raz dziennie o stałej porze, załatwią całą “bieżączkę” w zespole, a do tego – nie oszukujmy się – uzyskają status prac.
No właśnie, ten nieszczęsny status. Niemało PO nie tyle lubi wizytować Daily, co uznaje to za konieczność, aby mieć pewność, że obiecany zakres sprintu zostanie zrealizowany. Brak zaufania do zespołu (nierzadko są do tego mocne podstawy) albo naciski “z góry”, powodują, że rodzi się poczucie konieczności kontroli, pilnowania czy zespół radzi sobie jak trzeba, czy sprint nie jest zagrożony. Często chodzi tu też o uzyskanie terminów wdrożenia. W tych sytuacjach – znów – PO chodząc na Daily rozwiązuje problem leżący zupełnie gdzie indziej i wymagający natychmiastowej interwencji Scrum Mastera.
I – czy tego chcemy, czy nie – obecność Product Ownera zawsze w większy lub mniejszy sposób na to spotkanie wpłynie. Członkowie zespołu deweloperskiego automatycznie wykorzystają jego obecność, do zadania pytań, wyjaśnienia wątpliwości, tam gdzie one ostatnio się pojawiły. Pojawią się nowe wątki, dyskusje, nawet jeśli pozostawione jak klasyczne technikalia na, “po daily”, odciągające od głównego celu spotkania, zakłócające jego rytm, a w konsekwencji koncentrację uczestników. Zabieranie głosu Product Ownerowi “na później”, na “po spotkaniu”, będzie wydawało się po prostu sztuczne. Tym bardziej, że na pewno na spotkaniu trafi się okazja, potrzeba, aby zabrał głos, nawet jeśli ktoś go o to bezpośrednio nie poprosi.
Skoro tyle tu problemów, to może sobie po prostu to odpuścić? Czy są w ogóle jakieś plusy?
Na pewno, będąc na Daily, PO zbliża się do zespołu i ma okazję bliżej poznać jego codzienne zwyczaje, zachowania, ale i bolączki. Pozwala to lepiej zrozumieć zespół na wielu płaszczyznach. I budować Zespół Scrumowy, a nie tylko Deweloperski. Jak już wspomniałem wcześniej, PO zyskuje też jedno miejsce i czas na załatwienie bieżących spraw z całym zespołem. A i zespół na jednym spotkaniu załatwi wszystko, co potrzeba. W końcu – mamy jeszcze lepszy przepływ informacji. Wystarczy wszak zadbać tylko o nie zaburzanie jego przebiegu. I tyle.
W czym zatem problem? I co z tego wszystkiego wynika?
Product Owner poprosił Cię, jako Scrum Mastera, o to, że chciałby przychodzić na Daily?
Po pierwsze, porozmawiaj z nim o jego intencjach. Dlaczego chciałby uczestniczyć w tym spotkaniu, co chciałby uzyskać. Upewnij się, czy nie chce w ten sposób rozwiązać jakichś innych problemów, które widzi w zespole.
Po drugie, jeśli już wstępnie zaakceptujesz ten pomysł, porozmawiaj z zespołem. Jasno komunikuj ideę, powód, ale i oczekiwania. I zapytaj ich o zdanie.
W końcu – nie ulegaj presji. To Ty, jako Scrum Master, decydujesz o tym, jak to spotkanie powinno wyglądać i kto powinien w nim uczestniczyć. I jeśli uznasz, że Product Owner powinien na nim być, zaproś go. A potem mocno pilnuj i obserwuj czy wszystko działa jak należy. Daily z Product Ownerem, to już zdecydowanie więcej wyzwań, aby spotkanie przynosiło oczekiwane profity. A jeśli wbrew innym – uważasz inaczej – wyjaśnij wszystkim stronom dlaczego podjąłeś taką decyzję.
Osobiście jestem przeciwnikiem obecności PO na Daily. Zależy mi na tym, żeby to spotkanie pozostało czysto deweloperskie, żeby nikt i nic nie odciągało Zespołu od nadrzędnego celu – wspólnego zaplanowania prac. I nie chcę na nim nikogo innego, nawet jeśli miałby się nie odzywać. Co nie znaczy, że od tej reguły nie ma wyjątków. Ale to chyba na tym polega właśnie piękno agile?