Project managerzy, product ownerzy i scrum masterzy - czym oni się trudnią?

Spotkaliście kiedyś PM, PO, SM, którzy rzeczywiście byli pomocni dla developmentu? Dla developmentu, nie dla rzeczy biznesowych jak tłumaczenie się przed klientem. Jeśli nie są pomocni dla developmentu to czy nie powinni być odseparowani od developmentu?

Tam gdzie mogliby być pomocni to oni nigdy nie mają czasu dla developerów, bo mają hehe "spotkania".
Pierwszy raz w życiu spotkałem w firmie pomocnego scrum mastera, ale jego pomocniczość wynika z tego, że jest jeszcze product manager w zespole i product owner xD i scrum master zdjął z nich część obowiązków + programiści w zespole mają autyzm i ten scrum master rzeczywiście usprawnia naszą komunikację. Jednak gdyby PM i PO byli normalni, a programiści komunikatywni to nie byłby potrzebny.

PM/PO:
  czym się zajmuje:
  - cały dzień wypełniony spotkaniami, jak mniemam nie mającymi prawie żadnej wartości i mogłyby być skrócone do 30 min. dziennie, 
    ale co by wtedy robił przez resztę dnia?
  - pogania programistów "na kiedy będzie?", "wykres spalania słaby, nie dowoźcie na ostatni dzień sprintu ojojojo"
  - popuszcza ploty np. o tym co jakiś tam hehe manager hehe zrobił hehe
  - pisze enigmatyczne historyjki
  - przekłada taski w jirze z backlogu do sprintu
  czym powinien się zajmować:
  - być dostępny dla programistów na każde skinienie i opowiadać szeroko o produkcie, o tym co chce by było zakodzone, nawet jak ci nie pytają,
    bo się boją albo mają autyzm
  - na bieżąco oglądać pracę developerów, żeby w razie czego powiedzieć, że nie o to chodziło tylko o coś innego
  - ustalać piorytety a nie przekładać taski, o tym decyduje zespół co zrobi
  - prezentować wyniki pracy na demo, a nie że zrzuca to na programistów, bo hehe on hehe nietechniczny to hehe nie umie pokazać 
    np. strzału curlem czy postmanem
  - pomagać w komunikacji między zespołami, jak np. inny zespół ma w dupie i nie chce pomóc
SM:
  czym się zajmuje:
  - prowadzi:
    - daily
    - retro
    - planowanie
    - grooming
  - pogania programistów
  - popuszcza ploty
  - przekłada taski w jirze
  - pomaga w komunikacji między zespołami
  czym powinien się zajmować:
  - niczym, do zwolnienia, niepotrzebna funkcja

Tak, spotkałem. Co do scrum mastera to jest on całkowicie niepotrzebny w zespole. Nie wnosi praktycznie nic czego nie może zrobić jakiś Tech Lead czy PM. Mam tu na myśli "pogananie programistów", organizowanie spotkań z programistami w celu wymiany informacji, doprecyzowywanie wymagań, ogarnianie komunikacji pomiędzy zespołami, itd. Oczywiście taki Lead musi być komunikatywny i ogarnięty w sprawach okołobiznesowych. Raczej stanowisko nie dla programistycznego wymiatacza z autyzmem.

Rolą Project Managera jest pilnowanie harmonogramu prac, raportowanie ryzyk wyżej, eskalacje.

Product Owner zarządza produktem to znaczy analizuje rynek, trendy, zapotrzebowanie na produkt, priorytety i jest źródłem wymagań dla zespołu projektowego.

Mój idealny zespół projektowy w przeciętnym projekcie według powyższego to:

• programiści (od juniora do seniora) do klepania kodu
• testerzy (ze 2 starczy, w tym jeden z umiejętnościami automatyzacji testów)
• tech lead/architect jako pomost między programistami a biznesem
• PM do zadań j/w
• PO do zadań j/w

Oczywiście im bardziej złożony projekt to mogą się pojawić dodatkowe role jak architekt, analityk, ludzie od chmury, itd.

markone_dev napisał(a):

(...) doprecyzowywanie wymagań

a tego nie powinni robić developerzy z PO? przecież lepiej jak sobie pogadasz bezpośrednio z tym co wymyśla zadania niż przez pośrednika

