Z pewnym niepokojem obserwuję niezmiennie wysoką liczbę osób, które pracują w Scrumie, a dla których oczywistością jest, że moderatorem – i często gospodarzem zdarzeń stanowiących elementy tej metody – jest Scrum Master.

Wynika to niekiedy z błędnego tłumaczenia angielskiego słówka facilitate, którego polskim odpowiednikiem byłoby bardziej ułatwiacz niż moderator. Ten facylitator wspiera moderatora tam, gdzie jest to niezbędne, ale nie jest gospodarzem ani prowadzącym spotkanie.

Dużo częściej przekonanie o obowiązku Scrum Mastera bycia moderatorem bierze się z niewłaściwej interpretacji zapisów Scrum Guide, wedle której Developerzy nie powinni robić niczego, co nie jest związane z wytwarzaniem produktu. A zatem to Scrum Master ma im zorganizować, a potem poprowadzić każde spotkanie. Tymczasem Scrum nie bez przyczyny nazywa je zdarzeniami, albowiem stanowią one taką samą pracę, jak budowanie czy testowanie produktu. Bez tych spotkań-zdarzeń nie da się dobrze odpowiedzieć na potrzeby biznesowe, więc siłą rzeczy stanowią część pracy developerskiej; niekoniecznie to Scrum Master ma je organizować i moderować. A wręcz nie powinien tego robić, jeśli z jakiegoś dobrego powodu nie musi.

Kolejny powód, dla którego Scrum Master bywa obarczany rolą stałego moderatora to przekonanie, że w ten sposób wspiera Zespół w usuwaniu utrudnień i rozwiązywaniu problemów. Cóż, Developerzy mówiący, że konieczność zrozumienia wymagań i zdefiniowania dla nich kryteriów akceptacyjnych stanowi dla nich jakieś utrudnienie i problem, to… Może lepiej pozostawmy to bez komentarza.

Po rozmowie z osobami przekonanymi, że Scrum Master musi być moderatorem, najczęściej pojawia się refleksja, że źle zrozumiały one istotę tej odpowiedzialności w Scrumie. A drążąc temat nieco głębiej, udaje się odkryć, że rzeczony Scrum Master dał się wtłoczyć nie tyle w obowiązki wodzireja, ile sekretarza i asystenta biurowego Zespołu, bo pilnuje terminów, rezerwuje salki, załatwia pisaki do tablic suchościeralnych, zamawia pizzę na lunch i tak dalej. Smutne, ale jakże częste.

„Nie jest moderatorem, ale Retrospekcję musi prowadzić”

Zespoły stosunkowo łatwo przekonać, że Developerzy mogą zorganizować sobie Daily Scrum bez Scrum Mastera i że może bez jego moderacji odbyć się efektywne Planowanie Sprintu. Nie ma też konieczności długiego przekonywania Zespołów, że to Product Owner jest naturalnym gospodarzem Przeglądów Sprintu. Zupełnie inaczej dzieje się, gdy dyskusja dotyczy Retrospekcji Sprintu. Zdaniem ogromnej większości Zespołów i równie wielu Scrum Masterów, odpowiedzialność za przygotowanie i moderowanie Retrospekcji spoczywa na Scrum Masterze. To on powinien je organizować i prowadzić, bo… no, właśnie, czemu?

Retrospekcje służą usprawnieniu procesu, narzędzi, komunikacji, praktyk – wszystkiego, co pozwala Zespołowi Scrum jako całości działać i realizować cele, jakie przed nimi stawiają interesariusze. Wszyscy czują, że Retrospekcje są istotne, a jednocześnie różnią się od pozostałych zdarzeń w Scrumie, bo dotyczą nie produktu, ale Zespołu. To rodzi przekonanie, że wyjątkowość wymaga kogoś innego do moderowania spotkania, bo jakżeby Developer albo Product Owner mógł to zrobić? Wszak do poprowadzenia Retrospekcji potrzeba magicznych umiejętności scrum-masterskich.

Retrospekcja jest rzeczywiście wyjątkowa

Jest wyjątkowym zdarzeniem w Scrumie między innymi z racji tego, w jakim charakterze pojawia się na niej Scrum Master. Zaraz wyjaśnię dlaczego.

We wszystkich pozostałych zdarzeniach Scrum Master bierze udział po to, by być Scrum Masterem i działać jako Scrum Master, a więc wspierać Zespół, a czasami i interesariuszy w osiągnięciu celu, dla którego dane wydarzenie zostało zdefiniowane. Gdy trzeba, przypomina o upływie czasu, o konieczności skupienia się na celu, a czasami wręcz musi przeprowadzić szybki trening i zaprezentować sposób użycia jakiejś praktyki. Inaczej mówiąc, dąży do zapewnienia maksymalnej skuteczności Zespołu.

Natomiast w Retrospekcji Sprintu wszyscy (Product Owner, Scrum Master i Developerzy) uczestniczą po prostu jako członkowie Zespołu Scrum. Choć bez wątpienia ich spostrzeżenia odnośnie do Sprintu i pracy Zespołu są mocno związane z odpowiedzialnościami, jaką na siebie wzięli, Retrospekcja nie jest „spotkaniem odpowiedzialności” tylko spotkaniem ludzi. Niewykluczone, że momentami Scrum Master będzie musiał działać jako Scrum Master, ale jeśli to możliwe, jest po prostu uczestnikiem. Na dokładnie takich samych prawach jak pozostali. Z dokładnie takim samym celem, jaki przyświeca pozostałym.

