Коучинг команды, конфликты и сопротивление изменениям

Механику Scrum можно выучить за выходные. События, артефакты, тайм-боксы, обязательства — всё это конечный список фактов, который укладывается в голову к третьему прочтению Guide. А потом вы приходите в живую команду, где двое разработчиков не разговаривают друг с другом третий месяц, тестировщик молча ставит все задачи в «returned», а на предложение сократить спринт до двух недель отвечают: «мы пробовали, у нас так не работает».

И вот здесь выясняется, что вся выученная механика бесполезна. Не потому что она неправильная, а потому что никто её не применит, пока не решён вопрос отношений между людьми.

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

Эта статья — сборка. Мы разберём, где проходит граница между «Scrum-мастер обязан по Guide», «так делают в хороших командах» и «так делать точно не стоит»; как выбирать степень вмешательства; как читать конфликт по уровню эскалации, а не по громкости голосов; и почему сопротивление изменениям — не враг, а самый ценный источник информации, который у вас есть.

Что Scrum Guide реально говорит о коучинге

Начнём с первоисточника, чтобы дальше было понятно, где кончается норматив и начинается практика.

Guide 2020 описывает Scrum-мастера как «true leader who serves the Scrum Team and the larger organization». В списке служения команде первым пунктом стоит:

«Coaching the Scrum Team members in self-management and cross-functionality»

Обратите внимание на предмет коучинга. Не «коучинг людей вообще», не «личностный рост», не «карьерное развитие». Ровно два предмета: самоуправление и кросс-функциональность. То есть способность команды самой решать, кто что делает, когда и как, и наличие внутри команды всех навыков, чтобы довести работу до готового инкремента.

Остальные пункты служения команде из Guide:

• помогать команде фокусироваться на создании инкрементов высокой ценности, соответствующих Definition of Done;
• добиваться устранения препятствий (causing the removal of impediments) — заметьте формулировку: не «устранять самому», а «делать так, чтобы они были устранены»;
• обеспечивать, чтобы все события Scrum состоялись, были позитивными, продуктивными и уложились в тайм-бокс.

А вот чего в Guide нет — и это ловушка PSM I:

Это важное различение. Когда на экзамене спрашивают «что должен сделать Scrum-мастер, если два разработчика ссорятся», правильный ответ почти никогда не «разнять и вынести решение». Guide исходит из того, что команда самоуправляемая, а значит способна разбираться со своими конфликтами. Задача Scrum-мастера — сделать так, чтобы у неё была для этого способность и безопасное пространство.

Guide vs практика. Guide: Scrum-мастер коучит команду в самоуправлении. Практика: 80% времени начинающего Scrum-мастера уходит на разговоры один на один, разбор недопониманий и переговоры с менеджментом. Антипаттерн: Scrum-мастер становится штатным психотерапевтом или, наоборот, надзирателем с чек-листом.

Континуум вмешательства: сколько себя добавить в ситуацию

Главный навык — не «уметь коучить», а выбирать режим. Есть шкала от полностью директивного («делай так») до полностью недирективного («что ты об этом думаешь?»). Плохой Scrum-мастер живёт в одной точке этой шкалы и таскает её за собой везде.

Разберём режимы подробнее.

Директива. Вы просто говорите, как должно быть. Уместно ровно в двух случаях: нарушается сам каркас (команда собирается растянуть спринт, чтобы «доделать») или ситуация кризисная и нет времени на диалог. Директива дёшева в моменте и дорога в долгую: каждый раз, когда вы решаете за команду, вы забираете у неё немного самоуправления.

Обучение (teaching). Передача знания, которого у команды объективно нет. Новая команда не знает, зачем нужна Sprint Goal — вы объясняете. Это не «сдвиг влево», это нормальная работа, особенно в первые 90 дней.

Менторинг. Передача опыта: «я видел похожую ситуацию, вот что там сработало и почему». Отличается от обучения тем, что вы делитесь не знанием из книжки, а личной практикой — включая свои провалы.

Консультирование. Вы приносите варианты, но не выбираете. «Есть три способа справиться с зависимостью от соседней команды: договориться о контракте заранее, забрать компетенцию к себе, или сделать заглушку. Каждый чем-то плох. Что вам ближе?»

Фасилитация. Вы не приносите содержания вообще — вы приносите процесс. Ваш вклад: структура разговора, порядок, время, дисциплина. Тема — целиком команды. Подробно разбирали в статье о фасилитации.

