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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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