Как справиться с ситуацией, когда один член команды не хочет участвовать в ретроспективах?

Команда работает вместе пару месяцев. Они находятся где-то между этапами нормирования и выполнения. Все члены команды увлечены своей работой и продуктом, над которым работают. Один из членов команды говорит, что ретроспективы ему не нужны. Он побывал на многих из них (от 30 до 50) в разных командах и пришел к выводу, что вместо этого предпочитает делать работу, связанную с разработчиком.

В то же время он сотрудничает — помогает другим, соблюдает правила команды, активно участвует в других собраниях и т. д. Он также хороший инженер. Команда не хотела бы потерять его; иными словами, решение с увольнением его из команды неприемлемо.

Как остальные члены команды относятся к полезности ретроспектив? Если они находят их полезными, и они ценят его вклад, и он хочет помочь другим, то дело не в его пользе, а в их. :) Один из подходов, который я использовал с членами команды, которые не видят ценности в том, что ценит команда, заключается в том, чтобы предложить им создать свой собственный формат или процесс, который, по их мнению , будет работать для всех участников.
Почему он говорит, что не получает пользы от ретроспектив? Кажется, у него нет проблем с форматом других церемоний, так что же делает ретроспективы проблематичными? Кроме того, я согласен с комментарием @JeffLindsey — что другая команда думает о ретроспективах? Они также считают, что они не получают выгоду? Возможно, в вашем ретроспективном процессе есть что-то, что можно улучшить.
Не потому ли, что он считает, что действия по ретроспективе никогда не выполняются (особенно те, в которых изменение не входит в компетенцию команды). Я видел это и, честно говоря, не смог решить его полностью.
Пожалуйста, примите во внимание, что ретроспективный процесс не имеет недостатков. 5 членов команды получают от этого пользу, только 1 нет.
«Пожалуйста, примите во внимание, что ретроспективный процесс не имеет недостатков». Общая идея Agile заключается в том, что все можно улучшить, но это не обязательно означает, что в нем есть недостатки.
@SpoonerNZ Это правда. Улучшением в этой ситуации может быть то, что этот один член команды не будет участвовать в ретроспективном совещании.
Если вы действительно считаете, что это решение, опубликуйте его как ответ на свой вопрос. Я не вижу в этом хорошего решения, так как тогда этот член команды не будет знать об изменениях, которые команда вносит в свою работу, или, что более важно, не поймет причины, лежащие в их основе. Это также создает прецедент: «Наши встречи не важны, просто скажите, что не хотите приходить, и мы не будем их проводить». Я подозреваю, что за такое решение в целом проголосуют отрицательно.
@SpoonerNZ Я не думаю, что это хорошее решение. Это просто идея. Моя точка зрения была больше похожа на то, что улучшение не всегда должно означать следование общим рекомендациям, то есть «вся команда должна участвовать» в данном случае. Я также думаю, что есть краткосрочные и долгосрочные улучшения. В краткосрочной перспективе эта установка просто снимает напряжение, а в долгосрочной перспективе член команды может передумать, потому что он действительно будет скучать по ретро :-)

Ответы (5)

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

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

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

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

Это не тот случай. Член команды, упомянутый в вопросе, не говорит, что ретроспективные результаты плохи. Он также не пытается подорвать процесс. Все, что он говорит, что он хотел бы тратить свое время на разработку, а не на ретроспективу, потому что, по его мнению, он приносит больше пользы. Кроме того, как я уже писал в вопросе, он дружелюбный, опытный (не звезда), готовый помочь и т. д.
Но я согласен, что этот подход был бы хорошей отправной точкой для исправления цикла проверки и адаптации.

Вы не можете вносить изменения, не принимая изменений

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

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

