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

Более того, если в организации работает профессиональный agile-коуч, то организация может стать быстрой и гибкой через канбан-метод. Просто не резким революционным, а более плавным эволюционным путем. Некоторые организации по-другому не смогут. И даже реальная agile-команда в какой-то момент может временно приостановить продуктовые эксперименты (спринты), и просто начать работать на потоке заказов бизнеса. И тогда она временно станет обычной delivery командой.

Для командной работы над эффективностью поставки тоже нужны ретроспективы. Но проводить их нужно явно не совсем так, как для agile (scrum) команд. Обычно, команда не может быть успешной с помощью scrum-фреймворка из-за неспособности сфокусироваться над решением реальных проблем бизнеса. Так бывает, что заказчик отказывается формировать продуктовую стратегию бизнеса и делегировать ответственность за продукт(ы) в иерархию. При этом разработка ведется на рынок - подавляющее большинство запросов про функционал, которым пользуются клиенты бизнеса (а не его сотрудники). Scrum-фреймворк не работает в таких условиях. Поэтому нужны альтернативы.

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

Конечно, во-многом эти результаты появились благодаря Scrum-фреймворку, но системно их удалось получить именно канбан-методом. И если сравнивать получившуюся систему организации разработки с Scrum-фреймворком, то мы убрали из него несколько ключевых элементов - продукт/инкремент, а также спринт, его бэклог и планирование. Остальное всё осталось и преобразовалось:

• Dev Team - команда разработки.
• Product Owner - представитель заказчика, который отвечал за согласование заказов в потоке поставки. Это не совсем владелец продукта, потому что, как я уже сказал, заказчик не был готов делегировать ответственность за продукт в иерархию бизнеса. Однако, мы оставили название, чтобы не усложнять.
• Kanban Delivery Manager - бывший Scrum Master.
• Бэклог - очередь заказов на поставку.
• PBR - процесс оценки стоимости заказов в бэклоге. Здесь важно отметить, что безуспешное внедрение Scrum-фреймворка в команде дало некоторые позитивные побочные эффекты. В том числе сложный процесс оценки стоимости очень сильно упростился. Раньше это занимало недели и месяцы, теперь же это время сократилось буквально до нескольких часов. Подробнее об этом см. ниже (пропускная способность).
• Daily - бывший Daily Scrum.
• Обзор продукта - митинг, на котором собирались заинтересованные сотрудники из операционки бизнеса (техсаппорт, аккаунт-менеджеры, продавцы, маркетологи и т.д.), чтобы вместе с разработчиками наглядно поиграть с функционалом и пообщаться по части новых (или старых) фич. Этот митинг похож на обзор спринта с той лишь разницей, что эмпирический контроль на нем делается не в отношении спринта, которого собственно нет, а в отношении функционала, который был поставлен или планируется к поставке. Слово "продукт" также было оставлено, чтобы не усложнять переход.
• Ретроспектива - этот митинг тоже очень похож на ретроспективу спринта с той же разницей. На ретроспективе спринта в первую очередь анализируется эффективность цикла снижения рисков бизнеса. Здесь же коллективному анализу подвергается только цикл поставки.

Состав участников

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

Какими бывают неполноценные команды, ценность проведения ретроспективы в которых стремится к нулю:

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

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

В старой версии Scrum-guide (до 2020 года) есть достаточно годное определение delivery-команды под заголовком "The Development Team":

• состоит из профессионалов, которые делают работу по поставке потенциально готовой к релизу функциональности
• имеет все необходимые компетенции, чтобы подготовить релиз от и до
• нет никаких внешних зависимостей в рамках данной поставки (а то бывает, что в команде есть, например, навыки QA, но контроль качества менеджмент по какой-то причине отдал специализированной QA-команде)

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

Фактура для работы

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

Суть, конечно же в том, чтобы измерять эффективность поставки и системно работать над этими показателями. Agile-команды тоже работают над эффективностью, но в отличие от delivery-команд, параметры поставки - не единственные, и не самые главные для них. Нас же интересуют три основных показателя поставки, приоритет по которым мы уточнили у заказчика:

1. Время поставки с точки зрения заказчика (lead time, customer lead time)
2. Качество
3. Пропускная способность (throughput, velocity)

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

Время поставки

Для того, чтобы измерять время с точки зрения заказчика, мы должны отследить два момента:

• Получение заказа от заказчика. Здесь нюанс в том, что заказчик может запихивать в команду больше, чем они могут переварить. Но в идеале это не должно влиять на метрику эффективности. Однако, поскольку для заказчика это время имеет существенное значение, мы фиксировали оба момента: появление заказа в бэклоге + взятие командой обязательств по поставке.
• Готовность к поставке. Дело в том, что заказчик может распорядиться поставлять немедленно по готовности, а может попросить подождать. Это не должно влиять на метрику эффективности. Поэтому в зачет должен идти момент именно готовности, приемки, когда заказчик признает работу выполненной. Через некоторое время заказчик, убедившись, что команда достаточно осознанно относится к его заказам, дал указание всегда делать поставку по готовности и граница между готовностью к поставке и самой поставкой стерлась.

Для сбора фактуры мы использовали тикет-систему kaiten, на которую заводили всю нашу работу. Таким образом, сначала на наших досках в kaiten появлялись два типа карточек:

1. Результат, имеющий хоть какую-то ценность для заказчика. Например, фичи, user story, дефекты, техдолг. Все эти элементы сами по себе есть смысл поставлять, чтобы в IT-инфраструктуре бизнеса что-то изменилось к лучшему. Для простоты, далее по тексту я буду называть все такие карточки заказами.
2. Та часть работ по поставке в рамках заказа, которая может быть сделана какой-то командой или даже одним человеком, но не представляет никакой ценности для заказчика без реализации других частей заказа. Это могут быть архитектурные или функциональные компоненты, либо функциональные работы, которые нуждаются в интеграции между собой в рамках заказа. Далее по тексту я их буду называть задачами.

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

• Доска была единой для всех команд, которые делают один продукт.
• Заказы на ней ехали только по трём спартанским колонкам - todo, in progress, done. In progress - кто-то уже начал работать над фичей. Done - готово к релизу/поставке. Мы не расшивали in progress на подколонки в соответствии с definition of done (далее по тексту - DoD), потому что для заказчика вместе с операционной иерархией это непонятные слова.
• Для отдельного сбора данных по времени получения заказа и взятия ответственности за поставку по нему, мы использовали колонку todo на доске отдельно от бэклога. Таким образом, время фиксировалось при создании карточки в бэклоге и при переводе карточки из бэклога в todo.

У каждой команды по-началу была своя доска для задач. Команда может хотеть свою доску потому, что:

• работает на два и больше продуктов одновременно
• берет несколько заказов параллельно, по каждому из которых делает несколько "своих" задач
• имеет свой стандарт качества для задач (свой DoD, отличный от других команд)

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

Задачи на доске команд едут по колонкам definition of done (DoD) и нуждаются в интеграции между собой в рамках реализации заказа. Позже, когда команды осознали, что большинство коммитов подшивается не в задачи, а в заказы, они вообще отказались от использования "своих" досок. Они пристегнули DoD в виде шаблонного чек-листа ко всем заказам, которые заезжают за точку принятия обязательств (из бэклога продукта на доску с заказами). Это позволило убрать лишнюю бюрократию с карточками.

Таким образом, мы полностью отказались от учета задач и оставили учет только по заказам. Но даже если у вас это не так, то ретроспектива всё равно проводится по данным с учета только заказов (задачи игнорируются или используются опционально при анализе). Для анализа времени поставки в kaiten нам пригодились графики CFD, Lead Time, Spectral Chart (можно заменить на Control Chart) и Cycle Time. В других таск-трекерах вы, вероятно, легко найдете необходимые графики.

Кажется, я ещё не рассказывал про деление доски заказов по дорожкам. У нас там было три дорожки в соответствии с приоритетами обработки заказов:

1. Expedit. Срочные заказы, которые должны обрабатываться вне очереди. У нас это были инциденты с прода, а также заказы, которые product owner классифицировал как срочные (например, когда мы рискуем продолбать внешний дедлайн).
2. Standard. Обычные заказы, которые делаются в плановом режиме, потому что по ним требуется прогнозирование и попадание в SLA. Как правило, это 80% всей работы команды.
3. Slack. Фоновые заказы, которые делаются по остаточному принципу, потому что сроки поставки и SLA по ним не имеют значения для заказчика. Сюда обычно попадал разного рода техдолг и хотелки команды.

