Scrum-мастер — сложная роль, которая часто остаётся до конца не понятой. Из-за этого начинающие scrum-мастера легко попадают в «ловушки», которые замедляют карьерный рост, мешают команде и развитию Scrum. В этой статье мы разберём распространённые ошибки и то, как их избежать.
Ежедневный стендап
В некоторых командах кажется, что ежедневный стендап нужен только scrum-мастеру для галочки в графу: да, мы соответствуем Scrum. Ошибка в том, что команда не до конца понимает важность утренней синхронизации, а scrum-мастер практически насильно собирает всех и задаёт три стандартных вопроса.
Самоорганизующаяся команда должна сама отвечать на вопросы и уметь отследить свой прогресс. Scrum-мастер ведёт команду в этом направлении. Чтобы улучшить этот момент, проанализируйте:
- состоится ли стендап, если scrum-мастер заболеет?
- все участники приходят без телефонов/ноутбуков?
- если спросить предыдущего участника, что только что сказал следующий, он ответит?
Секретарь
На scrum-событиях мастер делаете всё, где нужна ручка или клавиатура? Только он печатает и заполняет карточки?
Любой в команде, кто умеет писать (то есть каждый), в состоянии заполнить пользовательскую историю и передвигать карточки в цифровых программах. Так как цель Scrum — создать самоорганизующуюся команду, не стоит всё делать за разработчиков. Scrum-мастер помогает с организацией процесса, но при этом не превращается в стенографиста на событиях.
Данные без анализа
Допустим, вы хороший scrum-мастер: ведёте все артефакты, собираете статистику. Ошибка появляется тогда, когда это делается в стол. Если данные с диаграммы сгорания, динамика Velocity и прочие вещи не используются в планировании и на ретроспективах, зачем вообще это делать?
Scrum-мастер должен обратить внимание команды на собранные данные, проанализировать их вместе и подобрать методики для улучшения. Scrum-мастер может не быть техническим специалистом, но он может подобрать варианты на выбор команде. Например, предложить парное программирование, разные подходы к тестированию, такие вещи, как BDD и прочее.
Мастер-нянечка
Если вы чувствуете, что ваши просьбы команде похожи на заботу в детском саду, это плохой сигнал. Вы просите передвинуть карточку, собраться на планирование, выбрать пользовательские истории... Но это ответственность команды, потому что относится к разработке. Игнорирование подобных вещей командой значит отсутствие прозрачности.
Что делать в таком случае? На собрании определите границы, а некоторые вещи воспринимайте как должностные обязанности. Есть разница между напомнить и упрашивать — уговоров быть не должно. Кроме этого расскажите о последствиях того, что значит работать без прозрачного процесса: отчеты руководителю проекта, трекеры времени и другие вещи, которые добавляют стресса.
Авторитарный стиль
Эта ошибка чаще появляется у бывалых scrum-мастеров, которые имеют большой практический опыт или совмещают роль с ролью разработчика (обычно, лида). Она состоит в том, что scrum-мастер не предлагает, а указывает, что делать. Команда или не знает, что можно возразить, или не хочет. И самое главное, команда не понимает, что выбор изначально должны делать именно разработчики.
Авторитарный стиль вместо демократии влияет на культуру в команде и препятствует прогрессу. Во всех решениях, которые принимаются командой, должны участвовать все. Для сбора мнений есть много методов в виде игр, опросов и других сценариев.
С этими пятью ошибками трудно соответствовать ценностям Scrum, поэтому с ними нужно бороться. Конечно, это не все частые ошибки, и в следующей статье мы опишем ещё пять распространённых ловушек.