W świecie IT, szczególnie wśród deweloperów, coraz częściej widzę pewnego rodzaju ,,szyderę” i niechęć wobec Scruma i Scrum Masterów.
Mnie, jako Scrum Mastera, nieszczególnie to cieszy, ale staram się samemu z tym nie walczyć, tylko próbować zrozumieć drugą stronę i dopiero wtedy reagować. Scrum zaczyna być masowy, a masowość nie kojarzy mi się z jakością, może zatem warto wziąć na klatę krytykę i coś w sobie zmienić?
Niedawno stworzyłem prostą ankietę i poprosiłem trzy strony scrumowego tortu, tj. Deweloperów (po staremu zespoły deweloperskie), Product Ownerów oraz Scrum Masterów o odpowiedź na jedno, otwarte pytanie: Jakie błędy – zaniedbania – grzechy – popełnia/popełniał Scrum Master, z którym pracujesz/pracowałeś(aś)?
Moja ,,grupa badawcza” była dość skromna, bo liczyła 33 osoby (7 Product Ownerów, 7 Scrum Masterów 19 Developerów), badanie nie pretenduje więc do miana naukowego, ale wyciągnąłem bardzo ciekawy feedback.
Pycha i nieufność
Deweloperzy, Product Ownerzy i Scrum Masterzy spotkali się w swojej przeszłości z pychą tytułowych bohaterów. Pojawiły się zarzuty traktowania zespołu z góry, a także wynikające z braku zaufania narzucanie własnych rozwiązań, niepozwalanie na inicjatywę i samoorganizację. Jest to poważny zarzut i dość zasadnicze pogwałcenie scrumowych wartości. Scrum Master może oczywiście czasem proponować rozwiązania, które wynikać powinny z jego doświadczenia, ale pamiętajmy, że zespół powinien się samoorganizować, ba, nawet samozarządzać i powinniśmy mu nawet czasem umożliwić popełnić błąd. Dlaczego? Bo człowiek, tak i jak zespoły, uczy się właśnie na błędach.
Brak umiejętności miękkich
W opinii badanych zdarzają się Scrum Masterzy, którzy mają spore trudności w budowaniu relacji z ludźmi. Trudny charakter, słaba komunikatywność, brak empatii Scrum Mastera mogą doprowadzić czasem do kryzysu w zespole. Jeden z odpowiadających na zadane pytanie wskazał wprost przykład, kiedy Scrum Master nieświadomie (przez brak miękkiego skill setu) doprowadził do dużego napięcia i kryzysu pomiędzy Deweloperami a Product Ownerem. Nie czarujmy się, Scrum Masterzy, tak jak wszyscy ludzie, mają mniej lub więcej umiejętności społecznych, ale nie można nie zauważyć, że powinna to być rola, która jednoczy ludzi, a nie ich dzieli. Nie mam tu na myśli sztucznego eliminowania konfliktów, bo konflikty czasem są dobre i mogą być konstruktywne.
Uległość i brak asertywności
Grzech, przeciwstawny do tego, który został wymieniony jako pierwszy (czyli nie wszyscy SMowie popełniają te same grzechy ?). W odpowiedziach pojawiały się postacie takich Scrum Masterów, którzy byli tak bardzo usłużni, tak bardzo dla zespołu, że dali sobie… wejść na głowę. I stali się popychadłem, a wraz z nim ich autorytet ,,lidera, który służy” zmieniał się w prawdziwego sługę, który nie jest już liderem. ,,SM staje się proxy i robi za sekretarkę” to kwintesencja tego grzechu. Są także zarzuty braku asertywności, pozwalanie by sprinty planowane były przez PO, a nie zespół. Jak taki Scrum Master ma potem bronić teamu przed nierealnym deadlinem, jak taki Scrum Master ma dać negatywny feedback leniom? Jak taki Scrum Master ma iść na urlop, skoro nikt nie poprowadzi daily czy planningu?
Błędy merytoryczne
Jest to grzech ciężki. Nie miejmy wątpliwości – takie grzechy psują cały rynek Scrum Masterów. Na szczęście nie było takich odpowiedzi wiele, ale pojawiły się i weźmy sobie to do serca. Nieznajomość Scruma, ustępowanie na każdym kroku, by było miło (scrumbuts), albo udawanie podczas DEMO (zakłamywanie rzeczywistości) absolutnie nie powinny się nam zdarzyć.
Brak zwinności
Dużo odpowiedzi pojawiło się pod tym zarzutem. ,,Za duży nacisk położony na proces scrumowy/ agile” był jednym z nich – robienie ze Scruma bożka, zamiast dążenia do autonomicznego zespołu. Niestety ludzie, z którymi jako Scrum Masterzy pracujemy, czasem widzą nas jako osoby, które wynoszą sam proces ponad korzyści, które mają z niego wynikać. Zdarza się, że sztywno trzymamy się procesu, skupiamy na mechanizmach, takich jak organizowanie kalendarza spotkań i głaskanie Jiry – to wszystko bez spojrzenia na wartość dla zespołu. Pomijamy przy tym najważniejsze – wsparcie zespołu np. w rozumieniu i realizacji celów sprintów. Dodatkowo, zespół wybija z rytmu nagminnie przeciągane spotkania, które do niczego nie prowadzą, nie mają agendy.
Apodyktyczność
Dość długa lista uwag pojawia się i tu. Nie brakowało przykładów, że Scrum Master za dużo zarządza, dyryguje zespołem, uprawia swego rodzaju micromanagement – jest koordynatorem, kontrolerem, przydziela zadania i ogranicza samoorganizację zespołu. Co więcej pełni de facto rolę Managera. Nie bądźmy jak Manager (nie mam nic do Managerów!) – nie sterujmy, pozwólmy zespołowi się rozwijać i zaufajmy mu.
Forsowanie własnych pomysłów, manipulowanie zespołem i podważanie kompetencji nie jest ok. Pamiętajmy, że Scrum zakłada płaską strukturę. Są momenty (szczególnie przy tworzeniu się zespołów), kiedy Scrum Master jest aktywniejszy i czasem więcej proponuje, ale trzeba rozróżnić zarządzanie od wspierania. Scrum Master wspiera.
Niedbalstwo
Dobry Scrum Master to zaangażowany Scrum Master. Jeśli np. brakuje follow-upu po retrospekcji, nie dziwmy się, że żaden Deweloper nie jest ,,fanem” tych spotkań. Jeśli jedyne, czym się zajmujemy to administrowanie Jirą i kalendarzem oraz spotkaniami, to rzućmy tę robotę. Niestety sporo uwag dotyczyło zaniedbywania zespołów przez Scrum Masterów: ,,było go za mało”, brak dbałości o np. refinement, brak interwencji w trudnych momentach, brak wsparcia teamu i Product Ownera, jeśli tego potrzebują.
Podsumowanie
Po wymienieniu powyższych grzechów wyłania się dość negatywny obraz, ale trudno o optymistyczne przesłanie, jeśli mowa o grzechach. Dorzucę zatem do pieca i powiem, że tych grzechów jest jeszcze więcej! Zamiast jednak zwieszać głowę w zadumie proponuję potraktować te opinie i przykłady jako punkt wyjścia do swoistej auto-retrospektywy na temat błędów, które z pewnością czasem popełniamy wszyscy.
Co zrobić z tą wiedzą? Pomarudzimy sobie i tyle? Zostawiam to każdemu pod rozwagę.
Jeśli mam coś sugerować Scrum Masterom (także sobie) to radzę, by mieć stale włączony czujnik słuchania i nakłaniania teamów do transparentności. Z pewnością pomoże to wyłapać i przeprocesować negatywny feedback, zanim trafi do nas poniewczasie. Zaufanie zespołu jest jak las – wolno rośnie, szybko płonie.
Co radzę osobom pracującym ze Scrum Masterami, tj. Deweloperom, Product Ownerom i innym osobom? Dbajcie o to, aby Scrum Master miał świadomość waszych potrzeb i bolączek. Lider, który służy, nie będzie w stanie robić tego efektywnie bez tej wiedzy.
Wszystkim teamom życzę wspaniałych Scrum Masterów!
PS. Jakiś czas temu mówiłem o tym na pewnym meetupie. Zrobiliśmy krótkie ,,retro” po tym i to były najważniejsze błędy:
- Brak asertywności SM
- Proces ważniejszy dla SM niż pragmatyczne podejście
- SM nie rozumie ducha/idei/logiki Scruma i powtarza oraz wdraża bezmyślne schematy
I wyszliśmy z tego spotkania z wnioskami: ,,co powinniśmy mówić Scrum Masterom otwarcie”
- Zarzut: brak asertywności:
- Zarzuty: Proces ważniejszy niż pragmatyczne podejście & brak zrozumienia ducha/idei/logiki Scruma i powtarza oraz wdraża bezmyślne schematy:
Chcesz zostać Scrum Masterem? Sprawdź nasze kursy!
- Zostań Scrum Masterem: sześciodniowe szkolenie dla początkujących.
- Scrum Master: dwudniowe szkolenie dla osób biorących udział w projektach (niezależnie od branży i tematyki) i pełniących role kierowników projektów, członków zespołów projektowych oraz pozostałych interesariuszy projektów.
Fajny wpis.
Dodałbym ze swojej strony kilka rzeczy.
– Narzuty kulturowe. W Polsce często zaangażowanie się jest źle odbieranei traktowane bardziej jako podlizywanie się.
– Często Scrum jest wpychany „na siłę” wszędzie nawet wtedy kiedy projekt opira się poprostu na zadaniach i bardziej przydałby się prosty Kanban
– Sztywne podział ról. Trudność polega w tym, że często deweloperzy nie chcą wchodzić w szczegóły biznesowe, bo oni są od baz danych i po co im ta wiedza :). Także pracują w wąski zakresie i wrecz oczekują wszystkiego wyspecykowania US z najdrobniejszymi szczegółami.
Oczywiście tutaj dużo zależy od SM. Czy jest wstanie tutaj wypracować rozwiązanie.
Pozdrawiam