Zacznę od tego, że rolą Scrum Mastera jest wspieranie zespołu. Co za tym idzie jedyną miarą sukcesu Scrum Mastera jest rezultat pracy zespołu oraz efektywność współpracy. W jaki sposób jako Scrum Master mam wpływ na pracę zespołu?
Obserwuję
Czyli po prostu patrzę jak zespół pracuje. Najlepiej na spotkaniach, ale również w trakcie codziennej pracy. Przyglądam się zachowaniom i rozmowom (lub ich braku). Staram się zrozumieć czy ludzie sobie ufają i czy się nawzajem wspierają w trakcie codziennej pracy. Kiedy i w jaki sposób ze sobą rozmawiają? W jaki sposób podejmują decyzje? Jak sygnalizują i rozwiązują problemy? Czy są ludzie, którzy monopolizują dyskusje lub tacy, którzy milczą? Czy wiedzą, dlaczego robią to, co robią?
(Zobacz również Scrum Master – Mistrz obserwacji)
Pokazuję, co widzę
Jeżeli coś zauważyłem, to działam jak lustro. Przekazuję informację zwrotną. Opisuję to, co widzę z mojej perspektywy. Staram się być bezstronny, unikać faworyzowania i narzucania rozwiązania. Jest to szczególnie trudne, bo często mam swoje zdanie i zwykle czuje się bardziej związany z “moim” zespołem niż z kimkolwiek innym w organizacji.
Jeżeli mówienie nie jest wystarczające, to sięgam po wizualizację. Może zrobię wykres pokazujący ile elementów zespół dostarcza co Sprint, a ile nowych się pojawi w tym samym czasie w backlogu. Może pokaże im ilość błędów, lub czas ich rozwiązywania. Może powieszę ich zasady współpracy albo DoD na ścianie.
Edukuję
Jeżeli zakładam, że to, co widzę wynika z niezrozumienia, braku wiedzy lub narzędzi to wytłumaczę jakie mogą być przyczyny. Pokażę kilka rozwiązań, które widziałem w innych zespołach. Zaprezentuję konkretną technikę. Podeślę linki do artykułów lub filmów. Zorganizuję warsztat, gdzie będziemy mogli w bezpiecznym środowisku przetestować nowe narzędzia lub zrozumieć skąd biorą się nasze problemy. Wytłumaczę dlaczego używamy jakiejś praktyki i kiedy nie należy z niej korzystać. Pokażę, jakie są konsekwencje, gdy na koniec Sprintu nie mają działającego produktu.
(Zobacz Zasady Scrum)
Pytam
Najczęściej jednak zakładam, że zespół sam jest w stanie rozwiązać swoje problemy. Dlatego zadaję pytania. “Czy to może być problemem?”, “Jakie macie opcje?”, “Jak chcecie to zaadresować?”, “Co jeszcze możecie zrobić?”, “Czy Wasz plan jest realny?”.
(zobacz Kto pyta, nie błądzi)
Pozwalam im się potknąć
Jeżeli zwróciłem zespołowi uwagę na jakiś problem, powiedziałem o konsekwencjach, zapytałem co chcą z tym zrobić i zespół wciąż z entuzjazmem Titanica zmierza w jego stronę, to pozwalam mu się potknąć. Nic lepiej nie uczy jak własne błędy, a wtrącenie się w to, co robią mogłoby tylko spowodować, że oddadzą mi odpowiedzialność i za każde niepowodzenie będą winić mnie.
Interweniuję
Oczywiście, popełniać błędy możemy jedynie w bezpiecznym środowisku. Dlatego jeżeli widzę, że sytuacja robi się naprawdę gorąca to wkraczam do akcji zanim ludzie powiedzą słowa, których będą żałowali jeszcze długo. Czasami polega to na przerwaniu spotkania lub wręcz przeciwnie, zorganizowaniu takiego.
Pracuję z Product Ownerem
Na początku zwykle skupiam się na samym zespole, ale szybko staram się przerzucić moje siły na sam produkt i to w jaki sposób są priorytetyzowane potrzeby użytkowników. Jak jest ustalany zakres najbliższego wydania. W jaki sposób współpracujemy z interesariuszami. Czyli pomagam Product Ownerowi zrozumieć jego rolę, pokazać narzędzia przydatne w jego pracy a także poprawić jego komunikację z zespołem, interesariuszami i użytkownikami.
(Zobacz Kim jest Product Owner)
Zmieniam Organizację
Wiele problemów, które odkrywam ma swoją przyczynę poza zespołem. Dlatego pracuję na poziomie organizacji i pokazuję co i jak wpływa na zespół, jego pracę i produkt. To trudne zadanie, bo często muszę rozmawiać z “ważnymi” osobami, mimo że sam nie zawsze jestem wysoko umocowany w organizacji. A jak to kiedyś powiedział Ken Schwaber
“Martwy Scrum Master to bezużyteczny Scrum Master.”
Jeżeli więc chcę uniknąć rozstania się z moim pracodawcą i zespołem, muszę zrozumieć swoją strefę wpływu, jak działa firma i w jaki sposób mogę wpływać na osoby decyzyjne.
Tłumaczę konsekwencje obowiązujących procedur i zachowań osób spoza zespołu. Uczę czym jest Agile i Lean. Pokazuję, jak obecnie działa organizacja, co przez to traci i co mogłaby uzyskać zmieniając sposób funkcjonowania.
Dbam o praktyki inżynieryjne
Zwinne praktyki inżynieryjne (Agile Engineering Practices) to coś co kuleje u wielu zespołów. Nic dziwnego, dużo łatwiej jest wprowadzić 15 minutowe Daily niż zautomatyzować wszystkie testy. Bez tego zespół nie będzie mógł dostarczać działającego (zgodnego z definicją ukończenia, czyli DoD) produktu na koniec każdego Sprintu. Muszę więc pomóc zespołowi zrozumieć wartość takich praktyk jak Continuous Integration, Pair Programming, Refactoring, czy Test Driven Development.
(Zobacz Scrum is hard)
Buduję bezpieczne środowisko
Zespół może eksperymentować tylko wtedy, gdy czuje się bezpiecznie. Dlatego czasami pojawia się potrzeba, żebym chronił zespół przed Product Ownerem, interesariuszami, czy wreszcie przed sobą samym. Oczywiście zawsze staram się wytłumaczyć, dlaczego coś robię i nauczyć zespół, żeby chronił się sam.
Usuwam przeszkody
Oczywiście nie wszystkie. Wiele z nich zespół może rozwiązać sam, a ja nie jestem niańką, która ma wiązać innym buty. Jednak na początku zespół może czuć się zagubiony i każda, nawet najprostsza, pomoc bywa przydatna. Może trzeba zdobyć licencję na oprogramowanie, albo fizyczną tablicę na ścianę. Wraz z rozwojem zespołu staram się mu pokazywać, jak sam może usuwać przeszkody stojące przed nim. Pomagam również poprzez pokazywanie całej organizacji konsekwencji tych przeszkód, ot chociażby kosztów nie posiadania środowiska testowego.
Buduję relacje
Jeżeli mam być efektywny, muszę zbudować relacje z ludźmi, z którymi współpracuje. Dlatego często możesz spotkać mnie przy automacie do kawy, czy na spotkaniach innych zespołów. Zawsze chcę też porozmawiać z każdym członkiem mojego zespołu i Product Ownerem.
Przypominam
To, że raz zwróciłem na coś uwagę nie znaczy, że wszyscy rzucą się z ochotą do naprawy problemu. To, że raz coś pokażę nie spowoduje, że zmienią się zachowania w organizacji. Dlatego wytrwale przypominam o ważnych rzeczach i z uporem pokazuje problemy i pomagam znaleźć rozwiązanie. Czasami zajmuje to miesiące, ale jak to powiedział jeden klient “chodził, chodził aż wychodził”.
Kwestionuje Status Quo
Wiele zespołów i organizacji jest tak zajętych tym, co jest do zrobienia, że nie ma czasu się zastanowić, czy w ogóle jest sens to robić. Dlatego swoimi pytaniami staram się kwestionować status quo. Próbuję zrozumieć jaki jest cel tego, co robią i jakie są konsekwencje. Czy są one spójne z tym co chcemy osiągnąć? Czy możemy to uzyskać inaczej? Pokazuję inną perspektywę, organizuję warsztaty, które pozwalają nam się zastanowić nad tym co robimy.
Uczę się
Mimo, że wspieram zespoły od ponad dekady to ciągle spotykam sytuacje, które wymagają ode mnie zdobycia nowej wiedzy i umiejętności. Czy to pierwsze eksperymenty w Scrumie w Sprzedaży, próba stworzenia nowej struktury organizacji, czy użycie nowego narzędzia. Na szczęście wokół mnie są trenerzy i Agile Coachowie gotowi do dzielenia się swoim doświadczeniem. Dzięki temu mogę przyznać się do swojej niewiedzy i liczyć na ich pomoc.
(Zobacz Scrum)
A w zamian za to…
Dobry Scrum Master to nie jest osoba, która tylko poprowadzi Daily i ma wolne na resztę dnia. Bycie Scrum Masterem to robota na pełen etat. Dzięki temu pomagam firmie znaleźć i rozwiązać problemy, budować zespoły, dostarczać niesamowite produkty i tworzyć organizację gotową na zmiany.