Коучинг. Вы помогаете человеку или группе самим найти ответ, задавая вопросы. Ваша гипотеза о правильном решении при этом остаётся при вас — и это самое трудное.

Как выбрать режим

Последний блок — не украшение. Самый распространённый провал: Scrum-мастер один раз обоснованно сдвинулся влево (команда новая, ничего не знает) и застрял там навсегда. Через год у него «команда, которая ничего не может без него» — и он искренне считает это признаком своей нужности.

Практическое правило. Если вы за неделю ни разу не задали вопрос, ответ на который не знали заранее, — вы не коучили. Вы проводили допрос с известным исходом, и команда это чувствует.

Механика коучингового разговора

Коучинг — это ремесло с конкретной техникой, а не «доброжелательное общение». Базовая техника, которую стоит освоить первой, — модель GROW (Goal, Reality, Options, Way forward), сформулированная Джоном Уитмором в книге «Coaching for Performance».

Разберём, что здесь сделано и чего сделано не было.

Не было объяснения. Scrum-мастер точно знал, что дейли — это инспекция прогресса к Sprint Goal, а не отчёт. Он мог сказать это первой же репликой, за десять секунд. И потерял бы всё: человек услышал бы «ты неправильно понимаешь» и закрылся. Знание, которое человек добыл сам, он потом защищает; знание, которое ему выдали, он забывает.

Вопросы открытые и короткие. «Каким бы ты хотел видеть», «что конкретно звучало», «что ещё». Ни одного вопроса, на который можно ответить «да» или «нет». Ни одного вопроса с зашитым ответом («а тебе не кажется, что стоило бы…» — это не вопрос, это переодетое указание).

«Что ещё?» — самый недооценённый вопрос коучинга. Первый вариант, который приходит в голову, почти всегда очевидный и слабый. Второй и третий — интереснее. Правило: спрашивайте «что ещё» минимум дважды, даже когда кажется, что тема исчерпана.

Разговор закончился действием с автором и сроком. Коучинговая беседа без выхода в конкретику — это душевные посиделки. Полезные, но не работа.

Три уровня слушания

Из Co-Active Coaching (Кимси-Хаус и соавторы) — модель, которая быстро окупается на практике:

Большинство разговоров люди ведут на уровне I. Ретроспектива, где Scrum-мастер слушает на уровне I, — это ретроспектива, где он ждёт паузы, чтобы вставить свой пункт. Уровень III — то, чем ценен опытный фасилитатор: он замечает, что после реплики тимлида двое замолчали, и умеет назвать это вслух: «я заметил, что после этой темы разговор стал тише. Это мне кажется, или тут есть что-то ещё?»

Что не является коучингом

Полезно иметь список — ошибки узнаваемые:

• Вопрос-обвинение. «А почему ты не сделал это на прошлой неделе?» Начинающееся с «почему» про прошлое почти всегда звучит как претензия. Замена: «что помешало?», «как получилось, что…»
• Вопрос с готовым ответом. «Не думаешь ли ты, что стоит разбить историю на части?» Человек слышит указание и либо соглашается формально, либо упирается.
• Терапия. Разбор детских травм, семейных обстоятельств и клинической тревоги — не ваша зона, даже если человек сам открывает эту дверь. Границу держать жёстко: вы работаете с рабочим контекстом, всё остальное — к профильным специалистам.
• Коучинг вместо информации. Человек спрашивает «в каком репозитории лежит конфиг?», а вы отвечаете «а как ты думаешь?». Это не недирективность, это издевательство.

Конфликты: читать по уровню, а не по громкости

Первая ошибка Scrum-мастера в конфликте — реагировать на форму. Спокойный вежливый диалог, где стороны обсуждают, «как реорганизовать команду, чтобы больше не работать вместе», гораздо опаснее громкого спора об индексах в базе.

Самая полезная модель здесь — уровни эскалации конфликта Спида Лиза (Speed B. Leas, «Moving Your Church Through Conflict»). Она изначально не про IT, но описывает универсальную механику: по мере эскалации меняется не громкость, а цель сторон.

Практическая ценность модели в двух вещах.

