LeSS в Додо Пицце: эволюция или революция

Текст выступления Дмитрия Павлова и Антона Бевзюка (Додо Пицца) на конференции Agile Days 21 марта 2019 года.
Видео доступно на YouTube-канале ScrumTrek, слайды – в программе конференции.

За последние 2 года наша команда разработки выросла с 20 до 70 разработчиков. В следующие 2 года мы планируем вырасти еще в 4 раза. Начав со Scrum, в прошлом году мы сформировали фича-команды и перешли на LeSS, а с января разделились на 2 Area и теперь у нас LeSS Huge. За это время мы пережили несколько революций процессов, помимо постоянных эволюционных изменений. В результате многочисленных экспериментов с процессами мы кое в чём отклоняемся от правил Scrum/LeSS, но делаем это осознанно. Мы расскажем, что делаем не «по методичке», и почему для нас это работает лучше. Будем развенчивать мифы и рвать шаблоны.

Дмитрий Павлов, Директор по продукту, Додо Пицца, Москва

Антон Бевзюк, Chief Agile Officer, Додо Пицца, Москва (по состоянию на март 2019)

Изначально мы назвали доклад «Эволюция или Революция». Пока его готовили, поняли, что хотим о другом рассказать, но название оставили. Мы расскажем про методички, и как мы от них отступаем, то есть, что мы делаем не по правилам. Но и про эволюцию тоже немножко поговорим.
Для начала немножко про Додо Пиццу. Кто же мы такие и почему будем рассказывать про LeSS и LeSS Huge? Сейчас у нас 456 пиццерий и мы работаем в 12 странах. У нас сеть пиццерий, но это всего лишь прикрытие. Мы разрабатываем информационную систему — Dodo IS. Когда вы заходите в нашу пиццерию, вы видите «ТВ-борды», меню, кассу ресторана, и всё это — составные части нашей информационной системы. Нам нужны пиццерии, чтобы куда-то нашу систему выкладывать.

У нас есть модуль трекинга, через который проходят все заказы. У нас есть «Оленька» — «искусственный Додо-разум», умная система, которая помогает следить за новыми заказами и поддерживать нужный темп работы. Также есть интерфейс менеджера смены, управляющего пиццерии, огромный блок с отчётами — в общем, это очень большая система. У нас также есть Digital часть, каналы, где можно оформить заказ — это сайт, это приложение, колл-центр. Наш бизнес в основном оффлайновый, но мы его «диджитализируем» с помощью Dodo IS.

Мы очень быстро растём. Сейчас у нас уже 70 разработчиков и 9 команд. Несколько месяцев назад у нас было 50 разработчиков, и мы поставили себе цель вырасти до 250 до конца 2020 года.

Синим цветом — наш предполагаемый график роста, красным — то, как мы реально растём

В начале 2018 года у нас было 6 команд и мы использовали Scrum. За первую половину 2018 года нас 2 раза очень мощно накрыло проблемами. 1-я проблема возникла 14 февраля, когда мы не выдержали повышенную нагрузку. 2-я проблема была в мае, когда у нас запустилась федеральная рекламная кампания, и мы тоже оказались к ней не готовы. Эти события подтолкнули нас к первой революции. Мы поняли, что надо перестраивать процессы и запустили LeSS на 6 команд. Потом мы начали экспериментировать со Sprint Reviews, с OKR, ввели дизайн-воркшопы и stop-the-line практику.

Сейчас у нас 9 команд, и в январе этого года мы сделали ещё один такой скачок: разделились на 2 Area (“области”, терминология из LeSS Huge). Теперь у нас LeSS Huge, первый официальный кейс в России. И мы сейчас продолжаем эволюционировать, про это дальше и расскажем. Это наш личный опыт, используйте его на свой страх и риск или не используйте вовсе. У вас свой контекст, своя команда и своя специфика продукта.
В Додо есть несколько принципов. 2 из них: принципы доверия и открытости. У нас открытые кухни, там есть камеры, и мы свою финансовую отчётность публикуем открыто. Следующий принцип — «no-bullshit», и этот принцип позволяет нам оспаривать любые решения. Любой человек, если видит «буллшит», то есть фигню, в чём угодно, в процессах, в поведении, он может об этом открыто сказать. Ещё один принцип — «мудаков у нас нет», то есть мы предполагаем, что люди у нас правильные, открытые, честные. А если это не так, то мы таких не нанимаем, или они уходят. Эти принципы нам очень помогают, в том числе и менять процессы. Когда мы видим, что что-то написано в методичке, а у нас оно что-то не взлетает, надо задать вопрос, а не фигню ли мы делаем.

Рассказываем, в чем мы отклоняется от методичек фреймворков Scrum и LeSS, какие процессы мы улучшили для себя.

Первый тезис: Product Owner должен быть один. Это цитата из Скрам Гайда (Scrum Guide).

Product Owner — лицо, принимающее решение о продукте, это визионер, который знает, куда развивать продукт, он управляет бэклогом, он работает с командами, принимает работу. Product Owner — это такой mini-CEO. Он должен отвечать за P&L, обладать видением продукта, быть постоянно доступен, при этом он должен как-то ещё peer’ом с командой, чтобы они балансировали отношения. Он также может увольнять команду разработки, нанимать себе другую.
В жизни вы таких много людей видели? Мы — нет, поэтому у нас не так. Слишком много для одного человека. У нас эта классическая роль, как она описана в Скрам Гайде, размазана. Федор отвечает за стратегию и за бюджет, а Дима управляет бэклогом и работает с командами. При этом ещё в этот процесс вовлечены руководители направлений бизнесовых: маркетинг, пиццерии, Digital сегмент и так далее. И большая часть решений принимаются командно. Если решение не получается, тогда Дима выстраивает приоритет, но как правило, это не требуется.

