Praca Scrum Mastera z Product Ownerami – część II

W poprzedniej części artykułu skupiliśmy się na omówieniu szkoleń i różnego rodzaju warsztatów, które organizujemy dla naszych Product Ownerów. Mamy już opracowane: wprowadzenie do pracy w roli PO, przygotowanie do zdobycia certyfikatu z serii PSPO, wstęp do zwinnej pracy dla interesariuszy Zespołów, a od niedawna, wspólnie z doświadczonymi Product Ownerami, prowadzimy dla całego działu Product Development warsztaty w zakresie pracy nad wymaganiami i backlogiem.


Tym razem, z perspektywy czasu, bliżej przyjrzymy się naszej „pracy operacyjnej”, codziennym działaniom, jakie realizowaliśmy na początku naszej zwinnej drogi, optykę kierując na kwestię wymagań biznesowych – sposób ich opisu, zlecania, śledzenia postępu i weryfikacji.

 

Obserwacja

Zaczęliśmy klasycznie. Przez kilka pierwszych cykli, wówczas tygodniowych i już nazywanych w firmie Sprintami, cierpliwie przyglądaliśmy się procesom prowadzenia projektu oraz utrzymania i rozwoju naszej aplikacji. Co prawda pierwsze działania mocno skoncentrowaliśmy na dziale IT, przebywaliśmy głównie z deweloperami i poznawaliśmy w szczególności ich punkt widzenia, ale uczestniczyliśmy też w spotkaniach typowo biznesowych, a przede wszystkim dużo rozmawialiśmy z wszystkimi zaangażowanymi w wytwarzanie oprogramowania, niezależnie od ich roli i miejsca w organizacji. Nie ma bowiem lepszej metody na poznanie sposobu funkcjonowania firmy i zrozumienia procesów, które w niej funkcjonują, niż bezstronna obserwacja.

Kanban board

GetResponse to firma z bogatą, już 20-letnią historią. Przez ten czas wypracowanych zostało wiele rozwiązań, dobrze sprawdzających się w kontekście organizacji, a które łatwo na pierwszy rzut oka zdyskredytować, bo rzekomo nie pasują do agile’owej rzeczywistości. Oczywiście, mimo że doskonale o tym wiedzieliśmy, sami sparzyliśmy się, wprowadzając niektóre zmiany zbyt szybko, gwałtownie, nie doceniając dotychczasowego sposobu działania w danym obszarze i jego skuteczności. Cierpliwość i rozwaga we wprowadzaniu zmian oraz wnikliwość w zrozumieniu, dlaczego coś realizowane jest w taki, a nie inny sposób, to cechy, które są potrzebne każdemu Scrum Masterowi, chcącemu zmieniać organizację.

Po kilku tygodniach obserwacji mieliśmy masę notatek, przemyśleń, sporo entuzjazmu do działania i głowę pełną pomysłów. Po omówieniu ich z Menedżmentem, ruszyliśmy do działania.

 

Wymagania dla wymagań

Zaczęliśmy od opracowania standardów dotyczących wymagań i backlogów. Właśnie – backlogi. Zabraliśmy się za uporządkowanie strumienia zadań spływających do poszczególnych zespołów. Od tej pory wszystko miało trafiać do dedykowanych backlogów w Jirze, które zgodnie z duchem Scruma, miały być jedynym źródłem wszystkich wymagań. Koniec z mniej oficjalnymi zadaniami, „szybkimi strzałami”, wrzutami, a to z maila, a to ze Slacka, a to omówionymi gdzieś przy kawie. Trzeba było zmienić dotychczasowe przyzwyczajenia, a także przekazać wszem i wobec, że o kolejności realizacji danego wymagania decydują wyłącznie Product Ownerzy, którzy stali się głównymi osobami odpowiedzialnymi za backlog, decyzyjnymi w jego zakresie.

Kolejnym krokiem była standaryzacja formatu wymagań.

Wspólnie z Product Ownerami wypracowaliśmy ogólnofirmowe Definition of Ready, które w znacznej mierze oparliśmy na klasycznym podejściu INVEST, opracowanym przez Billa Wake’a. Jako rzecz najważniejszą wskazaliśmy Wartość. Nacisk położony został na to, aby każde wymaganie – niezależnie od przyjętego formatu – miało jasno sprecyzowany cel, informacje nie tylko co jest do wykonania, ale przede wszystkim, dlaczego chcemy daną funkcjonalność realizować. Wiedza o tym, po co pracujemy nad implementacją danego wymagania, jest podstawą zwinnego trybu pracy. Buduje zaangażowanie, daje możliwość dyskusji, zaproponowania rozwiązania, wspólnej pracy nad wymaganiem, w przeciwieństwie do klasycznej pracy i podziału zlecający – realizujący.

Druga podstawowa zasada, wzajemne oczekiwanie, jakie sobie postawiliśmy, to jasno zdefiniowane i zrozumiałe kryteria akceptacji. Istotne było, aby wyeliminować niesnaski związane z różnym rozumieniem tego, co należy zrealizować, i zbudować zasady jednoznacznie wskazujące na to, co właściwie oznacza, że wymaganie jest zakończone.