Первое: уровень определяет ваш инструмент. На уровне 1–2 работает всё, чему учат Scrum-мастера: фасилитация, ретроспектива, рабочее соглашение. На уровне 3 нужны навыки медиации. На уровнях 4–5 Scrum-мастер, пытающийся «починить это в команде», делает хуже: он легитимизирует ситуацию, в которой людям объективно нельзя оставаться вместе. Правильный ход — эскалировать к тем, у кого есть организационные полномочия.

Второе: диагностика по языку. Уровень слышен в словах:

Обобщения «всегда/никогда» — самый ранний надёжный маркер того, что вы уже не на первом уровне. Хорошая привычка Scrum-мастера — мягко возвращать к конкретике: «можешь вспомнить последний случай?»

Пять стратегий поведения в конфликте

Модель Томаса — Килманна (TKI) раскладывает поведение по двум осям: насколько человек продавливает свой интерес (напористость) и насколько учитывает чужой (кооперативность).

Ключевая мысль: ни одна стратегия не «правильная». Это ловушка, в которую попадают на экзаменах и в жизни. Избегание уместно, когда вопрос ничтожен, а сил мало. Соперничество уместно, когда речь о безопасности или о нарушении границ. Приспособление уместно, когда вы неправы, — и это признак зрелости, а не слабости.

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

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

Позиции против интересов

Инструмент из гарвардского переговорного метода («Getting to Yes», Фишер и Юри), который в командах работает безотказно.

Позиция — что человек требует. Интерес — зачем ему это.

Классика: разработчик требует выделить целый спринт на рефакторинг, Product Owner категорически против. Позиции несовместимы, спор бесконечен. Вопрос «зачем тебе это?» вскрывает интересы: разработчику надоело, что каждая правка в модуле оплаты ломает три других места и он тратит вечера на разбор инцидентов. Product Owner боится, что спринт без фич обнулит доверие стейкхолдеров, которым он обещал релиз.

Оба интереса законны и не противоречат друг другу. Совместимые решения находятся сразу: чинить модуль оплаты постепенно внутри каждого спринта, встроив это в Definition of Done; или взять один рефакторинг, который выключает 80% инцидентов, вместо целого спринта.

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

Психологическая безопасность как фундамент

Всё вышеописанное работает только при одном условии: люди в команде готовы говорить неприятные вещи вслух. Если не готовы — ваша ретроспектива будет вежливым обменом благодарностями, а настоящие проблемы будут обсуждаться в курилке.

Термин psychological safety ввела Эми Эдмондсон (Harvard Business School) в исследовании 1999 года: это «общее убеждение членов команды, что команда безопасна для межличностного риска». Не «комфортно», не «все милые», а именно: можно сказать «я не понял», «я ошибся», «мне кажется, мы делаем ерунду» — и это не будет стоить репутации.

Проект Google Aristotle проверил это на 180 своих командах и получил результат, который до сих пор цитируют: психологическая безопасность оказалась сильнейшим предиктором эффективности команды — сильнее, чем состав, опыт или наличие звёзд (re:Work, Google).

Как понять, что её нет

Прямо спрашивать бесполезно — на вопрос «у нас безопасно?» в небезопасной команде отвечают «да». Смотрите на поведенческие маркеры:

• на ретроспективе никто не называет проблему, о которой все знают;
• в багтрекере нет багов, заведённых разработчиками на самих себя;
• фразы «я не знаю» и «я ошибся» не звучат месяцами;
• вопросы задают в личке, а не в общем канале;
• после встречи с менеджментом начинается вторая, «настоящая» встреча;
• новичок за два месяца ни разу не сказал, что чего-то не понял.

Последний пункт — самый диагностичный. Новый человек, который за два месяца ни разу не признался в непонимании, либо гений, либо уже усвоил, что здесь так не принято.

Что делает Scrum-мастер

Психологическую безопасность нельзя «внедрить» — она растёт из накопленного опыта: «я рискнул, и ничего плохого не случилось». Что реально работает:

Моделируйте уязвимость сами. «Я не понял, что сейчас обсуждалось, объясните ещё раз» из уст Scrum-мастера стоит больше, чем десять призывов быть открытыми. Признавайте свои ошибки публично и конкретно.

Ловите момент наказания за честность. Кто-то признался, что сломал прод, — и в комнате повисло. Это точка, в которой безопасность либо появляется, либо умирает. Ваша реплика: «отлично, что мы узнали об этом сейчас, а не через неделю. Что нам это говорит о нашем деплое?» Перевод с человека на систему — базовое движение.

