Jak zapobiec temu, by Scrum nie zmienił wielkich programistów w przeciętnych programistów?

Znalazłem to również zdarzyło się w mojej drużynie, chociaż może trochę przesadził.

Scrum to sposób, aby wziąć poniżej średniej lub biednego dewelopera i obrócić je do przeciętnego dewelopera. To również świetny sposób na zabranie świetnych deweloperów i zamieniając ich w przeciętnych deweloperów.

Wszyscy chcą po prostu zdjąć z zarządu co¶ łatwego, co można... zrób to w ciągu dnia, żebyś miał coś do zgłoszenia w jutrzejszym dniu > Scrum. Po prostu wszyscy próbują zrywać nisko zawieszone owoce. There's no incentive to be smart and to take time to think about solutions, if nothing is moving across what are you even doing? Jesteś zawodząc zespół w dół! Prędkość spada!

Myślę, że jeśli masz trudne problemy do rozwiązania, rozwiążesz je dając ...a potem zostawić ich w spokoju. Ty nie... /Ciągle nękają ich każdego dnia, /żądając wiedzy o tym, co zrobili. wczoraj i co zamierzają zrobić dzisiaj. Z codziennymi aktualizacjami gdzie jest zachęta dla inteligentnych ludzi do pracy nad ciężkimi problemami? Oni teraz mają taką samą motywację jak młodszy deweloper; znajdzą najłatwiejszą bilety na przejazd po całej burcie.

Czasami będę chciał po prostu być sam i zastanowić się nad rozwiązaniem dla kilka dni. Gdybym to zrobił, choć nie miałbym nic do powiedzenia w scrumie. So instead instead I'll pick the user story where the colour on a front end był złym odcieniem zieleni albo błędem w pisowni! Widzisz, znokautowałem 2 historie w jeden dzień, przed lunchem! Idź do mnie!

...

Nie do końca zgadzam się z jego słowami. Np., zgadzam się z jednym z komentarzy powiedział, to nie to, że oni (menedżerowie) im nie ufają, to, że nie robią rzeczy bez stałego nadzoru.

Kiedy wielki programista staje się przeciętnym programistą, zawsze jest wiele powodów, ale uważam, że codzienny scrum może być jednym z nich. Więc jak mogę zapobiec temu efektowi ubocznemu spotkań scrum?

Zdałem sobie również sprawę, że łatwiej jest to powiedzieć niż zrobić, ale lubię widzieć, jak inni widzą ten problem.

----- aktualizacja -----

Po przeczytaniu wszystkich odpowiedzi, które mam do tej pory, zdaję sobie sprawę, że muszę dodać kilka informacji, aby moje pytanie było bardziej istotne.

Zanim jednak do tego dojdę, chcę powtórzyć słowa Martin Maat podane w jego odpowiedzi: "Sam fakt, że tak wiele osób odczuwa potrzebę powiedzenia czegoś na ten temat, jest wskaźnikiem przyczyn frustracji Scrum".

Całkowicie się zgadzam! Kiedy po raz pierwszy zadałem pytanie, spodziewałem się, że niektóre odpowiedzi będą następujące: "Oh, nie robisz dobrze Scrum!"

Niektóre poprawki, które chcę wprowadzić do mojego pierwotnego pytania, to..,

1. Użyłem słowa "dobry programista" i prawdopodobnie powinienem po prostu powiedzieć dobry/ przyzwoity programista, ponieważ widziałem te odpowiedzi z boku. Poza tym, przez całą moją karierę nigdy nie pracowałem ze świetnymi programistami, więc nie powinienem tego używać w pierwszej kolejności. Chodziło mi o to, że od czasu do czasu widziałem, że scrum sprawia, że dobry programista wypada gorzej.
2. Niektóre odpowiedzi skupiają się na zdaniu "to jest to, że nie załatwiają spraw bez stałego nadzoru" i uważały, że jest to kwestia mikromanżowania. Ale to nie była moja sprawa, np. ja nie zajmuję się mikromanewrowaniem. Problemem, którego doświadczyłem (znów od czasu do czasu) jest to, że programiści dobrzy/opiekunowie techniczni niekoniecznie są ostrożni w biznesie. Czasami zbytnio koncentrują się na doskonaleniu swoich rozwiązań technicznych, nie zdając sobie sprawy, że mamy produkt do dostarczenia w końcu. Innym razem jest to cecha wielofunkcyjna, która wymaga koordynacji, zwłaszcza, że każdy zespół może mieć swój własny priorytet/harmonogram. Dlatego właśnie potrzebują nadzoru. Ale chyba nie powinienem po prostu kopiować słowa "ciągły nadzór" z oryginalnego postu i nie powinienem używać w pierwszej kolejności ciągły. Ale znowu, jeśli ktoś twierdzi, że "świetni deweloperzy" i "świetny zespół" tego nie robią, nie mam wtedy kontrargumentu.
3. Jedna z odpowiedzi brzmiała: "codzienne scrumy jakoś zamieniły się w konkurs, który zakończył się największą ilością zgłoszeń". I nigdy tego nie doświadczyłem. Dojrzała drużyna tego nie robi (dojrzała nie musi być jednak wspaniałą drużyną). Czy ktoś tego doświadczył?
4. Dla tych, którzy zaproponowali mi przeczytanie zwinnego manifestu, moim kontrargumentem jest to, że w 2008 roku (12 lat temu) napisałem długą recenzję książki do książki "The Enterprise and Scrum (Developer Best Practices)" współzałożyciela scrumu Kena Schwabera. Wymieniłem moją recenzję tutaj, nie po to, by się popisywać, ale by pokazać (1) Uważam, że scrum zrobiłem wystarczająco długo, by dostrzec jego siłę i słabość. (2) Wiem, na czym polega zwinność.