Długo zastanawiałem się nad tytułem dzisiejszego wpisu. Powodem była chęć znalezienia takiego, który maksymalnie odda jego sens. Dziś chciałbym zastanowić się wspólnie z Wami, czy i kiedy Scrum Master może podejmować decyzje. Decyzyjny SM, czy istnieje w ogóle coś takiego w przyrodzie?
Facylitacja
Zacznę od drugiego z najbardziej wyświechtanych słów w zwinności (pierwszym jest MVP). Facylitacja, bo o niej mowa, czyli bardziej po polsku umożliwienie zrobienia czegoś. Samo słowo „umożliwienie” jest już nacechowane bardzo neutralnie, no bo przecież jeśli umożliwiam to nie znaczy, że podejmuje decyzje. Skupiam się raczej na zagwarantowaniu środowiska, w którym taka decyzja może powstać.
Są miejsca, w których Scrum Master występuje w roli „członka Scrum Team„. W tych miejscach ma pewną decyzyjność, tj. tak samo jak pozostali członkowie zespołu może zadecydować o zrobieniu „czegoś”. Pierwszy z brzegu przykład to Retrospektywa, gdzie jako Scrum Master mogę i powinienem podzielić się swoimi przemyśleniami, ale również wpłynąć na kształt akcji, która się pojawi. Mam więc jako SM pewną decyzyjność w zakresie prac Scrum Teamu.
Zastanawiając się nad dzisiejszym tematem nie o taką decyzyjność jednak mi chodziło. Myślałem o możliwości narzucania samoorganizującemu się zespołowi sposobu pracy. Czy mieści się to w granicach facylitacji i odpowiedzialności SM?
Nie czas żałować róż, gdy…
„Nie czas żałować róż, gdy płoną lasy”, tak brzmi cytat z Juliusza Słowackiego. Różami w tym przypadku jest zwinność, samoorganizacja i samozarządzanie zespołów, płonącymi lasami zaś chaos, który nas otacza. Z tego chaosu raz na jakiś czas wyłania się duży problem, z którym musimy sobie poradzić. Nie raz i nie dwa mówiliśmy, że nie trzeba czekać do Sprint Retrospective, aby rozwiązać przeszkodę, którą los rzucił nam pod nogi. Ale czasem rozwiązanie tego typu sytuacji ad-hoc jest trudne, żeby nie powiedzieć niemożliwe. Czasem rozwiązań jest wiele, każde złe i nie ma nikogo, kto podejmie ostateczną decyzję i weźmie za nią odpowiedzialność.
O takiej sytuacji myślałem, pisząc o decyzyjnym Scrum Masterze. Przychodzi taki moment, w którym idealistyczny, zwinny, samoorganizujący się świat trzeba na chwilę schować do kieszeni i w imię wyższego dobra zacząć podejmować decyzję. Oczywiście, zaraz pojawią się głosy, że w ten sposób robimy za Zespół, że Zespół się nie uczy i nie wyciągnie wniosków na przyszłość. Zgadzam się z nimi! Tak właśnie będzie. Ale jest bardzo mało miejsc, gdzie w chwili kryzysu, kiedy wszystko się wali i pali, jesteśmy w stanie powiedzieć sobie: „spokojnie, mamy odpowiedzianych ludzi pracujących w zwinności, poradzą sobie, tylko potrzebują więcej czasu”. Zamiast tego bardzo często jest chaos i próba znalezienie rozwiązania na szybko.
Decyzyjny SM
Dlaczego napisałem akurat o decyzyjności Scrum Mastera? Powodów jest co najmniej kilka. Ta odpowiedzialność (pisząc o SM) jest najbliżej Scrum Teamu, najlepiej zna jego problemy i możliwości, posiada też doświadczenie bazujące na problemach, które pojawiły się w innych miejscach. Scrum Master patrzy na cały proces z oddali, zauważając rzeczy, których nie widzi nikt inny. W końcu Product Owner, który też mógłby takie decyzje podejmować zajmuje się inną działką procesu wytwórczego – Produktem.
Wydaje się, że to właśnie na Scrum Masterze ciążyć będzie odpowiedzialność za podejmowanie decyzji w sytuacjach krytycznych. Przykłady? Skierowanie deweloperów (wszystkich) do naprawy błędów z produkcji, które blokują nam rozwój jest jednym z nich. Czasem trzeba walnąć (przysłowiową) pięścią w stół i podjąć niewygodne decyzje, aby móc sobie później spojrzeć w lustro i powiedzieć, że zrobiło się wszystko, aby problem rozwiązać. Na tę jedną chwilę etykietę „Scrum Master” schowamy do kieszeni. Po rozwiązaniu problemu znów dumnie przyczepimy sobie ją na piersi, doglądając zwinnego procesu w ramach odpowiedzialności SM.
W tym przypadku trzeba jednak uważać. Może pojawić się pokusa, aby w sytuacji opisanej w dzisiejszym wpisie połączyć role Scrum Mastera z rolą Project Managera. Nie mam nic przeciwko takiemu łączeniu odpowiedzialności pod warunkiem, że Scrum Master robi co scrum masterskie, a Project Manager co project managerskie. W przeciwnym wypadku podejmowanie decyzji przesunie nas niebezpiecznie w stronę PM-a.
Na koniec pytanie do Was: czy Wasze organizacje wymagają od Was zachowania opisanego powyżej? Czy zdarzyło się Wam (często wbrew sobie) podejmować decyzje o sposobie działania Zespołu bez konsultacji z zainteresowanymi? Jestem bardzo ciekawy!