Меняйте формат, а не людей. Молчащие на ретроспективе часто молчат не от страха, а от формата: голосовое обсуждение по кругу выгодно экстравертам и старшим по статусу. Письменный сбор пунктов до обсуждения (1-2-4-All из Liberating Structures, silent writing) выравнивает поле мгновенно.

Работайте с менеджментом отдельно. Если руководитель приходит на ретроспективу и разбор «почему мы не успели» превращается в разбор виновных, никакие приёмы фасилитации не помогут. Это разговор один на один за пределами команды — и это часть служения организации из Guide.

Про командную коммуникацию, роли и групповую динамику подробнее — в статье Команда и коммуникация соседнего трека; здесь мы её не дублируем.

Сопротивление изменениям

Теперь самое главное. Всё, что Scrum-мастер делает, — это изменение. И почти каждое встречает сопротивление.

Почему сначала становится хуже

Модель изменений Вирджинии Сатир объясняет то, что новички воспринимают как провал:

Механика простая. Команда живёт в старом статус-кво — не идеальном, но предсказуемом. Появляется чужеродный элемент: новое правило, новый Definition of Done, новый человек, новая метрика. Старые способы работы перестают давать привычный результат, а новые ещё не освоены. Производительность падает.

Это не побочный эффект, а обязательная фаза. И именно в этой яме звучит «видите, стало только хуже, давайте вернём как было». Огромная доля Agile-трансформаций умирает ровно здесь — не потому что изменение было плохим, а потому что откатились на дне.

Из этого следуют два практических вывода.

Первое: провал надо анонсировать заранее. «Первые два-три спринта после введения нового DoD скорость упадёт. Это нормально и означает, что мы делаем всё правильно, а не что мы сломались». Предсказанная просадка воспринимается как признак прогресса; непредсказанная — как доказательство ошибки.

Второе: не запускайте пять изменений одновременно. Каждое даёт свою яму, ямы складываются, дно становится непроходимым. Одно изменение за раз, с явным критерием «мы поймём, что сработало, если…».

Сопротивление — это информация

Стандартная реакция на возражение — переубеждать. Это почти всегда ошибка, потому что за сопротивлением обычно стоит что-то рациональное, чего вы не знаете.

Разберём самые частые ветки.

«Мы уже пробовали, не сработало». Не спорьте. Спросите: «расскажите, как именно пробовали и что случилось». В 90% случаев выяснится, что пробовали другое, или без ключевого условия, или прекратили на дне кривой Сатир. Вы получите бесплатный разбор истории команды, а человек — ощущение, что его услышали, а не переехали.

Скрытая выгода. Тимлид сопротивляется тому, чтобы команда сама распределяла задачи, потому что распределение задач — источник его влияния и видимости для руководства. Это не злодейство: у него реальный интерес, который новый порядок обнуляет. Пока вы не предложите замену (например, роль архитектора или наставника), сопротивление будет вечным и будет маскироваться под технические аргументы. Модель Immunity to Change Кигана и Лейхи (Harvard) описывает это как «конкурирующее обязательство»: человек искренне хочет изменения и одновременно бессознательно защищает что-то, чему это изменение угрожает.

Реальное ограничение. Иногда «у нас так нельзя» — правда. Регуляторные требования, контракт с заказчиком, зависимость от вендора с квартальным релиз-циклом. Scrum-мастер, который упирается в стену из идеологии, теряет доверие. Гораздо сильнее позиция: «понял, это ограничение. Что мы можем изменить внутри него?»

Как проводить изменение

Практический алгоритм, собранный из 8 шагов Коттера и опыта Agile-коучей, адаптированный к масштабу команды:

1. Начните с боли, а не с фреймворка. Не «нам нужен Definition of Done», а «мы третий раз за квартал катим релиз с багом, который находит поддержка. Что с этим делать?» Люди меняются ради своей боли, а не ради вашей правильности.
2. Сделайте проблему видимой, а не рассказывайте о ней. Аргумент проигрывает данным. Повесьте на стену график: сколько задач за спринт возвращалось из «Done» обратно. Ничего не комментируйте. Это работает лучше любой презентации — и это прямое применение принципа прозрачности из эмпиризма.
3. Предложите эксперимент, а не реформу. «Давайте попробуем два спринта и на ретроспективе решим, оставляем или откатываем». Обратимость снимает половину сопротивления: людей пугает не изменение, а необратимость.
4. Найдите союзников до общего обсуждения. Изменение, у которого на встрече есть только один сторонник — вы, — обречено. Поговорите заранее с двумя-тремя людьми, чьё мнение весит.
5. Заранее определите, как поймёте, что сработало. Без этого «попробуем и посмотрим» превращается в спор о впечатлениях.
6. Закрепите результат явно. На ретроспективе после эксперимента: «мы договорились и делаем так. Это теперь наше рабочее соглашение». Изменение, которое не назвали новым нормальным, тихо откатывается за три спринта.

