Tym wpisem kończymy nasz cykl przedstawiający współpracę Scrum Masterów z Product Ownerami w GetResponse, od samego początku – momentu wprowadzenia tych ról, ustalenia zasad współpracy i wzajemnych oczekiwań – po dzień dzisiejszy.
Do tej pory skupiliśmy się na przeszłości, opisując krok po kroku jak zmienialiśmy sposób współpracy IT z działem Product Development i budowaliśmy platformę współdziałania pomiędzy nami a PO. Wcześniejsze artykuły omawiały nasze wsparcie w zakresie:
- wprowadzenia roli Product Ownera – jakie szkolenia organizowaliśmy i organizujemy,
- wprowadzenia spotkań scrumowych – zmiany sposobu codziennej pracy w zespołach deweloperskich i nowych wyzwań dla Product Ownerów.
Nadszedł w końcu czas na zobrazowanie stanu obecnego i krótkie podsumowanie całości.
Od momentu rozpoczęcia naszej pracy w firmie, liczba Scrum Masterów i Product Ownerów wzrosła dwukrotnie. Mamy coraz więcej zespołów rozwijających nasz produkt, w konsekwencji powstaje coraz więcej wzajemnych zależności i coraz więcej działań międzyzespołowych. Przy skoku, który nastąpił, bardzo ważne są mocne podstawy – jeżeli proces nie funkcjonuje na poziomie fundamentów, ciężko konstruować złożone produkty i z sukcesem prowadzić większe działania.
Kiedy przyjrzymy się wzorowym, najlepszym zespołom pracującym w agile’u, to jedną z ich newralgicznych cech jest to, że tworzą go nie sami deweloperzy, ale także Product Owner i Scrum Master. A zatem, gdy mamy klasyczny Zespół Scrumowy. Co oznacza, że jeśli osoby pełniące dwie główne scrumowe role nie nadają na tych samych falach, kiepsko współpracują lub choć jedna z nich nie wykonuje swojej roboty dobrze, z pewnością odbije się to w znaczący sposób na sposobie funkcjonowania zespołu deweloperskiego i jakości jego pracy.
Co wobec tego jest naszym zdaniem kluczowe przy współpracy wspomnianej dwójki? Wytypowaliśmy cztery najważniejsze czynniki.
Ustalenie wzajemnych oczekiwań
Niektórzy mogą być tu zdziwieni – po co? Przecież wydaje się to oczywiste. Tymczasem nasze doświadczenie wskazuje, że brak realizacji tego punktu jest jednym z głównych źródeł problemów. Przewodnik po Scrumie czy firmowe praktyki to jedno – dobrze je poznać. Ale każdy Scrum Master i każdy Product Owner powinni dostosować i dopracować te ogólne zasady do zespołu, w ramach którego pracują. Od tematów najbardziej błahych, typu: ustalenie dat cyklicznych spotkań scrumowych czy zasady dodawania zadań w backlogu, po trudniejsze – czy PO powinien być na daily, czy powinien siedzieć w pokoju razem z zespołem, czy Scrum Master powinien partycypować w tworzeniu planów na kolejne sprinty. I tak dalej, i tak dalej.
To, że będziecie mieli spotkanie organizacyjne na początku wspólnej pracy, jest oczywiste. Mniej oczywiste jest już to, żeby ustalić na nim jasne, podstawowe, wzajemne oczekiwania w stosunku do siebie. W jakich obszarach Product Owner szczególnie mocno oczekuje wsparcia Scrum Mastera – czy tylko w zakresie budowania dobrze funkcjonującego zespołu deweloperskiego, czy, przykładowo, również w procesie tworzenia wizji produktu, zarządzania backlogiem i tworzenia planów na Sprinty. Czy chce, żeby Scrum Master pomagał mu w rozmowach z Interesariuszami albo wspierał go w zdobywaniu wiedzy ze zwinnego rozwijania produktu czy preferuje całkowicie samodzielne działania w tym zakresie.
Z kolei Scrum Master powinien określić co, oprócz wizji, backlogu i odpowiedzi na pytania biznesowe, Product Owner powinien wnieść do zespołu, jakie są oczekiwania wobec niego. Warto omówić jakie wartości są szanowane w zespole (np. bycie dostępnym dla zespołu i zainteresowanie efektami jego prac, bycie zawsze przygotowanym, zaangażowanie, szczerość), a jakie zachowania mogą powodować niesnaski.
Rzeczy do omówienia będzie dużo, stąd na początku, w fazie wzajemnego “docierania się” trzeba jak najwięcej rozmawiać. Rozszerzymy ten wątek w kolejnym punkcie.
Codzienna współpraca i budowanie relacji
Po ustaleniu początkowych oczekiwań, należy – tu zaskoczenie – działać zgodnie z zasadami scrumowej inspekcji i adaptacji. Nieustannie wymieniać się spostrzeżeniami czy informacjami dotyczącymi zespołu i produktu, które gdzieś się pojawiły. Informować się o zadaniach zgłoszonych do backlogu, uwagach od klientów czy interesariuszy, bieżących planach, propozycjach, pomysłach. Dbać o to, by zawsze się wzajemnie informować o wydarzeniach z życia zespołu i produktu. Linia komunikacyjna Scrum Master ↔ Product Owner powinna być rozgrzana do czerwoności. Niekoniecznie trzeba ku temu organizować dedykowane spotkania, często wystarczy bieżąca wymiana informacji na komunikatorze, przy kawie czy gdzieś mimochodem. Czasem warto rozważyć sformalizowane, “wbite w kalendarz” cykliczne spotkanie, żeby po prostu mieć zawsze okienko czasowe, aby móc porozmawiać, o zespole, o backlogu, o współpracy czy o tym, że znowu przyszła zima i trzeba odśnieżyć samochód.
Częstym błędem w budowaniu tej relacji od strony Scrum Masterów jest zbyt dosłowne wzięcie do siebie drugiego członu nazwy stanowiska i stawianie siebie w roli Mastera w stosunku do PO. Działanie wedle wizji “słuchaj mnie, bo ja się znam na agile”, nie bacząc na doświadczenie, wiedzę drugiej osoby czy stawianie się w roli ważniejszego, szczególnie przed zespołem.
Z drugiej strony, Product Ownerzy często zapominają o tym, że Scrum Master powinien być w stanie wesprzeć ich także w ich codziennej pracy koncepcyjnej, priorytetyzacji, decyzjach, po prostu w rozwijaniu obszaru, za który odpowiadają. Ważką sprawą w pełnieniu funkcji Scrum Mastera jest to, żeby pamiętać, że pełni on ją tak samo w stosunku dla PO, jak dla zespołu deweloperskiego i obie “strony” powinien traktować z równą atencją, żadnej nie faworyzując.
Poprzez częste rozmowy trzeba budować zaufanie i dobrą relację. To oczywiste, że chemia w tym duecie nie zawsze się pojawi. Mocno pomoże, ale nie jest konieczna, czasem wystarczy szorstka przyjaźń. O czym w kolejnym akapicie.
Wzajemne wsparcie i pilnowanie
Co nam mówi Przewodnik po Scrumie?
- Właściciel Produktu jest odpowiedzialny za maksymalizację wartości produktu i pracy Zespołu Deweloperskiego.
- Scrum Master jest odpowiedzialny za promowanie i wspieranie stosowania Scruma. [Jego rolą jest – dop. GR Scrum Masters] maksymalizować wartość wytwarzaną przez Zespół Scrumowy.
Ważne jest, żeby o tym pamiętać. Po pierwsze, żeby wspólnie rozwiązywać problemy, działać w duecie, jak bliźniaki w słynnym filmie z J.C. Van Dammem. Product Owner i Scrum Master powinni od samego początku współpracy działać jak najbliżej, stworzyć swoisty tandem, wspólnie eliminujący od różnych stron wszelkie przeciwności i tworzyć środowisko, w którym zmotywowany zespół może tworzyć produkt wysokiej jakości w dobrym tempie i przyjaznej atmosferze.
Po drugie, będąc dla siebie codziennym wsparciem, trzeba wzajemnie pilnować siebie w zakresie obowiązków. Zaniedbanie ich, tak jak wspominaliśmy, znacząco odbije się na zespole. Scrum Master przechodzący obojętnie obok wymagań złej jakości, braku wizji i planu działania na więcej niż sprint do przodu czy “martwego” backlogu, jest tak samo zły, jak Product Owner, który nie reaguje na powtarzające się w zespole te same błędy albo na to, że Scrum Master pracuje tylko i wyłącznie z deweloperami, a do niego tylko ma konkretne wymagania.
Wspólny front dla zespołu
Ostatnia zasada jest fundamentalną w tej współpracy. Nie ma nic gorszego niż Scrum Master kontestujący przy zespole to, co mówi Product Owner i odwrotnie. Sprzeczne informacje do deweloperów, próba przeciągania ich na swoją stronę (Scrum Masterzy zawsze mają tu naturalną przewagę – są bliżej zespołu), to zawsze powoduje problemy.
Istotnym jest, żeby przed zespołem trzymać zawsze wspólny front i wzajemnie się nie zaskakiwać. Do tego konieczny jest wcześniej omawiany przebieg informacji.
Kluczowe jest to, żeby osoby w obu tych rolach były autorytetem i wzorem dla zespołu. Żeby to osiągnąć, konieczna jest ich dobra współpraca, a indywidualnie – ich codzienna postawa i podejście do obowiązków.
Co dalej?
Jak idzie nam powyższe w naszych kilkunastu zespołach? Śmiało możemy zaryzykować stwierdzenie, że naprawdę dobrze. Na poziomie współdziałania poszczególnych osób bywa i rewelacyjnie, ale i “zaledwie” nieźle. Jakiś czas temu pisaliśmy o ankiecie, którą corocznie przeprowadzamy dla naszych deweloperów. Ponad rok temu przygotowaliśmy podobną ankietę dla Product Ownerów, dotyczącą współpracy z nami i z zespołami. Chcieliśmy spróbować w ten sposób zebrać obraz całości. W chwili obecnej jesteśmy już dojrzalsi, bardziej doświadczeni, lepiej się wzajemnie poznaliśmy i stawiamy na bezpośrednią współpracę. Jesteśmy w stanie o coraz większej ilości tematów rozmawiać otwarcie.
Pojawiły się też pierwsze inicjatywy wyjść integracyjnych Product Ownerów ze Scrum Masterami, a także cykl spotkań, mający być miejscem na wymianę dobrych praktyk i zyskania inspiracji, opowiedzenia “jak to robimy w zespole X”, ale także przestrzenią na pytania, problemy, spostrzeżenia.
Wciąż powstają nowe pomysły, coraz lepiej się poznajemy i współpracujemy. Wszystko to powoli dojrzewa i przynosi coraz lepsze owoce.