Как сделать ретроспективу спринта эффективной: советы бизнес-аналитика

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

Из этой статьи вы узнаете, как сделать ретроспективу полезной для команды, проекта и для вас самих.

Ретроспектива – что это?

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

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

Признаки неэффективной ретроспективы

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

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

«Зачем готовиться, все и так понятно!». Иногда может показаться, что достаточно создать таблицу со столбцами «получившегося хорошо», «что плохо» и «что улучшить».

Но именно подготовка помогает решить несколько вызовов:

• Ретроспективы вообще не проходят

На одних проектах их никогда не проводили, на других нет Scrum-методологии (потому что проект продлится несколько месяцев). Кое-где команда не видит смысла в дополнительном анализе процессов. Но бизнес-аналитик должен показать пользу от ретроспектив. Вам следует проанализировать процессы и показать пути их улучшения. Создайте среду для комфортного общения и совместного поиска решений. Станьте инициатором процесса. А это невозможно без подготовки.

• Персональные обвинения

На некоторых проектах ретроспективы переходят в поиск виновных и перекидывании ответственности. Это ложный путь. Цель ретроспективы – обсудить результаты работы, а не самих людей.

• «Scrum не работает»

Когда слышите такую ​​фразу от коллеги, вы должны подготовиться особенно тщательно. Определите, что они вкладывают в эту оценку и стремятся получить от Scrum-методологии. Скорее всего, команда ожидает перемен, которые так и не происходят. Эта проблема может быть не в методе, а в нарушении процессов. К примеру, команда не прописывает Action Items или что-то неправильно внедряет.

• «У нас все и так хорошо»

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

Проведение ретроспективы

Обычно возникает две проблемы, снижающие эффективность встречи:

• Говорят один-два человека

Низкий уровень вовлеченности сказывается на качестве решений. Чтобы вся команда влияла на улучшение процессов, нужно использовать разные форматы и приемы фасилитации. Попробуйте Round-robin, когда один человек говорит вслед за другим, словно перенимает эстафету. Так, каждый участник сможет выговориться и предложить идеи для улучшения процессов и качества работы.

• “У нас все хорошо, а вот они…”

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

Завершение ретроспективы

Даже если прошедшие этапы прошли качественно, все может измениться в финале. Что обычно становится причиной?

• Нет Action Items или они не внедряются

Люди собираются на ретроспективу, все обсуждают, но дальше ничего не делают. Митинг теряет смысл. Поэтому фиксируйте и внедряйте Action Items (подробнее, как это делать, опишу ниже в статье).

• Ничего не меняется

Здесь причин может быть несколько. К примеру, вы неправильно работаете с Action Items или ставите ответственными за действия не соответствующих специалистов. Разберите каждую ситуацию и попытайтесь найти целесообразное решение.

Как подготовиться к ретроспективе — основные шаги

• Цель.  Она задает динамику встречи. До начала митинга вы должны с командой четко определить, зачем собираетесь на обсуждение.
• Участники и продолжительность встречи.  Представим команду, не работающую со Scrum. В этом случае вы приглашаете тех, кого касаются обсуждаемые изменения. Подобный митинг может занять от 1 до 8 часов. Последнее касается больших команд. Для таких обсуждений существует много техник, чтобы все прошло продуктивно. К примеру, объединяясь в малые группы, шанс быть услышанными возникает. Если вы работаете по Scrum-методологии, то участники ретроспектив прописаны в гайде: команда разработки, Scrum-мастер и Product Owner. Подчеркиваю: никаких менеджеров! Они часто хотят прийти на ретроспективу и повлиять на команду. Это нарушение методологии. Продолжительность таких встреч зависит от спринтов. При 4-недельном спринте это до 3 часов. В моих проектах обычно 2-недельные спринты, и ретро длятся до часа.
• Формат.  Классический формат предполагает обсуждение трех тем: что было хорошо, что было плохо, что следует улучшить. На самом деле их множество, но я сосредоточусь на наиболее интересных для меня.

Идеи ретроспективы для недавно сформированных команд

• Одно слово retro.  Участники одним словом описывают прошлый спринт или период времени. Благодаря этому можно легко разговорить людей. Формат отлично подходит для первой ретроспективы на проекте. Такая задача побуждает задуматься над спринтом, попытаться обобщить впечатление и подобрать меткое слово. А это становится основой для содержательного обсуждения.
• DAKI: Drop, Add, Keep, Improve. Эти слова обрисовывают колонки таблицы. В первой участники описывают, что хотят убрать в проекте, во второй — что добавить, в третьей — что продолжить делать, а в последней — что улучшить.
• 3Ls: Liked, Learned, Lacked. Команда должна описать, что ей понравилось, чему она научилась и что хотела бы, чтобы случилось в прошлый спринт. Главный плюс этого формата – нет отрицательной колонки, которую здесь заменяет Learned. Команды фокусируются на положительном подходе. Этот формат пригодится в особо сложном, трудоемком спринте, когда люди могут долго говорить, что было не так.
• Speedcar.  Участники просто перечисляют все, что позволяет двигаться и тормозит проект. Подобно движению машины: что-то ее ускоряет, а что-то останавливает.

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

