trojanus
2019-04-12 17:11

O decyzjach jako-takich...

Mój zespół zajmuje się dwoma projektami: jeden jest komercyjny, a drugi niekomercyjny - jeszcze - bo są plany żeby go zacząć sprzedawać, ale zanim to nastąpi to czeka nas długa droga. Ogólnie zasadę przyjęliśmy taką, że jeśli ktoś nie ma ciśnienia w projekcie komercyjnym, to sobie coś podłubie przy projekcie niekomercyjnym. Wszyscy, oprócz jednego kolegi - Player1 - byli niestety obłożeni pracą dla klienta. Player1 sobie brał taski z backlogu drugiego projektu i sobie je rozwiązywał, no i zamknął wszystko co można było z zadań ułożonych przez PO - innymi słowy zamknął Sprint. Powiedzmy, że zamknął, bo pracujemy w kanbanie, więc w zasadzie czekamy na decyzje PO co robić dalej.

Dziś Scrum Majster wywołał uśmiech na mojej buzi. Otóż stwierdził, że skoro wszystkie taski zostały zrobione przez Player1, a reszta "w ogóle się nie angażuje", to Player1 dostaje bana na robienie tasków! O! Bo jako Scrum Majster to jestem odpowiedzialny za proces w niekomercyjnym projekcie i nie może być tak, że jedna osoba robi, a reszta nie robi!

Już pomijam szkodliwość tej decyzji dla biznesu, ale zakładając że układ rozmieszczenia sił pomiędzy projektami się utrzyma, może się okazać, że następnego Sprintu nikt nie ruszy. Najwyżej będę słyszał jak Scrum Majster tupie nogami ze złości. :)

grski

Dajcie mu plakietke Scrum Slave

Desu

„I have to eliminate Scrum and Agile before I die” - Erik Meijer

superdurszlak

Scrum Majster zawalił sprawę, jakby robił mu codzienny stan d**py, backlog refinement dwa razy w tygodniu, 3h planning + estymaty to by za Chiny nie podomykał wszystkiego, tylko np. 90% i wszyscy byliby zadowoleni :]

LukeJL

Otóż stwierdził, że skoro wszystkie taski zostały zrobione przez Player1, a reszta "w ogóle się nie angażuje", to Player1 dostaje bana na robienie tasków! -- Kolejny przykład na to, że Scrum spowalnia i że ukrytym celem Scruma jest robić projekty wolniej (i sabotować postęp), jeśli osoba, która zrobiła więcej tasków w danym projekcie, jest karana za aktywność.

LukeJL

Poza tym widzę tutaj nie wykorzystany potencjał (Player1 z jakichś powodów upodobał sobie drugi projekt i udało mu się osiągnąć w nim ponadprzeciętną wydajność. I teraz - zamiast to wykorzystać i ułatwić Playerowi1 pracę w projekcie, jaki mu się spodobał (i w którym stał się wydajny), to próbuje się ściągać go siłą i równać w dół (i nie może być tak, że jedna osoba robi, a reszta nie robi!). Z drugiej strony - jak jedna osoba robi projekt, to nawet jak zrobi to kilka razy szybciej niz zespół, to wtedy jest bus factor = 1 (i Player1 byłby jedyną osobą, która wiedziałaby jak jest zaimplementowany ten drugi projekt), więc też niedobrze.

trojanus

@LukeJL: kilka słów sprostowania, żebyś sobie jeszcze czegoś nie wymyślił :D Player1 robił ten projekt przez 1.5 roku razem z PO, który też jest czasem devem, więc chwała im! Także oni znają projekt na wylot. Reszta zespołu, w tym ja,
nie znamy, ale i tak mamy co robić. W końcu ktoś musi finansować te "niekomercyjne" projekty :D

Shalom

+1 dla bus factora. Ja się nie dziwię takiej decyzji. Bo teraz co, Player 1 się zwalania a wy zostajecie w projektem którego nikt nie zna? Powodzenia ;) Widocznie jakoś dziwnie to planowaliście że nigdy nikt inny nie robił niczego przy tym projekcie ;]

trojanus

@Shalom: hehe, no coś Ty, nie masz wyrobionego autyzmu? Przecież to łatwo przeczytać w kodzie co się dzieje :D

superdurszlak

@Shalom: wystarczy odrobina chęci i odpowiednio ostry nóż na gardle - wszystko się da :D

mr_jaro

@Shalom nie widzę w tym nic szczególnego kilka razy na rok trafiam na taki projekt, gdzie nikt nic nie wie co się działo, czasem jest jakaś dokumentacja ale zazwyczaj nie ma ;)

cmd

Ale proszę was nie mylcie pojęć. To nie Scrum jest winny że zarządza nim jakiś ortodoksyjny scrum master :D. Nie wiem też co do tego ma bus factor. Skoro póki co mowa o jednym sprintcie, a zakładam że mimo wszystko CR jego zmian było robione z poszanowaniem dla zasad przez innych członków zespołu a zmiany są udokumentowane prawidłowo. Jeśli tak nie ma tu jakiegoś większego zagrożenia. Dla mnie to przykład właśnie skrzywionego podejścia do Scruma i zarządzania zespołem.

piotrpo

To nie jest problem scrum'a, kanbana, agile'a tylko (zakładając, że sytuacja faktycznie jest tak absurdalna jak tu opisano) cymbała na stanowisku scrum mastera, dla którego dostarczenie działającego produktu jest jedynie stanowiącym nadmierny ciężar tłem do planowania, estymowania, błyszczenia na meetingach, rysowania takich czy innych słupków. Prawdopodobnie jest to też problem organizacji, bo decydowanie kto co ma robić w produkcie jest akurat decyzją zdecydowanie wychodzącą daleko poza jego kompetencje.

somekind

Pytanie zasadnicze, co sprawia, że na stanowisko scrum mastera tak przyciąga cymbałów? Czyżby ludzie, którzy mają jakiś sensowny fach, wolą robić coś konkretnego? A może to stanowisko po prostu ogłupia każdego, kto się na nim znajdzie?

superdurszlak

@somekind: przedstawiłem już hipotezę w wątku o scrum masterach. Scrum master, który prowadzi zespół scrumowy tak, by faktycznie było z tego więcej pożytku, niż szkody, podcina gałąź, na której siedzi - jak już będzie dobrze, nie będzie potrzebny scrum master w zespole

cerrato

Programista musi posiadać wykształcenie, doświadczenie zawodowe, zdolność logicznego i analitycznego myślenia, wiedzę, umiejętność pracy pod presją itp. A taki scrum-czarodziej zarobi podobnie (a nieraz lepiej) wykonując egzorcyzmy, których się nauczył na 3-dniowym intensywnym kursie. I tak się zastanawiam - kto tak naprawdę jest cymbałem ;)

LukeJL

@somekind to trochę jak z politykami. Wśród polityków też jest masę cymbałów... Pytanie tylko, czy porządny człowiek nie pcha się do polityki, czy może sam fakt bycia politykiem i "rządzenia" tak degeneruje ludzi...?