Zespół pracuje zdalnie, jest rozproszony po świecie. Developerzy i Scrum Master są w Polsce, wszyscy są zatrudnieni w jednej organizacji. Product Owner jest zarówno w innej strefie czasowej jak i firmie, a między nimi jest dziewięć godzin różnicy. Dzieli ich także język. Sprinty w tym zespole są dwutygodniowe, a Sprint Retrospective odbywa się bez udziału PO. Sprint Planning i Sprint Review często zamykają się w kilkunastu minutach, lub w ogóle się nie odbywają. Dodatkowo zespół nie czuje potrzeby na pochylenie się nad ich jakością.
Takie scenariusze są bardzo powszechne. Zespoły różnie radzą sobie z wyzwaniem stref czasowych oraz dywersyfikacją kultury i języka. Jednak czy sytuacja, w której Sprint Retrospective dzieje się bez Product Ownera jest dobrym pomysłem? Czy jest coś zgubnego w przedstawionym podejściu? Pomijając inne aspekty powyższej historii, które mogą budzić w Was niepokój, skupmy się na Sprint Retrospective bez Product Ownera.
Po co robimy Sprint Retrospective?
Sprint Retrospective to wydarzenie, którego celem jest wspólne “planowanie sposobów na podniesienie jakości i efektywności”. Przez wspólne rozumiemy to, że cały zespół spotyka się, aby sprawdzić jak przebiegał ostatni Sprint pod wieloma względami. Uwzględnia się takie kwestie jak proces, narzędzia, Definicję Ukończenia, relacje w zespole, jakość wykonanej pracy, i wiele innych. Spotkanie może przybrać dowolną formę, jednak jednym z częstszych sposobów na jego realizację jest podążanie za modelem Derby & Larsen. (O tym jak przeprowadzić Sprint Retrospective więcej możecie przeczytać tutaj). Scrum Team dokonuje inspekcji efektywności swojej pracy i zastanawia się co działa dobrze, a co można spróbować zmienić by było jeszcze lepiej. Jest to wydarzenie dla wszystkich odpowiedzialności w Scrum Team, czyli dla Product Ownera, Developerów i Scrum Mastera. Jego ideą, jak zresztą wszystkich innych wydarzeń Scrumowych, jest wsparcie filarów Scruma, poprzez aktywne wykorzystanie jego wartości.
Dlaczego zespół wybiera Sprint Retrospective bez Product Ownera?
Strefy czasowe
Analizując historię ze wstępu historię widzimy, że jednym z oczywistych powodów jest różnica czasu. Biorąc pod uwagę, że Sprint Review, Sprint Retrospective i Sprint Planning powinny odbywać się jedno po drugim, przy Sprincie dwutygodniowym, na cały zestaw powinniśmy zarezerwować sobie około 4-7 godzin. Słowo “około” pojawia się tu celowo, bo tak naprawdę ramy czasowe mają pomóc nam określić maksymalny czas trwania wydarzeń. Każde z nich powinno trwać na tyle długo by udało się zrealizować jego cel.
Może się okazać, że Sprint Planning trwa trzydzieści minut zamiast sugerowanych czterech godzin, o ile, jak to mawia mój tato “wszyscy wszystko wiedzą”. Nie ma sensu przegadywać spotkań. Oczywistym wyzwaniem jest praca w zespołach mocno rozproszonych, kiedy mierzymy się z różnicą czasu, na przykład, dziewięciu godzin. Jedni wtedy muszą pracować do późna, drudzy wstawać bardzo wcześnie.
Wyzwania językowe
Kolejnym aspektem który może wpływać na niechęć organizowania wspólnego Sprint Retrospective jest po prostu bariera językowa. Niech pierwszy rzuci kamieniem ten, kto nie usłyszał kiedyś zdania “po angielsku jakoś tak ciężej wyrazić mi moje myśli”. Wtedy oczywistą pokusą staje się pominięcie Product Ownera, czy jakiegokolwiek innej odpowiedzialności w wydarzeniach. Co z mojej perspektywy skutkuje podziałem zespołu na dwa obozy.
Brak zaufania
Często brak zaufania jest następstwem dwóch powyższych, czyli wyzwań językowych i brakiem czasu na zbudowanie relacji. W bezpiecznym środowisku, kiedy znamy się dobrze, mamy swobodę eksperymentowania i popełniania błędów, z których wyciągamy cenne lekcje pracuje się po prostu lepiej. W zespole, w którym nie ma zaufania, oczywistym jest próba eliminacji, czy też odsunięcia niektórych członków zespołu od uczestnictwa w wydarzeniach. Dodatkowo, w opisanej sytuacji, cegiełką do czynników wpływających na zachwianie czy brak zaufania może być współpraca z PO spoza organizacji. Często powoduje to pewnego rodzaju dyskomfort i jest blokerem w budowaniu relacji. Bywa więc i tak, że organizujemy Sprint Retrospective bez Product Ownera.
Jakie to może nieść następstwa?
Obozy My i Oni
“Oni powiedzieli, oni zrobili”. To może być klasyczne zdanie wypowiadane przez Product Ownera do Scrum Mastera. Lub zupełnie na odwrót “On nam nie powiedział co mamy robić”. Kiedy to Developerzy negatywnie wypowiadają się o PO, nie przekazując mu bezpośrednio swoich obaw czy feedbacku. Pominięcie możliwości dokonania wspólnej inspekcji i adaptacji efektywności pracy często skutkuje stworzeniem dwóch obozów – My i Oni. W teorii pracujemy jako jeden zespół, a praktyce bardzo wiele sobie dopowiadamy. Szukamy drugiego dna w zachowaniu innych i dobudowujemy teorie do naszej narracji. Nie ma wtedy poczucia zespołowości, swobody wypowiedzi.
Brak transparentności i feedbacku
Pracując razem, a jednak osobno, organizując Sprint Retrospective bez Product Ownera, pozbawiamy się możliwości jasnego przekazu naszych uczuć i emocji, i wspólnego usprawniania procesów, które u nas kuleją. Poprzez “obgadywanie” Product Ownera za jego plecami zabieramy mu często możliwość zmiany jego zachowania, czy nawyków, czego oczywistym następstwem jest kontynuowanie złych (z perspektywy reszty zespołu) praktyk. Jak mam wiedzieć, że moje zachowanie i to co robię nie do końca podoba się zespołowi, czy być może nawet utrudnia ich pracę, jeżeli nie dostaje szczerej informacji zwrotnej? Mało kto z nas jest wróżką, która potrafi czytać w myślach. Większość z nas musi usłyszeć szczery feedback żeby wiedzieć nad czym ma pracować.
Brak możliwości dokonywania pełnej inspekcji i adaptacji
Transparentność naszych działań, rozmów i zachowań umożliwia istnienie dwóch pozostałych filarów Scruma, czyli Inspekcji i Adaptacji. Bez niej nie możemy dokonywać pełnego usprawnienia naszych procesów, a jedynie błądzić, trochę po omacku, i szukać rozwiązań niezbyt dobrze zwizualizowanych wyzwań. Praca z wykorzystaniem Scruma polega na wzajemnym zaufaniu, które jest pochodną wszystkich wartości Scruma jak i jego filarów. Bez uczestnictwa jednej z odpowiedzialności w kluczowym dla dokonywania inspekcji i adaptacji wydarzeń nie możemy w pełni dokonywać tych procesów.
Jak temu zaradzić?
Odpowiedź jest prosta – przestać organizować Sprint Retrospective bez Product Ownera. Ktoś mógłby powiedzieć: “Ale jak to? Przecież dalej jest różnica czasowa i bariera językowa?”. Owszem są, ale to dlatego Scrum opiera się na empiryzmie. Właśnie po to żeby eksperymentować, nie bać się wyzwań i potencjalnych niepowodzeń. Powiedzmy sobie szczerze o naszych obawach związanych z językiem, ale nie tylko w polskiej części zespołu, lecz właśnie w całym Scrum Teamie. Stwórzmy sobie tą bezpieczną przestrzeń gdzie odwaga i otwartość, zastępują miejscem lęk i obawę przed niepowodzeniem. Pójdźmy na pewne kompromisy. Być może nie jesteśmy dwoma połówkami jabłka, ale z pewnością możemy wypracować wiele, by wzajemnie dopasować się do siebie. Raz jedni mogą wstawać bardzo wcześnie, raz drudzy kończyć pracę później. Takie dopasowywanie się, co dwa tygodnie, powinno być naszą naturalną postawą jako zaangażowanych specjalistów. Pamiętajcie, że to dzięki wspólnym rozmowom będziemy mogli skupić się nad tym co dla naszego Scrum Teamu i produktu jest najważniejsze, a nie szukać drugiego dna.
Aha i jeszcze jedno! Jeżeli boicie się ciągłej obecności PO w życiu całej reszty zespołu wprowadzajcie zmiany stopniowo. Scrum Masterze – zorganizuj pierwsze wspólne Sprint Retrospective, wytłumacz cel i potrzebę. Następne zespołowe usprawnianie może odbyć się za jakiś czas. Dostosujcie tempo zmian to potrzeb waszego zespołu.
Na koniec chciałabym Was zostawić ze stwierdzeniem, które królowało u jednego z moich zespołów: “Over communication is always better than lack of communication”.
Sprawdź nasze ostatnie wpisy:
- Rozgrzewka przed retrospektywą
- #WTMDareToBe i Agile Hunters już 26 kwietnia we Wrocławiu!
- Po co Product Ownerowi Kanban?
