Зачем команде Scrum Master, если митинги может провести любой

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

Встречи занимают восьмую часть недели, остальное решает организация

По официальному описанию роли Scrum Master отвечает за эффективность всей Scrum-команды. Встречи для него только инструмент, и времени они занимают меньше, чем принято думать.

Гайд ограничивает события сверху: планирование до 8 часов на месячный спринт, обзор до 4, ретроспектива до 3, daily по 15 минут. Для коротких спринтов события обычно короче. Если поделить лимиты пропорционально для двухнедельного спринта, выйдет около 4 часов планирования, 2 часов обзора, полутора часов ретроспективы и двух с половиной часов daily.

Всего около 10 часов за спринт. Это примерно 5 часов в неделю, восьмая часть рабочего времени. И это верхняя граница.

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

Scrum Guide описывает, кому служит Scrum Master, по трём направлениям. Команде он помогает самой организовывать работу, держать фокус на готовом результате спринта (Increment) и убирает препятствия. Владельцу продукта (Product Owner) он помогает ясно сформулировать цель продукта (Product Goal) и вести бэклог. Организации помогает внедрять Scrum и убирает барьеры между командой и заказчиками. Если в описании вакансии из трёх направлений осталось «проводить встречи», роль обесценили ещё до найма.

Роль называют бесполезной по чужому критерию

Самая частая ошибка: оценивать Scrum Master мерками продакт-менеджера (PM). Команда работает медленно, цели не достигаются, конфликты копятся. Виноватого ищут среди людей, и под руку попадает тот, кто «отвечает за процесс». Его упрекают, что он «плохо управляет командой» или «не контролирует сроки».

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

Когда Scrum Master всё-таки подменяет менеджера, это почти всегда симптом. Роли не разведены, ожидания противоречат друг другу, и он становится «затычкой» для организационных дыр. Решает вопросы приоритетов, договаривается о сроках, гасит конфликты между бизнесом и командой.

Формально это не его зона. Но система толкает его туда, и энергия уходит на тушение пожаров. Слабость здесь у организации. Роль лишь показывает, где та ещё незрелая.

Выбраться из этой позиции помогает простая инвентаризация. Scrum Master выписывает всё, чем занимался за две недели, и помечает, чья это зона по Scrum Guide: его, Product Owner, менеджера или команды. Список с пометками идёт к руководителю. Нередко чужой оказывается заметная часть строк, и разговор о ролях становится разговором о конкретных задачах.

Ошибка Scrum Master учит, если меняет следующий спринт

Бывает, что ошибается сам Scrum Master. Он работает с живыми людьми, и эксперименты с форматом встреч или разбором конфликтов не всегда срабатывают. Это нормально.

Ошибка полезна, если из неё сделан вывод. Новый формат ретроспективы команда приняла в штыки, Scrum Master разобрал почему, поправил подход и попробовал снова. Проблема начинается, когда одна и та же ошибка повторяется механически. Тогда он перестаёт менять систему и превращается в администратора ритуалов.

Некомпетентность выдают два признака. Первый: фокус на правилах Scrum в отрыве от контекста команды. Правила соблюдены, смысл потерян.

Второй: стремление контролировать. Когда Scrum Master следит за загрузкой, давит на скорость и раздаёт указания, он разрушает самоуправление. Роль превращается в микроменеджмент. Часто это происходит под давлением среды, которая ждёт быстрых результатов и «порядка», и человек начинает работать против принципов роли, чтобы соответствовать ожиданиям.

Лисса Адкинс в книге «Coaching Agile Teams» (2010) описывает этот сдвиг как переход от позиции эксперта, который знает ответ, к позиции коуча, который помогает команде его найти. Для бывших руководителей и сильных разработчиков он даётся тяжелее всего.

Результат роли виден по тому, чего стало меньше

Работа Scrum Master редко заметна напрямую. Её видно по поведению команды.

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

Когда команда выпускает результат (delivery), это видно по реакции на сбой. Если после инцидента ищут виноватого, система не учится. Если разбирают причины и меняют процесс, учится.

В коммуникации роль видна по прямоте разговоров. Когда роль работает, команда говорит о сложных вещах вслух, а конфликты разбирают в безопасном формате. Когда не работает, обсуждения сводятся к отчётам и оправданиям.

Зрелость выдают и ретроспективы. Ретро, которое превратилось в список жалоб без выводов, и daily, ставший отчётом для менеджера, говорят об одном: Scrum Master модерирует, но ничего не меняет. Показательно и отношение к экспериментам. Если любое изменение встречает сопротивление или тихий саботаж, культура обучения ещё не сложилась.

Раз роль почти невидима, оценивать её по активности бессмысленно. Число проведённых церемоний о результате почти ничего не говорит. Смотреть приходится на косвенные следы:

• сколько дней проходит от появления препятствия (блокера) до его снятия;
• какая доля задач возвращается на доработку;
• сколько тем всплывает на ретроспективе третий спринт подряд;
• как быстро команда восстанавливается после сбоя;
• сколько решений замыкается на одном человеке.

Ни одну из этих цифр нельзя приписать Scrum Master целиком. Он не пишет код и не закрывает задачи, он меняет условия, в которых это делает команда. Зрелая работа поэтому выглядит как тишина: меньше эскалаций, меньше авралов, меньше поводов вмешиваться вручную.

