Совместная ретроспектива на сотни человек — что такое инспекция и адаптация в SAFe®?

На основе статьи: Inspect and Adapt — Scaled Agile Framework.

Что такое Инспекция и Адаптация?

Инспекция и Адаптация (Inspect and Adapt, I&A) — это крупное мероприятие, которое проводится в конце каждого Инкремента Программы (Program Increment, PI) и позволяет всему Agile Release Train (ART) продемонстрировать и оценить создаваемое Решение. Затем команды формируют бэклог улучшений по результатам рефлексии во время Воркшопа по решению проблем (Problem-Solving Workshop, PSW).

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

Кроме того, SAFe включает в себя «Безжалостное улучшение» (Relentless Improvements) как одну из четырех колонн дома Lean (House of Lean), а также компетенцию «Культуры непрерывного обучения» (Continuous Learning Culture).

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

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

В I&A наряду с командами участвуют все заинтересованные лица ART. Результатом события является список улучшений, которые добавляются в Бэклог Программы для следующего PI-планирования. Это позволяет ART улучшаться каждый Инкремент Программы. Похожее мероприятие проводится и для SAFe Уровня Крупного Решения.

I&A состоит из трех частей:

1. Системная Демонстрация PI (PI System Demo).
2. Оценка качественных и количественных метрик.
3. Ретроспектива и Воркшоп по решению проблем.

Участники должны включать, по возможности, всех людей, которые участвуют в создании Решения. Для ART это:

• Agile-команды.
• Release Train Engineer (RTE).
• Архитекторы/Инженеры Решения и Системные Архитекторы/Инженеры.
• Продуктовый Менеджмент, Представители Бизнеса и другие участники ART.

Также на мероприятии могут присутствовать заинтересованные лица Solution Train.

По моему практическому опыту внедрения SAFe в различных организациях, I&A второе по уровню волшебства мероприятие после PI-планирования. Это невероятный опыт межкомандного взаимодействия, которого так не хватает в крупных организациях. Во многих организациях уже сегодня отстроен уровень подведения итогов спринта и ретроспективный анализ результатов, но как только речь касается взаимодействия вне команды, на этом этапе и возникают основные сложности в части договоренностей и взаимодействия. Инспекция и Адаптация является объединяющим и вовлекающим событием для всего Solution Train. Это встреча, где все заинтересованные лица могут увидеть в цифрах уровень достижения бизнес-показателей и живое демо интегрированных результатов реализации. Особого внимания заслуживает межкомандная ретроспектива, которая дает невероятную ценность межкомандных договоренностей и способов безжалостного улучшения. © Айсылу Абдалова, Магнит

Уверен, что если не проводить I&A, то многие вещи остаются недосказанными и нет понимания, нужны ли какие-то изменения или нет, а если нужны, то какие именно. Все эти сомнения и вопросы накапливаются как напряжение, и участники ART уходят в следующий квартал с багажом нерешенных проблем и невысказанных идей. I&A позволяет выровнять контекст всех участников, а также обсудить и собрать идеи улучшений каждого в единый план действий. © Александр Сайфуранов, Xsolla

Системная демонстрация PI

Системная Демонстрация PI является первой частью Инспекции и Адаптации и немного отличается от обычных системных демонстраций, которые проводятся по результатам каждой итерации тем, что предназначена для демонстрации всех Фич, разработанных в ходе PI.

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

Перед этим или во время демонстрации Представители Бизнеса присваивают значение фактической бизнес-ценности каждой PI-цели команды.

Блок системной демонстрации PI — это презентация для лиц, принимающих решения, поэтому она должна стать впечатляющим шоу о достижениях команды команд. © Сергей Кунцевич, Л’Этуаль

Наше демо проходит за несколько дней до I&A, так как основные заинтересованные лица находятся в другом часовом поясе и у нас есть лишь пара общих слотов времени в течение каждого дня. Не смотря на отход от канонов SAFe, такой способ дает нам больше времени на осознание достигнутых результатов и сбор обратной связи. Во время демо спикер презентует решение, которое стало результатом интеграции инкрементов отдельных продуктов. Если на тот момент уже есть результаты от выхода функционала на рынок, например, сколько новых клиентов привлекли, — обязательно подсвечиваем это. © Александр Сайфуранов, Xsolla

Системную демонстрацию PI проводим аналогично с тем, как проводится системная демонстрация по итогам итерации. Команды демонстрируют интегрированный инкремент. Единственное ключевое отличие в том, что если на системном демо мы показываем всё, на что хотим получить ОС от участников, то на Системной демонстрации PI есть главное правило — показывать только то, что на бою. © Андрей Гирин, РТ Лабс