Rolą Project Managera jest pilnowanie harmonogramu prac, raportowanie ryzyk wyżej, eskalacje.

a developerzy czemu nie pilnują swojego harmonogramu prac, a lider harmonogrmau zespołu? Programiści nie powinni sygnalizować, gdy jest ryzyko, że nie zdążą? Przecież i tak to PM jak chce raportować ryzyka to musi odpytać o to programistów.

@LitwinWileński:

a tego nie powinni robić developerzy z PO? przecież lepiej jak sobie pogadasz bezpośrednio z tym co wymyśla zadania niż przez pośrednika

Mogą, ale to teoria. W praktyce PO nie będzie miał na to czasu żeby z każdym siedzieć i mu tłumaczyć. Możesz się z tym nie zgadzać i mieć swoją wizję, ale świata nie zmienisz.

a developerzy czemu nie pilnują swojego harmonogramu prac, a lider harmonogrmau zespołu?

Pilnują, ale developerzy nie są od tego żeby siedzieć w excelu czy MS Project i raportować wyżej postępy prac. Od tego jest kierownik projektu.

Programiści nie powinni sygnalizować, gdy jest ryzyko, że nie zdążą?

Oczywiście, ze powinni ale do PMa i to on bierze na siebie odpowiedzialność za rozwiązanie tego problemu.

Przecież i tak to PM jak chce raportować ryzyka to musi odpytać o to programistów.

Nie. PM nie jest od dopytywania. Jak coś nie działa w projekcie do zgłaszasz to od razu do PMa i on się tym zajmuje, a nie czekasz aż ktoś przyjdzie cię pogłaskać po główce i spytać czy wszystko w porządku.

markone_dev napisał(a):

@LitwinWileński:

a tego nie powinni robić developerzy z PO? przecież lepiej jak sobie pogadasz bezpośrednio z tym co wymyśla zadania niż przez pośrednika

Mogą, ale to teoria. W praktyce PO nie będzie miał na to czasu żeby z każdym siedzieć i mu tłumaczyć. Możesz się z tym nie zgadzać i mieć swoją wizję, ale świata nie zmienisz.

a dlaczego nie mają czasu? przecież to ich podstawowe zadanie, i chyba jedyna szansa (wg mnie), gdzie mogą być przydatni developerom.

a developerzy czemu nie pilnują swojego harmonogramu prac, a lider harmonogrmau zespołu?

Pilnują, ale developerzy nie są od tego żeby siedzieć w excelu czy MS Project i raportować wyżej postępy prac. Od tego jest kierownik projektu.

a czemu w ogóle to raportować co chwila do góry? demo nie wystarcza? co dyrektorom da, że w połowie sprintu dowiedzą się, że no może tej hisotryjki się nie uda a tę się uda? na koniec sprintu widzi na demo co zrobione a co nie.

Programiści nie powinni sygnalizować, gdy jest ryzyko, że nie zdążą?

Oczywiście, ze powinni ale do PMa i to on bierze na siebie odpowiedzialność za rozwiązanie tego problemu.

no i niby w jaki sposób PM rozwiąże problem programistyczny?

@LitwinWileński:

a dlaczego nie mają czasu? przecież to ich podstawowe zadanie, i chyba jedyna szansa (wg mnie), gdzie mogą być przydatni developerom.

Ale teoretyzujemy czy mówimy jak jest? Poza tym to jest dobre pytanie kto tak naprawdę jest komu potrzebny i kto komu płaci za robotę :P

a czemu w ogóle to raportować co chwila do góry?

Nigdzie nie napisałem, że "co chwila".

co dyrektorom da, że w połowie sprintu dowiedzą się, że no może tej hisotryjki się nie uda a tę się uda? na koniec sprintu widzi na demo co zrobione a co nie.

Gdzie napisałem, że PM raportuje do góry co sprint? Poza tym skąd założenie że wszędzie pracuje się w sprintach? No i kolejna kwestia demo jest dla PO a nie dla dyrektorów. Dyrektora interesuje wyłącznie to czy wyrobimy się z pracami przed końcem roku, czy nie.

no i niby w jaki sposób PM rozwiąże problem programistyczny?

