Плохие привычки вашего Scrum Master

Ответ 1

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

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

Для меня и нашей команды работа мастера Scrum Master должна быть щитом и помощником команды, блокируя препятствия и делая все возможное, чтобы помочь ускорить все. Ken Schwaber Agile Software Development с Scrum - отличное введение в Scrum, это то, что наша команда использовала, и мы с ней успешно справились. Там также Agile Project Management с Scrum, что больше подходит для ролей Scrum Master и Product Owner.

Ответ 2

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

Ответ 3

• микроуровне
• Управлять старым командованием и управлением вместо того, чтобы облегчить самостоятельную команду
• Фокусировка на числах/выгораниях/отставании, чем на люди, которые составляют команду
• Не защищать команду от внешних помех

Ответ 4

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

Ответ 5

• Микропрограммирование команды с повышенной активностью
• Преодоление старших разработчиков технических решений, потому что "Scrum говорит" и "команда должна голосовать". Полностью лишенные полномочий высокопоставленные технические люди.
• Попытка сжать кровь с камня на ретроспективе по вопросам, которые на самом деле не являются проблемами.
• Рассказывая мне, что пункты не имеют значения, но при каждом просмотре очки выводятся, анализируются каждые 2 недели при просмотре. Кроме того, основывая наш годовой бонус на производительности наших очков.

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

Ответ 6

Постоянная замена новых ошибок в и из Sprint.

Ответ 7

Существует два типа мастеров схватки:

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

Второй момент проповедуется и практикуется в "действительно" Agile-организациях. Это дорого, но имеет некоторые достоинства.

Кроме того,

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

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

Ответ 8

Не помогает с отталкивающей частью процесса, например. "это все магазины, которые хочет клиент на этой итерации, так что мы должны делать".

Ответ 9

Постоянно пытается связать фактические часы, отработанные до оценок сюжетной точки.

Ответ 10

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

Ответ 11

• Невозможно выполнить задачи по слоту в цикле (слишком много обычно)
• Не очень хорошо справляется с внешними клиентами (если определенная задача слишком велика для одного цикла, ныхая команде, а не отталкиваясь от клиента)
• Делать ежедневные схватки слишком большими для процесса - не придерживаться определенного срока (мы предпочитаем максимум 15 минут).

Ответ 12

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

По моему мнению, наши лучшие мастера Scrum были разработчиками с большим чувством ответственности или без PM.

И снова я работал (до того, как мир знал о Scrum) для PM, которые серьезно качались. Я уверен, что сегодня они сделают великих мастеров Scrum.