Do czego są scrum masterzy?

Odjebać szopkę na stan"dupie" (oczywiście nawet nie mając pojęcia o czym ten dev robi bez opamiętania), powygłupiać się, pograć w planszówki, powycinać (ale w systemie) pizzę z papieru i udowodnić, że tą metodologią to było to efektywniej niż tamtą i iść na szluga. Do czegoś jeszcze?

Do udowadniania, że idioci są w każdej branży.

https://www.scrum.org/resources/what-is-a-scrum-master

U nas rolę zarządzającego zadaniami ma analityk i to się bardzo dobrze sprawdza, bo wie doskonale na czym te zadania polegają. Ziomek tylko i wyłącznie od ceremonii to byłby totalny bezsens.

SM per zespół to przesada, tym bardziej że zespół sam powinien ogarnąć sobie ceremonie. Oczywiście od czasu do czasu doraźne wsparcie jest wartościowe, bo zespoły mają naturalnie odchyl w kierunku „po co nam retro?!”, warto też zwracać uwagę na cele biznesowe, jakość komunikacji itp itd

W praktyce rzeczywiście dochodzi do różnych anomalii, np. są takie patologie, gdzie SM to pomalowany PM albo lider zespołu, albo właśnie jest taką „maskotką zespołu”. W jednym i drugim przypadku zakontraktowałbym się z takim SM, czyli umówił na konkretne działania i ich weryfikację. Jak tego nie będzie, to obecność takiej osoby demotywuje zespół i z tego należy zdawać sobie sprawę.

Jakie wsparcie?

Ze swojej strony dodam, że jak dołączył do nas analityk to praca zespołu mocno się poprawiła. Zamiast dzielić czas na kodzenie i dogadywanie się z biznesem programiści zajęli się samym kodzeniem, a analityk samym dogadywaniem z biznesem. Efektywność pracy mocno się poprawiła. Natomiast jeśli chodzi o scrumowe ceremonie to minimalizujemy je, bo często okazują się stratą czasu. Dla przykładu olaliśmy planning poker i velocity i zastąpiliśmy to dzieleniem zadań na mniejsze i częstszym planowaniem. Retro mamy rzadko, bo wnioski z kolejnych retro mocno się pokrywają (czyli większości problemów z retro nie rozwiązujemy, bo nie mamy czasu).

Charles_Ray napisał(a):

SM per zespół to przesada, tym bardziej że zespół sam powinien ogarnąć sobie ceremonie. Oczywiście od czasu do czasu doraźne wsparcie jest wartościowe,[...]

Jakie wsparcie?

Wsparcie np. w przypadku nieefektywnych planningów, niedowożenia celów sprintów. Do tego można dodać pracę nad szeroko pojętą efektywnością zespołu. Głównie w postaci coachingu i wymiany doświadczeń.

Wsparcie np. w przypadku nieefektywnych planningów, niedowożenia celów sprintów.

Planning pokery się nie sprawdziły - wywaliliśmy. Velocity się nie sprawdziło - wywaliliśmy. Plany sprintów się rozjeżdżały, więc robimy je częściej i planujemy krótkofalowo - siłą rzeczy planowanie krótkofalowe jest obarczone mniejszym błędem niż długofalowe, bo jest mniej zmiennych. Retro przynosi bardzo podobne wnioski za każdym razem, więc robimy go rzadziej niż "prawdziwy" Scrum zakłada (po co w kółko powtarzać to samo?).

Do tego można dodać pracę nad szeroko pojętą efektywnością zespołu. Głównie w postaci coachingu i wymiany doświadczeń.

Co jakiś czas w korpo poszczególne zespoły prezentują chętnym innym zespołom co robią i jak wygląda ich projekt. Niewiele z tego jest pożytku. Już większy wpływ mają internetowe kursy dotyczące konkretnych tematów. Po co wymieniać losowe doświadczenia z kimś obok skoro można poszukać konkretnej wiedzy mając Internet pod ręką? Ta współpraca z zespołami obok praktycznie nigdy nie polegała na współpracy na żywo, np jakimś parowaniu się nad zadaniem.

Retro przynosi bardzo podobne wnioski za każdym razem, więc robimy go rzadziej niż "prawdziwy" Scrum zakłada (po co w kółko powtarzać to samo?).

Może w końcu warto rozwiązywać te wykryte problemy? :) dlaczego stale powracają? Może nie ma przypisanej osoby odpowiedzialnej?

