Пока команды одна или две, роль почти не важна. Один человек делает всё нужное, и никто не спрашивает, Scrum Master он или Agile Coach. Вопрос всплывает, когда команд становится пять, приоритеты конфликтуют, а Scrum Master тонет в задачах, до которых у него нет рычагов.
Почему роли путают, когда команд становится пять?
Потому что в этот момент команда перерастает формальный Scrum, а ожидания от ролей никто не пересматривал. Роли считают синонимами. Отсюда завышенные ожидания и быстрое разочарование.
Разница видна в трёх вещах: на кого человек влияет, за какой срок отвечает и насколько широко смотрит. По правилам самого Scrum, Scrum Master отвечает за то, чтобы Scrum-команда работала хорошо. Agile Coach смотрит шире: на всю компанию и на то, как в ней принято руководить.
Ни тот, ни другой не начальник команды. Их работа в том, чтобы создать условия, при которых команда работает ровно и предсказуемо. Как только об этом забывают, начинаются типичные ошибки.
Самая частая ловушка: повесить на Agile-роль ожидания, адресованные Product или Project Manager. От роли требуют директивных решений, контроля сроков и личной ответственности за результат. Scrum Master в ответ начинает «руководить» командой. Agile Coach начинает подменять собой менеджмент.
Особенно заметно это в компаниях с сильной иерархией. Там Scrum Master читается как младший менеджер, а Agile Coach как внешний консультант, которого позвали «всё починить». Но ни одна из ролей не работает через прямое управление людьми.
Проверка простая. Если роль оценивают по KPI вида «успели ли в срок» или «сколько фич выкатили», её почти наверняка поняли неверно.
Слабое управление превращает Scrum Master в пожарного
Слабое звено редко бывает личной проблемой. Обычно это симптом: роли размыты, ожидания спорят друг с другом, общих целей нет. С Agile-ролями происходит то же самое.
Всё идёт по цепочке. Приоритеты меняются каждую неделю. Scrum Master тушит пожары вместо того, чтобы помогать команде договариваться. Команда привыкает, что решения приходят через него. В итоге самоорганизация исчезает, а Scrum Master выгорает.
Agile Coach в тех же условиях либо выгорает, либо начинает навязывать практики, не меняя привычек руководства. Это имитация работы. Всё ломается там, где компания путает ежедневную работу команды с долгой перестройкой самой компании.
Scrum Master занят текущей работой и помогает команде получать от Scrum пользу. Agile Coach думает на годы вперёд. Он помогает компании понять, зачем ей Agile вообще и какие изменения для этого придётся пройти.
Ошибаться при этом нормально. Scrum Master может неудачно провести ретроспективу или не сразу заметить тлеющий конфликт. Agile Coach может ошибиться с точкой входа в организацию или с темпом изменений. Это материал для обучения, а не повод для разбора полётов.
Ошибка становится некомпетентностью, когда специалист не видит границ своей роли. Scrum Master, взявший на себя распределение задач и оценку людей, подрывает самоорганизацию. Agile Coach, который ограничился обучением событиям Scrum и не тронул управленческие практики, свою функцию не выполнил.
Второй признак: человек не видит картину целиком. Scrum Master, зациклившийся на соблюдении церемоний в отрыве от ценностей Agile, быстро становится «скрам-полицейским». Agile Coach, который не понимает бизнес, предлагает практики, от которых в реальной работе ничего не меняется.
Разница видна по тому, куда уходит внимание
Должностные описания тут мало что объясняют. Разницу видно по рабочему дню.
Когда команда решает, что делать, Scrum Master следит, чтобы бэклог и гипотезы были видны всем, а цель спринта понятна каждому. Agile Coach в это время вместе с руководством проверяет гипотезы о продукте и о том, как устроена компания.
Когда команда делает и выпускает работу, Scrum Master следит, чтобы задачи не застревали, и убирает помехи внутри команды. Agile Coach смотрит, где команды ждут друг друга, где мешает устройство системы и какие решения руководства тормозят выпуск.
В общении Scrum Master налаживает разговор внутри команды и с теми, кто с ней чаще всего работает. Agile Coach чаще выходит на топ-менеджмент. Он объясняет последствия решений и собирает долгосрочную стратегию изменений.
Зрелость выдают и артефакты. Зрелый Scrum Master относится к инструментам как к средству: меняет форматы ретроспектив, пробует разные доски, и рабочих документов у него немного. Документы Agile Coach адресованы всей компании: карта того, как задача проходит путь от идеи до клиента, схемы связей между командами, метрики скорости этого пути. Этой роли посвящена книга Лиссы Эдкинс «Coaching Agile Teams» (2010): коуч помогает команде и организации увидеть собственную работу, но не делает её за них.
Незрелость в обеих ролях выдаёт одно: слепое копирование практик без оглядки на контекст.
5 часов в неделю: сколько Scrum стоит команде по правилам
Спор о ролях часто упирается в ощущение, что Scrum съедает всё время. Посчитаем по таймбоксам, которые задаёт сам Scrum. Для месячного спринта планирование занимает не больше 8 часов, обзор не больше 4, ретроспектива не больше 3, ежедневная встреча 15 минут.
Для двухнедельного спринта таймбоксы обычно берут пропорционально:
Время на события за спринт = планирование 4 ч + обзор 2 ч + ретроспектива 1,5 ч + 10 дейли × 0,25 ч = 10 ч.
Это 10 часов за две недели, или 5 часов в неделю на человека, примерно одна восьмая рабочего времени. И это верхняя граница.
Теперь сравним с практикой. Илья Казначеев в статье 2024 года на Хабре описывает 10 часов скрам-церемоний в неделю. Вдвое больше расчётного, и такая картина знакома многим командам: если у вас тоже 10 часов вместо 5, таймбоксы никто не держит.
Держать их как раз работа Scrum Master. Поэтому полезная метрика для роли звучит так: доля часов команды на события Scrum. Выше 12% два спринта подряд означает, что Scrum Master занят не тем или ему не хватает полномочий.
Есть и вторая метрика, уже для решения о коуче. Доля рабочего времени Scrum Master на межкомандные блокеры = часы на вопросы вне команды / все рабочие часы. Если она держится выше 30% больше месяца, проблемы лежат на уровне системы, и Scrum Master их не снимет.
Оба порога стоит откалибровать под свою организацию. Их задача в том, чтобы спор о роли шёл на языке цифр.
Четыре сценария, которые обнуляют роль
Быстрее всего роль обнуляют повторяющиеся сценарии:
- Scrum Master подменяется менеджером, а от Agile Coach ждут быстрого результата без единого изменения в управлении.
- Внимание уходит на процесс в ущерб ценности, культуру игнорируют, с сопротивлением никто не работает.
- Церемонии проводят для галочки, практики спускают сверху, прозрачных метрик нет.
- Agile-роли изолируют от бизнеса, и непонимание границ ответственности закрепляется.
Сложите это вместе, и от ролей остаётся вывеска. Тот же диагноз слышен в речи. За фразами «Scrum Master должен заставить команду» или «Agile Coach сейчас внедрит Scrum» стоит ожидание магии вместо работы с системой.
Обратный путь тоже встречается часто. Вот две обобщённые ситуации, без привязки к конкретным компаниям.
В первой компании Scrum применяли формально, а Scrum Master фактически координировал задачи. С приходом Agile Coach началась работа с руководством над целями и метриками. Постепенно Scrum Master вернулся к команде, коуч занялся системой. Конфликтов стало меньше, поставка стала предсказуемее.
Во второй компании Agile Coach появился без внятного запроса, и его работа свелась к тренингам. Ожидания пересмотрели и роли развели: Scrum Master забрал команды, Agile Coach занялся руководством. Все стали одинаково понимать Agile, и сопротивление ослабло.
В обоих случаях сработало одно и то же: ожидания от ролей записали и развели. Сам по себе найм коуча этого бы не дал.
Когда пора звать Agile Coach: проверка из шести вопросов
Ответьте «да» или «нет». Каждый пункт проверяется по фактам последнего месяца.
- Больше 30% рабочего времени Scrum Master уходит на вопросы вне команды?
- Команд три или больше, и между ними есть зависимости по релизам?
- Приоритеты менялись чаще раза в спринт хотя бы в двух спринтах из трёх?
- Улучшения с ретроспектив упираются в решения, которые команда принять не может?
- Руководство само просит изменить подход к управлению?
- Ожидания от Scrum Master записаны и согласованы с руководителем?
Три «да» в первых пяти пунктах означают, что рычагов Scrum Master не хватает и нужна роль уровня системы. «Нет» в шестом пункте важнее остальных. Тогда сначала разводят ответственность, а уже потом нанимают.
Быстрый разбор: усиливать Scrum Master или звать Agile Coach
Короткое правило, чтобы не путать масштаб проблемы с масштабом роли:
- Проблемы команды решаются внутри неё (процессы, взаимодействие, качество ретро)? Это зона Scrum Master, коуч не нужен.
- Проблемы раз за разом упираются в приоритеты, зависимости или решения менеджмента? Рычагов Scrum Master не хватает, нужна роль уровня системы.
- Команда одна и структура простая? Scrum Master закрывает почти всё, отдельный Agile Coach избыточен.
- Команд несколько, локальные улучшения не складываются в общий эффект, а сверху идёт запрос на смену управления? Это три сигнала, что пора вводить Agile Coach.
- Роль есть, но ожидания смешаны? Сначала разведите ответственность, и только потом решайте, кому что добавить.
Семь коротких ответов о границе ролей
В чём ключевая разница между Scrum Master и Agile Coach?
Масштаб. Scrum Master работает с одной командой и её процессом: как она работает, как общается, что улучшает. Agile Coach работает с несколькими командами или со всей компанией: с привычками, культурой и тем, как руководят людьми.
Может ли Scrum Master стать Agile Coach?
Может, хотя это скорее смена масштаба, чем повышение. Придётся выйти за пределы одной команды и разобраться в бизнесе, организационном дизайне и управлении изменениями. Решают зрелость и опыт, строчка в оффере ничего не добавит.
Почему Scrum Master не должен управлять командой?
Управлять значит решать за команду и проверять исполнение. Роль Scrum Master стоит на служащем лидерстве: он помогает команде, а не командует ею, и создаёт условия, чтобы она сама решала, как работать. Как только он становится менеджером, инициатива падает, а всё замыкается на одном человеке.
Чем занят Agile Coach на уровне топ-менеджмента?
Помогает руководству увидеть последствия решений для команд и продукта. Работает с целями, метриками и оргструктурой, где чаще всего сидят главные ограничения трансформации. И переводит между языком бизнеса и языком команд.
Какие компетенции критичны для Scrum Master?
Умение вести обсуждение, понимать людей и хорошо знать Scrum. Он разбирает конфликты, помогает команде договориться и создаёт атмосферу, где не страшно пробовать новое. Плюс способность учиться и подстраивать подход под стадию развития команды.
Что отличает сильного Agile Coach?
Системное мышление и понимание того, как устроены организации. Умение работать с сопротивлением и неопределённостью, навыки коучинга и менторинга. И способность объяснять ценность изменений на языке бизнеса.
С чего начать, если роли путаются?
С письменного разделения ожиданий: что относится к Scrum Master, а что к Agile Coach. Дальше полезна совместная сессия команд и руководства, чтобы собрать общее понимание целей изменений.
Граница проходит по тому, где лежат проблемы команды. Если они раз за разом оказываются вне её зоны влияния, в приоритетах, зависимостях и решениях менеджмента, «усиливать» Scrum Master бесполезно. Системные препятствия снимает роль, работающая на уровне системы. А если такой роли пока нет, честнее сузить ожидания от Scrum Master до команды.