Ретроспектива: проводим быстро и результативно с помощью funretro

Если ваши ретро не приносят результата, а только тратят время и раздражают команду разработки есть два выхода — отказаться от ретро вообще или сделать нормально. Знакомая боль и выбираете второй вариант? Тогда статья для вас

Советы для проведения продуктивной ретроспективы:

• Используем сервис funretro.io (знаете сервис лучше? — напишите в комментариях)
• Приходим подготовленными
  
• Начинаем с разминки
• Ограничиваем время
  
• Убираем влияние авторитетов
• Убираем перекрестное влияние
• Фокусируемся только на самых важных проблемах
• Формируем задачи с ответственными
• Назначаем точку контроля выполнения действий

Не углубляясь в Scrum/Agile — ретроспективу проводим в конце каждого спринта (так говорит теория) для того чтобы найти боли команды/блокеры в проекте. На практике можно придерживаться более экономичного подхода — проводим, когда чувствуем что нужно/объединяем несколько спринтов в одно ретро (например, ретро раз в 2-3 спринта)

За несколько лет работы в командах разработки я выделил для себя топ-5 болей ретро, которые превращают его из эффективного инструмента в бессмысленную трату времени, демотивирующую команду:

• Зачем это нужно?
• Почему так долго?
• Меня не слушают, высказываться не буду
• Что делать?
  
• Почему ничего не меняется?

Давайте посмотрим как убрать эти боли и начать жить счастливо. В любом деле выбор правильного инструмента — половина успеха, поэтому начнем с него

Google docs/confluence и другие редакторы - привычная среда для большинства. Каждый пишет свои мысли или все говорят — ответственный записывает. В первом случае получаем влияние мнений более опытных членов команды на остальных, во втором — растянутый тайминг и усталость команды.

Trello/Jira - аналогично прошлому, чуть более удобное и привычное восприятие, возможность сразу отправлять задачи в работу

Funretro - сервис создан специально для проведения ретро. Плюсы — решает проблему анонимности, есть механизм голосования, много шаблонов ретро и тд. Из минусов — только 3 доски в бесплатной версии.

Попробовав несколько вариантов, остановился на funretro, он решил почти все боли. Инструмент выбран — начинаем подготовку к ретро

Подготовка — половина успеха в любом деле, ретро не исключение.

• объявите дату и время ретро заранее, оповестите всех участников. Хорошая практика — попросить заранее подумать о вопросах ретроспективы, это сэкономит время команды
• установите контекст ретроспективы — проговорите его в начале и пусть он будет всегда перед глазами. Например — обсуждаем прошлые 2 спринта проекта %Project_name%
• выберите опцию hide cards в настройках — так каждый будет видеть только свои идеи (в тч создатель доски) до момента изменения настройки
• не показывайте автора карточки (Show card’s author) — нам нужно максимально независимое мнение от всех
• установите число голосов на человека. Исходя из личного опыта 3±1 голоса на человека — оптимально
• поставьте таймер — ограничение заставляет думать и очень сильно повышает продуктивность. Для каждого раздела ретро — своя продолжительность

Настроили доску? Стартуем

Расскажите о цели ретро, проговорите базовые правила — говорить/писать честно, не винить в ошибках людей и тд

Первый раздел ретро обычно вызывает самые большие затруднения. Чем он проще, тем быстрее команда включится в работу. Например, это может быть описание спринта/проекта/настроения одним словом. Вообщем что угодно, но очень коротко. Ограничение времени — 1 минута. Ставьте таймер и не давайте выйти за лимит.

Когда время закончилось/все участники отписались — откройте карточки и зачитайте их. Поступайте так в конце каждого раздела ретро

Не забываем озвучивать хорошее, но без фанатизма, 3-4 минуты должно хватить

Сделали, зачитали, обрадовались и поехали дальше, к главным разделам

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

• обеспечить безопасную среду
• не дать забить эфир одному человеку
• не дать влиять на участников команды PO/teamlead/PM и тд
• не искать виновных

Анонимность, самостоятельная работа и установленные в начале правила успешно решают эти задачи

Наверняка проблем будет больше пяти. Вероятней всего все сразу решать не нужно, нет смысла их обсуждать. Приоритизация важна, поэтому голосуем за самые важные проблемы.

Что нам нужно для объективного голосования?

• скрыть число голосов до объявления результатов
• голосовать можно за свои карточки и карточки других
• 1 голос на одну карточку

Когда все проголосовали — выбираем топ-3(±1) проблем и начинаем заключительный этап

Переходим от самостоятельного заполнения тикетов к обсуждению голосом. Поочередно берем проблемы из топа и начинаем искать решение

Важно:

• высказываются все
• задачи распределяются не директивно, каждый сам берет на себя ответственность
• у задачи есть исполнитель
• если к задаче нельзя сформировать критерий приемки — это не задача, нужно менять формулировку
• сформулированные задачи переносятся в таск-трекер проекта (Jira/Trello и тд)
• задачи распределены между участниками команды. Если все задачи достались кому-то одному — у вас что-то не так

Выделите на этот раздел 35-50% процентов всего времени ретро. Он самый важный для достижения результатов и требует повышенного внимания модератора встречи, так как здесь участники общаются голосом, а не самостоятельно заполняют тикеты

Благодарим участников встречи, проговариваем что нужно сделать и примерные даты следующего ретро.

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

• время проведения не превысило времени одного школьного урока (45 минут, в идеале нужно стремиться к 30 при любом размере команды). Человеческое внимание устроено таким образом, что дольше быть сфокусированным на работе без перерыва сложно, продуктивность резко падает.
• все в команде дали фидбэк. Люди разные — кто-то любит болтать, кто-то молчать. Эфирное время при обсуждении решений проблем должно быть распределено относительно равномерно.
• после окончания ретро есть четкие и понятные действия с ответственными. В идеале с дедлайнами (без фанатизма, приоритизация с текущими задачами обязательна)
• к следующему ретро проект стал чуть лучше благодаря вашим действиям

Все перечисленное применялось в проектах, связанных с разработкой, однако ретроспектива — это универсальный инструмент, актуальный в любых проектах

Тратьте время ретро с умом и приносите пользу своей команде

PS если статья получит положительный отклик — я подготовлю аналогичный материал про проведение демо спринта

#ретро #scrum #разработка #agile #менеджмент