Aby to urzeczywistnić, konieczne było wprowadzenie też Definition of Done w poszczególnych zespołach. Tu również trzeba było dużego zaangażowania Product Ownerów celem podjęcia ważnych decyzji biznesowych, chociażby dotyczących tego, jakie przeglądarki w jakich wersjach i jakie urządzenia mobilne wspieramy.

Zaczęliśmy trochę od drugiej strony, niż robi się to zazwyczaj, kiedy najpierw tworzone jest Definition of Done dla całej firmy, a potem jest ono rozszerzane, staje się coraz bardziej restrykcyjne na poziomie poszczególnych zespołów. Postąpiliśmy tak, ponieważ w tamtym czasie brak było jednoznacznie wskazanych standardów i unifikacji sposobu pracy poszczególnych zespołów – czy to na poziomie standardów kodowania, używanych narzędzi czy procesu wdrażania kodu. Potrzeba było sporo pracy, głównie wykonanej przez Architektów i doświadczonych deweloperów, aby te kwestie uporządkować, ustandaryzować i ustalić wspólne zasady. To długi, czasochłonny i niełatwy proces, który w końcu doprowadził nas do wprowadzenia firmowego Definition of Done.

Mieliśmy zatem gotowe standardy dotyczące tworzenia i realizacji wymagań. Trzeba było przygotować te podwaliny, zanim mogliśmy wejść w praktykę. Jednak taka ilość zasad, wprowadzanych za jednym razem, wzbudziła w organizacji spore zaniepokojenie. Dopóki nie przeszliśmy do wprowadzenia ich w życie, część osób odebrała to wszystko jak oprocedurowanie prostych, oczywistych rzeczy, a w efekcie wydłużenie czasu realizacji zadań, które dotychczas realizowane były ad hoc. Do całości podchodzono z dużą nieufnością. Były obawy, że zamiast pracować nad implementacją wymagań, większość czasu będziemy tracić na cyzelowanie ich formatu, wyglądu, staranności i precyzyjności opisu. Wrażenie było takie, że proste procesy są biurokratyzowane i powstaje cała masa bezużytecznej, uciążliwej bumagi. Staraliśmy się wyjaśnić, po co to wszystko, ale wiedzieliśmy, że wszystkie te obawy rozwieje dopiero czas i konsekwentna realizacja założeń, które z czasem przyniosły oczekiwane profity.

Kiedy nasz złotousty orędownik agile, kot Waldemar (patrz: Jak dbać o przepływ informacji), lobbując za zmianami, przemówił cytatem: wiedzy korzeni niemiłe, owoc słodki, jeden z deweloperów szybko i celnie spuentował i dopisał: „wystarczy mi słodzik streszczenia”.

Wystarczy mi słodzik streszczenia

Wszystkie te zmiany dość mocno obciążyły też Product Ownerów, bo dokładały im sporo nowych obowiązków. Stąd konieczne było, abyśmy jako Scrum Masterzy nie ustawili się w wygodnej pozycji egzekutorów realizacji założeń, ale sami świecili przykładem i codziennie wspierali PO i Zespoły Deweloperskie w pracy z backlogiem. Dzięki temu, że w początkowej fazie włączyliśmy się również w pisanie wymagań czy koordynację komunikacji ze zlecającymi, czas „rozruchu” i wejścia w krew opracowanych zasad przeszedł bezboleśnie.

 

Standardy w praktyce

A jak wyglądał ten czas „rozruchu”?

Pierwsza sprawa to zasady weryfikacji wykonanych zadań. Przede wszystkim ustaliliśmy, że robi to zawsze Product Owner, że jest głównym odpowiedzialnym, niezależnie od tego, kto zleca zadanie. Zapewniliśmy w ten sposób, że tak Zespół, jak i zleceniodawcy zadań dla niego i interesariusze kontaktowali się w sprawach wymagań wyłącznie z Product Ownerem. W konsekwencji PO dostali kolejny zestaw obowiązków komunikacyjno-koordynacyjnych. Było to szczególnie ciężkie na początku drogi, zanim powszechnie zrozumiano nowy model pracy. Stąd właśnie, jak już wspomnieliśmy wyżej, jako Scrum Masterzy mocno włączyliśmy się na początku tego procesu, przejmując tymczasowo rolę pośrednika (lub, jak kto woli: proxy) pomiędzy PO a Zespołem i interesariuszami. Tłumaczyliśmy, wyjaśnialiśmy i staraliśmy się, aby wszyscy dobrze zrozumieli nowe zasady i wiedzieli, czego można oczekiwać od Product Ownerów i w jaki sposób się z nimi komunikować.

