Jak obiektywnie ocenić pracę Scrum Mastera?

U mnie w firmie w ogole pozbyli sie niedawno scrum masterow i jest git :D

Za pięć (max. 10 lat) scrum przestanie być tak szeroko stosowany jak dzisiaj, ponieważ nie przystaje w ogóle do realnego świata.

Po pierwsze, wymaga by cała organizacja działała w tej metodyce. To można zrobić w małej firmie, albo startupie. Poważne przedsiębiorstwo (nie IT) nie będzie ponosić gigantycznych kosztów reorganizacji, tylko dlatego, że jeden dział chce pracować inaczej.

Po drugie, w większości przypadków scrum kończy się na zespole deweloperskim - powyżej jest już twarde zarządzanie i typowo waterfallowe project plany.

Po trzecie scrum z definicji musi powodować problemy:

• brak długofalowego planu, to zawsze komplikacje, bo ktoś czegoś nie przewidzi, albo nastąpią kolejne zmiana wymagań.
• każda zmiana to koszt, nawet w najbardziej agileowym zespole.
• wraz z upływem czasu i kolejnymi przeróbkami rośnie presja by robić rzeczy szybko, co powoduje wzrost długu technicznego.

Nie wiem czy ktoś jest zainteresowany dalszą częścią historii, ale opowiem i tak.

Zrobiłem anonimowe ankiety z pytaniami zamkniętymi do Product Ownerów i Developerów i te wyniki przesłałem wyżej.
Co będzie dalej to kwestia zarządu, ale z odpowiedzi wynika że developerom pracuje się tak samo efektywnie ze scrum masterem jak i bez.
Natomiast obaj product ownerzy zaznaczyli, że pracuje im się zdecydowanie lepiej. Więc myślę, że scrum master zostanie chociażby ze względu na to.

tak wiem, pewnie mnie shejtujecie za to, że nie do końca anonimowe te ankiety były :D
Ale było kilka pytań typowo skierowanych do PO i inne skierowane do developerów.

mortadelek napisał(a):

Natomiast obaj product ownerzy zaznaczyli, że pracuje im się zdecydowanie lepiej. Więc myślę, że scrum master zostanie chociażby ze względu na to.

Czyli już wiadomo kto odwalał robotę SM przed ich zatrudnieniem.

Myślałem, że scrum działa jak się go poprawnie stosuje, dopóki nie dostałem najgorszego scrum master na świecie, który totalnie rozwala pracę zespołu.

W backlogu burdel, story bardziej przypominają todo listę.
Story niemierzalne, robione na zasadzie watefalowej przez leada starej daty. Musi być zadanie na inwestygację, implementację, testy, TMA i integrację. SM zadowolony, bo backlog wypełniony i tylko to się liczy.
Story powpychane na siłę do sprintów aby tylko velocity się zgadzało.
Zespół obecnie ma 2 gości od automatyzacji i 5 programistów, ale zazwyczaj w sprincie brakuje story dla programistów, ale velocity się zgadza. A dałoby się rozbić zadania tak, by każdy miał co robić.
Na siłę rozdzielanie zadań pomiędzy dostępne osoby, ponad możliwą granicę zrównoleglenia, bo przecież priorytet epica jest największy i musi być zrobiony jak najszybciej. (Patrz, w pierwszym sprincie rozpisać wszystkie zadania typu inwestygacja, implementacja, testy, TMA i integracja na różne osoby i liczyć na to, że wszytko się zrobi w tym samym czasie).

Zespół ma wywalone na agile i to jak powinien działać. Skoro scrum master mówi, że coś się robi tak, a nie inaczej, to mu wierzą ... Wejście w polemikę ze SM zawsze skutkuje dojściem do wniosku, że jest OK i tego od nas oczekują, potem się poprawi story (nigdy nie są poprawiane ...).

W kalendarzu burdel, nie wiadomo na które spotkania się wdzwaniać i po co jest ich aż tyle.

Management zadowolony, bo jest odgórne postanowienie, że ma być agile, bo scrum master ma lata doświadczenia i ciągle ma jakieś fajne nowe pomysły. Zanim zatrudnili profesjonalnego SM, ową rolę pełnił nasz były manager, programista z doświadczeniem w branży większym niż ja mam lat (a mam ponad 30 lat) i o dziwo działało i pracowało się dobrze. Tak wygląda transformacja agile w technologicznym (SW/HW) korpo.

