Wielokrotnie, w niejednej organizacji, obserwowaliśmy podobną sytuację. Zwinność zaordynowana w dziale IT, Scrum Masterzy całkowicie skupieni na pracy w nowo powołanych zespołach deweloperskich, patrzący na wszystko z jednego punktu widzenia. Reszta firmy ma porzucić dotychczasowy sposób działania, zachwycić się “agile’owością”, szybko zrozumieć nowe zasady i się do nich dostosować.
Należy szybko powołać Product Ownerów, przeszkolić ich co mają robić i pilnować, żeby za bardzo nie przeszkadzali. Przerysowane? Niekoniecznie, źródło nieudanych transformacji często tkwi w takim właśnie początku, a agile wychodzący z IT i narzucany reszcie firmy, często staje się zarzewiem ostrych sporów.
Nawet jeśli nie idzie to aż tak daleko, niejednokrotnie można zaobserwować podobny symptom, zwiastujący późniejsze trudności. Objawia się to tym, że Scrum Masterzy pracują wyłącznie z zespołami deweloperskimi, poświęcając im 100% swojego czasu. Product Ownerzy, Biznes znajdują się daleko poza obszarem ich zainteresowań. Ba, częstokroć tacy Scrum Masterzy są zaskoczeni, kiedy przypomina im się, że Przewodnik po Scrumie wyraźnie wskazuje, że powinni pracować w trzech obszarach: Zespół Deweloperski, Product Owner, organizacja. Tu i ówdzie panuje mylne przekonanie, że należy to realizować w kolejnych etapach, a zatem Product Ownerów wspieramy dopiero, kiedy mamy sprawnie działające Zespoły Deweloperskie, a działaniami ogólnofirmowymi zajmujemy się na samym końcu…
Mając świadomość tego wszystkiego, w GetResponse od samego początku postawiliśmy na pracę z Biznesem na równi z IT. Zadanie mieliśmy o tyle ułatwione, że pewne procesy zaczęły dziać się już wcześniej, zanim przyszliśmy do firmy i rozpoczął się proces transformacji agile. Duża praca została już wykonana, przy zgodnym współudziale obu stron, zatem przedpole było przygotowane. Wyjaśniono sobie nieporozumienia, zaczęto zwracać baczniejszą uwagę na dobrą komunikację, wprowadzono zalążki spotkań Scrumowych (Planowanie, Retrospekcja), stworzono Backlog, wdrożono nowe narzędzia ułatwiające codzienną prace. Nam pozostało to dopracować i rozkręcić.
W swoich działaniach z Product Ownerami od samego początku postawiliśmy na bliską i ciągłą współpracę, wymianę doświadczeń i edukację w zakresie zwinności. Zdecydowaliśmy się zmiany wprowadzać spokojnie, krok po kroku, mając cały czas w głowie plan długofalowy. Jak to w Gdańsku: nec temere, nec timide.
Jak wyglądało to w praktyce? Przedstawimy to w kilku częściach, w tej skupiając się na komunikacji z Zarządem i szkoleniach.
Komunikacja z Zarządem i Managementem
Wprowadzenie agile’a, to zawsze rewolucja, jakkolwiek ewolucyjnie chcielibyśmy to robić. W związku z tym istotne jest, aby wszyscy znali i zaakceptowali zasady gry. Stąd też na początku spotkaliśmy się z Dyrektorem działu Product Development, aby omówić oczekiwania, plany, obawy i potencjalne problemy, związane z wprowadzeniem w firmie nowego sposobu pracy. Wszak Product Owner miał się stać w firmie zupełnie nową rolą, z całkowicie nowymi zadaniami, sposobem pracy, odpowiedzialnością. Co więcej, praca w takiej roli wymaga dużej ilości czasu poświęconej Zespołowi Deweloperskiemu i Backlogowi, w konsekwencji może tego czasu zabraknąć na inne nominalne prace, dotychczas wykonywane w roli “Product Manager”.
Przedstawiliśmy zatem naszą wizję i pomysły, które zostały omówione i zaakceptowane. Przedyskutowaliśmy dokładnie oczekiwania w stosunku do roli Product Ownera, a wkrótce pierwsze osoby rozpoczęły prace w takiej właśnie roli. Później – każdorazowo dbaliśmy o to, żeby informować Zarząd i Menedżment o naszych nowych inicjatywach w tym obszarze.
Mając zielone światło i poparcie od Zarządu, wiele potencjalnych przeszkód zostało rozwiązanych w zalążku, pozostało nam tylko zakasać rękawy do roboty i działać.
Szkolenia wewnętrzne i zewnętrzne
Jeszcze przed wprowadzeniem nowego sposobu pracy, Menedżment zadbał o wyedukowanie Działu Biznesowego z podstaw Scruma i agile’a – było to szkolenie zewnętrzne. Dobre podstawy teoretyczne były zatem zapewnione, naszą rolą było przede wszystkim przekuć to w konkretne działania i profity w kontekście naszej organizacji.
Na samym początku sporo czasu poświęciliśmy na opracowanie własnych, autorskich szkoleń, których celem było praktyczne przygotowanie do pracy w roli Product Ownera w GetResponse.
Charakterystyka tej roli, wizja rozwoju produktu, tworzenie dobrych wymagań, codzienna praca z Backlogiem, praca z Zespołem Deweloperskim i Scrum Masterem, Impact Mapping, MVP, MMP – to tylko część poruszanych tematów. Ruszyliśmy w formacie półtoragodzinnego spotkania w cyklu miesięcznym, zaprosiliśmy na nie praktycznie cały Biznes, nie tylko osoby, które miały pracować jako PO.
Kiedy je zaczynaliśmy, pracowaliśmy w firmie ledwie trzy miesiące, nie znaliśmy jeszcze ludzi, mieliśmy jeszcze mgliste pojęcie o tym, jak działa Biznes, co wypracowano, jak próbowano działać wcześniej, jakie są problemy. Pierwsza edycja (niedawno odbyła się druga, dla nowych Product Ownerów) była zatem jeszcze mocno “teoretyczna”, oderwana od realiów firmy, bazująca na naszych wcześniejszych doświadczeniach. Miało to niemało zalet, ale wad było więcej. Brak konkretnych odniesień do rzeczywistości w GetResponse spowodował, że szkolenie wyraźnie nie było wciągające, a uczestnicy mieli do niego widoczną rezerwę, charakterystyczne fajne, ciekawe, ale u nas to… W efekcie z czasem wyraźnie spadła frekwencja. Zorientowaliśmy się wówczas, że musimy przekształcić jego formułę w bardziej warsztatową. Tak, aby mocniej zaangażować uczestników, a zarazem pozwolić im lepiej poczuć omawiane zagadnienia.
Krok po kroku do sukcesu
Stąpaliśmy po niepewnym gruncie, lecz stopniowo przełamywaliśmy wzajemne bariery. Korzystaliśmy z powszechnie dostępnych ćwiczeń, jak Lądowanie na Księżycu czy User Stories vs Requirements, wymyśliliśmy też własne. Agile ZOO i Crazy Blocks – dwie gry, z których stworzenia jesteśmy szczególnie dumni – powstały, aby pomóc uwidocznić i rozwiązać rzeczywiste problemy, z którymi zaczęli borykać się nasi Product Ownerzy. Było coraz lepiej, coraz ciekawiej, przynosiło to coraz większą wartość. Uczestnicy byli coraz bardziej otwarci, zaczęli poruszać problemy, które sami mają, dzielić się swoimi opiniami. Sami dużo się nauczyliśmy, zyskując odmienną perspektywę, słuchając wielu ciekawych spostrzeżeń. Wchodziliśmy w ciekawe dyskusje, momentami wręcz ostre spory. W efekcie wiele z naszych przeświadczeń runęło jak domek z kart. I musieliśmy szukać innych pomysłów, rozwiązań, dostosowanych do sposobu pracy i działania GetResponse. A dotyczyło to zarówno rzeczy małych, jak i dużych, jak przykładowo obecność Product Ownerów na Daily Scrum czy sposób i moment “odbierania”, weryfikacji realizowanych zadań.
Przy okazji spotkań, które odbywały się na przestrzeni roku, zbudowaliśmy w firmowym Confluence pokaźną bazę wiedzy – artykułów, prezentacji, filmów, książek, dogłębnie prezentujących dane zagadnienia.
Szkoleń ciąg dalszy…
Kolejna edycja szkoleń, realizowana dwa lata po poprzedniej, wyglądała już zupełnie inaczej. Ten sam materiał był już omawiany całkowicie z punktu widzenia GetResponse, a każdy slajd okazał się pretekstem do omówienia zebranych już dotychczas doświadczeń. Różnica była wyraźnie widoczna, a kurs bezboleśnie i niemalże natychmiast pozwalał rozpocząć prace w Zespole Scrumowym jako Product Owner, co potwierdzają sami uczestnicy.
Następnym krokiem było zorganizowanie – dla chętnych – kursu przygotowującego pod certyfikat Professional Scrum Product Owner I. Część z nas miała już doświadczenie w prowadzeniu tego typu zajęć, stąd wiedzieliśmy na czym trzeba się skupić, jakie tematy poruszyć. Jak się okazało, zagadnienia, mimo że często omawiane typowo “pod egzamin”, stały się zalążkiem ciekawych dyskusji, wymiany doświadczeń. Dzięki temu zyskaliśmy platformę wymiany wiedzy i dobrych praktyk pomiędzy uczestnikami. A osoby, które przystąpiły do certyfikacji, oczywiście ją uzyskały z bardzo dobrym rezultatem.
Niedawno ruszyliśmy też z kolejną edycją dłuższych szkoleń, odbywających się tym razem co dwa tygodnie. Temat przewodni to tworzenie dobrych wymagań i praca z Backlogiem – wspólnie z Product Ownerami uznaliśmy bowiem, że te obszary wymagają większej uwagi, tak przypomnienia i uporządkowania podstaw, jak i zbudowania od nowa bazy dobrych praktyk w tym zakresie, a także przedstawienia pewnych wspólnie wypracowanych standardów (o których w następnym artykule). Tym razem przygotowywaliśmy je wspólnie z Product Ownerami, a także działem UX. Wyraźnie widać na nim owoce wcześniejszych “kursów”, wszyscy uczestnicy są niezwykle aktywni w dyskusjach, a Scrum Master nie jest osobą dominującą, prowadzącym, a bardziej – uczestnikiem i moderatorem dyskusji.
Realizowaliśmy i wciąż realizujemy też niemało krótszych, jednorazowych warsztatów. Zadbaliśmy o solidne wprowadzenie i pokazanie dobrych praktyk pracy z narzędziami, które miały nas wspierać w codziennej pracy (JIRA, Confluence). Przeszkoliliśmy też wszystkich interesariuszy (księgowość, administracja, obsługa klienta etc.) poszczególnych Zespołów Scrumowych – przedstawiliśmy im podstawy agile’a i Scruma oraz zasady zgłaszania wymagań do Backloga i pracy z Product Ownerami.
Podsumowanie
Wszystkie wymienione szkolenia opracowywaliśmy sami, wymaga to niemałego wysiłku i poświęcenia sporej ilości czasu. Zwraca się to jednak z nawiązką – tak dla uczestników, jak i dla nas, zespołu Scrum Masterów. O tym, do czego doprowadziły nas te działania, a także o naszych kolejnych inicjatywach na polu współpracy z Biznesem, już w kolejnym tekście.