Gdzie napisałem, że PM jest od rozwiązywania problemów programistycznych? Czy twoim zdaniem jedyne problemy z którymi musi borykać się zespół programistyczny to te związane z programowaniem? Zmartwię cię, ale nie. Jest wiele innych problemów.

https://en.wikipedia.org/wiki/Scrum_(rugby)

markone_dev napisał(a):

Co do scrum mastera to jest on całkowicie niepotrzebny w zespole. Nie wnosi praktycznie nic czego nie może zrobić jakiś Tech Lead czy PM.

A sam jesteś takim Tech Leadem, który ma obowiązki PO i SM czy tak sobie tylko mówisz bo sam jesteś juniorem, który nie ma żadnej inicjatywy i wypowiada się tylko wtedy kiedy jest wywoływany na spotkaniach?

Praca zespołowa nie polega na tym, żeby zrzucać wszystkie odpowiedzialności na jedną osobę tylko polega na tym, żeby mieć osoby, które dbają o pozornie przeciwstawne cele i w konsekwencji dostarcza się produkt dobrej jakości. Zadaniem Scrum Mastera nie jest poganianie tylko pomoc w usuwaniu przeciwności oraz poprawa komunikacji. W zespole seniorów Scrum Master nie powinien musieć nawet zabierać głosu bo zespół jest tak dobrze zbalansowany.

Ja mam w zespole takich "seniorów", że jak pytam, któregoś z nich czy wprowadziliby drugą osobę w swoją historyjkę albo zrobili prezentację z tego co już mają to odpowiadają "potrzebuję jeszcze pół dnia bo jeszcze nie skończyłem". Ja nie pytam ich czy skończyli. Nie rozumiem dlaczego takie proste pytania sprawiają seniorom takie trudności. I zamiast robić code review to muszę się zajmować później tłumaczeniem przez pół dnia takiemu seniorowi czym jest praca zespołowa. Taką robotę powinien robić Scrum Master.

markone_dev napisał(a):

Tak, spotkałem. Co do scrum mastera to jest on całkowicie niepotrzebny w zespole. Nie wnosi praktycznie nic czego nie może zrobić jakiś Tech Lead czy PM.

Oczywiście, że może - tylko po co czas ma tracić PM albo tym bardziej TL?
Można też zwolnić sprzątaczkę, kible da radę umyć nawet architekt po dwutygodniowym przeszkoleniu.

@twoj_stary_pijany:

A sam jesteś takim Tech Leadem, który ma obowiązki PO i SM czy tak sobie tylko mówisz

Gdy zajmowałem się wyłącznie software developmentem to byłem Tech Leadem i Software Architectem, który robił robotę SM. Z PMem widziałem się raz w tygodniu, żeby zdać update z postępu prac. Na marginesie to nie wiem skąd wziąłeś tutaj PO czyli Product Ownera.

bo sam jesteś juniorem, który nie ma żadnej inicjatywy i wypowiada się tylko wtedy kiedy jest wywoływany na spotkaniach?

Hahaha, taaa jasne :D Z grzeczności nie zapytam jaki poziom ty reprezentujesz.

Praca zespołowa nie polega na tym, żeby zrzucać wszystkie odpowiedzialności na jedną osobę

Dlatego według twojego posta zrzućmy te odpowiedzialności z Tech Leada czy tam PMa na Scrum Mastera :D Fair enough...

Zadaniem Scrum Mastera nie jest poganianie tylko pomoc w usuwaniu przeciwności oraz poprawa komunikacji. W zespole seniorów Scrum Master nie powinien musieć nawet zabierać głosu bo zespół jest tak dobrze zbalansowany.

Czyli nie rozmawiamy o rzeczywistości tylko teoretyzujemy. Ok.

Ja mam w zespole takich "seniorów", że jak pytam, któregoś z nich czy wprowadziliby drugą osobę w swoją historyjkę albo zrobili prezentację z tego co już mają to odpowiadają "potrzebuję jeszcze pół dnia bo jeszcze nie skończyłem". [...]. Taką robotę powinien robić Scrum Master.

