«Мы легли на дно, мы зажгли огни, во Вселенной только мы одни». Кажется, эту строчку из песни группы Сплин смело можно признать саундреком внедрения практики Sprint Review у нас в Dodo Pizza.

Disclaimer: в статье Антон описывает первую версию жизнеспособного sprint review. У нас уже есть более продвинутая, но о ней в следующих сериях.

Первая попытка запустить практику sprint review в Dodo Pizza с треском провалилась.
Может быть, вы подумаете, что практики скрама сети пиццерий вообще ни к чему. Однако, одно из главных преимуществ Dodo Pizza — это, как ни странно, собственная IT-система, которая управляет всеми процессами в 495 пиццериях сети в 12 странах мира.

Над этой системой сегодня работает 80+ разработчиков и аналитиков (а будет со временем — больше двухсот). Как быстрорастущий стартап, мы стремимся к предельной эффективности, поэтому используем у себя многие фреймворки «гибкой разработки»: Cкрам, LeSS, экстремальное программирование.

Но что же это за cкрам, спросите вы, без sprint review? И будете правы.

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

Однако у нас такой подход почему-то не работал. Например, на одном из первых sprint review мы показывали франчайзи Dodo Pizza из Казахстана их новый сайт — dodopizza.kz. Обратная связь была вдохновляющая: партнеры говорили, что сайт выглядит шикарно, а на фоне конкурентов так вообще будет казаться шедевром.

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

В общем, вскоре мы такие обзоры спринта по-тихому прекратили.

Через несколько месяцев я решил попробовать снова. К тому моменту у нас было уже восемь команд, работающих над одним бэклогом в фреймворке LeSS. Мы старались следовать всем правилам Large Scale Scrum, и отсутствие sprint review было одним из нарушений.

Я заранее подготовился к тому, что сначала все будет плохо, и правильный формат нужно будет искать, действуя методом проб и ошибок. После каждого обзора я просил участников оценить мероприятие по шкале от 1 до 10 (Днище — Огнище). Сначала оценки были очень низкие, ближе к «днищу». Однако мы не сдавались, экспериментировали, и где-то через пару месяцев они стали смещаться к «Огнищу».

Вот что мы изменили

Делаем домашнюю работу

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

Не показываем недоделанное

Поначалу мы показывали полуготовые фичи. Но поняли, что так мы обманываем команды и, главное, клиентов. Однажды мы показали CEO компании геосервис, кеширующий картографические данные. Потом на следующем обзоре снова его показали — только уже с исправленными багами. Когда мы пришли в третий раз и показали тот же сервис, но уже на боевом сайте, у CEO возник закономерный вопрос: «Какого чёрта вы показываете одно и то же в третий раз?»
Теперь на sprint review мы показываем только то, что выложено на боевой сайт. Если что-то почти готово — осталось только баги пофиксить, протестировать и выложить — не показываем.

Переговорки вместо open space

Авторы LeSS рекомендуют проводить sprint review в форме «базара». Все команды должны показывать свою работу в одном большом помещении, а заинтересованные могут ходить по станциям, которые им интересны. Мы так пробовали несколько раз, получалось шумно и суетливо.

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

Переходы запрещены!

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

Начинаете отвечать — остальные скучают. Игнорируете — человек огорчается. Поэтому мы решили запретить перемещения между группами. Выбрал интересующую тебя тему — сиди в переговорке двадцать минут до следующего перерыва.

Дорогие гости

Мы поняли, что состав «гостей» имеет огромное значение. Ничто так не мотивирует разработчика, как появление на sprint review CEO. Особенно когда надо показать ему какую-нибудь техническую штуку-дрюку вроде сервиса в кубе или перевод Auth на .Net Core. Приходится объяснять, зачем мы это делаем. CEO Dodo Pizza Федор Овчинников заряжает энергией и умеет за три минуты минуты поднять всем настроение и обрисовать горизонты развития компании. Ну а когда мы показываем клиентские фичи, например, конструктор пицц из половинок в мобильном приложении — зовем теперь внешних гостей, как правило, знакомых и друзей из Facebook.

Удаленные участники

Несложно проводить встречу, когда все в одном помещении. Но у нас много удалённых сотрудников в Сыктывкаре, Нижнем Новгороде, Казани и Горячем Ключе. Им тоже важно присутствовать.

Поначалу «удаленщики» жаловались на то, что им было плохо слышно и почти ничего не видно. Сейчас мы заботимся о них так же, как и об офлайн участниках. В чеклисте подготовки к sprint review есть пункты, напоминающие нам о необходимости проверить связь и настроить оборудование. Мы ведем трансляцию в Slack, а с недавнего времени мы стримим мероприятие на нашем youtube-канале Dodo Pizza.

Отказ от обратной связи

Когда стало казаться, что все хорошо и улучшать формат дальше некуда, мы задали себе вопрос: а не фигню ли мы делаем? Обзор спринта — это ведь достаточно дорогое мероприятие (если посмотреть на него цинично — с точки зрения количества участников, их зарплат и потраченных часов). Используем ли мы эти два часа максимально продуктивно? В итоге мы решили полностью отказаться от сбора обратной связи во время sprint review.

В формате такого мероприятия сделать это глубоко и качественно не получается (вспомним кейс с Казахстаном). К тому же большую часть значимых и качественных отзывов мы собираем еще во время спринта, привлекая всех заинтересованных, от внутренних заказчиков до пользователей… Вы удивитесь, даже в Scrum Guide не написано, что на sprint review нужно собирать обратную связь: "During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint." Команда и стейкхолдеры, а не пользователи. Взаимодействуют, а не собирают обратную связь. Совсем другой смысл.

Открываем «кухню»

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

Мы по-прежнему показываем проделанную работу, но кроме этого команды рассказывают историю, которая стоит за новыми фичами. Какая была цель? Что происходило во время спринта? Что нас отвлекало или мешало достичь цели? Какие мы предприняли меры, чтобы спасти цель? Это помогает: так менеджерам становится понятно, например, почему «спрятать звёздочками email клиента в чеке» — совсем непростая задача («полчаса работы программиста», как казалось менеджерам). И наоборот, такой диалог помогает разработчикам думать в терминах «заказчиков» и их проблем, а не в терминах конкретных решений, над которыми они трудятся.

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

Главное, что мы поняли: не нужно зацикливаться на форматах, предложенных в методичках по скраму. Нужно пробовать, ошибаться и экспериментировать. Нет универсальных решений — нужно искать те, которые сработают в вашей ситуации.
Поэтому хочу напоследок предупредить: не копируйте наш формат. Он хорошо работает у нас, потому что родился в результате множества экспериментов. Ищите свой подход — и у вас обязательно получится. Хуже точно не будет.