Drugi list do Scrum Masterów
Wszyscy zapewne już czytali mój „List do Scrum Masterów” (nie czytali? nadrobić!). Wpisuje się on dość dobrze w to, na co kładziony jest największy nacisk podczas szkolenia Scrum Masterów oraz później przy dalszym rozwoju w kierunku Agile Coacha (np. w naszej Agile Coaching Academy) – oduczenie ludzi postawy dyrektywnej. Innymi słowy pisząc ów list jak zwykle myślałem o wybiciu ludziom z głowy rozwiązywania problemów zespołu metodą zarządzenia jak ma być, rodzielenia co kto zrobi i poganiania do roboty metodą kija i marchewki. Przekaz jest w skrócie taki: jako Scrum Master nie decydujesz, nie narzucasz, nie kierujesz i nie mówisz ludziom co konkretnie mają robić.
Poświęcanie uwagi walce z postawą dyrektywną jest dlatego uzasadnione, że jest to postawa domyślna, najczęściej przyjmowana przez ludzi zupełnie odruchowo, która kompletnie nie buduje zespołu. Odejście od niej wymaga świadomego wysiłku – pisząc i mówiąc o tym dużo staramy się Scrum Masterów zachęcić do podjęcia tego wysiłku.
Jednak ostatnio obserwuję coraz częściej zjawisko, które każe mi się zastanowić czy ten przekaz nie jest aby zbyt jednostronny. Mianowicie zaczynam się spotykać z problemem niejako odwrotnym – problemem Scrum Mastera „bezradnej sierotki”. Jest to taki Scrum Master, który nie próbuje nic zespołowi narzucać i w ogóle nic nieprzyjemnego o nim samym mu nie mówić, żeby przypadkiem nie zaburzyć samoorganizacji albo nie wyjść z wąsko postrzeganej roli „servant lidera” rozumianego najczęściej jako „dobry wujek”. Dobry przykład to pewien Scrum Master, który żalił się, że jego zespół ma złą relację z Product Ownerem i bardzo się zdziwił na uwagę, że ta relacja znacznie by się poprawiła gdyby zespół zaczął dostarczać co sprint działającą wersję produktu z funkcjami, których PO oczekiwał. A jeszcze bardziej się zdziwił kiedy otrzymał sugestię, że jest jego zadaniem coś z tym zrobić – w szczególności powiedzieć zespołowi, że sobie nie radzą i skłonić do zastanowienia się co mogliby robić lepiej tak, żeby to zmienić.
Dobrzym przykładem sytuacji, w której Scrum Master działa dyrektywnie i konkretnie zarządza jak ma być to wprowadzanie Scruma w zespole, który wcześniej z niego nie korzystał. Wtedy konieczne jest często bezdyskusyjne narzucenie wszystkich jego elementów. Oznacza to, że Scrum Master po prostu mówi, że będzie Daily Scrum (do dyskusji w zespole może być o której dokładnie godzinie i ew. gdzie ma się on odbywać), że będzie Sprint Backlog (do dyskusji zespołu w jakiej dokładnie formie i ew. gdzie ma wisieć), że będzie Kryterium Ukończenia (Definition of Done – do dyskusji zespołu co dokładnie w nim będzie) – i tak dalej. Również obecność członków zespołu na Daily czy Retrospekcji nie jest do dyskusji – Scrum Master ma prawo tego wręcz wymagać.
Pierwszy, drugi, trzeci Daily Scrum Scrum Master powinien poprowadzić, wręcz pokazując ludziom w zespole co mają mówić. Ale oczywiście już od pierwszego Daily Scruma SM nie powinien „odbierać raportów” czy stać w centrum pozwalając, by ludzie do niego mówili. Już wtedy może też np. wprowadzić jakiś element zapobiegający stałemu mówieniu w tej samej kolejności (np. jakiś token).
Za to pierwsze retrospekcje powinien Scrum Master po prostu poprowadzić od A do Z, przygotowując odpowiednie ćwiczenia zawczasu, nie oczekiwać, że ktoś z zespołu będzie chciał to zrobić. I trzymać się tego tak długo, aż po zespole nie zacznie być widać, że zaczynają rozumieć po co te wydarzenia są. Wtedy można zacząć proces przechodzenia z postawy nauczyciela ku postawie bardziej doradcy, mentora i coacha.
Podobnie, jeśli doświadczony, dojrzały zespół popadnie w jakąś patową sytuację Scrum Master może musieć zdecydowanie wkroczyć, zarządzić spotkanie, dyskusję, ekstra retrospekcję itp. a więc użyć posiadanych przez siebie narzędzi do przywrócenia zespołu do dobrego stanu. Gdy tylko zespół zacznie ogarniać swoje problemy natychmiast Scrum Master wycofuje się pół kroku na pozycję coacha zespołu.
Tak więc na wszelki wypadek piszę wyraźnie: nie jest tak, że jako Scrum Master nie masz w ogóle prawa nic nigdy narzucić, zwrócić uwagi czy pokazać, że coś jest nie tak. I w ogóle bycie Scrum Masterem nie zawsze polega na byciu miłym a już z pewnością nie polega na utrzymywaniu zespołu w dobrym samopoczuciu i błogostanie. Przeciwnie, czasem trzeba wytknąć ukrywane problemy i zmusić zespół do zmierzenia się z nimi, choć może to być dla zespołu nieprzyjemne. I oczywiście Scrum Master nie podejmuje decyzji technicznych, architektonicznych, nie rozdziela pracy itp. – jego interwencje dotyczą utrzymania spoistości i sensowności procesu oraz dobrostanu zespołu, polegają głównie na zarządzeniu spotkań, wprowadzaniu praktyk, pilnowaniu by zespół przestrzegał swoich własnych zobowiązań i umów.
Oczywiście, wkraczanie i zarządzanie to są te elementy postawy Scrum Mastera, które stosować należy rozsądnie i z rozwagą. Bardzo wiele zależy od etapu życia zespołu i stopnia jego rozwoju. Szczególnie na początku oraz w sytuacjach kryzysowych Scrum Master musi czasem po prostu „przejąć sytuację”. Dlatego nie bójcie się tego robić gdy sytuacja tego wymaga, ale upewnijcie się, że tak jest zanim to zrobicie. Linia między „bezradną sierotką” a kierownikiem jest cienka – po niej właśnie powinien poruszać się Scrum Master. Dlatego to taka trudna rola.