• Scrum retro. Всем знаком и действительно эффективен формат даже без улучшений, как в других схемах. Вспоминаем, что произошло плохого, что было хорошо и что следует сделать дальше.
• 4Ls. Улучшенный вариант 3Ls, к которому добавилось Longed for. В этой колонке участники описывают, что должно происходить на проекте в будущем. Но для понимания желаемого развития процессов у людей должен быть опыт, в идеале – из других проектов.
• Sailboat.  Это метафорический формат, внутри которого участники должны представить себя на корабле. Кое-что похож на Speedcar, но в дополнение к описанию того, что команду ускоряет (ветер) и тормозит (якорь), следует назвать положительные эмоции (солнце) и риски (рифы). Последнее позволяет подсветить потенциальные проблемы. Люди действительно могут рисовать это в виде парусника и адаптироваться к проекту. В том же Miro найдете много темплейтов под разные цели.
• KALM: Keep, Add, Less, More. В соответствующих колонках укажите: команда хочет продолжать делать; что нужно добавить; чего хочется делать меньше; что команда сделала хорошо.

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

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

Предлагаю организовать процесс в несколько этапов:

• Icebreakers. Когда всем нужно переключиться с будничных тасков на рефлексию. Также требуется высокий уровень эмпатии друг к другу, чтобы обсуждение было комфортным и открытым, без оскорблений. Техник, позволяющих достичь этого, много. Я выбрала 4 простейших Icebreaker:

1. описать одним словом свое настроение — печаль, тревогу, восторг, вдохновение и т.п.;
2. нарисовать, каким животным участник считает себя в спринте;
3. каким напитком человек был человек в предыдущем спринте;
4. happiness radar, по которому участник показывает на шкале уровень счастья или уныния относительно результатов, процессов, команды.

• Проверка предыдущих Action Items. Помните: ретроспективы проходят для изменения к лучшему. Но если вы не проверяете результаты, в какой-то момент люди перестанут выполнять работу над ошибками. Встречи потеряют смысл, и никаких улучшений не произойдет.
• Сбор данных. Если чувствуете неготовность команды к разговору или страх сказать лишнее в присутствии лида, опрашивайте анонимно. Так больше шансов получить реальные мнения. Что касается конкретных примеров, ограничусь двумя, подходящими для любого проекта:

1. Lessons Learned. Хорошо подходит для анализа релиза всего проекта или какой-либо части. Нарисуйте схему со шкалами Успех/Фейл и Плановое/Незапланированное. Наполняете их произошедшими событиями. Это поможет понять, что удалось, что на это повлияло и что не следует дублировать в следующей итерации.
2. Thumbs up. Хорошая техника для больших ретроспектив с подведением итогов в конце проекта или через год. Рисуете квадраты Thumbs up, Thumbs down, New Ideas и Recognition и заполняете их соответствующими данными.

• Поиск решений. После сбора данных нужно подумать, как справиться с выявленными проблемами. Для этого команда генерирует вероятные решения. Техник здесь много: брейншторминг, пять «Почему», диаграмма Ишикавы , упомянутый выше Round-robin. Подробно о каждом методе говорить не буду – это уже темы отдельных статей. Но суть одинакова: предлагать идеи и обсуждать, как они могут улучшить процессы.
• Выбор идей. Не всегда даже хорошую идею можно воплотить в жизнь. Однако любую проблему можно решить несколькими способами. Команда должна рассмотреть возможные варианты реализации различных решений и расставить приоритеты: что более важно, что сделать легче и т.д.

И в заключение…

• Составляем Action Items. Это позволит систематизировать идеи и решения и добавить их в спринт бэклог.
• Определяем ответственных. Action Items должны иметь ответственных за их исполнение. Люди будут вводить эти задачи, а вы сможете отслеживать прогресс.
• Собираем фидбеки. Участники встречи делится, что им понравилось, что нет, чего не хватало. Обмениваются мнениями, как улучшить фасилитацию и т.д.
• Спасибо команде. Не забывайте поблагодарить коллег за то, что они пришли и потратили свое время и силы на ретроспективу. Объясните, как это полезно для них и для дальнейшего развития проекта.

В заключение вспомню цитату из книги «Алиса в стране чудес». По-моему, в контексте ретроспективы этот диалог очень уместен:

– Скажите, пожалуйста, как мне отсюда выйти? – спросила Алиса

– А куда ты хочешь попасть? – ответил Кот.

– Мне без разницы…

– Тогда все равно куда идти.

– Только бы попасть куда-нибудь, – добавила девушка.

– Куда-нибудь ты обязательно попадешь, – сказал кот. — Нужно только достаточно долго уходить.

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

У каждого проекта свои цели. Где-то нужно побыстрее вывести продукт на рынок. Тогда неважные дефекты и покрытия тестами — главными являются быстрая презентация и получение первого фидбека. Или это может быть продукт для медицины, где акцент на уменьшении дефектов до уровня менее 1%. Поэтому и цель ретроспектив будет разной, и фокус обсуждения будет отличаться.

Так что всегда помните о цели. Именно она задает процессы. В самом начале работы определите цель для себя и команды. А когда поймете, куда двигайтесь как бизнес-аналитик и куда ведете команду, вам будет значительно легче достичь цели.