Szukałeś nowej pracy – i ją dostałeś.Zmieniłeś projekt, albo też w miarę wzrostu Twoich umiejętności poszerzyło się grono zespołów którym pomagasz. Niezależnie od tego, który z tych scenariuszy jest aktualny, raz na jakiś czas Scrum Masterom zdarza się rozpoczynać pracę z nowym zespołem. Jak najlepiej za to się zabrać? Jak szybko się wdrożyć i zacząć budować relacje? O czym warto pamiętać a jakich działań stanowczo unikać?
Równowaga dla Scrum Mastera
Na temat samej pracy Scrum Mastera zawsze mówiłem, że istotne w niej jest podtrzymywanie równowagi pomiędzy interweniowaniem, a wycofaniem się. Scrum Master, który jest pasywny i bierny zostaje po prostu osobą do wrzucania spotkań do kalendarza. Ale tak samo zły jest Scrum Master który mówi członkom zespołu, jak mają działać. Musi pozwalać drużynie scrumowej podejmować własne decyzje i uczyć się na własnych błędach, a jednocześnie od czasu do czasu wypychać ich ze strefy komfortu. Musi być trenerem dla zespołu, który pomaga im w osiągnięciu samozarządzania się.
Dołączając do nowego zespołu również musimy zachowywać pewną równowagę. Z jednej strony obserwować, jak pracuje nasz zespół i jakie ma potrzeby. Musimy zebrać trochę informacji zanim zaczniemy dawać zalecenia czy oceny. W przeciwnym razie mogą one się okazać błędne i będziemy gorzej niż bezużyteczni. Możemy też przesadzić w drugą stronę i będziemy tylko biernie siedzieć na spotkaniach, czytać dokumentację i mieć zero wpływu na skuteczność zespołu.
Nowi Scrum Masterzy w zespołach z jednej strony często czują się przedawkowani informacjami, a z drugiej męczy ich poczucie winy, bo nie robią tak naprawdę nic sensownego. Jak więc zabrać się za nowy zespół poprawnie?
Pierwszy krok – najważniejszy
SM nie może działać skutecznie bez odpowiednich relacji z ludźmi z którymi pracuje. Dlatego pierwszym krokiem będzie zacząć te relacje budować. Musimy poznać wszystkie nowe osoby z którymi będziemy pracowali: Developerów, Product Ownera, Interesariuszy i ludzi dookoła. Bardzo ważne jest na samym początku ustalić oczekiwania obu stron co do tego, jak będzie wyglądała współpraca.
Dobrą praktyką, którą polecam, jest przygotowanie krótkiej prezentacji na temat własnych obowiązków. „Jestem tu po to, żeby doradzać w stosowaniu praktyk zwinnych, pomagać rozwiązywać problemy i rozwijać mocne strony zespołu. Nie jestem tu po to, żeby robić notatki po spotkaniach bądź zatwierdzać timesheety członków zespołu.”
Poza tym, warto porobić jakieś ćwiczenia z integracji zespołu, żeby zapoznać się nie tylko pod względem obowiązków, ale też osobistym. To ulepsza atmosferę i zwiększa zaufanie zespołu. Scrum Master powinien zadbać, żeby jego/jej wizerunek w umysłach osób, z którymi pracuje wyglądał bardziej jako: „ten otwarty człowiek, który pomaga i z którym łatwo się dogadać”, niż jako: „ten gość, który zajmuje się nie wiadomo czym, wrzuca nam spotkania i mówi, że wszystko robimy źle”.
Jak uniknąć Analisys Paralysis
Bez odpowiedniej wiedzy nie da się dać sensownych zaleceń. Razem z tym, zbieranie wiedzy może okazać się niekończącym się procesem. Jak uniknąć tego zamkniętego kręgu?
Pierwszą najbardziej oczywistą rzeczą są wydarzenia zespołowe. Przez pierwszy Sprint czy dwa warto poobserwować, jak zespół przeprowadza Daily, Retro, Planowanie i tak dalej. Potem SM może je facylitować i od razu pokazać zespołowi, jak przeprowadzać je skutecznie(j).
Często może się okazać, że niektóre z tych wydarzeń są przeprowadzane w niewłaściwy sposób, a inne mogą w ogóle być nieobecne. Jeżeli Daily trwa 40 minut to już jest okazja dla SM-a, żeby udowodnić swoją pożyteczność. Analogicznie, jeżeli Retro nie odbywa się regularnie bądź co Sprint są te same akcje. Retrospektywy ogólnie są jak Eldorado wiedzy dla Scrum Mastera w nowym zespole.
To samo dotyczy jakichkolwiek antywzorców i odstępstw od dobrych praktyk. Jest to dobra okazją dla SM-a, żeby wesprzeć zespół i pomóc mu wdrożyć cały workflow.
Kolejną rzeczą jest „Backlog wiedzy”. Są pewne rzeczy o produkcie oraz procesach, które SM musi wiedzieć:
- Kto jest klientem i jakie ma oczekiwania?
- Skąd się biorą wymagania?
- Jakie są obecne wyzwania i ograniczenia?
- Jakie są zewnętrzne współzależności?
- Jakie są cele biznesowe i jak wygląda obecny postęp? Kto i jak sprawdza ten postęp?
- Czy obecne są DoD i DoR? Czy są aktualne? Czy są przestrzegane?
Wszystkiego wymienić nie sposób, ponieważ zależy to też od konkretnego produktu, ale idea jest prosta: wypisujemy sobie te pytania, a potem zastanawiamy się, czy znamy na nie odpowiedzi. Jeżeli nie – to zwracamy się do odpowiednich ludzi bądź źródeł w celu uzupełnienia braków. W taki sposób układamy konkretny, mierzalny plan do działań, zamiast tkwić w ciągłym „obserwowaniu”. Jeżeli lista wyjdzie zbyt długa, warto ją spriorytezować – dokładnie tak, jak to się to robi z Backlogiem.
Wdrożenie się do organizacji
Jeżeli dołączamy nie tylko do nowego zespołu, ale i firmy, to tak samo powinniśmy wdrożyć się w proces wspierania całej organizacji. To ma dużo podobieństw do wdrażania się do zespołu. Warto poznać ludzi, takich jak: managera wydziału bądź portfolio, do którego należymy, Agile Leadów/Coachów (jeżeli są), innych Srum Masterów. I zacząć budować z nimi relacje, oczywiście. Jeżeli jest jakaś Agile gildia, koniecznie zaczynamy w niej uczestniczyć. Jeśli nie ma – to możemy ją założyć.
Pewnym paradoksem w pracy Scrum Mastera jest to, że im dłużej on/ona pracuje z zespołem, tym lepiej ten zespół zna i tym bardziej pożyteczny/a potrafi dla tego zespołu być. Jednocześnie, im dłużej zespół współpracuje z kompetentnym SM-em, tym bardziej robi się samodzielny i tym mniej tego SM-a potrzebuje. To swoją drogą doprowadza do tego, iż rozwój kariery SM’a wiąże się ze skalowaniem swoich obowiązków. Im większe seniority, tym bardziej Scrum Master spędza czasu służąc organizacji niż poszczególnej drużynie. A więc opłaca się zakładać fundament do przyszłej współpracy na poziomie firmy od samego początku.
