Blog

Prezentujemy kontynuację wywiadu będącego dyskusją na temat zadań i roli Product Ownera w zespole Scrumowym. W części drugiej poruszamy bardziej techniczne aspekty pracy Product Ownera – od analizy po skalowanie i planowanie długofalowe. Pod gradobiciem pytań stanął Professional Scrum Trainer Andrzej Brandt.

Technicznie rzecz biorąc…

Z Twojej perspektywy lepiej stawiać konkretne i zrozumiałe dla wszystkich cele, których osiągnięcie jest wyznacznikiem postępu pracy, czy bardziej sprawdzają się algorytmy monitorujące większe zadania w czasie Sprintu?

Jeśli idzie o śledzenie postępów pracy w Sprincie to głównym narzędziem do tego jest śledzenie rozwoju produktu, zwłaszcza poprzez korzystanie z wersji testowych w miarę ich udostępniania przez zespół. Trzeba to przy tym robić delikatnie, tak, by nie zaburzać pracy zespołu.

Natomiast na pewno bardzo motywują zespół jasne, zgodne z wizją produktu cele, które Product Owner chce osiągać w każdym sprincie.

W swojej książce wspominasz o “efekcie fusów” podczas pracy z Backlogiem – przychodzi to intuicyjnie wraz z wykorzystaniem Scrum, czy wynika bardziej z rzeczowej analizy Backlogu?

To nie ma nic wspólnego z intuicją czy analizą, to raczej kwestia tego czy Backlog Produktu jest rzeczywiście tworem żywym, stale zmienianym w odpowiedzi na zmieniające się oczekiwania użytkowników czy szerzej warunki, otoczenie produktu. Jeśli tak się rzeczywiście dzieje, to zwykle pojawiają się jakieś pomysły, które wydają się z początku fajne i trafiają na backlog dość wysoko. Jednak ze Sprintu na Sprint Product Owner nie decyduje się postawić ich tak wysoko, by zostały zrealizowane – inne rzeczy okazują się być w danym momencie bardziej wartościowe. W końcu taki pomysł zaczyna opuszczać się w Backlogu coraz niżej i niżej – dokładnie jak fusy w szklance herbaty – takie pomysły gromadzą się w końcu na dole Backlogu, skąd można je ze spokojem usuwać.

Podczas targów i konferencji dostajemy często pytanie o Skalowanie. Sam poświęcasz temu zagadnieniu sporo miejsca w swojej publikacji. A jak ze Skalowaniem w kontekście produktu radzą sobie uczestnicy szkolenia?

Słabo. 😀

A poważnie – jak napisałem w mojej książce uważam, że główny problem Skalowania metod zwinnych leży właśnie w obszarze zarządzania produktem i wymaganiami. Polega on na tym jak sprawić by różne zespoły pracujące nad różnymi częściami aplikacji otrzymywały jednocześnie takie wymagania, które po wykonaniu co Sprint będą dawać sensowny całościowy produkt. To tutaj jest najwięcej różnic pomiędzy przeróżnymi metodami skalowania spotykanymi na rynku. Generalnie możliwe są dwa podejścia – hierarchiczne i autonomiczne.

W tym pierwszym tworzy się jakieś kolejne szczeble Backlogów – oraz związanych z nimi Product Ownerów, próbując rozwiązać wspomniany problem koordynacji synchronizacją na wyższych szczeblach. W tym drugim każdy zespół odpowiada za jakiś fragment produktu, wraz ze swoim Product Ownerem. Product Ownerzy nie tworzą hierarchii lecz luźny zespół, który koordynuje rozwój funkcjonalny produktu. Jest to model lepszy, ale w wielu przypadkach praktycznie niemożliwy do zastosowania. Główne przeszkody to taka a nie inna struktura produktu oraz panująca w danej firmie kultura organizacyjna.

Dodajmy, że najczęstszym błędem popełnianym przez firmy jest próba wdrożenia metod zwinnych przy zachowaniu tradycyjnego, warstwowego podziału na zespoły. W efekcie mamy na przykład takie absurdy jak zespół Scrumowy odpowiedzialny za UI, zespół Scrumowy odpowiedzialny za bazę danych – i do tego, na domiar złego, zespół Scrumowy odpowiedzialny za QA. Jest to absurdalne dlatego, że w efekcie żaden z tych zespołów nie jest w stanie stworzyć działającego produktu – żaden nie jest w stanie dojść do etapu ukończenia, w którym użytkownik mógłby potencjalnie korzystać z efektów jego pracy. To nie tylko wymusza wręcz takie dysfunkcje jak „fazy stabilizacji” ale praktycznie uniemożliwia sensowne zarządzanie rozwojem produktu na poziomie zespołów i Product Ownerów.

Planowanie długofalowe nie jest łatwym zadaniem w ciągle zmieniającym się środowisku. Tym bardziej jeśli firma ma wiele projektów i wiele zespołów. Od której strony w ogóle zacząć planowanie długofalowe?

Przede wszystkim od zdania sobie sprawy z tego, że wszelkie długofalowe plany mają zawsze charakter prognoz. Innymi słowy fajnie jest mieć plany, ale trzeba pamiętać, że w każdej chwili mogą one ulec zmianie.

Przejdź do części III