Все статьи
5 советов по I&A
Дата: 30.06.2020
OK, Вы – RTE или SPC, идёт IP-итерация в конце PI (Program Increment, Инкремент Программы). Вы готовитесь провести воркшоп Inspect & Adapt (I&A) из фреймворка Scaled Agile Framework® (SAFe®), и это вас пугает. Сессия большая и сложная. В ней участвует много людей. Возможно, вы даже сомневаетесь, несёт ли она вообще какую-либо ценность. Поверьте мне – несёт. И я уверяю вас: I&A легче, чем кажется.
Смысл I&A в том, чтобы проинспектировать и продукт, и процесс, чтобы вы могли сделать их лучше уже в предстоящем Инкременте Программы. I&A состоит из трёх частей:
Системная демонстрация PI (PI System Demo) – для инспекции и адаптации продукта.
Количественные измерения – для инспекции процесса по метрикам.
Воркшоп по решению проблем (Problem Solving Workshop) – для адаптации процесса.
Вероятно, вы хотите спросить: почему бы не использовать «обычную» ретроспективу вместо всей этой строгости?
Потому что… чем больше совокупность взаимодействующих между собой людей и технологий, тем больше и сложнее проблемы. Представьте использование ретроспективы в формате Начать/Прекратить/Продолжить для разрешения проблем в сложном конвейере поставки, затрагивающем несколько команд. Скорее всего, вы получите мешанину из мелких идей, которые не решат сложных проблем.
Принцип Безжалостного Улучшения требует от вас более большего вовлечения. Как насчёт нескольких подсказок по I&A, которые вас успокоят?
Совет #1: Сделайте ваш PI System Demo захватывающим с помощью симуляции в режиме реального времени
SAFe предлагает небольшое время в 45-60 минут для PI System Demo. Что обычно делают команды в это время? Быстро демонстрируют свою порцию фич, после чего уступают место для презентации следующей команды. Да, такой стиль демонстрации позволяет каждой команде получить свою порцию признания, но часто вся презентация выглядит неуклюжей и бессвязной (если не сказать… скучной). Может ли PI System Demo выглядеть лучше?
Одна из лучших демонстраций, которые я видел, была пародией, которую поставили Продуктовый Менеджер и Владельцы Продуктов. Перед всеми сотрудниками Agile Release Train (ART) и Представителями Бизнеса уровня вице-президентов они сымитировали телефонный звонок и продемонстрировали решение в том виде, как им на самом деле пользуются клиенты. После сценки от Продуктового Менеджера и Владельцев Продуктов они поблагодарили команды, попросив их встать на поклон зрителям. Люди хлопали и подбадривали – даже вице-президенты! Это стало открытием для всех людей в зале. Такой формат демонстрации впоследствии стал стандартом для всей остальной компании, и я рекомендую вам также перенять его.
Несколько вещей на заметку:
Эта симуляция была спланирована всего за несколько часов (не дней).
Показывали рабочий продукт, а не слайды PowerPoint.
Демонстрация была сфокусирована на решении, а не на командах разработки, поэтому некоторые компонентные команды и команды данных также ощутили свою причастность и ценность.
Совет #2: Сфокусируйтесь на общей картине
Итак, следуя 4 принципу SAFe – Инкрементальные поставки с быстрыми циклами обучения, встроенными в процесс, вы наладили регулярную поставку каждые две недели. Каждые пару недель вы проводите System Demo интегрированного работающего решения для Продуктового Менеджмента и Представителей Бизнеса, которые смотрят и утверждают отдельные фичи, а также обсуждают крайние сценарии использования и способы обработки ошибок. Они беспокоятся о деталях. Так какую ценность вы можете дать им на PI System Demo? Чего они ещё могут не знать?
Как всё это работает вместе! В первой части демо сфокусируйтесь на показе людям общей картине и постарайтесь не увязнуть в деталях. Помните, у вас есть мало времени! Абстрактное мышление позволяет вам быстро решать проблемы вместо того, чтобы застревать в несущественных нюансах. «Мышление по-крупному» – залог вашего успеха.
Несколько вещей на заметку:
По полной используйте «парковку», чтобы сфокусировать людей.
Проводите демо на среде по возможности максимально сходной с промышленной, чтобы убедиться, что решение хорошо интегрировано и выйдет на промышленное окружение с минимальным количеством проблем.
Если ваши среды всё же нестабильны, подумайте над записью видео с демо в качестве подстраховки, а затем заведите одну-две истории для стабилизации сред.
Совет #3: Расскажите историю PI на метриках
Во второй части встречи длительностью 45-60 минут проходит количественная оценка результатов. PI System Demo обеспечил обзор продукта. Теперь время для обзора процесса.
Типичные вопросы после PI: «Как мы справились?», «Попали в свои прогнозы?», «Автоматизация тестов растёт?». Подсказка: сами по себе числа не говорят ничего содержательного. Главное – знать историю, которую рассказывают нам метрики, именно она обеспечивает контекст.
Фраза: «Мы реализовали только 50% обещанного» – значит немного. Часто руководители избегают ответственности и просто обвиняют команды в обмане ожиданий вместо того, чтобы добраться до сути проблемы. Если хотите найти результативные решения, восстановите реальную историю, почему мы сделали лишь половину обещанного.
А вот заявление: «Мы реализовали лишь половину обещанного, потому что работали над слишком большим количеством задач одновременно» – может дать вам серьёзную пищу для размышлений на Problem-Solving Workshop (третья часть I&A). Для RTE – это отличная возможность помочь поезду вырасти!
Несколько вещей на заметку:
Иногда люди беспокоятся, что сессия «Количественные Измерения» вскроет массу плохих новостей. Но ведь если вы качественно проводили другие события SAFe и обеспечили прозрачность, то это уже не новости. Это всего лишь факты.
Более мощно эту секцию может презентовать «тройка» RTE, Продуктового Менеджмента и Архитектора (прим. пер. – в оригинале «troika»).
Если не знаете, какие метрики показать, начните с секции «Метрики Производительности Программы» из статьи Метрики от Scaled Agile Inc. Или попробуйте бесплатный инструмент для оценки зрелости ART от ICON.
Совет #4: Обучите фасилитаторов Problem Solving Workshop заранее
Перейдём к последней части I&A – Problem Solving Workshop. Первый раз использовать инструменты «Диаграмма Исикавы» (прим. пер. – диаграмма «рыбий скелет» или Фишбоун») и «5 Почему» очень тяжело. Наилучшая подготовка – наработка практики их использования и обучение тому же Scrum-мастеров, которые будут помогать вам с фасилитацией.
Почему бы не использовать «Фишбоун» и «5 Почему» на последней ретроспективе команды в PI? Ваши Scrum-мастера учатся фасилитировать ретро, а команды – изучают инструменты. Обычно я собираю Scrum-мастеров для обучения и выравнивания по целям и инструментам примерно на час. После этого мне достаточно просто поддерживать Scrum-мастеров во время ретро. Хорошая подготовка экономит время на освоение самих инструментов и позволяет больше сфокусироваться на решении проблем.
Несколько вещей на заметку:
Бывает сложно сформулировать проблему. Дайте командам несколько примеров, к каким хорошим формулировкам проблем стоит стремиться и каких плохих формулировок стоит избегать.
Формулировки проблем не должны предполагать решения.
Сфокусируйтесь на проблемах, которые они могут контролировать или на которые они могут влиять.
Покажите, к каким финансовым затратам приводит проблема – это реально воодушевляет людей на её решение. Большинство проблем ведут к потерям времени, которые вы можете показать в деньгах, запросив у руководства стоимость команды разработки за день, за спринт и т.д.
Чтобы рассмотреть более подробные предложения и примеры, как лучше провести Problem Solving Workshop, а также примеры хороших/плохихи формулировок проблем, скачайте этот полезный PDF.
Совет #5: Шаблон встречи Inspect & Adapt – ваш помощник!
Если вы – SPC, то у вас есть доступ к SAFe Program Increment Toolkit из секции «Инструменты и Шаблоны» сайта Сообщества. PI Toolkit содержит шаблон встречи Inspect and Adapt в формате PowerPoint со всеми шагами, которые требуется пройти людям в ходе I&A. Он очень, очень полезен!
I&A – это сложная встреча и о ней долго можно говорить, но эти пять советов должны помочь вам начать. А теперь – идите и сделайте ваш поезд лучше!