Разбор реальных ситуаций

Теория проверяется сценариями. Разберём четыре, которые встречаются почти в каждой команде.

Сценарий 1. Дейли превратилось в архитектурный спор

Что происходит. Два разработчика на Daily Scrum на десятой минуте уходят в спор о том, класть ли новую логику в существующий сервис или выделять отдельный. Остальные пятеро молча ждут. Так третий день подряд.

Плохая реакция. Прервать и сказать: «Daily Scrum — 15 минут, обсудите после». Формально правильно, по факту — вы отменили важный разговор, не дав ему места. Спор вернётся завтра.

Что делать. Прервать — но с местом для продолжения: «Похоже, это важный разговор, и он больше дейли. Кому он нужен? Вам двоим и Ане? Соберитесь сразу после, 30 минут, я забронирую переговорку». Разница в одном слове: не «не здесь», а «не здесь, а вот здесь».

И вторым слоем — вопрос к команде на ретроспективе: «Мы третью неделю решаем архитектурные вопросы в дейли. Что это нам говорит?» Скорее всего, обнаружится, что архитектурные решения нигде не обсуждаются системно, а уточнение бэклога не покрывает технический дизайн. Это уже реальная проблема, и она чинится изменением процесса, а не одёргиванием людей.

Сценарий 2. Тестировщик молчит на ретро и жалуется в личке

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

Плохая реакция №1. Стать его рупором: самому поднять тему на ретро. Вы решите проблему один раз и закрепите механизм: теперь все несут вам, а вы носите команде. Вы стали каналом связи вместо того, чтобы его чинить.

Плохая реакция №2. Игнорировать: «выноси на ретро сам». Формально верно, но человек уже показал, что не может.

Что делать. Разговор один на один, в коучинговом режиме: «Что произойдёт, если ты скажешь это вслух в четверг?» Обычно всплывает конкретный страх: «Костя скажет, что я тормозлю релиз», «меня в прошлый раз назвали нытиком». Дальше работаете с этим страхом: что самое худшее, что реально случится? что тебе нужно, чтобы стало безопаснее? хочешь, я подстрахую — если разговор пойдёт в переход на личности, я вмешаюсь как фасилитатор?

И параллельно — работа с системой. Проблема-то реальная: работа доезжает до тестирования в последний день. Это классический мини-водопад внутри спринта (разберём в статье об антипаттернах). Её можно сделать видимой без называния имён: показать на ретроспективе диаграмму, когда задачи входили в статус «в тестировании» по дням спринта. График скажет всё сам, и никому не придётся быть обвинителем.

Сценарий 3. Product Owner давит на команду

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

Что говорит Guide. Однозначно: Developers сами определяют, сколько работы взять в спринт. PO не может продавить объём. Но простое цитирование Guide на планировании («по скраму вы не имеете права») редко меняет поведение — оно превращает содержательный конфликт в спор о правилах.

Что делать в моменте. Обозначить границу, но через вопрос о последствиях, а не через ссылку на документ: «Давайте посмотрим на прошлые четыре спринта: сколько историй мы завершали? Пять, четыре, пять, три. Если мы возьмём восемь, что произойдёт в конце спринта?» Числа сделают работу за вас. Это уместный сдвиг влево по континууму — вплоть до прямой директивы, если давление продолжается: правило «объём определяют Developers» не подлежит обсуждению.

Что делать в долгую. Работать с настоящей проблемой, а она не у PO. PO давит, потому что сам зажат обещаниями наверх. Значит, дело в том, как организация планирует и как коммуницирует сроки. Это работа Scrum-мастера с организацией: помочь PO научиться говорить со стейкхолдерами про вероятности и цели, а не про списки фич; показать коммерческому директору Sprint Review, где видно реальный инкремент. Про прогнозирование и метрики — в следующей статье, про ответственности сторон — в статье о трёх ответственностях.

