W czasie ostatniego spotkania na Zwinnej Łodzi, na której prezentowałem swoją opowieść o ścieżce kariery agilowej, 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 projektu, koordynowanie prac pomiędzy zespołami czy przynoszenie do zespołu jakichś nowych wytycznych z organizacji i wdrażanie ich.
Pytanie jest o tyle dobre, że sięgało do istoty problemu, obaj z pytającym 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 kwestie merytoryczne:
- Usuwanie pośredników – usuwanie głuchego telefonu którego istnienie jest często nieświadome, 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 review. Albo zajrzyj w backlog poprzednich sprintów. Chcesz żeby zespół coś dla Ciebie zrobił – przyjdź do nas na planning, pozwól się zaprosić na retro.
- Budowanie odpowiedzialności w zespole – taka inspiracja „Scrum Mastery” żeby być SMem, który rozwija cały zespół w odpowiedzialności za całość produktu, nawet jeśli oznacza to „kłopotanie” zespołu rzeczami innymi niż development. Moim zdaniem ślepą uliczką jest odciążanie zespołu od tych innych rzeczy (raporty, komunikacja, itd.) – w długim okresie czasu takie rzeczy należy optymalizować (nie powiem usuwać, bo to może być zbytnie uproszczenie), w krótkim nie chować, nie plastrować.
- 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.
Realizacja powyższych punktów w praktyce może się dziać między innymi dzięki rzetelnie przeprowadzanym i angażującym Retrospektywom. Jak je przeprowadzić porządnie? Sprawdź mój webinar o Retrospektywie Sprintu.
I jak o tym piszę, to ostatnia refleksja – każdy z tych punktów jest nadal równie prawdziwy a może jeszcze prawdziwszy dla roli Agile Coacha…