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 jest niedopuszczalną nadinterpretacją, że 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ń” nie da się dobrze odpowiedzieć na potrzeby biznesowe, więc siłą rzeczy stanowią część pracy developerskiej; niekoniecznie Scrum Master musi je organizować i moderować. A wręcz nie powinien tego robić, jeśli z 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 zdefiniowanie dla nich kryteriów akceptacyjnych to utrudnienie i problem… 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ć”

Względnie łatwo o zaakceptowanie przez Zespoły stwierdzenia, ż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 na Przeglądach 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 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 pojawia się 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 i 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 managementu 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. Tam Scrum Masterów przecież najczęściej nie ma, a mimo to retrospekcje (małą literą, bo niekoniecznie są to zdarzenia Scrum) 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. Jego brak 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… Im bardziej Scrum Master jest doświadczony, tym bardziej unika improwizacji, choć jednocześnie potrafi wykorzystać nadarzające się okazje i spontanicznie na nie reagować.

To prawda, że ekspert poradzi sobie z poprowadzeniem Retrospekcji ad hoc, ale wartość, jaką takie zdarzenie przyniesie, może być nieco 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.