Gdyby stanowisko i rola Scrum Mastera było takie wspaniałe to nie byłoby tej dyskusji jak i wielu innych w internecie w tym wylewania pomyj na Scrum Masterów wszelakich, a wszystkie projekty IT gdzie jest Scrum Master były sukcesami :D Smutna prawda jest taka, ze nieudane jak i udane projekty IT były przed powstaniem Scruma jak i po. Wprowadzenie Scrum Mastera do projektów nie zmieniło za bardzo nic w kwestii dowożenia. Ot w większości wypadków kolejne modne stanowisko jak mikroserwisy czy architektury sterowane zdarzeniami wpychane tam gdzie nie zawsze ma sens bo tak jest cool.

somekind napisał(a):

markone_dev napisał(a):

Tak, spotkałem. Co do scrum mastera to jest on całkowicie niepotrzebny w zespole. Nie wnosi praktycznie nic czego nie może zrobić jakiś Tech Lead czy PM.

Oczywiście, że może - tylko po co czas ma tracić PM albo tym bardziej TL?
Można też zwolnić sprzątaczkę, kible da radę umyć nawet architekt po dwutygodniowym przeszkoleniu.

Gdyby Scrum Masterzy rzeczywiście zajmowali się tym czym powinni to by nie było tej dyskusji. Rzeczywistość jednak jest odmienna. Dlatego zapytam po raz trzeci w tym wątku. Czy teoretyzujemy na temat tego kim są i czym zajmują się Scrum Masterzy czy piszemy jak jest w rzeczywistości. Jeżeli to pierwsze to dyskusja nie ma sensu bo rola SM została opisana w Scrum Guide i w zasadzie link do niego wyczerpuje temat dyskusji odnośnie SM.

w zespole często jakaś z tych osób to krewny i znajomy, którego trzeba było gdzieś umieścić, ewentualnie czyjś "przyjaciel lub przyjaciółka" Jak by nie było tych stanowisk to by się ich zatrudniło jako programistę seniora i ktoś z zespołu musiałby poprawiać co chwilę to co napisali

markone_dev napisał(a):

Gdyby Scrum Masterzy rzeczywiście zajmowali się tym czym powinni to by nie było tej dyskusji. Rzeczywistość jednak jest odmienna. Dlatego zapytam po raz trzeci w tym wątku. Czy teoretyzujemy na temat tego kim są i czym zajmują się Scrum Masterzy czy piszemy jak jest w rzeczywistości. Jeżeli to pierwsze to dyskusja nie ma sensu bo rola SM została opisana w Scrum Guide i w zasadzie link do niego wyczerpuje temat dyskusji odnośnie SM.

Jak rozumiem próbujecie dążyć do jakiejś generalizacji na podstawie swoich jednostkowych doświadczeń, nie jestem tylko pewien jak to się ma przekładać na wspomnianą rzeczywistość.
Miewałem w różnych projektach różnych SM, którzy robili różne rzeczy. Czy część z nich była rzeczywista, a część nie?
Często to, że SM niczego nie robi wynika z faktu, że projekt jest scrumowy tylko z nazwy, więc nie ma jak realizować swojej roli, bo ma związane ręce (bo np. o przydzielaniu tasków i zatwierdzaniu urlopów decyduje project manager). To częsta sytuacja w firmach, które chciały być nowoczesne, zapłaciły grubą kasę za szkolenia i certyfikaty, po czym dalej pracują po staremu.

No i pytanie za 100 punktów w nawiązaniu do pierwszego posta - jak można zwolnić rolę?

LitwinWileński napisał(a):

Spotkaliście kiedyś PM, PO, SM, którzy rzeczywiście byli pomocni dla developmentu? Dla developmentu, nie dla rzeczy biznesowych jak tłumaczenie się przed klientem.

Co do SM to tak, co do PO i PM to nigdy bym czegoś takiego nie oczekiwał. Jak niby mieliby mi pomóc?

Jeśli nie są pomocni dla developmentu to czy nie powinni być odseparowani od developmentu?

Jeśli programiści nie będą pracowali dla biznesu, to kto im będzie płacił?

markone_dev napisał(a):

Mój idealny zespół projektowy w przeciętnym projekcie według powyższego to:

• programiści (od juniora do seniora) do klepania kodu
• testerzy (ze 2 starczy, w tym jeden z umiejętnościami automatyzacji testów)
• tech lead/architect jako pomost między programistami a biznesem
• PM do zadań j/w
• PO do zadań j/w

Blisko ideału. Ja bym tylko usunął juniorów, testerów i PMa, bo to całkowicie zbędne osoby.

