Scrum Master ma spowodować, by Scrum był zrozumiany, bo tylko wtedy może zostać świadomie wybrany i dobrze wykorzystany jako narzędzie. A gdy już metoda jest używana, Scrum Master ma doprowadzić do tego, by Zespół działał skutecznie. Jest to jego odpowiedzialność w znaczeniu anglojęzycznego terminu accountability, nie zaś responsibility. Jaka jest różnica?
To pierwsze (accountability) jest odpowiedzialnością za doprowadzenie do osiągnięcia jakiegoś celu, za spowodowanie czegoś, ale niekoniecznie przez bezpośrednie działanie. Tak rozumiana odpowiedzialność, jeśli ktoś ją na siebie bierze, nie może być scedowana na kogoś – delegować można jedynie odpowiedzialność za wykonanie działań, pozostając przy tym odpowiedzialnym za ich realne skutki.
To drugie (responsibility) jest odpowiedzialnością za wykonanie jakichś działań, przy czym odpowiedzialność tę można przekazać komuś innemu (delegować na kogoś).
Scrum Master jest więc odpowiedzialny za skuteczność Zespołu Scrum, z którym pracuje, aczkolwiek to nie on sam osobiście ma ją uzyskać. Nad tym pracuje cały Zespół, choć wciąż to Scrum Master pozostaje odpowiedzialny za to, by faktycznie tak się działo.
No, ale jak należy rozumieć tę skuteczność? Kiedy Zespół jest skuteczny? Najprostsza odpowiedź, jakiej mogę udzielić: skuteczny Zespół potrafi dostarczyć interesariuszom, na których rzecz pracuje tego, czego im potrzeba w momencie, gdy jest im to niezbędne, do tego w cenie, którą są za to skłonni zapłacić.
Inaczej mówiąc, skuteczny Zespół Scrum to taki Zespół, którego Product Owner potrafi dobrze wybrać, co i w jakiej kolejności należy zrobić, i którego Developerzy potrafią często i regularnie przekuwać plany Product Ownera na działający, nadający się do użytku produkt, który jest wart więcej, niż kosztuje jego wytworzenie. Tylko tyle i aż tyle. A Scrum Master ma do powstania takiego Zespołu doprowadzić.
Efektywność czy skuteczność?
Zatrzymajmy się na chwilę przy terminie, jakim się tu posługuję: skuteczność (pisałem już o tym, ale warto pochylić się nad tym raz jeszcze). W języku angielskim twórcy Scruma użyli słowa effectiveness, które wielu na język polski tłumaczy jako efektywność. Niestety, nie jest to trafne tłumaczenie, dlatego że stanowi jedynie kalkę brzmieniową w stosunku do anglojęzycznego terminu. Inaczej mówiąc, brzmi podobnie, ale znaczy nieco co innego.
Effectiveness wywodzi się od słowa effective, które jest pochodną innego słowa effect. Chodzi więc o zdolność do uzyskiwania pożądanych efektów, a więc tego, co nam jest potrzebne wtedy, kiedy tego potrzebujemy. Dlatego effective w polskim oznacza ni mniej, ni więcej, tylko skuteczny (albo, jak już na siłę chcemy się trzymać podobieństw brzmienia, dający pożądane efekty).
Jest w języku angielskim termin efficiency, który na polski tłumaczyć należałoby jako efektywność. Efektywność rozumianą jako optymalne wykorzystanie sił i środków. Co nie oznacza od razu skuteczności. Dlaczego? Najlepiej zobrazować to na przykładzie.
Jeśli do zrobienia jest jakaś skomplikowana praca, która wymaga dużej wiedzy i doświadczenia, efektywność (ang. efficiency) nakazywałaby poczekać na dostępność eksperta, który będzie tę wiedzę i doświadczenie posiadał. To może spowodować, że praca nie zostanie wykonana od razu, ale z pewnym opóźnieniem. Być może za późno, przez co ciężko będzie mówić o skuteczności (ang. effectiveness).
Zdarzają się sytuacje, gdy efektywność i skuteczność idą ze sobą w parze, ale jak widać, nie jest to bezwzględną regułą. Scrum Master jest odpowiedzialny za zapewnienie, że Zespół będzie skuteczny, natomiast dążenie do jak najwyższej efektywności jest jedynie jednym z narzędzi, jakie mogą w tym pomóc. Inaczej mówiąc, Zespół nie powinien dążyć do maksymalizacji efektywności (efficiency) tylko maksymalizacji skuteczności (effectiveness). Wysoka efektywność jest jednym ze środków do jej uzyskania.
Nowy wymóg względem Scrum Masterów?
Do 2020 w Scrum Guide nie było żadnego zapisu, który określałby tę odpowiedzialność Scrum Mastera, dlatego zmiana, jaka nastąpiła w tym roku, była dla niektórych zaskoczeniem. Odkryli bowiem, ku swemu zdumieniu, że Scrum Master nie zawsze musi być miłym misiem-przytulasiem dla Zespołu, który nie ma prawa niczego się domagać i który może co najwyżej bawić się w sugerowanie usprawnień.
Nic bardziej mylnego: jeśli Zespół nie działa skutecznie, Scrum Master musi coś z tym zrobić, sięgając po takie metody, jakie są do tego niezbędne – oczywiście bez łamania zasad Scruma.
To oznacza, że nie może np. przejąć od Product Ownera zarządzania Backlogiem Produktu, ale może zacząć wykazywać temu Product Ownerowi niedociągnięcia w sposobie, w jaki Backlog jest zarządzany.
Oczywiście nie chodzi o wygarnięcie w twarz błędów i wypaczeń ani o bezmyślną krytykę, ale o doprowadzenie do zrozumienia, co wymaga usprawnienia i pomoc w znalezieniu sposobu na jego dokonanie. W praktyce oznacza to, że trzeba nauczyć Product Ownera, jak korzystać z narzędzi i praktyk, dzięki którym Backlog Produktu będzie lepszy.
Dokładnie to samo dotyczy Developerów: Scrum Master nie może z buciorami wejść w ich odpowiedzialność i nakazać działanie w ten czy inny sposób. Ma natomiast prawo domagać się zmiany sposobu pracy, jeśli ten jest nieskuteczny. Może też proponować możliwe usprawnienia i musi pomagać w ich wdrażaniu.
Czy ta zmiana z 2020 wprowadza faktycznie nowe oczekiwania względem Scrum Masterów? Absolutnie nie. Pojawił się zapis, który wprost nazywa coś, co i tak było oczywiste dla każdego, to zrozumiał sens istnienia Scrum Mastera w Zespole. Fakt, że wywołało to zdziwienie, a u niektórych osób wręcz oburzenie, jest dość niepokojący, bo wskazuje na umiarkowany poziom zrozumienia metody wśród jej użytkowników…
Trudne wybory
Wróćmy do odpowiedzialności Scrum Mastera. Aby się z niej wywiązać, musi ciągle dokonywać wyboru sposobu działania. Im bardziej dyrektywną postawę przyjmuje, tym większa jest szansa, że zaszkodzi Zespołowi (Product Ownerowi i Developerom), utrudniając im samodzielny rozwój albo w ogóle go blokując. Lub, w ekstremalnych przypadkach, przejmując od nich odpowiedzialność (sam stając się Developerem lub Product Ownerem). Natomiast jeśli będzie zbyt wycofany, ucierpieć może skuteczność Zespołu.
Nie należy się bać twardego działania wprost, ale nie należy też podejmować go zbyt pochopnie. Każda bezpośrednia interwencja ma szansę cofnąć proces rozwoju Zespołu na jakiś czas (a w ekstremalnym przypadku na trwałe). Wiedząc to, ale też mając na sobie odpowiedzialność, jaką przyjmujemy, godząc się być Scrum Masterem, dokonujmy wyborów. I mimo że pomylimy się często, w ten sposób też sami się uczymy.
Praca dla Zespołu, ale nie tylko z Zespołem
Tylko na stosunkowo wczesnym etapie swego rozwoju Zespół przede wszystkim potyka się o wewnętrzne ograniczenia i ma pełnię swobody ich eliminowania.
Dość szybko staje się widoczne, że część istniejących ograniczeń jest wynikiem zasad współpracy (interakcji) z otoczeniem, sposobów postępowania narzuconych przez organizację, stylu pracy managerów, procesów toczących się w ramach całej firmy itd.
A skoro tak, Scrum Master musi zacząć coraz częściej współpracować z otoczeniem Zespołu. Bo to w nim uzyskać będzie można nowe możliwości (np. poprzez zwiększenie autonomii Zespołu), niezbędne środki, bez których skuteczność Zespołu jest ograniczona (np. narzędzia lub materiały, albo choćby szkolenia), ale także rozwiązania różnych problemów, o które potyka się Zespół (np. wymóg robienia czegoś wedle procedury, która prowadzi do marnowania czasu, nie dając niczego w zamian).
Środowisko sprzyjające zwinności
Nawet najlepsze chęci nie wystarczą, jeśli brak możliwości. Na skuteczność działania Zespołu bardzo duży wpływ mają warunki jego pracy i środki, jakimi dysponuje. Mogą pomagać, a mogą stanowić przeszkodę.
Można powiedzieć, że Scrum Master ma wykreować środowisko, w którym Scrum ma szansę działać i przynosić korzyści interesariuszom, na których rzecz Zespół pracuje. I rzeczywiście taki zapis znajduje się w definicji Scruma. O ile sam Scrum Master nie jest zwykle w stanie tego środowiska stworzyć, o tyle jest odpowiedzialny za doprowadzenie do tego, by powstało i rozwijało się w sposób spójny ze zmiennymi potrzebami Zespołu.
Oczywiście bez wspomnianej już wcześniej efektywności (wykorzystania możliwości i środków w sposób ekonomiczny) Zespół skuteczności nie osiągnie. Nie sposób mówić o skuteczności również wtedy, gdy ograniczony czas pracy Developerów marnowany jest na robienie rzeczy zbędnych. I za to, by tak się nie stało, również odpowiada Scrum Master. W szczególności oznacza to często konieczność wsparcia Product Ownera w procesie wyboru tego, co warto zrobić.
Dużo tego, prawda? Cóż, odpowiedzialność Scrum Mastera nie jest dla każdego i dobrze, by brały ją na siebie osoby świadome trudności, jakie mogą wynikać z dążenia do wywiązania się z niej. Każdego, kto chce dobrze zrozumieć zarówno Scrum, jak i odpowiedzialność Scrum Mastera w nim, zapraszam na szkolenia.
Przy okazji: ten artykuł stanowi niewielki fragment materiałów, a dokładniej e-booka udostępnianego uczestnikom moich szkoleń Professional Scrum Master po zakończeniu zajęć. Zainteresowanych zapraszam na kolejne edycje.