Jak obiektywnie ocenić pracę Scrum Mastera?

0

Cześć, jestem tutaj nowy, ale mam nadzieję, że piszę w dobrym dziale.

Od roku jestem teamleaderem w firmie (w praktyce zajmuję się rekrutacją osób technicznych na nowe stanowiska, formowaniem teamów itd - piszę o tym, bo wiem, że w każdej firmie teamleader robi co innego), wcześniej byłem w tej firmie przez 4 lata developerem.
Od początku pracowaliśmy w scrumie, ale bez scrum mastera. Firma się mocno rozrastała, teraz zatrudniamy ok. 150 programistów, devopsów i testerów.
Zarząd wymyślił, że dobrze by było wdrożyć Scruma "poprawnie", czyli ze scrum masterem. Pół roku temu doszedł do nas 1 scrum master, zostały mu przydzielone 2 teamy.

Teraz zarząd prosi mnie o wypisanie korzyści jakie przynosi nam Scrum Master. Mam tutaj ogromny problem, gadałem z developerami i oni nie widzą różnicy. Scrum master nie wprowadził praktycznie żadnej nowej rzeczy w teamie (czyli wychodzi na to, że dobrze implementowaliśmy scrum, mimo braku scrum mastera).
Product owner cieszy się, że ma 1 spotkanie do prowadzenia mniej (retrospektywa) oraz cieszy go to, że jeśli ma jakieś wątpliwości jak coś zrobić w scrumie to pyta scrum mastera zamiast szukać po internetach.

Obawiam się, że zarząd nie przekona się do tych odpowiedzi. Myślałem, żeby jeszcze z rzeczonym scrum masterem pogadać, ale boję się że się wystraszy.

Macie jakiś pomysł, żeby ocenić obiektwynie czy scrum master wykonuje dobrą pracę czy nie? Czy powinniśmy dowozić szybciej dzięki SM-owi?
Za cholerę nie wiem jak do tego podejść. Nieraz broniłem programisty przed zarządem, gdy np. zarząd uważał, że dany programista się obija, ale tutaj nie mam żadnych pomysłów. Na dobrą sprawę nie wiem co robi scrum master przez cały dzień oprócz bycia na spotkaniach teamowych i prowadzenia retrospektywy.

15

Sam sobie odpowiedziałeś "gadałem z developerami i oni nie widzą różnicy". Skoro nie widać różnicy to po co przepłacać?

4

Scrum master nie powinien być rolą na pełen etat w jednym zespole - on jest właśnie od naprawiania procesu. Jak zespół jest dojrzały i wie jak robić scrum, to scrum master wypełnił swoją rolę i może przejść do następnego zespołu.

2

Tak, jak napisał powyżej @ralf - skoro gadałem z developerami i oni nie widzą różnicy to znaczy, że jego wprowadzenie nic nie dało.

Myślałem, żeby jeszcze z rzeczonym scrum masterem pogadać, ale boję się że się wystraszy

No ale z drugiej strony, koleś bierze kasę (i to pewnie niemałą) za swoje usługi, więc powinien sam się umieć obronić, pokazać do czego jest przydatny, co dzięki niemu idzie sprawniej itp. Bo tak w sumie to czytając to, co napisałeś, to jedynym pożytkiem z trzymania tego kogoś jest fakt, że PO ma jedno spotkanie mniej :D

Nieraz broniłem programisty przed zarządem, gdy np. zarząd uważał, że dany programista się obija, ale tutaj nie mam żadnych pomysłów

Ale czemu masz go bronić? Jedyny wyjątek, to jeśli tym SM jest jakaś seksowna 24-letnia blondynka z dużym dekoltem, z którą planujesz się bliżej poznać. Bo we wszystkich innych przypadkach to, co napisałeś nie ma sensu. Skoro koleś nic soba nie wnosi (nie twierdzę, że się obija i ściemnia, a jedynie bazuję na tym, co napisałeś - że nie widać efektów, nie wiesz jak uzasadnić jego trzymanie, a ponadto jeszcze sam nie wiesz, co on właściwie robi i po co jest w firmie) to znaczy, że z biznesowego punktu widzenia jest dla firmy jedynie zbędnym wydatkiem. Jak fontanna w holu, chociaż fontanna przynajmniej fajnie wygląda i może robić wrażenie na klientach.