agile coach, to jest fucha

markone_dev napisał(a):

Gdy zajmowałem się wyłącznie software developmentem to byłem Tech Leadem i Software Architectem, który robił robotę SM. Z PMem widziałem się raz w tygodniu, żeby zdać update z postępu prac. Na marginesie to nie wiem skąd wziąłeś tutaj PO czyli Product Ownera.

Czyli nie rozmawiamy o rzeczywistości tylko teoretyzujemy. Ok.

Gdyby stanowisko i rola Scrum Mastera było takie wspaniałe to nie byłoby tej dyskusji jak i wielu innych w internecie w tym wylewania pomyj na Scrum Masterów wszelakich, a wszystkie projekty IT gdzie jest Scrum Master były sukcesami :D Smutna prawda jest taka, ze nieudane jak i udane projekty IT były przed powstaniem Scruma jak i po. Wprowadzenie Scrum Mastera do projektów nie zmieniło za bardzo nic w kwestii dowożenia. Ot w większości wypadków kolejne modne stanowisko jak mikroserwisy czy architektury sterowane zdarzeniami wpychane tam gdzie nie zawsze ma sens bo tak jest cool.

Pomyje wylewają właśnie tacy "architekci" jak Ty, którzy nie rozumieją roli SM i popularyzują takie opinie jak Twoje. Wprowadzenie Scrum Mastera jest absolutnym game changerem. Żeby to zrozumieć trzeba mieć porównanie, pracować w różnych modelach i rozumieć na czym polega team building. Dołączałem do projektów, które były zawładnięte manią kontrolowania wszystkiego i wszystkich. Cała sztuczka polega na tym, że wprowadzasz tak naprawdę anarchię, zdejmujesz kontrolę i jako Scrum Master skupiasz się tylko na identyfikowaniu problemów w komunikacji.

Ludzie w moim zespole mi zgłaszają na priv, że idą do lekarza, a ja im odpisuję, że po co mi to piszą na priv? Powinni to napisać na zespołowym czacie, żeby ich koledzy z zespołu wiedzieli, że ich nie będzie przez dwie godziny, a nie pytać mnie o pozwolenie, żeby iść do kibla. Jak widać niektórzy przez lata pracy w systemie proletariackim panikują kiedy muszą wziąć odpowiedzialność za swoje życie, swoją pracę i widzą, że każdy z osobna jest odpowiedzialny za tworzenie kultury pracy w zespole.

@twoj_stary_pijany:

Pomyje wylewają właśnie tacy "architekci" jak Ty, którzy nie rozumieją roli SM i popularyzują takie opinie jak Twoje. Wprowadzenie Scrum Mastera jest absolutnym game changerem. Żeby to zrozumieć trzeba mieć porównanie, pracować w różnych modelach i rozumieć na czym polega team building.

:D Robi się grubo... Nie wylewam pomyj na SM ani nie hejtuję, tylko uważam go za zbędnego w projekcie. To różnica.

Co do reszty twojego wpisu to pracowałem w projektach przed modą na Scrum jak i po. W założeniach Scrum Guide masz rację, rola Scrum Mastera powinna być game changerem, ale z jakiegoś powodu nie jest. A jeśli jest to w małym procencie projektów, które faktycznie podążają za Scrum Guide i projekt jak i cała organizacja jest zwinna. Niestety, większość firm i projektów podąża za modą i wdraża pseudo Scrum z pseudo Scrum Masterami.

Cała sztuczka polega na tym, że wprowadzasz tak naprawdę anarchię, zdejmujesz kontrolę i jako Scrum Master skupiasz się tylko na identyfikowaniu problemów w komunikacji.

Naprawdę wierzysz w to, że problemów z komunikacją nie da się rozwiązać w inny sposób niż wsadzając do projektu Scrum Mastera?

Ludzie w moim zespole mi zgłaszają na priv, że idą do lekarza, a ja im odpisuję, że po co mi to piszą na priv? Powinni to napisać na zespołowym czacie, żeby ich koledzy z zespołu wiedzieli, że ich nie będzie przez dwie godziny, a nie pytać mnie o pozwolenie, żeby iść do kibla. Jak widać niektórzy przez lata pracy w systemie proletariackim panikują kiedy muszą wziąć odpowiedzialność za swoje życie, swoją pracę i widzą, że każdy z osobna jest odpowiedzialny za tworzenie kultury pracy w zespole.

