Обзор спринта и Демонстрация инкремента итерации: что делать и не делать

О Sprint Review и демонстрациях в целом я писал во вводной статье. Здесь речь пойдёт не о “Sprint Review by Scrum”, а в целом об обзорах, которые команды проводят в конце итерации или супер-итерации (Program Increment, супер-спринт, квартал). Не считая сотни демонстраций, на которых я присутствовал, в этой статье использованы заметки с обратной связью после 27 обзоров.

Наблюдения и комментарии сгруппированы в разделы:

1. Вводная часть
2. Формат и культура
3. Живая демонстрация
4. Обратная связь — самое важное на обзоре
5. Слайды
6. Ретро на демо
7. Подготовка
8. Больше демо, чем статус
9. Больше отчёт-статус, чем демонстрация

А затем будут детально рассмотрены следующие темы:

1. Почему так важно, чтобы в конце итерации был инкремент
2. Разве можно не готовиться к демонстрации?
3. Почему так важно, чтобы на демо была обратная связь от стейкхолдеров
4. Демонстрация нескольких команд
5. Инкремента и хорошего Sprint Review нет, но вы стремитесь
6. Самоопросник после демонстрации

Наблюдения и комментарии

Вводная часть

🟢 Вводное слово: повестка, формат взаимодействия, время на вопросы.

🟢 Обсуждено достижение цели спринта. Демонстрация организована вокруг прогресса в достижении цели итерации.

🔴 Обсуждение цели спринта занимает 20 минут.

🟢 Перед демонстрацией функциоала звучит короткий рассказ о клиентском пути по схеме. 🟡 Схема большая, детали мелкие, их трудно разобрать даже на экране ПК.

🟢 О метриках и NPS.

Формат и культура

🟢 Цель, план-факт, живая демонстрация, планы на будущее.

🔴 Обзор спринта проводится нерегулярно. — Проводить в конце каждого спринта, хотя бы 20–30 минут.

🟢 Все с включенными камерами. Или хотя бы спикеры.

🟢 Участники команд вовлечены — помогают спикеру.

🟢 Встреча командная, а не “для начальника”.

🟢 Уложиться в тайминг. Закончить не позднее, чем обещали.

🟡 Спикерам не откашливаться, особенно на видео-звонке.

🟢 Вводные и заключительные слова, благодарности командам, признание заслуг. Это хороший показатель взаимоотношений в коллективе. 🟡 Однако в меру — не превращать в показную похвалу.

🟢 Позитивно и доброжелательно, иногда с юмором, неформальное общение — хороший индикатор климата в командах.

🟡 Иногда просто обсуждение между несколькими людьми, без схем, экранов и видео. На встрече 27 человек. Вопрос: интересно ли другим.

Живая демонстрация

🔴 Чтение “по бумажке”. Тараторство. — 🟢 Лучше рассказывать своими словами, чтобы получалось поживее и естественнее.

🟡 При показе было непонятно, куда и зачем человек что-то листает молча. Какой функционал показывает? Что пользователь сможет сделать?

🟢 Демонстрация функционала приложения с комментариями своих действий.

Обратная связь — самое важное на обзоре

🔴 Нет обратной связи, вопросов и комментариев. Это один из самых распространённых недостатков демонстраций. Возможно, причина неподходящем составе заинтересованных лиц. (Подробнее читайте ниже в детальном разборе в § “Почему так важно, чтобы на демо была обратная связь от стейкхолдеров”.)

🟢 Звучит призыв ведущего в адрес заинтересованных лиц дать ОС.

🟢 Диалоги с гостями, задаются вопросы, даются ответы.

🟢 Дана ОС, были разъяснения, дискуссия, вопросы о функционале.

🟡 При эмоциональных отзывах приглашённых заинтересованных лиц не вступать в противостояние. (Кто такие “заинтересованные лица”.)

🟡 Пользователям и представителям бизнеса, с их слов, трудно воспринимать технические детали. — 🟢 Сделать меньше технической части, больше демонстрации внешнего поведения, ценности для клиента/пользователя.

Слайды

🟡 Если есть слайды, то только для вступления, плана, заключения и задания структуры встречи. Слайды — не инкремент, не результат вашей работы (конечно, если ваш продукт не заключается в создании слайдов).

🟡 Непонятно, что готово и будет показано, а что “на этапе 2.б.34”.

🟢 На самой встрече: вот план (и там только то, что может быть завершено в спринте), вот что мы сделали, вот это мы покажем, а вот здесь посыпаем голову пеплом и обсудим на ретроспективе.

🟡 Формулировки на слайдах непонятны — сложный канцелярский язык.

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

Ретро на демо

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

