У вас “Chief Product Owner” и Copy Paste Scrum?

Компании часто неверно интерпретируют отдельные положения Скрама, когда разрабатывают большие продукты. Особенно часто встречается непонимание роли Владельца Продукта. Структура “одна команда один Владелец Продукта”, которую я часто вижу, выглядит примерно так:

Мы называем эту модель Copy Paste Scrum и она вызывает целый ворох проблем:

В общем случае Copy Paste Scrum — фейковый Скрам. В этой статье я объясню почему, а затем мы разберемся в том, как разрабатывать большие продукты, используя Скрам профессионально.

В модели Copy Paste Scrum команды часто образуются вокруг архитектурных систем и компонентов (“платформа”, “CRM”, “BI”), внутренних бизнес процессов (“процессинг”, “биллинг”), технологий (“Android”, “iOS”, “Web”). Появляются искусственные зависимости, которые увеличивает Time-2-Market. “Владельцы Продуктов” становятся координаторами зависимостей. Могут существовать специальные встречи, называемые “PO Sync”-и. Это искусственная сложность. Управлять зависимостями не нужно, от них следует избавляться.

Напоминаю, что в профессиональном Скраме у команд нет зависимостей:

Команды разработчиков являются кросс-функциональными и обладают всеми необходимыми навыками, необходимыми для создания продукта (Скрам Гайд).

Несмотря на то, что Chief Product Owner (CPO) имеет собственный “Бэклог Продукта”, этот артефакт не сквозной. Он представляет коллекцию индивидуальных “Бэклогов Продуктов” команд и определяется их загрузкой, а не потенциальной ценностью для организации и ее клиентов.

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

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

Эту мысль иллюстрирует картинка ниже. Порядок элементов в настоящем сквозном Бэклоге Продукта, приоритезированном с точки зрения самого ценного для организации, никогда не совпадает с порядком элементов в нескольких очередях. В модели Copy Paste Scrum команды всегда сфокусированы не на самом важном с точки зрения организации.

Что такое организационная гибкость? Мне нравится определение Майкла Биддла:

Бизнес-гибкость — это способность быстро и эффективно адаптироваться под любые виды изменений, доставляя при этом максимум ценности и клиентского опыта.

Модель Copy Paste Scrum нельзя назвать гибкой, потому что при значительном изменении рынка команды не способны “подхватить” работу у других команд. Они могут выполнять только конкретные типы фич. Дело в том, что фактическая цель Copy Paste Scrum — эксплуатация экспертизы людей и фокус на выхлопе (outputs), а не организационная гибкость и максимизация бизнес-ценности.

Модель Copy Paste Scrum стимулирует “Владельцев Продуктов” заниматься “пережевыванием” требований, оформлением их в артефакты, а затем передачей их командам. Это отдаляет разработчиков от бизнеса и рынка. Напомню принципы Аджайл Манифеста:

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

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

Руководство по Скраму описывает организационный дизайн в миниатюре. Скрам-команда кросс-функциональна, самоорганизованная, не имеет зависимостей и каждый Спринт может поставлять на рынок готовую функциональность. Этот дизайн реализует ценности и принципы Аджайл Манифеста.

Copy Paste Scrum сохраняет традиционную организацию, лишь взяв на вооружение терминологию Скрама.

Copy Paste Scrum — это фейковый Скрам.

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

Неверно масштабировать Скрам и его элементы (роли, артефакты, процессы). Это подход вызывает усложнение системы управления. Что если мы будем масштабировать продукт, а не Скрам?

Тогда относительно небольшая продуктовая группа размером 50-70 человек имеет простую структуру:

В профессиональном Скраме Бэклог Продукта и Владелец Продукта всегда один, независимо от количества команд.

Несколько Скрам-команд часто работают вместе над одним и тем же продуктом. Один Бэклог Продукта используется для описания предстоящей работы (Руководство по Скраму).

Один Владелец Продукта управляет порядком Бэклога Продукта, отвечая за видение и стратегию развития продукта. Ему помогают команды, которые занимаются уточнением элементов Бэклога Продукта напрямую со стейкхолдерами (пользователи, клиенты), со-создавая с ними функциональность. Так они снимают нагрузку с Владельца Продукта, оставляя за ним видение и стратегию.

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

При дальнейшем масштабировании продукта количество сегментов пользователей и комплексность возрастает. Скрам Гайд не дает ответа на вопрос, как вести разработку гигантских продуктов. Можно воспользоваться Скрам-паттерном Value Areas.

Команды группируются вокруг областей требований (Value Areas) и продолжают независимо поставлять ценность на рынок. Области требований возглавляет бизнес-эксперты, называемые Area Product Owner (APO), работающие с 4-8 командами. Области могут формироваться вокруг клиентских сегментов (B2B, B2C), пользовательского пути (“Joining”, “Supporting”, “Paying”) или рынков (“платежи СНГ”, “Европейские платежи”). Владелец Продукта может перебрасывать команды между областями, поддерживая адаптивность организации.

В основе Скрама лежат идеи бережливого мышления (Lean Thinking). В частности, принцип постоянного движения к совершенству. Профессиональный Скрам устанавливает высокую планку для организаций, моделируя систему, которой тяжело соответствовать, но к которой можно и нужно стремиться. Очень возможно, что, прочитав эту статью, вы чувствуете себя растерянным или разочарованным. Не расстраивайтесь, потому что Скрам — это инструмент непрерывного улучшения.

Скрам показывает относительную эффективность управления вашим продуктом и методов работы, чтобы вы могли постоянно улучшать продукт, команду и рабочую среду (Руководство по Скраму, 2017).

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