Czy Scrum Master / Agile Coach musi się tłumaczyć z tego, co robi?

Tak, SM (a dotyczy to praktycznie w tym samym stopniu Agile Coacha) musi się tłumaczyć przed całym zespołem i firmą z tego co robi – w tym sensie, że musi wytłumaczyć pozostałym członkom zespołu swoją rolę, swoje zadania, swój dzień pracy. Zwłaszcza, jeśli zespół czy firma są nowi w temacie albo nieprzekonani – wtedy nieznajomość roli SMa prowadzi do uproszczenia „nic nie robi, jest niepotrzebny”. I nie ma co jako Scrum Master brać do siebie tego, że zespół będzie sceptyczny do naszej roli albo nisko oceniał pracę takiego SMa (zwłaszcza tą niewidoczną) – jak nie rozumieją to trzeba wytłumaczyć, a jak nie widzą efektów pracy, może trzeba unaocznić.

Czytaj dalej Czy Scrum Master / Agile Coach musi się tłumaczyć z tego, co robi?

Brak planu B przy planowaniu

Wczoraj byłem na review pewnego zespołu i Scrum Masterka zadała wspaniałe pytanie: „A jaki mamy plan B jak [plan działania] nie wypali?” (i zignoruję na chwilę kontekst w jakim to jest zadane, materiał na inny wpis…). Świetnie mi to koresponduje z przemyśleniem o którym planowałem napisać – nadmierny optymizm niektórych zespołów.

Czytaj dalej Brak planu B przy planowaniu

Dlaczego Scrum Master nie powinien być pośrednikiem

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:

  1. 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.
  2. 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ć.
  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.

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…