Компании видят возможность для первенства в изменении старых процессов. Особенно это касается разработки, где внедряются Agile-подходы. Scrum является наиболее популярным фреймворком среди организаций. Его концепция проста, но сложна в реализации.
Быть хорошим scrum-мастером — сложная задача. В этой статье мы собрали распространенные ошибки этой роли и неудачные решения при внедрении Scrum.
Scrum-мастер равно менеджер проекта
В Agile методологии команды используют дейли для синхронизации. Перед началом рабочего дня (или в другой момент) команды собираются у доски, чтобы обсудить задачи текущего и предыдущих дней. В плохом сценарии scrum-мастер проверяет статус и назначает на исполнителя новую задачу. Это не даёт команде самоорганизоваться. Scrum-мастер действует как менеджер. По Scrum, он должен вернуть вопрос в команду, чтобы они сами спросили: «Что должно быть дальше?»
Scrum-мастер принимает решения за команду
Есть случаи, когда команда полагается на scrum-мастера в принятии каждого решения, что абсолютно неправильно и противоречит самоорганизации. Коллеги доверяют практическому опыту scrum-мастера, и вместо генерации своих идей и решений ждут ответа от этой роли.
Scrum-мастер пытается показать свою значимость и вместо коучинга, консультаций и советов берёт на себя решения. Это путь не туда.
Избегайте диктатуры, так как она влияет на командный дух, душит прогресс и возможности для дискуссии, общения, а в итоге для самоорганизации. Scrum-мастер должен построить команду так, чтобы она функционировала без него.
Scrum-мастер работает на DONE, а не на качество
Есть распространённая проблема в применениях Scrum, когда от команд требуют больше выполненных задач в ущерб качеству.
Scrum-мастеру дают метрику задач в продакшне для измерения эффективности его работы. Вместо исправления процессов, мотивирования команд он концентрируется на доставке продукта.
Чтобы избежать этого, прекратите планировать задачи индивидуально. Планирование осуществляется всеми членами команды коллективно. Необходимо, чтобы каждый член команды придерживался обязательств, понимал цель и способы её достижения.
Scrum-мастер — прокси между командой и владельцем продукта
Допустим, команда сталкивается со сложностями во время разработки, и нужно получить новую информацию от владельца продукта. Тут scrum-мастер связывается с PO, передаёт информацию команде.
Зачем в этом процессе нужен scrum-мастер? Чтобы ощутить собственную значимость, снять негатив или зачем-то ещё? Нужно решить корневую проблему и перестать работать передатчиком.
Scrum-мастер позволяет нарушает правила
Есть множество аргументов у незрелых команд и организаций, почему не нужно ревью, дейли или ретроспектива. Scrum-мастер не должен нарушать фреймворк и позволят это делать своей команде. Работайте над качеством событий, фасилитацией и другими препятствиями, но не отменяйте scrum-церемонии.
То же касается всех обязательных в Scrum артефактов. Без статистики, которую ведёт команда каждый спринт, путь к совершенствованию будет затруднён.
Scrum-мастер не работает с владельцем продукта
В силу разных причин работа scrum-мастера и владельца продукта может быть осложнена. Это воспринимается как данность. В итоге, бэклог не подготовлен, задачи собраны по случайным признакам, а приоритеты меняются изо дня в день.
Помочь владельцу подготовить бэклог — это ответственность scrum-мастера. Установите цели для владельца продукта и работайте с ним, несмотря на то, что это будет занимать много времени.
Для компаний важно правильно применять Agile для создания продуктов и быстрого получения ценности. Если вы scrum-мастер, не избегайте решения вышеупомянутых проблем со Scrum, чтобы не упустить возможность построить действительно великолепную команду.
Какой ваш топ самых частых ошибок?