Мы стартуем I&A сессию c обзора статусов PI-целей и значимых релизов от Скрам-мастеров и Владельцев продукта. После переходим непосредственно к live demo: представители каждой из команд проводят демонстрацию результатов разработки, максимально фокусируясь на бизнес фичах. После live demo переходим к овервью технического долга. © Юлия Дрянцова, Wiley

Обзор качественных и количественных метрик

В этой части I&A команды коллективно анализируют любые количественные и качественные метрики, которые были собраны в ходе Программного Инкремента, а затем обсуждают полученные данные и тренды. В ходе подготовки к этому блоку RTE или Solution Train Engineer (STE) часто отвечают за сбор информации и ее анализ для поиска потенциальных проблем, а во время самого обзора — за фасилитацию презентации результатов.

Одна из основных метрик — это показатель предсказуемости программы. Для определения этой метрики сравниваются планируемая и фактическая бизнес-ценность, доставленная каждой командой. «Надежные» команды должны работать в диапазоне 80-100%, это позволяет бизнесу и внешним заинтересованным лицам проводить планирование с максимальной эффективностью. (Примечание: расширенные цели не учитываются при расчете плановой части, но учитываются при расчете фактической бизнес-ценности).

Благодаря имплементации Flow Metrics в процессы команд отслеживаем и анализируем такие показатели (и их динамику) как Flow time, Flow velocity, Flow efficiency и Predictability за квартал. Интересны причины для всех типов кейсов — и при ухудшении и при улучшении отслеживаемых показателей. В первом случае на этапе ретроспективы формулируются предложения и action points по улучшению, во втором случае — фокусируемся на активностях по сохранению/усилению позитивного тренда. © Юлия Дрянцова, Wiley

В Ак Барс Банке мы разработали шаблон процессных метрик, на которые смотрели в динамике (Velocity, Cycle Time, покрытие тестами, количество багов и уязвимостей, объем технического долга и т.д.), а также отслеживали расширенные продуктовые метрики, которые самостоятельно формировали продуктовые команды под свой продукт и реализуемые фичи, например, конверсию на этапах воронки, количество выданных кредитов в разных каналах (когда фокус был на развитии одного из них), динамику продаж нового карточного продукта, объём льготной ипотеки за период и т.д. В РТ Лабс мы дополнительно отслеживаем тренд объема авральных задач и задач третьей линии поддержки. © Андрей Гирин, РТ Лабс

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

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

Так как l&A-циклы имплементированы и в более краткосрочные каденции команд (Ретроспектива Итерации), результаты последней командной ретроспективы перед I&A-сессией можно использовать как часть пунктов для обсуждения на уровне программы. © Юлия Дрянцова, Wiley

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

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

Во время ретроспективы мы обязательно смотрим на то, какие улучшения мы реализовали за время с предыдущей сессии I&A. При этом важно помнить, что нет необходимости выполнять план улучшений полностью, ведь мы находимся в процессе непрерывного совершенствования и если мы будем пусть немного, но улучшаться, то наши процессы никогда не будут деградировать. © Александр Сайфуранов, Xsolla

Это наша любимая часть сессии — за 1 день до I&A-сессии все участники получают форму для заполнения или ссылку на борд, при этом вопросы от сессии к сессии, а также инструменты сбора мнений меняются. Последний раз, например, формат был следующий: Stop-Start-Continue с использованием Lucid Spark (whiteboard). Обязательно делаем 10-минутный перерыв до старта ретроспективы с воркшопом по решению проблем — для возможности переключиться или заполнить форму/борд тем, кто еще не поделился своим фидбэком. © Юлия Дрянцова, Wiley

Воркшоп по решению проблем

Для решения системных проблем ART проводит структурированный воркшоп по глубокому анализу проблем. Инструменты, которые используются во время воркшопа, позволяют определить исходную причину возникновения проблемы, а не просто устранить симптомы. Фасилитирует сессию обычно RTE, она должна быть ограничена по времени и занимать не более 2 часов.

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

Мы проводим воркшоп по решению проблем по требованию. Результат: оптимизация поставки фич, оптимизация бизнес-процессов функциональных подразделений. © Сергей Лебедев, консультант, руководитель отдела в производственной компании

Каждая команда в процессе обсуждения заполняет Problem Solving Board, который состоит из нескольких частей.

Формирование единого понимания проблемы

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

1. Что? — что за проблема возникла.
2. Где? — где возникла проблема.
3. Когда? — когда возникла проблема.
4. Влияние — какое влияние оказала проблема.

Анализ первопричин

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

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

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

