Tym razem chciałbym się pochylić nad tematem Scrum Master kontra Team Leader. W Scrum wiadomo jak jest – nie da rady. Nie da rady, bo Scrum Master ma być głównie rolą wspomagającą zespół i jego podstawowym zadaniem jest wspomaganie samoorganizacji zespołu. Team Leader to gość, którego głównym celem jest rozdzielanie zadań, pilnowanie postępu, projektowanie, narzucanie terminów i inne ładne funkcje. Czyli widać, nijak się nie klei.

Jednak ilość ogłoszeń o pracę na pozycję Scrum Master/Team Leader sugeruje, że pozycja taka jest całkiem popularna. Z drugiej strony często w firmie Scrum Master jest powoływany z byłego Team Leadera i sytuacja taka w życiu występuje. Generalnie podczas wprowadzania Scrum powstaje problem co zrobić z Team Leaderami. Jeśli stają się członkami zespołów to również rodzi to problemy (ale tym tutaj nie będę się zajmował). A jak nie członek zespołu to co, mamy powiedzieć wieloletniemu pracownikowi „sorry, wiesz w Scrum nie ma dla ciebie miejsca, wiele lat byłeś najlepszy ale teraz dziękujemy, do widzenia”?

Pominę tutaj patologię w rodzaju Scrum Master/Team Leader bo oficjalnie chwalimy się, że mamy Scrum ale wewnętrznie i tak wszyscy wiemy, że samoorganizującemu się zespołowi trzeba mówić, co ma robić (znane, prawda?). Chciałbym się skupić na praktycznym aspekcie jak można to połączyć i co mnie (ja również Scrum Masterem zostałem w wyniku ewolucji z Team Leadera) sprawia największe problemy. Oczywiście mówimy o sytuacji kiedy chcemy mieć prawdziwy Scrum i sytuacja Scrum Master/Team Leader jest konsekwencją powyżej opisanych sytuacji – czyli ewolucja w hierarchii lub sytuacja praktyczna, że Scrum Master również posiada jakieś funkcje administracyjne.

Największy ból powstaje w 2 obszarach – pierwsze to ukrycie faktu bycia Team Leader-em, drugie to wewnętrzna przemożna chęć „pomagania” zespołom bo przecież i tak wiem lepiej jak to zrobić. O ile administracyjne zadania jak podpisywanie urlopów da się zorganizować tak, żeby nie tworzyły hierarchii o tyle zatrudnianie/zwalnianie i ocenianie pracowników może być trudne. Na szczęście te sytuacje nie są bardzo częste więc tutaj przy odrobinie dobrej woli w organizacji to też da się rozwiązać.

Temat „pomagania” to już jednak zupełnie inna bajka. Tutaj poprzeczka jest bardzo wysoko, bo przecież Scrum Master również często wchodzi w rolę trenera i musi przekazywać wiedzę na temat Scrum w zespole. Granica pomiędzy przekazywaniem wiedzy a wydawaniem poleceń jest tak cienka i krucha, że czasami łatwo się zgubić.

Drugi problem to codzienne sytuacje podczas Daily Scrum i w trakcie Sprintu. Tu niestety na początku ilość „jasny gwint, znowu to zrobiłem, nie wierzę, to niemożliwe…” jest spora. Co chwilę łapiemy się na powiedzeniu kilku słów za dużo lub wręcz na „nakierowaniu” zespołu na rozwiązanie. Na szczęście w miarę upływu czasu jeśli znamy kierunek w którym podążamy i nie tracimy z oczu nadrzędnego celu to sytuacja ulega znacznej poprawie. Wewnętrzna determinacja w eliminowaniu takiej źle pojętej pomocy jest kluczem do odniesienia sukcesu. Oczywiście należy się na bieżąco wspomagać czym się da, czyli literaturą, pomocą zewnętrznych coach-ów, rozmowami z innymi Scrum Masterami.

Na zakończenie dla podsumowania – oczywiście łączenie roli Srum Master i Team Leader nie jest ani wskazane, ani nawet możliwe. Ponieważ jednak coś takiego jak rzeczywistość również istnieje (to takie smutne) często trzeba się z tym zmierzyć. I jeśli nie stracimy z oczu kierunku w którym podążamy, to wbrew pozorom drogą ewolucji jesteśmy w stanie stopniowo wyemigrować z Team Leader-a w stronę Scrum Mastera. Z wielkim pożytkiem dla organizacji (nawet jeśli organizacja początkowo tego nie rozumie, ale to temat na osobny wpis…).