По сути, вы сделали Scrum-фреймворк необязательным для этого разработчика, но пытаетесь получить свой пирог и съесть его. Если вы собираетесь позволить каждому члену команды выбирать те части фреймворка, которые им нравятся и которым они готовы следовать, то вы не просто приглашаете Scrum- но, но, по сути, отказываетесь от строгости (и, скорее всего, от преимуществ) вашей реализации Scrum.

Можно сказать, что данная структура не работает для вашей команды и вашей организации; конечно, есть и другие фреймворки на выбор. Тем не менее, у вас должна быть какая -то структура управления проектами со строго соблюдаемым контролем, если вы не хотите вызывать анархию.

Примадонны не гибки

У вас есть кто-то, кто не вписывается в ваш командный процесс. Это оставляет вам следующие варианты:

  1. Переоцените формат и эффективность ваших ретроспектив, а затем настройте церемонию так, чтобы она стала полезной для всех.
  2. Предоставление обучения, стимулов и последствий для обеспечения эффективного участия всех членов команды в этой обязательной церемонии Scrum.
  3. Откажитесь от процесса Scrum, если вы все равно не планируете ему следовать.

Scrum — это командная работа. Одинокие волки, даже если они технические рок-звезды, токсичны для гибких процессов.

Ретроспективы требуются Scrum Framework

Один из членов команды говорит, что ретроспективы ему не нужны.

Этот член команды упускает суть. Выиграет ли он от ретроспективы или нет, не имеет значения; реальная проблема заключается в том, получает ли команда пользу от ретроспектив.

Кроме того, Ретроспектива Спринта — это формально определенная Scrum-церемония , необходимая для процесса проверки и адаптации. Это означает, что вы должны проводить ретроспективы, если придерживаетесь формальной схемы Scrum. Неспособность провести эффективные ретроспективы спринта снижает эффективность структуры и противоречит основным принципам гибкой разработки.

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

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

Без обид, но это много абсолютных советов, и у нас очень мало контекста. Я хочу, чтобы он ответил с дополнительной информацией! :)
Подробный ответ :-) Насколько я понимаю, в Руководстве по Scrum говорится, что в нем должна участвовать вся команда. Я намеренно не пометил свой вопрос Scrum и не упомянул сам Scrum в вопросе.

Какой формат вы используете для своих ретроспектив? По моему опыту, изменение формата может повысить уровень участия. Если вы просто используете «колесо перемен», ожидая, что члены команды будут говорить открыто перед своими коллегами, попробуйте немного изменить его. Создавайте гистограммы для основных областей и попросите членов команды прикрепить стикеры к тому, насколько хорошо они (лично) оценивают эффективность в этой области. В качестве альтернативы попробуйте подход «Однажды в ретроспективе», описанный на StickyMinds.com. Прежде всего, убедитесь, что вы документируете все предлагаемые изменения и назначаете действия членам команды, а затем следите за ними до или в начале следующей ретроспективы.

Обычно я выбираю Start Stop Continue, но время от времени добавляю другие форматы (скажем, каждое 3-е ретро). Это хорошее решение, спасибо :-)

[Изменено] Как упоминалось ниже, я неправильно истолковал реакцию, предполагая, что невыполнение действий было основной причиной неявки. Таким образом, приведенный ниже ответ может быть не по теме, но я оставил его здесь, так как чувствую, что он все еще может быть полезен для читателей этой темы.

Я думаю, что член команды прав, если он считает, что действия, вытекающие из ретроспективы, не предпринимаются; это серьезная проблема.

Было ли это расследовано, известны ли первопричины? Это было бы первое, что я бы сделал.

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

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

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

Автор вопроса не заявляет, что этот член команды считает, что действия, вытекающие из ретроспектив, не выполняются.
Моя ошибка, я видел это упомянутым в предыдущем обсуждении и неправильно истолковал это как исходящее от Бартека Кобылецкого, который задал вопрос. Спасибо, что указали на это jordix!
Как справиться с ситуацией, когда один член команды не хочет участвовать в ретроспективах?
СпросиСетьПолитика конфиденциальности1y, 1v