Dlaczego Scrum Master nie powinien być pośrednikiem?

W czasie wystąpienia w zeszłym roku na społeczności w Łodzi (Zwinna Łódź) dostałem bardzo dobre pytanie: „a tak w zasadzie, to co jest złego w tym, że Scrum Master bywa pośrednikiem między firmą a zespołem”. Chodziło o mój przykład życia, gdy odradzam z własnego doświadczenia, by SM brał na siebie odpowiedzialność za na przykład raportowanie statusu postępu prac, koordynowanie zadań pomiędzy zespołami (w ramach jakiegoś układu skalowania Scruma) czy przynoszenie do zespołu jakichś nowych wytycznych z organizacji i wdrażanie ich. W niektórych firmach Scrum Master jest traktowany jako specyficzny rodzaj menedżera, które może być traktowany jako reprezentant i tuba informacji pomiędzy zespołem a firmą. Pytanie “co jest nie tak w tym pośrednictwie” jest o tyle dobre, że sięgało do istoty problemu, obaj z pytającym w krótkiej rozmowie kuluarowej zgodziliśmy się, że samo stwierdzenie „Scrum Guide tak każe” nie jest dla nas wystarczające.

W temacie przychodzą mi do głowy trzy argumenty merytoryczne:

  1. Usuwanie pośredników – usuwanie głuchego telefonu, którego istnienie jest często nieuświadomione, a każde kolejny szczebel przekazywania informacji bezwiednie zmienia niuanse komunikatu. Stąd SM powinien dążyć do tego, żeby różnego rodzaju komunikaty do i z zespołu przechodziło bezpośrednio między nadawcą a odbiorcą. Chcesz się dowiedzieć jaki jest status prac – przyjdź na Sprint Review. Albo zajrzyj w backlog poprzednich sprintów. Chcesz żeby zespół coś dla Ciebie zrobił – przyjdź do nas na Sprint Planning, pozwól się zaprosić na Retrospektywę. Scrum Master nigdy nie będzie miał tak pełnego obrazu sytuacji i nie zada tych pytań, które zadałby cały zespół, ze swoją różnorodnością perspektyw. I z punktu widzenia załatwiania takich tematów porządnie – warto zadbać, by ten kto dociera do zespołu w reakcji na odmowę SMa zostania pośrednikiem sam też nie był czyimś pośrednikiem. SM powinien dążyć do tego, by połączyć źródło danego tematu (pomysłu, decyzji) z zespołem.
  2. Budowanie odpowiedzialności w zespole – inspiracja pochodząca z lektury książki „Scrum Mastery”: warto się postarać żeby być nie tylko dobrym, ale świetnym SMem. Świetny Scrum Master rozwija cały zespół w odpowiedzialności za całość produktu, nawet jeśli oznacza to „kłopotanie” zespołu rzeczami innymi niż “czyste wytwarzanie oprogramowania”. Moim zdaniem ślepą uliczką jest odciążanie zespołu od tych innych rzeczy (raporty, komunikacja, spotkania z użytkownikami itd.) – w długim okresie takie rzeczy należy optymalizować, a w krótkim nie chować, nie plastrować, tylko wyciągać na światło dzienne. Zespół widząc cały kontekst tego, co jest potrzebne do zrobienia w produkcie i w ramach jego rozwoju, może lepiej zrozumieć potrzeby klientów i organizacji, może pomóc w zorganizowaniu jakiegoś usprawnienia, które odciąży konkretne role (np. PO czy SM).
  3. Nie branie na siebie nie swojej odpowiedzialności – SM (zwłaszcza z korzeniami menedżerskimi albo PMowymi) może mieć ochotę wykazać się w zespole i przejąć tematy koordynacyjne. Niektóre z nich bardziej pasują do zestawu odpowiedzialności Product Ownera (praca z interesariuszami, odpowiedzialność za decyzje w produkcie), inne powinny być w całym zespole (dbałość o jakość, znalezienie sposobu na współpracę pomiędzy zespołami). SM zabierający na siebie te odpowiedzialności, zwłaszcza robiąc to niejawnie, osłabia role innych członków zespołu, jednocześnie zaburzając czystość swojej odpowiedzialności w Scrumie. To zaburzenie czystości swojej roli może być szczególnie spotęgowane, jeśli otoczenie zespołu (management, inne zespoły) zacznie traktować Scrum Mastera jako przedstawiciela zespołu w różnych sprawach, które do niego nie należą i wzmacniać nieoptymalny układ. W skrajnym przypadku prowadzić to może do zupełnie złego wykształcenia roli i odpowiedzialności Scrum Mastera w firmie. Pośrednictwo w przekazywaniu informacji może szczególnie nieszczęśliwie wyjść, jeśli SM jest posłańcem jakiejś nieprzyjemnej dla zespołu informacji – jakiś nowy obowiązek, nowa polityka firmowa czy feedback z innego poziomu zarządzania. “Posłaniec” nie jest autorem tego przekazu, ale jest zobowiązany dotrzeć do adresatów. Adresaci mogą nieświadomie postrzegać Scrum Mastera jako stronnika firmy (czyli kogoś poza zespołem).

Mocnym adwokatem pogłębiającym w moich oczach tematykę usuwania pośredników jako sposobu radzenia sobie ze złożonością w organizacjach i produktach jest Dave Snowden (autor Cynefina), z którego materiałów w tym temacie mogę polecić na start choćby krótki wpis pt. “Disintermediation”.

I na koniec refleksja – każdy z tych punktów powyżej jest równie prawdziwy dla roli Agile Coacha  (osoby budującej kompetencje zwinne na poziomie całej organizacji) jak i Product Ownera. Przykładowo Właściciel Produktu może wciągać swój zespół również w tematy, które bez trudu załatwiłby samodzielnie – zaproszenie zespołu do wczesnych faz kreatywnych z mojej praktyki brzmi zawsze jak dobry pomysł (przy założeniu, że te działania są dobrze zmoderowane), a nadal spotykam Ownerów, którzy wolą by ich zespołu skupiły się na developmencie w czasie gdy oni odkrywają potrzeby klientów.

Od autora: Artykuł w pierwszej wersji pojawił się na moim blogu kubaszczepanik.pl i zebrał tam sporo wizyt. Pomyślałem, że nadaje się do tego, by po lekkim rozszerzeniu również zawrzeć go na portalu z szerszym gronem odbiorców.

Źródło zdjęcia „soapbox zone”: https://flic.kr/p/6HQSUD Autor: ruminatrix na licencji CC BY-NC-ND 2.0

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x