3

A ja uważam ze jest inny problem: wprowadzenie Scrum mastera nic nie dało, bo ktoś wykonywał jego zadania i dalej to robi. Np kontakt z biznesem, ustalanie backloga, organizację spotkań i trzymanie porządku na nich itp itd. Albo macie słabego SM i nie potrafi się przebić przez to co już było zastane, albo robi taką robotę, o jakiej nie macie pojęcia, że jest do zrobienia. Jak dobrze pamiętam to w "Scrum Guide" jest kto jest od czego i jakie są jego obowiązki.

5

Myśle że właśnie dokonałeś obiektywnej oceny ;) W rzeczywistości jeśli zespoły są doświadczone, to taka pozycja w ogóle nie jest potrzebna, albo może być realizowana na jakiś ułamek etatu przez team leadera. Scrum Master na cały etat to jakaś abominacja, albo jak macie team samych juniorów.

3

robi taką robotę, o jakiej nie macie pojęcia, że jest do zrobienia

Dlatego też pisałem w poprzednim poście, że zamiast bać się że się wystraszy, to OP powinien pogadać z tym SM i dowiedzieć się, co on konkretnie robi, jak widzi swoje miejsce w firmie, dać mu szansę się obronić. I wtedy od razu będzie jasne, czy koleś rzeczywiście pracuje i będzie miał coś ciekawego do powiedzenia (o czym być może OP nie wie), czy zacznie się jąkaś i rzucać jakieś slogany. W drugim przypadku jasne będzie, że to jest jedna wielka ściema, którą wypadałoby zakończyć jak najszybciej.

1
Tomek Pycia napisał(a):

A ja uważam ze jest inny problem: wprowadzenie Scrum mastera nic nie dało, bo ktoś wykonywał jego zadania i dalej to robi. Np kontakt z biznesem, ustalanie backloga, organizację spotkań i trzymanie porządku na nich itp itd. Albo macie słabego SM i nie potrafi się przebić przez to co już było zastane, albo robi taką robotę, o jakiej nie macie pojęcia, że jest do zrobienia. Jak dobrze pamiętam to w "Scrum Guide" jest kto jest od czego i jakie są jego obowiązki.

Tym zajmuje się bardziej product owner, on ma wiedzę o produkcie i ustala np. roadmapę z biznesem. Podobnie z backlogiem, organizacją spotkań (refinementy prowadzi albo PO albo jeden z developerów, jeśli taski są bardziej techniczne). Oczywiście Scrum master przebywa na tych spotkaniach, ale nic zbytnio nie wnosi, bo nie ma ani wiedzy technicznej ani wiedzy o produkcie (zresztą produkt jest bardzo techniczny, PO jest byłym devem).

2

Scrum master przebywa na tych spotkaniach, ale nic zbytnio nie wnosi, bo nie ma ani wiedzy technicznej ani wiedzy o produkcie

Kolejny raz sam napisałeś, że nie ma sensu go trzymać :D :D

0
mortadelek napisał(a):
Tomek Pycia napisał(a):

A ja uważam ze jest inny problem: wprowadzenie Scrum mastera nic nie dało, bo ktoś wykonywał jego zadania i dalej to robi. Np kontakt z biznesem, ustalanie backloga, organizację spotkań i trzymanie porządku na nich itp itd. Albo macie słabego SM i nie potrafi się przebić przez to co już było zastane, albo robi taką robotę, o jakiej nie macie pojęcia, że jest do zrobienia. Jak dobrze pamiętam to w "Scrum Guide" jest kto jest od czego i jakie są jego obowiązki.

Tym zajmuje się bardziej product owner, on ma wiedzę o produkcie i ustala np. roadmapę z biznesem. Podobnie z backlogiem, organizacją spotkań (refinementy prowadzi albo PO albo jeden z developerów, jeśli taski są bardziej techniczne). Oczywiście Scrum master przebywa na tych spotkaniach, ale nic zbytnio nie wnosi, bo nie ma ani wiedzy technicznej ani wiedzy o produkcie (zresztą produkt jest bardzo techniczny, PO jest byłym devem).

Ile ten SM pracuje w tym projekcie? To że projekt jest techniczny nie ma znaczenia. Kto ustala co ma ze sprint wylecieć jak biznes potrzebuje poprawkę na szybko?

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0