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

Почему Trello

Я пользовался большим количеством инструментов, из которых можно выделить основные: Miro - как интерактивный флипчарт, с которым может взаимодействовать вся командa; Google Docs с секциями помапанными на стадии ретроспектив; Confluence (так как все мои проекты пронзены Atlassian-стеком); а также, порой, Jira (вау, это была достаточно плохая идея)!

Я думаю что все пытались нащупать тот самый инструмент, который можно применить фактически в любой области!

И вот я бы выделил основными критериями для проведения Ретро и собирания фидбека о Демо в подобных инструментах:

1. Насколько хорошо оно работает на уровне объектов (во время обсуждений). -> в идеале тут хотелось бы видеть карточки (все таки мы в физическом мире работаем со стикерами) :)

2. Быстрая и эффективная работа с карточками / объектами

3. Подсветка / теги для карточек / объектив (чтоб все могли), не важно как (цвет, тег, еще какая-то штука позволяющая дифференцировать карточки)

4. Перетасовка / изменение порядка карточек / объектов / айтемов

5. Как можно меньшее время, затраченное на следующую последовательность действий: создание секции (списка) -> добавление в него объектов / карточек -> тегирование / подсветка айтемов (членами команды) -> добавление комментария к айтему.

Miro

Я безумно люблю Miro, и постоянно использую его для воркшопов. Но. использовать в ретроспективе и без подготовки этот сервис не настолько просто, насколько хотелось бы (сам сервис функционала предоставляет ого-го, однако ж формат ретроспектив сильно завязан на карточках, работа с которыми в Miro - не самая сильная его сторона). В самой основе, скелете, так сказать, не заложена поддержка карточек как дефолтного варианта, поэтому эту структуру приходится содержать самостоятельно: создавать колоночку, двигать айтемы аккуратно, чтоб оно все относительно ровно стояло. Это тратит время, это не так просто и быстро работает в браузере. Ну и тегирование - тоже не сказать что сильная сторона Miro.

Google Docs

Гуглодоки это дефолтный инструмент для тысяч компаний во всем мире. При этом, как бы не нравилась простота самой платформы, она недостаточно наглядная, если мы хотим работать в ретро на уровне заметок-объектов, которые куда-то потом в идеале надо положить, декомпозировать на самостоятельные сущности, объединенные колонкой.

В этом плане, знаете, даже google sheets казалось бы удобно использовать, как инструмент более подходящий для нашей аналогии двухмерной-классической-ретро-доски (ну как двухмерной, скорее именно с точки зрения того, что у нас есть некие секции с контентом для хорошо/не оч/ улучшить). Но и тут нас поджидает неудобство - drag-n-drop для айтемов, и их линкование друг с другом работает ужасно. Я еще пробовал в свое время google slides, с подходом слайд-для-секции (например перечислить все те великие свершения, в которые мы шмогли с прошлого спринта) - но в итоге менеджить это было сложно, ввиду тяжеловесности решения, ну и на одном таком канвасе могло одновременно ну человека два работать может, не больше. Ну и подсвечивать айтемы там конечно можно, но оно для того не очень приспособлено.

Confluence

Ну вот же confluence, там же целый шаблон для ретро есть! Скажете вы. И будете правы!

Но хорош этот шаблон для документирования/стенографирования, для журнала принятия решений. А нам это в ретро не нужно! Нам нужна живая дискуссия где народ таскает карточки по колонкам, клонирует, обсуждает, помечает!

Более того, Atlassian обычно старается сделать confluence неким легковестным решением, если вас кормят всем их стеком. Но по простоте коллаборации там до gDocs как до луны. Возвращаясь к нашему подходу (ищем блочную структуру для карточек) - confluence неудобен. А еще - нестабилен: с потерей контента и его перезатиранием в режиме коллаборации, отвалом соединения и последующими невозможностями сохранить.

Trello

Ну вот а когда мы подходим к Trello - оно просто поддерживает карточки. И голосовалку для этих карточек с помощью power-up'ов (очень просто). Или через тегирование этого дела цветами (что работает просто и быстро).

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

Короче говоря: trello это самый простой в использовании аналог флипчарта со стикерами :)

Подготовка к самой ретроспективе, и ее начало

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

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

• Общего понимания того, что своё лицо шарить нужно. Поэтому ретро без включенных камер - это как ретро без включения в процесс

