Blog

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 facilitator 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 kodowanie 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ć.

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 roli. A drążąc temat nieco głębiej udaje się odkryć, że rzeczony Scrum Master dał się wtłoczyć nie tyle w obowiązki „wodzireja”, co 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 retrospektywę musi prowadzić

O ile względnie łatwo o zaakceptowanie, że developerzy mogą zorganizować sobie Daily Scrum lub planowanie sprintu i poprowadzić je bez Scrum Mastera, i o ile najczęściej to Product Owner jest gospodarzem na przeglądach sprintu, o tyle brak chętnych do organizowania i moderowania retrospektyw. Te ma prowadzić Scrum Master, bo… no właśnie, czemu?

Retrospektywy służą usprawnieniu procesu, narzędzi, komunikacji, praktyk – wszystkiego, co pozwala zespołowi scrumowemu jako całości działać i realizować cele, jakie przed nimi stawia Product Owner. Wszyscy czują, że są one istotne, a ta ich wyjątkowość wymaga kogoś „innego” do moderowania spotkania. Bo jakżeby developer mógł to zrobić, do tego trzeba magicznych umiejętności scrum-masterskich.

Retrospektywa jest rzeczywiście wyjątkowa

I to między innymi z racji tego, w jakiej roli pojawia się na niej Scrum Master. Zaraz wyjaśnię dlaczego.

We wszystkich pozostałych zdarzeniach poza retrospektywą Scrum Master pojawia się po to, by „być i działać jako Scrum Master”, a więc wspierać zespół i Product Ownera, 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.

Natomiast w retrospektywie wszystkie trzy role (Product Owner, Scrum Master i Zespół Developerski) uczestniczą po prostu jako członkowie zespołu scrumowego. 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” retro to tak naprawdę semantyczne nadużycie. Idealny model to taki, w którym retrospektywy prowadzi cały zespół, albo rotując rolę moderatora, albo wręcz obchodząc się bez tej roli. Można też poprosić zaprzyjaźnionego Scrum Mastera z innego zespołu, by pomógł poprowadzić retrospektywę. Lub Agile Coacha, jeśli takiego kogoś mamy w organizacji.

W mojej skromnej ocenie konieczność prowadzenia retrospektywy przez doświadczonego Scrum Mastera jest jednym z objawów niedojrzałości zespołu i należy dążyć, by tak nie było (być może, poprzez retrospektywę, a jakże!). Bo przecież istotą retrospektywy jest poszukiwanie usprawnień. Gdyby umiejętność usprawniania zależała od osoby, która moderuje dyskusję na retrospektywie, 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 retrospektywy były efektywne. A jeśli są niedoświadczeni, w szczególności gdy dopiero zaczynają pracę w tej roli, zastępuje się ich a to Agile Coachem, a to 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ądne retro”. 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 retrospektywy, ponieważ to zdarzenie jest praktyką stosowaną nie tylko w Scrumie. Korzystają z niego projekty tradycyjne, całe organizacje, nawet te niezwiązane z wytwarzaniem oprogramowania. Tam Scrum Masterów przecież nie ma, a retrospektywy bywają bardzo skuteczne.

A zatem zamiast „doświadczonego Scrum Mastera” potrzeba przede wszystkim dobrego moderatora i zaangażowanych uczestników. Jasny cel i zrozumienie, po co zdarzenie się odbywa, to klucz do sukcesu.

Starannie zaplanowana improwizacja

Brak doświadczenia oczywiście natychmiast zemści się przy próbie poprowadzenia retrospektywy bez przygotowania, z marszu. Błędem wynikającym z braku praktyki jako Scrum Master może być próba 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 tego zdarzenia… 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 retrospektywy ad hoc, ale wartość, jaką taka retrospektywa przyniesie, może być nieco ograniczona, a samo zdarzenie 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ć retrospektywy. 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ć retrospektywę, a wtedy ty weźmiesz w niej udział jako uczestnik, dzieląc się z innymi swoimi obserwacjami i proponując usprawnienia.