Ретроспектива, после которой ничего не меняется. Что с этим делать
IT-сектор у нас вырос в 18 раз с 2019 года, и вместе с ним выросло количество команд, которые работают по Scrum. Ретроспективы проводят почти все. Результат от них получают немногие.
Типичная ретро в команде, которая работает распределённо между Алматы и Астаной (или с удалёнными участниками в других городах): скрам-мастер открывает Miro, все пишут стикеры, группируют, голосуют. Самые популярные темы попадают в action items. На следующей ретро те же action items переносятся, потому что «не успели» или «зависит от другой команды». Через пару месяцев команда перестаёт воспринимать ретро всерьёз.
Почему ретро превращается в формальность
В распределённых командах, которых у нас становится всё больше, ретроспектива сталкивается с дополнительными барьерами. Люди в Zoom менее склонны поднимать неудобные темы, чем в одной комнате. Молчание в онлайне читается иначе: в офисе видно, что человек думает, в Zoom кажется, что ему всё равно. Скрам-мастер чувствует, что обсуждение буксует, и начинает заполнять паузы сам. Ретро превращается в монолог фасилитатора.
Есть и более фундаментальная проблема. Многие вещи, которые всплывают на ретро, лежат за пределами влияния команды. «Согласования занимают слишком долго», «продукт-менеджер меняет приоритеты каждую неделю», «смежная команда задерживает API». Команда обсуждает эти вещи, записывает и ничего не может с ними сделать. После нескольких таких циклов появляется ощущение, что от ретро пользы нет.
Третий фактор: безопасность. Настоящие проблемы часто связаны с конкретными людьми и отношениями. Обсуждать «процесс код-ревью неэффективен» гораздо комфортнее, чем поднимать вопрос о том, что конкретный человек блокирует работу. Особенно в культуре, где прямая обратная связь коллеге воспринимается болезненно.
Что можно изменить
Разбирать конкретные задачи вместо впечатлений. Команда берёт 3-4 задачи из прошлого спринта и прослеживает их путь от начала до конца. Где были задержки? Почему? Что зависело от команды? Это превращает ретро из обмена мнениями в анализ фактов. В распределённой команде это работает даже лучше, чем классические стикеры, потому что данные из Jira объективны и не зависят от того, кто смелее высказывается.
Разделять то, что команда может изменить, и то, что требует эскалации. Попытка решить на ретро проблему уровня организации предсказуемо заканчивается ничем. Полезнее сформулировать запрос к руководству с данными. Cycle time из Jira, показывающий, что задачи 60% времени проводят в ожидании, работает убедительнее, чем «нам мешают согласования».
Один action item вместо пяти. Пять action items после каждой ретро гарантируют, что ни один из них не будет выполнен. Один конкретный, с владельцем и сроком, имеет реальный шанс.
Начинать ретро с проверки предыдущих договорённостей. Пять минут на вопрос «что стало с тем, о чём мы договорились в прошлый раз» формируют культуру, при которой ретро воспринимается как инструмент, а не как ритуал.
Менять формат. Если команда год работает с одним и тем же шаблоном, ретро превращается в автопилот. Timeline, sailboat, четыре L. Новый формат заставляет думать по-другому и вытаскивает темы, которые в привычных рамках просто не возникают.
Где развивать навыки фасилитации
Проводить ретроспективу, которая приводит к изменениям, заметно сложнее, чем кажется. Особенно в распределённых командах, где фасилитатор работает через экран. На программе Advanced Scrum Master & Agile Coach эти инструменты разбираются на практике. Сертификат ICP-ATF от ICAgile подтверждает компетенции и работает у нас и за рубежом.
Базовая программа Certified Agile Professional даёт понимание того, зачем нужны agile-церемонии и как они работают в связке. Тренинги проходят в Zoom, время удобно для Алматы и Астаны.