Вот какие антипаттерны могут появляться, когда Scrum Мастер понимает то, что он делает, как обязанности менеджера, а не как служащего лидера:
1.Он решает, кто на встрече будет говорить следующим.
Если участники команды прежде чем заговорить ищут глазами Scrum Мастера, это верный знак: вместо фасилитации он вернулся к роли супервайзера.
2.Скрам мастер навязывает команде Burn Down чарты.
При таком антипаттерне Scrum Мастер существенное время вкладывает в обновление этих графиков. Если команде нужны Burn Down чарты, в этом нет ничего дурного, хотя их в принципе можно заменить регулярно обновляемой доской спринта.
Если же Burn Down чарты нужны только для того, чтобы отчитываться, команде стоит пересмотреть эту практику.
3.Менеджмента нет в принципе.
Например, к чему Команде разработки заниматься учетом зарплат? Вряд ли это добавит ценности для заказчика. Самоорганизацию не стоит понимать как полное освобождение менеджера от работы. Скорее это отсутствие микроменеджмента.
4.Scrum Мастер контролирует команду через показатели личной эффективности.
Такими показателями могут быть стори–пойнты каждого разработчика за спринт. Это классический способ протащить в аджайл принципы вертикального управления с черного хода.
5.Scrum Мастер подгоняет команду, чтобы вписаться в дедлайн.
Например, Scrum Мастер может докладывать вышестоящим коллегам о том, что команда не вписывается в план спринта или в собственные прогнозы. Попадаются даже такие требования в вакансиях: четко придерживаться графика и заставлять команду в него уложиться. От них недалеко и до публичных наказаний "недорабатывающих" сотрудников.
6.Слишком заботится о гармонии в команде.
Бывает так, что под названием Scrum master понимают обязанность красиво заминать все конфликты и противоречия вместо того, чтобы открыто разбираться с ними на ретроспективе. Такое поведение выдает манипуляции и желание вписаться в ценности организации, которые противоречат принципам Скрама.
7.Члены команды без возражений принимают огромный бэклог спринта.
Команда регулярно берется за большее количество задач, чем ей удалось бы без уловок Scrum Мастера. В конце спринта 50% задач остаются невыполненными, и их перебрасывают в следующий спринт.
Если такое вошло в привычку, то команда практикует не Скрам… а, например, Канбан с таймбоксами. Что тоже неплохо, только вам нужно определиться и придерживаться одной линии.
8.В Бэклог берут неупорядоченные истории.
Оценивать выполнимость историй, которые поступают в бэклог — одна из обязанностей Scrum Мастера, и ее нарушение приводит к общей неспособности выполнить цель спринта. Так нарушается один из принципов Скрама — поставлять готовый инкремент в конце каждого спринта. Внеурочные ситуации, конечно, исключение.
9.100%-ная занятость.
Владелец Продукта вводит в бэклог максимум функциональной работы, а Scrum Мастер не отстаивает тот факт, что часть времени нужна на расслабление. Эффективность команды сильно снизится, если каждый спринт не оценивать ее технический долг. Когда команда занята под завязку, она всегда хуже работает в долгосрочной перспективе.
10.Нарушение рабочего потока.
Это вмешательство стейкхолдеров, которое хороший специалист должен предотвращать. Примеры:
Scrum Мастер попустительствует стейкхолдерам в вопросах доступа к команде.
Он не противостоит линейным менеджерам, которые приходят к команде с посторонними задачами.
Он не возражает, когда менеджеры приглашают разработчиков на ненужные им встречи как технических экспертов.
Бэклог может измениться в середине спринта, и возражений не будет.
Их не будет и в том случае, когда стейкхолдеры превращают ежедневный скрам в отчетную сессию.
11.Разработчики получают дополнительные задания.
Scrum Мастер позволяет Владельцу Продукта или кому бы то ни было другому из внешних сотрудников ставить команде задачи, в то время как он должен защищать ее как самоорганизованную единицу.
12.Scrum Мастер определяет технические решения.
Такое бывает, когда Scrum Мастером становится бывший разработчик, и команда обращается к нему за подсказками.
13.Недостаточно поддержки.
Роль Scrum Мастера предусматривает поддержку людей, которые не справляются с задачами. Например, задача создана на день, а разработчик выполняет ее два дня. В здоровой Скрам–практике такие задачи на доске отмечают красными точками, а разработчику нужно помочь справиться с трудностями. К сожалению, иногда это правило игнорируют.
14.День сурка.
Ретроспективы не меняются ни по структуре, ни по месту, ни по продолжительности: все шансы решать одну и ту же проблему ретроспектива за ретроспективой — без шансов на хеппи–энд.
15.«Я подумаю об этом завтра».
Ретроспектива откладывается до следующего спринта. Но дело в том, что ретроспектива нужна не только для инспекции и адаптации. Это также момент мысленной перезагрузки команды перед новым спринтом. Не проводить ретроспективу вовремя — значит нарушать темп команды и откладывать улучшения на потом.
16.#NoRetro.
Во время спринта Scrum Мастер не собирает данные, которые бы пригодились команде на ретроспективе. Это может быть признаком его профессионального выгорания.
Ретроспектива не документируется.
Заметки и видео с ретроспектив — не формальность, а способ поддержать должное серьезное отношение к этой встрече в команде.
17.Вопросы психологической безопасности.
Ретроспектива превращается в бесконечный поиск виноватых, а Scrum Мастер ничего с этим не делает, проигрывает вся команда.
18.Травля в команде.
Ретроспектива должна быть безопасным способом обратной связи для всех участников команды, в том числе неразговорчивых или, например, не самых популярных в коллективе людей. Если на ней кто–то кому–то будет угрожать, а Scrum Мастер не вмешается, она перестанет быть безопасным местом для высказываний, и люди будут ее избегать. Например: время на высказывание в эффективных командах Google распределяется поровну между участниками. Больше материала по этой теме есть в статье " What Google Learned From Its Quest to Build the Perfect Team".
19.Участие стейкхолдеров.
Они могут приходить на обзор спринта, уточнение бэклога, Ежедневный Скрам, не говоря уже о разговорах в перерывах от работы. Если и этого не хватает, всегда можно назначить еще встречи. Но на ретроспективу стейкхолдеры приходить не должны — хороший Scrum Мастер непременно позаботится об этом.