Ta współpraca z zespołami obok praktycznie nigdy nie polegała na współpracy na żywo, np jakimś parowaniu się nad zadaniem.

Bardziej chodziło mi o dzielenie się dobrymi praktykami pomiędzy zespołami. Np. jeden z zespołów pochwalił się, że robi krótkie groomingi zawsze po daily, albo ma określony sposób prowadzenia retro, który fajnie wychodzi.

Wibowit napisał(a):

...

Retro mamy rzadko, bo wnioski z kolejnych retro mocno się pokrywają (czyli większości problemów z retro nie rozwiązujemy, bo nie mamy czasu).

Take głupie pytanie... Dlaczego nie macie czasu?

Może w końcu warto rozwiązywać te wykryte problemy? :) dlaczego stale powracają? Może nie ma przypisanej osoby odpowiedzialnej?

Nie ma przypisanej osoby, bo wszyscy są obłożeni robotą.

Bardziej chodziło mi o dzielenie się dobrymi praktykami pomiędzy zespołami. Np. jeden z zespołów pochwalił się, że robi krótkie groomingi zawsze po daily, albo ma określony sposób prowadzenia retro, który fajnie wychodzi.

Czemu takich rzeczy mam się dowiadywać od przypadkowych zespołów, a nie np z jakiejś "biblii" Scruma? Dlaczego losowe odchyły od "prawdziwego" Scruma robione przez lokalne zespoły mają być lepsze od szeroko polecanych Scrumowych standardów?

To jest bardzo naiwne pytanie, to tak jakby pytać do czego są tasiemce.
Jedzą i się rozmnażają, więc są.

Ani wygląda to ładnie,
ani z nich skóra na buty.
Nie ma co pytać, koledzy: robiła i tak jej wyszło.
Nikt nie wymyślał specjalnie tego w czym żyć nam przyszło.

Pasożyty też pełnią ważną rolę w ekosystemie - uśmiercają nadmiar osobników danego gatunku. Tylko czy programistów jest już za dużo?

Coś w tym jest, ale celem pasożyta jest pasożytowanie, a nie uśmiercanie żywiciela.

Każdy (złożony?) organizm powstał w wyniku mutacji, a te są czasem dobre, a czasem złe. Dobre to takie które zwiększają szansę na zachowanie liczebności gatunku, a złe to takie które takie szanse zmniejszają. To czy mutacja jest dobra czy zła może okazać się od razu, ale równie dobrze może okazać się po X pokoleniach. Dla przykładu jeśli mutacja powoduje szybsze rozmnażanie się oraz jednocześnie szybsze uśmiercanie żywiciela (ale dalej po rozmnażaniu, a nie przed) to okaże się że jest zła dopiero jak uśmierci zbyt dużo żywicieli i dopiero wtedy będzie zastępowana innymi mutacjami. Dojście do równowagi w przyrodzie, gdzie gatunki konkurują ze sobą, a ich liczebność jest stabilna zajmuje czasem wiele pokoleń. Jak np człowiek w jakimś środowisku wybije dany gatunek, bo mu się nie podoba to ta równowaga zostanie zachwiana i mogą na tym ucierpieć zupełnie inne gatunki (np sami ludzie): https://pl.wikipedia.org/wiki/Kampania_walki_z_czterema_plagami
I co na to powiecie? :]

Do zwalniania. Zwłaszcza teraz.

Coś takiego jak funkcja scrum mastera jakiś sens ma - sprawdzić, czy zadania poprzypisywane, pogonić ludzi na daily i generalnie przypilnować, czy to co zespół ustalił jest przez ten zespół wykonywane. Coś takiego jak etat scrum mastera jest dla mnie kompletnym absurdem i kończy się na zatrudnieniu osób które nie mają pojęcia co robi zespół, jak i po co ale usiłują tym zarządzać a jedyny skutek jest taki, że ludzie wkurzeni, bo oprócz walki z problemami technicznymi, analitycznymi, czy organizacyjnymi trzeba jeszcze marnować czas na tłumaczenie rzeczy oczywistych osobie, która nie ogarnia i nie ma szans w krótkim czasie ogarnąć.
Natomiast nikt nie powiedział, że ROLI scrum mastera w zespole nie może pełnić developer, analityk, albo, że scrum mastera nie można wykorzystać do takich zadań jak ogarnięcie współpracy z innymi zespołami, pisanie dokumentacji projektowej, czy papierkowa robota, która też musi być wykonana.

