Как провести ретро

Ретроспектива: проводим быстро и результативно с помощью 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 и тд
не искать виновных

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

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

Не забывайте мержить карточки с одинаковыми проблемами (а они точно будут), иначе голоса размажутся. В funtretro для этого есть механизм drag’n’drop тикетов

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

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

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

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

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

Типичная ошибка формулировки решения:

Проблема — заказчик недоволен скоростью работы команды

Решение — давайте работать быстрее!

Это не конкретное действие, а лозунг. Не надо так

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

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

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

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

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

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

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

Как провести ретроспективу

Эта статья является для меня шпаргалкой для проведения ретроспективы. Это вдохновитель и конструктор.

Ретроспектива спринта — это возможность для скрам-команды провести инспекцию, направленную на себя, и создать план улучшений командной работы в следующем спринте.

На выходе должно получиться не менее чем одно улучшение, которое, согласно последней редакции Scrumguide, мы берём задачей в следующий спринт.

Максимальная продолжительность Ретроспективы — 3 часа для Спринта длительностью один месяц.

Для двухнедельного спринта ретро будет занимать примерно 1,5 часа.

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

Шаг №1. Создание атмосферы

5% от всего времени. Здесь важно создать хорошее настроение и «включить» всех участников команды в работу.

Термометр. На сколько от 1 до 10 вы довольны прошедшим спринтом.. Рисуем по одному животному или метафору, с которым ассоциируется прошедший спринт, чтобы повеселиться;. Чертим график с «хорошо», «плохо», «нормально» для людей, процесс и технологии. Чтобы понять настроение команды;
Суперсила. Рассказываем «в чём я крут», чтобы перезнакомить новую команду. Вариация: каждый рассказывает какой он супергерой;. Спрашиваем, кто «исследователь», «покупатель», «отпускник» и «узник», чтобы понять ожидания.. Просим участников выбрать число от 1 до 5, которое указывает, насколько они чувствуют себя в безопасности в высказываниях в данной группе.

Шаг №2. Сбор данных

40% от всего времени. Собираем данные о прошедшем спринте: цель, velocity, burndown.

+/Δ. Что было хорошо и что можно было сделать лучше, если это первые ретроспективы у команды;
Glad, Mad, Sad. Расписать события по трём эмоциям, если хочется разнообразия;
Объект в движении. Воздушный шар, кораблик, лодку или гоночный болид с препятствиями и балластами, чтобы пробудить креативное мышление;
Прекратить, Пробуем, Закрепить, Доработать.Клеим стикеры, в каждый из блоков;
Временная шкала спринта. Рисуем график и стикерами каждый клеит события, чтобы построить полную картину;. В основе следующие показатели: "Scrum", "Definition of Done, Stakeholder Management, «Директивность», Return on Investment", "Quality of the Product Backlog", and "Collaboration". Применяем, если «кажется» что все проблемы решены.

Шаг №3. Генерация идей

30% от всего времени. Обязательно следите за временем и используйте таймер.

Brainstorm, когда команда сработана
Пять почему, для комплексных проблем
Метод Уолта Диснея, если очень любим критиковать , если мозговой штурм не удаётся
Матрица идей
World cafe

Шаг №4. Выбор решений

20% от всего времени.

Обсудить и принять решение
Голосовать точками
Голосовать руками
Screening matrix, если очень сложно выбрать. Рисуем матрицу с осями Быстро-Долго, Дёшево-Дорого или Сильный эффект-Слабый эффект;
Молчаливое ранжирование
Потрать 100$

Шаг №5. Закрытие

5% от всего времени.

Проговорить план действий
Спасибки, если было жёстко, чтобы доработать ретро, если не уверен, что формат зашёл
Одно слово
Эмоция

p.s. Рассказываю голосом про ретроспективы

Полезные ссылки

�� Сервис Retromat, который позволят посмотреть примеры на каждый из пяти шагов