Работа с доской была постоянной, спонтанной, однако обязательным был командный ритуал обновления доски раз в день за 15 минут на Daily-митинге. Команда собиралась, кто-то открывал доску на своём (или общем) компьютере и происходил перебор всех карточек на доске заказов справа налево (с конца к началу) и сверху вниз. Порядок перебора важен потому, что чем ближе к поставке находится конкретный заказ, тем больше ценности приносят усилия команды по его движению вперед. Исключением были карточки на дорожке Expedit: если таковые есть, то в первую очередь в разбор идут они, затем все остальные. Поначалу product owner злоупотреблял этой дорожкой и на одной из ретроспектив в эту дорожку был установлен wip-лимит = 1. Постепенно, классы обслуживания (дорожки) снова заработали как положено, и в Expedit очень редко попадало более одной карточки одновременно.

Delivery-менеджер научил команду генерировать/обновлять план по заказу простым вопросом: что нам осталось сделать, чтобы двинуть этот заказ в колонку Done? Ответы команды записывались в карточку в виде пунктов чек-листа. Иногда пункты менялись, удалялись - это нормальный процесс, потому что в разработке очень часто мы не знаем что мы не знаем, когда берем заказ в работу. Со временем, процесс планирования поставки заказа стал таким естественным для команды, что они делали его в среднем за 5-10 минут, а на Daily за 15 минут успевали обновлять до 20 карточек.

Качество

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

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

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

Пропускная способность

Помимо самых важных параметров - времени и качества поставки - заказчик также хочет знать объем поставки за единицу времени - Velocity, ThroughPut (здесь и далее я буду сокращенно писать - TP). Ему это надо для подсчета фактических расходов на поставку и сравнения с плановыми расходами. Почему эта метрика стоит на третьем месте, я уже выше сказал: заказчику нужно в первую очередь выполнять обязательства перед контрагентами в срок и с должным качеством. И уже во вторую очередь заказчику важно знать, насколько финансово эффективно он выполняет эти обязательства. Кроме расходов на разработку у него есть ещё другие расходы на эти обязательства. Однако, все прочие расходы он понимает, как планировать и учитывать, а вот разработка для него - непрозрачная история, которая не поддается традиционным способам контроля и учета.

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

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

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

1. Сначала заказчик общается с аналитиком и дизайнером, чтобы они в несколько итераций нарисовали ему техзадание и макеты.
2. Эти артефакты спускаются разработчикам и QA. Разработчики, как правило, указывают на проблемы, недоработки и двусмысленность требований, из-за чего дизайнер уходит на доработки (а чаще всего разработчиков продавливают делать так, как нарисовано, потому что сроки горят).
3. Затем каждый разработчик и QA уходят на оценку и через некоторое время приносят свою цифру в часах.
4. Product owner накидывает сверху подстраховку и только теперь получает плановые значения по сроку и стоимости своего заказа.

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

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

Проектный менеджмент нужен там, где работы либо совсем не содержат эвристики, либо неопределенность и запутанность может быть устранена за счет up-front анализа перед началом работ (см. cynefin framework, домен complicated). В IT это, например, настройка CMS/LMS или иных no-code систем под запрос заказчика. В разработке такая определенность появляется только при полной готовности к поставке/релизу (см. cone of uncertainty). Но это абсурд - никакой заказчик не захочет тратить весь бюджет только на то, чтобы получить плановые трудозатраты. Поэтому up-front анализ делается на 60-80%, а затем применяется PERT для оценки трудозатрат и принятия решения о запуске разработки, что и приводит к вышеупомянутым последствиям.

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

1. Объединить все роли, которые участвуют в этом процессе в одну единственную - команда разработки. Дизайнер, аналитик, QA - все эти ребята включаются в команду.
2. Заменить метод оценки с PERT по часам на относительные функциональные единицы, попугаи, story points, которые включают в себя все работы по поставке заказа. Здесь и далее я буду писать сокращенно - SP.
3. Дать команде поработать некоторый период времени, чтобы накопить статистику по фактической TP, опираясь на которую, команда может давать оценки. К счастью, это не проблема, потому что самые важные аспекты эффективности (время поставки и качество) лечатся сразу, и заказчик вполне может немного подождать с учетом расходов. Тем более, что грубо он их прекрасно знает - нет ничего сложного в том, чтобы сложить зарплаты всей команды, накинуть повышающий коэффициент (на налоги, офис, кофемашину и т.п.) и разделить на фактические поставки за период.

