Wiele osób pyta mnie o to, czy Scrum Master powinien być stale obecny w zespole. W tym artykule próbuję opisać moje spojrzenie na tę rolę. To tylko moja opinia, nie ogłaszam jedynej słusznej prawdy.
Zacznijmy od genezy roli Scrum Mastera. W pierwotnym założeniu była to osoba, która wprowadza Scruma. Oznacza to, że uczy i wspiera zespół w samoorganizacji, odpowiedzialności za cel, rozumieniu filarów, wartości i zasad Scruma. Po wprowadzeniu wszystkich w wiedzę, ustabilizowaniu pracy zespołu i zbudowaniu podstaw mógł przejść do kolejnego zespołu. Zgodnie z założeniem miało to trwać od trzech do sześciu miesięcy.
Kiedy Scrum Master jest potrzebny?\ Co się stało z pierwotnym założeniem?\ Dlaczego to nie działa w ten sposób?
Oczywiście, to działa, ale tylko wtedy, gdy spełniony jest inny warunek, czyli zapewniona jest stabilność otoczenia. Zmienność zawsze wprowadza chaos, który wpływa na pracę zespołu. Widać to wyraźnie na wykresie Velocity, który z czasem zaczyna falować, a to oznacza utratę przewidywalności dostarczania.
Wdrażanie Scruma
Samo wdrażanie Scruma jest dla rozwoju zespołu czymś rewolucyjnym. Najczęściej powstają nowe zespoły, wprowadzana jest automatyzacja testów. Zespoły są mniejsze, pojawiają się nowe, obce rytuały, a znikają znane i proste spotkania statusowe. Zgodnie z założeniami autorów Scrum Guide rola Scrum Mastera jest potrzebna do poprawnego, trwałego i bezpiecznego wprowadzenia tych zmian.
- Poprawność wdrożonego Scruma jest kluczowa, ponieważ framework nie będzie trwały, bezpieczny i skuteczny, jeśli nie zostanie wdrożony w całości. Próba omijania niektórych elementów zniekształca i w efekcie deformuje cały sposób pracy. Widać to, gdy zaczynamy wymagać od zespołu większej efektywności i wydajności. Czasem porównuję to do mechanizmu zębatek w zegarze: jeśli coś usuniemy, będzie się kręciło, ale nie będzie przewidywalności, nie będzie płynności, a próba przyspieszenia skończy się rozsypaniem wszystkiego.
- Trwałość zmiany w podejściu zwinnym powinna mieć kluczowe znaczenie. Nie wystarczy szkolenie z Scruma i jednosprintowy test, żeby sprawdzić, czy wszyscy rozumieją zasady. Po odejściu Scrum Mastera sposób pracy i role powinny zostać utrzymane na stałe i nie powinny wykraczać poza Scruma.
- Bezpieczeństwo wdrażania Scruma rozumiem jako zabezpieczenie planowanej produkcji tak, by zmiana nie spowodowała pogorszenia albo załamania projektu czy całego biznesu. Scrum Master powinien wprowadzać zmiany tak, by wahania wydajności pozostawały w akceptowalnym zakresie, a terminy dostarczenia pozostały bez zmian. W przeciwnym razie modyfikacje trzeba uzgodnić i zatwierdzić.
Zmiany w zespole
Zmiany personalne to duża zmiana dla zespołu i mają ogromny wpływ na to, jak pracuje. Zdarza się, że nowa osoba szybko i sprawnie dopasowuje się do działającego systemu, ale częściej jej dołączenie i adaptacja powodują destabilizację. Jeszcze poważniejsze skutki może wywołać odejście ważnego członka zespołu.
Wsparcie Scrum Mastera zmniejsza turbulencje i skraca ich czas trwania, a to oznacza, że jego obecność jest potrzebna i opłacalna. Szczególnie ważne jest zapewnienie jak najdłuższego czasu od pierwszej informacji o zmianie personalnej do faktycznej zmiany w zespole. Dzięki temu Scrum Master i zespół mogą się przygotować i płynnie wejść w nową sytuację.
Zmiany technologiczne
Technologia zmienia się bardzo szybko, a te zmiany wymagają stałego uzupełniania kompetencji. To oznacza konieczność ciągłego i planowanego rozwoju. Problemy zaczynają się wtedy, gdy technologiczna rewolucja jest nieplanowana, a zespół musi radzić sobie ze zmieniającymi się wymaganiami bez przygotowania do pracy w nowej technologii.
Zespół, działając w roli twórcy produktu, naturalnie skupia się na technicznych aspektach zmian technologicznych. Product Owner interesuje się nowymi możliwościami, jakie zmiana może przynieść klientowi lub użytkownikowi. Scrum Master odpowiada wyłącznie za skupienie się na zmianach w sposobie pracy zespołu. Najczęściej widzi zagrożenia dla stabilności pracy wynikające ze zmiany technologii. Rozwój kompetencji, zależności międzyzespołowe lub zewnętrzne, sposoby rozwiązywania problemów i wspierania nowych rozwiązań wpływają na velocity i przewidywalność pracy. Starannie przygotowane zmiany technologiczne pozwalają organizacji płynnie zmieniać sposób działania i ograniczać negatywne skutki.
Zmiany skali
Dołączenie kolejnego zespołu do projektu nie jest bezkosztowe, a velocity nie tylko zostanie zaburzone, ale prawdopodobnie nie wróci już do osiągniętego poziomu. Większy projekt i więcej zespołów oznaczają więcej zależności, większą złożoność i większe problemy.
Problem jest powszechny, bo brak zrozumienia dla trudności związanych z rozwojem prowadzi do wniosku: "Idzie za wolno, dołóżmy kolejne zespoły do pracy." Problem nie leży w samym zespole, ale większa liczba zespołów wpływa na sposób planowania pracy, dodatkowe zależności międzyzespołowe w trakcie dostarczania, sposób testowania, integrację przyrostów w jeden produkt, a nawet sposób prowadzenia spotkań Scrumowych. Często biznes zakłada, że praca będzie skalować się liniowo, czyli że 3 zespoły dostarczą produkt 3 razy szybciej. Najczęściej to nierealne i prowadzi do rozczarowania.
Zmiany biznesowe
Zmiany sytuacji rynkowej, struktury organizacyjnej, a w końcu zmiana Product Ownera to najostrzejsze czynniki wpływające na rozumienie pracy planowanej przez zespół. Powoduje to coraz większą niepewność zespołu i duże zamieszanie w sposobie pracy, a w konsekwencji krytyczne zmiany dla wydajności zespołu. Taka sytuacja zwykle wymaga obecności Scrum Mastera, ponieważ zespół Scrumowy nie powinien zajmować się ponownym dostosowywaniem otoczenia biznesowego do zasad pracy Scruma.
Ciągłe zmiany na stanowiskach biznesowych skutkują chęcią wprowadzenia nowego porządku. "Jestem nowy na tym stanowisku, ale jestem świetny, pokażę wam, jak to się robi, bo przecież jasne jest, że mój poprzednik robił wszystko źle". Zespół musi wtedy stawić czoła konieczności opierania się zmianom, które mogą wpływać na jego pracę. Przesadzone planowanie, tworzenie raportów dających złudne poczucie kontroli, mechaniczne porównywanie wydajności zespołów i pojedynczych developerów - z takimi działaniami zespół musi sobie radzić bez Scrum Mastera lub Agile Coacha.
Scrum Master ma wspierać zespół we wprowadzaniu zmian, z którymi ten zespół nie poradzi sobie samodzielnie. Jego obecność ogranicza negatywne skutki tych zmian. Najważniejsze jest to, by biznes zrozumiał, że opłaca się zapewnić stabilność środowiska pracy. Developerzy są inteligentni - poradzą sobie ze wszystkim, jeśli dostaną odpowiednią autonomię.