�� Сервиc Fun Retrospectives c различными форматами для проведения ретроспектив

�� Видео «Ретроспективы. Настраиваем наш процесс разработки» от Сергея Дмитриева CEO компании Unusial Concepts

�� Видео «Эффективные ретроспективы», от Бориса Вольфсона директор по развитию в HH.ru

�� Статья «Ретроспектива без бубна и танцев», от Ильи Павличенко сооснователя компании AgileX

�� Статья «Как проводить крутые ретроспективы», от Ильи Павличенко сооснователя компании AgiliX

�� Статья «Ретроспектива: как и зачем ее проводить?», от Ирины Цыбденовой экс-ScrumTrek

�� Статья «Первая ретроспектива, от Романа Петрова Agile Coach в Сбербанке

Ретроспектива: как и зачем ее проводить?

Проведение ретроспектив – это активность, которую каждая agile-команда проводит для того, чтобы решать свои проблемы. Что такое ретроспектива? Это регулярная встреча, на которой команда обсуждает свой рабочий процесс и что-то в нем меняет.

Зачем нужна ретроспектива?

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

Основных причин две. Во-первых, если мы приходим к команде с готовыми решениями, возникает феномен, который называется «not invented here». Даже если члены команды понимают, что это правильное решение и его нужно выполнять, у них нет чувства собственности по отношению к нему. Такие решения, не «выстраданные» самим коллективом, а «навязанные» или предложенные сверху, имеют меньше шансов на реализацию.

Во-вторых, сейчас разработка ПО – настолько сложная и запутанная вещь, что вряд ли найдется специалист, который сможет, не зная контекста, расписать, как на самом деле должны работать процессы в конкретной команде при решении определенной задачи. Чтобы это выяснить, надо что-то пробовать, проводить эксперименты, смотреть, к чему приводят те или иные решения. Только попробовав, можно понять, хороша или не очень та или иная практика в контексте данной команды.

Тем не менее, существуют такие вещи как good practice или best practice. Это практики, которые многие используют и которые многим помогают. Возьмем, например, code review: хорошая это практика или плохая? Одним командам она помогает. Другие пытаются ее использовать, и ничего хорошего из этого не выходит. Так происходит потому, что эта конкретная практика, не хороша и не плоха как таковая: ее можно оценить только в контексте конкретной команды и ситуации.

Хотя бы поэтому невозможно сказать заранее, даст она какое-то преимущество или нет. Сode review – это один пример. На самом деле этот эффект характерен для любой практики – никогда нельзя знать заранее, насколько она будет эффективна в той или иной ситуации.

Цели и результаты

В основе ретроспективы лежит концепция цикла Деминга, PDCA (англ. Plan-Do-Check-Act). Цель ретроспективы – к ее окончанию получить план изменений. Но важно понимать, что это не план окончательных изменений в процессе – это план эксперимента на ближайший период. Мы что-то пробуем, а потом смотрим, что из этого вышло, и на основании этого принимаем решение.

Цикл Деминга: Plan – запланируй, Do – выполни, Check – посмотри, что получилось, Act – прими какие-то дальнейшие решения, реши, что дальше делать. Ретроспектива должна проходить именно по этому циклу. Собственно, сама ретроспектива – это стадия Plan.

Ретроспектива, как и любая командная встреча, должна иметь какую-то цель. Цель ретроспективы – получить план процессного эксперимента. Однако многие команды этого не понимают. Например, на ретроспективе команды порой пытаются придумать какие-то глобальные решения своей проблемы, и упираются в то, что у них не получается этого сделать. Они застревают и в итоге вообще ничего не делают. Если команда с такой проблемой сталкивается, то надо ей объяснить, что двигаться надо маленькими шагами, пробуя разные вещи и проверяя, что из этого выходит.

Если команда просто считает, что ретроспектива – это встреча для того, чтобы обсудить свой рабочий процесс и как-то его улучшить, то, как правило, все сводится к тому, что люди приходят, о чем-то разговаривают, выливают свою боль, облегчают душу – в итоге это ни к чему это не приводит. Так происходит потому, что цель не достигнута, план не получен.

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

Что такое действия? Это конкретные задачи с известными исполнителями. Причем если выполнить действие должен тот, кого нет сейчас в комнате, из присутствующих выбирается человек, который берет на себя ответственность объяснить отсутствующему, что и как нужно сделать, а также проконтролировать результат. В итоге за каждое действие отвечает кто-то из присутствующих на ретроспективе.

Какие бывают ретроспективы?

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

ретроспектива в самом общем смысле слова;
ретроспектива по качеству;
ретроспектива по проблемам;
ретроспектива по какому-либо отдельно взятому вопросу.

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

Есть ретроспективы, на которых работа ведется с проблемами, возникающими у заказчика или у владельца продукта. Это третий тип ретроспективы. Четвертый тип – когда есть конкретная специфическая проблема, и ретроспектива посвящается ее решению.

В чем проблема?

Какие в процессе ретроспективы могут возникнуть дисфункции, и как с ними бороться? Вот одна из дисфункций: команда считает, что у нее нет проблем, ее рабочий процесс достаточно хорош, и не видит смысла в его улучшении. Как правило, это не так. Но команде этого просто так не объяснить.

Для того, чтобы сдвинуть коллектив с этой позиции, полезно пригласить на ретроспективу кого-то из стейкхолдеров – заказчика или пользователей, которые знают, что с командой не все в порядке (заказчики вообще очень редко полностью удовлетворены работой команды). Они могут быть удовлетворены до определенной степени, но, как правило, у них все равно есть какие-то мысли на тему того, «что команда могла бы сделать лучше». Если такой заказчик приходит на ретроспективу и рассказывает это команде, ей уже некуда отступать, она начинает обсуждать направления для дальнейшего роста.

Еще одна дисфункция – когда на ретроспективе говорит в основном кто-то один или 2-3 человека, а все остальные сидят и молчат. На самом деле этим людям есть, что сказать. Просто, если все внимание на себя забирает, к примеру, лидер команды, он начинает доминировать, а остальные просто слушают.

Почему это плохо? Если каждый будет открыто высказывать свои мысли, то вероятность найти лучшие решения намного возрастет. Когда мы участвуем в групповой дискуссии, мы друг друга подстегиваем. Это и помогает придумать лучшее решение.

Часто справиться с этой проблемой помогает ведущий (фасилитатор) ретроспективы, который будет следить за тем, чтобы каждый из присутствующих высказал свою точку зрения. Иногда для того, чтобы участники ретроспективы более свободно выражали свое мнение, полезно давать им возможность не высказывать свои соображения вслух, а записывать их на клейких листках (их обычно прикрепляют на стену или специальную доску, причем это могут сделать как сами участники, так и – для пущей «анонимности» – фасилитатор).

Формат ретроспективы: наши предложения

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

Вместо того, чтобы выставлять жесткий тайминг и последовательность действий, мы предлагаем просто расчертить доску на 4 основные области и заполнять ее по ходу обсуждения:

Плюсы. Что шло хорошо в прошлой итерации?
Минусы. Какие проблемы были в прошлой итерации?
Идеи. Какие идеи появились по ходу ретроспективы?
План. Какие улучшения мы запланируем на следующую итерацию?

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

После обсуждения плюсов, минусов и идей команда переходит к составлению плана, куда попадают не просто результаты обсуждения, а (как уже было отмечено) конкретные действия («Выполнить…», «Обсудить…», «Сформировать…») или правила («Задачу Х выполнять с использованием подхода Y»). Не стоит при этом пытаться выработать пути решения всех возможных проблем команды – для эффективной работы на следующей итерации достаточно плана из 3-6 пунктов. Слишком объемный план может в итоге оказаться невыполним и только демотивирует команду.

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