piotrpo napisał(a):

Coś takiego jak funkcja scrum mastera jakiś sens ma - sprawdzić, czy zadania poprzypisywane, pogonić ludzi na daily i generalnie przypilnować, czy to co zespół ustalił jest przez ten zespół wykonywane.

Tak, mikromanagement jest niezbędny. Ale oficjalnie nie jest on częścią pracy Scrum Mastera.

podoba mi się to jak ich nazwaliście - pasożyci XD. W sumie pasuje idealnie. No niestety taka jest prawda - zwłaszcza jeżeli trafi się na kogoś kto nie ogarnia jako człowiek. Jeżeli trafi się na kogoś ogarniętego człowieka i na luzie to sam SCRUM potrafi nieźle zoptymalizować pracę - w życiu prywatnym też można stosować np. cotygodniowe sprinty i planować zadania na dany tydzień. firmy które wdrożyły agile potrafiły zwiększyć swoją wydajność

Poczytałem i tylko utwierdzam się w przekonaniu, że ludzie nie rozumieją, że Scrum Master to nie jest ani analityk, ani menadżer, ani tym bardziej ktoś, kto ma jakąkolwiek władzę. Taki mały cytacik ze scrum guida:

Jak Scrum Master wspiera Zespół Deweloperski?

Scrum Master służy pomocą Zespołowi Deweloperskiemu na kilka sposobów, na przykład:

• coachując Zespół Deweloperski w zakresie wykorzystania zasad samoorganizacji i międzyfunkcyjności,
• pomagając Zespołowi Deweloperskiemu tworzyć produkty wysokiej wartości,
• usuwając przeszkody ograniczające postępy Zespołu Deweloperskiego,
• wspomagając przebieg wydarzeń scrumowych, kiedy jest to konieczne lub kiedy jest o to proszony,
• coachując Zespół Deweloperski w zakresie sposobu wykonywania pracy w organizacjach, w których Scrum nie jest jeszcze w pełni przyjęty i rozumiany.

Czyli mówiąc inaczej, rolą SM jest przede wszystkim dbać o to:

• żeby zespół pracował zgodnie z przyjętą metodyką;
• miał narzędzia, które ułatwiają pracę i to zarówno techniczne jak i miękkie;
• osoby spoza zespołu mogły lepiej zrozumieć, dlaczego zespół działa w taki, a nie inny sposób;

Niestety w ogromnej części przypadków SM to jest taki niedorobiony PM, który nie łapie, czym jest scrum jako taki i próbuje upchnąć go w tabelki excela.

I trochę obok, ale fajny przykład do posłuchania jak bardzo rozmija się powszechne pojęcie zebrań scrumowych, z tym jak to powinno rzeczywiście wyglądać:

@Koziołek: oglądnąłem podlinkowany film, przeczytałem Twoją odpowiedź i teraz (wciąż) nie wiem, dlaczego to się nazywa akurat scrum i dlaczego ta "praktyka" potrzebuje tzw. ogólnie "mistrza ceremonii"? Mam 20 różnych nazw na to, ale strzelę kilka: organizacja pracy, organizacja zespołu, zakres odpowiedzialności, zakres obowiązków. A jak to robią inne branże, że istnieją bez scruma? Dajmy na to, nie wiem, kancelarie prawne, wedle tego wszystkiego, idealnie by tam pasował. Mam wręcz teorię, że te ze scrumem powinny być tak dobrze zorganizowane, że więcej spraw przed sądem powinny wygrywać dla klientów, mylę się?

Pójdźmy dalej - załóżmy roboczo na ten moment, że ten scrum i scrum masterzy to jakkolwiek pożyteczny koncept. Zatem ja proponuję wprowadzić coffee master. Któż to jest? To ktoś, kto pilnuje, aby na kawie ludzie się relaksowali, nikt im nie przeszkadzał akurat w trakcie tylko tego zajęcia, pokazuje jak właściwie parzyć kawę z użyciem odpowiednik technik, że samo parzenie kawy jest nawet celem samym w sobie, bo jest relaksujące, pozwala inaczej pomyśleć o problemach, itp. Byłbym się skłonny założyć, że coffee master mógłby zwiększać przychody i satysfakcję pracy w niejednej firmie, chyba nawet ma to umocowanie w jakichś badaniach. Stąd teraz pytanie: dlaczego firmy (zazwyczaj) mają tylko scrum masterów, a nie coffee masterów?