В результате этих изменений, владелец продукта приносит свой заказ команде на PBR-митинг, команда коллективно уточняет у него необходимые детали, сразу же делает оценку в SP, которую он легко переводит в стоимость и время (благодаря статистике по фактической TP). Это позволяет ему сходить подумать, вернуться с корректировками и попросить сделать оценку повторно, или даже делать такие корректировки сразу же на PBR-митинге. Прямой контакт между представителем заказчика и командой разработки при оценке позволяет им сработаться и быстро делать достаточно точные оценки на заказы большого объема за несколько часов. Более того, разработчики от такого радикального сближения с бизнесом неизбежно начинают разбираться в его специфике, предметке, сходу предлагать какие-то более оптимальные с точки зрения архитектуры решения и в конечном итоге избавляют его от необходимости тратить время на поиск решения - он сразу несет бизнес-проблему, чтобы на PBR-митинге вместе с командой найти самое оптимальное со всех сторон решение.

Надо ли говорить о том, как сильно это влияет на мотивацию команды разработки? Из трех основных нефинансовых мотиваторов (см. AMP/RAMP), такой метод поиска IT-решений и их оценка непосредственно активирует два - Autonomy и Purpose. Это так сильно контрастирует с реалиями проектной организации разработки, что HR-ы и руководители очень редко верят в то, что такое вообще возможно.

Но вернемся к учету расходов. Полученные таким образом оценки в SP заносятся в карточки заказов в бэклоге. Обычно, при оценке заказ обтачивается, видоизменяется и разбивается (не путать с декомпозицей!). Это приводит к размножению заказов, каждый из которых оценивается отдельно. Затем, когда команда берет заказ в работу, kaiten автоматически собирает статистику TP как по карточкам, так и по SP. Поначалу цена SP может сильно плясать от периода к периоду, тем не менее позволяя product owner-у прикидывать стоимость по вилке. По мере целенаправленной работы по эффективности, происходит нормализация потока и цена SP также стабилизируется в некотором вполне приемлимом для достаточно точной оценки даже без вилки.

В результате, открыв график TP за прошедший период, мы можем увидеть как кол-во заказов (и заказиков), так и кол-во SP. Делим совокупные расходы команды на кол-во SP и получаем цену SP, которую product owner и использует для вычисления стоимости заказа при оценке. Глядя в график TP по разным дорожкам (Expedit, Standard, Slack) и типам заказов (Story, Bug, TechDebt, Arch) можно понять, на что сколько денег ушло. Также здесь можно увидеть фокус-фактор команды и прикинуть, какой объем заказов команда скорее всего сможет поставить в течение следующего периода.

Проводим ретро

Очень важно перед началом ретроспективы проговорить цель. Зачем мы тут собираемся потратить время? Цель в том, чтобы повышать эффективность нашей совместной работы по поставке с помощью точечных изменений в организации. Для этого мы измеряем эффективность, ищем системные факторы, которые влияют на неё и придумываем изменения в регламентах и правилах нашей совместной работы. Ретро не предназначено для сбора обратной связи менеджерами (для этого есть 1/1-встречи). Не смотря на то, что у ретро может быть какой-то HR-эффект на атмосферу в коллективе, это именно побочный эффект, а не цель.

Принципы проведения ретроспективы для delivery команды не особо отличаются от принципов проведения ретроспективы спринта:

1. ломаем лёд и создаем атмосферу
2. собираем информацию
3. анализируем собранное
4. генерируем гипотезы улучшений
5. принимаем решения
6. закрываем ретроспективу

Отличие только в том, что на этапе сбора и анализа информации, мы изучаем не цель спринта и её достижение, а целевое и текущее состояние конвейера поставки вместе с командой.

Ломка льда и закрытие ретроспективы не представляют из себя сложности. Достаточно подобрать какую-то подходящую активность. С количеством проведенных ретроспектив появится необходимая насмотренность, чтобы подбор соответствовал ситуации и запросу команды. Поэтому, я не буду тут подробно останавливаться. Советую использовать retromat.ru, там есть из чего выбрать.

Сбор информации - дивергентная фаза

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

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

Можно писать не только негативные, но и позитивные факты. Есть смысл дать им для этого стикеры разных цветов (например, зеленые для достижений, красные - для проблем).

Итак, какие источники и как мы используем для сбора информации:

• CFD. На этой диаграмме хорошо видны изменения потока при настройке WiP-лимитов. Мы этот график вскоре забросили, потому что команда уже была достаточно зрелой, чтобы не брать задач больше, чем они могут сделать - WiP выставили в 3 на in progress на доске заказов и практически никогда в него не упирались.
• Lead time. Общеупотребимое сокращение - LT. Открываем просто для того, чтобы оценить текущее состояние и динамику развития команды. Смотрим LT отдельно по дорожкам Expedit и Standard. Открыли, обрадовались/огорчились, закрыли. Но во время изучения графика у кого-то в команде может появиться идея, вопрос или инсайт. Поэтому тратим минуту времени на изучение.
• ThroughPut. Он же velocity, но чаще velocity считается по спринтам, а у нас спринты отменены и поэтому всё таки лучше TP. Смотрим чтобы понять, какой объем функционала был сделан за период. Сравниваем с предыдущими периодами. Здесь тоже открыли, обрадовались/огорчились, закрыли. Важно помнить, что толку с этого графика в плане эффективности команды никакого нет, потому что TP никак не помогает понять, насколько хорошо команда научилась 10-му принципу Agile (простота, искусство минимизации лишней работы).
• Spectral chart. Позволяет выявить аномалии в процессе поставки. Особенно, если заказы имеют разную оценку. Последовательно открываем списки заказов с конкретной оценкой (например, 1 SP), и ищем среди них "выскочки" - те заказы, которые были поставлены сильно дольше, или сильно быстрее, чем основная масса других с такой же оценкой.
• Control chart. Позволяет контролировать соблюдение SLA. Сразу же показывает, какие заказы и насколько сильно выбиваются по LT - чем выше точка (кластер) на графике, тем дольше поставлялся заказ.
• Cycle time. Показывает среднее время, в течение которого, задачи висят в определенной колонке. Это помогает критически оценить работу конвейера в целом. Насколько адекватное время мы тратим на отдельные пункты DoD? Над какими стоит поработать?
• Инциденты. Здесь мы смотрели статистику с техподдержки, которую приносил старший аккаунт-менеджер. Если там были серьезные проблемы за прошедший период, то мы пропускали этап сбора данных и после ломки льда сразу погружались в анализ. Надо сказать, что в целом очень нелегко было привить немедленный RCA (в виде "5 почему") по инцидентам. Его почти всегда приходилось делать на ретроспективе.

Сбор информации - конвергентная фаза

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

Не отпускайте их, внимательно смотрите за их работой и помогайте правильно формулировать и переформулировать свои записи. Какие бывают проблемные записи:

• Абстрактные формулировки. Например, бардак в джире. Часто они бывают ещё и эмоционально нагружены. Напомните команде, что должны быть только конкретные факты и события, предложите переформулировать запись. Хорошо работает в виде вопроса "В каких конкретных негативных фактах и событиях это проявилось?"
• Скрытые решения. Например, отсутствие CI/CD. Здесь хорошо подходит вопрос "Какую конкретную проблему решает CI/CD?" и дальше по необходимости "Как эта проблема проявилась за прошедший период?"
• Обвинения. Например, QA-инженеры пропустили критичный дефект. Просто напомните цель ретроспективы и предложите обезличить факт, чтобы не уводить дискуссию в неконструктивное русло. Хорошая формулировка "такой-то дефект пролез на прод".

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

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

Анализ - решение - план

Дальше, по каждому пункту списка топиков мы последовательно должны пройти путь: анализ - решение - план. На самом деле, если вы тщательно провели сбор информации, то дальше всё идёт как по маслу. Команда генерирует очень много разных идей, спорит между собой. Здесь важно контролировать несколько моментов:

• Лечим причину, а не следствие. Поскольку вы качественно поработали на этапе сбора информации, команда жаждет как можно скорее порешать все эти проблемы. Однако, важно выявить и убрать причину, иначе эти проблемы будут появляться вновь и вновь в разных формах. То же самое касается и достижений - если не выявить скрытые возможности, их не получится переиспользовать.
• Фокусируемся. Не давайте команде соскочить с выбранной проблемы. А то, почувствовав вкус свободы и радость общения люди в команде часто начинают уходить куда-то в сторону. Здесь вы, как фасилитатор, должны вмешаться и вернуть дискуссию к исходной проблеме.
• Доводим до конкретики. Когда команда нашла решение, у всех наступает радость и облегчение. Все хотят перейти к следующей проблеме или же завершить ретро. Но если их отпустить, то к следующему ретро решение так и не будет опробовано. Для этого нужно распределить ответственных за его внедрение. Конкретные действия, имена и сроки, которые вы фиксируете на видном для всех месте.

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

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

Эмпирический контроль решений

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

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

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