Co to ma do dyskusji? Widocznie macie źle określone role i odpowiedzialności w zespole i jeśli potrzebujecie Scrum Mastera żeby wam takie proste rzeczy ogarnął i nauczył ludzi co mają robić to iks de :D

LitwinWileński napisał(a):

a programiści komunikatywni to nie byłby potrzebny.

Łoo panie. I tu cały wywód upada. Znajdź cały zespół komunikatywnych programistów. Może jednego, dwóch, no ale nie cały zespół pracujący w tej samej technologii. Ile by oni kasy chcieli za to że umią w komunikację

@somekind:

Jak rozumiem próbujecie dążyć do jakiejś generalizacji na podstawie swoich jednostkowych doświadczeń, nie jestem tylko pewien jak to się ma przekładać na wspomnianą rzeczywistość.

Na podstawie obserwacji świata wokół.

Często to, że SM niczego nie robi wynika z faktu, że projekt jest scrumowy tylko z nazwy, więc nie ma jak realizować swojej roli, bo ma związane ręce (bo np. o przydzielaniu tasków i zatwierdzaniu urlopów decyduje project manager). To częsta sytuacja w firmach, które chciały być nowoczesne, zapłaciły grubą kasę za szkolenia i certyfikaty, po czym dalej pracują po staremu.

Zgadza się, dlatego rola SM w tego typu projektach jest niepotrzebna i szkodliwa bo nie realizuje celu do jakiego został powołany i tylko szkodzi i sieje zamęt.

Blisko ideału. Ja bym tylko usunął juniorów, testerów i PMa, bo to całkowicie zbędne osoby.

No i ok. Życzę Ci z całego serca abyś pracował w swoim ulubionym setupie projektowym ze SM bez juniorów, testerów i PMa :)

[markone_dev napisał(a)].

Naprawdę wierzysz w to, że problemów z komunikacją nie da się rozwiązać w inny sposób niż wsadzając do projektu Scrum Mastera?

Przyczepiłeś się tych SM jak by bylo oni odpowiedzialni za całe zło w IT, a tak nie jest. Punktem wyjścia dla podejścia zwinnego może być organizacja zespołu i możemy przegadać tysiące godzin na temat brania odpowiedzialności, rozwoju, komunikacji, a na samym końcu i tak musimy zrobić projekt.

Dlatego czasem warto użyć gotowego frameworku, narzucić sztywne reguły przez pierwsze miesiące tworzenia zespołu, a później zacząć je dostosowywać do konkretnego przypadku.

Jak w klasycznym 1. Follow the rule. 2. Break the rule 3. Be the rule.

Problem jest taki, że architekci starej daty mają problem już z pierwszym punktem bo są oporni na wiedzę i nie są team playerami.

@twoj_stary_pijany:

Przyczepiłeś się tych SM jak by bylo oni odpowiedzialni za całe zło w IT, a tak nie jest.

Bo wątek jest między innymi o Scrum Masterach.

Dlatego czasem warto użyć gotowego frameworku

Oczywiście, tylko dlaczego zwykle musi być Scrum ze swoimi ceremoniami i znienawidzonym Scrum Masterem? Jest tyle pięknych metodyk prowadzenia projektów. Ba, można je modyfikować i dostosowywać do swoich realiów projektowych.

Problem jest taki, że architekci starej daty mają problem już z pierwszym punktem bo są oporni na wiedzę i nie są team playerami.

To jak rozumiem o mnie? :D No właśnie tu się mylisz, bo to że nie akceptuję czegoś co jest wszędzie na siłę wciskane, nawet tam gdzie nie pasuje bo jest trendy, nie znaczy że jestem oporny na wiedzę i że nie jestem graczem zespołowym. Wbrew przeciwnie, na podstawie doświadczenia mogę powiedzieć co się sprawdzi w projekcie a co nie bo już swoje widziałem i przeżyłem. I tak, z ostrożnością podchodzę do napompowanych medialnie nowinek i zwykle czekam, aż się wygrzeją przed wprowadzeniem ich do projektu. Tyczy się to zarówno frameworków, narzędzi, architektur jak i metodyk prowadzenia projektów.