Если нужна одна метрика, берите время от появления блокера до его снятия и смотрите его вместе с долей тем, которые повторяются на ретроспективах три спринта подряд. Блокеры снимаются быстрее, а старые темы уходят? Значит, роль работает.

Допустим, в начале квартала блокер в среднем висел четыре рабочих дня, а к концу полтора. На команду из семи человек, у которой за спринт случается шесть блокеров, это пятнадцать сэкономленных дней ожидания каждые две недели. Никакой отчёт о проведённых встречах такой цифры не покажет.

Ретро без последствий и буфер между бизнесом и командой

Обе команды ниже придуманы, но узнать их несложно.

В первой команде Scrum формально был, но церемонии воспринимали как обязаловку. Daily пролетали за пять минут, ретроспективы раздражали, сложные темы переводили в шутку. Проблемы копились.

Scrum Master убрал шаблоны ретроспектив и начал разбирать реальные случаи из спринта. Норм Керт ещё в книге «Project Retrospectives» (2001) описывал ретроспективу как способ команды учиться на собственном опыте, и Scrum Master вернул встрече эту функцию: каждая стала заканчиваться одним изменением с владельцем.

Встречи стали длиннее и глубже. Команда сопротивлялась: «слишком много разговоров». Он выдержал паузу и продолжил. Через несколько спринтов участники сами начали поднимать сложные вопросы. Конфликты перестали копиться, срывов стало меньше, и роль перестали считать обслуживающей.

Во второй команде жили под постоянным давлением сроков. Бизнес менял приоритеты, команда перерабатывала, а от Scrum Master ждали, что он «договорится с менеджментом».

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

Потом подход пересобрали. Опорой стала цель спринта. По правилам Scrum команда обязуется достичь именно её, а состав задач можно обсуждать с Product Owner по ходу спринта. Поэтому срочный запрос от бизнеса стали проверять одним вопросом: ломает ли он цель спринта. Если не ломает, задачу меняют на другую такого же объёма. Если ломает, решение принимает Product Owner, открыто и с последствиями.

Scrum Master перестал быть буфером. Он начал фиксировать перегрузку на планировании и разбирать причины авралов на ретроспективах, при всех и с цифрами. Сопротивлялись и бизнес, и команда. Он держался фактов. Через несколько месяцев приоритеты стабилизировались, команда научилась отказываться от нереалистичных обязательств, а Scrum Master перестал работать пожарным.

Почему у противников Scrum есть резон

Скептиков легко записать в ворчуны, но у них есть материал. Илья Казначеев в июне 2024 года опубликовал на Хабре резкий текст, где сравнивает Scrum с раковой опухолью индустрии и пишет о десяти часах скрам-церемоний в неделю. Статистикой это не назовёшь, это наблюдение одного автора, но цифра узнаваемая.

Сравните её с расчётом выше. Десять часов в неделю вдвое больше верхней границы, которую задаёт сам Scrum Guide для двухнедельного спринта. Значит, проблема в раздутых встречах. А раздувает их чаще всего роль, сведённая к администрированию расписания.

Насчёт зрелой команды, которая уже сама замечает свои проблемы, скептики правы. Ей постоянный фасилитатор не нужен, и Scrum Master, сделавший себя ненужным в повседневности, со своей задачей справился. Такой команде хватит редких, но точных вмешательств.

Ошибаются они там, где роль урезают ради экономии. Один человек на пять команд формально проведёт все церемонии. Но на работу с доверием, динамикой и причинами сбоев у него не останется ни времени, ни контекста. Роль снова схлопнется до расписаний, и скептики получат ещё один пример в свою пользу.

Шесть вопросов, по которым Scrum Master проверяет себя

Вопросы выросли из обоих случаев. На каждый можно ответить «да» или «нет»:

1. Работаю ли я с причинами, или только с симптомами и отдельными людьми?
2. Поднимает ли команда сложные темы сама, без моего вопроса?
3. Привела ли последняя ретроспектива хотя бы к одному изменению, которое видно в следующем спринте?
4. Не подменяю ли я ответственность команды собой: не договариваюсь ли о сроках за неё, не распределяю ли задачи?
5. Укладываются ли встречи в лимиты времени из Scrum Guide?
6. Стало ли за квартал меньше решений, которые замыкаются на мне?

Два «нет» подряд в первых трёх вопросах обычно означают, что роль ушла в администрирование.

Отдельно стоит развести Scrum Master и смежные роли. От Agile Coach он отличается масштабом. Scrum Master работает с конкретной командой и её повседневной практикой. Коуч работает на уровне нескольких команд или всей организации, с трансформацией и масштабированием. В зрелых компаниях они дополняют друг друга.

Совмещать роль с PM пытаются часто, но это конфликт интересов. Один и тот же человек защищает продуктовые приоритеты и помогает команде говорить об ограничениях. В спорной ситуации эти задачи тянут в разные стороны. Если совмещения не избежать, порядок разрешения такого конфликта нужно согласовать заранее.

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

Scrum Master и смежные роли: за что отвечает каждый

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

Спотыкаются обычно именно здесь. Команде, где Scrum Master тонет в переносах задач и переговорах о сроках, ищут человека посильнее. Но дело в неразведённых ролях PM и менеджера, и любой новый человек на этом месте снова станет «затычкой». Если неделя Scrum Master уходит на расписание встреч, менять надо роли вокруг него, а не его самого.