Scrum Master: не начальник

Самая непонятная роль в Scrum: человек без власти над людьми, который при этом отвечает за то, чтобы всё работало.

Scrum Master (SM) — отвечает за то, чтобы команда работала эффективно: помогает вести встречи, убирает препятствия и защищает процесс. Он не руководитель команды и не раздаёт задачи.

Почему эту роль так тяжело объяснить

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

Отсюда два симметричных провала. Либо SM тихо превращается в тимлида и начинает командовать. Либо становится «секретарём Jira»: двигает карточки, напоминает про статусы, бронирует переговорки. В первом случае убивают самоорганизацию, во втором — тратят зарплату впустую.

Правильная метафора — не начальник и не секретарь, а тренер команды. Тренер не выходит на поле и не забивает голы. Но если команда играет плохо, спрашивают с него.

Работа №1: убирать препятствия

Препятствие (impediment) — всё, что мешает команде довести работу до конца и что она не может убрать сама. Классика жанра:

ЖУРНАЛ ПРЕПЯТСТВИЙ — команда «Каталог»

#  Препятствие                            Кто блокирует    Дней  Статус
1  Нет доступа к тестовому стенду         отдел ИБ         12    эскалировал CTO
2  Релиз ждёт согласования безопасности   отдел ИБ         5     назначена встреча 16.07
3  Аналитик занят на другом проекте       рук. аналитики   8     договорился на 50%
4  Сборка CI идёт 40 мин, ждём каждый PR  —                21    команда взяла в спринт
5  PO не отвечает по чату дольше суток    —                 3    поговорил, договорились

Строка №1 — самая показательная. Разработчик двенадцать дней назад написал заявку в отдел информационной безопасности и получил тишину. Он может писать туда каждый день ещё месяц — ничего не изменится, потому что у него нет ни рычагов, ни времени. У Scrum Master есть и то и другое: он идёт в отдел ИБ ногами, выясняет, что заявку потеряли, а когда и это не срабатывает — эскалирует до CTO.

Звучит скучно и совсем не «аджайл». Но именно это, а не стикеры на ретро, приносит основную пользу. Двенадцать дней простоя — это порядка недели работы одного разработчика, выброшенной на согласования.

Важная деталь: не всякую помеху SM обязан убирать сам. Строка №4 (медленная сборка) — техническая проблема, её решает команда, SM лишь помогает выбить на это время в спринте. А вот строка №5 — «PO пропал» — это точно к нему.

Работа №2: фасилитация встреч

Фасилитатор — тот, кто ведёт обсуждение так, чтобы группа пришла к решению сама. Не советует, не решает за других, следит за процессом и временем.

Разница видна на планировании спринта. Двенадцать человек сорок минут спорят, сколько задач взять. Плохой SM: «Берём восемь, в прошлый раз столько сделали». Хороший: «У нас 15 минут до конца. Мы обсуждаем задачу №3 уже двадцать минут — похоже, нам не хватает информации. Что если вынести её из спринта и вернуться, когда PO уточнит?» Первый принял решение за команду. Второй назвал вслух то, что все чувствовали, и вернул решение команде.

То же на ретроспективе. Без фасилитатора она скатывается либо в жалобы («всё плохо, менеджмент виноват»), либо в неловкое молчание. Работа SM — вытащить конкретику и добиться, чтобы из встречи вышло одно-два действия с ответственным и сроком, а не двадцать благих намерений.

Чего Scrum Master НЕ делает

Не делает	Почему
Не раздаёт задачи	Задачи берут сами разработчики. Если их назначает SM, самоорганизация выключается: люди перестают думать о работе целиком
Не отчитывает за просрочку	Он не начальник. Если команда не успела — это тема для ретро и разговора о причинах, а не для разноса
Не оценивает сотрудников	Нельзя одновременно быть тем, кому безопасно признаться в ошибке, и тем, кто пишет отзыв на ревью зарплаты
Не обещает сроки за команду	Оценку даёт команда, обязательства по спринту — тоже она
Не пишет код за других	Может, если он технарь и команда просит. Но это не его роль, и это не должно вытеснять роль
Не «сдаёт» команду наверх	Кто сколько закрыл задач, кто опоздал на стендап — не предмет для отчёта. Это верный способ убить доверие

Последний пункт — про суть роли. Как только команда понимает, что SM пересказывает начальству, кто из них тормозит, все встречи превращаются в театр: на стендапе все «в порядке, работаю над задачей», на ретро — «всё отлично». Проблемы уходят в подполье, и SM больше не узнаёт о них до дня релиза.

Как это работает

Влияния у Scrum Master ноль по должности и много по факту — если он его заработал. Инструменты у него такие:

Вопрос вместо указания. Не «делайте задачи меньше», а «мы третий спринт подряд переносим по три задачи. Что у них общего?» Команда сама увидит, что задачи слишком крупные, — и тогда она это и починит.
Данные вместо мнений. «За квартал 40% времени ушло на срочные баги из продакшена» — с таким аргументом разговор с руководством о качестве идёт совсем иначе, чем с «команда устала».
Прозрачность. Сделать видимым то, что все чувствуют, но никто не произносит: очередь на согласование, вечно занятого единственного тестировщика, PO, который не появлялся десять дней.
Защита спринта. Классический случай: в среду приходит директор и просит «одну маленькую задачку». SM — тот, кто говорит «давайте посмотрим, что мы вынесем из спринта взамен», а не тот, кто молча передаёт задачу разработчику.

Хороший показатель зрелости: чем дольше SM работает с командой, тем меньше он нужен. Через год команда сама ведёт стендап, сама тормозит расползающийся спор, сама эскалирует блокеры. Тогда SM берёт вторую команду или уходит работать на уровень организации.

Частые ошибки

SM = тимлид. Самый распространённый и самый разрушительный гибрид. Человек, который решает вашу премию, не может одновременно быть тем, кому безопасно сказать «я не понимаю эту задачу и торможу уже неделю».
SM = администратор Jira. Если вся его работа — двигать карточки и напоминать про заполнение полей, роль стоит просто упразднить и раздать эти дела команде.
SM на шесть команд. Экономия, которая не работает: на каждую команду остаётся час в неделю, а препятствия требуют настойчивости и присутствия. Один-два коллектива — рабочий максимум.
Гонка за velocity. «В прошлом спринте 30 очков, давайте в этом 35». Команда мгновенно начинает завышать оценки, и метрика перестаёт что-либо значить. Velocity — инструмент планирования, а не KPI.
Обрядоверие. Встречи проводятся, доска обновляется, стикеры клеятся — а препятствия из журнала висят по три недели. Форма соблюдена, смысла нет.
SM берёт вину на себя. «Я не уследил, поэтому не успели». Так он вновь становится начальником — просто виноватым. Ответственность за результат спринта несёт команда целиком.

Итоги

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