Co do bycia graczem zespołowym to od zawsze uważałem i uważam dalej że siła tkwi właśnie w samoorganizujących się zespołach, które nie potrzebują wynalazków typu Scrum Master bo są samowystarczalne. Ale żeby taki zespół zbudować to trzeba mieć wiedzę jak się buduje takie zespoły i tak jak @Miang napisała, nie brać po taniości, tylko po mindsetcie. Jak ktoś nabierze sobie do zespołu juniorów albo samych zamkniętych w sobie autystów lub gwiazdorzących seniorów to nie ma się co dziwić, że potrzebuje potem jakiegoś szamana w zespole, żeby usprawnić komunikację.

markone_dev napisał(a):

Na podstawie obserwacji świata wokół.

Może pora wreszcie wyjść z tej projektowej Odry? :)

Zgadza się, dlatego rola SM w tego typu projektach jest niepotrzebna i szkodliwa bo nie realizuje celu do jakiego został powołany i tylko szkodzi i sieje zamęt.

Oczywiście. Ale to potwierdza tylko, że SM są niepotrzebni w projektach, w których są niepotrzebni.
Co nie znaczy, że nie ma innych przedsięwzięć, w których mogą być potrzebni. Nie są niezbędni, można by ich było usunąć, ale ich zadania magicznie od tego nie znikną, czyli komunikacja zostałaby by przerzucona na programistów albo lidera zespołu.
Ja wolę mieć SM w zespole, i nie musieć nikogo popychać ani dopytywać. Nie dlatego, że nie umiem, tylko dlatego, że nie lubię być wytrącany, gdy skupiam się na programowaniu.

No i ok. Życzę Ci z całego serca abyś pracował w swoim ulubionym setupie projektowym ze SM bez juniorów, testerów i PMa :)

Dziękuję, jakoś tak od ponad 6 lat się udaje. :)

@somekind:

Oczywiście. Ale to potwierdza tylko, że SM są niepotrzebni w projektach, w których są niepotrzebni.

Bo tak jest i o tym pisałem. Clue mojego pierwszego posta jest takie, że SM nie robi nic czego nie mogliby robić inni członkowie zespołu i czego nie robili przed powstaniem stanowiska Scrum Mastera. I tak jak też pisałem SM to żaden game changer w zarządzaniu projektami IT. Dodanie takiego osobnika (oraz Scruma) do projektu nie sprawa magicznie, że projekt będzie sukcesem. Często jest gorzej i pod wpływem takiego micro managementu uprawnianego przez SMa ludzie zaczynają się frustrować i odchodzić z firmy. Bo powiedzmy sobie szczerze, większość firm nie umie w Scrum, a stanowisko SMa stało się ostatnio tak popularne że cytując "co raz więcej amatorów pcha się do zabawy" bo myślą można nieźle zarobić i się nie narobić i jakość spada.

Co nie znaczy, że nie ma innych przedsięwzięć, w których mogą być potrzebni. Nie są niezbędni, można by ich było usunąć, ale ich zadania magicznie od tego nie znikną, czyli komunikacja zostałaby by przerzucona na programistów albo lidera zespołu.

Dokładnie o tym piszę i dlatego napisałem, że lubię dobrze działające samoorganzujące się zespoły, które nie potrzebują szamanów żeby działać wspólnie. Niestety w dobie kontraktorni i wszelakiego outsourcingu, ciężko o taki zespół, bo zwykle jest to jakaś zbieranina ludzi z całego świata, którym kazali wspólnie coś robić.

Ja wolę mieć SM w zespole, i nie musieć nikogo popychać ani dopytywać. Nie dlatego, że nie umiem, tylko dlatego, że nie lubię być wytrącany, gdy skupiam się na programowaniu.

I ok.

Dziękuję, jakoś tak od ponad 6 lat się udaje. :)

Oby tak dalej :)

markone_dev napisał(a):

Bo powiedzmy sobie szczerze, większość firm nie umie w Scrum, a stanowisko SMa stało się ostatnio tak popularne że cytując "co raz więcej amatorów pcha się do zabawy" bo myślą można nieźle zarobić i się nie narobić i jakość spada.

