Кейс: внедрение SAFe в глобальном ретейле

Особенности периметра и вызовы, с которыми столкнулись наши консультанты:
1
14 команд в нескольких центрах разработки (США, Великобритания, Германия, Индия) - культурные особенности, быстрая коммуникация осложнена различием временных зон, большое количество промежуточных менеджеров.
2
Задачей этих 14 команд было развитие ритейловой платформы, которая обслуживала несколько бизнес-линий - критичная для клиента бизнес-система с высочайшими требованиями к надежности доступности разрабатывалась большим количеством плохо координируемых команд.
3
Два владельца бюджета - разные годовые цели и разные роадмапы, не учитывающие новую стратегическую инициативу. Нет площадки для диалога относительно сквозных приоритетов.
4
Стабильная и предсказуемая поставка независимых фич на уровне отдельных команд - наряду с раздельным подчинением команд создавало культуру межевания ответственности, а не сотрудничества. За последние 6 месяцев не было поставлено ни одной фичи с зависимостями от других команд.
5
Горизонт разработки 2 года и более - отсутствие возможностей для оперативного реагирования на особенности локальных рынков, достижение стратегических инициатив бизнеса ограничивалось (предположительно) развитием IT.
6
Команды использовали в работе Scrum и Kanban разного уровня зрелости, некоторые работали по своему ad-Hoc процессу - затрудняло взаимодействие между командами на уровне общего понимания производственных процессов, не было механизма быстрого принятия решений без эскалаций.
7
Команда, ответственная за архитектурный надзор, находилась в Нью-Йорке - наличие внутреннего регулирующего органа, также географически удаленного (а также удаленного в разрезе временных зон) от каждой из команд, увеличивало время формальных согласований и общее время поставки фич.
Решение
Для преодоления описанных вызовов было реализовано:
1
Внедрение SAFe как коммуникационного фреймворка и инструмента управления зависимостями.
2
1,5-месячные каденции сквозного планирования и разработки (PI) с недельными итерациями.
3
Ротация центров разработки (DCR, Development Center Rotation) и мероприятие “online ротация” в спринте инноваций. На ротации слетались представители всех команд и выступали связующими звеньями с командами в центрах разработки.
4
Кик-офф всей “команды команд” непосредственно перед первым планированием PI, когда собрали практически всех в головном офисе. 
5
Предварительное обучение и онбординг для новых ролей нового процесса.
Результаты

Влияние на бизнес по оценке клиента порядка сотен миллионов долларов.

Стабильная и предсказуемая поставка 6-7 кросс-командных фич в каждую 1,5-месячную каденцию PI.

После успешного внедрения на контуре 14 команд было принято решение о вертикальном масштабировании SAFe на уровень портфельного управления (с использованием Kanban портфельных инициатив).

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