Albo inny człowiek: motivation master - psychoterapeuta z lepszą nazwą. Posiada swój pokój w firmie, można się umówić, zwierzyć z problemów, spróbować poszukać rozwiązania na polu emocjonalnym. Normalnie "satysfakcja" z pracy byłaby jeszcze lepsza. PM/PO mnie ochrzanił, kolega spuścił mój pull request w kanał, klient odrzucił moje rozwiązanie, nad którym siedziałem miesiąc... takie sytuacje, że nie chce się pracować. A w firmie taki motivation master, można iść, pogadać, po takiej rozmowie od razu będzie lepiej, on razu dzień bardziej słoneczny, od razu inne nastawienie.

Takich pożytecznych stanowisk typu *master to można utworzyć na pęczki jak widać, więc dlaczego tylko scrum masterzy się najczęściej pojawiają? Żeby nie było, nie kpię, tylko się pytam?

Jak Scrum Master wspiera Zespół Deweloperski?

Scrum Master służy pomocą Zespołowi Deweloperskiemu na kilka sposobów, na przykład:

    coachując Zespół Deweloperski w zakresie wykorzystania zasad samoorganizacji i międzyfunkcyjności,
    pomagając Zespołowi Deweloperskiemu tworzyć produkty wysokiej wartości,
    usuwając przeszkody ograniczające postępy Zespołu Deweloperskiego,
    wspomagając przebieg wydarzeń scrumowych, kiedy jest to konieczne lub kiedy jest o to proszony,
    coachując Zespół Deweloperski w zakresie sposobu wykonywania pracy w organizacjach, w których Scrum nie jest jeszcze w pełni przyjęty i rozumiany.

Całe te "coachowanie" to istne sekciarstwo. Traktuje się programistów jak idiotów, którzy nie potrafią sobą zarządzać. Oczywiście, jak w każdej innej grupie są takie osoby ale tutaj wystarczy ogarnięty PM (jak już zostało wspomniane). Szczególnie groźnym przypadkiem jest SM, który nie ma wiedzy technicznej (o czym też już pisano). Traci się czas na ciągłe tłumaczenie co i dlaczego powinno mieć taki priorytet i dlaczego załatanie dziury w autoryzacji albo naprawa replikacji jest ważniejsza od dodania przycisku na panelu. Gdzieś usłyszałem, że najlepiej jest wtedy, kiedy SM jest właśnie osobą nietechniczną. Może to się sprawdza wyłącznie wtedy kiedy SM nie wpieprza się do zarządzania zespołem tylko klika sobie w jirze i robi kolorowe tabelki. Kiedy jednak osoba bez podstawowej wiedzy wtrąca się w pracę zespołu technicznego to w rezultacie otrzymujemy jakość pracy rzędu spółek państwowych - niekompetentny zarząd i sfrustrowani pracownicy.
Scrum miał być narzędziem, frameworkiem - stał się gdzieniegdzie religią, która ma swoje bojówki.
Uprzedzając - wiem oczywiście, że pracowałem w miejscach gdzie scrum był źle wdrożony... Jak komunizm...

Co to jest "coachując"? To coś jak "zając"? Bo np "bukować" to wiem, pewnie coś z bukiem, tym drzewem. Ale "coachując" to to chyba coś z ch*jem za przeproszeniem

TurkucPodjadek napisał(a):

@Koziołek: oglądnąłem podlinkowany film, przeczytałem Twoją odpowiedź i teraz (wciąż) nie wiem, dlaczego to się nazywa akurat scrum i dlaczego ta "praktyka" potrzebuje tzw. ogólnie "mistrza ceremonii"? Mam 20 różnych nazw na to, ale strzelę kilka: organizacja pracy, organizacja zespołu, zakres odpowiedzialności, zakres obowiązków.

Nazwy, które wymieniłeś, nie opisują zasad działanie systemu, a jedynie jakiś jego aspekt. W dodatku są generyczne. Scrum to zbiór konkretnych zasad, które opisują:

• jak powinien być zorganizowany zespół → https://www.scrumguides.org/scrum-guide.html#team
• jaki jest zakres obowiązków w ramach zespołu → j.w.
• jak powinna być zorganizowana jego praca → https://www.scrumguides.org/scrum-guide.html#events
• jaki jest zakres odpowiedzialności zespołu → https://www.scrumguides.org/scrum-guide.html#artifact-transparency-done

