No właśnie – po co? Pytanie “po co jest Scrum Master?” pada najczęściej ze strony osób lub organizacji nie zaznajomionych z metodykami zwinnymi, oraz ze strony osób (zespołów) i organizacji wątpiących w sens posiadania Scrum Mastera. Najczęściej z powodu nienajlepszych doświadczeń w przeszłości. Odpowiedzi na to pytanie najczęściej zawierają się w trzech obszarach. Pierwszy – to odpowiedzi samych Scrum Masterów lub w mniejszości – organizacji zatrudniających tychże, najczęściej zahaczające o opis roli (tak, wiem, odpowiedzialności, nie roli ;)) zawarty w Scrum Guide’zie:
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.
The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.
Scrum Masters are true leaders who serve the Scrum Team and the larger organization.
Najwięcej miejsca poświęca się tutaj na pracę z zespołami scrumowymi (lub jak czasem mówi Radek Orszewski – scrumującymi :)). Udział w wydarzeniach scrumowych (jest specjalne miejsce w piekle dla ludzi mówiących “ceremonie scrumowe”), oraz facylitacja tychże. Czyli opieranie się na pierwszym elemencie powyższego cytatu.
I ja się z tym zgadzam w pełni, natomiast jest to tylko niewielka część prawdy. I jeśli Scrum Master skupia się nad tym nadmiernie, albo co tragiczne – wyłącznie, to łatwo wpaść w antywzorce o których pisał Barry Overeem tutaj, a ja wspomniałem pokrótce w swoich przemyśleniach tutaj.
Więc żeby ten Scrum z pierwszego punktu działał, a Scrum Master mógł się wykazać, że działa – to czasem tenże Scrum Master zaczyna być skrybą zespołu (któremu to oczywiście na rękę) – i obowiązkowo spisuje status i AP z Daily (na którym Developerzy raportują status swoich zadań na Jirze), z Retrospektyw, i z innych spotkań na których obowiązkowo jest i je “facylituje”. Co ciekawe, jak się tak zastanowić – bardzo często słowo “facilitate” w praktyce oznacza “prowadzenie spotkań” – otwieranie, zamykanie, wyświetlanie Jiry i spisywanie notatek. Czyli bycie na świeczniku i grzanie piórek od słoneczka.
Jeśli ktoś widzi sens i wartość tego, żeby Scrum Master był meeterem-greeterem na Sprint Review, pilnowaczem harmonogramu i przydzielaczem głosu to chętnie posłucham argumentów.
Analogicznie – skoro Scrum ma timeboxy, to trzeba ich rygorystycznie pilnować – bo Scrumowa Policja na posterunku! 🙂 No i jeszcze organizacja wszystkiego za wszystkich i załatwianie spraw, zanim się zadzieją. Wyjście integracyjne – gdzie jest Scrum Master(ka)? Budżet do wydania? Kto jak nie Scrum Master załatwi budżet i zorganizuje ankietę, w której zespół wybierze spośród pięciu propozycji wymyślonych przez, a jakże – Scrum Mastera. Chyba Andy Brandt wspomniał kiedyś, że nie chodzi o to, żeby Scrum Master był kaowcem zespołu :).
Kiedy indziej taki Scrum Master wyśle wniosek o dostępy, przeprowadzi szkolenie stanowiskowe, lub pokaże gdzie jest zespołowa strona, na którą wszyscy wrzucają zespołowe rzeczy. Albo powinni, bo w praktyce robi to tylko Scrum Master.
I wyświetla taki Scrum Master tę nieszczęsną Jirę na Daily, wpisuje komentarze, uaktualnia statusy, czy nawet raporty wyciąga. Albo będzie Scrum Masterem bohaterem, robiącym za zespół wszystko, o czym zespół pomyśli że potrzebuje, a nawet zanim zdąży pomyśleć. Bo przecież Scrum Master ma usuwać przeszkody zespołu, tak? BŁĄD! Nie ma usuwać (samodzielnie), tylko powodować usuwanie przeszkód.
A czy można inaczej? Nie tylko można, ale i trzeba 🙂
Dawno dawno temu w wyborach samorządowych wziął udział kandydat, którego występ i prezentacja kandydatury w jednej z lokalnych telewizji stały się (zanim to określenie stało się modne) – viralem. Kandydował on z listy Podlasie XXI wieku a nazywał się (wszyscy pewnie już wiecie) Krzysztof Kononowicz.
Padł tam znamienny, memiczny do dziś cytat kończący się słowami:
“(…) żeby nie było niczego”.
Krzysztof kononowicz
I to w sumie świetnie opisuje to, po co jest Scrum Master w zespole. Żeby go nie było.
W tym momencie pewnie część Developerów zaczyna się szeroko uśmiechać i zacierać ręce, a część Scrum Masterów ma nieprzyjemne uczucie w kręgosłupie. Ale jak to…
No bo dokładnie po to Scrum Master jest – żeby go nie było. Tylko nie tak od razu 😉 Chodzi o to, żeby go nie było docelowo, bo staje/stanie się niepotrzebny. I już tłumaczę dlaczego.
Nie bądź jak Scrum Master – huba
W tytule zawarłem swoisty apel, żeby Scrum Masterzy byli katalizatorami, a nie hubami. Jaka jest różnica? Ano znaczna.
Hubę drzewną każdy zna, przynajmniej z dzieciństwa, z książek od przyrody. To pasożytniczy grzyb będący naroślą na drzewie i czerpiący z zasobów gospodarza. I w sumie taka dobra metafora kiepskiego Scrum Mastera 🙂 Jest, jest widoczny, zużywa zasoby (organizacji), ale dużego pożytku z nie(go/j) nie ma.
I tutaj pewnie niektórzy się oburzą, że jak to, Scrum Master który prowadzi Daily, wyświetla codziennie Jirę, robi notatki za zespół, przygotowuje retrospektywy i icebreakery w stylu “jakim kolorem jesteś”, prowadzi Sprint Review, zespołowe wiki i rozwiązuje wszystkie problemy za zespół nie jest pożyteczny? Przecież dzięki temu zespół ma więcej czasu na kodzenie, a przecież o to chodzi, prawda? Ano NIEPRAWDA!
Taki efekt obecności Scrum Mastera jest pozorny, a w najlepszym wypadku – daleki od optymalnego i pożądanego. Bo realnie, na dłuższą metę – niewiele się zmienia
Tego typu Scrum Mastera można zobrazować inaczej – wyobraźmy sobie szklankę wody, do połowy pełną ^^ która będzie metaforą zespołu. A następnie wyobraźmy sobie, że do tej szklanki wrzucamy piłeczkę golfową. Piłeczka golfowa w zauważalny sposób podnosi poziom wody. No i fajnie. Tylko jak się taką piłeczkę golfową ze szklanki wyjmie – to poziom wody opada do stanu poprzedniego. Tak samo dzieje się z zespołem, w którym był Scrum Master huba. Jak znika – zespół wraca do stanu sprzed pojawienia się Scrum Mastera.
I teraz pytanie – czy właśnie na tym nam zależy? Albo czy na tym powinno zależeć organizacjom, którym rzeczony Scrum Master ma służyć?
Hell no!
Więc mówisz, że Scrum Master nie jest od tego, żeby usuwać przeszkody za zespół i robić wszystko to, czego zespół woli nie robić skupiając się na swoich wąskich specjalizacjach, kodzeniu, testowaniu, analitykowaniu, czy DevOpsowaniu? To po co jest?
DO-SKO-NA-ŁE PYTANIE!!!
Teraz będzie grubo – prawda objawiona.
Pozwolę sobie przypomnieć ponownie dwa kluczowe według mnie fragmenty ze Scrum Guide’a:
The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.
Scrum Masters are true leaders who serve the Scrum Team and the larger organization.
Scrum Master jest po to, żeby (pomóc) uczynić zespół na tyle samodzielnym (POZA obszarem technicznym), żeby najpierw móc się usunąć w cień, a potem zniknąć – a zespół nie tylko będzie dalej utrzymywał WYPRACOWANE wspólnie praktyki, ale i dalej aktywnie poszukiwał nowych ścieżek. Bez. Scrum. Mastera.
A przynajmniej bez dedykowanej ROLI Scrum Mastera, przejmując ODPOWIEDZIALNOŚĆ Scrum Mastera. O tym kiedy indziej.
A Scrum Master, zamiast cyzelować praktyki w dotychczasowym zespole z 90% ideału na 92% ideału, pójdzie wspierać zespół w którym tego ideału jest znacznie mniej, i co pozwoli na znacznie lepsze wykorzystanie możliwości, jakie Scrum Master daje organizacji.
No dobra, ale o co chodzi z tym katalizatorem? Bo huba to już wiemy, źle.
Za Wikipedią (no a jakże :)):
Katalizator – substancja chemiczna, która dodana do układu powoduje zmianę ścieżki kinetycznej reakcji chemicznej, na taką, która ma niższą energię aktywacji, czego efektem jest wzrost szybkości reakcji (…)
Wikipedia, wiadomo
Powtórzmy dwa fragmenty:
- ma niższą energię aktywacji
- efektem jest wzrost szybkości reakcji
Czyli Scrum Master ma ułatwić i przyspieszyć identyfikowanie i wdrażanie zmian w zespole (i organizacji!), prowadzących do większej efektywności – czyli wprowadzania i usprawniania praktyk tę efektywność kształtujących.
To teraz będzie trochę o fizyce – wzywamy Newtona. Tak, tego Newtona
Każdy układ społeczny ma swoją dynamikę. Nie zawsze najwyższą 😉 Często tą dynamiką jest inercja 😉 Trochę znów odniosę się do fizyki – i pierwsza zasada dynamiki rzeczonego Newtona
właściwość wszystkich ciał materialnych o masie spoczynkowej większej od zera, polegająca na tym, że w inercjalnym układzie odniesienia, jeśli na ciało nie działa siła lub działające siły równoważą się, to porusza się ono ruchem jednostajnym lub pozostaje w spoczynku.
No i właśnie. Najczęściej elementy układu nie mają wewnętrznej, oddziałującej na nie siły. Można to obrazować poniższymi cytatami (każdy autentyczny):
- “Jest tak bo zawsze tak było” (wielokrotnie opowiadałem przypowieść o pieczeniu gęsi, kto pamięta?)
- “Powodzenia w próbach zmiany, trzy lata temu próbowaliśmy inaczej, nie wyszło”
- “U nas się nie da”
Pierwszy efekt działania Scrum Mastera
I taki Scrum Master – katalizator powinien właśnie obniżyć energię aktywacji zmian (np. poprzez transparentne pokazywanie słonia w pokoju, którego wszyscy nauczyli się obchodzić i robią to konsekwentnie od miesięcy czy nawet lat). Wówczas ten słoń zaczyna im przeszkadzać, dzięki czemu transparencja ma szansę przerodzić się w inspekcję, a ta – w adaptację. I nie mam tu na myśli podawania przez Scrum Mastera gotowych rozwiązań – raczej pokazywania schematów myślowych, problemów do rozwiązania w kontekście danego zespołu czy organizacji.
Drugi efekt działania Scrum Mastera
Kolejny efekt wpływu Scrum Mastera – katalizatora to przyspieszenie szybkości zmian. Owszem, można mieć nadzieję, że zespół czy organizacja na pewne rzeczy wpadną sami. Ale jak któryś kolejny Sprint z rzędu Zespół Scrumowy “dowozi” tylko ułamek przewidywanego zakresu, albo nie realizuje celu, lub ma wielocele, nie uwzględnia w szacowaniu testów, lub na planowaniu otwartych zadań z poprzedniego Sprintu – warto powiedzieć “hej, czy tak powinno być?”. Lub pokazać miary, na które nikt z zespołu by nie wpadł.
Lub zamiast pozwalać zespołowi tłuc po raz kolejny to samo Retro (co było dobrze, co było niedobrze, jakie akcje do podjęcia), którego efekty są dokładnie takie same jak poprzednich – pokazać inne ścieżki. Inne formuły, inne tematy. Zaangażować inne zespoły, zrobić mapę interesariuszy, roadmapę rozwojową czy analizę ryzyk. Albo zrobić Retro o retro, pogadać o kanbanie, czy zwinnych praktykach których zespół nie stosuje, a z perspektywy Scrum Mastera – mógłby spróbować.
Taki Scrum Master – katalizator nie zaczyna od ewangelizacji frameworkiem, ani od poprawiania, że już nie mówimy “rola”, tylko “odpowiedzialność”, bo dla nikogo na tym poziomie i etapie nie ma to najmniejszego znaczenia. Za to pokazuje i tłumaczy jakie praktyki, w jaki sposób i dlaczego mogłyby pomóc w zespole. Uświadamia, że jeśli Scrum Guide mówi o timeboxie 15 minut na Daily, to nie musimy ubijać wartościowej rozmowy.
I jeśli nasze Daily trwa 30 minut, ale w czasie jego trwania rozwiązujemy wspólnie problemy, ucząc się nawzajem – to róbmy to, dopóki przynosi nam to wartość. Taki Scrum Master uczy eksperymentowania i uzyskiwania szybkiej informacji zwrotnej z metody małych kroków, które łatwo modyfikować, a nawet cofać, jeśli zajdzie potrzeba. Uczy krytycznego spojrzenia, zaczynania od dlaczego, zastanawiania się po co coś robimy, i czy jest to najlepszy, albo nawet dobry sposób osiągnięcia celu. No i świadomości tego, czy/że mamy cel.
Taki Scrum Master – katalizator sprawia, że zespół w jego/jej obecności rozwija się znacznie szybciej i znacznie szerzej niż miałoby to miejsce bez Scrum Mastera. Jest (bardziej) samodzielny, a jak Scrum Master choruje, idzie na urlop, zmienia zespół lub firmę – nic się nie dzieje. To znaczy nic złego 😉 a wszystko pozostałe dzieje się tak, jak powinno. Jak trzeba zrobić Sprint Planning, Product Owner i Developerzy doskonale sobie radzą, zadając sobie te same pytania, jakie mógłby zadać Scrum Master.
Cel Sprintu jest jeden i to rozsądnie sformułowany. Lista rzeczy do zrobienia, wraz ze zgrubnym planem przygotowana. Praca zwizualizowana, ryzyka nazwane. Na Daily Developerzy się nie statusują, tylko planują kolejne etapy w kierunku realizacji Celu Sprintu. Na Review chcą mieć interesariuszy, żeby wiedzieć gdzie dalej będzie szedł rozwój Produktu. A Retrospektywa pokaże i zaadresuje realne problemy i zidentyfikuje realne usprawnienia.
Podsumowanie
Taki Scrum Master pomoże zespołowi rozwinąć się pod wieloma względami, tak że na koniec, wracając do metafory piłeczki golfowej, po jej wyjęciu ze szklanki, w szklance powinno być (znacznie) więcej wody niż przed jej włożeniem. A następnie piłeczkę-Scrum Mastera można włożyć do kolejnej szklanki do połowy pełnej, żeby w nowym zespole, nowym otoczeniu mógł dalej realizować swoją misję. I dopełniać zarówno szklankę zespołu, jak i dzbanuszek organizacji.
Kończąc cytatem z cudownego i nieśmiertelnego Forresta Gumpa,
Pozdrawiam serdecznie,
Marcin
1 comment