• Соединение должно быть отличное! Мы не хотим страдать из-за непонимания (особенно в мультиязычных командах, и нам не нужны лаги

• Подготовиться требуется заранее. Проработанной агендой, или же общими темами, задающими направление. Мы можем предварительно отметить те или иные проблемы, которые хотелось бы подсветить, на онлайн доске во время самого спринта. Все члены команды на ретроспективе должны понимать структуру того как ретроспектива идет, чтобы быть готовыми к набрасыванию в колонки своего фидбека, и понимания что их ждет.

Сама Ретроспектива

В зависимости от зрелости и атмосферы в команде можно использовать Ice Breakers (чтобы настроить на легкое взаимодействие и убрать ощущение обязаловки). Ну и не забудьте проверить как команда чувствует себя после спринта (проверка температуры) - не ждите высокой оценки как данности.

Запланированные улучшения с прошлого спринта

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

Так что мы помечаем получившиеся вещи зеленым (и, в идеале, у нас есть список улучшенных со временем вещей с прошлого, к которому мы можем обращаться). Или же оранжевым (критичные улучшения, которые мы не достигли, но запланировали). Ну или красный (что планировали, но не смогли улучшить за последние два спринта). Позже мы приоритизируем красное (если оно все еще актуально, по прошествии аж двух спринтов) выше всего остального. В целом - пользуйтесь таким цветовым кодированием, которое вам как команде нравится больше.

Это позволяет команде добавить прозрачности в её процессах, а также задать тон саморефлексии для самого события ретроспективы.

Иногда эта стадия может затянуться (планировали улучшение - не смогли достичь - начинаем погружаться слишком сильно в детали почему). Как фасилитатор, ваша задача помочь команде найти продуктивный путь для выявления настоящей причины в достаточно короткий срок (у нас ведь есть таймбокс). Поэтому мы с вами планируем один обязательный пункт улучшения, два уже имеют риск затянуть начало ретроспективы. Также старайтесь просто запарковать это обсуждение на более поздние части ретроспективы - если нужно действительно разобраться. А возможно это даже не относится к ретроспективе как к событию, а надо проводить RCA / Post-Mortem?

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

Цели спринта и метрики

Цели Спринта

Цели спринта это ваш индикатор прозрачности. Достигли ли вы их или нет. При правильном использовании, команда постоянно ориентируется на цели спринта во время каждого события, и поэтому сама должна отлично понимать как она с этой целью справилась. Я считаю что даже если цель обсуждена на Sprint Review, все равно хорошо бы еще раз подсветить причины удачи или неудачи достижения (а это уже непосредственно относится к процессу работы, а значит и к ретроспективе).

Опять же, color-coding предельно простой - зелененький цвет говорит что цель достигнута, красный - нет. Можно добавить комментарий, чтоб дать контекст почему нет или да.

Метрики

Метрики спринта важны и как внутренний-SLA для команды, и как общий индикатор, который в комплексе помогает команде понять динамику.

Обычно команда навскидку придумает с десяток факторов, которые для неё препятствия чтоб быть более эффективной. Если поддерживать ведение такой дискуссии в правильном русле (читай, фасилитировать), и помогать команде наводящими вопросами (читай, коучить), ребята сами соорудят путь к улучшению и как его измерять. Главное чтобы был запрос на улучшение, и была понята сама проблема (нафига оно нам вообще). Еще нюансик: не рассматривайте метрики отдельно друг от друга, и стройте связи между опережающими индикаторами (гипотезами) и запаздывающими индикаторами (результатом). Например, действительно ли увеличение покрытия кода тестами увеличивает уверенность в том, что на проде качество улучшается?

Стандартные метрики, которые я стараюсь использовать:

• Lead Time (время от запроса клиента до поставки)

• Cycle Time (время от начала работы над задачей до поставки). Когда объяснишь на примере донесения ценности до пользователя - как устроен весь пайплайн и где затыки, ребята сами будут мотивированы следить за этими метриками (если, конечно, они у вас общаются с клиентами постоянно),

• Время в Code Review (атож, сколько задача висит и сколько ее проверяют),

• Количество раз тикет был переоткрыт (помогает вместе с определением Definition of Ready),

• Mean Time to Recovery (инцидент-метрика для понимания среднего времени на устранение),

• Bug Escape Rate (сколько багов мы не поймали на тестовых стендах, но поймали после релиза на прод).

В целом все зависит от ситуации, но я считаю Cycle Time и Lead Time тем самым минимумом для всех. Cycle Time в целом дает вам понимание прозрачности и предсказуемости.

Активность на выявление дельты улучшения ~ 'Хорошо-Плохо-Улучшения

Единственное, что как и в локализованных командах, люди в распределенных командах должны "вешать стикеры" с рефлексией заранее, чтоб у всех был контекст. Если таких "стикеров" много - можно организовать голосование, дабы сузить круг обсуждаемого. Не нужно ждать начала самого ретро для сбора обратной связи. Опять же, роль фасилитатора заключается в подсветке конфликтов и проблем когда команда непосредственно с проблемами этими сталкивается. Можно и нужно помогать команде корректно и ёмко отражать саму суть проблемы. Подсвечивать можно по-разному, например отражая что слышишь от команды (я правильно понимаю, что ты имеешь ввиду ....), или беря на себя роль человека, не знакомого с контекстом задачи/проблемы, как-то еще. Самое главное, чтобы команда была вовлечена в процесс инспекции во время самого спринта или каденции, а не только во время ретро.

Собираем фидбек с команды о том, как прошла ретроспектива

Ну а что, нужно же нам знать, насколько плохо мы справились! Я просто прошу оценить ретро по 10-бальной шкале, и назвать одно улучшение, чтобы увидеть дельту.

Референсы и полезности

У Бена Линдерса (Ben Linders) есть хорошая трелло-доска, в которой люди краудсорсят ретроспективные техники для распределенных команд в трелло.

• https://www.benlinders.com/news/trello-board-retrospective-techniques/ Это, наверное, и разговоры с самим Беном, были огромным подспорьем, чтобы написать этот пост.