Доминирующие члены команды в команде Scrum

22

Что бы вы сделали в ситуации, когда член команды пытается взять на себя обязанности, изначально не переданные ему, а перед Скраммастером?


источник
5
Следует ли это перенести на pm.stackexchange.com ?
Абдель Рауф
1
Я не уверен, как это на самом деле относится к Scrum или программированию в этом отношении. «Доминирующий член команды затмевает всех в команде».
Оз
5
Я не согласен с переходом на pm.stackexchange.com, потому что Scrum master не PM, а проект Scrum не должен иметь PM.
Ладислав Мрнка
3
Похоже, что вы единственный в своей команде, кто обеспокоен. Брось ему вызов на дуэль.
JeffO
2
Я скучаю по важному контексту в этом вопросе. Может случиться так, что «доминирующий» разработчик берет на себя больше обязанностей, потому что он искренне чувствует, что мастер схватки недостаточно эффективен и пытается улучшить работу команды, возможно, он хочет кормить свое эго и превосходные навыки, возможно, он действует в доброй воле и просто не осознавая потенциального разрушительного воздействия на команду, возможно, он просто придурок ... или, может быть, проблема в самом мастере схваток.
MaR

Ответы:

17

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

Что ты можешь сделать:

  • Мотивируйте других быть независимыми, но сотрудничать - это может быть наилучшим образом достигнуто, если вы будете сотрудничать с их менеджером и сотрудником отдела кадров, который установит им некоторые ожидания, которые будут оцениваться на регулярной основе.
  • Во время стоянки, планирования и ретроспективы; пусть другие члены команды выступят первыми Во время проверок пусть другие члены команды представят истории пользователей, которые они реализовали.
  • Пусть другие сначала выбирают задачи, чтобы доминирующий разработчик не мог выбирать только те задачи, которые он хочет выполнить.
  • Привлекайте парное программирование для некоторых задач, чтобы доминирующий член команды сотрудничал с другими разработчиками.
  • Будьте демократичны - мнение одного члена команды недостаточно для внесения изменений в процесс - Scrum будет работать только в том случае, если команда общается четко или вы просто блокируете друг друга.
  • Если ничто из этого не помогает, поговорите с доминирующим членом команды и объясните ему ситуацию, но будьте осторожны, в Scrum нет лидера команды по какой-то причине. Если у вас есть поддержка со стороны руководства, вы также можете угрожать стабильности его работы, но это должен быть самый последний вариант.

Если доминирующий член команды не хочет терять свое доминирование, а пассивные члены команды не хотят быть более активными, вам понадобится поддержка их менеджера и HR. Это может быть проблемой, если руководство не поддерживает процесс Scrum.

Ладислав Мрнка
источник
14

Предположительно, причина этого вопроса в том, что вы чувствуете, что команда как-то неэффективна из-за этого доминирующего человека. Возможно, потому что остальная часть команды не вносит 100%, потому что, ну, в чем смысл?

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

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

Все это сложно, но для этого нужны менеджеры и Scrum Masters.

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

Дейв
источник
1
Просто отличный ответ.
Ладислав Мрнка
Мне нравится ваше внимание на обратную связь.
съеживаться
7

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

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

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

rupjones
источник
Это отличный способ переосмыслить проблему. Обращение за помощью полностью меняет ситуацию (и делает ее намного менее пугающей).
Джо Уайт
5

Похоже, он пытается быть Scrum Master.

Уточните свои позиции и действуйте соответственно.

Роль Scrum Master заключается в том, чтобы задействовать командный дух. Если вы не можете сделать этого единственного человека командным игроком, удалите его из команды .

Краткое примечание: ваш доминирующий разработчик не более проблематичен, чем ваш пассивный разработчик.

работа
источник
3
Хотя это хорошая черта, просто удалить кого-то из команды легче сказать, чем сделать в большинстве случаев, я бы подумал, Пьер.
Оз
@james: не могли бы вы сказать мне, почему?
Ну, ограничив людей работать над проектом для одного. Перемещая его в другую команду, другая команда испытывает неудобства и может сопротивляться. Сохранение знаний о проекте было бы другим (легко сказать, что знания должны распространяться, но на самом деле это не так). Это 3 очень РЕАЛЬНЫЕ причины, почему это легче сказать, чем сделать. Не то чтобы это не могло быть сделано, конечно. Конечно, может быть, вы имеете в виду уволить его :-)?
Оз
1
Я живу в Великобритании, и наличие доминирующей личности не является причиной, чтобы кого-то уволить, вам нужно намного больше, чем это!
Оз
1
@Pierre - намного сложнее уволить людей в Великобритании, чем, скажем, в США. Но, показывая образец плохого поведения и предупреждений, тогда да, конечно, кто-то может быть уволен. Я не уверен, что эта конкретная ситуация будет легко уволить кого-то из Великобритании. Хотя я могу ошибаться.
Оз
2

в настоящее время планирование спринта - это роль, которая вращается в команде

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

Если то, что вы говорите, является правдивым и объективным, тогда у вас есть серьезная проблема: люди, которые не участвуют, и «Доминатор», который мешает действительно гибкому процессу. Как мастер барабана, вы должны действовать. Может быть, вы бы хотели, чтобы ваш менеджер проекта был уверен в этой ситуации.

DPD
источник
2

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

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

Запланируйте всю ретроспективную сессию вокруг этого. Получить их, чтобы зафиксировать некоторые значения и следить за во время следующей ретроспективы. Не указывайте пальцем, используйте нейтральные методы.

Представьте методы, которые заставляют других членов высказывать свое мнение безопасно. Нечто простое, как пять , отлично подходит для того, чтобы услышать тихие голоса в команде. Это до боли очевидно, что команда не согласна с доминирующим парнем. Planning Poker работает хорошо, но главное - не допустить никаких обсуждений до того, как карты будут показаны. Все, что помогает услышать других без начальных конфликтов, полезно.

Если все идет хорошо, все готово. В противном случае поговорите с ним о проблеме. Используйте коучинг и задавайте важные вопросы, которые могут помочь ему ясно понять проблему. Попытайтесь найти причину, по которой он взял на себя доминирующую роль. Может быть, ему не хватает доверия к команде (почему?) И, возможно, он чувствует себя ответственным за успех (почему?). Я подозреваю, что эта роль - не то, что он хочет, и вполне возможно, что он хотел бы, чтобы она изменилась. Он может прийти и осознать это.

Мартин Викман
источник
1

Возможно, «доминирующий» разработчик вознаграждается своими индивидуальными результатами, а не командными достижениями?

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

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

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

vtuson
источник
1

Предложите ему стать Мастером Скрама для следующего спринта.

Люди, желающие взять на себя ответственность, - это не проблема (если они не хотят монополии на них), это именно то, чего мы стремимся достичь с помощью самоорганизации.

Кстати, команды с ролью мастера вращающейся схватки не редкость.

guillaume31
источник
0

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

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

Мартин Маат
источник
-1

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

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

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

user25482
источник