Разница Scrum Master и Agile Coach: не “кто круче”, а “какую задачу решаем”
1) Один вопрос, который моментально проясняет различия
Scrum Master помогает команде делать Scrum рабочим и улучшаться внутри выбранного способа работы.
Agile Coach помогает командам и руководителям делать организацию способной устойчиво создавать ценность — через Agile/Lean-мышление, улучшение потока, культуры, взаимодействий, метрик и изменений на уровне системы.
Если коротко в одной фразе:
- Scrum Master чаще “про команду и рамку Scrum”.
- Agile Coach чаще “про систему и способность меняться”.
2) Область ответственности: где заканчивается “команда” и начинается “организация”
Scrum Master: фокус на команде и её окружении “на расстоянии вытянутой руки”
Типовая зона влияния Scrum Master:
- одна команда (иногда две, если они тесно связаны);
- качество Scrum-событий и артефактов;
- устранение препятствий, которые блокируют доставку;
- улучшение договорённостей и прозрачности;
- помощь PO и команде работать эмпирически (учиться на фактах).
Это согласуется с классическим определением роли: Scrum Master как человек, который устраняет препятствия и “ведёт” Scrum-процесс.
Agile Coach: фокус на нескольких командах, лидерах и “правилах игры”
Agile Coach обычно работает там, где:
- несколько команд завязаны зависимостями;
- есть слои управления и приоритизации;
- требуется изменение поведения руководителей и способов принятия решений;
- проблемы лежат в политике, структуре, метриках, портфеле инициатив и “очередях согласований”.
Хорошая метафора: Scrum Master улучшает команду как двигатель, Agile Coach улучшает дороги, правила движения, топливо, навигацию и сервис, чтобы двигатель мог ехать быстро и безопасно.
3) Масштаб влияния: “локальная оптимизация” против “системной”
Если нарисовать шкалу масштаба:
- Команда → Несколько команд → Департамент → Компания
- Scrum Master обычно наиболее эффективен слева.
- Agile Coach чаще нужен ближе к центру и справа.
Почему? Потому что многие узкие места — не в команде, а в системе вокруг: приоритеты, зависимости, поток, политика “всем срочно”, непрояснённые ожидания, конфликт целей. Это как раз та область, где “одной роли по процессу” мало.
4) Цели на разных горизонтах: “спринт” против “квартал/полгода”
Scrum Master
Цели чаще измеряются на коротком цикле:
- качество планирования и ясность Sprint Goal;
- уменьшение блокеров;
- улучшение DoD/качества;
- устойчивость ритма и предсказуемость команды;
- рост самостоятельности команды.
Agile Coach
Цели чаще “длиннее” и связаны с изменением системы:
- сокращение lead time / cycle time на уровне нескольких команд;
- снижение WIP и количества параллельных инициатив;
- повышение согласованности целей (strategy → execution);
- улучшение качества взаимодействия функций (продукт/разработка/маркетинг/продажи/поддержка);
- изменение управленческих практик (как принимаются решения, как ставятся цели, как управляются зависимости).
В North Star подходе хорошо подсвечена причина, почему организации “ходят по кругу”: разные части говорят на разных языках — клиента, продукта и бизнеса — и нужен способ связать эти перспективы.
Agile Coach часто и выступает тем, кто помогает наладить эту связность на практике (цели, метрики, ритуалы, прозрачность, ответственность).
5) Что каждый делает “руками”: сравнение по типам задач
5.1 Scrum Master — типовые практические действия
- фасилитирует Scrum-события так, чтобы они приводили к решениям и действиям;
- помогает команде увидеть и устранить препятствия (включая организационные);
- помогает PO и команде договориться о критериях готовности и качества;
- обучает команду эмпирике: “посмотрели на факты → решили → проверили”.
5.2 Agile Coach — типовые практические действия
- проводит диагностику потока (где очереди, где потери, где зависимостям “нечем дышать”);
- выстраивает способы согласования приоритетов на уровне нескольких команд;
- помогает руководителям менять управленческие практики: от “контроль и отчётность” к “цели, ограничения и доверие”;
- развивает “организационную мышцу” изменений: коммуникация, обучение, change management.
В North Star playbook прямо отмечается: North Star не “лозунг на стене”, нужны системы (поддержка лидеров, коммуникации, процессы изменений), чтобы это работало.
Это типичная зона работы Agile Coach.
6) Артефакты и результаты работы: чем отличаются “продукты” ролей
Scrum Master обычно “оставляет после себя”
- улучшенный формат планирования / daily / review / ретро;
- прозрачную доску и понятные правила работы;
- перечень препятствий и их разбор;
- договорённости команды, более сильную автономность;
- рост качества и предсказуемости поставки в рамках команды.
Agile Coach обычно “оставляет после себя”
- правила и инструменты управления потоком (WIP-лимиты, классы обслуживания, политики вытягивания);
- межкомандные механизмы синхронизации и уменьшения зависимостей;
- систему метрик потока и здоровья;
- работающие форматы выравнивания целей и приоритетов;
- библиотеку практик, обучение, внутреннее комьюнити.
7) Метрики эффективности: как понять, что роль приносит пользу
Scrum Master — признаки результата
- меньше “застрявших” задач внутри спринта;
- меньше конфликтов вокруг “что значит готово”;
- ретроспективы приводят к изменениям, а не к разговорам;
- команда быстрее доводит работу до Done, меньше “почти готово”.
Agile Coach — признаки результата
- падает средний lead time / растёт throughput на уровне потока (не одной команды);
- уменьшается количество параллельных инициатив;
- улучшается предсказуемость сроков и качество прогнозов;
- стейкхолдеры меньше “впихивают срочное”, потому что появились явные правила;
- команды могут объяснить, как их работа связана со стратегией и ростом — в playbook это описано как необходимость связать повседневную работу со стратегией, иначе либо стратегии нет, либо “грязная середина”, либо делается не то.
8) Взаимодействие с руководством: где “точка входа” роли
Scrum Master
Обычно работает с менеджерами точечно:
- чтобы снять блокеры;
- чтобы защитить фокус команды;
- чтобы улучшить входной поток задач;
- чтобы договориться о границах изменений в спринте.
Agile Coach
Работает с руководителями системно:
- меняет правила приоритизации;
- уменьшает организационные очереди и “ступени согласований”;
- помогает сформировать понятные цели и метрики;
- обучает лидеров поддерживающим практикам (не “как контролировать”, а “как выстроить систему”).
9) Компетенции: где пересечение, а где расхождение
Общие навыки (оба должны уметь)
- фасилитация и работа с групповыми решениями;
- конфликтология и переговоры;
- обучение взрослых (без “лекций сверху”);
- наблюдение за системой и обнаружение узких мест.
Scrum Master — “ядро”
- глубокое понимание Scrum и командной динамики;
- практики улучшения поставки и качества в команде;
- работа с impediments и прозрачностью.
Agile Coach — “ядро”
- системное мышление, орг-дизайн (хотя бы на прикладном уровне);
- flow/Lean-подход, работа с зависимостями, управлением спросом;
- change management и работа с лидерами;
- построение “систем” (метрики, правила, способы принятия решений), а не только проведение встреч.
10) Ошибки и антипаттерны: как роли ломаются в реальности
Антипаттерны Scrum Master
- Секретарь церемоний: “созвал, провёл, разослал” — без улучшений.
- Диспетчер задач: вручную раздаёт работу, убивая самоорганизацию.
- Суррогат PM/PO: начинает решать, что делать, вместо того чтобы улучшать способ работы.
- Полицейский Scrum: “по книжке надо так”, вместо адаптации под контекст.
Антипаттерны Agile Coach
- Полиция Agile на уровне компании: “запретить, заставить, наказать”.
- Вечный консультант: много диагнозов, мало закреплённых изменений и систем.
- Один человек вместо системы: все идут к коучу за решениями — это признак зависимости.
- Размытая роль: “делаю всё” → нет измеримого эффекта.
Полезная мысль из источника про роли: добавлять дополнительные роли можно, но важно убедиться, что они реально добавляют ценность и не конфликтуют с процессом.
11) Когда достаточно Scrum Master, а когда нужен Agile Coach
Scrum Master обычно “закрывает” ситуацию, если:
- одна команда и ограниченные зависимости;
- Scrum ещё не стал рабочей привычкой;
- основные проблемы — в прозрачности, качестве договорённостей, дисциплине улучшений;
- препятствия можно устранять через непосредственные договорённости со стейкхолдерами.
Agile Coach становится нужным, если:
- 3+ команды завязаны зависимостями;
- много параллельных инициатив и постоянные переключения;
- правила приоритизации конфликтуют между функциями;
- проблема “не в команде”: решения, бюджеты, цели, орг-структура, метрики;
- нужно выстроить change management, обучение, общие способы работы.
В книге даже приводится пример полезной дополнительной роли для большого проекта: человек, который помогает нескольким командам и Product Owner-ам синхронизироваться.
По сути это очень близко к тому, как часто выглядит работа Agile Coach (или Agile Delivery Lead) в многокомандной среде.
12) “Матрица выбора”: быстрый способ решить, какую роль усиливать
| Ситуация | Что усиливать в первую очередь | Почему |
|---|---|---|
| Одна команда, Scrum “не взлетел” | Scrum Master | Нужны базовые ритмы, прозрачность, DoD, ретро с действиями |
| Две команды, умеренные зависимости | Scrum Master + лёгкая координация | Часто достаточно сильных SM и договорённостей |
| 3–10 команд, общий продукт/портфель | Agile Coach | Важно выстроить поток, приоритизацию, зависимости, правила срочности |
| “Сверху” постоянно меняют приоритеты | Agile Coach | Это проблема управления спросом и системы принятия решений |
| Много релизных болей и ручных процессов | Scrum Master + инженерные практики, иногда Coach | Команда может улучшить, но часто нужны изменения системно |
| Конфликт функций (продукт/разработка/продажи) | Agile Coach | Нужны общие цели, язык ценности, правила взаимодействия |
13) RACI-картина: кто за что отвечает (чтобы не дублировать роли)
Обозначения: R — делает, A — отвечает, C — консультирует, I — информируется.
| Задача | Scrum Master | Agile Coach | PO/PM | Руководители |
|---|---|---|---|---|
| Настроить рабочие Scrum-события в команде | R/A | C | C | I |
| Устранение командных препятствий | R | C | C | I/A (если препятствие орг.) |
| Межкомандные зависимости | C | R/A | C | A |
| Политика приоритизации портфеля | I | C/R | C | A |
| Внедрение WIP-лимитов и flow-метрик на уровне департамента | C | R/A | I/C | A |
| Обучение и change management на уровне компании | I/C | R/A | I/C | A |
14) Как роли усиливают друг друга, а не конкурируют
Самая рабочая конфигурация в зрелых организациях:
- Scrum Master делает команды сильными и автономными.
- Agile Coach улучшает систему вокруг команд и помогает лидерам менять правила игры.
Именно поэтому Agile Coach редко “заменяет” Scrum Master: он увеличивает пропускную способность организации, когда проблемы уже не помещаются в рамки одной команды.
15) Практический сценарий: один кейс — две разные оптики
Ситуация: команда не успевает, задачи “висят”, срочное ломает планы
Scrum Master в первую очередь разберёт:
- почему работа не доходит до Done;
- где неясность DoD/критериев;
- как планируется спринт и почему появляется “внезапное”;
- как устроена ежедневная координация и видимость блокеров.
Agile Coach в первую очередь разберёт:
- почему срочное может входить без ограничений (нет классов обслуживания/правил);
- кто и как меняет приоритеты (нет системы управления спросом);
- где очереди согласований и зависимости;
- сколько WIP и как оно раздувает сроки;
- какие метрики потока показывают реальную картину на уровне нескольких команд.
Обе оптики правильные — они просто про разные уровни системы.