I takich mechanizmów opisujących różne aspekty pracy zespołów jest wiele, jest RUP, jest Waterfall, jest Kanban. Każde z tych podejść inaczej traktuje powyższe elementy. Nazwy pozwalają na identyfikację konkretnego zbioru zasad.

A jak to robią inne branże, że istnieją bez scruma?

Robią według swoich metodyk:

• TPS – Toyota Production System → https://pl.wikipedia.org/wiki/Toyota_Production_System
• Six Sigma → https://pl.wikipedia.org/wiki/Sze%C5%9B%C4%87_sigma
• PRINCEW → https://pl.wikipedia.org/wiki/PRINCE2

Dajmy na to, nie wiem, kancelarie prawne, wedle tego wszystkiego, idealnie by tam pasował. Mam wręcz teorię, że te ze scrumem powinny być tak dobrze zorganizowane, że więcej spraw przed sądem powinny wygrywać dla klientów, mylę się?

I oczywiście mylisz się, bo na zachodzie kancelarie prawnicze używają Scruma w swojej pracy. W Polsce też to robią. Osobiście scrumowałem dwie kancelarie i jedną fundację :D To naprawdę się da ładnie.

Zresztą tu ważna rzecz, która też jest ignorowana. Scrum nie jest przypisany do projektów IT. Co więcej, w Scrum Guide nigdzie nie pada słowo komputer. To jest metodyka, która jest zaprojektowana do działania w różnych branżach.

Pójdźmy dalej - załóżmy roboczo na ten moment, że ten scrum i scrum masterzy to jakkolwiek pożyteczny koncept. Zatem ja proponuję wprowadzić coffee master. Któż to jest? To ktoś, kto pilnuje, aby na kawie ludzie się relaksowali, nikt im nie przeszkadzał akurat w trakcie tylko tego zajęcia, pokazuje jak właściwie parzyć kawę z użyciem odpowiednik technik, że samo parzenie kawy jest nawet celem samym w sobie, bo jest relaksujące, pozwala inaczej pomyśleć o problemach, itp. Byłbym się skłonny założyć, że coffee master mógłby zwiększać przychody i satysfakcję pracy w niejednej firmie, chyba nawet ma to umocowanie w jakichś badaniach. Stąd teraz pytanie: dlaczego firmy (zazwyczaj) mają tylko scrum masterów, a nie coffee masterów?

Sprowadzania ad absurdum, ale słabo, bo w dużych firmach takie stanowiska są i mają się nieźle. Tyle tylko, że to już kwestia skali biura. Nikt nie będzie dla 3 osób organizował baristy. Jednak już dla dużego biura zatrudnienie takiej osoby zaczyna się opłacać (mówię o dużych biurach typu Google czy Apple). W przypadku mniejszych firm niczym niezwykłym jest inwestowanie w wysokiej klasy ekspresy do kawy.

Tutaj ciekawostka, pracę zaczynałem w firmie, gdzie każdy pracownik, który miał bezpośredni kontakt z klientem, przechodził szkolenie z robienia kawy. W kuchni stał profesjonalny ekspres, a zakup kawy był ujęty w całkiem zgrabny proces uwzględniający jakość ziarna.

Albo inny człowiek: motivation master - psychoterapeuta z lepszą nazwą. Posiada swój pokój w firmie, można się umówić, zwierzyć z problemów, spróbować poszukać rozwiązania na polu emocjonalnym. Normalnie "satysfakcja" z pracy byłaby jeszcze lepsza. PM/PO mnie ochrzanił, kolega spuścił mój pull request w kanał, klient odrzucił moje rozwiązanie, nad którym siedziałem miesiąc... takie sytuacje, że nie chce się pracować. A w firmie taki motivation master, można iść, pogadać, po takiej rozmowie od razu będzie lepiej, on razu dzień bardziej słoneczny, od razu inne nastawienie.

I znowuż nie wiesz, co masz do dyspozycji. Rolę „motivation mastera” powinna pełnić osoba, która jest za ciebie odpowiedzialna w dziale HR. Ma to różne nazwy HR Partner, HR Support, i takie osoby mają w obowiązkach dbanie o morale załogi. Niestety panowie programiści czują się zbyt ważni, by pójść i pogadać co ich boli z „jakimś rekru, co nie rozróżnia JS od Javy”. Takie małe zadanie popytaj, jak będziesz mieć okazję, o wykształcenie osób z twojego działu HR. Będzie tam przewaga psychologów i to nie dlatego, że psychologia to gównokierunek i praca w HR była alternatywą dla kasy w biedrze.