Zgodzę się z tym, że większość polskich SH nie umie w Scrum. Za granicą niekiedy wygląda to mocno inaczej.
Przy czym Scrum sam w sobie nie jest jakimś dobrym rozwiązaniem, ale jak już z niego korzystamy, bo ktoś kazał albo nam za to płaci, to trochę bez sensu nie korzystać z jego możliwości.

Dokładnie o tym piszę i dlatego napisałem, że lubię dobrze działające samoorganzujące się zespoły, które nie potrzebują szamanów żeby działać wspólnie. Niestety w dobie kontraktorni i wszelakiego outsourcingu, ciężko o taki zespół, bo zwykle jest to jakaś zbieranina ludzi z całego świata, którym kazali wspólnie coś robić.

Mnie nie chodzi o wspólne działanie w ramach zespołu. Mnie chodzi o interakcje z innymi zespołami. Ja się nie chcę tym zajmować, i wolę też, aby nie zajmował się tym mój lider. Jeśli jest od tego jakaś inna osoba, to bardzo dobrze.

Ja to nie rozumiem części tej dyskusji. Pewnie większość z was pracowała z ogarniętymi oraz nieograniętymi programistami, pewnie też większość z was się zastanawiała "co ten ${pracownikTechniczny} robi?". I jakoś nikt się nie zastanawia, czym naprawdę zajmują się programiści.

Jedyną z mojego punktu bezużyteczną rolą jest SM. Tzn. rozumiem, po co ta rola jest na papierze, ale z doświadczenia:

• jeśli masz ogarnięty zespół to SM jest niepotrzebny. Wbrew obiegowej opinii - nie jest on potrzebny ani w komunikacji wewnątrzzespołowej, ani poza zespołem.
• jeśli masz zespół, który się dopiero ogarnia to rola SM w ogarnianiu tego zespołu jest bardzo ograniczona.
• jeśli masz zespół, którego się ogarnąć nie da to SM nie pomoże

Oczywiście mówimy o "czystym" SM, a nie hybrydach typu "PO to też SM" czy "PM to też SM" - ponieważ dobry PO/PM potrafi przyspieszyć pracę.

Dyskusję należy zacząć od tego, czy w ogóle cały ten scrum jest do czegokolwiek potrzebny, czy to tylko taka moda. Bo chyba raczej to drugie.

gajusz800 napisał(a):

Dyskusję należy zacząć od tego, czy w ogóle cały ten scrum jest do czegokolwiek potrzebny, czy to tylko taka moda. Bo chyba raczej to drugie.

w takim razie zacznijmy od zdefiniowana kiedy już jest scrum a kiedy juz nie.

Jesli chodzi o ceremonie scruma to:

• daily: uważam za potrzebne, ale powinno być bardziej techniczne, a zazwyczaj jest tak, że biznes je przejmuje
• planowanie: kompletny bezsens, tak jak ktoś napisał, pierwszy raz czytając historyjkę wydaje się wszystko eleganckie, a dopiero jak zaczynasz dłubać wychodzi miliard problemów
  wycenianie tasków powinno odbywać się na zasadzie podziału ich na zadania: do 1 dnia, do tygodnia, do miesiąca, ponad miesiąc. Szacowanie w dniach jest do kitu, dlatego już lepsze to szacowanie story pointami, ale też do kitu.
• retro: uważam za potrzebne
• grooming: uważam, że jest zaprzeczeniem agile. Rozwiązywać problemy powinno się ad hoc na bieżąco, a nie na korpo spotkaniach
• sprinty i demo: bezsens, zaprzeczenie agile. Prezentowanie wyników iteracji powinno odbywać się na bieżąco. Sztywne dema na koniec sprintu powodują to, że na koniec programiści robią coś byle jak i w pośpiechu dopychając często robiąc jakąś sztuczną pracę typu mocki w serwisach, żeby coś ładnie wyglądało na demo

Na co dzień bardziej przeszkadzają niż pomagają. Jednak w przypadku jakichś interakcji między zespołowych / biznesowych, przydają się. To są ludzie od gadania - niczego więcej. Temat scruma to rzeka :D Zwykłe narzędzie do micromanagamentu. Zawsze mi się chce śmiać jak taki SM podkreśla, że nie ma to nic wspólnego z kontrolą <3

Ok to tyle teorii. A praktyka wygląda najczęściej mniej więcej tak: