Когда спринт срывается третий раз за квартал, на разборе обязательно звучит вопрос, чем вообще занят Scrum Master. Ответа в цифрах обычно ни у кого нет.
Его и не будет, пока роль оценивают по скорости и срокам. Scrum Guide в редакции 2020 года делает Scrum Master ответственным за эффективность всей Scrum-команды, то есть за среду, в которой команда думает, спорит и принимает решения. Эффект такой работы проступает медленно и косвенно, поэтому роль так легко списать со счетов.
Scrum Master спрашивают за чужие метрики
Первое искажение возникает, когда на роль смотрят глазами продуктового менеджмента. Как только у команды проблемы с результатом, сроками или качеством, организация ищет виноватого, и им часто оказывается PM или Scrum Master. Scrum Master начинают спрашивать, почему команда не успевает, почему не растёт скорость, почему delivery нестабилен. Но приоритетами он не управляет и за бизнес-результат не отвечает, поэтому такой разговор ничего не чинит.
Хуже всего, когда целью становится скорость в сторипойнтах (velocity). Закон Гудхарта срабатывает здесь почти мгновенно: стоит потребовать роста сторипойнтов, и команда начинает оценивать задачи щедрее. Через три спринта скорость выросла на бумаге, а объём сделанного остался прежним. Scrum Guide 2020 подсказывает более честную опору: команда обязуется достичь цели спринта, а состав работы внутри спринта можно обсуждать и менять. Спрашивать стоит, достигнута ли цель и что помешало, если нет. Число закрытых очков на этот вопрос не отвечает.
Дальше срабатывает подмена ответственности. Системные проблемы перекладывают на одного человека, Scrum Master превращается в удобного козла отпущения, а корневой сбой остаётся нетронутым.
Разница в предмете работы объясняет, почему вклад роли так трудно измерить. Результат PM виден в релизах и метриках продукта. Результат Scrum Master виден в том, как команда спорит, как быстро вскрывает проблемы и как ведёт себя, когда что-то идёт не так. В отчёт о скорости это не помещается, хотя на длинной дистанции среда влияет на результат сильнее любого отдельного спринта.
Буфер прячет дефект системы
Если Scrum Master закрывает собой слабые места PM или менеджмента, в системе что-то сломано. Обычно это случается там, где роли размыты, ожидания противоречат друг другу, а ответственность нигде не записана. Scrum Master незаметно становится посредником. Он договаривается о сроках, объясняет команде решения бизнеса, сглаживает конфликты. Со стороны это выглядит полезно. На деле он заменяет собой процессы, которые не работают.
Во что обходится такая подмена, легко прикинуть. Допустим, команда из шести человек планирует на двухнедельный спринт 60 сторипойнтов и закрывает их, но каждый перерабатывает по 8 часов. Норма команды 6 × 80 = 480 часов, фактически отработано 528. Устойчивая мощность без переработок около 60 × 480 / 528 ≈ 54,5 очка.
Бизнес видит 60 и на следующем планировании снова рассчитывает на 60, хотя каждый спринт команда обещает примерно на 10% больше, чем может сделать без авралов. Буфер этот разрыв не устраняет. Он его прячет.
За иллюзию стабильности команда расплачивается выгоранием и потерей самостоятельности. Выгорание при этом измеримо. Опросник Маслач (Maslach Burnout Inventory) используется с 1981 года, и его можно раз в квартал прогонять анонимно, вместо того чтобы спорить об усталости на уровне ощущений.
Коварство буфера в том, что чем лучше он работает, тем дольше система остаётся сломанной. Пока Scrum Master гасит последствия, у организации нет причин чинить исходный дефект. Полезнее всего он в этой ситуации тогда, когда перестаёт договариваться за команду и начинает показывать цифры: плановую мощность рядом с фактической, часы переработки рядом с обещанным объёмом.
Ошибка учит, контроль разрушает
Чтобы выйти из режима обслуживания, роль вынуждена экспериментировать, а любой эксперимент допускает промах. Scrum Master пробует форматы встреч, приёмы фасилитации, правила взаимодействия и границы ответственности, и неудачи здесь неизбежны. Допустима та ошибка, из которой делают вывод. Scrum Master меняет формат ретроспективы, команде он не нравится, формат корректируют на следующем ретро: ошибка выполнила свою функцию.
Помогает простая дисциплина: каждый эксперимент получает срок в два-три спринта и заранее записанный критерий. Например: «к третьему ретро команда сама приносит хотя бы одну тему, которую раньше обходили». Без критерия эксперимент невозможно ни признать удачным, ни честно закрыть, и он тихо превращается в новую привычку. Scrum Master, который боится ошибаться, поступает наоборот: цепляется за формальные правила и сам низводит роль до администрирования ритуалов.
Граница между обучающей ошибкой и дилетантством проходит по отношению к системе. Первый признак некомпетентности: Scrum Master ограничивается церемониями и регламентом, а реальные проблемы команды остаются за скобками. Второй признак: стремление к контролю. Scrum Master, который следит за загрузкой, давит на скорость и раздаёт указания, разрушает самоорганизацию и действует как менеджер, только без мандата. Чаще всего такое поведение формирует сама среда: когда от Scrum Master ждут «порядка» и «результатов», он начинает действовать против принципов роли, лишь бы этим ожиданиям соответствовать.
Ту же подмену слышно в правильно звучащих фразах. «Давайте просто соблюдать Scrum» часто означает уход от реальной проблемы: процесс становится оправданием вместо изменений. «Моя задача, чтобы вы уложились в срок» превращает Scrum Master в контролёра, потому что он берёт на себя чужую ответственность за результат. Обе фразы звучат ответственно и поэтому особенно опасны: они дают роли ощущение полезности ровно в тот момент, когда она перестаёт делать своё дело.
Зрелость роли читается в поведении команды
Работу Scrum Master редко видно напрямую. Её следы проступают в трёх местах.
В поиске решений они видны по глубине обсуждений. Если команда боится задавать вопросы, избегает неопределённости и быстро прыгает к решениям, психологической безопасности мало. Зрелый Scrum Master удерживает исследовательскую позицию: он не раздаёт ответы, он создаёт пространство, где допустимы сомнения, сырые гипотезы и честное «я не знаю».
В разработке роль заметнее всего по реакции на сбои. Когда при первой проблеме начинается поиск виноватых, система не поддерживает обучение. В зрелой команде разбирают причины, и ошибка становится поводом поправить процесс.
Здесь же Scrum Master может показать механику, которую команда обычно не видит. По закону Литтла (1961) среднее время, которое задача проводит в работе, равно числу начатых задач, делённому на число задач, которые команда закрывает за неделю. Если в работе одновременно 15 задач, а закрывается 5 в неделю, каждая в среднем идёт три недели. Сократите незавершённое до 10 при той же пропускной способности, и среднее время упадёт до двух недель без единого часа переработки.
В коммуникации роль видна по качеству диалога. Если встречи превращаются в отчёты и оправдания, роль фактически не выполняется. Зрелость там, где команда прямо говорит о сложном и конфликты обсуждают по существу, без замалчивания и без эскалации.
Есть и более осязаемые улики. Глубина ретроспектив и качество выводов напрямую отражают способность команды к рефлексии. Норман Керт, автор книги «Project Retrospectives» (2001), строил ретроспективу как инструмент изменения, и эту проверку легко перевести в число: какая доля действий, записанных на ретро, выполнена к следующему ретро.
Допустим, за три ретро команда записала 12 действий и выполнила 4. Треть означает, что ретроспектива превратилась в список жалоб без последствий. Рабочий ориентир (настраиваемый): если доля ниже половины три ретро подряд, меняйте формат и сокращайте число действий до одного-двух на спринт.
У этой метрики должен быть ограничитель, иначе её легко накрутить мелкими пунктами вроде «обновить вики». Поэтому рядом стоит держать долю незапланированной работы в спринте и часы переработки. Если действия выполняются, а переработка не падает, команда чинит удобное и обходит главное.
Финальная проверка проще любых метрик: становится ли команда со временем самостоятельнее. Если без Scrum Master всё сразу встаёт, роль пока держит команду на себе.
Сценарии поломки подпитывают друг друга
Там, где культура обучения не сложилась, роль ломается по узнаваемым сценариям. Их удобно разделить на три группы.
Сползание к контролю и форме. Вместо вопросов появляются указания, кто что делает и когда будет готово, и команда мгновенно отдаёт ответственность обратно. Спор о том, уложиться ли daily в отведённые Scrum Guide 15 минут, заслоняет вопрос, зачем он вообще нужен. Церемонии идут по одному шаблону, люди присутствуют без внимания, и каждая такая встреча укрепляет мнение, что Scrum сводится к бюрократии.
Уход от напряжения. Scrum Master гасит любой спор ради комфорта, хотя замалчиваемое напряжение уходит в пассивную агрессию и тихие увольнения. Он избегает неудобных разговоров про перегрузку, слабого участника или сомнительное решение менеджмента, и именно эти несостоявшиеся разговоры потом становятся кризисами. Он стремится всем нравиться. Хороший Scrum Master регулярно создаёт дискомфорт: подсвечивает проблемы и возвращает ответственность.
Подмена системы собой. Scrum Master сам договаривается со стейкхолдерами, сам чинит процесс, сам следит за доской, и в первый же его отпуск всё разваливается. Церемонии идут, но назвать, что команда поняла за месяц, никто не может. Он повторяет одни и те же приёмы независимо от результата и идеально выстраивает процессы внутри команды, которую рвут на части внешние приоритеты.
Сценарии складываются в круг. Сполз к контролю, команда отдала ответственность, роль стала незаменимой, поднимать неудобные темы стало страшно, чтобы не расшатать хрупкое равновесие. В итоге всё держится на одном человеке, который всем нравится и ничего не меняет. Косметикой этот круг не разорвать, потому что каждый виток вырастает из предыдущего. Выход один: сознательно возвращать ответственность команде даже там, где быстрее и спокойнее сделать самому.
Два разворота: ретро и роль буфера
Возьмём команду, каких много. Она формально работала по Scrum, но воспринимала церемонии как рутину: daily проходили механически, ретроспективы раздражали, реальные проблемы не обсуждались. Scrum Master заметил, что разговоры о перегрузке и качестве быстро сворачивают или переводят в шутку.
Он отказался от шаблонов ретро и стал разбирать реальные эпизоды последнего спринта. Встречи стали напряжённее и длиннее, команда открыто выражала недовольство, но Scrum Master выдержал давление и продолжал собирать обратную связь. Со временем участники начали сами поднимать сложные вопросы, и конфликты стали решаться раньше, чем успевали накопиться.
Другая типичная команда жила под постоянным давлением бизнеса. Приоритеты менялись почти каждую неделю, сроки сжимались, переработки стали нормой. От Scrum Master ждали, что он «защитит команду». Сначала он так и делал: сглаживал конфликты, договаривался о переносах, брал на себя тяжёлые разговоры с менеджментом. Напряжение спадало, но настоящие ограничения оставались невидимыми. Бизнес думал, что команда справляется, и Scrum Master, сам того не замечая, поддерживал эту иллюзию.
Подход пришлось поменять. Scrum Master перестал быть щитом и начал показывать факты. На планировании стали записывать реальную мощность без переработок, как в расчёте с 54 очками вместо 60. На ретро разбирали, почему срывались сроки. Бизнесу было неприятно слышать про ограничения, команда боялась последствий открытости. Но Scrum Master держался данных и никого не обвинял. Через несколько месяцев приоритеты стали стабильнее, ожидания реалистичнее, а Scrum Master наконец перестал тушить пожары.
У обоих разворотов общий механизм. В первом Scrum Master сделал видимыми темы, которые команда обходила, во втором ограничения, которые не видел бизнес. В обоих случаях первые недели были хуже прежних, и это нормальная цена: команда, которая перестала делать вид, сначала выглядит менее благополучной.
Нужен ли стабильной команде отдельный Scrum Master?
Рано или поздно кто-то в финансах задаёт простой вопрос. В стабильной команде из семи человек выделенный Scrum Master занимает седьмую часть бюджета команды. Если команда давно работает вместе, неплановой работы мало, а ретроспективы и договорённости со стейкхолдерами она ведёт сама, этот человек обслуживает процесс, который уже работает без него, и выделенная должность выглядит излишеством.
Для зрелой команды это справедливо, и Scrum Master, который хорошо сделал свою работу, сам к этому приводит. Лисса Адкинс в книге «Coaching Agile Teams» (2010) описывает роль через коучинговую позицию, где цель в самостоятельности команды. Ошибка в другом: решать вопрос по ощущению зрелости, без проверки.
Проверка выглядит так. Два спринта команда работает без активного участия Scrum Master. Если ретро проходят с выполненными действиями, доля незапланированной работы не растёт, а с изменением приоритетов команда разбирается сама, Scrum Master можно разделить между двумя-тремя командами. Если что-то из этого проседает, роль ещё нужна, и стоит выяснить, какую функцию она выполняла незаметно.
8 вопросов, на которые есть проверяемый ответ
Двадцать вопросов для самопроверки легко пройти формально. Восемь, приведённых ниже, сложнее, потому что на каждый есть проверяемый ответ.
- Какие реальные ограничения команды я сделал видимыми для бизнеса за последний месяц?
- Какую ответственность я взял на себя вместо команды и когда верну её обратно?
- Какая доля действий с прошлых трёх ретро выполнена?
- Какой неудобный разговор я откладываю дольше двух недель?
- Какой эксперимент с процессом сейчас идёт и по какому критерию я его закрою?
- Принимает ли команда решения без меня, и на каком последнем примере я это видел?
- Работает ли команда без переработок, и чем я это подтверждаю?
- Что сломается, если я уйду в отпуск на две недели?
Пять вопросов, которые задают про роль
Чем Scrum Master отличается от менеджера?
У менеджера в руках люди, бюджет и результат. Scrum Master работает с процессами, правилами взаимодействия и культурой команды: он не ставит задачи, не оценивает людей и не распределяет ответственность. Его задача в том, чтобы команда умела управлять собой. Когда эти роли смешиваются, теряется доверие: люди перестают говорить Scrum Master о проблемах, если он же влияет на их оценку.
Должен ли Scrum Master оценивать людей?
Нет. Кадровая оценка и распределение вознаграждений конфликтуют с фасилитацией, поэтому их отделяют от обратной связи, которая помогает команде учиться. Scrum Master может помогать работать с данными и наблюдениями, но выводы о людях делает менеджмент, а выводы о процессе команда делает сама. Если руководитель просит у Scrum Master «характеристику» на участника, правильный ответ: вернуть вопрос тому, кто отвечает за оценку.
Может ли Scrum Master быть бывшим разработчиком?
Может, и технический бэкграунд часто помогает: Scrum Master быстрее понимает контекст, и разработчики ему больше доверяют. Риск в экспертной позиции. Бывшему разработчику трудно удержаться от того, чтобы предлагать решения и вмешиваться напрямую. Полезное правило: на технических обсуждениях он задаёт вопросы и не предлагает вариантов, пока команда не перебрала свои.
Можно ли совмещать роли Scrum Master и PM?
Формально можно, но это почти всегда приводит к конфликту. PM отвечает за результат и приоритеты, Scrum Master за процесс и культуру взаимодействия, и под давлением срока совмещающий выбирает результат. Ретро, на котором команда говорит, что приоритеты меняются слишком часто, проводит тот же человек, который их меняет. Краткосрочно совмещение работает, на длинном горизонте снижает устойчивость команды.
Что делать, если команда сопротивляется Scrum Master?
Сопротивление часто связано с прошлым опытом: команда уже видела формального Scrum Master, который лишь усложнял работу. Начинать стоит с одной конкретной боли команды, например с совещания, которое все считают бесполезным, и убрать или переделать его в первые две недели. Авторитет у этой роли зарабатывается пользой, которую команда ощущает на практике, и должность здесь ничего не добавляет.
Лучше всего работа видна в отпуске
Вклад Scrum Master трудно измерить и невозможно свести к списку задач: он работает с отношениями, поведением и правилами взаимодействия, а планы и сроки остаются за командой и PM. Отсюда парадокс, из-за которого роль так трудно оценить со стороны. Пока Scrum Master на месте, ретро с выводами и самостоятельные договорённости команды выглядят заслугой самой команды, и в хорошем случае так оно и есть.
Если в его отпуск всё это пропадает, роль подменяла систему собой. Запланируйте этот отпуск как эксперимент: перед уходом запишите, что должно работать без вас, а после возвращения сверьте список с реальностью. Пункты, которые не выдержали двух недель, и есть план на следующий квартал.