Takich pożytecznych stanowisk typu *master to można utworzyć na pęczki jak widać, więc dlaczego tylko scrum masterzy się najczęściej pojawiają? Żeby nie było, nie kpię, tylko się pytam?

Scrum masterzy pojawiają się najczęściej, ponieważ wiele firm traktuje Scrum jako dobry, rekrutacyjny buzz word. Swoisty lep na programistów zaraz obok mikroserwisów i ML. W rzeczywistości większość firm ogranicza się jedynie do rozdania nazw stanowisk i robienia daily. Zupełnie pomijają to czym jest scrum i biorą z niego jedynie ceremonie i nazwy, a nie mechaniki.

Jacek Zabrzowski napisał(a):

szopkę na stan"dupie" (oczywiście nawet nie mając pojęcia o czym ten dev

Obecność scrum mastera na stand-upie jest opcjonalna.

Scrum masterzy pojawiają się najczęściej, ponieważ wiele firm traktuje Scrum jako dobry, rekrutacyjny buzz word. Swoisty lep na programistów zaraz obok mikroserwisów i ML.

Taki z tego lep jak z frazy "młody i dynamiczny zespół".

W rzeczywistości większość firm ogranicza się jedynie do rozdania nazw stanowisk i robienia daily. Zupełnie pomijają to czym jest scrum i biorą z niego jedynie ceremonie i nazwy, a nie mechaniki.

Ceremonie się regularnie powtarzają, więc to jest najbardziej widoczne tak czy siak. Podział obowiązków czy "definition of done" nie zmieniają się ze sprintu na sprint. Stwierdzenie czy mamy do czynienia z "prawdziwym" Scrumem jest równie trudne i dyskusyjne co stwierdzenie czy mamy do czynienia z "prawdziwym" komunizmem, bo nie ma jednej, szczegółowej i sztywnej definicji jednego czy drugiego. Każdy sobie interpretuje te pojęcia trochę inaczej.

Żeby Scrum sam w sobie był przekonujący to musiałby być porównany z alternatywami. Z tych materiałów reklamowych o Scrumie to wynika, że ma same zalety, oczywiście oprócz straty czasu na regularne ceremonie. Inną wadą jest stres tym, że Scrum nie wychodzi tak jak w reklamach mi i mojemu zespołowi, a jakimś tam innym zespołom wychodzi, nawet jeśli to zależy mocniej od tematyki projektu niż umiejętności członków zespołu. Zgodnie z zasadą "trawa u sąsiada jest zawsze bardziej zielona" według PMa Scrum zawsze działa lepiej w innych zespołach niż w naszym i to jest powód do czepiania się.

Scrum masterzy potrzebni są gdzy zespół jest niezdyscyplinowany i nie umie się sam zorganizować (wtedy też sam scrum może pomóc)

Tyle lat minęło, i żadnych wniosków.

https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html

https://vimeo.com/110554082

Koziołek napisał(a):

TurkucPodjadek napisał(a):

@Koziołek: oglądnąłem podlinkowany film, przeczytałem Twoją odpowiedź i teraz (wciąż) nie wiem, dlaczego to się nazywa akurat scrum i dlaczego ta "praktyka" potrzebuje tzw. ogólnie "mistrza ceremonii"? Mam 20 różnych nazw na to, ale strzelę kilka: organizacja pracy, organizacja zespołu, zakres odpowiedzialności, zakres obowiązków.

Nazwy, które wymieniłeś, nie opisują zasad działanie systemu, a jedynie jakiś jego aspekt. W dodatku są generyczne. Scrum to zbiór konkretnych zasad, które opisują:

• jak powinien być zorganizowany zespół → https://www.scrumguides.org/scrum-guide.html#team
• jaki jest zakres obowiązków w ramach zespołu → j.w.
• jak powinna być zorganizowana jego praca → https://www.scrumguides.org/scrum-guide.html#events
• jaki jest zakres odpowiedzialności zespołu → https://www.scrumguides.org/scrum-guide.html#artifact-transparency-done

Zaraz, zaraz, jakich "konkretnych". Weźmy to: https://www.scrumguides.org/scrum-guide.html#team

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.

To ten niby "konkret"? Każda zdrowa firma, nawet budowlana Zdzicha i Rycha działa w takim modelu, pomijając, że sobie takich fancy nazw nie nadają, poza "szwagier". Co Scrum tutaj wnosi? Nazwy stanowisk?

I takich mechanizmów opisujących różne aspekty pracy zespołów jest wiele, jest RUP, jest Waterfall, jest Kanban. Każde z tych podejść inaczej traktuje powyższe
elementy. Nazwy pozwalają na identyfikację konkretnego zbioru zasad.

Ale Kanban Masterów, Waterfall Masterów się nie spotyka... widać orędownicy źle podeszli do spraw marketingowych. :-)

