Scrum Masterzy w pelnym wymiarze godzin sa trudni do zrealizowania
W coraz większej liczbie organizacji Scrum jest używany jako zwinna metoda tworzenia oprogramowania. Tworzone są zespoły i wyznaczani Scrum Masterzy, aby zespoły mogły zacząć pracować w sposób zwinny i samoorganizować się. Jednak nawet jeśli Agile może na pierwszy rzut oka wydawać się proste, rola Scrum Mastera okazuje się często trudna. Zastanówmy się, dlaczego tak trudno jest pracować z Scrum Masterami w pełnym wymiarze czasu i zbadajmy alternatywę w postaci pozwolenia technicznym członkom zespołu przejąć rolę Scrum Mastera.
Pozyskanie dobrych Scrum Masterów w pełnym wymiarze czasu jest trudne
Posiadanie dedykowanych Scrum Masterów w pełnym wymiarze czasu, którzy nie mają innych zadań ani ról (technicznych), jest często wybieranym rozwiązaniem w organizacjach, które zaczynają pracować w sposób zwinny. Ludzie ci wywodzą się z zarządzania projektami lub innego, bardziej „biurokratycznego" podejścia do zarządzania i naprawdę starają się jak najlepiej wypełniać rolę Scrum Mastera jako Servant Leadera. Jednak okazuje się to często dość trudne.
Moim zdaniem tacy Scrum Masterzy w pełnym wymiarze czasu nie pasują dobrze do większej zwinności. Często po prostu nie działa.
W większych i bardziej biurokratycznych organizacjach z klasycznymi hierarchiami odgórnymi zazwyczaj istnieje kultura zarządzania opartego na poleceniach i kontroli. Ze względu na to, do czego przyzwyczajeni są członkowie zespołu, będą postrzegać swojego Scrum Mastera jako lidera – menedżera. Postrzegają Scrum Mastera jako kogoś, kto został „przypisany" do ich zespołu i jest na wyższym szczeblu hierarchii niż oni sami. Tak właśnie byli zarządzani przez wszystkie poprzednie lata. Dlatego nie dziwi, że wątpią, czy Agile cokolwiek w tym zmieni.
Menedżerowie wyższego szczebla, którzy nie do końca zrozumieli Agile, często uważają Scrum Masterów za menedżerów i liderów zespołów. Chcą, aby Scrum Master był ich łącznikiem z zespołem. Jest wtedy jedyną osobą, z którą ci menedżerowie współpracują, i ma ich na bieżąco informować. Zamiast komunikować się bezpośrednio ze wszystkimi członkami zespołu, wolą pracować tylko ze Scrum Masterem. Dają Scrum Masterowi informacje zwrotne. Proszą Scrum Mastera o zajęcie się pewnymi sprawami, wymagają zobowiązań i oczekują ich spełnienia.
Nie można winić menedżerów za takie oczekiwania wobec roli Scrum Mastera. Nauczono ich zarządzać i kierować zespołami w ten sposób. Tak zawsze to robili, tak im to działało i tak odnieśli sukces. Dlaczego miałoby być inaczej z Agile?
Dla Scrum Masterów jest to trudna sytuacja robocza. Zespół i kierownictwo postrzegają ich jako menedżerów. Kierownictwo oczekuje od Scrum Masterów, że będą coachować zespoły i pomagać im na drodze do samoorganizacji. Jednocześnie muszą jednak kontrolować wszystko. Ponadto Scrum Masterzy są często pociągani do odpowiedzialności za wyniki zespołu. W Agile nacisk kładziony jest na to, że zespoły uczą się i doskonalą – a przy tym chętnie popełniają błędy lub całkowicie się mylą – ale menedżerowie oczekują, że poprawa nastąpi od pierwszego dnia.
Przy wszystkich tych różnych oczekiwaniach w organizacji trudno jest właściwie wypełniać rolę Scrum Mastera. Dla Scrum Masterów trudno jest budować zaufanie i tworzyć otwartą kulturę, w której wszyscy współpracują i wspólnie się uczą.
Ostatecznie często nic się nie zmienia i organizacja nie może czerpać korzyści biznesowych z Agile. Z technicznymi członkami zespołu w roli Scrum Mastera można dokonać prawdziwych zmian w organizacjach i poprawić ich zwinność.
Techniczni członkowie zespołu w roli Scrum Mastera
Wolę, gdy (techniczny) członek zespołu przejmuje rolę Scrum Mastera, zamiast pracować z przypisanymi Scrum Masterami w pełnym wymiarze czasu. Mogą wykonywać zadania Scrum Mastera obok swoich regularnych technicznych prac.
Jeden z członków zespołu przejmuje więc rolę Scrum Mastera. Wspiera on i kieruje zespołem w pracy i wdrażaniu Agile. Pomaga zespołowi w zwinnych praktykach, na które wcześniej się umówił, przypomina członkom zespołu o ważnych kwestiach, daje informacje zwrotne i coachuje ich w razie potrzeby.
Dzięki temu rozwiązaniu będzie mniej oporu i większa akceptacja w zespole, ponieważ członkowie zespołu mogą sami wybrać swojego Scrum Mastera. Rolę Scrum Mastera można też co jakiś czas przekazywać dalej, tak aby różni członkowie zespołu byli Scrum Masterami w różnych Sprintach.
Jedną z zalet rotacji Scrum Mastera jest to, że aktualny Scrum Master może skupić się razem z zespołem na swoim Sprincie, podczas gdy Scrum Master na następny Sprint może skupić się razem z Product Ownerem na Groomingu Backlogu i mieć dobre User Stories, gdy rozpocznie się następny Sprint.
W większości zespołów nie ma prawdziwej potrzeby posiadania oddzielnego Scrum Mastera w pełnym wymiarze czasu. Samoorganizujący się zespół składający się z siedmiu plus/minus dwóch członków nie powinien potrzebować 40 godzin zarządzania tygodniowo – nawet nie 20. Nie chcesz Scrum Mastera, który zarządza trzema lub więcej zespołami. Lepiej, gdy rola Scrum Mastera jest realizowana w niepełnym wymiarze czasu w ramach zespołu, ponieważ wtedy jest zawsze dostępny, gdy jest potrzebny.
Scrum Masterzy mogą pomagać swoim zespołom w usuwaniu przeszkód. Mogą pomagać im w samoorganizacji, pokazując im, jak rozpoznawać i podchodzić do takich przeszkód. Scrum Masterzy nie powinni sami rozwiązywać wszystkich problemów i oczywiście nie powinni narzucać zespołowi, kto ma rozwiązywać problemy i jak to robić.
Dlaczego Scrum Masterzy w pełnym wymiarze czasu są potrzebni?
Ukończenie pracy oznacza więcej niż tylko jej wykonanie. Trzeba komunikować się z klientami i uzgadniać, co ma zostać dostarczone. Trzeba regularnie sprawdzać, jak postępują prace i czy cokolwiek spowalnia zespół. Ponadto wszystko musi być uzgodnione z interesariuszami zespołu i dobrze jest przeprowadzać retrospektywy, aby reflektować i uczyć się. Scrum Masterzy zajmują się tymi wszystkimi sprawami i pomagają członkom zespołu we wdrażaniu.
Jakiś czas temu przeprowadziłem wywiad z Nicem Ferrierem dla InfoQ i wspomniał, że doświadczone zespoły może w ogóle nie potrzebować już Scrum Mastera:
InfoQ: Na początku – gdy zespoły zaczynają pracować z metodami zwinnymi – Scrum Masterzy są przydatni, ale z czasem mogą stać się zbędni?
Ferrier: Tak jest. I to jest powód, dla którego Scrum Masterzy tak często wywodzą się z zespołu, w którym pełnią właściwie rolę techniczną. Dzięki temu mogą po prostu coraz bardziej wycofywać się z roli Scrum Mastera. Uważam jednak, że nie zawsze to działa, ponieważ menedżerowie w firmach nie pozwalają technicznym zespołom rozwijać się w sposób zwinny.
Teraz pojawia się pytanie, dlaczego retrospektywy nie mogłyby być po prostu prowadzone przez tego członka zespołu, który pełni rolę Scrum Mastera. Czy nie jest trudne dla nich, skoro są też częścią zespołu i mogą współdecydować o tym, jak praca powinna być wykonywana? Oczywiście, że tak. Doświadczony Scrum Master jest jednak zazwyczaj w stanie zarówno prowadzić spotkanie, jak i uczestniczyć w nim jako członek zespołu. Jeśli nie ma się pewności, czy to zadziała, zawsze można szukać zewnętrznego Scrum Mastera, np. kogoś z innego zespołu, Agile Coacha lub moderatora, aby przeprowadzić retrospektywę.
Niniejszy tekst pochodzi z bloga Bena Lindersa i został przez nas przetłumaczony na język polski.
Zostań certyfikowanym Scrum Masterem z Agile Academy
Dla Scrum Masterów oferujemy następujące szkolenia i bezpłatne możliwości doskonalenia:
