Scrum — один из самых популярных фреймворков Agile, но далеко не волшебная палочка. Даже у опытных команд случаются ситуации, когда спринт выходит из-под контроля: планы рушатся, задачи висят мёртвым грузом, а мотивация падает. В такие моменты Scrum Master становится пожарным: нужно быстро локализовать «очаг возгорания» и помочь команде не только выжить, но и вынести уроки.
Согласно исследованию Agile Sherpas, маркетинговые команды чаще всего сталкиваются с тремя типами проблем:
- трудности с незапланированной работой (44%);
- возврат сотрудников к старым, не-Agile-подходам (36%);
- проблемы взаимодействия с командами вне Agile (31%).
Эти вызовы универсальны и характерны не только для маркетинга, но и для IT, продуктовой разработки, госструктур. Давайте разберём три кризисные ситуации, в которые может попасть любая команда, и посмотрим, как их разрешить.
Ситуация 1. Незапланированная работа сжигает спринт
Картина: команда стартовала с чётким планом, но уже на третий день всё идет не так, как задумывалось. Появляются срочные задачи от руководства, «пожары» у смежных подразделений, запросы клиентов. В итоге бэклог спринта раздут, а фокус потерян.
Почему это опасно: незапланированные задачи, если они влияют на текущую работу в спринте, подрывают доверие к Scrum — команда не видит смысла в планировании, если всё равно «живём в пожарном режиме».
Что делать скрам-мастеру?
• Прозрачность: фиксировать все незапланированные задачи в Projectum/Trello/другой доске, чтобы команда и стейкхолдеры видели масштаб «вторжений».
• Разговор с Product Owner: вместе определить правила: сколько незапланированной работы допустимо (например, до 10−15% ёмкости спринта в часах) или в принципе не допустимо. Всё, что сверху, — выносить в отдельный трек или следующую итерацию.
• Дипломатия со стейкхолдерами: объяснять, что каждая «внеочередная» задача имеет цену — откладываются стратегические цели. Здесь важен язык последствий: «Мы можем взять этот срочный отчёт, но тогда задержим запуск рекламной кампании на неделю».
• Ретроспектива: анализировать, почему такие ситуации повторяются: слабое планирование, неопределённые приоритеты, нехватка ресурсов?
• Разговор с Product Owner: вместе определить правила: сколько незапланированной работы допустимо (например, до 10−15% ёмкости спринта в часах) или в принципе не допустимо. Всё, что сверху, — выносить в отдельный трек или следующую итерацию.
• Дипломатия со стейкхолдерами: объяснять, что каждая «внеочередная» задача имеет цену — откладываются стратегические цели. Здесь важен язык последствий: «Мы можем взять этот срочный отчёт, но тогда задержим запуск рекламной кампании на неделю».
• Ретроспектива: анализировать, почему такие ситуации повторяются: слабое планирование, неопределённые приоритеты, нехватка ресурсов?
Вывод: незапланированная работа неизбежна, но она должна быть под контролем. Если её превращать в статистику, команда со временем учится с этим работать.
Ситуация 2. Возврат к старым привычкам
Картина: команда внедрила Scrum, но под давлением стресса возвращается к старым моделям: командирскому стилю, микроменеджменту или привычным «пожарным» совещаниям. Вместо Daily Scrum появляются длинные отчёты, задачи начинают «спускать сверху», а бэклог игнорируется.
Почему это опасно: команда теряет веру в новые практики. Scrum начинает восприниматься как «мода», а не как рабочий инструмент.
Что делать скрам-мастеру?
• Напоминание о ценностях: возвращать команду к принципам Agile (прозрачности, самоорганизации, ценности результата). Иногда достаточно задать простой вопрос: «А помогает ли это нам достичь цели спринта?»
• Фасилитация встреч: если Daily превращается в отчёт руководителю — мягко возвращать формат («Мы говорим не начальнику, а друг другу»).
• Видимые артефакты: доска задач, burn-down диаграмма, Definition of Done — всё это помогает держать команду в Agile-контуре.
• Работа с лидерами: часто именно руководители бессознательно тянут назад. Scrum Master должен быть «переводчиком», показывать им выгоды нового подхода: скорость обратной связи, прозрачность, управляемость.
• Фасилитация встреч: если Daily превращается в отчёт руководителю — мягко возвращать формат («Мы говорим не начальнику, а друг другу»).
• Видимые артефакты: доска задач, burn-down диаграмма, Definition of Done — всё это помогает держать команду в Agile-контуре.
• Работа с лидерами: часто именно руководители бессознательно тянут назад. Scrum Master должен быть «переводчиком», показывать им выгоды нового подхода: скорость обратной связи, прозрачность, управляемость.
Вывод: возврат к старым привычкам — это сигнал, что команда чувствует стресс или не до конца понимает ценность практик. Задача скрам-мастера — мягко удерживать рамку и демонстрировать пользу нового.
Ситуация 3. Конфликт Agile- и не-Agile-команд
Картина: команда по Scrum работает итерациями, но соседние подразделения живут по-старому: линейные планы, жёсткие дедлайны, бюрократические процессы. В итоге Agile-команда упирается в «стену согласований» и не может двигаться с нужной скоростью.
Почему это опасно: внешняя среда превращает гибкость в фикцию. Команда демотивируется: зачем планировать спринты, если всё равно ждём визы от начальства или подрядчика?
Что делать скрам-мастеру?
- Синхронизация: договариваться о регулярных точках контакта. Даже если внешняя команда не Agile, можно встроить её в ритм, например: «Каждый вторник мы уточняем приоритеты».
- Визуализация зависимости: создать карту стейкхолдеров, показывать на общей доске, где мы зависим от других. Когда бизнес видит, что 40% работы блокируется внешними согласованиями, это становится аргументом для изменений.
- Кросс-функциональность: искать возможности включать представителей смежных функций в команду или хотя бы на планирование. Иногда достаточно «встроить» одного эксперта, чтобы снять барьеры.
- Работа на уровне организации: Scrum Master не должен замыкаться на команде. Нужно помогать компании постепенно выстраивать гибридную модель: где-то Scrum, где-то Kanban, где-то упрощённые согласования.
Вывод: Agile-команда редко существует в вакууме. Чем быстрее выстроить мосты к остальным, тем меньше будет срывов и конфликтов.
Итог
Спринт может «встать в огне» по разным причинам: незапланированная работа, откат к старым моделям или конфликт с внешней средой. Но в каждой из этих ситуаций Scrum Master играет ключевую роль — как фасилитатор, дипломат и хранитель процесса.
Кризис в Scrum — это сигнал. Если правильно его интерпретировать, отработать, команда станет сильнее, а процесс — зрелее.
Кризис в Scrum — это сигнал. Если правильно его интерпретировать, отработать, команда станет сильнее, а процесс — зрелее.
Главное правило: не тушить пожар в одиночку. Scrum строится на прозрачности и совместной ответственности. Чем быстрее команда и стейкхолдеры увидят истинные причины, тем легче выпрямить ситуацию.