Заметки на полях: что было интересного на ENTERPRISE AGILE RUSSIA 2019

20 сентября мне удалось побывать на Enterprise Agile Russia – первой в России конференции, посвященной SAFe. На мероприятии освещалась тема, которая волнуют все больше людей – как работать в соответствии с принципами Agile в масштабе крупного предприятия. Цель организаторов – помочь участникам понять зачем нужен SAFe, как запуститься и выравниваться в процессе, как добиться улучшений и перенести маленькие успехи на всю компанию. 

Я не буду освещать все доклады, так как в скором времени доступ к ним появится на YouTube-канале ScrumTrek. Сейчас я остановлюсь на выступлении Mark Richards, а именно на тех вещах, которые лично для меня оказались наиболее интересны в свете опыта внедрения SAFe в нашей компании. 

Марк один из немногих, кто удостоен статуса SAFe Fellow. В группе всего 18 человек. Это признанные идейные лидеры и практики SAFe, которые не только продемонстрировали наивысшую степень мастерства в области внедрения и практического применения SAFe, но и содействуют развитию фреймворка. 

В докладе “Business Agility за счет кросс-технологичных ARTs” Марк поделился своими ошибками и уроками, которые он извлек за годы Lean/Agile-коучинга и практического внедрения SAFe в крупных организациях.

Кейс 1: The Software is the Product

Agile Dev Teams use a consistent recipe, but Agile Business Teams require more creativity and Kanban is usually a better fit

Марк отметил, что с гибкостью Software Development все достаточно понятно. Существуют материалы, описывающие внедрение и управление гибкой разработкой. Ситуация со стороны бизнеса несколько иная. SAFe активно фокусируется на решении проблем, существующих в контексте гибкости бизнеса. Если кто-нибудь пробовал примерять Scrum на команды маркетинга или продаж, то поймут, о чем речь. Канбан в данной парадигме ложится лучше на бизнес-команды.

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

You’ve spent years learning to live apart, now you have to learn to live together. 

Единый Release Train в SAFe действительно заставляет выравнивать команды и фокусироваться на единой цели. Говоря о Development Teams, у людей, привыкших работать компонентно, развивается конвейерное мышление: собрал компоненту – принялся за новую. В попытках начать работать в одной команде, такие товарищи соберутся, обсудят совместную работу и успешно разойдутся работать каждый над своей компонентой. Создать в такой ситуации команду и показать, что у всех есть одна цель для меня лично оказалось непросто. Собрать людей из Business Teams и Dev Teams в единую команду оказалось еще более сложной задачей. 

It’s easy to forget your early struggles and how much you had to learn. You have to slow down and support your new Business Teams as they begin their journey.

Практика трансформации показывает что нужно быть готовым идти по кривой принятия новой технологии д. Мура (Рис. 1).

Внедрение инноваций – будь то технологии или инновации на организационном уровне –  сопряжено с трудностями. Этот момент усугубляется еще и тем, что у команды нет опыта совместной работы. Соответственно, будут присутствовать все стадии развития группы по Такмену (Рис.2).

А еще, все метрики, которые имели место быть, скорее всего слетят. Надо продолжать помогать командам расти, так как в долгосрочной перспективе эта стратегия может оказаться выигрышной.

Кейс 2: The Service is the Product

When change impacts staff, frequent change is hard! The best people to figure out how to solve that problem are business people. 

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

Одна из наиболее часто возникающих ситуаций – когда заказчик закидывает команду изменениями. Идей у такого заказчика много, мысли растекаются по древу. Требования на изменения вносятся с завидной регулярностью. При этом результат нужен быстро. Это не простой стейкхолдер для команды, но взаимоотношения с ним все же можно вывести в конструктивное русло. Работу можно наладить, если разговаривать с заказчиком на его языке. К сожалению, не все это умеют и говорят: “Все оговоренные требования зафиксированы, а вы постоянно их меняете. Вы сами не можете определиться с тем, что вам надо!” или “Вы постоянно меняете требования. Как только мы начинаем эти требования реализовывать, вы сразу все меняете. Что вы от нас ждете?” Одно из моих “любимых”: “Мы работаем по Скраму, значит вы не можете менять требования в середине итерации!” =) Во всех этих сценариях велика вероятность, что взаимопонимания с заказчиком вы не достигнете. Вы, как человек управляющий требованиями, будете винить его, а он – вас.

