Я работаю скрам-мастером в команде, в которой есть разработчики и тестировщики. В организации, в которой я работаю, у нас есть цикл проверки каждые шесть месяцев. Директора проводят оценку команды Scrum на основе agile-принципов и результатов команды, а менеджеры оценивают отдельных сотрудников. Но у нас нет формального процесса обратной связи от команды Scrum к менеджерам для каждого члена команды .
Например, что если члену команды нужно изменить свой стиль работы, а этого не происходит даже после многочисленных обсуждений? Причина, по которой я думаю, что формальный процесс необходим, заключается в том, что я чувствую, что люди не думают, что они принадлежат к команде Scrum, поскольку в оценках / обзорах команда Scrum не участвует, и все это все еще находится в руках руководства.
Мне было интересно, имели ли вы дело с чем-то в этом роде. Каково было ваше решение?
РЕДАКТИРОВАТЬ
Еще немного информации: у нас есть смешанные цели: часть целей является командной, на которую директора смотрят в зависимости от результатов работы команды, а часть из них являются индивидуальными целями, которые менеджеры устанавливают на основе своего понимания личности и ожиданий. Между скрам-командой и менеджерами нет обсуждения при постановке индивидуальных целей. Они могут быть о мягких или жестких навыках. Но работа выполняется в скрам-команде, а скрам-команда не знает об индивидуальных целях. Но ониоценивается в конце шести месяцев, тем не менее. Если бы это были только командные голы, я бы не волновался. Но если индивидуальные цели противоречат целям команды, то сотрудники отдают предпочтение индивидуальным целям (или тому, что говорит менеджер), потому что, в конце концов, именно их мнение определяет оценку, по крайней мере, когда речь идет об индивидуальных целях.
Насчет примера, который я привел, был общий пример. Это может быть и хорошо (кто-то уходит с дороги). Проблема, которую я вижу, заключается в том, что нет никакого способа распознать это. Для всего этого нужен процесс. В прошлом я пытался отправить отзыв менеджеру, так как менеджер принимает решение об оценке индивидуальных целей, но это было встречено с пренебрежением, если таковое имело место. Вся эта сложность приводит меня к мысли, что должна быть обратная связь от команды Scrum к руководству. Предложения обратной связи на 360 градусов кажутся мне приемлемыми. Я вообще не хочу повышаться до менеджерано я не знаю, как защитить команду, если обратная связь скрам-команды не является частью процесса оценки. Было бы идеально иметь обратную связь на 360 градусов (сделайте это в соответствии с agile) или это просто как-то заставляет agile работать в смеси традиционного управления с agile? Или было бы идеально иметь только командные цели, или скрам-команда должна обсуждать с менеджерами при определении целей, индивидуальных или иных?
Как вы понимаете скрам -мастера ?
Я спрашиваю, потому что оценка сотрудников не является классической задачей скрам -мастера . Независимо от того, связана ли оценка как-то с agile-процессом или нет.
Но у нас нет формального процесса обратной связи от команды Scrum к менеджерам для каждого члена команды.
Я не уверен, что это будет плодотворный процесс вообще. Такой процесс может вызвать некоторые критические проблемы команды. Несмотря на это, это противоречит некоторым принципам Scrum.
И учтите, руководство в первую очередь интересует результат команды, а не индивидуальные показатели.
Например, что если члену команды нужно изменить свой стиль работы, а этого не происходит даже после многочисленных обсуждений?
С чистой точки зрения Scrum команда должна справиться с проблемой. Это означает, что команда должна найти способ интегрировать товарища по команде, чтобы он/она стал ценным для проекта независимо от его/ее собственного стиля работы. Как я уже писал, скрам -мастер не несет ответственности за оценку работы члена команды .
Как было сказано JDRodger , скрам-мастер отвечает за помощь в решении таких проблем для повышения производительности команды. Это может быть немного не по теме, но давайте посмотрим, что вы можете сделать.
[...] что, если члену команды нужно изменить свой стиль работы, а этого не происходит даже после многочисленных обсуждений?
Слово «обсуждения» (в том виде, в каком вы его использовали) имеет для меня негативный оттенок. Следовательно, ситуация, которую вы описали, уже предполагает наличие конфликта, и я предполагаю, что вы, скорее всего, находитесь в его середине.
К сожалению, вы не описываете важные детали, например, кто участвует, как вы узнали о проблеме, какова, по вашему мнению, причина проблемы и т. д. (пожалуйста, добавьте больше деталей).
В любом случае, как правило, старайтесь предотвращать такие ситуации, не вмешивайтесь, не принимайте чью-либо сторону, старайтесь всегда быть максимально нейтральным. Я знаю, что это нелегко, но это лучшая позиция, которую вы можете иметь (помочь разрешить такие конфликты).
Конечно, вы не всегда можете избежать конфликтных ситуаций, как ScrumMaster . У вас есть определенные обязанности, которые могут привести к конфронтации.
Например, давайте предположим, что член команды не приходит на регулярный ежедневный скрам. В конце концов вы видите необходимым, чтобы вся команда разработчиков присоединилась к Daily (по крайней мере, если это возможно).
Худшее, что вы можете сделать, это напрямую противостоять товарищу по команде и начать дискуссию типа «Почему ты не присутствуешь на ежедневках?», «Ты должен участвовать, как и все остальные!»
Немного лучше, но тоже не идеально «Было бы хорошо для проекта и для ваших товарищей по команде, если бы вы могли присоединиться к ежедневным газетам. Вы важная часть этого».
Так что никогда не пытайтесь противостоять кому-то, будучи властным или воспитателем, и относитесь к нему как к ребенку. Лучшее, что вы можете сделать в такой ситуации, сделать глубокий вдох и отступить. Посмотрите, как развивается ситуация, посмотрите, действительно ли это проблема для команды и успеха проекта.
Если это имеет тенденцию быть проблемой, вы должны действовать. Поднимите проблему во время Ретроспективы Спринта (если никто из членов команды не решит эту проблему); и опять же, будьте нейтральны, не принимайте чью-либо сторону и слушайте.
В лучшем случае члены команды находят решение. Если нет, попробуйте подтолкнуть их в правильном направлении; помните, не будьте властными, никакого воспитания. Сделайте нейтральное заявление: «Может быть, вам следует обсудить это в следующий раз?».
Так что решать конфликты непросто. И правильный способ их разрешения зависит от конкретного конфликта. Окончательное соотношение состоит в том, чтобы обострить его и обратиться непосредственно к руководству (или косвенно, в процессе обратной связи). Но такие действия не обязательно идут на пользу вам или команде.
Воспоминание,
Люди и взаимодействия важнее процессов и инструментов (1) .
Я видел, как работают следующие вещи:
Есть ли у Spotify менеджеры? «У Spotify есть менеджеры, просто это другая точка зрения».
Это еще одно распространенное заблуждение. У нас есть менеджеры, это просто другой взгляд. Вместо менеджеров команд у нас есть линейные менеджеры, которых мы называем руководителями отделений. Они присматривают за всеми теми людьми с одинаковым набором навыков в отрядах. Например, я мог бы быть руководителем отдела для всех разработчиков Android. Круто то, что руководители глав — это разработчики, работающие неполный рабочий день, обычно они сами сидят в одном из отрядов.
Я бы сделал оба. Обращайтесь с людьми как с людьми, а не как с ресурсами. Тренируйте их, но если команда считает, что они не работают, и они сопротивляются изменениям, выгоняйте их из команды. Пусть руководство разбирается, что с ними делать. Командная работа настолько важна в Agile, что эффективнее работать с меньшим количеством людей, чем с тем, кто сопротивляется изменениям. Найдите для них занятие, где они смогут побыть в одиночестве :)
На это уже был дан ответ и предложено, но я считаю, что обратная связь 360 — правильное решение, учитывая, что команда достаточно зрелая.
Дайте каждому члену команды scrum анонимный опрос, чтобы оценить других членов команды. Задайте им 5 главных вопросов, которые, по вашему мнению, являются ОСНОВНЫМИ ценностями вашей компании и вашими ожиданиями от этого человека. Старайтесь, чтобы вопросы были объективными, и пусть люди оценивают по шкале от 1 до 10. Задайте последний вопрос как «поделитесь отзывом о человеке X, который у вас есть», и пусть люди напишут в этом вопросе, что они хотят. (направить их к конструктивной критике)
Проблема №1. «Члену команды нужно изменить свой стиль работы, а этого не происходит даже после многочисленных обсуждений?» - Трудно убедить людей без данных. Если вы будете обсуждать с ним/ней такие данные, как «4 из 5 членов команды оценивают ваш вклад в успех команды как 4/10, в то время как средний балл по команде по этому вопросу составляет 8/10». Это заставило бы других людей поверить в то, что если все так думают, то ему/ей лучше усердно работать.
Проблема №2. «Люди не думают, что они принадлежат к Scrum-команде, поскольку в оценках\обзорах Scrum-команда не участвует и все остается в руках руководства». Используйте эти данные и в оценках, не полностью, но можно Х% для начала. Теперь люди будут верить, что оценки/обзоры более научны, а не основаны только на одном мнении, которое может быть предвзятым.
Резиновая утка