Ten artykuł jest trzecim w ramach cyklu opowiadającego o tym, jak, jako Scrum Masterzy, rozpoczynając transformację agile w GetResponse, współtworzyliśmy platformę współpracy IT ↔ Product Development i w jaki sposób wypracowaliśmy zasady wspólnego działania z naszymi nowo powołanymi Product Ownerami.
Kiedy mieliśmy już za sobą szkolenia wstępne, wprowadzające do roli PO i ruszyliśmy z cykliczną wymianą wiedzy, a także ujednoliciliśmy oraz uporządkowaliśmy sposób tworzenia i zapisu wymagań, nadszedł czas na zmianę sposobu codziennego działania. Zaczęliśmy zatem reformować istniejące spotkania na linii Zespoły IT ↔ Product Development, które już wcześniej (o czym mogliście przeczytać w naszym pierwszym artykule) zostały powołane w scrumowym duchu i nomenklaturze. I właśnie w związku z tym, czekała nas mała niespodzianka.
Trudne początki
Okazało się, że efektem ubocznym wprowadzenia scrumowej terminologii w zakresie m.in. spotkań – wprowadzenia Planowania Sprintów i Daily – było myślenie niemałej części osób, że to, co już funkcjonowało, to jest właśnie ten “mityczny Scrum”. Zarówno ówczesna forma Backlogów, jak i samych spotkań, znacząco odbiegały jednak od formuły Scrumowej. Były zaledwie drogą do celu, swoistym przygotowaniem przedpola do dalszych działań.
Nie wszyscy pracownicy mieli wcześniej styczność z agile’owym sposobem pracy, stąd spora ich część uznała, że tak te wszystkie “wydarzenia” powinny właśnie wyglądać. Opinia ta dość mocno zakorzeniła się szczególnie wśród deweloperów. Efekt został spotęgowany faktem, że wydarzenia te, nawet w takiej niepełnej, nieniosącej pełnych profitów formie, były pewnym kamieniem milowym w sposobie planowania i organizacji prac, a także codziennym rozmawianiu o ich postępie. Innymi słowy – były widoczne ich pozytywne skutki, co odczuwały nie tylko Zespoły IT i osoby najbliżej z nimi pracujące.
I w to wszystko wchodzimy nagle my, Scrum Masterzy… I znowu chcemy coś zmieniać! Niełatwo było wytłumaczyć, dlaczego te spotkania powinny zmienić swoją formułę. I wprowadzać w nich zmiany – przyjmowane niechętnie, a konieczne.
Konsekwencja i komunikacja
Główny problem wystąpił w Zespołach w momencie wysłania, w firmowym kalendarzu, zaproszeń do pierwszych cyklicznych scrumowych wydarzeń w pełnym zestawieniu. Co się wówczas stało? Klasyka – chciałoby się rzec – bowiem natychmiast pojawiły się głosy, że spotkań jest za dużo, że nie będzie czasu na pracę, że ciągle będzie się odrywanym od “podstawowych” zadań. Product Ownerzy również byli temu nieprzychylni, nie widzieli początkowo wartości w dokładaniu kolejnych cyklicznych “zebrań”. Do tego praktycznie każde z nich kładło szczególny nacisk na wykonanie niemałej pracy i solidnego przygotowania z ich strony.
Byliśmy jednak na te zjawiska w pełni przygotowani. Znów potrzebne były duże pokłady wytrwałości i cierpliwości. Właściwie, podobnie jak w przypadku wprowadzania zmian w kwestii wymagań, można wręcz dosłownie zacytować zdanie z poprzedniego artykułu: 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.
Najważniejsza była klarowna komunikacja i pozostawienie sporej przestrzeni na kontestowanie i zadawanie pytań ze strony Zespołu czy PO co do samej formuły czy istoty zdarzeń. Istotne było też, aby wszystkie spotkania od początku były przeprowadzane sprawnie, żeby nikt nie miał poczucia zmarnowanego czasu, żeby ludzie zrozumieli, że mają one dużą wartość, że to też “praca”. Stąd to właśnie my, Scrum Masterzy, na początku prowadziliśmy niemalże wszystkie, aby pokazać pewien wzór na przyszłość.
Przyjrzyjmy się zatem ewolucji poszczególnych spotkań, szczególnie pod kątem roli, jaką pełnili w nich Product Ownerzy.
Planowanie Sprintu
W momencie rozpoczęcia transformacji agile, wydarzenie o takiej nazwie funkcjonowało w firmie już od kilku miesięcy. W telegraficznym skrócie: praca toczyła się w tygodniowych cyklach, już nazywanych Sprintami, w ramach których odbywały się dwustopniowe podsumowania i planowania. Oba najpierw odbywały się w gronie menedżerów IT i wybranych deweloperów, a następnie menedżerowie podsumowywali tydzień oraz proponowali plan na kolejny już w gronie Zarządu czy Kierownictwa.
Najważniejszymi zadaniami były zatem:
- scedowanie na Product Ownerów całej odpowiedzialności za cel/propozycję zadań do zrealizowania w ramach danej iteracji,
- scedowanie na Zespoły Deweloperskie decyzji, ile pracy są w stanie wykonać w ramach iteracji i jak tego dokonają, jaki na to mają plan.
Oczywiście oba tematy nie są łatwe do wprowadzenia i wdrożenie ich w życie to długotrwały proces. Od wsparcia współpracy Product Ownerzy ↔ Interesariusze (w tym Zarząd), poprzez wdrożenie nowych zasad estymacji (Story Points, Planning Poker) i stopniowe przejmowanie przez deweloperów odpowiedzialności za prognozowany zakres prac do realizacji, po wykształcenie samodzielności i samoorganizacji. Zespoły zyskały wolność, ale straciły “parasol ochronny” – musiały nauczyć się przyjmowania konsekwencji własnych decyzji.
To między innymi te zmiany potrzebowały pewnego “okresu ochronnego”. Efektem bowiem było to, że początkowo nastąpił regres pod kątem organizacji pracy i jej efektów. Jako Scrum Masterzy wzięliśmy odpowiedzialność za to, żeby to “gorzej” nie spowodowało przestojów czy problemów w codziennym funkcjonowaniu firmy i żeby jak najszybciej przejść do docelowego stadium. W tym celu musieliśmy znacząco wyjść poza teoretyczne ramy naszej roli i niejako “z lotu ptaka” nadzorować całość, by w sposób możliwie przezroczysty i niewidoczny reagować na zauważane problemy i eliminować je na jak najwcześniejszym etapie.
Po niespełna pół roku udało się zbudować odpowiednie podwaliny. Zespoły Deweloperskie zaczęły planować wespół z Product Ownerami, a efekty spowodowały, że Menedżerowie zaufali temu rozwiązaniu.
Daily Scrum
Czy Product Owner powinien uczestniczyć w Daily Scrum zespołu? To pytanie rozgrzało już niejedną agile’ową dyskusję, również w naszej firmie. W Sieci znajdziemy niejeden artykuł przedstawiający konsekwencje jednego i drugiego podejścia, jego wady i zalety. Sam Przewodnik po Scrumie na przestrzeni lat nie jest w tej sprawie konsekwentny, zmieniając często zdanie w tej materii. U nas od początku było z tym… różnie. Już dwa pierwsze zespoły scrumowe różniły się pod tym kątem: w jednym Product Owner był stałym gościem na tym spotkaniu, w drugim nie.
Kiedy ilość zespołów się rozrosła, gdzieniegdzie zaczęły się pojawiać pytania, tak ze strony Właścicieli Produktu, jak i deweloperów: dlaczego są takie różnice w tej kwestii pomiędzy zespołami? Wzięliśmy ten temat na wokandę w zespole scrummasterskim i zgodnie ustaliliśmy, że decyzję tę pozostawiamy w pełni Scrum Masterom poszczególnych zespołów. Każdy z nas podejmował ją w porozumieniu z Zespołem i Product Ownerem, ale jednocześnie każdy miał prawo do liberum veto i działania wedle tego, co sam uznaje za najlepsze dla danego Zespołu na danym etapie jego rozwoju.
W chwili obecnej w większości naszych zespołów Product Owner jest obecny na Daily.
Doskonalenie Backlogu
Już na samym początku zdecydowaliśmy, że we wszystkich zespołach Doskonalenie Backlogu przyjmie formę dedykowanych spotkań. Założeniem było też, że będzie odbywać się co tydzień i trwać jedną godzinę, co z czasem stało się naszym uzusem. Oczywiście, w przypadku, gdy jest taka potrzeba, dodatkowe doskonalenia zwoływane są ad hoc.
Było to całkowite novum, więc z miejsca udało nam się wykreować pożądaną formułę, która w zasadzie od samego początku satysfakcjonuje zarówno nas, jak i wszystkich uczestników. Postawiliśmy na dyskusję i wspólne kreowanie wymagań. Product Ownerzy zawczasu przygotowują listę tematów do omówienia, wcześniej przekazują ją zespołom, a w czasie spotkania zagadnienia są omawiane, wymagania doprecyzowywane, dzielone, łączone, a ustalenia zapisywane. Chyba największą różnicą pomiędzy poszczególnymi zespołami jest to, że część z nich w ramach tego spotkania estymuje wymagania, a część robi to w innych momentach (np. po Daily Scrum).
Opracowaliśmy też specjalną checklistę, która pomaga ocenić jakość tego spotkania. Możecie się z nią zapoznać w dedykowanym artykule.
Przegląd Sprintu
Z rozrzewnieniem sięgamy dziś pamięcią do pierwszych Przeglądów Sprintów w GetResponse. Z rozrzewnieniem i dumą, patrząc na to jak wiele udało nam się w tej kwestii osiągnąć.
Jak pisaliśmy przy okazji Przeglądu, zaczynaliśmy od podsumowań tygodnia w gronie Menedżmentu i Zarządu. Wprowadzenie zatem otwartego spotkania, na którym Zespół opowiada o tym, co udało się osiągnąć, a co nie, w ramach Sprintu, było prawdziwą rewolucją.
Tutaj zadziałaliśmy radykalnie. Po przeprowadzeniu przez nas dwóch pierwszych spotkań, założyliśmy, że od tego momentu będą za nie odpowiadali całkowicie deweloperzy i Product Owner (rola Scrum Mastera miała być tu zmarginalizowana). Ludzie stanowczo oponowali, tłumacząc, że to nie jest ich rola, że nie na tym polega ich praca. Zespoły podeszły do sprawy różnie – gdzieniegdzie całość prowadzili Deweloperzy, gdzieniegdzie dominował głos Product Ownera. Trzeba było przywyknąć do pełnej transparentności pracy, a także odpowiadania na różne pytania zgromadzonych związane ze zrealizowanymi zadaniami. Oczywiście, wprowadzenie Przeglądu przyniosło też większą mobilizację w Zespołach. Skoro co tydzień trzeba było pokazać efekty pracy, wiadomo było, że szybciej muszą znaleźć sposób na jak najefektywniejszą wewnętrzną organizację.
Od początku dbaliśmy o to, żeby spotkania miały jak największą frekwencję. Pierwsze spotkania wyglądały źle: sztywno, formalnie, niejasno. Pracowaliśmy nad tym na retrospektywach, które zaczynaliśmy od omówienia wrażeń z przeglądu. Początkowe spotkania zniechęcały także samych Interesariuszy i gości, dlatego również z nimi trzeba było pracować – wyjaśniać dlaczego ich obecność jest ważna i prosić o cierpliwość. Z czasem wszystko zaczęło nabierać rumieńców, na Przeglądach padało coraz więcej ciekawych pytań, sugestii, propozycji, a deweloperzy poczuli, jak bardzo ich praca jest ważna i dlaczego. Udało się!
Retrospektywa Sprintu
Retrospektywa jako spotkanie najbardziej “intymne”, wymagające od uczestników wzajemnego zaufania, odwagi, szczerości i otwartości, jest chyba najtrudniejszym do wprowadzenia spotkaniem scrumowym. Stąd zawsze trzeba robić to delikatnie, szczególnie w firmach z długą historią, wieloma projektami, w których osoby, mające “od teraz” ze sobą otwarcie rozmawiać o problemach i wspólnie je rozwiązywać, często stały po przeciwnych stronach barykady, ostro się spierając.
Zdecydowaliśmy się zatem wprowadzić rozwiązanie sprawdzone już przez nas w takich sytuacjach, w Zespołach, w których tak deweloperzy, jak i Product Owner, współpracowali ze sobą w poprzednim modelu pracy: podzielić retrospektywę na dwie części. Pierwszą – w pełnym gronie, drugą – bez udziału Product Ownera. Oczywiście od razu wszystkim komunikowaliśmy przyczyny tej decyzji, a także jasno podkreśliliśmy, że jest to rozwiązanie tymczasowe, do czasu zbudowania pełnego wzajemnego zaufania i w całości wspólnych retrospektyw. Jak poszło? Dobrze! W formule dwuczęściowej najdłużej to spotkanie przetrwało w jednym z zespołów trzy miesiące.
Wspólne zaufanie na linii Product Ownerzy ↔ Deweloperzy, dzięki bardzo dużym chęciom i pozytywnemu podejściu obu stron, udało się szybko zbudować we wszystkich zespołach. Jesteśmy dumni, że dołożyliśmy do tego małą cegiełkę.
Na koniec
Tyle o spotkaniach w kontekście ich ewolucji i roli, jaką ma w nich do odegrania Product Owner. Przeszliśmy daleką drogę, aby ich forma była zgodna ze scrumowymi zasadami i aby móc czerpać płynące z tego profity. To nam się udało, choć tak naprawdę był to dopiero punkt wyjścia do dalszych prac, o których będziemy jeszcze pisać w kolejnych artykułach. Póki co, za miesiąc kończymy nasz cykl, koncentrując się na tym, jak w chwili obecnej wygląda w GetResponse codzienna współpraca Scrum Masterów z Product Ownerami.