Часто говорят, что Product Owner как комитет — это не сработает, потому что все будут ссорится, отбирать друг у друга ресурсы команды и так далее. У нас это не происходит, потому что это диктуется нашей культурой.

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

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

Следующий тезис: Scrum, LeSS и другие фреймворки нужны вам, потому что вам нужна гибкость. У вас полная неопределённость, запутанный домен, ничего не понятно, бэклог каждый день меняется.

Задайте себе вопрос: сколько % бэклога меняются во время спринта? Действительно ли у вас такая высокая неопределённость? Если да — вы получите все преимущества от Scrum и кросс-функциональных команд и от гибкости. Но если нет, то вы можете получать преимущества от других вещей: от предсказуемости, от фокуса, от специализации.
Мы поняли, что мы ни в одной из крайностей и не посередине, а где-то ближе к определенности. Наш бэклог не так часто меняется, и меняется примерно на 20%, а для остальных 80% мы знаем, куда мы пойдём и куда будем развиваться. Например, мы выпускаем кассу доставки и знаем, что не откажемся от концепции доставки и не поменяем полностью бизнес-модель, и бэклог не перестроится.

Следующий тезис, который тоже часто используют коучи: команда должна делать всё.

У команды есть все компетенции, она умеет делать Customer Development, разрабатывает, тестирует, потом выкладывает в продакшн, осуществляет поддержку пользователей. Хорошо, если она при этом еще бизнес-метрики соберёт, на фидбэк отреагирует.
Цитата из LeSS: “все ключевые функции должна делать сама команда”. Но у нас опять-таки не так. Наш продукт очень сложный. На некоторые гипотезы точно одного спринта не хватит, нужно месяцы работы, чтобы просто погрузиться в домен. Поэтому мы пришли к модели, когда команды у нас кросс-доменные, а продакт-менеджеры узкоспециализированные. И, как правило, это люди, которые сами в пиццерии работали или очень много времени проводят в нашей рознице для того, чтобы понимать эту экспертизу и формулировать глубокие и прорывные идеи и гипотезы.

Следующий тезис — Collective code ownership, то есть код в продукте принадлежит всем командам, и они в нём ориентируются.
Есть Feature Adoption Map, когда мы должны стремиться вот туда в правый верхний угол, где команды знают всё про продукт и умеют его полностью поддерживать.

И наши команды начали на это настраиваться с самого начала. И поняли, что Collective code ownership — это хорошо и правильно, и надо туда идти, но это нужно делать постепенно. Если попытаться это сделать сразу, то вы попадёте в no ownership: все могут менять весь код, но никто им не владеет, никто не понимает как он должен развиваться, никто не следит за его чистотой.

Промежуточный шаг к Collective code ownership — это Component ownership, один из паттернов LeSS.
При этом у компонентов кода есть component owner, который будет думать, как ему развивать и рефакторить его. Другие команды могут помогать, вливать код в тот же компонент, перед этим пообщавшись с этим component owner.

Ещё один тезис — выделенные команды для чего-либо. Мы такие команды обычно не создаём, потому что собираем всю экспертизу в одном месте.
Вот пример из команды QA. Мы собрали тестировщиков, на берегу договорились, что команда будет существовать месяцев 6-7, основная задача — это автоматизировать ручное тестирование, чтобы можно было выкладываться в продакшн без ручного регресса. После этого мы их распределили по разным командам, и сейчас у нас нет выделенной команды QA.
Второй пример, команда платформы или SRE. Она у нас выделенная, потому что чтобы погрузиться в нашу инфраструктуру, требуется много времени. Гемба этой команды — это другие команды разработки, соблюдение нефункциональных требований, помощь командам с инструментами, например логированием или мониторингом. У нас бывают “шахматы”: когда кто-то из SRE команды уходит в команду разработки и наоборот.

До этого мы приводили примеры, когда облегчаем какие-то правила или отступаем от них, но есть один пример, когда мы, наоборот, усиливаем правило. В LeSS есть обязательные правила, которые образуют сам фреймворк, и есть рекомендации, которые можно делать по желанию. К сожалению, в LeSS техническое совершенство – Technical excellence – не входит в обязательный набор правил. А для нас это не так: для нас это обязательно, мы делаем ставку на Technical excellence и вкладываемся очень сильно. Мы прокачиваем наших разработчиков, организуем для них внутренние тренинги, интенсивы, мастер-классы. По нашему мнению, ни Scrum, ни LeSS, ни SAFe не заработают, пока у вас нет сильной инженерной культуры.

Ищите свой процесс, не бойтесь экспериментировать. В любом случае получите опыт, а может быть даже придумаете что-то лучше. И самое важное, что хочется сказать нам, как людям с очень сильным разработческим бэкграундом, Technical excellence решает всегда. Когда у нас есть Technical excellence, билды, откаты, докаты, автотесты, там уже Scrum можно строить, LeSS, или изобрести свой процесс.

Дмитрий Павлов d.pavlov@dodopizza.com

Антон Бевзюк bevzuk@gmail.com