🟡 “В ходе спринта опять в плане спринта всё поменялось. Пришёл [имя], попросил…”️ — это тема для ретроспективы.

Подготовка

🔴 Не хватает чёткости. Пример:
— Кто следующий? Команда 2? Показывать что-то будете? Ау!
— Ну, мы можем посмотреть, что улучшилось.

🟢 Решить, кто будет демонстрировать, кто будет комментировать.

🟡 “Макс, можно следующий слайд?” — 🟢 Либо Макс внимательно следит и вовремя перелистывает, либо спикер листает сам.

🟢 Проверить доступность площадок, приложений, смежных систем.

🟢 Убедиться, что имеются тестовые данные.

🔴 “Произошли проблемы со стендом и на ходу меняли последовательность демо.” — 🟢 Подготовить план Б. Иметь возможность переключиться, если на какой-то площадке не работает.

🟡 “Мы будем дважды репетировать и, скорее всего, поменяем спикеров с разработчиков на аналитиков, чтобы были более простые слова для понимания.” — Подготовку нужно свести к минимуму. В контексте одной команды — до минут. Чтобы это стало возможно, доводите задачи до состония Done.

Больше демо, чем статус

🟢 Демонстрируется новый реальный функционал. Ещё лучше, если соответствующий Definition of Done. (Подробнее читайте ниже в детальном разборе в § “Почему так важно, чтобы в конце итерации был инкремент.”)

🟢 По возможности больше показывать. “На портале выложили вебинар” — покажите, где он красиво лежит, хотя бы на скрине, а лучше по боевой ссылке.

🟡 “Сегодня мы не покажем…” — 🟢 хорошие демо те, на которых демонстрируется готовый результат, потому что в этом случае, 1) сами демонстрации перестанут быть отчётными слайдами, 2) команды научатся завершать работу, а не копить набор из десятка задач готовых на 99%.

🟡 “Демонстрация будет проведена на моках.” Это уже хорошо тем, что честно и открыто. Для большей прозрачности, стоит 🟢 указывать, в какой готовности по DoD находится демонстрируемый функционал, на какой площадке развёрнут, когда окажется в промышленной среде.

Больше отчёт-статус, чем демонстрация

🔴 “А у нас ещё тестировщики не рассказали.” И дальше рассказ тестировщиков. Участники завершают рассказ словами “У меня всё.” Похоже на синхронизацию, как дэйли, только biweekly. Выглядит, как серия индивидуальных отчётов и мини-демонстраций проделанной работы каждого участника.

🔴 Демонстрируются наработки сотрудников, не инкремент команды. — Стремиться 🟢 на демо показывать то, что DoD-готово. Не просто “мы знаем, что это нужно, но пока не можем” (на самом деле обычно это означает “не очень хотим”), а реально стремиться.

🟡 “Мы в этом спринте подобавляли поля. Подключились. Начало падать, поэтому мы немного отложили эту задачу.” — Возможно, команда делает не то, что нужно и важно, а то, что проще и удобнее.

🔴 “Проведен ряд встреч…” — это процесс, информация о том, что “есть работа, и она работается”. Обычно такие детали неинтересны участникам.

🔴 “Начать разработку…” — эту задачу можно выполнить за несколько минут — просто начать.

🔴 “Разработка…, системный анализ…” — это внутренние процессы. Они говорят только о приближении к результату, но не о самом результате.

🟡 Результаты не сопоставляются с планами. Рассказывается о том, что было сделано, но непонятно, что было запланировано. Другими словами, что “не было сделано” и “что незапланированное было сделано”.

🔴 На слайде “Результаты итерации” показан весь план, и он на 100% выполнен? Или это только то, что готово? Если второе, то это уловка, ведь выглядит будто бы 100% done.

🔴 Несколько строк начинаются с такой или подобой фразы: “Продолжаются работы по подключению функционала…” — в этих 5 словах нет сути задачи. У таких статусных формулировок обычно есть три назначения:

1. Чтобы задействованные смежные подразделения понимали, к какому времени им нужно подготовить свою часть, и подготовили её. Это более-менее хороший вариант.
2. Чтобы кто-то видел, что есть какой-то прогресс с каким-то темпом.
3. Чтобы кто-то видел, что люди заняты чем-то вроде бы полезным.

🟡 Если у вас осознанно больше статус-синхронизация, а не демо, то 🟢 лучше идти по задачам, а не по людям. Идти от плана, сопоставлять результаты с ним: что должно быть готово к концу итерации, что готово, что нет. “Вот это план на эти спринты, а вот что мы реально довели до DoD”.

Согласно Скраму на Обзоре спринта не показывается то, что не достигло состояния DoD. Однако, поскольку команды всё равно будут показывать “хоть что-то”, и вдобавок ещё и много разного рассказывать, то форматом честного слайда будет такой:

🟡 На слайде в одном списке вперемежку и встречи, и артефакты, и функции, и задачи, и подзадачи, и технические задачи, и процессные (согласования, доступы), в разных статусах и разной гранулярности. 🟢 Вести повествование от ожидаемых результатов и функционала → к задачам. Больше ориентации на результат, не на промежуточные этапы. Вместо “У нас есть работа, и мы её работаем” формулировать в формате

ожидаемый результат + статус + срок.

Перефоразируйте так: “Функция Абв” и рядом статус “В процессе, срок ГГГГ.ММ.ДД.” В этом случае ваш отчёт хотя бы будет 🟢 вокруг ценности, которую вы поставите, но не сегодня. Однако, по-прежнему, это внутренние детали вашей команды, а готового функционала вы не показываете, и поэтому непонятно, нужны ли эти детали участникам демонстрации.

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

🟢 Начинайте с задач, которые пойдут на прод, потому что 1) нужно всячески стараться фокусировать команду на поставке итоговой ценности. 2) Поставка — цель, к которой вы стремитесь, а аналитика — лишь подэтап для задач, которые будут сделаны в следующих итерациях. 3) Если стейкхолдер может лишь ненадолго зайти на демонстрацию, то за первые 15–30 минут увидит результат, отключится от встречи, а команда продолжит подведение итогов.

🟢 Получение доступов, типовые этапы по площадкам, типовые интеграции → добавьте в DoD.

🟡 У разных команд разный формат отчёта, слайды отличаются по структуре → их сложно воспринимать → вероятно, в этот момент гости не слушают. Если всем заинтересованным лицам понятно, то ОК. Если непонятно, то лучше, когда 🟢 формат отчёта выровненный, одинаково структурированный.

Детальный разбор некоторых ситуаций

Далее будут рассмотрены следующие темы:

1. Почему так важно, чтобы в конце итерации был инкремент?
2. Разве можно не готовиться к демонстрации?
3. Почему так важно, чтобы на демо была обратная связь от стейкхолдеров?
4. Демонстрация нескольких команд
5. Инкремента и хорошего Sprint Review нет, но вы стремитесь
6. Самоопросник после демонстрации

Почему так важно, чтобы в конце итерации был инкремент

чтобы в конце каждого спринта у команды был potentially releasable increment. Этот принцип позволяет: 1) поставлять ценность раньше, 2) получать новые знания, 3) каждые две недели иметь доработанную рабочую версию продукта, 4) снижать технические риски и зависимости, 5) всегда поставлять и быть молодцами. (О других плюсах и подробнее читайте здесь.)

Разве можно НЕ готовиться к демонстрации?

Нужно! И можно. Ну, почти.

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

1. Регулярные обзоры стринтов команды. Их не нужно репетировать. Это не означает, что и готовиться не нужно; однако подготовка не должна занимать времени больше, чем сама встреча. Более того, здесь есть важный момент, связанный со зрелостью команды и её процесса разработки. К моменту демонстрации и даже раньше элементы бэклога должны быть “готовыми” — в состоянии Done. Обычно это помимо прочего подразумевает, что функционал работоспособен на pre-prod — в среде, приближенной к промышленной, и что бэклог в актуальном состоянии. И поэтому подготовка будет заключаться в выборе ведущего и, возможно, в создании простого слайда с элементами плана итерации и указании статуса “Done/нет”.
2. Большие отчётно-статусные встречи. У вас ведь такие есть, правда? Буквоеды с криками “это не по Скраму!” могут пойти почитать книги Кена Швабера и увидеть, что автор Скрама пишет о коммуникациях со стейкхолдерами. Однако и здесь применимы аргументы, перечисленные выше: доводите задачи до состояния Done и сводите подготовку к минимуму.

Почему так важно, чтобы на демо была обратная связь от стейкхолдеров?

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

На последних демонстрациях перестала звучать ОС от ЗЛ.

Предположение: на демонстрацию приходят те, кому нечего сказать, и не приходят те, кто может дать ОС.

ОС — самое важное в демонстрации.

Чтобы исправить ситуацию:

1. Проанализируйте список приглашённых: 1) от кого нужна ОС на демо, 2) все ли нужные люди были приглашены, 3) приняли ли они приглашение, 3) если не приходят, то спросить о причинах персонально 1–1, и индивидуально пригласить их, пояснив, почему их мнение важно для вас, 4) после демонстрации инкремента задать им адресные вопросы: вместо “У кого какие есть какие вопросы?” спросите “Александр, Мария, Иван, что думаете о показанном функционале?”
2. По интонациям можно понять, всё ли ОК с коммуникацией. Если не ОК, то будет полезно повторить упражнение по выявлению стейкхолдеров и их ожиданий. И на уровне команды, и на уровне команды-команд. (Как создать карту заинересованных лиц и план работы с ними.)
3. Если матрица заинтересованных сторон уже создана, то провести её анализ, выявить тех, которые будут давать ОС на демонстрации, обновить матрицу, приглашать их, проанализировать результаты через 2–3 демонстрации.

Демонстрация нескольких команд

🟡 Некоторые команды демонстрируют новый функционал, а другие нет. При общей демонстрации нескольких команд проще “затеряться”, и при этом в целом встреча проходит нормально, просто демонстрируются результаты других команд.

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

I. Создать повестку с расписанием, например, по 15 минут на команду. Добавить в приглашение, чтобы ЗЛ могли подключаться к нужному времени, а не на всю встречу. Стараться следовать повестке:

1. Не выходить за лимит времени.
2. Если команда завершает раньше и остается 5 минут перед следующей командой, то заполнить эту пустоту буферными вопросами заранее подготовленными как раз для таких случаев. Например, рассказать о целях и метриках команды, показать бэклог на ближайшие 2–3 спринта или квартал, показать и обсудить зависимости, показать и обсудить риски, представить участников команды, рассказать об аналитике рынка (даже если она была проведена не в ближайшем спринте).

II. В рамках лимита времени на команду проанализировать, какие пункты повестки действительно интересны приглашенным ЗЛ, а какие включены просто по привычке, “потому что можем рассказать”, “потому что всегда так делаем.” Например,

1. рассказ о плане на спринт и под-статусах задач, которые не в состоянии DoD, дополнительные детали и нюансы длинных административных и технических задач;
2. демонстрация реально работающего функционала (самое важное);
3. рассказ о будущих задачах не в разрезе функций (зачем-то).

🟢 Попросите команды проводить командные демо, без объединения в общую встречу. Иногда заходите на демо команд без предупреждения, чтобы посмотреть, что демонстрируют команды. Цель — постепенно добиться, чтобы в конце каждого спринта у команды был potentially releasable increment.

Инкремента и хорошего Sprint Review нет, но вы стремитесь

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

Приемлемым промежуточным вариантом станет постепенное сокращение количества колонок до 3 штук:

• название задачи/story,
• DoR: да/нет,
• DoD: да/нет.

Вариант хуже, но всё же приближающий вас к предыдущему — 6 столбцов, подэтапов DoD. Ещё более промежуточных вариантов не дожно быть — система бинарная: либо готово, либо нет.

• Серое — задачи предыдущих спринтов.
• Желтое — план на этот спринт.

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

“Аналитика готова” =

• Сделано один;
• Оформено два;
• Согласовано три;
• И т.д.

“Дизайн готов” = [аналогично в виде checklist].

Аналитика готова + Дизайн готов = DoR. (Это пример, у вас может быть по-другому.)

“Разработка выполнена” = [аналогично в виде checklist].

“Тестирование выполнено”= [аналогично в виде checklist].

“Фича готова” =

• Здесь такой же чеклист того, что должно быть сделано после “Тестирование выполнено”, чтобы фунционал оказался на проде. Это нужно, чтобы 1) было понятно, что означает слово “сделано” — интегрировано ли, на какой площадке, включено ли, были ли первые транзакции и т.п., 2) понятнее и однозначнее планировать работу.

Разработка выполнена + Тестирование выполнено + Фича готова” = DoD. (Это пример, у вас может быть по-другому.)

Самоопросник после демонстрации

• Как вам слайды, количество букв?
• Как вам выступления спикеров, было интересно слушать или мыслями отключались?
• Как вам организация передачи слова и переключение между спикерами?
• Как вам демонстрации функционала, хватило ли, интересно ли? Подходит для приглашённой аудитории?
• Что в следующей демо можно сделать чуточку лучше?
• Что удалось, получилось хорошо?
• Демонстрацию инкремента команды проводится каждые 2 недели.
• Демонстрация максимально наглядна, состоит из законченных сценариев использования: от появления проблемы/задачи до её решения.
• Интеграции реализованы до начала демонстрации.
• Тестовые данные готовы и приближены к реальным.
• На демонстрации получена обратная связь. (О её важности см. выше.)

Дополнительные статьи по упомянутым темам

1. Карта заинтересованных сторон и план работы с ними
2. Стейкхолдеры, stakeholders, заинтересованные стороны, лица
3. Scrum: Sprint Review — Обзор спринта
4. Scrum: Инкремент (и Инкрементальность)
5. Scrum: Definition of Done — определение готовности