Kolejna kwestia to „zmiany” w wymaganiach w trakcie ich implementacji. Wprost zapisaliśmy zasadę, że wymagania biznesowe mogą ulegać zmianom tak długo, jak nie trafią do realizacji, w momencie, kiedy rozpoczną się nad nimi prace (np. trafią do Sprintu), pozostaje wyłącznie ewentualne doszczegółowienie na podstawie wątpliwości realizujących. Oczywiście samo zapisanie takiej reguły to nie wszystko. Konsekwentnie uczyliśmy zespoły asertywności, pokazując jednocześnie zleceniodawcom zagrożenia i skutki związane z podjęciem realizacji niedopracowanych, nie do końca przeanalizowanych pomysłów.

W kwestii „odbioru” zadań, chcieliśmy utrzymać dotychczasowy tryb, gdzie zadanie było weryfikowane przez zgłaszającego tak wcześnie, jak to tylko możliwe. Product Owner widział i potwierdzał zatem poprawność realizacji danych zadań w czasie trwania Sprintu, a na Przeglądzie Sprintu prezentowano już zaakceptowane, nierzadko wdrożone na produkcję wymagania. Nowością było wprowadzenie pełnej transparentności pracy Zespołu Deweloperskiego. PO w każdym momencie wiedział, na jakim etapie znajdują się prace nad danym zadaniem, a nie czekał cierpliwie, aż z „czarnej skrzynki IT” wyskoczy niespodziewanie gotowy produkt.

A skoro już jesteśmy przy statusach – ustaliliśmy zasady pracy od strony technicznej, w używanej przez nas do prowadzenia backlogów Jirze. Uporządkowaliśmy i ujednoliciliśmy reguły – statusy, ich znaczenie, „przepływ” (tzw. workflow), co powinno znaleźć się w danym polu. Staraliśmy się przy tym zachować zdrowy rozsądek i elastyczność i zachować specyfikę funkcjonowania poszczególnych zespołów. Łatwo wpaść w pułapkę procesów, standardów i zasad, przez co znika gdzieś idea zwinności. Naczelna zasada była też jedna: wszystko miało być proste, logiczne i naturalne. Celem było wspomaganie prac, a nie utrudnianie. Stąd zaledwie kilka statusów i prosty flow (new → in progress → ready for tests → in tests → to review → for deploy → done). Tak, próbowaliśmy pracy z klasycznymi tablicami i post-itami, ale to temat na osobny wpis.

Rozpoczęliśmy też prace nad tzw. kulturą pracy w Jirze. Naczelnym zadaniem było wyeliminowanie komentarzy dotyczących zadań na rzecz bezpośrednich rozmów i to, żeby całość wymagania znalazła się w jednym polu (Description), a nie – jak to często się zdarzało – część w opisie, a doprecyzowania i zmiany w komentarzach. Stworzyliśmy też schemat boardów dla Zespołów i Jirowych dashboardów, dających różne informacje w zależności od potrzeb – dla Zespołów, Product Ownera czy menedżerów.

Po tym wszystkim pozostało nam znów cierpliwie obserwować proces, tym razem w nowym, realizowanym według naszych pomysłów, kształcie. Obserwować, słuchać, rozmawiać, decydować, a przede wszystkim – nieustannie ulepszać. Wierzyliśmy w to, że idziemy we właściwym kierunku i – mimo wspomnianej początkowej nieufności – w końcu udało się nam przełamać sceptycyzm w stosunku do zmian i zdobyć mandat do dalszych działań.

 

Wnioski

Trzy lata to kawał czasu. Patrząc na to, jak proces wygląda dzisiaj, wszystko wydaje się proste i oczywiste, wręcz naturalne. W naszej pamięci zatarły się wspomnienia o tym, ile wysiłku i pracy potrzebne było, aby zmienić dotychczasowe przyzwyczajenia i sposób organizacji pracy.

Kluczowe było nasze aktywne włączenie się w cały proces, początkowo znacząco wychodząc z roli Scrum Masterów, realizując rzeczy, które docelowo miał robić czy to Product Owner czy Zespół Deweloperski. Takie działanie przez przykład miało przede wszystkim pokazać, że to wszystko nie jest takie straszne, trudne czy czasochłonne. Że potrzeba wyłącznie chęci i dobrej organizacji pracy.

Druga ważna sprawa to przetrwanie początkowego okresu zmian, kiedy oczywistym jest, że będzie gorzej, że zapanuje mniejszy lub większy chaos. Zwinne metody mają to do siebie, że uwidaczniają wszelkie istniejące problemy. Spod dywanu wychodzi zamieciony brud, a zdarza się, że i coś wypadnie z przysłowiowej szafy. Trzeba otwarcie stanąć w szranki z problemami. Istotne jest, aby dostać od organizacji glejt na ich metodyczne zwalczanie, nastawione na konkretne wyniki, ale pozbawione silnej presji czasu.

Tyle w kwestii współpracy PO ze Scrum Masterami w kwestii wymagań. Za miesiąc, w kolejnej części artykułu, zrobimy kolejny krok i zagłębimy się z kolei w zmiany, jakie zachodziły w związku z wprowadzaniem poszczególnych spotkań scrumowych.

BĄDŹ NA BIEŻĄCO:

x

BĄDŹ NA BIEŻĄCO:

x