Jeśli nie Scrum Master to kto?

„Prowadzenie Retrospekcji” to tak naprawdę semantyczne nadużycie. Idealny model to taki, w którym Retrospekjcę prowadzi cały Zespół, albo rotując rolę moderatora, albo wręcz obchodząc się bez niej. Można też poprosić zaprzyjaźnionego Scrum Mastera z innego Zespołu, by pomógł poprowadzić Retrospekcję. Lub Agile coacha, jeśli takiego kogoś mamy w organizacji.

W mojej skromnej ocenie konieczność prowadzenia Retrospekcji przez doświadczonego Scrum Mastera jest jednym z objawów niedojrzałości Zespołu, w tym i samego Scrum Mastera. Należy dążyć, by dojrzałość tę zwiększyć (być może, poprzez efektywne Retrospekcje, a jakże!). Bo przecież istotą Retrospekcji jest poszukiwanie usprawnień. Gdyby umiejętność usprawniania zależała wyłącznie od osoby, która moderuje dyskusję w czasie spotkania, Zespół bez niej nic nie udoskonali.

Egzamin maturalny dla Scrum Masterów

Organizacje rozpoczynające dopiero pracę w metodzie Scrum boją się zmarnować okazję do usprawnień, dlatego pojawia się presja na Scrum Masterów, by to oni pilnowali, aby Retrospekcje były efektywne. A jeśli są niedoświadczeni – w szczególności, gdy dopiero zaczynają pracę jako Scrum Masterzy – zastępuje się ich Agile coachem, albo innym bardziej doświadczonym Scrum Masterem. W założeniu kierownictwa podejmującego takie decyzje ma to dać nowicjuszom wzór do naśladowania i przykład, jak ma wyglądać „porządna Retrospekcja”. Egzaminem dojrzałości w tym modelu jest przejęcie przez niedoświadczonego Scrum Mastera roli moderatora w tym zdarzeniu.

Brak doświadczenia scrum-masterskiego nie jest wcale przeciwwskazaniem do poprowadzenia Retrospekcji, ponieważ tego typu zdarzenie jest praktyką stosowaną nie tylko w Scrumie. Korzystają z niego projekty tradycyjne, a nawet całe organizacje. W wielu z nich Scrum Masterów przecież najczęściej nie ma, a mimo to retrospekcje (małą literą, bo tym razem nie chodzi o nazwę zdarzenia w Scrumie) bywają bardzo skuteczne.

A zatem zamiast doświadczonego Scrum Mastera potrzeba przede wszystkim zaangażowanych uczestników i dobrego moderatora (jeśli faktycznie jest niezbędny). Jasny cel, chęć jego osiągnięcia i zrozumienie, po co zdarzenie się odbywa, to klucz do sukcesu.

Starannie zaplanowana improwizacja

Przyjmijmy, że Scrum Master nie musi prowadzić Retrospekcji, ale często to robi, by użyć ich jako narzędzia do pracy z Zespołem. Czy to dobry pomysł? Bez wątpienia tak, pod warunkiem, że nie staje się to rutyną i czasami zdarzenie obywa się bez moderatora lub jest nim kto inny.

Użycie Retrospekcji jako narzędzia wymaga pewnej biegłości, którą zdobywa się wraz z doświadczeniem. I nie, nie przeczę w ten sposób tezie postawionej wcześniej: czym innym jest moderowanie spotkania (do czego doświadczenie nie jest niezbędne), a zupełnie czymś innym jest wykorzystywanie tych spotkań do stymulowania rozwoju Zespołu.

W tym drugim przypadku brak doświadczenia może skutkować próbami pójścia na żywioł, bez zastanowienia się, jaką strukturę powinno mieć zdarzenie, jakich praktyk i ćwiczeń można użyć w czasie dyskusji, jak zadbać o osiągnięcie celu Retrospekcji…

A im bardziej Scrum Master jest doświadczony, tym staranniej unika improwizacji (choć jednocześnie potrafi wykorzystać nadarzające się okazje i spontanicznie na nie reagować). Jako ekspert poradzi sobie z poprowadzeniem wartościowej Retrospekcji ad hoc, ale wie, że wartość, jaką zdarzenie przyniesie, będzie wtedy ograniczona, a samo spotkanie może mieć bardzo schematyczny i zniechęcający dla uczestników przebieg.

Jeśli zatem jesteś niedoświadczonym Scrum Masterem, nie czekaj, aż będziesz gotowy, by moderować Retrospekcje Sprintów. Po prostu zacznij to robić, a ekspertów lub coachów użyj jako wsparcia. Mogą być twoimi mentorami, doradcami, lub coachami właśnie. Gromadź doświadczenia i dziel się nimi z Zespołem. Naucz ich tego, co sam już umiesz – może będą w stanie poprowadzić Retrospekcję (ale nie zmuszaj ich do tego!), a wtedy ty weźmiesz w niej udział jako uczestnik, dzieląc się z innymi swoimi obserwacjami i proponując usprawnienia.