Сценарий 4. «Ретроспективы бесполезны, давайте их отменим»

Что происходит. Команда прямо говорит: ретроспективы — трата часа, всё равно ничего не меняется.

Ключ. Они, скорее всего, правы фактически и неправы в выводе. Если после ретроспективы ничего не менялось полгода, она действительно бесполезна — в том виде, в каком проводится.

Что делать. Не защищать ретроспективу как обязательное событие Scrum (хотя она обязательна — событие Sprint Retrospective не опционально). Сначала согласиться с фактом: «Согласен, за полгода мы приняли 14 решений и выполнили два. Это действительно бесполезно». Согласие обезоруживает — вы перестали быть оппонентом.

Дальше — вопрос: «При каком условии этот час стал бы полезным?» И часто выясняется: решения принимались слишком крупные («улучшим коммуникацию»), без ответственного, без срока, и никогда не проверялись на следующей ретроспективе.

Минимальный ремонт, который почти всегда работает:

• одно улучшение за спринт, а не список из семи;
• у улучшения есть автор и оно живёт в Sprint Backlog как обычная работа, а не в чьей-то голове;
• следующая ретроспектива начинается с проверки предыдущего решения.

Это ровно та работа Scrum-мастера, за которую платят: не «проводить события», а делать их продуктивными — прямая формулировка из Guide.

Вопросы в формате PSM I

Вопросы этой темы на экзамене редко про определения. Обычно это ситуации, где несколько ответов выглядят разумно, и надо выбрать тот, который согласован с идеей самоуправляемой команды.

Вопрос 1. Два разработчика в команде постоянно спорят и не могут договориться о технической реализации. Спор мешает работе. Что должен сделать Scrum-мастер?

• A) Принять решение самому, чтобы разблокировать команду
• B) Передать вопрос Product Owner как владельцу продукта
• C) Эскалировать к функциональному руководителю разработчиков
• D) Коучить команду в том, чтобы она сама разрешила разногласие

Ответ: D.

Разбор. Технические решения — зона Developers (см. распределение ответственностей). Вариант A нарушает самоуправление и делает Scrum-мастера техническим арбитром — роль, которой у него нет. Вариант B неверен: PO отвечает за что и зачем, а не за как. Вариант C — типовая ловушка: эскалация к линейному менеджеру подрывает самоуправление и уместна только при эскалации конфликта на уровень 4–5 по Лизу, чего в условии нет. D соответствует прямой формулировке Guide: «coaching the Scrum Team members in self-management».

Вопрос 2. Команда согласилась на ретроспективе внедрить новую практику. Через два спринта скорость доставки заметно упала, и несколько человек требуют вернуться к старому порядку. Как поступить Scrum-мастеру?

• A) Немедленно откатить изменение — данные показывают, что оно вредит
• B) Настоять на продолжении, потому что решение уже принято командой
• C) Помочь команде на ретроспективе инспектировать результат и решить самой, продолжать ли
• D) Обратиться к менеджменту за решением

Ответ: C.

Разбор. Здесь проверяют понимание эмпиризма: изменение — это эксперимент, а ретроспектива — точка инспекции и адаптации. A подменяет инспекцию рефлексом и игнорирует, что просадка может быть нормальной фазой освоения (кривая Сатир). B превращает Scrum-мастера в надзирателя за исполнением решений. D выносит решение о собственном процессе за пределы команды, что прямо противоречит самоуправлению. C оставляет решение команде и обеспечивает, что оно принимается на основе фактов, а не эмоций.

Вопрос 3. Scrum-мастер замечает, что на Daily Scrum разработчики отчитываются лично ему, а не общаются между собой. Что делать?

• A) Ничего: Daily Scrum — событие Developers, вмешиваться нельзя
• B) Сделать наблюдение видимым для команды и помочь ей изменить формат
• C) Ввести правило «Scrum-мастер не присутствует на Daily Scrum»
• D) Установить обязательный формат «трёх вопросов» из старых версий Guide

Ответ: B.

Разбор. A — ложная недирективность: Scrum-мастер отвечает за то, чтобы события были продуктивными, и обязан назвать наблюдаемую дисфункцию. C — механический приём, который может сработать, но применяется командой, а не назначается Scrum-мастером в одиночку, и не устраняет причину. D неверно вдвойне: в Guide 2020 трёх вопросов нет, а формат Daily Scrum определяют Developers. B соответствует главной механике работы Scrum-мастера: сделать невидимое видимым и вернуть решение команде.