Сменив риторику, Вы может быть услышаны. Например: “Я посчитал метрики. Сейчас команда за 2 недели в среднем теряет Х ₽, чтобы переключаться на новые задачи, которые появляются в результате изменения требований. Мой опыт показывает, что если мы не можем зафиксировать требования, значит мы их просто плохо прорабатываем. Давайте предпримем следующие действия, чтобы более уверенно подходить к итерациям.” Я бы советовал не жалеть время и использовать практики Impact Mapping и User Story Mapping. Разговаривать со стейкхолдером на одном языке не всегда просто, но позволяет сэкономить ресурсы и силы.

Возможно вы поступаете именно так, и беклог проработан и зафиксирован. Но в ряде случаев изменения могут появляться от других команд. Например, системные команды могут часто менять стандарты и инфраструктуру, или в вашей организации часто меняются правила игры. Для подобных ситуаций подходят единые Agile Release Train (Рис. 3) и Program Increment. Это тоже способ управления изменениями, который заставляет все команды готовиться и фиксировать набор изменений, необходимых для достижения общей цели организации. 

There’s far more to assurance than software testing, and it’s a huge cause of delays. Bring your business assurance people onto the team and learn how to achieve assurance flow together!

Тестировать софт, конечно, хорошо, и это обязательно надо делать. Однако, если Feature реализована не так, как это ожидается заказчиком, то вся работа стопорится на согласованиях, изменениях требований и т.д. В простом слове “ожидания” часто скрывается масса нюансов, которые делают саму суть этого слова очень сложным и тяжело воспроизводимым. 

На практике получается так, что вроде как все видели описание, дизайн и UX-прототипы, но когда начинают ходить по системе “живые” данные, и стейкхолдер наконец-то может “потрогать” систему, то появляются новые сценарии. В этот момент выявляется несогласованность “ожиданий”. А что делать, если мы уже потратили много времени на тестирование и аналитику – все переделывать? В такой ситуации прибегают к тому, что закидывают заказчика “Запросами на изменения”. Основные задержки всегда бывают на утверждениях и на согласованиях с бизнесом. Чем больше объем функционала выкатывается, тем дольше будем согласовывать, тем больше риск сделать ненужную работу и просто потерять деньги. В концепции SAFe есть описание Feature Team. Марк говорит о том, чтобы мы добавляли в эти feature-команды людей со стороны бизнеса. Самый недорогой способ попасть в ожидания бизнес-заказчика или ряда stakeholder-ов – это взять их в команду. Надо договориться на начальном этапе о времени, которое они должны будут выделять на работу, и выстроить процессы взаимодействия. Как это происходит в бизнесе заказной разработки также можно описывать в отдельной статье, так как сюда это явно не поместится.

Don’t have business teams and technology teams. Set your teams up for success by making them real teams with an enabling structure and compelling direction.

Создавать кросс-функциональные команды непросто: управлять персоналом, понимать, какие люди в каком бизнесе должны работать совместно, чтобы эти команды были продуктивными очень трудно. Фасилитация работы этих команд также непростое дело. В нашей компании мы до сих пор пытаемся решить этот нелегкий вопрос. Тут очень легко попасть в ограничения по численности эффективной команды, также сразу встает много вопросов с выделением capacity этих людей и, как следствие, вопросы с тем, сколько таких активностей и в рамках какого процесса они смогут выдерживать и не перегорать. Лично для меня этот вопрос пока остается до конца нераскрытым с точки зрения эффективности управления.

Прослушав доклад “Business Agility за счет кросс-технологичных ARTs”, я понял, что совершал ошибки, о которых рассказал Марк. Надеюсь, этот небольшой обзор пригодится вам и подскажет, на что обратить внимание при внедрении SAFe в вашей компании. 

Подробнее изучить вопрос про:

• Agile Release Train здесь.
• Program Increment здесь.
• Feature Team здесь.