Приведите пример ситуации, когда ретроспектива помогла команде решить глубокую проблему

В одной из команд, с которой я работал, в какой-то момент стали регулярно срываться спринты. На дейли участники вежливо отчитывались о проделанной работе, но при этом почти не обсуждали реальные сложности. Атмосфера внешне оставалась спокойной, но по ощущениям что-то было не так — люди перестали открыто взаимодействовать, пропала энергия, начались взаимные недопонимания.

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

Подготовка к ретроспективе

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

Уже на этом этапе стало ясно, что многие испытывают скрытое напряжение. Кто-то чувствовал, что его идеи не слушают. Кто-то боялся признавать ошибки, чтобы не подвести команду. А кто-то просто не понимал приоритетов и терял мотивацию. Всё это не проговаривалось на обычных встречах, но сильно влияло на результат.

Работа с корневой причиной

Мы провели несколько раундов обсуждения, применив технику «5 Why’s». Выяснилось, что ключевая причина — потеря доверия между участниками после серии неудачных релизов. Несколько человек тогда допустили ошибки, и команда, не обсудив это открыто, начала подсознательно избегать ответственности. На дейли стали звучать общие фразы вроде «всё под контролем», хотя на самом деле проблемы копились.

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

Изменения после ретроспективы

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

Спустя два месяца мы провели ещё одну ретроспективу, чтобы оценить прогресс. Команда отметила, что атмосфера стала заметно здоровее. Люди стали брать инициативу, предлагать улучшения, самостоятельно обсуждать приоритеты. Количество незавершённых задач сократилось почти вдвое, а velocity стабилизировался.

Почему это сработало

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

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