Я надеюсь на некоторую помощь в борьбе со скрам-мастером, который прямо идет против воли команды разработчиков.
У рассматриваемого скрам-мастера есть подход, который ставит завершение спринтерских историй превыше всего остального.
Как правило, разработчик (человек А) может столкнуться с препятствием и попросить помощи у члена (человека Б) другой, более опытной команды. Следует отметить, что последняя команда является удаленной командой, работающей в часовом поясе с отставанием на 5 часов, поэтому возможны задержки, а иногда решение проблем может занять день или два, несмотря ни на что.
Что начало происходить, так это то, что даже если разработчик заявляет, что он контролирует ситуацию, мастер схватки отправляет электронное письмо Б, а иногда и менеджеру Б, заявляя, что А заблокирован и нуждается в немедленной помощи.
Команда разработчиков подняла этот вопрос на ретроспективе последнего спринта, и скрам-мастер неохотно согласился остановиться, если разработчик не попросит о помощи напрямую.
Разработчики опасались, что скрам-мастер вбивает клин между двумя командами и что его электронные письма приведут к вражде между командами, поскольку это можно интерпретировать как санкционирование электронного письма разработчиком.
Несмотря на согласие остановиться, скрам-мастер продолжает рассылать эти электронные письма.
Как можно было бы справиться с этим на профессиональном уровне, чтобы остановить это навсегда?
Одна из целей Скрам-мастера — устранить препятствия, существующие между командами. Ваш скрам-мастер, вероятно, рассматривает этот «блокировщик» как препятствие, а затем делает все возможное, чтобы устранить его, заявляя о необходимости «немедленной помощи».
Понимание того, что скрам-мастер делает это как часть своей роли, является ключом к решению проблемы. Так что не делайте это частью их роли.
Вместо этого запланируйте дружеские беседы в системе календаря. Тогда ничего не заблокировано, только запланированные элементы. Обязательно сообщите скрам-мастеру, что прогресс идет, и что необходимые межкомандные ресурсы доступны, запланированы на (любое время) и достаточно рано, чтобы уложиться в сроки.
Если вы устраните препятствие, вам не на что будет воздействовать. Если проблема решена до того, как ваш скрам-мастер попытается ее решить, вы можете управлять отношениями между командами и прибегать к помощи своего скрам-мастера, когда самоуправление невозможно.
Поднимите его снова на скрам-собрании. Укажите на его неудачи и на то, что он отравляет атмосферу команды. Ударь его - сильно. Скрам-мастер не должен этого делать. Завершение истории Sprint не является самоцелью. Если истории задерживаются, важен анализ. Его beahvrios, вероятно, приведет к большому количеству плохого поведения, вплоть до сообщения о ложных завершениях.
Скорее всего, скрам-мастер думает, что помогает. Мне интересно, что будет дальше в ваших ситуациях. Что отвечает человек Б? Что отвечает менеджер лица Б. Почему скрам-мастер считает, что ему необходимо предпринять это действие? Есть ли SLA для ответа человека B или он указывает время регистрации, когда он ожидает получить больше информации для вас?
По моему опыту, скрам-мастера действуют таким образом в одном из трех случаев:
Выяснение того, является ли это одним из этих трех, может повлиять на ваши следующие шаги. Если это третье, это может быть проблемой в другом месте — Scrum Master не несет личной ответственности за выполнение работы, как PM. Если это первое или третье, вы можете попытаться провести безопасный эксперимент, чтобы выяснить, правы ли они (или показать им, что их действия не приносят пользы).
Вы уже сказали скрам-мастеру, что его поведение, по вашему мнению, неадекватно, они даже договорились и сказали, что прекратят, и до сих пор это продолжается.
Очевидно, скажите своему скрам-мастеру еще раз, на этот раз очень решительно, и если вы обнаружите, что это произойдет снова, напишите письмо менеджеру Б и Б, что запрос не был срочным, что ваш скрам-мастер отправил это самостоятельно, и что Б ответил на ваш запрос. был в полном порядке.
Нео
DarkCygnus
бхарал