Jak obiektywnie ocenić pracę Scrum Mastera?

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.

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

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.

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.

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.

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.

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.

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).

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

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?

Pinek napisał(a):

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.

Scrum team składa się z

• project ownera
• scrum mastera
• development teamu

Można debatować po co komu scrum master, ale bez niego to nie jest scrum, tylko co najwyżej coś podobnego do scrumu.

A po co komu scrum master? Yyy żeby ogarniał terminy spotkań i rezerwował sale :D

cerrato napisał(a):

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

Gdyby to ode mnie zależało to wolałbym testera albo developera, który będzie pełnił funkcję SM-a, ale zarząd uznał, że lepiej nada się osoba bez backgroundu technicznego.
Dziwi mnie tylko to, że teraz niemal we wszystkim większych firmach są Scrum Masterzy, zwykle nietechniczni. To chyba musi im się opłacać w jakiś sposób? Po co trzymaliby kogoś kto nie dodaje żadnej wartości do teamu?

Gdyby to ode mnie zależało to wolałbym testera albo developera

no ale przecież to zależy od Ciebie - masz dać opinię dla zarządu, więc licza się z Twoim zdaniem i pytają, co sadzisz. Może po prostu pokaż im ten wątek, wtedy nie będzie jakichkolwiek wątpliwości odnośnie Twojego zdania w tej sprawie ;)

Azarien napisał(a):

Pinek napisał(a):

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.

Scrum team składa się z

• project ownera
• scrum mastera
• development teamu

Można debatować po co komu scrum master, ale bez niego to nie jest scrum, tylko co najwyżej coś podobnego do scrumu.

A po co komu scrum master? Yyy żeby ogarniał terminy spotkań i rezerwował sale :D

W projektach, których pracowałem w Scrumie, SM ogarniał mi rzeczy, które potrzebowałem od innych zespołów: adminów, testerów, bezpieczeństwa. Dogadywał rzeczy ze zewnętrznymi podzleceniowacami - co kiedy i jak.

Ile ten SM pracuje w tym projekcie? To że projekt jest techniczny nie ma znaczenia.

SM pracuje pół roku w 2 teamach. Nie wiem jakie opinie o tym scrum masterze mają w drugim teamie, bo oni nie podlegają pode mnie.

Kto ustala co ma ze sprint wylecieć jak biznes potrzebuje poprawkę na szybko?

Zwykle product owner ustala priorytety, ewentualnie któryś z devów, jeśli zostały taski utrzymaniowe.

mortadelek napisał(a):

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

A ja mam inne pytanie. Czego SM ma się wystraszyć? I co ma zrobić jak się wystraszy? Zwolni się sam zanim go zwolnią?

Może zarządź spotkanie na którym SM wytłumaczy co właściwie robi i opowie czemu jest potrzebny oraz pochwali się co udało mu się dokonać?
Albo w dwie osoby, albo przed całym zespołem. Ale uważaj! Słyszałem o przypadku, gdzie było powiedziane że na imprezie firmowej Scrum Masterzy powiedz co oni w zasadzie robią i żaden nie dotrwał do imprezy bo się pozwalniali :)

Azarien napisał(a):

Pinek napisał(a):

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.

Scrum team składa się z

• project ownera
• scrum mastera
• development teamu

Można debatować po co komu scrum master, ale bez niego to nie jest scrum, tylko co najwyżej coś podobnego do scrumu.

Kiedyś słyszałem że oryginalne objawione teksty mówią o tym że SM jest rolą przechodnią. Słyszałem że było to nawet praktykowane w Allegro. Programista mógł na jeden sprint odpocząć od programowania i bawić się w SM.
Z tego co zrozumiałem OPa to w jego zespole była rola łączona, PO robił też za SM i jeśli PO się wyrabiał to chyba nie ma sensu zatrudniać dodatkowego SMa

Ja bym tutaj był przeciwko dopytywaniu się samego scrum mastera o to co robi. Wtedy może zacząć udowadniać, że coś robi i zamieni się w teletubisia od ustawiania dupnych meetingów.

Jeżeli firma zarząd pyta Cię o opinię, to powiedz prawdę i niech ewentualnie zarząd się dopytuje innych. Przecież chyba o to im chodzi, dowiedzieć się czy programiści widzą jakąś różnicę.