A jak to robią inne branże, że istnieją bez scruma?

Robią według swoich metodyk:

• TPS – Toyota Production System → https://pl.wikipedia.org/wiki/Toyota_Production_System
• Six Sigma → https://pl.wikipedia.org/wiki/Sze%C5%9B%C4%87_sigma
• PRINCEW → https://pl.wikipedia.org/wiki/PRINCE2

Dajmy na to, nie wiem, kancelarie prawne, wedle tego wszystkiego, idealnie by tam pasował. Mam wręcz teorię, że te ze scrumem powinny być tak dobrze zorganizowane, że więcej spraw przed sądem powinny wygrywać dla klientów, mylę się?

I oczywiście mylisz się, bo na zachodzie kancelarie prawnicze używają Scruma w swojej pracy. W Polsce też to robią. Osobiście scrumowałem dwie kancelarie i jedną fundację :D To naprawdę się da ładnie.

Scrumowałeś, więc z tego wynika, że jesteś w jakiś sposób bardziej związany z tematem, więc nie wiem na ile obiektywnie jesteś w stanie spojrzeć z boku "problemu".

Co do kancelarii: ok, to co daje im scrum? Klienta, czyli dajmy na to mnie, obchodzi jedynie, czy wygram sprawę przed sądem - zatem czy sądy są przychylne scrumowo działającym kancelariom, czy mają to kompletnie gdzieś? Bo mnie interesuje wartość biznesowa, a nie jakieś certy ISO czy inne tego typu laurki.

Zresztą tu ważna rzecz, która też jest ignorowana. Scrum nie jest przypisany do projektów IT. Co więcej, w Scrum Guide nigdzie nie pada słowo komputer. To jest metodyka, która jest zaprojektowana do działania w różnych branżach.

To już wiem, tylko wciąż nie wiem jaki problem ma rozwiązać. Złe zarządzanie w ogólności? IMO lepiej zmienić szefa/managera, niż "wdrożyć" scrum, który notabene może "zabetnowoać" niewłaściwe osoby, na niewłaściwej pozycji (zwłaszcza w korpo), bo "coś niby robią"

Pójdźmy dalej - załóżmy roboczo na ten moment, że ten scrum i scrum masterzy to jakkolwiek pożyteczny koncept. Zatem ja proponuję wprowadzić coffee master. Któż to jest? To ktoś, kto pilnuje, aby na kawie ludzie się relaksowali, nikt im nie przeszkadzał akurat w trakcie tylko tego zajęcia, pokazuje jak właściwie parzyć kawę z użyciem odpowiednik technik, że samo parzenie kawy jest nawet celem samym w sobie, bo jest relaksujące, pozwala inaczej pomyśleć o problemach, itp. Byłbym się skłonny założyć, że coffee master mógłby zwiększać przychody i satysfakcję pracy w niejednej firmie, chyba nawet ma to umocowanie w jakichś badaniach. Stąd teraz pytanie: dlaczego firmy (zazwyczaj) mają tylko scrum masterów, a nie coffee masterów?

Sprowadzania ad absurdum, ale słabo, bo w dużych firmach takie stanowiska są i mają się nieźle. Tyle tylko, że to już kwestia skali biura. Nikt nie będzie dla 3 osób organizował baristy. Jednak już dla dużego biura zatrudnienie takiej osoby zaczyna się opłacać (mówię o dużych biurach typu Google czy Apple). W przypadku mniejszych firm niczym niezwykłym jest inwestowanie w wysokiej klasy ekspresy do kawy.

Tutaj ciekawostka, pracę zaczynałem w firmie, gdzie każdy pracownik, który miał bezpośredni kontakt z klientem, przechodził szkolenie z robienia kawy. W kuchni stał profesjonalny ekspres, a zakup kawy był ujęty w całkiem zgrabny proces uwzględniający jakość ziarna.

