Внутри Scrum у Scrum Master понятная зона: эффективность одной Scrum-команды. Agile Coach в самом фреймворке не упоминается вовсе. Зато эта должность есть в вакансиях, и там обязанности двух ролей перемешаны так, что их постоянно путают.
Цена путаницы конкретна. От обеих ролей ждут несовместимого: починить сроки, культуру и конфликты сразу. В итоге буксуют обе.
Разница проходит по масштабу. Scrum Master работает с одной командой и её повседневной практикой, а Agile Coach с системой команд и организационным контуром. Ниже о том, где эта граница стирается и как её вернуть.
Роли сливаются в тот момент, когда горят сроки
Путаница почти всегда начинается с кризиса. В продукте что-то не работает, и организация ищет того, кто «должен был это предотвратить».
Тогда обе роли начинают считать продолжением менеджмента. От них ждут, что они починят сроки поставки и ускорят команды. Оценивают их по метрикам, за которые они не отвечают.
Дальше начинается прямая подмена. Scrum Master решает вопросы приоритетов, хотя это работа владельца продукта. Agile Coach лезет в повседневную работу одной команды, потому что от него ждут быстрых изменений. Владелец продукта при этом теряет фокус.
Система при этом не развивается. Вместо разделения уровней возникает хаотичное вмешательство. Роли теряют силу, проблемы становятся хроническими.
Сбои повторяются от компании к компании. Роли оценивают по метрикам поставки, используют как «затычки» для организационных дыр, ждут быстрых результатов там, где изменения по определению небыстрые. Это слышно и по языку. «Пусть Agile Coach поработает с этой командой» обычно означает, что Scrum Master нет или ему не доверяют. «Scrum Master должен масштабировать agile на всю компанию» означает перекладывание ответственности.
Что случится, если спросить с коуча velocity?
Метрика сломается первой. Как только Scrum Master или Agile Coach начинают отвечать за показатели поставки, эти показатели превращаются в цель и перестают быть честным измерением.
Scrum тут ни при чём, так ведёт себя любая метрика: когда мера становится целью, она перестаёт быть хорошей мерой. Люди быстро находят, как сдвинуть число, не сдвигая того, что оно должно было показывать.
Механизм простой. Команду, с которой спрашивают velocity (сколько оценочных очков она закрывает за спринт), быстро приучают завышать оценки. Где давят на скорость закрытия задач, растёт число мелко нарезанных тикетов. Ценности больше не становится.
Допустим, команда закрывала 30 story points за спринт. После того как цифру начали обсуждать на планёрке у директора, стало 45. Продукт за эти полтора раза не вырос: выросли оценки.
Роль, задуманная как зеркало для команды, превращается в ещё один источник давления. Поэтому вопрос, за какую метрику отвечает роль, совсем не косметический. Неверный ответ ломает и роль, и систему измерений, на которую опирается организация.
Что тогда мерить? У Scrum Master есть показатель, который не превращается в погоню за цифрой. В Scrum команда обязуется достичь цели спринта, а объём работ внутри спринта остаётся предметом переговоров. Доля спринтов, где цель достигнута, плюс доля решений ретроспективы, доведённых до конца, говорят о зрелости практики больше, чем velocity.
У коуча показатели системные: время ожидания между командами, число случаев за квартал, когда одна команда заблокировала другую, время прохождения задачи от идеи до релиза по всему потоку. Эти цифры трудно «нарисовать» усилием одной команды, поэтому они честнее.
Где ошибка нормальна, а где это уже подмена мандата
Обе роли работают в высокой неопределённости. Люди, культура и сложные системы плохо поддаются расчёту, поэтому ошибка масштаба нормальна.
Например, Scrum Master пробует новый формат ретроспективы и получает сопротивление. Agile Coach предлагает организационное изменение, которое не срабатывает. Если из этого сделаны выводы, ошибка стала обучением.
Искажение начинается, когда роль выходит за пределы мандата. Scrum Master берётся менять оргструктуру. Agile Coach ведёт daily и контролирует задачи. Эксперимент у обоих теперь идёт над границами собственных полномочий.
Второй маркер: попытка «чинить всё сразу». Scrum Master отвечает за одну команду и её контекст, Agile Coach за систему команд. Когда уровни смешаны, ни один не получает достаточного внимания.
Часто такое искажение навязывает среда. Она ждёт универсального «agile-спасателя» вместо двух ролей с разным масштабом.
Одна разметка на каждый день: исследование, поставка, найм
Названия встреч у обеих ролей могут совпадать. Различаются вопросы и уровень, на котором роль работает.
Исследование задачи (discovery). Scrum Master следит за качеством командных обсуждений: чтобы команда не перепрыгивала к решениям, умела задавать вопросы и держать неопределённость. Agile Coach смотрит шире: есть ли такая работа в процессах всей компании, как команды делятся выводами, как принимаются решения сразу по всем продуктам.
Если коуч глубоко погружается в исследования одной команды, это обычно сигнал: Scrum Master в ней нет.
Поставка (delivery). Scrum Master работает с устойчивостью команды: помогает видеть причины срывов, улучшать взаимодействие, снижать внутренние потери. Agile Coach анализирует несколько команд сразу: зависимости, узкие места, структуру потоков, управленческие решения, которые тормозят всех.
Когда Scrum Master оптимизирует межкомандные зависимости, а коуч проверяет выполнение задач, роли перепутаны.
Коммуникация. Scrum Master отвечает за качество диалога и психологическую безопасность внутри команды и в разговорах с заказчиками и руководством. Agile Coach выстраивает диалог между уровнями управления, командами и функциями.
Видно это и по следу, который остаётся после роли. Scrum Master редко пишет стратегические документы. Его след: изменения в поведении команды, глубина ретроспектив, качество договорённостей. Agile Coach работает с моделями взаимодействия, картами потоков, распределением ответственности.
Сам коуч при этом постоянно переключается: то учит, то наставляет, то фасилитирует, то задаёт вопросы, на которые ответ должен найти собеседник. Хороший коуч знает, в какой из этих позиций он сейчас, и не застревает в роли того, кто делает работу за команду.
Найм. Та же разметка работает на собеседовании. Кандидат на Scrum Master рассказывает в основном про трансформации и работу с топ-менеджментом? Претендент на коуча гордится тем, как вёл daily и следил за доской? Это сигнал, что человек метит не на свой уровень или вакансия описана через чужие обязанности.
Вместо вопросов про любимые фреймворки полезнее спрашивать про масштаб: что именно изменилось в поведении команды или системы после вмешательства и как человек понял, что пора остановиться.
Если свести различие к рабочей разметке, границы видно по объекту, вопросам и следу, который остаётся после роли:
| Ось | Scrum Master | Agile Coach |
|---|---|---|
| Объект работы | одна команда и её повседневная практика | система команд и устройство организации |
| Типичный вопрос | «почему команда буксует и как помочь ей здесь и сейчас» | «где ломаются стыки между командами и что удерживает менеджмент» |
| Discovery | качество обсуждений внутри команды | встроено ли исследование в процессы компании, как команды делятся выводами |
| Delivery | устойчивость команды, внутренние потери | зависимости, узкие места, потоки между командами |
| Заметный след | сдвиги в поведении команды, глубина ретроспектив | модели взаимодействия, карты потоков, распределение ролей |
| Сигнал подмены | рисует оргсхемы, берётся за трансформацию | ведёт daily, проверяет доску одной команды |
У пяти команд 10 стыков, у десяти уже 45
С ростом узкое место смещается. Пока команда одна, её главные проблемы внутри. Когда команд несколько, проблемы переезжают на стыки: общие зависимости, очереди к общим сервисам, конфликтующие приоритеты.
Число стыков растёт быстрее числа команд. Между n командами может быть n × (n-1) / 2 пар. У пяти команд это 10 возможных связей, у десяти уже 45. Каждая пара способна заблокировать другую.
Зависимости ещё и перемножаются. Допустим, релиз команды ждёт результатов трёх других, и каждая успевает в срок в 80% спринтов. Вероятность, что успеют все три, равна 0,8 × 0,8 × 0,8, то есть около 51%. Каждый второй релиз сдвигается, хотя каждая команда по отдельности выглядит надёжной.
Это уровень Agile Coach. Даже безупречная работа отдельного Scrum Master его не закрывает: команда может быть здоровой внутри и всё равно простаивать в ожидании чужого релиза.
Структура коммуникации к тому же отпечатывается в архитектуре продукта (это наблюдение известно как закон Конвея): если две команды почти не разговаривают, граница между их модулями обычно проходит ровно там, где проходит граница между людьми. Перестроить зависимости между командами значит в итоге перестроить и сам продукт.
Сколько команд тянет один Scrum Master, тоже можно прикинуть. События в Scrum ограничены по времени, и для двухнедельного спринта типичная раскладка такая: около 4 часов планирования, 2 часов обзора, 1,5 часа ретроспективы и 10 daily по 15 минут, примерно 10 часов событий. На остальную работу с командой остаётся больше 60 часов, так что две команды одному человеку по силам, пять уже нет.
Отсюда практический вывод: обе роли нужны не всегда. Одной небольшой команде, которая только осваивает Scrum, обычно хватает сильного Scrum Master. Коуч там будет решать задачу системного масштаба, которой ещё нет, и за неимением другой работы сползёт в операционную рутину.
Коуч оправдан при трёх условиях: команд уже несколько, между ними есть зависимости и конфликты приоритетов, а менеджмент готов менять собственные ожидания. Приглашать коуча туда, где наверху никто не собирается ничего менять, значит заранее обречь роль на бессилие.
Что меняется, когда роли разводят
Дальше два типовых сюжета, без конкретных компаний.
Случай первый: коуч вместо всех. Несколько Scrum-команд, один Agile Coach, роли Scrum Master нет. Коуч ведёт ретроспективы, сидит на планированиях, гасит конфликты. Он знает детали каждой команды, но не успевает работать на системном уровне, хотя ждут от него именно стратегических изменений.
В каждую команду вводят Scrum Master. Сначала сопротивляются все: команды не сразу принимают новых людей, коучу тяжело отпустить операционный уровень. Через несколько месяцев роли стабилизируются. Scrum Master работают с командами, коуч с системой, и появляется пространство для организационных изменений.
Случай второй: «внедрите нам agile». Организация приглашает коуча с размытыми ожиданиями: обучить команды, изменить культуру, улучшить сроки и снизить конфликты одновременно.
Коуч начинает с команд: воркшопы, ретроспективы, базовые практики. Эффект заметен, но краткосрочен. Без постоянного присутствия изменения откатываются, а на руководителей не хватает ни времени, ни фокуса.
Когда становится ясно, что одна роль не закрывает два уровня, в команды выделяют Scrum Master с мандатом на ежедневную практику. Коуч сосредотачивается на их обучении, работе с менеджментом и перестройке ожиданий, а в команды приходит редко и по запросу. Хаос снижается, трансформация становится предсказуемее.
Из этих историй вырастает короткая самопроверка для любой из двух ролей:
- На каком уровне системы я работаю и есть ли у меня мандат на изменения такого масштаба?
- Не подменяю ли я чужую роль своей активностью?
- Работаю ли я с причинами или только с симптомами?
- Есть ли у команд постоянная поддержка Scrum Master, или я стал «единственной точкой agile», без которой всё откатывается?
- По каким метрикам меня оценивают: по моим задачам или по чужим результатам?
Ни одна из ролей не отвечает за бизнес-результат напрямую: обе работают с системой, в которой этот результат создаётся. Поэтому разводить роли удобно с того же вопроса про метрики.
Выпишите, по каким показателям сейчас оценивают Scrum Master и Agile Coach, и вычеркните всё, что относится к результату поставки: velocity, сроки, число закрытых задач. Оставшееся покажет реальный мандат каждой роли.
Если у Scrum Master не осталось ничего про поведение команды, а у коуча ничего про стыки и ожидания менеджмента, переписывать нужно мандат, а людей менять рано.