Внедрение Scrum в организации

Скрам фреймворк прост, в нем всего 11 элементов. И все же в самом начале пути всегда встает вопрос - как внедрить все 11 сразу? А если не все сразу, то с чего начать? В скрам-гайде написано, что скрам работает только целиком.

Обычно начинается с того, что легче всего внедряется - спринты, бэклог спринта, планирование, дэйли скрам, обзоры. Потом переходим к более сложным - кросс-функциональные команды, ретроспективы, бэклог продукта. И на закуску оставляем то, что внедрить уже потом практически невозможно - владелец продукта, продукт/инкремент и full-time скрам-мастер.

Результат - скрам не работает. Нет ничего хуже для скрам-мастера, чем увидеть себя в ситуации необходимости тратить по 8 часов в день на поддержку зомби скрама в 3+ командах. Если вдруг мне, как Scrum-мастеру, кажется, что неправильные пчелы не дают мне делать правильный скрам, то скорее всего проблема в порядке внедрения и пчелы тут не причем.

Принцип "съешь лягушку" предписывает нам начать внедрение с самых трудных элементов.

1. Scrum-мастер

Scrum нужен для повышения гибкости бизнеса в организации (см. "В чем разница между Agile и Scrum?). Внедрение Scrum всегда сопровождается сильными, порой радикальными и судьбоносными изменениями в организации, поэтому нужно четко себе ответить на следующие вопросы:

• Как можно кратко (в несколько предложений) описать ситуацию в организации, в связи с которой понадобился Scrum? Почему эту ситуацию надо менять?
• Кто взял на себя ответственность за решение и какой у него на это бюджет?
• Что плохого случится у него, если ничего не менять?
• Сколько ещё времени он может терпеть эту ситуацию?
• Какие ещё есть варианты решения, кроме Scrum, и почему Scrum лучше них?
• Как будет измеряться выгода от внедрения Scrum?

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

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

2. Продукт/инкремент

10-й принцип аджайл предписывает нам регулярно спрашивать себя, а не херню ли мы делаем? Если компания тратит деньги на команду разработчиков какого-то своего продукта, значит развитие продукта очень нужно бизнесу (см. "Что такое продукт?").

Чтобы выделить продукт, можно воспользоваться следующими вопросами:

• Почему развитие продукта очень важно для бизнеса? Какой стратегической цели достигнет бизнес с помощью развития этого продукта?
• Кто является идеальным клиентом для этого продукта?
• Как клиент сейчас живет без продукта/инкремента?
• В чём проблема? Почему нельзя оставить всё как есть?
• Какие альтернативные решения есть у клиента?
• Как можно измерить ценность этого продукта для клиента?
• Где границы этого продукта (что в него включено, а что нет)?
• Какими самыми минимальными усилиями команды можно отгрузить ценность клиенту? (пресловутое MVP)
• Как с точки зрения клиента выглядит весь процесс получения ценности?

Заказчиком продукта может быть конкретный бизнес (продукт как проект) либо рынок (продукт как готовое решение). В первом случае нужно будет посчитать ROI как есть: с какой скоростью расходы на разработку вернутся в виде прибыли/капитализации? Во втором случае ROI рассчитывается через P&L. Эти расчеты есть у Владельца Продукта, но наша задача - убедиться, что они есть, в них всё логично и обосновано.

3. Владелец продукта

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

Кто отвечает за то, что инвестор получит назад свои деньги? Какой там ROI? Это один человек или группа? Если группа, то почему не один? Если группа, то согласны ли они все одновременно (!) тратить до 50% своего рабочего времени на согласование между собой и коммуникацию, связанную с разработкой? Если не согласны, то кому одному из них они все могут доверить принятие решений и при каких условиях и почему условия именно такие?

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

Давайте попробуем поразмышлять на тему, кто лучше справится с ролью PO. Представьте, что вы генеральный директор компании. Вы собираетесь делегировать ответственность за P&L по одному из продуктов компании. У вас есть два кандидата:

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

Кого из них при прочих равных вы выберете? Им обоим недостает опыта, но в разном - одному не хватает знания вашего бизнеса, второму не хватает продуктовых знаний. А если в компании не один такой продукт, а десять?

Роль владельца продукта часто имеет следующие вариации (примеры для интернет-телеком):

• Chief Product Owner (сокр. - CPO) - сидит на P&L и отвечает за бизнес-направление. Например, домашний проводной интернет.
• Product Owner - отвечает за один из продуктов в рамках бизнес-направления. Например, тарифы домашнего интернета для любителей он-лайн игр.
• Area Product Owner (сокр. - APO) - отвечает за развитие продуктовой функции (capability). Например, игровые бонусы к тарифам по играм MMO RPG, игровые Wi-Fi роутеры к тарифам для он-лайн игр, и т.д.

4. Кросс-функциональная команда разработчиков

Одна из самых серьезных проблем организации - чудовищные координационные издержки на пути разработки продуктов. Сформировать какую-нибудь команду организация сможет и без SM. Однако, смогут ли они сформировать действительно автономную с точки зрения внешних зависимостей команду, которая сможет запилить любую фичу, решить любой дефект в продукте? Будет ли в этой команде ЛДПР (Лицо Действительно Принимающее Решения)? Скорее всего нет, потому что иначе Scrum такой организации уже не нужен.

Какие навыки и технологии нужны, чтобы разработать продукт/инкремент? Где нам взять full-time специалистов, чтобы закрыть весь стэк навыков и технологий? Какие технологии и навыки являются узким местом (знает/умеет только один специалист, part-time специалист, удаленный специалист)? Как мы будем снижать риски по узким местам?

5. Бэклог продукта

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

Однако, необходимо четко понимать, что офигительный UX, customer-oriented продукт - это всё не является целью разработки. Удобство для клиента нужно не само по себе, а чтоб денег заработать - повысить рентабельность или капитализацию бизнеса. Поэтому каждый элемент бэклога должен иметь business value или потенциал снижения TCO (total cost of ownership). Business Value может быть как числовой метрикой относительно стратегической цели бизнеса в отношении продукта, так и текстовым описанием бизнес-гипотез владельца продукта. Каждая итерация в разработке - это эксперимент по проверке одной или нескольких гипотез, которые делают бизнес ближе к его целям. В этом суть разработки.

Ещё один важный момент в том, что далеко не все гипотезы нужно проверять силами команды из от 3 до 9 высокоплачиваемых специалистов. Продукт можно развивать силами одного менеджера продукта, который периодически будет выдергивать некоторых сотрудников из операционки на какие-то разовые работы (например, дизайнера отвлечь на 1-2 часа, чтобы вместе сделать пару мокапов для тестирования гипотез). В какой момент для развития продукта становится нужна целая команда разработчиков? Ответ - риски бизнеса, которые нельзя снизить без разработки. Их можно разделить на две категории: низкая удовлетворенность (лояльность) клиентов и высокие операционные расходы.

Когда говорим "клиентов", то кроме пользователей не забываем про Лицо Принимающее Решение (ЛПР), Лиц Влияющих на принятие Решения (ЛВР-ов) и Лицо Действительно Принимающее Решение (ЛДПР) на стороне заказчика. В целом, речь идет про фасад продукта - ту часть, которая обращена в рынок. PO берет какой нибудь потребный формат для описания текущего клиентского/пользовательского опыта (например, Customer Journey Map, сокр. - CJM), рисует его исходя из своего представления, выделяет там критические (болевые) точки, идет проверять свои представления с помощью клиентских интервью, корректирует описание, раскатывает это в бэклог (например, через User Story Map, сокр. - USM) и поехали в разработку.

Высокие операционные расходы, напротив, это внутренние узкие места в организации, которые мешают брать на борт большее количество клиентов и пользователей. Обычно команда делает какую-то автоматизацию для сотрудников организации, пытаясь снизить операционные расходы, освобождая дорогу для масштабирования. Например, биллинг на 30 клиентов b2b требует ежемесячно на 2-3 рабочих дня выключать секретаря и старшего аккаунт-менеджера на ручную обработку, перепроверку данных и отправку счетов на оплату. Если АКБ (активная клиентская база) вырастет в 10 раз, то вся остальная не менее важная работа этих двух сотрудников встанет. Бизнес нельзя масштабировать, не расшивая это узкое место. В этом случае в бэклог мы складываем эти узкие места, описанные не в виде решений, а в виде проблем, чтобы команда предлагала решения.

6. Спринты

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

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

Нужна консультация?

Если вам нужна бесплатная консультация по внедрению Scrum-фреймворка в организацию, оставьте ваш контакт для связи (перезваниваю в течение одного дня), либо напишите мне в телеграм (как правило отвечаю в течение часа).