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

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

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

Все мало мальски подкованные в тайм-менеджменте и личной эффективности знают правило "съешь лягушку", и поэтому лучше начать внедрение с самых трудных элементов.

1. Scrum-мастер

Full-time позиция подразумевает ответственность за что-то значимое для организации. Кому и зачем нужен Scrum в организации? Какую проблему в организации надо решать? Кого это волнует больше всех? Кто decision maker? Кто спонсор? А кто power-спонсор? В чем причины проблемы? А причины причин? Исходя из этого - какая цель у организации? А если по SMARTу? Как мы узнаем, что проблема решена?

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

10-й принцип аджайл предписывает нам регулярно спрашивать себя, а не херню ли мы делаем?

Я бы задал следующие вопросы: Кто пользователь? Каков его текущий UX (без продукта)? Какой UX он получит с продуктом? Почему пользователь захочет поменять свой текущий UX на новый UX? В чём ценность продукта для организации? Кто конкретно в организации заинтересован в продукте и почему? Что из ответов является фактами, а что - гипотезами? Какой приоритет по критичности у этих гипотез? Как их можно проверить, снизив риски? Как измерить результаты каждой проверки? В каком порядке надо проверять?

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

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

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

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

Одна из самых серьезных проблем организации - чудовищные координационные издержки на пути разработки продуктов.

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

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

Разработка - это всегда долго, дорого и с багами.

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

6. Спринты

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

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