Как только причина выявлена, она исследуется с помощью техники «5 почему». Просто задавая вопрос ‘почему’ несколько раз, команда обнаруживает причину предыдущей причины и добавляет ее на диаграмму. Процесс останавливается, как только будет определена настоящая первопричина, затем тот же процесс применяется к следующей причине. Это позволяет определить цепочку событий, которые привели к возникновению проблемы.

По итогам проведения своего первого воркшопа по решению проблем я признал, что не могу фасилитировать качественную работу с диаграммой Исикавы. С тех пор под воркшоп подбираю другие инструменты. Последнюю сессию в РТ Лабс проводил через связку SWOT/TOWS. В итоге получились отличные результаты. SWOT — очень понятный инструмент, про возможность применения которого в Agile мне напомнили на тренинге от OKR Russia. © Андрей Гирин, РТ Лабс

Определение основной первопричины

Закон Парето, также известный как принцип 80/20, используется для сужения числа действий, которые дают наиболее значительный эффект. На этом этапе команда руководствуется принципом Парето, чтобы определить 20% причин, которые привели к возникновению 80% проблем. Это особенно важно, когда видится множество возможных вариантов, что почти всегда бывает во время работы над сложными системными проблемами.

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

Формулирование новой проблемы

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

Мозговой штурм по поиску решений

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

• Генерируйте как можно больше идей.
• Не допускайте критики или дебатов.
• Позвольте воображению работать на максимум.
• Анализируйте и объединяйте идеи.

Выбор улучшений

Затем участники с помощью голосования выбирают до трех решений. Они будут добавлены в следующее PI-планирование как Истории или Фичи. Во время мероприятия RTE поможет обеспечить планирование работы, необходимой для реализации выявленных улучшений. Это замыкает цикл и гарантирует, что для улучшения текущей ситуации будут приняты необходимые меры.

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

Дополнительные блоки и особенности I&A на практике

Перед рассмотрением общих метрик мы проводим награждение отличившихся ребят и команд в рамках номинаций. © Сергей Кунцевич, Л’Этуаль

Обязательно делаем чек по фидбэку с прошлой сессии, что понравилось и что нужно поменять/улучшить. А также выделяем отдельную часть сессии на овервью по задачам разработки и исследований в рамках Innovation week. © Юлия Дрянцова, Wiley

На текущий момент мы проводим внедрение не по SAFe Implementation Roadmap, а эволюционно. Поэтому все указанные блоки I&A распределены по времени — инспекция и адаптация происходят чаще, чем по фреймворку. Но совокупность условий приводит нас к потребности в полноценном Essential SAFe, с «правильными» событиями, потому что только так происходит настоящая синхронизация поезда по текущему состоянию Решения. © Сергей Лебедев, консультант, руководитель отдела в производственной компании

Ретроспектива на уровне крупного решения

Вышеизложенное описывает подход к решению проблем в контексте одного Agile Release Train. Если ART является частью Solution Train, в мероприятии I&A часто участвуют ключевые заинтересованные лица с уровня Крупного Решения. Однако, для более масштабных потоков создания ценности может потребоваться дополнительное мероприятие Инспекции и Адаптации, которое проводится в том же формате.
Из-за большого количества людей в Solution Train, I&A не может охватить всех, поэтому выбираются заинтересованные лица, которые лучше всего подходят для решения возникающих проблем. Чаще всего это основные заинтересованные лица Solution ART, а также представители различных ART и поставщиков.

Советы по подготовке мероприятия от экспертов

Проведите обязательный тестовый прогон Системной демонстрации PI, преимущества — «бесшовное» переключение между докладчиками, возможность скорректировать сценарий с фокусом на то, что ценно для Представителей Бизнеса. Идеальный день для I&A по нашему опыту — четверг, подготовка стартует за неделю до. © Юлия Дрянцова, Wiley

С целью экономии времени можно расставить все оценки по PI-целям команд заблаговременно. © Сергей Кунцевич, Л’Этуаль

Очень важно, чтобы у ключевых акторов мероприятия (PO, SM, RTE) было одинаковое понимание, что и когда делать, потому что во время проведения I&A очень жесткий тайминг и нет опции выходить из ритма. Для этого в процессе подготовки RTE пишут скрипт мероприятия с таймингом, инпутом, участниками и действиями на каждом этапе. Далее RTE созваниваются, делают тестовый прогон и записывают репетицию встречи для того, чтобы поделиться записью скрипта с PO и SM. С этой же целью мы тщательно организуем рабочее пространство в Miro c указанием времени начала каждого этапа I&A, описанием того, что необходимо здесь сделать, тайм-боксом и подготовленными шаблонами артефактов. © Александр Сайфуранов, Xsolla

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.