Всем привет!

Сегодня я хочу поделиться опытом фасилитации неформальной встречи из фреймворка Scrum под названием “Обзор спринта” или “Sprint Review”. К написанию этой заметки меня побудили наблюдения за командой на серии таких обзоров и пост ребят из Unusual Concepts (далее UC) на аналогичную тему.

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

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

С чего мы начали

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

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

Детали

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

Цель встречи

Инспекция инкремента и, по необходимости, адаптация бэклога продукта.

Осознание, что у встречи есть цель, нам очень помогло. Вдруг выяснилось, что у нас нет инкремента, который бы мы могли инспектировать. Да и само понятие инкремента у нас отсутствует. Это, кроме прочего, показало нам, что еще в начале спринта, на спринт-планировании, мы стали “дрейфовать”.

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

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

Участники встречи

Скрам-команд и приглашенные Владельцем продукта стекйхолдеры. Под стейкхолдерами я понимаю всех заинтересованных в продукте лиц. Это и пользователи, и спонсоры, и представители других команд. В общем, здесь Владельцу продукта действительно виднее, кого лучше пригласить.

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

На что именно мне бы хотелось обратить ваше внимание. Если на обзоре спринта у вас нет стейкхолдеров, это очень сильный звоночек с вопросами: “А что вообще происходит?” и “А есть ли вообще у продукта заинтересованные лица?”. Или “Может быть этот продукт вообще никому не нужен и неинтересен, кроме Владельца продукта?”.

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

Владелец продукта объясняет, что готово, а что нет

В этой части мы еще немного “плаваем”, потому что для себя до конца не поняли, что и кому он объясняет. Здесь видимо речь о стейкхолдерах, потому как команда и так прекрасно знает, что у нее готово.

Команда разработки обсуждает, что получилось

А также, какие были проблемы и как они решались. Здесь у нас тоже пока всё “тонко”. Мы учимся разговаривать на эти темы в неформальном ключе, без отчетов и статусов. И здесь рекомендация ребят из UC о печенюжках, пожалуй, самая актуальная.

Команда разработки демонстрирует готовую работу

и отвечает на вопросы по инкременту. Здесь — просто для творчества. Иногда команда сама показывает, что сделано. Иногда к нам приходит реальный пользователь и сам садится за продукт и пробует его на деле. Однако, из наблюдений хочется порекомендовать не ждать обзора спринта, чтобы пригласить пользователя. Как правило, его можно и нужно ловить внутри спринта и сразу же демонстрировать сделанную работу, чтобы собирать обратную связь. Так продукт получается слаще и интереснее для пользователя.

Владелец продукта обсуждает бэклог продукта

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

Все обсуждают, над чем стоит работать дальше

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

Еще на этом шаге бывает полезно помочь высказаться разным стейкхолдерам-спонсорам. Фактически, это хорошая площадка для того, чтобы они сами между собой договорились о том, что стоит дальше делать по продукту. А это — помощь в приоритетах Владельцу Продукта.

Все обсуждают изменения на рынке

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

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

Обзор сроков, бюджетов, возможностей для прогноза следующего релиза продукта

Здесь мы в целом обсуждаем со всеми присутствующими прогноз по следующему релизу. Например, здесь может быть полезным напомнить о данных Владельцем продукта обещаниях и как-то скорректировать приоритет элементов в бэклоге продукта. Или, например, если вы работаете с аутсорсной командой по схеме “time and material”, отсылка к оставшемуся бюджету тоже быть полезна при выборе следующих для проработки элементов и последующего релиза.

Итоги

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

И здесь я соглашусь с ребятами из UC. Самое важное, на мой взгляд, что происходит на этой встрече — это общение между людьми.

Сейчас мы используем вот такой флип-чарт напоминалку о самых важных шагах этого события:

Удачи вам!

И хороших, насыщенный, общительных, веселых и неформальных обзоров спринта с пиццей и напитками.