Blog

W dużym stopniu to wynik tego, że mamy setki jak nie tysiące Scrum Masterów – jak ja ich nazywam – “motylków” nie mających pojęcia o programowaniu czy technologii w ogóle a zajmującymi się głównie rozsiewaniem “zwinnego pyłku”. Scrum Masterzy tacy spędzają czas na wymyślaniu coraz bardziej skomplikowanych „zabaw” na retrospekcje, z wymyślnymi rekwizytami i scenariuszami jak do przedstawienia w przedszkolu. Albo poświęcają całe dnie na przygotowywanie warsztatów o psychologicznym bezpieczeństwie, równości i inkluzywności lub cyzelują kolejne piękne tablice w Muralu. Nic dziwnego, że developerzy postrzegają to wszystko jako oderwane od rzeczywistości ich pracy. A menedżerowie coraz częściej zadają głośno pytanie: za co właściwie płacimy tym ludziom i co oni realnie wnoszą? Co robią po całych dniach?

A tymczasem odpowiedź na tytułowe pytanie jest zaskakująco prosta: Scrum Master przez większość dnia po prostu pracuje z zespołem nad osiągnięciem Celu Sprintu. Programuje, testuje, analizuje – wykonuje te same czynności co inni Developerzy w zespole. To, co go odróżnia to dodatkowa odpowiedzialność, która na nim spoczywa i powoduje, że ma (powinien mieć) szerszy ogląd sytuacji. Tak właśnie działali ludzie, na których koncepcja Scrum Mastera jest oparta – bo przecież twórcy Scruma nie wymyślili tej odpowiedzialności „z powietrza”, powstała w wyniku obserwacji realnych zespołów w czasach, kiedy Scrum powstawał w odpowiedzi na rzeczywiste wyzwania.

A jest to odpowiedzialność bardzo konkretna – Scrum Guide jasno mówi, że Scrum Master odpowiada za efektywność zespołu. Owa “efektywność” to nie jest jakiś mglisty koncept – chodzi o zdolność zespołu do dostarczania nowych, wartościowych i działających wersji produktu nie rzadziej niż co sprint. Bez tego fundamentu cała reszta – retrospekcje, ciekawe techniki facylitacji, długie dyskusje o procesie – nie ma większego sensu. Scrum jest metodą empiryczną – opiera się na podejmowaniu decyzji w oparciu o rzeczywiste obserwacje. W praktyce oznacza to, że bez nowej wersji produktu powstającej co sprint nie ma empiryzmu, nie ma Scruma. Są tylko jego pozory.

Pracując w zespole nad osiągnięciem Celu Sprintu Scrum Master powinien więc zachowywać świadomość stanu zespołu i szerszą perspektywę. Nie chodzi tu o jakieś nadzwyczajne umiejętności – po prostu o to, by nie zatracić się całkowicie w szczegółach technicznych nad którymi właśnie pracujemy, ale mieć też na uwadze czy jako zespół zmierzamy we właściwym kierunku wyznaczanym przez Cel Sprintu, czy zachowujemy wspólnotę pracy, czy nie brakuje nam komunikacji nie tylko w zespole ale i z innymi zespołami czy interesariuszami – i tak dalej.

Poza świadomością oczywiście czasem trzeba podjąć też działanie – odpowiedzialność to przecież nie tylko bierna obserwacja. Czego zatem Scrum Master używa, kiedy pojawia się potrzeba działania z tej odpowiedzialności? Oczywiście, nie ma tu standardowego podręcznika zachowań ani gotowego algorytmu postępowania. Wypracowaniu odpowiednich reakcji na różne sytuacje służą szkolenia i warsztaty, literatura – ale przede wszystkim praktyka. Jednak w tym artykule chcę przypomnieć o pomocnej metaforze “pięciu narzędzi” – w gruncie rzeczy pięciu postaw jakie może przyjmować Scrum Master zależnie od sytuacji. Zaczerpnąłem je od Bas-a Vodde, jednego ze współtwórców metody skalowania LeSS.

Te pięć narzędzi to:

1. Zadawanie pytań (Question) – aby prowokować do szukania odpowiedzi i dążyć do pełnej przejrzystości. Pytania te padają podczas codziennej pracy, przy okazji rozwiązywania problemów czy omawiania kodu. Nie chodzi o to, by przerywać pracę i urządzać specjalne sesje pytań, ale o to by w naturalny sposób nakierowywać zespół na odkrywanie problemów i ich rozwiązań.
2. Uczenie (Teach) – o Scrumie, technikach i praktykach developerskich, jeśli są potrzebne. Znów, nie chodzi głównie o organizowanie formalnych szkoleń czy prezentacji (choć oczywiście i to może Scrum Master robić), ale o dzielenie się wiedzą w kontekście konkretnych sytuacji z codziennej pracy zespołu. Czasem będzie to krótkie wyjaśnienie podczas daily, czasem rozmowa przy kawie o tym jak inny zespół rozwiązał podobny problem a czasem pokazanie bezpośrednio jak coś zrobić. 
3. Facylitacja (Facilitate) – pomoc w działaniu i podejmowaniu decyzji, w tym moderacja spotkań. Tu oczywiście najbardziej widoczna jest facylitacja wydarzeń Scrumowych, ale równie ważna jest umiejętność pomocy zespołowi w dochodzeniu do decyzji podczas codziennej pracy.
4. Aktywna bierność (Actively do nothing) – obserwacja sytuacji, pozwalanie zespołowi na samodzielne rozwiązywanie problemów. „Aktywna” bo Scrum Masterowi zależy na dobrym wyniku, „bierność” bo czasem najlepszą pomocą jest powstrzymanie się od natychmiastowej interwencji. To najtrudniejsze z narzędzi, wymagające dużej samoświadomości i dyscypliny.
5. Interwencja (Intervene) – najczęściej w sytuacji kryzysowej, kiedy zagrożone jest dostarczenie przyrostu, przejrzystość lub fundamentalne zasady. Wtedy Scrum Master może po prostu nakazać zrobienie czegoś lub czegoś wprost zakazać. To ostateczność, bo płaci się za to cofnięciem się zespołu w rozwoju ku samozarządzaniu, ale czasem konieczna by zespół nie zboczył całkowicie z kursu.

Kluczowe jest to, że Scrum Master używa tych narzędzi przede wszystkim w toku Sprintu, pracując z innymi nad realizacją Celu Sprintu. Nie jest zewnętrznym obserwatorem czy „ekspertem od Scruma” unoszącym się nad zespołem na skrzydełkach z kolorowych karteczek, jest częścią zespołu, która dba o jego skuteczność.

I właśnie dlatego odpowiedź na pytanie „co Scrum Master robi przez cały dzień” jest tak prosta: koduje, testuje, analizuje – robi to co inni w zespole. Po prostu robi to zachowując szerszą perspektywę i robiąc to co trzeba, używając odpowiednich narzędzi, by wywiązać się z dodatkowej odpowiedzialności jaka na nim spoczywa.