No i tak naprawdę, żeby oceniać czy robi swoją robotę, musisz wiedzieć co powinien robić z zasady.

@Tomek Pycia: niekoniecznie. Bo w sumie liczy się to, jak idzie praca w zespole. Koleś może nawet cały dzień ostro zapieprzać, ale od wożenia pustej taczki nic się nie zmieni. Jeśli programiści (oraz inne osoby będące w firmie/zespole) nie widzą różnicy, to moim zdaniem koleś nie jest potrzebny.

cerrato napisał(a):

@Tomek Pycia: niekoniecznie. Bo w sumie liczy się to, jak idzie praca w zespole. Koleś może nawet cały dzień ostro zapieprzać, ale od wożenia pustej taczki nic się nie zmieni. Jeśli programiści (oraz inne osoby będące w firmie/zespole) nie widzą różnicy, to moim zdaniem koleś nie jest potrzebny.

Powinno się oceniać ogólny efekt, a nie subiektywne spojrzenie jednego albo drugiego znudzonego developera. Czyli ktoś powinien zmierzyć wydajność przed i po wprowadzeniu zmiany. A tak to o kant tyłka można robić taką ocenę.

Ale do tego powinny być wprowadzone jakieś narzędzia czy w inny sposób powinno to być wykonane przez osoby ponad @mortadelek. A skoro zarząd go pyta o jego odczucia i przemyślenia, to powinien właśnie się nimi podzielić. Nie tyle analizować jego pracę, co powiedzieć ```"za bardzo nie wiem, co koleś robi, ale ani ja, ani mój zespół nie zauważyliśmy żadnej różnicy od chwili jego wdrożenia"````. A takie benchmarki o których piszesz to powinno szefostwo stosować, ale z tego co zrozumiałem to nie pytają o obiektywne dane, tylko raczej o subiektywne odczucia pracowników. A tego nie da się zmierzyć.

Ocenić najlepiej po efektach

gorzej jak zatrudnili go dlatego ze trzeba było upchnąć gdzieś protegowanego i za prawdziwa ocenę jego pracy oberwie OP :(

W ogóle dziwny pomysł z tym zatrudnieniem Scrum Mastera. Można było zatrudnić na kontrakt na 3-6 miesięcy i poprosić zewnętrznego SM o wdrożone usprawnienia i plany na przyszłość + zespoły o feedback nt. współpracy. Wtedy sytuacja byłaby klarowna. Czyli należało do tego podejść z głową.

Perspektywa zespołów też może być niejednoznaczna. Są zespoły, które nie chcą robić retro, bo "trzeba skupić się na robocie". Takie zespoły powiedzą, że same się doskonale ogarniają, podczas gdy tak naprawdę nie stawiają sobie celów i są nieterminowe. Po drugie bias - zwykle inżynierowie mają alergię na agile coachów i SM-ów. Nie popieram, ale tak jest, nawet rozumiem - bariera komunikacyjna.

Co ja bym zrobił w Twojej sytuacji. Przede wszystkim ustalił stan faktyczny :)

• ankieta dla SM-a, aby uchwycić jego perspektywę: jakie usprawnienia wprowadził i jaki efekt zaobserwował, jakie plany na przyszłość
• ankieta dla zespołów - usprawnienia, efekty, jak przebiegała współpraca. Tutaj dodatkowo jakie usprawnienia zespół wprowadza samodzielnie, w jaki sposób dba o swoją efektywność.
• ankieta dla interesariuszy - jak się pracuje z IT, czy zauważyli jakieś zmiany.

Zderzyłbym obie perspektywy i wyciągnął wnioski - warto czy nie warto.

Zwróć uwagę na pewien błąd logiczny. Pytasz o to jak obiektywnie ocenić jego pracę, a w rzeczywistości chcesz ją ocenić subiektywnie. Obiektywnej oceny dokonałeś w pierwszym poście tego wątku, wliczając w to pewne pozytywy które niektórzy w tym wątku wydają się pomijać. Ty natomiast szukasz sposóbu na ocenienie go tak aby go wybronić, czyli z góry zakładasz wynik tej "oceny".

Poza tym koledzy wyżej mają sporo racji, chociaż w równym stopniu mogą się mylić bo bazują na domniemaniach, własnej interpretacji odpowiedzialności SM oraz- o czym słusznie wspomniał @Charles_Ray- uprzedzeniach. Są pewne wątpliwości:

• Czy faktycznie jest tak że wszystkie zespoły dobrze sobie wcześniej radziły? Jak sam napisałeś nie wiesz jakich zmian SM dokonal w innych zespołach, co za tym idzie nie możesz wiedzieć czy przed jego pojawieniem się było lepiej, gorzej albo bez zmian.
• Czy faktycznie SM nic a nic nie poprawił/zmienił w stosunku do tego jak było wcześniej? Nawet subtelne zmiany mogą mieć bardzo pozytywny wpływ, problemem natury takich zmian jest to że zauważamy ich znaczenie dopiero kiedy się je cofnie. Jesteśmy tylko ludźmi i często błędnie zapominamy że obecny stan rzeczy jest sumą przeszłości, nie istniał od zawsze.

Najlepiej zagrać w otwarte karty z zarządem i powiedzieć to co powiedziałeś tutaj.

Ja to tylko tu zostawię.

No najpierw trzeba go przekwalifikować na programistę/testera/analityka, żeby w ogóle można było zacząć mówić o jakiejś pracy.

Ten temat pięknie pokazuje jaką patologią jest scrum :D

Ja już pomijam temat agile jako takiego, ale właśnie scrum z tymi swoimi ustalonymi rolami, sprintami, estymowaniem w bananach, dzieleniem zadań na mniejsze (bo broń Boże zadanie nie może trwać za długo) to jest kompletna patologia i sekciarstwo które prowadzi wprost do spadku wydajności zespołów, obijania się, chaosu w wymaganiach i istnienia takich idiotyzmów jak właśnie wspomniany profesjonalny scrum master :D Kiedyś sobie pochodziłem po profilach takich Certified Scrum Masterów na Linked In (dużo się takich kręci w okolicach Sabre w Krakowie), poza kopiuj - wklej opisu roli scrum mastera żaden nie miał wpisanego żadnego konkretnu czym się faktycznie zajmują. A przepraszam, zajmują się "facylitacją spotkań" (cytat autentyczny).

Tu jest autentyczny opis z Linked In (oczywiście nie podam linka do profilu):

Title Scrum Master
Nov 2018 – Present

1. Wspieranie zespołu developerskiego
- Usuwanie wszelkich blokad oraz eskalowanie ryzyk
- Dbanie o dobre samopoczucie zespołu
- Wspieranie samoorganizacji zespołu
- Planowanie i facylitacja spotkań Scrumowych
- Ciągle przypominanie o dobrych praktykach Scrum oraz zasadach i wartościach Agile
- Dbanie o przepływ informacji oraz wyjaśnianie nieporozumień w zespole
- Mierzenie wydajność zespołu
- Obrona zespołu przed dodatkowymi zadaniami, nagłą zmianą priorytetów pracy
- Zwiększenie produktywności zespołu
- Nadzorowanie akcji z retrospektyw

2. Wspieranie Product Ownera
- Pomoc w zarządzaniu backlogiem
- Pomoc w opisywaniu US
- Przypominanie o stosowaniu zasad Scrum
- Pomoc w organizacji Demo

3. Wspieranie organizacji
- Pomoc innym pracownikom organizacji w zrozumieniu Scrum/metodyk zwinnych
- Pokazywanie, że zwinne podejście przynosi korzyści
- Wsparcie managementu w zakresie Agile
- Inicjowanie działań zwiększających produktywność
- Wspieranie procesu zmian w organizacji
- Popularyzacja dobrych praktyk
- Koordynowanie pracy zespołów

Czemu w żadnej innej metodologii nie jest potrzebne dedykowane stanowisko które polega na bronieniu tej metodologii przed otoczeniem? Jak to jest że w innych metodologiach nie trzeba facylitować spotkań i nadzorować czy metodologia jest właściwie wdrażana?

Może ze scrumem jest coś mocno nie tak skoro nikt go nie chce i wszyscy rzucają mu kłody pod nogi?