А где статистика по Project/Product managers и PO?
С моего опыта, на этих позициях очень много девушек, а с тем что я на эти должности собеседую, есть еще любопытное наблюдение что как раз девушки обычно самые лучшие кандидатуры.
Почему-то эта область работы в айти опускается в рассказе, а зря. Руководителей девушек очень много, и нередко они компетентнее мужчин.
Нет излишнего апломба, а лишь стремление доказать свой профессионализм.
Так что не там роете. Если хотите найти девушку девопса и не находите, то зачастую вывод о дискриминации это кривое и софистическое трактование данных.
P.S. Проблема мизогогии и сексизма есть только в отдельно взятых случаях, но так же круто их раздувать до объёмов обычного поведения в отрасли, ведь сейчас это популярно и наверняка соберет отзыв.

Вы ответили на какой-то другой вопрос как и примеры они не опровергают или доказывают мой тезис. Скорее вы посчитали, возможно из-за негативного опыта работы на галерах, что я предлагаю внедрять офисную культуру в каждую щель жизни человека. Это полный бред, и я сам против ситуаций когда человеку неприятно, но компания переходит границу личного ( чего только стоят поздравления всем офисом с днём рождения...)
Рекомендую почитать о хикикомори как о феномене. Действительно интересный социальный, или скорее асоциальный, способ жизни. Т.к. одной из основ моего вывода был этот материал плюс пресловутый нетворкинг, который при должном умении сильно улучшает качество жизни.
Подход что удаленка однозначное благо — слишком однобокий взгляд на ситуацию.
Простите , но нужно смотреть шире нежели свой личный комфорт и определять его как единственный параметр для вывода что есть плохо или хорошо.

Эта ситуация, как и все вокруг, имеет плюсы, минусы и серую зону.
Действительно тем кто зарекомендовал свою продуктивность в домашней обстановке и все участники процесса не имеют претензий к качеству выполнения задач, не стоит, а порой и опасно заставлять возвращаться в офисную среду.
Но, есть пласт специалистов, особенно юнных только вышедших из университета или кто еще учится, кого нельзя лишать социальных взаимодействий. Подобная ситуация сделает медвежью услугу начинающим жить самостоятельной жизнью людям. В долгосрочной перспективе всегда решает навык общения, налаживания коммуникаций да и нахождения в обществе как таковом. Поколение хикк манит своей возможностью организовать мир как им удобно, удаляя «ненужные» социальные интеракции , но зачастую такой мир разрушается при встрече с реальностью.
Потом читаем на доу статьи о том как найти девушку, хобби и вопросов о выгорании которые не с кем обсудить кроме интернет друзей.
Я считаю что в каждом случае нужно решать индивидуально, но подход — всех под одну гребенку, уже совершенно не работает.

Зачастую в подобных темах в комментах безнадега и жесткая критика. От же скрам паршивый, не дает разрабатывать...
Ретроспектива только тогда ретро если после нее есть изменения. Эти изменения должны быть маленькими, конкретными, приносящими очевидную пользу и выполнимыми. Что где и когда менять решает сама команда.
По опыту могу сказать что самое тяжелое в ретро это приводить в жизнь изменения. Зачастую подход — «работает — не трожь». Потому почти все идёт со скрипом.
Если нет должного уровня организации и поддержки команды в изменениях, то так и будут в темах о ретро ныть про скрам и что вообще лучше писать лишь код, а не тратить время на действительно проявления карго культа.

Статья представляет собой сборник ситуаций, которые редко встречается в проекте с настроеными процессами. Но все вышеперечисленные ситуации корелируется со стадией динамики работы команды и maturity процессов, имея прямую зависимость.
Действительно разработчики, не всегда ломятся сразу чинить или делать работу вне скоупа тикетов. И это правильно.
С чётким распределением ролей всегда понятно кто принимает последнее решение. Задача всей команды состоит в том чтобы делать то что нужно и что матчится с целями, которые задают и описывают PO/PM и другие руководящие стейкхолдеры процесса, в том числе заказчики.
Качество выполненных задач на плечах всей команды, если же разработчики единогласно решает судьбу багов, то ни о какой командной работе не идёт речи. Ровно так же если бы только QA принимал такие решения.
С каждым кейсом нужно понять почему именно разработчик так отвечает и вывести абстрактные ответы в конкретные причины уже с которыми можно работать.
Важно помнить что люди ленивы, и проще ответить без аргументов, хотя за такой формой может находится весьма весомые доказательства. Нужно лишь копать.