Я вот безотносительно конкретного кейса готов сказать, что смысл в ретроспективе есть, если вам вообще нужен Agile. Почему, потому что Agile manifesto:

Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Далее, даже если не разделяют agile manifesto, вы как SM/руководитель/etc: наверняка знаете что можно работать эффективние. И в этом и есть смысл.

Даже если бизнес сейчас устраивает текущая производительность, то развивайтесь как SM, достигая с людьми большей производительности

Спасибо всем за советы! Ничего плохо не вижу пока, вот просто обдумываю, как можно попробовать развивать эту ситуацию.
Никита - это слишком высокий для меня уровень абстракции пока, но тоже спасибо.

Вообще я думала именно про ответ Ивана как первый шаг, команда на стадии формирования, правила вообще нужны. Общие соглашения (п1).

Вариант Славы мне тоже нравится, но есть некоторые опасения.

Женя, спасибо. У наших камеры есть, но некоторые не включают, посмотрим как пойдет с соглашениями. Я пока начала с себя с включением.

Михаил, тоже спасибо...а где этот вопрос лучше задавать (ну если будут какие-то последствия) - один на один или на общем собрании?

Я просто попала прямо в центр торнадо, пытаюсь откусывать маленькие куски.

С пониманием улучшений тоже все плохо - ретро раньше не было, если и было - никаких улучшений особо не происходило. Так что нужно восстановить доверие к инструменту тоже.

@pavlovajane коллеги, можно поподробнее про нездоровые амбиции? Это когда человек хочет работу,должность, но не может ей соотвествовать? У меня вот наоборот, очень пасивные люди, которых все устраивает и из зоны комфорта выходить не хотят. Или хотят, но сформулировать не могут. Как эти амбиции развивать? При этом в рамках возможностей того или иного человека?

Катя, а можешь потом отписать, что предприняли и как прошло? У меня тут они тоже стали торчать, у некоторых частей команды. Вот буквально сегодня вылезли на пленнинге. Я про амбиции

Как эти амбиции развивать? -> Узнать их настоящую мотивацию + Показать им ответственность, которую вы им можете передать, но не обязанность. Ответственность, которая станет внутренней мотивацией, а не внешним напрягающим фактором.

Сергей, мы тоже используем LeSS и договорились о подходе, когда есть команды-оунеры компонентов. Изменения в компонент могут вносить любые команды, но оунеры обязательно проводят ревью, поэтому отвечают за его кволити и как следствие баги в компоненте фиксит оунер. В случае же если багов по компоненту очень много, то команда эскалирует и подключает другие команды к фиксам, если баги критичные и блокируют выпуск продуктового инкремента в конце спринта

Мы используем практику аукциона. Раз в спринт публикуется пачка багов и команды сами разбирают себе тикеты в спринты

вообще странно что баги распределяются. баги это очередь запросов с разной степенью приоритета внутри, она должна потихоньку вытягиваться той командой, которая наиболее свободна для их разрешения ))

» 3. Оставшихся участников сделать multifunctional — моя боль.. еденицы готовы, хотят и могут быть multifunctional. Разработчики готовы писать код, хороший код, - но требовать с заказчика, условно, данные? Нееее.... Это вон аналитики, они за это работают. Аналитикам лишний раз написать заказчику напоминалку? Нееее... Ты манагер, ты и спрашивай со всех.. 😢 Может у меня команда не на том уровне эволюции, но свои задачи все далеют хорошо, а шаг влево - все..

Это вам нужно почему-то, а не им. Им зачем это?

В общем очередь багов это очередь, как работать с очередями запросов лучше всего описано в канбан-методе. В скраме там все усложняется в разы и этот вопрос просто спускается командам на откуп, чтобы они нашли "способ" это делать.