Ja po roku walki z betonem mam kompletnie wywalone. Było jeszcze parę innych osób, które próbowało sytuację zmienić na lepsze, ale wszyscy po kolei odpuścili.

Ja za to teraz mam akurat fajnego Scrum Mastera. Mieszka na jakimś zadupiu bez normalnego internetu, więc zazwyczaj nie jest się w stanie nawet dodzwonić na spotkania.
A poza tym nie przeszkadza, a jak potrzebuję linku do Excela z urlopami, to mi go zawsze wysyła, więc w sumie jak dla mnie, to on wykonuje swoją "pracę" na 11/10. Do tego liczy jakieś tam capacity, coś gada o jakichś buldup czartach (potem pokazuje takie prawie prostokątne coś z jedną przekątną i narzeka), no ogólnie rzeczy istotne być może dla jakichś dziwnych ludzi, na pewno nie dla programistów.
A, no i nagrywa dema, żeby ktoś je potem oglądał. Nie wiem czy ktoś to robi, no a poza tym to po co, skoro jak już wspominałem internet ma słaby, więc nie jest w stanie nagrać obrazu, a i dźwięk szarpie. No, ale proces dokonany, a proces jest najważniejszy według religii scrum.

Z tego co widzę, to ten wątek jest pełen ofiar waterfalla, które teraz są szczęśliwe z powodu pracy w scrumie, a więc każdy atak na scruma odbierają bardzo osobiście. No cóż, jak się nie ma porównania z agile, to faktycznie jedyny wniosek jaki można wyciągnąć jest taki, że scrum jest lepszy od waterfalla.

Wiele lat pracowałem w firmie, która była "agile" tak naprawdę. Takie firmy bardzo łatwo poznać - po tym, że tam nikt nie gada o byciu agile. Ani nie ma wydzielonych pracowników od agilowania reszty. Nie ma plakatów szczęśliwych scrum masterów na ścianach ani wzniosłych haseł tamże. Po prostu są zadowoleni programiści, którzy zawsze mają coś do roboty, i zadowoleni PO, którzy praktycznie zawsze mają dowiezione wszystko na czas. (Niedowiezienia się zdarzały z przyczyn wyłącznie zewnętrznych.)
Ale to jest osiągalne tylko wtedy, kiedy przestanie się udawać, certyfikować i wpieprzać profesjonalistom w ich robotę przy użyciu jakichś kołczy.
No, a teraz mam bardzo fajny kontrast w produktywności. Bo jak jest normalnie, to po skończeniu taska bierze się następnego. Ale w scrumie nie można, bo po pierwsze buldup czart się dziwnie wygnie, po drugie kapłan krzyczy, że religia na to nie pozwala, a po trzecie, to jak się weźmie taska, a potem go nie dowiezie, to jest w ogóle sodomia i gomoria, error w sprincie i raporty do ogólnoświatowego rządu scrumowego.
Tak więc jeśli skończy się taska na 2 dni przed końcem sprintu, to lepiej dla własnego komfortu następnego już nie brać. A dniówka leci, no cóż, nasz klient, nasz pan. ;)

somekind napisał(a):

Tak więc jeśli skończy się taska na 2 dni przed końcem sprintu, to lepiej dla własnego komfortu następnego już nie brać. A dniówka leci, no cóż, nasz klient, nasz pan. ;)

No i scum master może znowu się wykazać organizując spotkania na temat problemów dotyczących "estymacji tasków"

var napisał(a):

No i scum master może znowu się wykazać organizując spotkania na temat problemów dotyczących "estymacji tasków"

No nie do końca - bo taski dowiezione w sprincie, więc problemu z estymacją nie było. A to, że jakiś kontraktor za morzem siedział kilka dni i się nudził zamiast zrobić coś dla firmy, no to już nie problem SM przecież.

Dowiezione ale ktoś nie miał roboty przez 2 dni. A przecież można podkręcić velocity pod sam korek :D

Ile pracuję to nikt przy mnie nawet nie próbował symulować że wprowadza jakieś SCRUMy czy cokolwiek innego o dziwnej nazwie. Styczność moja z Agile ogranicza się więc do tego co na studiach robiliśmy w tej formule w grupach.

Z jakiej firmy najlepiej zrobić sobie certyfikat scrum mastera

Ja mam taki, sam zrobiłem: