Фасилитация: как вести встречи, чтобы они приносили пользу

Посчитайте: команда из семи человек, двухнедельный спринт. Планирование — 4 часа, дейли — 15 минут × 10, обзор — 2 часа, ретроспектива — 1,5 часа, рефайнмент — ещё пара часов. Итого около 11 часов встреч на человека за спринт, то есть 77 человеко-часов на команду. При средней стоимости часа разработчика это заметная сумма — и это только регулярные события, без разовых обсуждений.

Вопрос не в том, много это или мало. Вопрос в том, что вы получаете за эти 77 часов. Если из планирования команда выходит без общего понимания цели, а из ретроспективы — со списком жалоб, который никто не будет чинить, деньги сожжены. Если из тех же 77 часов выходит согласованный план, снятые риски и одно реально изменённое поведение — это лучшая инвестиция спринта.

Разница между этими двумя исходами почти никогда не в людях. Она в фасилитации.

Зачем это на PSM I. Слово «фасилитация» встречается в Scrum Guide 2020 ровно один раз, и это создаёт две противоположные ловушки. Одни считают, что Scrum-мастер обязан вести все события — это неверно. Другие считают, что фасилитация вообще не его дело — это тоже неверно. Правильная граница проходит по формулировке «ensuring that all Scrum events take place and are positive, productive, and kept within the timebox», и на экзамене её проверяют ситуационными вопросами.

Что ломается без фасилитации

Начнём не с определения, а с симптомов. Вот что происходит со встречей, у которой нет ведущего, — независимо от того, Scrum у вас или нет.

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

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

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

Встреча заканчивается ничем. Времени нет, все расходятся, решение «дообсудим в чате». В чате его не дообсуждают.

Присутствие начальника обнуляет обсуждение. Стоит появиться человеку с формальной властью, и группа перестаёт генерировать варианты — она начинает угадывать нужный. Это явление известно как HiPPO (highest paid person’s opinion).

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

Каждый из этих симптомов — не «плохая команда». Это отсутствующая функция: никто не отвечает за то, как группа думает вместе. Фасилитация и есть эта функция.

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

Что говорит Scrum Guide, а что нет

Здесь нужно быть предельно точным, потому что на экзамене проверяется именно текст.

Написано в Guide. Scrum Master отвечает за эффективность Scrum-команды и служит ей, среди прочего, так:

«Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.»

И отдельно, в списке служения Product Owner:

«Facilitating stakeholder collaboration as requested or needed.»

Это всё. Дословный текст — на scrumguides.org/scrum-guide.html.

Чего в Guide нет. В нём не написано, что Scrum-мастер обязан вести (facilitate) события Scrum. Не написано, что он должен быть в комнате на дейли. Не написано, какие техники применять, как рассаживать людей, нужны ли стикеры. Версия 2020 намеренно убрала прежние формулировки вроде «Scrum Master обеспечивает проведение встречи и понимание её цели участниками» из описаний отдельных событий и оставила один общий пункт в разделе о Scrum-мастере. Это часть общего сжатия документа — подробнее в статье про Scrum Guide построчно.

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

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

Фасилитация против четырёх похожих вещей

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

• Фасилитация — я отвечаю за процесс обсуждения и не имею мнения о содержании. Мой продукт — качественное решение группы, каким бы оно ни было.
• Коучинг — я задаю вопросы, чтобы человек или команда сами нашли ответ. Ответа у меня нет и не должно быть. Про это следующая статья — коучинг и конфликты.
• Обучение (teaching) — у меня есть знание, которого у команды нет: что говорит Scrum Guide, как работает Definition of Done. Здесь я говорю прямо.
• Менторство/консультирование — я делюсь опытом «как я делал в похожей ситуации», но решение остаётся за собеседником.

Практический тест на режим: если у вас есть предпочтительный ответ по содержанию — вы не фасилитируете. Вы можете быть правы, но не можете одновременно быть ведущим и участником спора. Это ключевой принцип нейтральности, к которому мы вернёмся ниже.

Анатомия встречи: пять вопросов до начала

Хорошая встреча спроектирована до того, как люди вошли в комнату. Минимальный чек-лист — пять вопросов, которые в литературе по фасилитации известны как 5P: Purpose, Product, Participants, Process, Pitfalls.

Разберём каждый вопрос предметно.

Purpose. Не «обсудить архитектуру», а «выбрать между двумя вариантами хранилища и зафиксировать выбор». Формулировка цели через глагол принятия решения сразу показывает, встреча это или рассылка. Если цель — «поделиться информацией», встреча почти наверняка не нужна: напишите текст.

Product. Что материально останется после встречи: строка в Sprint Backlog, обновлённая Definition of Done, три пункта в списке действий с именами. Если на этот вопрос нет ответа, встречу нельзя считать состоявшейся ни при каком настроении участников.

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

Process. Это и есть фасилитация в узком смысле. Расписанная последовательность шагов с таймингом: «5 минут молча пишем → 10 минут группируем → 15 минут обсуждаем топ-3 → 5 минут голосуем → 5 минут фиксируем действия». Такой план вы можете показать команде на старте — это одновременно и прозрачность, и способ держать фокус.

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

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

Ромб участия: главная модель фасилитатора

Если запомнить из всей статьи одну вещь — пусть это будет ромб. Модель предложил Сэм Кейнер в книге «Facilitator’s Guide to Participatory Decision-Making», и она описывает форму любого содержательного группового обсуждения.

Зона расхождения (divergent). Задача — набрать варианты. Здесь запрещена критика: любая оценка на этом этапе убивает поток идей, потому что люди начинают фильтровать себя. Инструменты: молчаливая запись, brainwriting, «а как бы это решил кто-то совсем другой».

Зона стона (groan zone). Самая важная и самая недооценённая часть. Идеи собраны, они противоречат друг другу, единой картины нет, люди начинают уставать и раздражаться. Возникает сильнейшее искушение закончить: «ну давайте как Петя предложил». Именно здесь группа строит общее понимание — переводит чужие формулировки в свои, находит, что за разными словами стоит одна и та же боль. Пропустив зону стона, вы получите решение, принятое формально и не выполняемое фактически.

Что делает фасилитатор в зоне стона:

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

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

Типичная ошибка команды — ромб схлопывается в прямую линию: кто-то предлагает решение в первую минуту, все кивают, встреча заканчивается за пятнадцать минут. Все довольны, а качество решения равно качеству мнения одного человека. Быстрая встреча не равно хорошая встреча.

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

Нейтральность: что это на самом деле значит

Фасилитатор нейтрален к содержанию и совсем не нейтрален к процессу. Это разделение стоит проговорить, потому что «нейтральный» часто понимают как «пассивный».

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

Проблема в том, что Scrum-мастер часто не может быть нейтральным. Он видит, что команда собирается сделать глупость, и молчать не хочет. Что делать?

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

Способ 2: передать фасилитацию. Если у вас сильная позиция по вопросу — попросите вести кого-то другого, а сами станьте обычным участником.

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

Отдельно: нейтральность не распространяется на нарушения Scrum. Если команда решает «давайте в этом спринте не будем делать инкремент по DoD», вы обязаны вмешаться — но не как фасилитатор, а как обучающий. Так же как вы не «нейтральны» к тому, что кто-то унижает коллегу. Границы допустимого — не предмет группового решения.

Лестница вмешательства

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

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

Отдельно про первую ступень. Пауза — это техника, а не растерянность. После вопроса группе держите тишину 5–10 секунд, не заполняя её. Большинство людей физически не выдерживают паузу и начинают говорить — в том числе те, кто обычно молчит. Это самый дешёвый способ расширить участие.

Техники: каталог по назначению

Техник фасилитации сотни. Полезно держать в активном арсенале десяток и понимать, под какую задачу что берётся. Хорошая открытая коллекция — Liberating Structures (33 структуры с описанием шагов и таймингов) и retromat.org для ретроспектив.

Разберём ключевые.

1-2-4-All. Универсальная структура: 1 минута молча думаешь сам → 2 минуты обсуждаешь в паре → 4 минуты в четвёрке → выносим общее в круг. Решает главную проблему обсуждений: интроверты и младшие успевают сформулировать мысль в безопасной среде, прежде чем говорить при всех. За 12 минут высказываются все, а не двое. Описание шагов.

Молчаливая запись (silent writing). Перед любым обсуждением — 3–5 минут все пишут свои мысли на стикерах, не разговаривая. Убивает якорение: варианты рождаются независимо. Это, пожалуй, самая высокая отдача на единицу усилия во всей фасилитации.

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

Точечное голосование (dot voting). У каждого N точек (обычно 3), можно ставить на разные пункты или несколько на один. Быстро отделяет топ от хвоста. Осторожно: голосование — инструмент схождения, применять его до того, как группа поняла варианты, — прямой способ выпрыгнуть из зоны стона.

Кулак из пяти (fist of five). По команде все показывают от 0 до 5 пальцев: 5 — «полностью за», 0 — «блокирую». Ценность не в цифре, а в том, что дальше вы спрашиваете тех, кто показал 1–2: «что должно измениться, чтобы стало три?» Так несогласие превращается в конкретное предложение.

Consent вместо консенсуса. Консенсус — «все за», недостижим и съедает время. Consent (из социократии) — «ни у кого нет обоснованного возражения, что это навредит». Планка ниже, а решения крепче: человек, у которого нет возражения, но есть сомнение, не блокирует. Формулировка вопроса важна: не «все согласны?», а «есть ли возражения, из-за которых так делать нельзя?»

Парковка тем (parking lot). Флипчарт или колонка на доске, куда уезжает всё, что не относится к цели встречи. Позволяет прервать человека, не обесценив его: «Отличный вопрос, но не про эту цель — записал в парковку, вернёмся в конце». В конце обязательно вернитесь, иначе парковка станет мусорной корзиной и доверие к ней исчезнет.

Рабочие соглашения (working agreements). Правила, которые команда пишет себе сама: камеры включены, один говорит — остальные не перебивают, опоздание больше 5 минут = встреча идёт без тебя. Ключевое — команда пишет их себе сама, иначе это ваши правила, а не её. Пересматривать раз в несколько спринтов.

ROTI (Return on Time Invested). В конце встречи каждый показывает 1–5: насколько время окупилось. Занимает 30 секунд, даёт метрику качества ваших встреч и — главное — при низких оценках вы задаёте вопрос «что сделать иначе в следующий раз». Про то, как не превратить любую цифру в цель, — в статье про эмпиризм и метрики.

Фасилитация событий Scrum

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

Sprint Planning

Ловушка: превращается в распределение задач по людям вместо выработки цели. Признак — Sprint Goal формулируют в последние две минуты как «сделать всё, что взяли».

Как вести. Разделите планирование на явные части, соответствующие трём темам из Guide: зачем (ценность и цель), что (элементы бэклога), как (план работы). Тайминг объявите вслух. Главное — не давайте перейти к «что» и «как», пока нет чернового ответа на «зачем».

Рабочий приём: попросите Product Owner сформулировать желаемый исход спринта одной фразой до обсуждения элементов, а команду — переписать эту фразу своими словами. Расхождение формулировок вскрывается мгновенно и стоит трёх часов сэкономленных споров.

Признак хорошего планирования: любой участник может назвать Sprint Goal через час после встречи, не глядя в Jira.

Daily Scrum

Ловушка: отчёт руководителю. Каждый по очереди рассказывает, что делал вчера, глядя на Scrum-мастера или тимлида. Скука, 25 минут, нулевая польза.

Как вести. Формально — никак: это встреча Developers, они выбирают формат сами. Ваша работа делается не на дейли. Если вы видите, что дейли деградировало, поднимайте это на ретроспективе как наблюдение, а не чините в моменте.

Что можно предложить команде как эксперимент: «walk the board» — идти не по людям, а по доске справа налево, от самой близкой к готовности задачи. Разговор сразу становится про поток работы, а не про занятость людей. Второй приём — начинать со слов «наша цель спринта — X; что мешает нам её достичь сегодня?»

Разница принципиальна. Если формат дейли починили вы — он развалится, как только вы уйдёте в отпуск. Если формат выбрала команда на ретроспективе — он её.

Sprint Review

Ловушка: превращается в презентацию со слайдами, стейкхолдеры вежливо хлопают, обратной связи нет. Guide прямо предостерегает: Review — рабочая сессия, а не демонстрация.

Как вести. Сократите доклад до минимума, увеличьте долю разговора. Приёмы: дать стейкхолдерам потрогать продукт руками вместо просмотра демо; заранее раздать вопросы, на которые команде нужна обратная связь; вести обсуждение бэклога прямо на встрече, чтобы изменения были видны.

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

Фасилитация Review — единственное место, где Guide прямо употребляет слово facilitating: сотрудничество со стейкхолдерами. Это ваша прямая работа.

Sprint Retrospective

Ловушка: список жалоб без действий, либо наоборот — «всё хорошо» из-за отсутствия безопасности.

Как вести. Классическая структура из книги «Agile Retrospectives» Эстер Дерби и Дианы Ларсен — пять фаз:

Три правила, которые чинят большинство сломанных ретроспектив:

1. Начинать с данных, а не с мнений. Выложите таймлайн спринта: релизы, инциденты, изменения состава, крупные события. Обсуждение фактов уводит от «мне кажется, все ленятся».
2. Выходить максимум с 1–2 действиями. Список из восьми улучшений не будет сделан ни одним пунктом. Одно улучшение, у которого есть владелец и которое можно проверить к следующей ретро, — работает. Кладите его в Sprint Backlog, а не в отдельный документ.
3. Начинать следующую ретро с проверки прошлого действия. Ничто не убивает ретроспективу быстрее, чем ощущение, что решения испаряются.

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

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

Product Backlog Refinement

Формально это не событие Scrum — оно упомянуто как деятельность, а не как отдельный event. Тем не менее рефайнмент часто самая мучительная встреча в календаре.

Ловушка: двухчасовая сессия, где семь человек по очереди слушают, как PO читает описания задач, каждая из которых касается одного-двух из них.

Как вести. Не собирайте всю команду на всё. Работайте малыми группами: пара разработчиков + PO по конкретной области. Ставьте на обсуждение элемента жёсткий таймбокс (например, 10 минут) — не уложились, значит элемент не готов и нужен эксперимент или отдельное исследование. Подробнее про сам процесс уточнения — в статье про бэклог.

Трудные ситуации: разбор сценариев

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

Сценарий 1. Один человек говорит 70% времени. Разбор: не затыкать. Ступень 5 — сменить формат: «Давайте следующие пять минут пишем молча, потом каждый зачитает свой пункт». Структура делает то, что неловко делать словами. Если повторяется из встречи в встречу — разговор один на один вне встречи: «я заметил, что на планировании ты говоришь больше всех; какие идеи, как дать больше места остальным?»

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

Сценарий 3. На дейли пришёл директор и начал раздавать указания. Разбор: в моменте — мягко обозначить рамку, после — разговор наедине. Guide не запрещает присутствие наблюдателей, но дейли принадлежит Developers. Скрипт: «Рад, что зашли. Формат такой: сейчас 15 минут команда синхронизируется по цели спринта, вопросы можно после — я останусь». Дальше отдельная встреча: объяснить, какой эффект даёт его вмешательство и как получать нужную ему информацию иначе (Sprint Review, доска, разговор с PO).

Сценарий 4. Ретроспектива: «у нас всё нормально, просто менеджмент виноват». Разбор: не спорить и не защищать менеджмент. Сузьте фокус до зоны влияния: нарисуйте круги «мы контролируем / мы влияем / вне нашего контроля» и распределите проблемы. Дальше работайте только с первыми двумя кругами. Для третьего ваша работа — вынести наверх как препятствие, что и есть прямая обязанность из Guide (causing the removal of impediments).

Сценарий 5. Команда согласилась с решением, но никто его не выполняет. Разбор: почти наверняка был побег из зоны стона — согласие было формальным. В следующий раз проверяйте согласие явно: кулак из пяти или вопрос про обоснованные возражения. И всегда фиксируйте действие с именем и проверяемым признаком выполнения, а не «мы будем внимательнее».

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

Сценарий 7. Удалённая встреча: камеры выключены, тишина. Разбор: в распределённой команде обычное обсуждение работает хуже, потому что нет невербальных сигналов очереди. Компенсируйте письменной работой: общая доска, где все пишут одновременно, — уравнивает участие лучше, чем любая офисная техника. Явно назначайте очередь («идём по списку сверху вниз»). Сокращайте таймбоксы: два часа в видеозвонке тяжелее двух часов в комнате. И договоритесь про камеры как про рабочее соглашение команды, а не ваше требование.

Как понять, что фасилитация работает

Опасно мерить фасилитацию удовлетворённостью: приятная встреча и полезная встреча — разные вещи. Наблюдаемые признаки полезнее.

Последняя строка первой таблицы — важнейшая. Ваша фасилитация успешна ровно в той мере, в какой она перестала быть нужной. Это неудобный критерий: он означает, что хорошо работающий Scrum-мастер выглядит бездельником на встречах. Именно поэтому в статье про первые 90 дней мы отдельно обсуждаем, как показывать свою ценность организации.

Практический план передачи фасилитации: сначала вы ведёте и вслух объясняете, почему делаете так; потом вы ведёте вместе с добровольцем; потом ведёт он, а вы даёте обратную связь после; потом команда сама назначает ведущего по ротации. Реалистичный срок — 3–6 месяцев, и не для всех событий сразу: дейли уходит первым, ретроспектива — обычно последней, потому что там выше цена ошибки.

Антипаттерны фасилитации

• Фасилитатор с мнением. Ведёте встречу и одновременно продавливаете свой вариант. Даже если вы правы, вы разрушаете доверие к формату: в следующий раз группа будет угадывать, чего вы хотите.
• Игрофикация ради игрофикации. Метафоры, шарики, «нарисуйте команду в виде животного» без связи с целью встречи. Взрослые люди быстро считывают, что их развлекают вместо работы.
• Один формат навсегда. Ретроспектива по одному шаблону год подряд перестаёт давать новую информацию.
• Фасилитация как контроль. Использование структуры, чтобы не дать поднять неудобную тему. Обнаруживается моментально и убивает доверие насовсем.
• Нет фиксации. Отличное обсуждение, все довольны, ничего не записано. Через неделю никто не помнит договорённостей.
• Незаменимый ведущий. Все события ведёте только вы, всегда. Это не сила, а созданная зависимость.
• Фасилитация вместо решения проблемы. Идеально проведённая ретро о том, что команде третий месяц не дают тестовый стенд, не заменяет вашей работы по добыче стенда.

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

Вопрос 1. Согласно Scrum Guide, кто должен фасилитировать события Scrum?

• A. Scrum Master, всегда
• B. Scrum Master для ретроспективы, Product Owner для остальных
• C. Guide не назначает фасилитатора событий; Scrum Master отвечает за то, чтобы события состоялись и были продуктивными
• D. Внешний профессиональный фасилитатор

Вопрос 2. Scrum Master отсутствует и не может прийти на Daily Scrum. Что произойдёт?

• A. Daily Scrum отменяется
• B. Daily Scrum проводит Product Owner
• C. Developers проводят Daily Scrum сами
• D. Daily Scrum переносится на время, когда Scrum Master сможет присутствовать

Вопрос 3. На Sprint Retrospective команда обсуждает проблему, у Scrum-мастера есть сильное мнение о том, как её решать. Как лучше поступить?

• A. Молчать: фасилитатор не имеет права высказываться
• B. Высказать мнение первым, чтобы задать направление
• C. Явно обозначить смену роли, высказаться как участник и вернуться к ведению
• D. Провести голосование между своим вариантом и вариантом команды

Вопрос 4. Sprint Planning идёт третий час из четырёх отведённых, а Sprint Goal всё ещё не сформулирована. Что должен сделать Scrum Master?

• A. Продлить встречу до появления цели
• B. Сформулировать Sprint Goal самостоятельно
• C. Помочь команде и Product Owner сфокусироваться на цели в оставшееся время, а причину разобрать на ретроспективе
• D. Отменить спринт

Вопрос 5. Стейкхолдеры на Sprint Review молчат и не дают обратной связи. Что наиболее уместно?

• A. Отменить будущие Sprint Review как бесполезные
• B. Заменить обсуждение подробной презентацией результатов
• C. Изменить формат так, чтобы стейкхолдеры работали с продуктом и отвечали на конкретные вопросы
• D. Обязать стейкхолдеров письменно комментировать каждый элемент

Вопрос 6. Команда самостоятельно и слаженно проводит все события, Scrum Master почти не вмешивается. Что это означает?

• A. Scrum Master плохо выполняет свою работу
• B. Scrum Master больше не нужен команде ни в каком качестве
• C. Это признак зрелого самоуправления; Scrum Master смещает фокус на организацию и системные препятствия
• D. Команде следует отказаться от Scrum

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

Мини-итог

• Фасилитация — это ответственность за процесс группового мышления, а не за его содержание. Ведущий с мнением по существу — уже не ведущий.
• Guide говорит только одно: Scrum-мастер обеспечивает, чтобы события состоялись, были продуктивными и укладывались в таймбокс. Обязанности вести все встречи в Guide нет.
• Хорошая встреча спроектирована до входа в комнату: цель, материальный результат, участники, процесс по шагам, план на срыв.
• Любое обсуждение имеет форму ромба: расхождение → зона стона → схождение. Большинство плохих решений — это побег из зоны стона.
• Вмешиваться нужно с самой лёгкой ступени: пауза, невербальный сигнал, вопрос, наблюдение, смена формата, жёсткая структура, остановка встречи.
• Техники подбираются под фазу: молчаливая запись и 1-2-4-All для расхождения, кластеризация и «5 почему» для зоны стона, точечное голосование и consent для схождения.
• У каждого события своя ловушка: планирование вырождается в раздачу задач, дейли — в отчёт, обзор — в презентацию, ретро — в список жалоб.
• Ретроспектива выходит максимум с 1–2 действиями, у которых есть владелец и проверяемый признак, и начинается с проверки предыдущего.
• Успех фасилитации измеряется тем, насколько события работают без вас. Передача фасилитации команде — не потеря роли, а её выполнение.
• Нейтральность не распространяется на нарушения Scrum и на безопасность людей: там вы обучаете и вмешиваетесь, а не фасилитируете.

Источники

• The Scrum Guide (scrumguides.org) — первоисточник, версия ноября 2020
• Sam Kaner. Facilitator’s Guide to Participatory Decision-Making — ромб участия, зона стона, работа с групповыми решениями
• Esther Derby, Diana Larsen. Agile Retrospectives — пятифазная структура ретроспективы
• Liberating Structures — 33 структуры фасилитации с пошаговыми инструкциями
• Retromat — генератор форматов ретроспективы, русская версия
• Scrum.org: Professional Scrum Facilitation Skills — официальный курс и глоссарий терминов фасилитации
• Amy Edmondson. Psychological Safety and Learning Behavior in Work Teams — исходная статья про психологическую безопасность
• Sociocracy 3.0: Consent Decision Making — согласие вместо консенсуса
• Методы решения проблем — «5 почему», Исикава и другие аналитические техники
• Команда и коммуникации — модели командной динамики и коммуникации на портале
• Делегирование задач — уровни делегирования, полезные при передаче фасилитации команде

Что дальше

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

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