Ретроспектива, после которой ничего не меняется. Почему так происходит и что с этим делать
Ретроспектива в большинстве команд выглядит примерно так. Раз в две недели команда собирается, скрам-мастер открывает Miro или FigJam, все пишут стикеры в три колонки. «Хорошо сделали релиз вовремя». «Плохо опять не успели с тестированием». «Надо улучшить коммуникацию с бэкенд-командой». Стикеры группируются, по самым популярным формулируются action items. На следующей ретроспективе всё повторяется, включая те же action items.
Если эта картина знакома, вы в хорошей компании. По нашему опыту, большинство команд проводят ретроспективы регулярно, но лишь малая часть может сказать, что ретро привело к конкретному изменению в последние три месяца.
Почему ретроспективы становятся ритуалом
Первая причина довольно банальна: action items формулируются слишком абстрактно. «Улучшить коммуникацию» невозможно выполнить, потому что непонятно, что конкретно нужно сделать, кто за это отвечает и как понять, что получилось. Сравните с «Андрей на следующем sprint planning приглашает разработчика из бэкенд-команды для обсуждения зависимостей». Второе можно сделать. Первое можно только обсуждать.
Вторая причина глубже. Многие проблемы, которые всплывают на ретро, лежат за пределами влияния команды. «Согласования занимают слишком долго», «релизный процесс тормозит», «продукт-менеджер меняет приоритеты каждую неделю». Команда обсуждает эти вещи, записывает и… ничего не может с ними сделать. После нескольких таких циклов возникает выученная беспомощность: зачем поднимать проблемы, если от нас ничего не зависит.
Третья причина: безопасность. Настоящие проблемы часто связаны с конкретными людьми, отношениями и конфликтами. Говорить «наш процесс код-ревью неэффективен» гораздо комфортнее, чем «Миша делает ревью формально и это создаёт проблемы для всей команды». Ретроспектива, на которой обсуждаются только «безопасные» темы, может быть приятной, но бесполезной.
Что можно изменить
Разбирать конкретные задачи вместо абстрактных тем. Вместо обсуждения общих впечатлений от спринта команда берёт 3-4 задачи и прослеживает их путь от начала до конца. Где были задержки? Почему? Что зависело от команды? Это превращает ретроспективу из обмена мнениями в анализ фактов, и выводы из такого анализа обычно получаются конкретнее.
Разделять то, что команда может изменить сама, и то, что требует эскалации. Попытка решить на ретро проблему, которая зависит от решений руководства, предсказуемо заканчивается ничем. Полезнее чётко разделить: вот это мы меняем сами на следующей неделе, а вот это формулируем как запрос к менеджменту с данными и аргументами. Cycle time из Jira, показывающий, что задачи 60% времени проводят в ожидании, работает убедительнее, чем «нам мешают согласования».
Ограничить количество action items до одного-двух. Пять action items после каждой ретро гарантируют, что ни один из них не будет выполнен. Один конкретный action item с владельцем и сроком имеет шанс превратиться в реальное изменение.
Проверять action items предыдущей ретро в начале следующей. Это звучит очевидно, но делают это далеко не все команды. Пять минут в начале ретро на вопрос «что стало с тем, о чём мы договорились в прошлый раз» создают accountability и постепенно формируют культуру, при которой ретро воспринимается как инструмент, а не формальность.
Менять формат. Если команда год работает с одним и тем же шаблоном (три колонки, стикеры, голосование), ретро превращается в автопилот. Иногда достаточно сменить формат: timeline ретро, sailboat, четыре L (Liked, Learned, Lacked, Longed for). Новый формат заставляет думать по-другому и иногда вытаскивает темы, которые в привычных рамках просто не поднимаются.
Ретроспективы в командах с AI-инструментами
В 2026 году у ретроспектив появился ещё один слой. Команды, которые используют Cursor, Copilot и другие AI-инструменты, сталкиваются с вопросами, которых раньше просто не существовало. Какие задачи AI ускорил в этом спринте, а какие замедлил? Где AI-код пришлось полностью переписывать и почему? Как это влияет на оценку задач и планирование?
Эти вопросы стоит выносить на ретро, потому что команда часто не осознаёт паттерны использования AI-инструментов, пока не начнёт обсуждать их явно.
Где развивать навыки фасилитации
Проводить ретроспективу, которая приводит к изменениям, заметно сложнее, чем кажется. Это навык фасилитации, работы с групповой динамикой, управления конфликтами. На программе Advanced Scrum Master & Agile Coach эти инструменты разбираются на практике, с реальными кейсами участников. Сертификат ICP-ATF от ICAgile подтверждает эти компетенции.
Для тех, кто хочет начать с основ, базовая программа Certified Agile Professional даёт понимание того, зачем нужны agile-церемонии и как они должны работать в связке. Включая ретроспективу.