Widocznie w tej firmie miało to jakieś uzasadnienie biznesowe. Jak coś nie ma uzasadnienia biznesowego, to albo się tego nie robi (po raz któryś tam), albo się to wciąż robi, po czym firma bankrutuje, innych możliwości nie widzę (poza wyjątkami typu firmy państwowe i jakieś korpa co lubią przepalać pieniądze w okresach prosperity)

Albo inny człowiek: motivation master - psychoterapeuta z lepszą nazwą. Posiada swój pokój w firmie, można się umówić, zwierzyć z problemów, spróbować poszukać rozwiązania na polu emocjonalnym. Normalnie "satysfakcja" z pracy byłaby jeszcze lepsza. PM/PO mnie ochrzanił, kolega spuścił mój pull request w kanał, klient odrzucił moje rozwiązanie, nad którym siedziałem miesiąc... takie sytuacje, że nie chce się pracować. A w firmie taki motivation master, można iść, pogadać, po takiej rozmowie od razu będzie lepiej, on razu dzień bardziej słoneczny, od razu inne nastawienie.

I znowuż nie wiesz, co masz do dyspozycji. Rolę „motivation mastera” powinna pełnić osoba, która jest za ciebie odpowiedzialna w dziale HR. Ma to różne nazwy HR Partner, HR Support, i takie osoby mają w obowiązkach dbanie o morale załogi. Niestety panowie programiści czują się zbyt ważni, by pójść i pogadać co ich boli z „jakimś rekru, co nie rozróżnia JS od Javy”. Takie małe zadanie popytaj, jak będziesz mieć okazję, o wykształcenie osób z twojego działu HR. Będzie tam przewaga psychologów i to nie dlatego, że psychologia to gównokierunek i praca w HR była alternatywą dla kasy w biedrze.

"Powinna" - w jakiej księdze to jest zapisane? Bo np, jakie podatki i do kiedy mam zapłacić, definiuje prawo podatkowe danego kraju i jest to obiektywnie znane i prawdziwe, bez względu na to, czy jesteś pucybutem na ulicy czy superkorpo. Natomiast, to, kto jest "za mnie odpowiedzialny", to co ma niby uniwersalnie definiować? W teorii jest to pracodawca jak jesten na UoP, a nie jakiś tam "HR". I dlaczego firma Zdzicha jest prawnie firmą, a nie ma działu HR dajmy na to?

Bo widzisz, tutaj dochodzimy do pewnego uproszczenia sprawy, scrum to jest coś co niby gdzieś tam, jakoś działa. Z tej strony co podałeś, scrum to coś co jest "simple to understand" ale "difficult to master". Mam świetny kontrprzykład: prowadzenie działalności gospodarczej - powinno przynosić zyski. Proste do zrozumienia, trudne do wdrożenia. Czy w związku z tym ryzykujemy tezę, że prowadzenie działalności gospodarczej przynosi tylko zyski?

Takich pożytecznych stanowisk typu *master to można utworzyć na pęczki jak widać, więc dlaczego tylko scrum masterzy się najczęściej pojawiają? Żeby nie było, nie kpię, tylko się pytam?

Scrum masterzy pojawiają się najczęściej, ponieważ wiele firm traktuje Scrum jako dobry, rekrutacyjny buzz word. Swoisty lep na programistów zaraz obok mikroserwisów i ML. W rzeczywistości większość firm ogranicza się jedynie do rozdania nazw stanowisk i robienia daily. Zupełnie pomijają to czym jest scrum i biorą z niego jedynie ceremonie i nazwy, a nie mechaniki.

To do mnie nie przemawia, ja wiem, że mój przykład to nie jest reprezentacyjny, ale nie znam nikogo kto szedł do jakiejś firmy, bo "scrum". Scrum był chyba w 3 kategorii "potrzeb", jak już zeszło z wynagrodzenia, projektu czy atmosfery trzeba było coś dodać, co jest niby ciekawe. ML i mikroserwisy są wymieniane zazwyczaj na początku, scrum rzadko, jeśli w ogóle.

A dlaczego firmy "rozdają" takie stanowiska? Wydaje mi się, że dobrze to tu wyjaśniłem: https://4programmers.net/Forum/Kariera/323459-zostan_scrum_masterem?p=1573859#id1573859