Вопрос 4. Организация внедряет Scrum. Руководитель отдела просит Scrum-мастера еженедельно присылать ему отчёт о том, кто из разработчиков сколько задач закрыл. Как поступить?

• A) Отправлять отчёт: руководитель имеет право на информацию
• B) Отказаться и не обсуждать это дальше
• C) Выяснить, какое решение руководитель принимает на основе этих данных, и предложить прозрачность, которая его действительно закроет
• D) Передать просьбу команде и сделать так, как она решит

Ответ: C.

Разбор. Это про служение организации и про работу с сопротивлением на уровне менеджмента. Индивидуальные метрики производительности разрушают командную работу и психологическую безопасность, поэтому A вредит. B — конфронтация без альтернативы; Scrum-мастер теряет союзника и влияние. D перекладывает организационный разговор на команду. C — правильное движение: за позицией («дайте отчёт») стоит интерес (обычно — «я не понимаю, что происходит, и не могу отвечать за сроки наверх»). Этот интерес закрывается приглашением на Sprint Review и командными метриками потока — а не персональными счётчиками задач.

Как думать на таких вопросах. Три эвристики, которые вытаскивают верный ответ чаще всего:

1. Решение принимает тот, чья это зона. Если в варианте Scrum-мастер решает за команду её работу — почти наверняка неверно.
2. Сначала прозрачность, потом действие. Правильный ответ часто выглядит как «сделать проблему видимой команде», а не «починить».
3. Не эскалировать, пока команда может справиться сама. Эскалация к менеджменту в вопросах PSM I почти всегда дистрактор.

Больше разборов и тактика прохождения — в статье про экзамен PSM I.

Типичные ошибки Scrum-мастера

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

Мини-итог

• Guide про коучинг говорит мало и конкретно: самоуправление и кросс-функциональность. Всё остальное — практика, и её надо уметь отличать от норматива.
• Ключевой навык — не «коучить», а выбирать режим на континууме от директивы до коучинга и возвращаться вправо при первой возможности.
• Коучинг — это техника: открытые вопросы, «что ещё?», слушание уровня II–III и выход на конкретное действие с автором и сроком.
• Конфликт читается по уровню эскалации, а не по громкости. Уровни 1–3 — зона Scrum-мастера, 4–5 — зона организационных решений.
• В споре ищите интересы за позициями: позиции сталкиваются почти всегда, интересы — редко.
• Психологическая безопасность — фундамент всего остального; она растёт из накопленного опыта безнаказанного риска, а не из деклараций.
• Сопротивление — это информация. Провал производительности после изменения — нормальная фаза, которую надо анонсировать заранее, а не пугаться на дне.
• Изменение продвигается через боль команды, видимые данные и обратимые эксперименты, а не через аргументы о правильности.

Источники

• Scrum Guide 2020 — раздел «Scrum Master», формулировки о коучинге и служении
• Lyssa Adkins, «Coaching Agile Teams» — базовая книга по роли Agile-коуча
• John Whitmore, «Coaching for Performance» — модель GROW
• Henry Kimsey-House et al., «Co-Active Coaching» — уровни слушания, мощные вопросы
• Amy Edmondson, The Fearless Organization — психологическая безопасность
• Google re:Work, Understanding Team Effectiveness — проект Aristotle
• Roger Fisher, William Ury, «Getting to Yes» — интересы против позиций
• Thomas-Kilmann Conflict Mode Instrument — пять стратегий поведения в конфликте
• Robert Kegan, Lisa Lahey, «Immunity to Change» — конкурирующие обязательства
• Kotter, 8 Steps — управление изменениями
• Liberating Structures — форматы, выравнивающие участие
• Patrick Lencioni, «The Five Dysfunctions of a Team» — модель командных дисфункций
• Marshall Rosenberg, Nonviolent Communication — язык наблюдений вместо оценок

Что дальше

Мы разобрали работу с людьми — самую субъективную часть ремесла. Следующий шаг — противоположный полюс: цифры. Как команда принимает решения на фактах, что такое velocity и burndown на самом деле, почему их превращают в инструмент давления и как Scrum-мастер этому противостоит.

Эмпиризм и метрики: velocity, burndown и как ими злоупотребляют